A Distributed Transaction Consistency Guarantee Method and Server for Medical Information Integration

Abstract

This application discloses a distributed transaction consistency guarantee method and server for medical information integration, relating to the field of platform integration technology. The method includes: obtaining a business operation identifier; parsing and determining multiple distributed medical service participants participating in the global transaction from a preset participant configuration file based on the business operation identifier, generating a globally unique transaction ID; extracting key business state parameters and constructing an instantaneous state vector; generating a transaction pre-check request containing the globally unique transaction ID and the instantaneous state vector, and distributing it in parallel to all distributed medical service participants; summarizing all pre-check responses, and, under the condition that all pre-check responses are successful, using the instantaneous state vector as a lock identifier to acquire an exclusive lock in a distributed lock service; and issuing a final execution instruction to all distributed medical service participants to commit the local transaction. This application can effectively reduce the risk of medical accidents caused by transaction rollback.

Description

Technical Field

[0001] This application relates to the field of platform integration technology, and in particular to a distributed transaction consistency guarantee method and server for medical information integration. Background Technology

[0002] With the continuous development of medical informatization, modern hospitals have generally established multiple specialized information systems, including HIS (Hospital Information System), EMR (Electronic Medical Record System), LIS (Laboratory Information System), RIS (Radiology Information System), pharmacy management system, and blood bank management system. While these systems improve the efficiency and quality of medical services, they also bring complex challenges to data consistency and business coordination between systems.

[0003] In healthcare scenarios, many critical operations require collaborative processing across multiple systems. For example, a patient's surgical procedure involves the joint operation of surgical scheduling, anesthesia management, drug management, blood bank, and billing systems; similarly, emergency resuscitation requires simultaneous access to laboratory, imaging, pharmacy, and bed management systems. These cross-system business operations essentially constitute distributed transactions, requiring all participating systems to either all succeed or all be rolled back to ensure the consistency of medical data and the integrity of business processes.

[0004] Currently, the most widely adopted distributed transaction solutions in the industry include the TCC (Try-Confirm-Cancel) mode. The TCC mode ensures the consistency of distributed transactions through a three-phase protocol: reserving resources in the Try phase, confirming and committing in the Confirm phase, and releasing resources in the Cancel phase.

[0005] However, the aforementioned TCC (Traffic Control Circle) solution primarily focuses on consistency guarantees during transaction execution, i.e., ensuring the consistency of operational states among all participants after a transaction has started. While this post-event guarantee mechanism is effective in general business scenarios, it faces significant challenges in the medical environment. Medical operations are characterized by high timeliness and high risk, with frequent and unpredictable changes in business states, such as sudden changes in patient vital signs, temporary allocation of critical medical resources, and priority handling of emergency medical events. These dynamic factors make the effective window of medical transactions extremely short. Furthermore, in medical scenarios, the executability of business operations often depends on the real-time states of multiple systems, such as the inventory quantity of specific drug specifications, the availability of specific blood types, the usage status of critical medical equipment, and the scheduling of medical staff. This state information may change at any time during transaction execution. The aforementioned solutions often only discover state conflicts halfway through the transaction execution. Rolling back the transaction at this point not only wastes system resources but, more importantly, may delay the patient's optimal treatment time.

[0006] In summary, because medical transactions have extremely short validity windows and are subject to numerous dynamically changing states, the traditional distributed transaction solutions mentioned above only discover state conflicts after the transaction has started, which is too late and greatly increases the risk of medical accidents. For example, in a complex surgery involving multiple interconnected systems such as medication preparation, blood preparation, and billing, if it is discovered midway through execution that a specific blood type in the blood bank has just been used up by another emergency surgery, the rollback of the entire transaction not only incurs technical costs but also wastes medical resources and threatens patient safety.

[0007] Therefore, there is an urgent need for a method that can effectively solve the above problems. Summary of the Invention

[0008] This application provides a distributed transaction consistency guarantee method and server for medical information integration, which can effectively reduce the risk of medical accidents caused by transaction rollback.

[0009] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0010] Firstly, a distributed transaction consistency guarantee method for medical information integration is provided, applied to a server. This method includes:

[0011] In response to a global transaction request received from the business initiator, obtain the business operation identifier;

[0012] Based on the business operation identifier, the multiple distributed medical service participants participating in the global transaction are parsed and identified in the preset participant configuration file, and a globally unique transaction ID is generated for the global transaction.

[0013] Key business status parameters are extracted from global transaction requests and pre-configured business rules. The key business status parameters are then combined and cryptographically hashed according to the business operation identifier to construct an instantaneous state vector, which is used to represent the current transaction execution conditions.

[0014] Generate a transaction pre-inspection request containing a globally unique transaction ID and a transient state vector, and distribute the transaction pre-inspection request in parallel to all distributed healthcare service participants. Each distributed healthcare service participant is used to verify the executability of the transaction pre-inspection request during the pre-inspection phase and generate a pre-inspection response.

[0015] Aggregate all pre-inspection responses returned from the participants in the distributed healthcare service, and if all pre-inspection responses are successful, use the transient state vector as the lock identifier to acquire an exclusive lock in the distributed lock service;

[0016] A final execution instruction is issued to all participants in the distributed healthcare service to commit local transactions. The final execution instruction is used to instruct each participant in the distributed healthcare service to convert the temporary state of the pre-inspection phase into a persistent state and release the local resource lock.

[0017] In one possible implementation of the first aspect, based on the business operation identifier, multiple distributed healthcare service participants participating in the global transaction are parsed and determined from a pre-defined participant configuration file, including:

[0018] Parse the business operation identifier to obtain the combination of business type and operation type;

[0019] The corresponding service mapping table is retrieved from the participant's configuration file based on a combination of business type and operation type.

[0020] Extract the list of participating services from the service mapping table;

[0021] The list of participating service providers determines the multiple distributed healthcare service participants involved in the global transaction.

[0022] In another possible implementation of the first aspect, key business state parameters are combined and cryptographically hashed based on business operation identifiers to construct an instantaneous state vector, including:

[0023] Retrieve the business rule corresponding to the business operation identifier from the pre-configured business rule base;

[0024] The key parameter definitions affecting transaction execution are obtained by parsing the business rules;

[0025] Based on the definition of key parameters, the parameter key names are extracted and sorted according to preset priority to obtain a list of key names;

[0026] Extract the values ​​corresponding to the list of keys from the global transaction request to obtain a set of key-value pairs;

[0027] Sort and concatenate the key-value pair collection to obtain a string;

[0028] Concatenate the string with the globally unique transaction ID to obtain the combined string;

[0029] The combined string is hashed using the SHA-256 hash algorithm to obtain the initial hash value.

[0030] Append the current timestamp to the initial hash value and perform a second hash operation to obtain a time-sensitive hash value;

[0031] The time-sensitive hash value is Base64 encoded to obtain the encoded hash value, and the encoded hash value is used as the instantaneous state vector.

[0032] In another possible implementation of the first aspect, each distributed healthcare service participant is used to perform executability verification on the transaction pre-screening request during the pre-screening phase and generate a pre-screening response, including:

[0033] For each distributed healthcare service parameter, during the pre-inspection phase, the transaction pre-inspection request is received and parsed to obtain a globally unique transaction ID and an instantaneous state vector.

[0034] Check the local transaction log based on the globally unique transaction ID to confirm whether there are duplicate transaction requests.

[0035] Based on the instantaneous state vector, verify whether the current local data state meets the preconditions for transaction execution;

[0036] Check the availability of local resources to confirm whether the transaction operation can be completed. Local resources include database connections, memory space, and computing resources.

[0037] If there are no duplicate transaction requests, the current local data state meets the preconditions for transaction execution, and the transaction operation can be completed, reserve local resources and generate a preflight response containing a success flag; otherwise, generate a preflight response containing the reason for failure.

[0038] In another possible implementation of the first aspect, based on the instantaneous state vector, it is verified whether the current local data state meets the preconditions for transaction execution, including:

[0039] Analyze the instantaneous state vector to obtain key business state parameters;

[0040] Based on the key business status parameters, the current status of the corresponding data record can be retrieved from the local data storage.

[0041] Compare the current status with the key business status parameters to determine if the data version is consistent, and verify whether the local data record is locked by other transactions;

[0042] If the data version is consistent and it is not locked by other transactions, determine that the current local data state meets the preconditions for transaction execution.

[0043] In another possible implementation of the first aspect, under the condition that all preflight responses are successful, an exclusive lock is acquired in the distributed lock service using a transient state vector as the lock identifier, including:

[0044] If all preflight responses are successful, create a lock request that includes the transient state vector.

[0045] The lock request is sent to the distributed lock service, which uses the transient state vector as the lock path and creates a temporary sequence node.

[0046] Determine whether the temporary sequential node is the node with the smallest sequence number;

[0047] If the temporary sequence node is the smallest sequence number node, then an exclusive lock is acquired in the distributed lock service.

[0048] In another possible implementation of the first aspect, the method also includes:

[0049] Based on the global transaction request, obtain the estimated execution time, and calculate the basic timeout duration based on the estimated execution time;

[0050] Based on the preset average execution time, the base timeout duration is adjusted to obtain the adjusted timeout duration;

[0051] Obtain the current network latency, and further adjust the corrected timeout duration based on the current network latency to obtain the final duration;

[0052] Set the final duration as the timeout for the exclusive lock and start a timeout monitoring thread to release the exclusive lock before the final duration is reached.

[0053] In another possible implementation of the first aspect, the method further includes:

[0054] If any participant in the distributed healthcare service fails the pre-check or fails to acquire an exclusive lock, a transaction cancellation instruction is issued to all participants in the distributed healthcare service to release the reserved resources and the acquired locks. The reserved resources are the database connections, memory caches and temporary storage space locked by each participant during the pre-check phase. The acquired locks refer to the exclusive locks created in the distributed lock service based on the transient state vector.

[0055] In another possible implementation of the first aspect, both the final execution instruction and the transaction cancellation instruction contain a globally unique transaction ID.

[0056] Secondly, this application provides a server, comprising:

[0057] The memory is configured to store instructions; and

[0058] The processor is configured to retrieve instructions from memory and, when executing instructions, implement the aforementioned distributed transaction consistency guarantee method for medical information integration.

[0059] The above technical solutions, by introducing a pre-inspection verification mechanism and instantaneous state vector technology, significantly improve the reliability and efficiency of distributed transaction processing in medical scenarios. By pre-emptively verifying consistency, the executability of all participants is verified during the pre-inspection phase before the actual execution of the transaction, fundamentally solving the time lag problem of post-event conflict detection and rollback in the traditional TCC model. This pre-inspection mechanism can quickly identify potential state conflicts within the golden time window of medical operations, avoiding transaction rollbacks due to resource conflicts during critical medical processes such as surgery and emergency care, and significantly reducing the risk of medical accidents. Secondly, by combining and cryptographically hashing key business state parameters, an efficient state snapshot mechanism is created, which can accurately capture dynamically changing business states in the medical system, such as drug inventory, blood reserves, equipment status, and personnel scheduling, and perform state consistency verification among all participants. The distributed lock mechanism based on instantaneous state vectors achieves more refined resource control. Compared with traditional global locking methods, it can perform differentiated locking based on specific business state characteristics, improving the system's concurrent processing capabilities and enabling multiple non-conflicting medical transactions to proceed simultaneously, effectively improving the utilization efficiency of medical resources. Furthermore, the parallel distribution of pre-detection requests significantly shortens transaction preparation time and maximizes processing speed while ensuring consistency, which is particularly important for time-sensitive medical operations. By converting temporary states to persistent states, strong consistency is maintained even in medical environments with high-frequency state changes, effectively preventing data inconsistencies caused by network latency, system failures, and other factors, thus providing a solid technical guarantee for the reliable operation of medical information systems.

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

[0061] Figure 1 A flowchart illustrating a distributed transaction consistency guarantee method for medical information integration provided in this application embodiment;

[0062] Figure 2 An overall architecture diagram of a distributed transaction consistency guarantee method for medical information integration provided in this application embodiment;

[0063] Figure 3 This is a schematic diagram of a distributed lock mechanism based on instantaneous state vectors, provided as an embodiment of this application. Detailed Implementation

[0064] 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.

[0065] 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.

[0066] 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.

[0067] Figure 1 The illustration shows a flowchart of a distributed transaction consistency guarantee method for medical information integration according to an embodiment of this application. Figure 1 As shown in the figure, this application provides a distributed transaction consistency guarantee method for medical information integration, applied to a server, and the method may include the following steps.

[0068] S110. In response to the global transaction request received from the business initiator, obtain the business operation identifier;

[0069] S120. Based on the business operation identifier, parse and determine the multiple distributed medical service participants participating in the global transaction in the preset participant configuration file, and generate a globally unique transaction ID for the global transaction.

[0070] S130. Extract key business status parameters from global transaction requests and pre-configured business rules, and combine and perform encrypted hash operations on the key business status parameters according to the business operation identifier to construct an instantaneous state vector, wherein the instantaneous state vector is used to represent the current transaction execution conditions.

[0071] S140. Generate a transaction pre-inspection request containing a globally unique transaction ID and an instantaneous state vector, and distribute the transaction pre-inspection request in parallel to all distributed healthcare service participants. Each distributed healthcare service participant is used to perform executability verification on the transaction pre-inspection request during the pre-inspection phase and generate a pre-inspection response.

[0072] S150. Summarize all pre-inspection responses returned from the participants in the distributed healthcare service, and if all pre-inspection responses are successful, use the transient state vector as the lock identifier to acquire an exclusive lock in the distributed lock service.

[0073] S160. Issue a final execution instruction to all participants in the distributed healthcare service to commit local transactions. The final execution instruction is used to instruct each participant in the distributed healthcare service to convert the temporary state of the pre-inspection phase into a persistent state and release the local resource lock.

[0074] like Figure 2 As shown, in actual implementation, the server first establishes a listening mechanism to receive global transaction requests from various business initiators. Business initiators can include various front-end applications of the hospital, such as outpatient registration apps, inpatient management terminals, surgical scheduling interfaces, and emergency management platforms. When any business initiator needs to perform a complex cross-system medical business operation, it sends a global transaction request to the server. This request is encapsulated in a standardized data format (such as JSON or XML) and contains basic request information such as the request timestamp, initiator identifier, patient information, and operation type.

[0075] The server extracts the business operation identifier by parsing the structure and content of the received global transaction request. The business operation identifier typically uses a hierarchical encoding structure; for example, "SURGERY_PREP_001" represents operation number 001 of the surgical preparation type. During extraction, the server first verifies the completeness and validity of the request format, ensuring the presence of necessary fields. Then, it accurately identifies and extracts the business operation identifier from the request payload using a field mapping table or regular expression matching. This identifier extraction mechanism not only ensures the accuracy of subsequent processing but also provides a unified identification standard for different types of medical services, effectively supporting the standardized management of complex business processes in medical information systems.

[0076] Based on the extracted business operation identifiers, the server parses and processes them in the pre-configured participant configuration files. These participant configuration files are stored in a hierarchical tree structure, containing service mapping relationships corresponding to different business types. For example, for surgical preparation operations like "SURGERY_PREP_001" mentioned above, the configuration file predefines the distributed medical services that need to be participated in, including surgical scheduling services, anesthesia management services, drug inventory services, blood bank management services, and billing services.

[0077] The server first parses the structure of the business operation identifier, separating the business type (e.g., SURGERY_PREP) and the specific operation type (e.g., 001). Then, it performs a hierarchical search and matching in the configuration file. The search process uses a combination of prefix matching and exact matching to ensure accurate location of the corresponding service mapping table. Once a matching mapping relationship is found, the server extracts the list of participating services, obtaining detailed information on all distributed healthcare service participants that need to participate in this global transaction, including service name, network address, interface protocol, authentication method, etc. Simultaneously, the server uses the UUID (Universally Unique Identifier) ​​algorithm combined with the current timestamp and server identifier to generate a globally unique transaction ID, in the format "TXN_20250729_223045_SRV001_UUID", ensuring the uniqueness and traceability of this transaction throughout the distributed healthcare system. This participant determination and transaction ID generation mechanism provides a clear scope of participants and a unique identification basis for subsequent distributed transaction coordination.

[0078] The specific implementation process for constructing the instantaneous state vector is as follows: First, the server extracts basic business data from the global transaction request, and then, in conjunction with a pre-configured business rule base, identifies key business state parameters affecting the execution of the current transaction. For surgical preparation transactions, key parameters may include patient ID, surgical type, required drug specifications and quantity, blood type and blood volume, operating room number, surgeon ID, anesthesiologist ID, etc. Next, the server determines parameter combination rules based on the business operation identifier, sorts these key parameters according to a preset priority, and forms an ordered set of key-value pairs. The parameter combination process uses a fixed concatenation format, such as "PatientID:P001|SurgeryType:ST003|DrugCode:D123|BloodType: B+|Amount:500ml". Subsequently, the server concatenates the combined parameter string with the globally unique transaction ID to form a combined string.

[0079] The cryptographic hash operation employs a double hashing mechanism to enhance security and uniqueness: First, the combined string is hashed using the SHA-256 algorithm to obtain an initial 256-bit hash value; then, a timestamp accurate to milliseconds is appended to the initial hash value, and a second SHA-256 hash operation is performed to generate a time-sensitive hash value; finally, this hash value is Base64 encoded to obtain the final instantaneous state vector. This instantaneous state vector accurately reflects the combined characteristics of all critical business states at the moment of the current transaction execution. Even a slight change in any parameter will result in a completely different vector value, thus ensuring high accuracy and high sensitivity in state detection.

[0080] The generation and distribution of transaction preflight requests are crucial steps in implementing transaction pre-verification. The server first constructs a standardized transaction preflight request data packet, which contains core information such as a globally unique transaction ID, transient state vector, business operation type, expected execution parameters, and timeout settings. The data packet is encapsulated in a lightweight format to ensure efficient network transmission.

[0081] During the distribution phase, the server employs a parallel processing mechanism, simultaneously sending pre-screening requests to all identified distributed healthcare service participants. Parallel distribution is achieved through multi-threading, with each participant allocated an independent communication thread, avoiding the accumulated time delays that might occur with serial processing. Upon receiving a pre-screening request, each distributed healthcare service participant immediately initiates its local executability verification process. This verification process includes checks across multiple dimensions: first, verifying the uniqueness of the transaction ID to ensure no duplicate transactions occur; then, parsing the instantaneous state vector to obtain key business state parameters, comparing them with local real-time data to confirm data version consistency; next, checking the availability of local resources, including database connection pool status, memory usage, and processing capacity load; and finally, evaluating the executability of the business logic, such as whether drug inventory is sufficient, blood reserves meet demand, and equipment availability. If all checks pass, the participant reserves relevant resources and generates a pre-screening response containing a success flag; if any check fails, a pre-screening response containing detailed reasons for the failure is generated. This pre-inspection and verification mechanism effectively avoids the predicament of discovering problems only halfway through the execution of traditional solutions, significantly advancing the discovery of potential conflicts and providing important protection for the safe execution of medical services.

[0082] Preflight response aggregation and distributed lock acquisition are used to ensure transaction consistency. The server has a dedicated response collector to aggregate preflight response results from all participants. The collection process uses an asynchronous waiting mechanism with a reasonable timeout threshold (typically 5-10 seconds, adjusted according to the urgency of the medical process) to ensure all responses are obtained within a limited time. The response aggregation algorithm checks the response status of each participant one by one; the transaction can only proceed to the next phase when all participants' preflight responses are marked as successful. Once all preflight responses are confirmed to be successful, the server immediately initiates the distributed lock acquisition process.

[0083] Figure 3 This illustration shows a schematic diagram of a distributed lock mechanism based on instantaneous state vectors provided in an embodiment of this application. Figure 3The diagram illustrates a distributed lock service and two concurrent transaction scenarios. Scenario 1: State conflict. Transaction A (handling resource reservation for surgery ST003) generates a transient state vector V1. Transaction A requests the distributed lock service to create a temporary node on the path / locks / V1 and successfully acquires the lock. Almost simultaneously, transaction B (also handling the same resource reservation for surgery ST003) generates the exact same transient state vector V1. Transaction B attempts to acquire the lock on the path / locks / V1, but fails because the lock is already held by transaction A (or enters the waiting queue). This mechanism effectively prevents concurrent modifications to the same business state, ensuring data consistency. Scenario 2: No state conflict. Transaction A still holds the lock on the path / locks / V1. At this time, transaction C (handling a completely different business, such as billing medication for another patient P002) generates a completely different transient state vector V2. Transaction C requests the distributed lock service to create a temporary node on the path / locks / V2. Because the paths / locks / V2 and / locks / V1 are different, transaction C successfully acquired the lock and can execute concurrently with transaction A. This mechanism achieves fine-grained locking, ensuring mutual exclusion only when business states truly conflict, greatly improving the system's concurrency capabilities and resource utilization. Distributed lock services are typically implemented based on mature distributed coordination services such as Zookeeper or etcd, offering high availability and strong consistency guarantees. During lock acquisition, the server uses a transient state vector as the unique identifier for the lock. This design ensures that transactions with the same state characteristics will compete for the same lock, while transactions with different states can execute in parallel, significantly improving concurrency capabilities. The lock service creates temporary sequential nodes with the transient state vector as the path, determining the lock acquisition status by checking if the current node is the smallest sequence number node. If an exclusive lock is successfully acquired, it means that the current transaction has exclusive execution rights in operations of the same state; if acquisition fails, it indicates that concurrent transactions with conflicting states are executing, requiring waiting or cancellation. This state vector-based fine-grained locking mechanism not only ensures the mutual exclusion of transactions but also maximizes the concurrent processing performance of the system, making it particularly suitable for the diverse and high-frequency business operation needs in the medical environment.

[0084] The final execution instruction and local transaction commit are the final stages of the entire distributed transaction process and the key steps in transforming the preparatory work of the pre-inspection phase into actual business results. After successfully acquiring the exclusive lock, the server immediately constructs the final execution instruction and broadcasts it to all participants. The final execution instruction contains complete information such as a globally unique transaction ID, confirmed business operation parameters, execution time window, and rollback contingency plan. Instruction transmission employs a reliable message passing mechanism to ensure that each participant receives the execution notification, and a retry mechanism and exception handling process are implemented for transmission failures.

[0085] Upon receiving the final execution instruction, each participant in the distributed healthcare service immediately initiates the formal commit process for its local transactions. This process involves converting temporary states locked during the pre-inspection phase into persistent states, such as converting drug reservations into formal issuance, blood reservations into actual allocation, and equipment reservations into formal occupancy. State transitions employ atomic operations, ensuring either complete success or complete failure, with no intermediate states. Simultaneously, participants release local resource locks acquired during the pre-inspection phase, including database row locks, memory cache locks, and file system locks, making these resources available for other transaction requests. The entire commit process also includes recording local transaction logs, detailing the transaction's execution time, operation content, and affected data, providing comprehensive data support for subsequent auditing, traceability, and fault recovery. This design not only ensures strong consistency of distributed transactions but also provides technical guarantees for the traceability and compliance requirements of healthcare services.

[0086] In this embodiment, the introduction of a pre-verification mechanism alters the traditional transaction processing timeline, moving consistency checks from mid-transaction execution to before transaction initiation. This effectively addresses the core pain points of short transaction validity windows and frequent state changes in medical scenarios. This pre-verification avoids transaction rollbacks due to resource conflicts during critical medical processes such as surgery and emergency care, significantly reducing the risk of medical accidents. Instantaneous state vector technology accurately captures dynamically changing business states in the medical system, such as drug inventory, blood reserves, equipment status, and personnel scheduling, using a cryptographic hash algorithm. This creates an efficient state snapshot mechanism, ensuring strong consistency verification of state information among all participants. The state vector-based distributed lock mechanism achieves refined resource control. Compared to traditional global locking methods, it can perform differentiated locking based on specific business state characteristics, significantly improving the system's concurrent processing capabilities. This allows multiple non-conflicting medical transactions to execute simultaneously, effectively improving the efficiency of medical resource utilization. Furthermore, the parallel distribution of pre-verification requests and the atomic state transition mechanism significantly shorten transaction preparation and commit time, maximizing processing speed while ensuring strong consistency, making it particularly suitable for time-sensitive medical business needs. This solution not only provides a solid technical guarantee for the reliable operation of medical information systems, but also makes significant contributions to improving the quality of medical services and protecting patient safety.

[0087] In one embodiment of this example, based on the business operation identifier, multiple distributed healthcare service participants participating in the global transaction are parsed and determined from a preset participant configuration file, including the following steps:

[0088] S210. Parse the business operation identifier to obtain the combination of business type and operation type;

[0089] S220. Retrieve the corresponding service mapping table from the participant's configuration file based on the combination of business type and operation type;

[0090] S230. Extract the list of participating service providers from the service mapping table;

[0091] S240. Determine multiple distributed healthcare service participants participating in the global transaction based on the participant service list.

[0092] In medical information integration systems, business operation identifiers adopt a hierarchical coding structure, typically following the format "business type_operation type_serial number". For example, "SURGERY_PREP_001" represents operation number 001 of the surgical preparation type. The parsing process uses a string splitting algorithm, employing underscores as delimiters to break down the complete business operation identifier into independent components.

[0093] In practice, the parser uses regular expression matching technology with the pattern "([A-Z_]+)_([A-Z_]+)_(\d+)", where the first capture group represents the business type, the second capture group represents the operation type, and the third capture group represents the sequence number. For the identifier "SURGERY_PREP_001" above, after parsing, the business type is "SURGERY", the operation type is "PREP", and the sequence number is "001". Then, the business type and operation type are combined to form the type combination identifier "SURGERY_PREP". This combination method ensures accurate classification of medical services, enabling accurate identification of different types of medical services such as surgical preparation, emergency resuscitation, outpatient treatment, and inpatient management.

[0094] The parsing process also includes a validity verification mechanism, checking whether the identifier format conforms to predefined specifications. Identifiers that do not meet the format requirements will trigger an exception handling process. This structured parsing method not only ensures the accuracy of business classification but also provides standardized input parameters for subsequent service mapping lookups, effectively improving the reliability and efficiency of the entire participant determination process.

[0095] The participant configuration files are stored in a hierarchical XML or JSON format, with an internal structure organized according to a dual index of business type and operation type. The top-level structure of the configuration file contains multiple business domains, such as surgical, emergency, and outpatient domains, each further subdivided into specific operation type branches. The retrieval process uses the combination of business type and operation type obtained from the preceding steps to perform hierarchical navigation within the configuration file.

[0096] In practice, the retrieval algorithm employs a tree-based traversal strategy, starting from the root node, locating the corresponding business type node, and then searching for matching operation type child nodes under that node. For example, for the combination "SURGERY_PREP", the retrieval algorithm locates the "SURGERY" business domain and then searches for the "PREP" operation branch under that domain. To improve retrieval efficiency, the configuration file uses a hash table structure for memory caching, preloading commonly used business types and operation type combinations into memory, reducing the retrieval time complexity to O(1).

[0097] The retrieval process also includes a fault-tolerance mechanism. When an exact match fails, a fuzzy matching strategy is activated, using an edit distance algorithm to find the most similar configuration item. Furthermore, the configuration file supports a dynamic update mechanism, allowing for real-time updates without restarting the entire service when new medical service types or operation types are introduced. Upon successful retrieval, a reference to the corresponding service mapping table is returned. This table contains all the distributed service information required to process a specific medical service, laying the foundation for the next step of service list extraction.

[0098] The service mapping table is stored in a structured data format. Each entry contains detailed information such as service name, service address, service interface, priority, load weight, and health check configuration. The extraction process verifies the integrity of the mapping table to ensure that all necessary service items exist and are configured correctly. For surgical preparation-related services, a typical service mapping table includes services such as surgical scheduling, anesthesia management, drug inventory, blood bank management, equipment management, and billing.

[0099] The extraction algorithm iterates through each service item in the mapping table, filtering based on the service's activation status, priority settings, and current availability. In practice, a multi-dimensional evaluation mechanism is employed: checking the basic availability of the service by verifying its online status through heartbeat detection or health check interfaces; assessing the service's load status to avoid selecting overloaded service instances; and considering the service's business priority to ensure that critical services are selected first.

[0100] The extraction process also supports a service substitution mechanism. When the primary service becomes unavailable, a backup service or a similar alternative service is automatically selected. The extraction results form an ordered list of participating services, sorted by execution priority, dependencies, and concurrency compatibility, providing an optimized execution sequence for subsequent parallel transaction processing. This intelligent service extraction mechanism not only ensures the integrity of medical business processing but also provides good fault tolerance and scalability.

[0101] After obtaining the list of participating services, further verification, optimization, and confirmation are required. The process involves real-time status checks on each service in the list, including network connectivity testing, service responsiveness verification, and resource availability assessment. A parallel checking mechanism is employed, simultaneously sending lightweight status query requests to all candidate services. These requests contain basic service identifiers and timestamp information, with response times typically kept below 100 milliseconds. Services with normal responses are marked as available; services that time out or return errors are marked as unavailable and removed from the candidate list.

[0102] Next, service dependency analysis is performed. Strong dependencies exist between services in certain healthcare operations; for example, the drug management service depends on the inventory query service, and the blood bank management service depends on the blood matching service. The analysis process constructs a service dependency graph and uses a topology sorting algorithm to ensure that dependent services participate in transactions in the correct order. Then, load balancing optimization is performed. When multiple instances of the same type of service are available, the optimal instance is selected based on factors such as current load, historical performance data, and geographical location.

[0103] The final list of participants includes not only basic service information but also execution parameters such as role definition, execution weight, timeout settings, and retry policies for each service. The results are persistently stored for subsequent transaction execution tracking and auditing. This multi-layered verification and optimization mechanism ensures that all healthcare services participating in distributed transactions have the necessary execution conditions and performance guarantees, laying a solid foundation for the reliable execution of healthcare services.

[0104] In this embodiment, the structured business operation identifier parsing provides a unified classification standard for different types of medical services, enabling accurate identification and processing of various medical scenarios such as surgery, emergency, outpatient, and inpatient care. This effectively solves the problems of ambiguous business types and inaccurate participant selection in traditional methods. The hierarchical retrieval mechanism based on business type combinations significantly improves the search efficiency of service mapping. Through optimization strategies such as hash caching and tree traversal, the retrieval time is optimized from the traditional linear search O(n) to a constant level O(1), greatly improving the response speed of transaction initiation. The multi-dimensional service extraction mechanism not only considers the functional matching of services but also comprehensively evaluates key factors such as availability, load status, and priority, ensuring that all services participating in the transaction have the best execution conditions and effectively avoiding transaction failures caused by improper service selection. The real-time status check and dependency analysis mechanism provides important guarantees for the reliable execution of distributed medical transactions. Through parallel verification and intelligent optimization, it ensures the service quality and execution efficiency of the participants. The entire participant determination process not only improves the automation level of the medical information system but also enhances the system's fault tolerance and scalability. When new healthcare services or business types are introduced, seamless integration is achieved simply by updating the configuration file, without requiring modifications to the core processing logic. This design provides strong technical support for the informatization and digital transformation of healthcare institutions, effectively promoting the improvement of healthcare service quality and the optimal allocation of healthcare resources.

[0105] In one embodiment of this invention, key business state parameters are combined and cryptographically hashed based on business operation identifiers to construct an instantaneous state vector, including the following steps:

[0106] S310. Retrieve the business rule corresponding to the business operation identifier from the pre-configured business rule base;

[0107] S320. Parse the key parameter definitions that affect transaction execution from the business rules;

[0108] S330. Based on the definition of key parameters, extract the parameter key names and sort them according to preset priority to obtain a list of key names;

[0109] S340. Extract the values ​​corresponding to the key name list from the global transaction request to obtain a set of key-value pairs;

[0110] S350. Sort and concatenate the key-value pair set to obtain a string;

[0111] S360. Concatenate the string with the globally unique transaction ID to obtain the combined string;

[0112] S370. Perform the first hash operation on the combined string using the SHA-256 hash algorithm to obtain the initial hash value;

[0113] S380. Append the current timestamp to the initial hash value and perform a second hash operation to obtain a time-sensitive hash value;

[0114] S390. Encode the time-sensitive hash value using Base64 to obtain the encoded hash value, and use the encoded hash value as the instantaneous state vector.

[0115] When retrieving business rules corresponding to business operation identifiers from the pre-configured business rule base, the business rule base adopts a hierarchical storage architecture, comprising three main components: a rule definition layer, a rule index layer, and a rule cache layer. The rule definition layer stores detailed rule configurations for various medical services in XML or JSON format. Each rule item contains complete information such as the applicable business operation identifier, key parameter definitions, constraints, priority settings, and validity period. The rule index layer establishes a fast mapping relationship from business operation identifiers to specific rules, using a B+ tree index structure to achieve fast lookups with O(log n) time complexity.

[0116] In practice, the retrieval process standardizes the input business operation identifiers, removing extra spaces, converting case, and validating formatting. Then, it performs exact matching in the rule index. The retrieval tool uses a prefix matching strategy, supporting hierarchical matching from specific to general. For example, for the identifier "SURGERY_PREP_001", it first attempts an exact match; if not found, it then attempts to match "SURGERY_PREP_ "Wildcard rules, finally trying to match "SURGERY_" "General rules."

[0117] The retrieval process also includes rule validity verification to ensure that the returned rules are valid at the current time and have not been marked as obsolete. To improve retrieval performance, the rule caching layer uses an LRU (Least Recently Used) strategy to cache frequently used rules, reducing the retrieval time for commonly used rules to the millisecond level. The retrieval results contain complete business rule objects, which not only define the key parameters affecting transaction execution but also contain important information such as dependencies between parameters, constraints, and processing priorities, providing comprehensive guidance for subsequent parameter parsing.

[0118] The business rules employ a structured parameter definition format. Each parameter definition includes multi-dimensional attribute information such as parameter name, data type, value range, importance level, dependencies, and change sensitivity. The parsing process performs syntactic analysis on the business rules, identifies all parameter definition blocks, and then parses the detailed attributes of each parameter one by one. For business rules related to surgical preparation, typical key parameters include basic patient information, surgical-related parameters, resource requirement parameters, and personnel configuration parameters.

[0119] The parsing algorithm employs recursive descent analysis, enabling it to handle nested parameter definitions and complex constraint expressions. In practice, the parser categorizes parameters based on their importance, classifying them into three levels: core parameters, important parameters, and auxiliary parameters. Core parameters are key factors directly affecting transaction executability, such as patient ID and surgery type; important parameters are significant factors influencing transaction execution performance, such as surgery duration and resource requirements; auxiliary parameters provide additional information but do not directly affect execution, such as notes and historical records.

[0120] The parsing process also identifies dependencies between parameters and constructs a parameter dependency graph to ensure that the relationships between parameters can be correctly handled in subsequent processing. The parsing results form a structured set of parameter definitions. Each parameter definition not only contains basic name and type information, but also technical parameters such as weight coefficients, hash seeds, and encoding methods used for state vector construction, providing complete metadata support for accurate state representation.

[0121] The parameter key extraction process iterates through the parameter definition set obtained in the preceding steps, extracting standardized key identifiers from each parameter definition. Key standardization adopts a unified naming convention, typically following the format "domain_category_attribute", such as "patient_basic_id". The extraction process also includes a key validation mechanism to ensure that all key names conform to the predefined naming conventions; key names that do not conform to the conventions are automatically corrected or marked as abnormal.

[0122] The sorting process is based on a multi-level priority strategy, sorting parameters according to their importance level, with core parameters having the highest priority, important parameters second, and auxiliary parameters the lowest. Within the same importance level, a second-level sort is performed according to the sensitivity to changes, with parameters that are more sensitive to changes ranked first. Finally, a third-level sort is performed according to the lexicographical order of the parameter names to ensure the stability and reproducibility of the sorting results.

[0123] In practice, the sorting algorithm employs a stable multi-key sorting technique to ensure that parameters with the same priority maintain the same relative position in multiple sorts. The sorting process also considers the business semantics of the parameters; for example, patient identity information typically has a higher priority than auxiliary information, and resource requirement information is more important than historical data. The sorting result forms an ordered list of keys, the order of which directly affects the generation of subsequent state vectors. Fixed sorting rules ensure consistency in state vectors generated for the same business state at different times, which is crucial for state comparison and conflict detection in a distributed environment.

[0124] Global transaction requests are typically encapsulated in structured data formats such as JSON, XML, or Protocol Buffers, containing all the parameter information required to perform specific medical tasks. The extraction process performs format validation and integrity checks on the global transaction request to ensure that the requested data is structurally correct and contains all required fields. Then, based on the key name list obtained in the previous steps, the corresponding data value is searched one by one in the transaction request.

[0125] The search process employs a multi-level matching strategy, attempting exact key matching, and if no match is found, then trying synonym matching and fuzzy matching. For example, for the key "patient_basic_id", if the field is not found in the request, it will try to find possible synonym fields such as "patientId", "patient_identifier", and "pid". The extraction process also includes data type conversion and format standardization to ensure that all extracted values ​​conform to predefined data format requirements. For numeric parameters, precision standardization is performed; for string parameters, case normalization and special character handling are performed; and for date and time parameters, they are converted to a uniform time format.

[0126] During the extraction process, if any missing required parameters are found, default values ​​will be filled in or an exception handling process will be triggered according to business rules. After extraction, a complete set of key-value pairs is formed. Each key-value pair contains a standardized key name and a corresponding data value. These key-value pairs are organized in the order of the key name list to ensure the consistency and predictability of subsequent processing.

[0127] As described in detail in step S130 above, the process of sorting and concatenating the key-value pair set adopts a fixed concatenation format. Each key-value pair is formatted as "key:value" according to the order of the key name list, and then connected using the pipe symbol "|" to form a standardized parameter string, ensuring that the same business state can generate a consistent string representation. The process of concatenating the parameter string with a globally unique transaction ID involves adding the transaction ID to the end of the parameter string to form a combined string containing business state information and a transaction identifier, providing complete input data for subsequent hash operations. The process of performing the first hash operation on the combined string using the SHA-256 hash algorithm converts the variable-length combined string into a fixed-length 256-bit hash value using the standard SHA-256 algorithm, ensuring the uniqueness and irreversibility of the state representation.

[0128] As described in detail in step S130 above, appending a timestamp accurate to milliseconds to the initial hash value and performing a second SHA-256 hash operation generates a time-sensitive hash value, effectively preventing replay attacks and enhancing the timeliness of the state vector. Furthermore, the Base64 encoding of the time-sensitive hash value converts the binary hash value into a readable string format, generating the final instantaneous state vector. This vector has good transmission and storage properties, making it suitable for state comparison and verification in a distributed environment.

[0129] In this embodiment, an intelligent retrieval and parsing mechanism based on a business rule base provides personalized parameter identification strategies for different types of medical services, ensuring that the state vector accurately reflects the key state characteristics of various medical scenarios and effectively solving the problems of inaccurate and incomplete state representation in traditional solutions. Structured parameter extraction and standardized processing ensure the consistency and integrity of state data. Through multi-level verification and conversion mechanisms, it ensures that business data from different systems and formats can be uniformly processed and represented. Priority-based parameter sorting and fixed-format string concatenation mechanisms ensure the reproducibility of state vector generation; the same business state can generate the same intermediate representation at any time, providing a reliable foundation for state consistency checks in a distributed environment. Double hash encryption and timestamp mechanisms not only guarantee the uniqueness and unforgeability of state vectors but also add time-sensitive features, effectively preventing the misuse of expired states and malicious replay attacks. The entire instantaneous state vector construction process is highly automated and intelligent, adaptable to the complexity and dynamism of medical services, and provides accurate state awareness capabilities for distributed transaction processing in medical information systems. This technical solution not only improves the accuracy and reliability of medical business processing, but also provides strong technical support for the secure transmission and consistency of medical data, which is of great significance for promoting the in-depth development of medical informatization and ensuring the high-quality operation of medical services.

[0130] In one embodiment of this example, each distributed healthcare service participant is used to perform executability verification on the transaction pre-inspection request during the pre-inspection phase and generate a pre-inspection response, including the following steps:

[0131] S410. For each distributed medical service parameter, receive and parse the transaction pre-inspection request during the pre-inspection phase to obtain a globally unique transaction ID and instantaneous state vector.

[0132] S420. Based on the globally unique transaction ID, check the local transaction log to confirm whether there are duplicate transaction requests.

[0133] S430. Based on the instantaneous state vector, verify whether the current local data state meets the preconditions for transaction execution.

[0134] S440. Check the availability of local resources to confirm whether the transaction operation can be completed. Local resources include database connection, memory space, and computing resources.

[0135] S450. If there are no duplicate transaction requests, the current local data status meets the preconditions for transaction execution, and the transaction operation can be completed, reserve local resources and generate a pre-flight response containing a success flag; otherwise, generate a pre-flight response containing the reason for failure.

[0136] When participants in a distributed healthcare service receive and parse transaction preflight requests, each participant deploys a dedicated preflight request listening service. This service employs a multi-threaded asynchronous processing model, capable of handling concurrent requests from multiple transaction coordinators simultaneously. The listening service is implemented using either a long TCP connection or HTTP / 2 protocol, ensuring reliable network communication and low latency. Upon receiving a transaction preflight request, each participant performs message format verification to confirm the integrity and validity of the requested data.

[0137] The parsing process employs streaming parsing technology to avoid memory overflow issues caused by large data volume requests. Specifically, the parser extracts key information from the request field by field according to predefined message format specifications. The globally unique transaction ID is extracted by looking up a fixed message header field; after extraction, format verification is performed to ensure the ID conforms to the UUID standard format requirements. Extracting the transient state vector requires processing Base64-encoded hash strings; the parsing process includes encoding verification, length checking, and character validity verification.

[0138] The parsing process also includes a timestamp verification mechanism to ensure that received pre-detection requests are within a valid time window; expired requests are directly rejected. To improve parsing efficiency, participants employ message caching and reuse mechanisms. For request types with the same format, parsing templates are reused to reduce redundant parsing overhead. After parsing, participants generate an internal pre-detection task object containing the extracted global transaction ID, transient state vector, and other relevant execution parameters, providing standardized input data for subsequent verification processes. This efficient receiving and parsing mechanism ensures that the distributed healthcare service can quickly respond to the transaction coordinator's pre-detection requests, providing crucial assurance for the timeliness of the entire distributed transaction.

[0139] The local transaction log employs a high-performance persistent storage system, typically implemented using an LSM-Tree storage engine, supporting high-concurrency read / write operations and fast range queries. The transaction log records complete lifecycle information, including transaction ID, execution status, start time, completion time, and execution result. The inspection process involves searching within the transaction log's primary index, which is built on a B+ tree structure and can complete the search operation in O(log n) time complexity.

[0140] In practice, the checking algorithm not only verifies the existence of the transaction ID but also analyzes the current state of the transaction. If the same transaction ID is already being executed (in a RUNNING state), it indicates a concurrency conflict, and the current request must be rejected. If the historical record corresponding to the transaction ID is in a COMPLETED or FAILED state, it means that the transaction has already been processed, and duplicate execution must also be rejected. The checking process also includes time window verification; even if the transaction ID is not duplicated, it must ensure that there is a sufficient time interval between the current request and similar historical requests to prevent abnormally high-frequency duplicate requests.

[0141] To optimize inspection performance, participants maintain an LRU-based in-memory cache, storing the most recently processed transaction IDs in memory, significantly improving inspection speed in common scenarios. The inspection process also supports cross-instance deduplication in distributed scenarios, preventing duplicate execution in load-balanced environments by sharing transaction state information with other service instances. Inspection results are recorded in the audit log, including inspection time, result status, and related historical information, providing detailed tracking data for subsequent problem diagnosis and system monitoring. This comprehensive duplicate inspection mechanism effectively prevents duplicate operations in medical services, avoiding abnormal situations that could harm patients, such as duplicate medication, duplicate billing, and duplicate inspections.

[0142] The verification process requires parsing the instantaneous state vector and reconstructing the characteristic information of key business state parameters from the Base64-encoded hash value through reverse engineering. Although hash operations are irreversible, participants can determine state consistency through comparative verification. In practice, participants extract the business operation identifiers and parameter features contained in the received instantaneous state vector, and then query the local data storage system to obtain the real-time status of the relevant business data.

[0143] The verification process includes multiple levels of checks: data existence verification, confirming that the core business data required for the transaction (such as patient records, drug information, equipment status, etc.) exists and is accessible in the local system; data version consistency verification, confirming that the local data is consistent with the expected data state in the global transaction request by comparing information such as data version number, modification timestamp, or checksum; and business rule compliance verification, checking whether the current data state meets the preconditions for business execution, such as whether drug inventory is sufficient, whether equipment is available, and whether the patient's condition is appropriate.

[0144] The verification process also includes data lock status checks to confirm that the relevant data records are not locked or occupied by other transactions. To ensure the atomicity of verification, the entire check process is executed under the protection of database transactions to prevent changes in data state during verification. Verification results are categorized into three states: VALID indicates that all preconditions are met, INVALID indicates that some conditions are not met, and UNCERTAIN indicates that the state cannot be determined due to system load or network issues. For INVALID and UNCERTAIN states, the participants generate detailed error reports explaining the specific reasons for failure and suggested handling measures, providing complete status feedback information for the transaction coordinator's decision-making.

[0145] The resource check process employs a multi-layered evaluation strategy, performing basic resource availability checks, including system-level metrics such as CPU utilization, memory usage, disk space usage, and network bandwidth. In practice, the check process obtains real-time resource usage data through system calls. CPU utilization checks ensure the current processor load is below a preset threshold (typically 80%), reserving sufficient computing power for transaction execution. Memory space checks not only confirm sufficient available memory but also assess memory fragmentation and cache hit rate to ensure no memory shortages occur during transaction execution.

[0146] Database connection checks verify key metrics such as the number of available connections in the connection pool, connection health status, and database server response time. The check process creates test connections and executes simple queries to verify the availability and performance of the database service. For resources specific to healthcare operations, such as interfaces to specialized medical equipment, external system connections, and capabilities for handling special data formats, dedicated availability checks are also required.

[0147] Resource checks also include business-level capacity assessments, predicting required resource consumption based on the expected execution complexity and data volume of transactions, and comparing this prediction with currently available resources. The check process employs a dynamic threshold adjustment mechanism, intelligently adjusting resource sufficiency criteria based on historical execution data and current system load. To avoid excessive system load from the resource checks themselves, a sampling and caching mechanism is used: cached data is used for slowly changing resource metrics, while rapidly changing metrics are sampled in real time. Check results are generated in a structured report format, containing detailed information such as the current status, availability, and expected transaction size of various resources, providing a comprehensive resource status assessment for participating parties' pre-check decisions.

[0148] The response generation process summarizes the results of the aforementioned checks, including feedback from all verification stages such as repeatability checks, status verification checks, and resource availability checks. The summarization process uses a logical AND operation; the overall pre-check is only considered successful when all checks return a success status. In practice, if the pre-check succeeds, the participating parties immediately initiate the resource reservation process, a crucial step to ensure the successful execution of subsequent transactions.

[0149] Resource reservation involves multiple layers of operations: at the database level, reservation locks are added to relevant data records to prevent other transactions from modifying this data; at the memory level, cache space and processing buffers required for transaction execution are pre-allocated; at the connection level, database connections are reserved from the connection pool to ensure sufficient connection resources during transaction execution; at the business level, specific medical resources (such as medicines, blood, equipment, etc.) are temporarily reserved to prevent resources from being occupied by other transactions. A reasonable timeout mechanism is set during the reservation process, typically 30-60 seconds, after which the reserved resources are automatically released to avoid long-term resource occupation.

[0150] A successful preflight response includes a success identifier, a list of reserved resources, estimated execution time, and maximum wait time, providing information for the transaction coordinator's subsequent decisions. If any check fails, the participating parties generate a response containing detailed reasons for the failure. This failure information includes the specific error type, error code, error description, suggested solutions, and a retry feasibility assessment. The failure response also includes a snapshot of the current system state, helping the transaction coordinator understand the specific cause of the failure and the current system load. The response generation process also includes formatting and encryption of the response message to ensure the integrity and security of the response data. The generated response is sent to the transaction coordinator via a reliable network channel, with an acknowledgment mechanism to ensure successful delivery of the response message.

[0151] In this embodiment, the standardized request reception and parsing process ensures that different types of medical services can uniformly handle pre-screening requests from the transaction coordinator. Through a high-performance asynchronous processing mechanism, the system's concurrent processing capability and response speed are significantly improved. The transaction log-based duplicate checking mechanism effectively prevents the risk of duplicate operations in medical services, avoiding abnormal situations such as duplicate medication, duplicate examinations, and duplicate billing that could cause harm or economic loss to patients, providing crucial protection for medical safety. The data state verification mechanism based on instantaneous state vectors achieves accurate business state consistency checks, enabling the detection of potential state conflicts before transaction execution, avoiding the predicament of discovering problems midway through transaction execution in traditional solutions, and significantly reducing the risk of medical accidents. Multi-dimensional resource availability checks and intelligent resource reservation mechanisms ensure the reliability and efficiency of transaction execution. Through dynamic resource evaluation and reservation strategies, the system's resource utilization efficiency is maximized while guaranteeing the priority execution of critical medical services. The entire pre-screening verification process not only improves the success rate and execution efficiency of distributed medical transactions but also enhances the system's fault tolerance and adaptability. When faced with high-concurrency medical service requests or complex resource competition, this mechanism can intelligently perform load balancing and resource scheduling to ensure the continuity and availability of critical medical services. This design provides a solid technical foundation for the digital transformation and intelligent upgrading of medical institutions, effectively promoting the improvement of medical service quality and the optimization of medical resource allocation.

[0152] In one embodiment of this invention, verifying whether the current local data state meets the preconditions for transaction execution based on the instantaneous state vector includes the following steps:

[0153] S510. Analyze the instantaneous state vector to obtain the key business state parameters;

[0154] S520. Based on the key business status parameters, query the local data storage to obtain the current status of the corresponding data record;

[0155] S530. Compare the current status with the key business status parameters to determine whether the data version is consistent and verify whether the local data record is locked by other transactions.

[0156] S540. If the data version is consistent and not locked by other transactions, determine that the current local data state meets the preconditions for transaction execution.

[0157] The parsing of transient state vectors reconstructs key business state parameters through pre-stored business rules and parameter mapping relationships. Although the transient state vector is generated through irreversible hash operations, the parsing process can reconstruct key business state parameters using pre-stored business rules and parameter mapping relationships. In practice, the parser decodes the Base64-encoded transient state vector to obtain the original hash byte sequence. Then, by matching it with the locally stored business rule base, the business operation type and parameter structure corresponding to the state vector are determined.

[0158] The parsing process employs pattern matching technology, locating the corresponding parameter definition template in the business rule base based on the generation timestamp of the state vector and business context information. The parameter reconstruction process includes multiple stages such as parameter key name extraction, data type inference, and value range determination. For healthcare business scenarios, typical key business state parameters include core information such as patient identifiers, medical resource requirements, operation time windows, and execution priorities.

[0159] The parsing process also needs to handle the hierarchical structure and dependencies of parameters, and some composite parameters need to be further decomposed into basic parameter items. To ensure the accuracy of parsing, the parser employs a multi-layered verification mechanism, including parameter integrity checks, data type validation, and value range validation. The parsing process also supports vector version compatibility handling, enabling it to process state vectors generated by different versions of business rules. The parsing results are output in the form of structured parameter objects, with each parameter containing complete metadata information such as name, type, value, priority, and validation rules. This intelligent parsing mechanism ensures that even in complex medical business scenarios, all key state parameters affecting transaction execution can be accurately extracted, providing a reliable data foundation for subsequent state verification.

[0160] Local data storage typically employs a multi-tiered storage architecture, including relational databases, caching layers, and indexing services. The query process requires the comprehensive utilization of these storage resources to achieve efficient data retrieval. In practice, the query process constructs query conditions based on key business status parameters, converting these parameters into corresponding SQL statements, NoSQL query expressions, or cached key-value pairs. For patient-related parameters, the query process accesses multiple data sources such as the patient basic information table, medical record table, and current status table; for medical resource-related parameters, it queries specialized data tables such as the equipment status table, drug inventory table, blood reserve table, and personnel scheduling table.

[0161] The query optimizer selects the optimal query path and indexing strategy based on the importance of parameters and query frequency. For frequently accessed critical data, it prioritizes retrieval from the memory cache; for data with high real-time requirements, it directly accesses the main database; and for historical data or statistical information, it can be retrieved from the data warehouse or read-only replicas. The query process employs parallel query technology, allowing query operations to be executed in parallel for independent parameters, improving overall query efficiency.

[0162] The query results include metadata such as the complete content of the data records, version information, last modified time, modifying user, and lock status. To ensure data consistency, the query process is executed under transaction isolation level protection to prevent data from being modified by other transactions during the query. The query process also includes data integrity verification to confirm that the retrieved data records conform to the expected format and constraints. In the event of query failure or missing data, the query process generates a detailed error report, including the reason for the failure, the scope of impact, and suggested handling measures.

[0163] As partially described in step S430 above, the comparison process between the current state and key business state parameters employs a multi-dimensional consistency verification strategy. In practice, the comparison process includes not only precise matching of data content but also verification across multiple dimensions such as data version, timestamp, and checksum. Data version consistency checks confirm that the data has not been modified by other transactions by comparing the version number of the local data record with the expected version number in the state parameters. Version comparison uses a semantic versioning strategy, supporting hierarchical comparison of major version numbers, minor version numbers, and revision version numbers.

[0164] Timestamp verification ensures that the last modification time of local data is within an acceptable time window; outdated data is marked as inconsistent. Lock status verification checks whether related data records are held by other transactions with exclusive or shared locks. Lock checks include verification of lock status at multiple levels, such as row-level locks, table-level locks, and application-level locks. For distributed locks, it is also necessary to verify the distributed consistency and validity of the locks.

[0165] The comparison process also includes business rule compliance verification to confirm that the current data status meets the execution prerequisites of the business logic. For example, for surgical procedures, it is necessary to verify multiple business conditions such as the patient's condition being suitable for surgery, the operating room being available, and medical staff being in place. The comparison results are output in the form of Boolean values ​​and detailed reports, providing an accurate basis for the final judgment of the prerequisites.

[0166] Determining that the current local data state meets the preconditions for transaction execution, assuming data version consistency and no locking by other transactions, is based on a comprehensive evaluation and logical reasoning mechanism. This requires considering the results of the aforementioned checks as well as the specific requirements of business rules. In practice, the decision-making process summarizes the results of the comparative checks in the preceding steps and uses a weighted scoring mechanism to differentiate the importance of different check items. Consistency checks of core business parameters have the highest weight, followed by resource availability checks, while checks of auxiliary parameters have relatively lower weights.

[0167] The decision-making algorithm combines threshold judgment and expert rules, requiring not only that all key checks pass, but also that the overall score reaches a preset safety threshold. The decision-making process also includes a risk assessment phase, analyzing potential risks to executing transactions under the current conditions, such as data contention, resource conflicts, and business logic conflicts. For high-risk situations, even if technical checks pass, the transaction may still be deemed as failing to meet the preconditions.

[0168] The decision-making process supports a multi-level decision-making mechanism, which can trigger manual review or expert system intervention for boundary cases or complex scenarios. The final decision result includes a clear satisfaction / dissatisfaction judgment, detailed decision basis, risk assessment report, implementation recommendations, and other complete information. The decision-making process also generates a decision audit log, recording the time, basis, process, and result of the decision, providing data support for subsequent problem tracing and decision optimization. Through this scientific and systematic decision-making mechanism, it is ensured that distributed medical transactions are only allowed to be executed under the safest and most reliable conditions, maximizing the security and reliability of medical services.

[0169] In this embodiment, intelligent state vector parsing technology overcomes the limitation of the irreversibility of hash operations. Through a business rule base and pattern matching technology, it accurately reconstructs key business state parameters, providing a complete parameter foundation for subsequent verification and effectively solving the technical challenges of state information transmission and parsing in a distributed environment. The multi-dimensional local data query mechanism fully leverages the advantages of modern data storage architecture. Through caching, index optimization, and parallel querying, it achieves millisecond-level fast data retrieval, significantly improving the response speed of state verification and meeting the stringent real-time requirements of medical services. The comprehensive state comparison and locking verification mechanism not only ensures strict consistency of data versions but also effectively prevents resource conflicts between concurrent transactions. Through multi-level lock state checks and business rule verification, it minimizes unexpected risks during transaction execution. The scientific precondition judgment mechanism employs advanced decision support technologies such as weighted scoring, risk assessment, and multi-level decision-making, ensuring that transactions are only allowed to execute under the safest and most reliable conditions, providing a solid guarantee for the security of medical services. The entire verification process is highly automated and intelligent, adaptable to complex and ever-changing medical business scenarios, and supports state verification needs for various medical transactions, from simple outpatient services to complex surgical procedures. This technical solution not only significantly improves the success rate of distributed medical transactions, but also greatly reduces transaction rollbacks and resource waste caused by inconsistent states. It provides strong technical support for the digital transformation and intelligent upgrading of medical institutions, and has important practical value and promotion significance for promoting the in-depth development of medical informatization and ensuring the high-quality operation of medical services.

[0170] In one embodiment of this example, under the condition that all preflight responses are successful, an exclusive lock is acquired in the distributed lock service using the transient state vector as the lock identifier, including the following steps:

[0171] S610. Under the condition that all preflight responses are successful, create a lock request including the transient state vector;

[0172] S620. Send the lock request to the distributed lock service, where the distributed lock service uses the transient state vector as the lock path and creates a temporary sequence node;

[0173] S630. Determine whether the temporary sequential node is the node with the smallest sequence number;

[0174] S640. If the temporary sequence node is the smallest sequence number node, then acquire the exclusive lock in the distributed lock service.

[0175] When creating a lock request, including a transient state vector, under the condition that all preflight responses are successful, the lock request creation is based on structured data encapsulation and secure transmission protocols to ensure the integrity and uniqueness of lock identification information. In practice, the lock request creation process aggregates the successful preflight responses returned by all participants, verifies the integrity and consistency of the responses, and confirms that each participant has the capability and resources to execute the transaction. The creation process uses a standardized lock request data structure, containing core fields such as the transient state vector, global transaction ID, request timestamp, lock type identifier, timeout setting, priority, and other key information.

[0176] The transient state vector, as a core component of the lock identifier, ensures that transactions with the same business state characteristics will compete for the same lock resource, while transactions in different states can execute in parallel. The lock request also includes additional metadata information, such as the request initiator's identity, business type identifier, expected execution time, and resource requirement list, providing a reference for the intelligent scheduling of the distributed lock service. The creation process uses digital signature technology to ensure the immutability of the request, preventing malicious requests or data corruption during network transmission.

[0177] Lock requests are formatted using compact binary encoding or standardized JSON format, balancing transmission efficiency and readability. The creation process also includes request validity verification, ensuring the instantaneous state vector is correctly formatted, the timestamp is within a valid range, and business parameters meet expected constraints. To improve request processing efficiency, the creation process supports batch request mode; when multiple related transactions need to acquire a lock, requests can be merged and sent. Completed lock requests are temporarily stored in a local queue, awaiting transmission to the distributed lock service, while a timeout monitoring mechanism is activated to prevent requests from remaining unresponsive for extended periods.

[0178] Distributed lock services are typically implemented based on mature distributed coordination systems such as Apache Zookeeper, etcd, or Consul, possessing strong consistency, high availability, and automatic fault recovery capabilities. In practice, the lock request sending process employs reliable network transport protocols, such as TCP long connections or HTTP / 2, to ensure that requests reach the distributed lock service accurately. The sending process includes a complete flow of connection establishment, authentication, data transmission, and acknowledgment of receipt.

[0179] Upon receiving a request, the distributed lock service parses the transient state vector and uses it as a key component of the lock path. The lock path employs a hierarchical structure, typically formatted as " / distributed-locks / medical-tx / {hash-prefix} / {full-vector}", where `hash-prefix` is a prefix hash of the transient state vector used for load balancing and fast indexing, and `full-vector` is the complete state vector value. The creation of ephemeral sequential nodes is a core feature of coordination systems like Zookeeper. The node creation process automatically assigns incrementing sequence numbers, ensuring that all requests within the same lock path receive a unique sequence identifier.

[0180] The ephemeral nature of nodes ensures that related lock requests are automatically cleaned up when a client connection is lost or exits abnormally, preventing deadlocks. The sequential nature of nodes guarantees fairness in lock acquisition; requests arriving earlier receive smaller sequence numbers and have higher lock acquisition priority. The node creation process also records detailed request information, including request time, client identifier, business type, and other metadata, providing complete audit information for lock management and monitoring. After creation, the distributed lock service returns the node's complete path and sequence number information, providing a basis for subsequent lock state determination.

[0181] The process of determining whether a temporary sequential node is the smallest sequence number node is based on ZooKeeper's sequential node characteristics to achieve a fair lock contention mechanism. In practice, the process queries all temporary sequential nodes under the current lock path to obtain a complete list of nodes and their corresponding sequence numbers. This query operation is implemented through the distributed lock service's API interface, such as ZooKeeper's `getChildren()` method, which returns the names and basic attributes of all child nodes.

[0182] The node sequence number extraction process parses the sequence number suffix from the node name, typically in the format "lock-{sequence-number}", and obtains the actual sequence number value through string processing and numerical conversion. Sequence number comparison uses a numerical sorting algorithm to determine the relative position of the current node among all active nodes. The judgment process needs to consider the node's lifecycle state, filtering out nodes that are invalid or being deleted to ensure the accuracy of the comparison results.

[0183] To address network latency and timing issues, the judgment process employs a multi-round verification mechanism. A second confirmation is performed after the initial judgment to prevent misjudgments caused by network jitter or changes in node state. The judgment process also includes an exception handling mechanism. When encountering anomalies such as network timeouts, service unavailability, or data inconsistencies, a retry process or error reporting is triggered. For boundary cases, such as nodes created simultaneously with the same sequence number, the judgment process introduces additional winning rules, such as node creation timestamps and client identifier hash values, to ensure the uniqueness and determinism of the judgment result.

[0184] The judgment result includes not only a Boolean value indicating whether it is the smallest sequence number, but also detailed information such as the current node's queuing position, the identifier of the previous node, and the estimated waiting time, providing complete status feedback for subsequent client processing. This sequence number-based fair competition mechanism ensures the orderliness and fairness of lock acquisition in a distributed environment, avoiding common concurrency control problems such as starvation and priority inversion.

[0185] As described in step S150 above, when the temporary sequence node is confirmed as the smallest sequence number node, it indicates that the current transaction has acquired an exclusive lock based on the transient state vector, and has exclusive execution rights. In practice, the process of acquiring an exclusive lock includes multiple steps such as lock state confirmation, lock information recording, timeout setting, and monitoring startup. The lock state confirmation process will further verify the validity and exclusivity of the node to ensure that no other client acquires the same lock simultaneously.

[0186] Lock information records persistently store key information such as lock acquisition time, holder ID, lock ID, and expected release time, providing data support for lock management and fault recovery. Timeout settings, based on the expected execution time of transactions and system configuration parameters, set reasonable timeout thresholds for locks to prevent long-term lock holding due to client anomalies. Monitoring startup creates a dedicated monitoring thread to periodically check the lock status and client health, enabling automatic lock management and anomaly recovery. Upon successful acquisition, the client receives a clear lock acquisition confirmation message containing important information such as the lock's unique identifier, validity period, and release method. This fine-grained locking mechanism based on state vectors not only ensures mutual exclusion of transactions but also enables parallel execution of transactions in different states, significantly improving the system's concurrency processing capabilities and resource utilization efficiency.

[0187] In this embodiment, the structured lock request creation mechanism ensures the integrity and security of lock identification information. Through digital signature and format verification technologies, it effectively prevents malicious requests and data tampering, providing trusted request input for the distributed lock service. The ephemeral sequential node creation mechanism, based on a mature distributed coordination system, fully leverages the strong consistency and high availability characteristics of systems like Zookeeper. Through automatic sequence number allocation and ephemeral node features, it achieves fair lock contention and automatic deadlock prevention. The minimum node judgment mechanism based on sequence number comparison ensures the fairness and orderliness of lock acquisition, avoiding the starvation and priority inversion problems common in traditional lock mechanisms, ensuring that all transaction requests receive a fair processing opportunity. The fine-grained exclusive lock mechanism based on state vectors achieves unprecedented granularity of concurrency control. Transactions with different business states can be executed in parallel, while transactions with the same business state are strictly mutually exclusive. This design maximizes the system's concurrency processing capabilities while ensuring data consistency. The entire lock acquisition process is highly automated and intelligent, supporting various application scenarios from simple single-resource locking to complex multi-dimensional state locking. This technical solution is particularly suitable for the complex business needs of medical information systems. It can effectively coordinate resource competition issues in various medical processes such as surgery, emergency, outpatient, and inpatient care, ensuring the rational allocation and secure use of critical medical resources. Through this advanced distributed locking mechanism, it not only significantly improves the execution efficiency and success rate of medical operations but also enhances the system's scalability and fault tolerance. This provides strong technical support for the digital transformation and intelligent upgrading of medical institutions and has significant practical value in promoting the improvement of medical service quality and the optimization of medical resource allocation.

[0188] In one embodiment of this invention, the method further includes the following steps:

[0189] S710. Based on the global transaction request, obtain the estimated execution time, and calculate the basic timeout duration based on the estimated execution time;

[0190] S720: Based on the preset average execution time, the basic timeout duration is corrected to obtain the corrected timeout duration;

[0191] S730: Obtain the current network latency, and further adjust the corrected timeout duration based on the current network latency to obtain the final duration;

[0192] S740: Set the final duration as the timeout for the exclusive lock and start the timeout monitoring thread to release the exclusive lock before the final duration is reached.

[0193] When obtaining the estimated execution time and calculating the basic timeout duration based on the global transaction request, the process of obtaining the estimated execution time analyzes key indicators such as the business operation identifier, number of participants, data scale, and operation complexity in the global transaction request. In specific implementation, the estimation algorithm adopts a multi-dimensional evaluation model. The business operation identifier determines the basic execution time range; for example, the basic execution time for a simple outpatient registration business is 1-2 seconds, while the basic execution time for a complex surgical preparation business is 10-30 seconds. The number of participants affects the total execution time through a linear or logarithmic function; the more participants, the greater the coordination overhead, and the longer the execution time.

[0194] Data scale assessment analyzes factors such as the number of data records involved in a transaction, data transmission volume, and computational complexity, and uses empirical formulas to predict execution time. The estimation process also considers the urgency and priority of the business; high-priority medical transactions receive more resource allocation and have relatively shorter execution times. The calculation of the base timeout duration employs a safety factor amplification strategy, typically set at 2-3 times the estimated execution time. The formula is: Base Timeout Duration = Estimated Execution Time × Safety Factor + Fixed Buffer Time.

[0195] The safety factor is dynamically adjusted based on the predictability of the business type. Businesses with high predictability use a smaller safety factor, while businesses with high uncertainty use a larger safety factor. A fixed buffer time is used to handle unexpected situations and system overhead, typically set to 2-5 seconds. The calculation process also includes boundary value handling to ensure that the timeout duration is neither too short (to avoid falsely killing normal transactions) nor too long (to avoid abnormal transactions occupying resources for extended periods), setting reasonable minimum and maximum limits.

[0196] Average execution time data is derived from the system's historical execution records and categorized by business type, time period, system load, and other dimensions. In practice, the correction process queries historical transaction records similar to the current transaction. Similarity assessment is based on multiple dimensions, including matching business operation identifiers, the range of participating parties, and data scale. Historical data statistics employ a sliding window mechanism, focusing on execution performance over a recent period, typically selecting data from the last 7 or 30 days to ensure the statistical results reflect the system's current performance status.

[0197] The average execution time is calculated using a weighted average algorithm, assigning higher weights to more recent data. The formula is: Weighted Average Time = Σ(Execution Time i × Weight i) / Σ Weight i. The correction algorithm employs an adaptive adjustment strategy. When the historical average execution time is significantly less than the estimated execution time, the base timeout duration is appropriately reduced to improve resource utilization efficiency; when the historical average execution time is close to or exceeds the estimated execution time, the base timeout duration is appropriately increased to improve the execution success rate.

[0198] The correction formula is: Corrected timeout duration = Base timeout duration × (1 + Correction factor), where the correction factor is dynamically calculated based on the statistical characteristics of historical data, typically ranging from -0.3 to +0.5. The correction process also considers data confidence and sample size. With sufficient and stable sample size, the correction magnitude can be larger; with insufficient or highly volatile sample size, the correction magnitude is more conservative. The correction process also includes outlier filtering, removing obviously abnormal historical execution records to prevent extreme cases from having an excessive impact on the correction result.

[0199] The network latency acquisition process combines active probing and passive monitoring. Active probing assesses network latency by sending lightweight ping or heartbeat messages to each participant and measuring round-trip time. In practice, network latency measurement employs a multi-point sampling strategy, simultaneously measuring the network latency of all participants and using the average, maximum, and standard deviation as a comprehensive indicator of network condition. Parallel probing technology is used to avoid time accumulation caused by sequential measurements. Measurement results include key parameters such as minimum latency, maximum latency, average latency, and packet loss rate.

[0200] Passive monitoring analyzes network performance data from historical communication records to establish a time-series model of network latency and predict the current network status. The network latency correction algorithm is calculated based on a latency impact factor, using the formula: Final latency = Corrected timeout latency × (1 + Network latency correction coefficient). The network latency correction coefficient is calculated based on the ratio of the current network latency to the baseline latency. When the network latency is significantly higher than the baseline value, the timeout latency is increased to address network instability; when the network latency is lower than the baseline value, the timeout latency can be appropriately reduced to improve resource turnover efficiency.

[0201] The correction process also considers the trend of network latency. If network latency worsens, the timeout duration is increased in advance; if network latency remains stable or improves, corrections are made according to the current situation. The correction algorithm also includes an adaptive learning mechanism, which dynamically adjusts the correction strategy and parameters based on feedback from historical correction effects, achieving self-optimization of the correction algorithm. The final duration also needs to undergo a reasonableness check to ensure that the result is within the preset boundary range, avoiding excessive deviations in timeout duration from the normal range due to network anomalies.

[0202] The timeout setting process configures the calculated final duration into the distributed lock service, typically through the lock service's API. In practice, a layered management strategy is used for timeout settings: hard timeout limits are set at the distributed lock service level, while soft timeout warnings are implemented at the application level. Hard timeouts ensure that lock resources are not occupied indefinitely; when the timeout period is reached, the lock service forcibly releases the lock resources. Soft timeouts provide an early warning mechanism, proactively releasing the lock before the timeout period, preventing forced termination.

[0203] The timeout monitoring thread is started in an independent thread mode, separated from the main business logic, to ensure the stable operation of the monitoring function. The monitoring thread uses a timed check mechanism, with the check interval typically set to 5%-10% of the timeout duration, ensuring timely response while avoiding excessive consumption of system resources. The monitoring process includes multiple check dimensions: checking the execution progress of transactions to assess whether they can be completed before the timeout; checking the lock holding status to confirm that the lock is still valid and has not been abnormally released; and checking the health status of the client to ensure that the lock holding process is running normally.

[0204] The pre-release mechanism is automatically triggered when the monitoring thread detects an approaching timeout, typically set to start when less than 10%-20% of the time remains. The pre-release process includes a complete workflow of transaction status checks, resource cleanup, and lock release, ensuring that lock resources are promptly made available to other waiting transactions. The monitoring thread also supports dynamic timeout adjustment; when transaction execution progress is detected to be ahead of or behind expectations, the remaining timeout can be adjusted appropriately for more granular resource management. The monitoring process generates detailed log records, including monitoring time points, lock status, transaction progress, and adjustment operations, providing data support for system optimization and problem diagnosis.

[0205] In this embodiment, a pre-estimation algorithm based on business complexity and historical data provides personalized timeout configurations for different types of medical services. Through a multi-dimensional evaluation model and a security factor amplification strategy, it ensures that the timeout duration meets normal execution requirements while effectively preventing long-term resource occupation, thus effectively solving the problem that traditional fixed timeout strategies cannot adapt to diverse business needs. The correction mechanism based on historical statistical data fully utilizes the execution experience accumulated during system operation. Through a weighted average algorithm and adaptive adjustment strategy, the timeout setting dynamically reflects the system's true performance, significantly improving the accuracy and rationality of the timeout setting. The dynamic correction mechanism based on network latency effectively addresses the impact of changes in network conditions in a distributed environment. By combining active detection and passive monitoring, it promptly senses changes in network performance and adjusts the timeout strategy accordingly, ensuring reliable execution of distributed transactions even under unstable network conditions. Independent timeout monitoring and pre-release mechanisms provide multi-layered resource protection. Through a combination of hardware and software timeouts, periodic checks, and dynamic adjustments, it maximizes the avoidance of lock resource waste and deadlock problems while ensuring the continuity of critical medical services. The entire timeout management mechanism is highly intelligent and adaptive, dynamically optimizing timeout strategies based on various factors such as system load, network conditions, and business characteristics. This adapts to the specific requirements of 24 / 7 continuous operation and sudden load surges in healthcare services. This technical solution not only improves the success rate and resource utilization efficiency of distributed healthcare transactions but also enhances the system's self-management and fault recovery capabilities. It provides a more stable and reliable technical foundation for the digital operation of healthcare institutions, and is of great significance for ensuring high-quality healthcare services and promoting the in-depth development of healthcare informatization.

[0206] In one embodiment of this invention, the method further includes the following steps:

[0207] S810. If any distributed healthcare service participant fails the pre-inspection or fails to acquire an exclusive lock, a transaction cancellation instruction is issued to all distributed healthcare service participants to release the reserved resources and the acquired locks. The reserved resources are the database connections, memory caches and temporary storage space locked by each participant during the pre-inspection phase. The acquired locks refer to the exclusive locks created in the distributed lock service based on the transient state vector.

[0208] The issuance of transaction cancellation commands and the release of resources ensure the rational utilization of resources and the avoidance of resource leaks in distributed healthcare systems. Its implementation principle is based on rapid fault detection, cascading cancellation, and resource reclamation technologies. Specifically, the triggering conditions for transaction cancellation include two core scenarios: pre-check failure of any participant in the distributed healthcare service and failure to acquire a distributed lock. Pre-check failure detection is achieved by aggregating and analyzing the pre-check responses returned by all participants. When a failure response is detected from any participant, the system immediately initiates the transaction cancellation process.

[0209] The failure detection algorithm employs a fast-fail strategy, not waiting for all responses; it immediately triggers cancellation upon detecting a failed response, minimizing resource occupation time. Distributed lock acquisition failure detection is achieved by monitoring the status of lock requests, including various failure scenarios such as lock service unavailability, lock contention timeout, and network communication anomalies. The transaction cancellation command is constructed using a standardized message format, containing key information such as the global transaction ID, cancellation reason, cancellation timestamp, and resource release list.

[0210] The command issuance process employs a parallel broadcast mechanism, simultaneously sending cancellation commands to all distributed healthcare service participants who have participated in the pre-screening phase, ensuring the timeliness and consistency of the cancellation operation. The issuance process utilizes a reliable transmission protocol; participants experiencing failed transmissions will be retried, with reasonable retries and timeout limits set. Upon receiving the cancellation command, each participant immediately initiates a local resource release process, including releasing database connections locked during the pre-screening phase, clearing allocated memory caches, deleting temporary storage files, and revoking the reserved state of data records.

[0211] The resource release process employs atomic operations to ensure resource consistency and avoid data inconsistencies caused by partial releases. Simultaneously, the transaction coordinator releases acquired distributed exclusive locks by sending a lock release request to the distributed lock service and deleting the corresponding temporary sequence node, allowing the lock resource to be immediately acquired by other waiting transactions. The entire cancellation and release process also includes operation log recording, detailing the cancellation reason, scope of impact, and release result, providing data support for subsequent problem analysis and system optimization.

[0212] In this embodiment, the fast failure detection and parallel cancellation instruction issuance mechanism ensures timely termination when transactions cannot be executed normally, avoiding long-term ineffective resource occupation. Especially during peak medical business periods, this rapid release mechanism can significantly improve the overall throughput and responsiveness of the system. The multi-layered resource release strategy covers various system resources such as database connections, memory caches, temporary storage, data reservation, and distributed locks. Atomic release operations ensure the consistency and integrity of resource states, effectively preventing resource leaks and deadlocks. The unified cancellation mechanism based on global transaction IDs achieves cross-system coordination and consistency, ensuring that all participating medical services can synchronously cancel related operations, avoiding data inconsistencies and business chaos caused by some systems continuing to execute. Detailed operation logs and auditing mechanisms provide complete data support for system monitoring, optimization, and troubleshooting. Administrators can analyze logs to understand the distribution, frequency characteristics, and impact scope of transaction cancellation reasons, thereby optimizing system configuration and business processes in a targeted manner. This mechanism is particularly suitable for complex business scenarios in medical environments, effectively addressing transaction interruption needs caused by sudden changes in patient conditions, emergency allocation of medical resources, equipment failures, and other unforeseen circumstances. By ensuring the rapid recovery and reallocation of system resources, not only is the reliability and availability of the medical information system improved, but also a strong technical guarantee is provided for the efficient operation and high-quality service of medical institutions. This has important practical value for promoting the continuous improvement of medical service quality and the optimization of medical resource allocation.

[0213] In one embodiment of this example, both the final execution instruction and the transaction cancellation instruction contain a globally unique transaction ID.

[0214] As described in step S160 above, the final execution instruction includes a globally unique transaction ID as the core identifier to ensure accurate transmission and execution confirmation of the instruction. In specific implementation, the globally unique transaction ID plays multiple key roles in the final execution instruction. As the primary key identifier of the instruction, it ensures that each participant can accurately identify the specific transaction corresponding to the current instruction, avoiding instruction confusion or erroneous execution. The transaction ID is encapsulated in the instruction using a fixed field position and standardized data format, usually located in the first field of the message header, and uses UTF-8 encoding to ensure cross-platform compatibility.

[0215] The transaction ID is used to associate and match with the temporary state in the pre-check phase. After receiving the final execution instruction, the participants will look up the corresponding pre-check record based on the transaction ID to verify the legality and continuity of the instruction. The association verification process includes multiple steps such as transaction ID format checking, existence verification, and state consistency confirmation, ensuring that only transactions that have undergone the complete pre-check process can enter the final execution phase. The transaction ID in the final execution instruction also contains execution context information, such as metadata like transaction creation time, expected completion time, and execution priority, providing comprehensive guidance information for the participants' local execution.

[0216] During execution, participating parties establish local execution logs based on transaction IDs, recording the detailed process and results of the execution, providing a complete data link for subsequent auditing, tracing, and fault diagnosis. The transaction ID in the final execution instruction also supports a feedback mechanism for execution results. After completing their local transactions, participating parties will send the execution results along with the transaction ID back to the transaction coordinator, ensuring real-time synchronization and global consistency of transaction states.

[0217] As described in step S810 above, the transaction cancellation instruction also includes a globally unique transaction ID to ensure the accuracy and completeness of the cancellation operation. In practice, the role of the transaction ID in the cancellation instruction is similar to, but more stringent than, that of the final execution instruction. The transaction ID is used to precisely locate the transaction instance that needs to be cancelled. After receiving the cancellation instruction, the participating parties will look up the corresponding pre-check records and reserved resources based on the transaction ID to ensure the targeting and accuracy of the cancellation operation.

[0218] The precise matching mechanism for cancellation operations prevents the risk of mistakenly canceling other transactions, which is crucial, especially in high-concurrency healthcare environments. The transaction ID in the cancellation command carries the cancellation reason and contextual information, including the cancellation trigger time, the identifier of the failing participant, and detailed reasons for failure, providing participants with a complete decision-making basis for local cancellation processing. The transmission of the cancellation reason not only helps participants understand the necessity of cancellation but also provides valuable feedback for subsequent problem analysis and process optimization.

[0219] The transaction ID in the cancellation command also ensures the idempotency of the cancellation operation. Even if participants receive the same cancellation command repeatedly, it can correctly identify and avoid duplicate cancellation operations. The idempotency guarantee mechanism is implemented through transaction ID state tracking. Participants maintain a record of processed cancellation commands, and for duplicate cancellation requests, the processed status is directly returned, avoiding duplicate resource release or abnormal operations. The transaction ID in the transaction cancellation command supports a cascading cancellation mechanism. When the main transaction is cancelled, all related sub-transactions and dependent transactions are also automatically cancelled according to the association relationship of the transaction IDs, ensuring the integrity and consistency of distributed transactions.

[0220] The consistent use of globally unique transaction IDs in both final execution and transaction cancellation instructions reflects the consistency design principle of distributed transaction processing. Its implementation is based on a rigorous ID generation, transmission, and verification mechanism. In practice, the uniformity of transaction IDs is ensured through standardized ID generation. Both final execution and transaction cancellation instructions use the same transaction ID generation algorithm and format specification, ensuring the uniqueness and consistency of the ID throughout the entire transaction lifecycle. The ID generation process adopts the UUID version 4 standard, combining server identifiers, timestamps, and random numbers to ensure global uniqueness in a distributed environment.

[0221] The transaction ID transmission mechanism employs end-to-end integrity protection. Throughout the instruction transmission process from the transaction coordinator to each participant, the transaction ID remains unchanged. The transmission protocol uses checksums to ensure that the ID is not tampered with or corrupted during network transmission. The transaction ID verification mechanism is integrated throughout the entire instruction processing flow. Upon receiving any instruction, each participant verifies the format validity, uniqueness, and relevance of the transaction ID. Only instructions that pass verification are executed or processed. The verification process includes multiple layers, such as ID format checking, existence verification, and state consistency confirmation, ensuring the reliability and security of instructions.

[0222] The audit trail mechanism based on transaction IDs ensures that all related operations can be associated and traced through transaction IDs throughout the entire process from transaction creation to final completion or cancellation, providing a complete data link for system monitoring and management and problem diagnosis. This unified design not only simplifies the management complexity of distributed transactions but also improves the maintainability and scalability of the system.

[0223] In this embodiment, the unified transaction ID design significantly simplifies the complexity of transaction management in a distributed environment. All participants can accurately identify and process relevant instructions using the same identifier, avoiding instruction confusion or execution errors caused by inconsistent identifiers. This uniformity is crucial for ensuring the accuracy and security of operations, especially in complex scenarios in healthcare. The instruction transmission mechanism based on the unified transaction ID enables end-to-end operation traceability and state synchronization. Throughout the entire lifecycle of a transaction, from initiation to completion or cancellation, all related operations can be precisely associated through the transaction ID, providing complete data support for audit compliance and quality control in healthcare operations. The idempotency guarantee mechanism of the transaction ID effectively prevents duplicate operations and resource waste. Whether executing or canceling instructions, it correctly handles abnormal situations such as network anomalies and message duplication, ensuring stable system operation under various fault scenarios. The unified transaction ID design also enhances the system's scalability and interoperability. New healthcare services or business scenarios can be seamlessly integrated into the existing transaction processing framework without modifying the core identifier management logic. This technical solution is particularly suitable for the diverse business needs of medical information systems, effectively supporting various medical transaction scenarios ranging from simple single operations to complex cross-system collaborations. It provides a standardized and regulated technical foundation for the digital transformation and business process optimization of medical institutions. By ensuring the consistency and reliability of distributed transaction processing, it not only improves the execution efficiency and success rate of medical services but also enhances the integrity and accuracy of medical data, which has significant practical value and far-reaching implications for ensuring patient safety and improving the quality of medical services.

[0224] This application embodiment also provides a server, including:

[0225] The memory is configured to store instructions; and

[0226] The processor is configured to retrieve instructions from memory and, when executing instructions, implement the aforementioned distributed transaction consistency guarantee method for medical information integration.

[0227] 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.

[0228] 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, and 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0229] 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.

[0230] 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.

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

[0232] 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.

[0233] 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.

[0234] 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.

[0235] 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 distributed transaction consistency guarantee method for medical information integration, characterized in that, Applied to servers, including: In response to a global transaction request received from the business initiator, obtain the business operation identifier; Based on the business operation identifier, the multiple distributed medical service participants participating in the global transaction are parsed and identified in the preset participant configuration file, and a globally unique transaction ID is generated for the global transaction. Key business status parameters are extracted from global transaction requests and pre-configured business rules. The key business status parameters are then combined and cryptographically hashed according to the business operation identifier to construct an instantaneous state vector, which is used to represent the current transaction execution conditions. Generate a transaction pre-inspection request containing a globally unique transaction ID and a transient state vector, and distribute the transaction pre-inspection request in parallel to all distributed healthcare service participants. Each distributed healthcare service participant is used to verify the executability of the transaction pre-inspection request during the pre-inspection phase and generate a pre-inspection response. Aggregate all pre-inspection responses returned from the participants in the distributed healthcare service, and if all pre-inspection responses are successful, use the transient state vector as the lock identifier to acquire an exclusive lock in the distributed lock service; A final execution instruction is issued to all participants in the distributed healthcare service to commit local transactions. The final execution instruction is used to instruct each participant in the distributed healthcare service to convert the temporary state of the pre-inspection phase into a persistent state and release the local resource lock.

2. The method according to claim 1, characterized in that, Based on the business operation identifier, the system parses and identifies multiple distributed healthcare service participants participating in the global transaction from the pre-defined participant configuration file, including: Parse the business operation identifier to obtain the combination of business type and operation type; The corresponding service mapping table is retrieved from the participant's configuration file based on a combination of business type and operation type. Extract the list of participating services from the service mapping table; The list of participating service providers determines the multiple distributed healthcare service participants involved in the global transaction.

3. The method according to claim 1, characterized in that, Based on the business operation identifier, key business state parameters are combined and cryptographically hashed to construct an instantaneous state vector, including: Retrieve the business rule corresponding to the business operation identifier from the pre-configured business rule base; The key parameter definitions affecting transaction execution are obtained by parsing the business rules; Based on the definition of key parameters, the parameter key names are extracted and sorted according to preset priority to obtain a list of key names; Extract the values ​​corresponding to the list of keys from the global transaction request to obtain a set of key-value pairs; Sort and concatenate the key-value pair collection to obtain a string; Concatenate the string with the globally unique transaction ID to obtain the combined string; The combined string is hashed using the SHA-256 hash algorithm to obtain the initial hash value. Append the current timestamp to the initial hash value and perform a second hash operation to obtain a time-sensitive hash value; The time-sensitive hash value is Base64 encoded to obtain the encoded hash value, and the encoded hash value is used as the instantaneous state vector.

4. The method according to claim 1, characterized in that, Each participant in the distributed healthcare service is responsible for verifying the executability of the transaction pre-screening request during the pre-screening phase and generating a pre-screening response, including: For each distributed healthcare service parameter, during the pre-inspection phase, the transaction pre-inspection request is received and parsed to obtain a globally unique transaction ID and an instantaneous state vector. Check the local transaction log based on the globally unique transaction ID to confirm whether there are duplicate transaction requests. Based on the instantaneous state vector, verify whether the current local data state meets the preconditions for transaction execution; Check the availability of local resources to confirm whether the transaction operation can be completed. Local resources include database connections, memory space, and computing resources. If there are no duplicate transaction requests, the current local data state meets the preconditions for transaction execution, and the transaction operation can be completed, reserve local resources and generate a preflight response containing a success flag; otherwise, generate a preflight response containing the reason for failure.

5. The method according to claim 4, characterized in that, Based on the instantaneous state vector, verify whether the current local data state meets the preconditions for transaction execution, including: Analyze the instantaneous state vector to obtain key business state parameters; Based on the key business status parameters, the current status of the corresponding data record can be retrieved from the local data storage. Compare the current status with the key business status parameters to determine if the data version is consistent, and verify whether the local data record is locked by other transactions; If the data version is consistent and it is not locked by other transactions, determine that the current local data state meets the preconditions for transaction execution.

6. The method according to claim 1, characterized in that, Assuming all preflight responses are successful, an exclusive lock is acquired in the distributed lock service using the transient state vector as the lock identifier, including: If all preflight responses are successful, create a lock request that includes the transient state vector. The lock request is sent to the distributed lock service, which uses the transient state vector as the lock path and creates a temporary sequence node. Determine whether the temporary sequential node is the node with the smallest sequence number; If the temporary sequence node is the smallest sequence number node, then an exclusive lock is acquired in the distributed lock service.

7. The method according to claim 6, characterized in that, The method also includes: Based on the global transaction request, obtain the estimated execution time, and calculate the basic timeout duration based on the estimated execution time; Based on the preset average execution time, the base timeout duration is adjusted to obtain the adjusted timeout duration; Obtain the current network latency, and further adjust the corrected timeout duration based on the current network latency to obtain the final duration; Set the final duration as the timeout for the exclusive lock and start a timeout monitoring thread to release the exclusive lock before the final duration is reached.

8. The method according to claim 1, characterized in that, The method also includes: If any participant in the distributed healthcare service fails the pre-check or fails to acquire an exclusive lock, a transaction cancellation instruction is issued to all participants in the distributed healthcare service to release the reserved resources and the acquired locks. The reserved resources are the database connections, memory caches and temporary storage space locked by each participant during the pre-check phase. The acquired locks refer to the exclusive locks created in the distributed lock service based on the transient state vector.

9. The method according to claim 8, characterized in that, Both the final execution instruction and the transaction cancellation instruction contain a globally unique transaction ID.

10. A server, characterized in that, include: The memory is configured to store instructions; as well as A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the distributed transaction consistency guarantee method for medical information integration according to any one of claims 1 to 9.

Images