Distributed transaction consistency guarantee method oriented to medical information integration and server

Abstract

The invention discloses a distributed transaction consistency guarantee method and server for medical information integration, and relates to the technical field of platform integration, and the method comprises the steps: obtaining a business operation identifier; according to the business operation identifier, analyzing and determining a plurality of distributed medical service participants participating in the global transaction in a preset participant configuration file, and generating a global unique transaction ID; key service state parameters are extracted, and an instantaneous state vector is constructed; generating a transaction pre-check request containing a global unique transaction ID and an instantaneous state vector, and distributing the transaction pre-check request to all distributed medical service participants in parallel; summarizing all the pre-check responses, and under the condition that all the pre-check responses are successful responses, using the instantaneous state vector as a lock identifier, and obtaining exclusive locks in the distributed lock service; and issuing a final execution instruction to all distributed medical service participants to submit the local transaction. The risk of medical negligence threats caused by transaction rollback can be effectively reduced.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of platform integration, and in particular to a distributed transaction consistency guarantee method for medical information integration and a server. BACKGROUND

[0002] With the continuous deepening of medical informatization construction, 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, blood bank management system, etc. These systems not only improve the efficiency and quality of medical services, but also bring complex challenges of data consistency and business coordination between systems.

[0003] In the medical business scenario, many key operations need to be processed across multiple systems. For example, the patient's surgery process involves joint operations of the surgery scheduling system, anesthesia management system, drug management system, blood bank system, billing system, etc.; for another example, in the emergency rescue process, the inspection system, image system, pharmacy system, and bed management system need to be called at the same time. These cross-system business operations essentially constitute a distributed transaction, which requires all participating systems to either all succeed or all roll back to ensure the consistency of medical data and the integrity of the business process.

[0004] Currently, the widely used distributed transaction solution in the industry mainly includes the TCC (Try-Confirm-Cancel) mode, which guarantees the consistency of distributed transactions through the three-phase protocol of reserving resources in the Try phase, confirming submission in the Confirm phase, and releasing resources in the Cancel phase.

[0005] However, the above-mentioned TCC mode solution mainly focuses on consistency guarantee during transaction execution, that is, how to ensure the consistency of the operation state of each participant after the transaction has started. This post-guarantee mechanism is effective in general business scenarios, but it faces serious challenges in the medical environment. Medical business has strong timeliness and high risk characteristics, and the business state changes frequently and unpredictably, such as sudden changes in patient vital signs, temporary calls for key medical resources, and queue processing of emergency medical events, etc. These dynamic factors make the effectiveness window of medical transactions extremely short. And in the medical scenario, the executability of business operations often depends on the real-time state of multiple systems, such as the inventory quantity of specific specification drugs, the availability of specific blood types, the use state of key medical equipment, the scheduling situation of medical staff, etc. These state information may change at any time during transaction execution, and the above-mentioned solution often discovers state conflicts only when the transaction is half executed, at which time transaction rollback not only wastes system resources, but more importantly, may delay the best treatment opportunity for the patient.

[0006] In summary, due to the extremely short validity window of medical affairs and the large number of dynamically changing states, the above-mentioned traditional distributed transaction solution discovers state conflicts after the transaction is started, which is too late, thereby greatly increasing the risk of medical accidents. For example, in a complex operation, multiple systems such as drug preparation, blood preparation, and billing are linked. If it is found in the middle of the execution that the specific blood type of the blood bank has just been used up by another emergency operation, the rollback of the entire transaction not only has a technical cost, but also wastes medical resources and threatens patient safety.

[0007] Therefore, there is an urgent need for a method to effectively solve the above problems. SUMMARY

[0008] The embodiments of the present application provide 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-mentioned purpose, the embodiments of the present application adopt the following technical solutions: In a first aspect, a distributed transaction consistency guarantee method for medical information integration is provided, applied to a server, and the method comprises: In response to a global transaction request received from a business initiator, obtaining a business operation identifier; According to the business operation identifier, a plurality of distributed medical service participants participating in the global transaction are parsed and determined in a preset participant configuration file, and a globally unique transaction ID is generated for the global transaction; Key business state parameters are extracted from the global transaction request and pre-configured business rules, and the key business state parameters are combined and encrypted and hashed according to the business operation identifier to construct a transient state vector, wherein the transient state vector is used to represent the current transaction execution condition; A transaction pre-check request containing the globally unique transaction ID and the transient state vector is generated, and the transaction pre-check request is distributed in parallel to all distributed medical service participants. Each distributed medical service participant is used to verify the executability of the transaction pre-check request in the pre-check stage, and a pre-check response is generated; All pre-check responses returned from the distributed medical service participants are summarized, and under the condition that all pre-check responses are successful responses, an exclusive lock is obtained in the distributed lock service using the transient state vector as a lock identifier; An ultimate execution instruction is issued to all distributed medical service participants to submit a local transaction, and the ultimate execution instruction is used to instruct each distributed medical service participant to convert the temporary state in the pre-check stage to a persistent state and release the local resource lock.

[0010] In a possible implementation manner of the first aspect, according to the business operation identifier, a plurality of distributed medical service participants participating in the global transaction are parsed and determined in a preset participant configuration file, including: The business operation identifier is parsed to obtain a business type and an operation type combination; The corresponding service mapping table is retrieved in the participant configuration file according to the business type and the operation type combination; The participant service list is extracted in the service mapping table; The plurality of distributed medical service participants participating in the global transaction are determined according to the participant service list.

[0011] In another possible implementation manner of the first aspect, a key business state parameter is combined and encrypted and hashed according to the business operation identifier to construct an instantaneous state vector, including: The business rule corresponding to the business operation identifier is retrieved in a preconfigured business rule library; The key parameter definition affecting transaction execution is parsed from the business rule; According to the key parameter definition, the parameter key name is extracted, and the key name list is obtained according to a preset priority order; The values corresponding to the key name list are extracted from the global transaction request to obtain a key-value pair set; The key-value pair set is sorted and spliced to obtain a string; The string is spliced with the globally unique transaction ID to obtain a combined string; The SHA-256 hash algorithm is used to perform a first hash operation on the combined string to obtain an initial hash value; The current timestamp is appended to the initial hash value, and a second hash operation is performed to obtain a time-sensitive hash value; The time-sensitive hash value is Base64 encoded to obtain an encoded hash value, and the encoded hash value is taken as the instantaneous state vector.

[0012] In another possible implementation manner of the first aspect, each distributed medical service participant is configured to perform executability verification on a transaction pre-check request in a pre-check stage, and generate a pre-check response, including: For each distributed medical service participant, the transaction pre-check request is received and parsed in the pre-check stage to obtain a globally unique transaction ID and an instantaneous state vector; According to the globally unique transaction ID, the local transaction log is checked to confirm whether there is a repeated transaction request; Based on the instantaneous state vector, it is verified whether the current local data state meets the precondition of transaction execution; checking local resource availability to confirm whether the transaction operation can be completed, wherein the local resource includes a database connection, memory space, and computing resource; in the absence of a duplicate transaction request, the current local data state satisfies the precondition of transaction execution, and the transaction operation can be completed, reserving the local resource and generating a pre-check response containing a success identifier, otherwise generating a pre-check response containing a failure reason.

[0013] In another possible implementation of the first aspect, based on the instantaneous state vector, verifying whether the current local data state satisfies the precondition of transaction execution comprises: parsing the instantaneous state vector to obtain a key business state parameter; querying the corresponding data record in the local data storage according to the key business state parameter to obtain a current state; comparing the current state with the key business state parameter to determine whether the data version is consistent, and verifying whether the local data record is locked by other transactions; in the case that the data version is consistent and not locked by other transactions, determining that the current local data state satisfies the precondition of transaction execution.

[0014] In another possible implementation of the first aspect, under the condition that all pre-check responses are success responses, using the instantaneous state vector as a lock identifier to acquire an exclusive lock in a distributed lock service comprises: under the condition that all pre-check responses are success responses, creating a lock request including the instantaneous state vector; sending the lock request to the distributed lock service, wherein the distributed lock service uses the instantaneous state vector as a lock path to create a temporary sequential node; determining whether the temporary sequential node is a minimum sequence number node; if the temporary sequential node is the minimum sequence number node, acquiring the exclusive lock in the distributed lock service.

[0015] In another possible implementation of the first aspect, the method further comprises: obtaining an estimated execution time according to the global transaction request, and calculating a basic timeout duration according to the estimated execution time; correcting the basic timeout duration based on a preset average execution time to obtain a corrected timeout duration; obtaining a current network delay, and further correcting the corrected timeout duration based on the current network delay to obtain a final duration; setting the final duration as a timeout time of the exclusive lock, and starting a timeout monitoring thread to release the exclusive lock before the final duration is reached.

[0016] In another possible implementation of the first aspect, the method further includes: If any distributed medical service participant fails the pre-check or fails to obtain an exclusive lock, a transaction cancellation instruction will be issued to all distributed medical service participants to release reserved resources and release the acquired locks. The reserved resources are the database connection, memory cache and temporary storage space locked by each participant in the pre-check phase, and the acquired lock refers to the exclusive lock created in the distributed lock service based on the transient state vector.

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

[0018] In a second aspect, the present application provides a server, comprising: a memory configured to store instructions; and The processor is configured to call instructions from the memory and implement the above-mentioned distributed transaction consistency assurance method for medical information integration when executing the instructions.

[0019] The above technical solution, through the introduction of a pre-check verification mechanism and transient state vector technology, significantly improves the reliability and efficiency of distributed transaction processing in medical scenarios. By pre-emptively checking consistency, all participants can verify the feasibility of transactions before they are actually executed. This fundamentally addresses the time lag inherent in the traditional TCC model, which requires post-detection and rollback of conflicts. This pre-check mechanism rapidly identifies potential state conflicts during prime medical service hours, avoiding transaction rollbacks caused by resource conflicts mid-process, such as surgery and emergency treatment, and significantly reducing the risk of medical malpractice. Furthermore, by combining and cryptographically hashing key business state parameters, an efficient state snapshot mechanism is created. This mechanism accurately captures dynamically changing business states within the medical system, such as drug inventory, blood reserves, equipment status, and staff schedules, and performs state consistency verification across all participants. A distributed locking mechanism based on transient state vectors enables more refined resource control. Compared to traditional global locking methods, it can differentiate locks based on specific business state characteristics, improving the system's concurrent processing capabilities and enabling multiple non-conflicting medical transactions to proceed simultaneously, effectively enhancing the utilization of medical resources. Furthermore, the parallel distribution of pre-check requests significantly shortens transaction preparation time, maximizing processing speed while ensuring consistency, which is particularly important for time-sensitive medical services. By converting temporary states to persistent states, the final submission of transactions maintains strong consistency even in medical environments with high-frequency state changes. This effectively prevents data inconsistencies caused by factors such as network latency and system failures, providing a solid technical foundation for the reliable operation of medical information systems.

[0020] Other features and advantages of the embodiments of the present application will be described in detail in the following detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 A flowchart of a distributed transaction consistency guarantee method for medical information integration provided by an embodiment of the present application is shown. Figure 2 A whole architecture diagram of a distributed transaction consistency guarantee method for medical information integration provided by an embodiment of the present application is shown. Figure 3 A distributed lock mechanism based on a transient state vector provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be understood that the specific embodiments described herein are merely used to explain and illustrate the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0023] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are merely used to explain the relative position relationship, movement condition, etc. between components in a certain posture (as shown in the drawings), and if the certain posture changes, the directional indications also change accordingly.

[0024] In addition, if the embodiments of the present application involve descriptions such as “first”, “second”, etc., the descriptions of “first”, “second”, etc. are merely for description purposes, and cannot be understood as indicating or implying the relative importance of the indicated technical features or implicitly indicating the number of the indicated technical features. Therefore, the features limited by “first”, “second” can explicitly or implicitly include at least one of the features. In addition, the technical solutions of each embodiment can be combined with each other, but it must be based on the fact that a person of ordinary skill in the art can realize the combination, and when the combination of technical solutions contradicts each other or cannot be realized, it should be considered that the combination of technical solutions does not exist, and is also not within the scope of protection claimed by the present application.

[0025] Figure 1 A flowchart of a distributed transaction consistency guarantee method for medical information integration provided by an embodiment of the present application is shown. As shown in FIG. 1, the method comprises the following steps. Figure 1As shown, the embodiment of the present application provides a distributed transaction consistency guarantee method for medical information integration, which is applied to a server and can include the following steps.

[0026] S110, in response to the global transaction request received from the service initiator, obtaining the service operation identifier; S120, according to the service operation identifier, parsing and determining the plurality of distributed medical service participants participating in the global transaction in the preset participant configuration file, and generating a globally unique transaction ID for the global transaction; S130, extracting the key business state parameters from the global transaction request and the preconfigured business rules, and combining and encrypting the key business state parameters according to the business operation identifier to perform a hash operation to construct a transient state vector, wherein the transient state vector is used to represent the current transaction execution condition; S140, generating a transaction pre-check request containing the globally unique transaction ID and the transient state vector, and distributing the transaction pre-check request to all distributed medical service participants in parallel, each of which is used to perform executability verification on the transaction pre-check request in the pre-check stage and generate a pre-check response; S150, aggregating all pre-check responses returned from the distributed medical service participants, and under the condition that all pre-check responses are successful responses, using the transient state vector as a lock identifier to obtain an exclusive lock in the distributed lock service; S160, issuing a final execution instruction to all distributed medical service participants to commit the local transaction, the final execution instruction being used to instruct each distributed medical service participant to convert the temporary state in the pre-check stage to a persistent state and release the local resource lock.

[0027] As Figure 2 shown, in actual implementation, the server first establishes a listening mechanism to receive global transaction requests from various service initiators. The service initiators can include various front-end application programs of the hospital, such as outpatient registration APP, inpatient management terminal, surgery scheduling interface, emergency management platform, etc. When any service initiator needs to perform a complex medical business operation across systems, it will send a global transaction request to the server. The request is encapsulated in a standardized data format (such as JSON or XML), containing basic information such as request timestamp, initiator identifier, patient information, operation type, and other core data.

[0028] The server extracts the business operation identifier from the received global transaction request by parsing its structure and content. The business operation identifier usually adopts a hierarchical coding structure, such as "SURGERY_PREP_001" representing the first operation of the surgery preparation type. During the extraction process, the server first verifies the integrity and legality of the request format, ensuring the presence of necessary fields, and then accurately identifies and extracts the business operation identifier from the request payload through field mapping tables or regular expression matching. This identification 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.

[0029] According to the extracted business operation identifier, the server performs parsing processing in the pre-configured participant configuration file. The participant configuration file adopts a hierarchical tree structure for storage and contains service mapping relationships corresponding to different business types. For example, for the "SURGERY_PREP_001" surgery preparation operation mentioned above, the configuration file predefines the distributed medical services that need to participate, including surgery scheduling services, anesthesia management services, drug inventory services, blood bank management services, and billing services.

[0030] The server first parses the structure of the business operation identifier, separates the business type (such as SURGERY_PREP) and the specific operation type (such as 001), and then performs hierarchical structure retrieval and matching in the configuration file. The retrieval process combines prefix matching and exact matching to ensure accurate positioning of the corresponding service mapping table. Once the matching mapping relationship is found, the server extracts the participant service list to obtain the detailed information of all distributed medical service participants involved in this global transaction, including service name, network address, interface protocol, authentication method, etc. At the same time, the server uses the UUID (Universal Unique Identifier) algorithm combined with the current timestamp and server identifier to generate a globally unique transaction ID, such as "TXN_20250729_223045_SRV001_UUID", ensuring that the transaction has uniqueness and traceability in the entire distributed medical system. This participant determination and transaction ID generation mechanism provides a clear participant scope and unique identifier basis for subsequent distributed transaction coordination.

[0031] The specific implementation process of the construction of the instantaneous state vector is as follows: first, the server extracts the basic business data from the global transaction request, and then combines the pre-configured business rule library to identify the key business state parameters that affect the execution of the current transaction. For the surgical preparation transaction, the key parameters can include patient ID, surgery type, required drug specifications and quantity, blood type and blood usage, operating room number, lead surgeon ID, anesthesiologist ID, etc. Next, the server determines the parameter combination rule according to the business operation identifier, sorts these key parameters according to the preset priority, and forms an ordered key-value pair set. The parameter combination process uses a fixed splicing format, such as "PatientID:P001|SurgeryType:ST003|DrugCode:D123|BloodType: B+|Amount:500ml". Subsequently, the server connects the combined parameter string with the globally unique transaction ID to form a combined string.

[0032] The encryption hash operation uses a double hash mechanism to enhance security and uniqueness: first, the SHA-256 algorithm is used to perform the first hash operation on the combined string to obtain a 256-bit initial hash value; then the current time stamp accurate to milliseconds is appended to the initial hash value, and the SHA-256 hash operation is performed again to generate a time-sensitive hash value; finally, the hash value is Base64 encoded to obtain the final instantaneous state vector. This instantaneous state vector accurately reflects the combined characteristics of all key business states at the current transaction execution time. Any small change in the parameters will result in a completely different vector value, thereby ensuring high precision and high sensitivity of state detection.

[0033] The generation and distribution of the transaction pre-check request is a key step to realize the pre-validation of the transaction. The server first constructs a standardized transaction pre-check request data packet, which contains the globally unique transaction ID, the instantaneous state vector, the business operation type, the expected execution parameters, the timeout setting, and other core information. The data packet is packaged in a lightweight format to ensure the efficiency of network transmission.

[0034] In the distribution phase, the server adopts a parallel processing mechanism and sends the pre-check request to all determined distributed medical service participants at the same time. Parallel distribution is realized through multi-threading technology, and each participant is allocated an independent communication thread, avoiding the accumulation of time delay caused by serial processing. After receiving the pre-check request, each distributed medical service participant immediately starts the local executability verification process. The verification process includes multiple dimensions of checks: first, the uniqueness of the transaction ID is verified to ensure that there is no repeated transaction processing; then the transient state vector is parsed to obtain the key business state parameters, which are compared and verified with the local real-time data to confirm the consistency of the data version; then the availability of local resources is checked, including the database connection pool state, memory usage, processing capacity load, etc.; finally, the executability of the business logic is evaluated, such as whether the drug inventory is sufficient, whether the blood reserve meets the demand, whether the equipment is available, etc. If all checks pass, the participant will reserve the relevant resources and generate a pre-check response containing a success identifier; if any check fails, a pre-check response containing detailed failure reasons will be generated. This pre-check verification mechanism effectively avoids the dilemma of discovering problems halfway through transaction execution in traditional solutions, significantly advancing the discovery time of potential conflicts and providing an important guarantee for the safe execution of medical business.

[0035] Pre-check response aggregation and distributed lock acquisition are used to ensure transaction consistency. The server sets a special response collector to aggregate the pre-check response results from all participants. The collection process adopts an asynchronous waiting mechanism, sets a reasonable timeout threshold (usually 5-10 seconds, adjusted according to the urgency of medical business), and ensures that all responses are obtained within a limited time. The response aggregation algorithm will check the response status of each participant one by one, and only when all participants' pre-check responses are identified as successful, the transaction can enter the next phase. Once it is confirmed that all pre-check responses are successful, the server immediately starts the distributed lock acquisition process.

[0036] Figure 3 A distributed lock mechanism based on a transient state vector is shown in the schematic diagram of the embodiment of the application, as shown in Figure 3As shown, the figure depicts a distributed lock service and two concurrent transaction scenarios. Scenario one: state conflict, transaction A (processing resource reservation for surgery ST003) generates a transient state vector V1. Transaction A requests the distributed lock service to create a temporary node on path / locks / V1 and successfully acquires the lock. Almost simultaneously, transaction B (also processing the same resource reservation for surgery ST003) also generates the same transient state vector V1. Transaction B attempts to acquire the lock on path / locks / V1 but fails (or enters the waiting queue) because the lock is already held by transaction A. This mechanism effectively prevents concurrent modification of the same business state, ensuring data consistency. Scenario two: state non-conflict, transaction A still holds the lock on path / locks / V1. At this time, transaction C (processing a completely different business, such as charging 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 path / locks / V2. Since path / locks / V2 is different from / locks / V1, transaction C successfully acquires the lock and can execute in parallel with transaction A. This mechanism implements fine-grained locking, which only mutual exclusion when the business state is truly conflicting, greatly improving the system's concurrent processing capability and resource utilization. The distributed lock service is usually implemented based on mature distributed coordination services such as Zookeeper or etcd, with high availability and strong consistency guarantees. During the lock acquisition process, the server uses the 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 concurrent processing capability. The lock service creates a temporary sequential node with the transient state vector as the path, and determines the lock acquisition state by determining whether the current node is the smallest sequential number node. If the exclusive lock is successfully acquired, it indicates that the current transaction has exclusive execution rights in the same state operation; if the acquisition fails, it indicates that there are concurrent transactions with state conflicts being executed, which need to be waited or canceled. This fine-grained locking mechanism based on state vectors not only guarantees the mutual exclusivity 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.

[0037] The final execution instruction issuance and local transaction submission is the last stage of the entire distributed transaction process, and is also the key link to transform the preparation work in the pre-check stage 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 global unique transaction ID, confirmed business operation parameters, execution time window, rollback plan, etc. The instruction transmission uses a reliable message passing mechanism to ensure that each participant can receive the execution notification, and a retry mechanism and exception handling process are set for transmission failure cases.

[0038] Upon receiving the final execution instruction, each distributed medical service participant initiates the formal commit process of the local transaction. This process includes converting the temporary state locked in the pre-check stage to a persistent state, such as converting a drug reservation to a formal outbound, converting a blood reservation to an actual allocation, converting a device reservation to a formal occupation, etc. The state conversion adopts an atomic operation mechanism to ensure complete success or complete failure, without intermediate states. At the same time, the participant releases the local resource locks obtained in the pre-check stage, including database row locks, memory cache locks, file system locks, etc., so that these resources can serve other transaction requests. The entire commit process also includes the recording of the local transaction log, which details the execution time, operation content, and affected data of the transaction, providing complete data support for subsequent auditing, tracing, and fault recovery. Through this design, not only is the strong consistency of distributed transactions ensured, but also technical support is provided for the traceability and compliance requirements of medical business.

[0039] In this embodiment, the introduction of the pre-check verification mechanism changes the timing mode of traditional transaction processing, moving the consistency check from the middle of transaction execution to before transaction initiation, effectively addressing the core pain points of short transaction validity window and frequent state changes in medical scenarios. This front-end verification avoids transaction rollback due to resource conflicts in critical medical processes such as surgery and emergency care, significantly reducing the risk of medical accidents. The transient state vector technology accurately captures the dynamic changes in business states such as drug inventory, blood reserves, device status, and personnel scheduling in the medical system through encryption hash algorithms, creating an efficient state snapshot mechanism to ensure strong consistency verification of state information between participants. The distributed lock mechanism based on state vectors enables fine-grained resource control, which can be differentiated according to specific business state characteristics compared to traditional global locking methods, significantly improving system concurrency processing capability, allowing multiple non-conflicting medical transactions to be executed simultaneously, and effectively improving medical resource utilization efficiency. In addition, the parallel distribution of pre-check requests and the atomic state conversion mechanism significantly shorten the 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 foundation for the reliable operation of medical information systems, but also makes an important contribution to the improvement of medical service quality and the protection of patient safety.

[0040] In one embodiment of the present embodiment, according to the business operation identifier, the pre-set participant configuration file is parsed and determined to determine the plurality of distributed medical service participants participating in the global transaction, including the following steps: S210, parsing the business operation identifier to obtain a combination of business type and operation type; S220, retrieve the corresponding service mapping table according to the business type and operation type combination in the participant configuration file; S230, extract the participant service list from the service mapping table; S240, determine the multiple distributed medical service participants participating in the global transaction according to the participant service list.

[0041] In the medical information integration system, the business operation identifier adopts a hierarchical coding structure, usually following the format specification of "business type_operation type_sequence number", for example, "SURGERY_PREP_001" represents the first operation of the surgery preparation type. The parsing process uses a string splitting algorithm to split the complete business operation identifier into independent components using the underscore as the separator.

[0042] In specific implementation, the parser uses regular expression matching technology, the pattern is "([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 above "SURGERY_PREP_001" identifier, the parsing gets the business type as "SURGERY", the operation type as "PREP", and the sequence number as "001". Then combine the business type and operation type to form the type combination identifier "SURGERY_PREP". This combination ensures accurate classification of medical services, allowing accurate identification of different types of medical services such as surgery preparation, emergency rescue, outpatient treatment, and inpatient management.

[0043] The parsing process also includes a legality verification mechanism to check if the identifier format conforms to the predefined specification. For identifiers that do not meet the format requirements, an exception handling process is triggered. Through this structured parsing method, not only the accuracy of business classification is ensured, but also standardized input parameters are provided for subsequent service mapping lookup, effectively improving the reliability and efficiency of the entire participant determination process.

[0044] The participant configuration file is stored in hierarchical XML or JSON format, and the internal structure is organized according to the double index of business type and operation type. The top-level structure of the configuration file contains multiple business domains, such as surgery domain, emergency domain, outpatient domain, etc. Each business domain is further subdivided into specific operation type branches. The retrieval process navigates the hierarchical configuration file according to the business type and operation type combination obtained in the previous steps.

[0045] In practice, the retrieval algorithm uses a tree-like traversal strategy, starting from the root node, locating the corresponding business type node, and then searching for matching operation type subnodes under that node. For example, for the "SURGERY_PREP" combination, the retriever 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 type and operation type combinations into memory, reducing retrieval time complexity to O(1).

[0046] The retrieval process also incorporates a fault-tolerance mechanism. When an exact match fails, a fuzzy matching strategy is invoked, using an edit distance algorithm to find the most similar configuration item. Furthermore, the configuration file supports dynamic updates, enabling real-time configuration 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 mapping table contains information about all distributed services required to process a specific medical service, laying the foundation for the subsequent service list extraction.

[0047] The service mapping table is stored in a structured data format. Each mapping table entry contains detailed information such as the 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 required service entries are present and correctly configured. For a surgical preparation service, a typical service mapping table might include surgery scheduling, anesthesia management, drug inventory, blood bank management, equipment management, and billing services.

[0048] The extraction algorithm traverses each service entry in the mapping table and selects services based on their enabled status, priority settings, and current availability. This is done through a multi-dimensional evaluation mechanism: It checks the basic availability of services, verifying their online status through heartbeat monitoring or health check interfaces; assesses the load on services to avoid selecting overloaded service instances; and considers the business priority of services to ensure that critical services are prioritized.

[0049] The extraction process also supports a service substitution mechanism. When the primary service becomes unavailable, a backup service or a similar alternative 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 excellent fault tolerance and scalability.

[0050] After obtaining the list of participant services, further verification, optimization, and confirmation are required. The determination process performs real-time status checks on each service in the list, including network connectivity tests, service responsiveness verification, and resource availability assessment. A parallel checking mechanism is implemented, sending lightweight status query requests to all candidate services simultaneously. The requests contain basic service identification and timestamp information, and the response time is typically controlled within 100 milliseconds. For services that respond normally, they are marked as available; for services that respond with a timeout or return an error, they are marked as unavailable and removed from the candidate list.

[0051] Next, service dependency analysis is performed. In some medical services, there are strong dependencies between services, such as the drug management service depending on the inventory query service, the blood bank management service depending on the blood matching service, etc. The analysis process constructs a service dependency graph and uses a topological sorting algorithm to ensure that dependent services can 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 current load, historical performance data, and geographic location, etc.

[0052] The final participant list not only contains basic information about the services, but also contains execution parameters such as role definition, execution weight, timeout settings, and retry strategies for each service. The determination result is stored persistently, used for subsequent transaction execution tracking and auditing. Through this multi-level verification and optimization mechanism, it ensures that all medical services participating in distributed transactions have execution conditions and performance guarantees, laying a solid foundation for reliable execution of medical services.

[0053] In this embodiment, the structured business operation identification 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, effectively solving the problems of ambiguous business types and inaccurate participant selection in traditional methods. The hierarchical retrieval mechanism based on business type combination significantly improves the search efficiency of service mapping, optimizing the retrieval time from traditional linear search O(n) to constant level O(1) through hash caching and tree traversal optimization strategies, 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 the services participating in the transaction have the best execution conditions, effectively avoiding transaction failures caused by improper service selection. Real-time state checking and dependency analysis mechanisms provide important safeguards for the reliable execution of distributed medical transactions, ensuring service quality and execution efficiency through parallel verification and intelligent optimization. The entire participant determination process not only improves the automation level of medical information systems, but also enhances the fault tolerance and scalability of the system. When new medical services or business types are introduced, only the configuration file needs to be updated for seamless integration without modifying the core processing logic. This design provides strong technical support for the informatization construction and digital transformation of medical institutions, effectively promoting the improvement of medical service quality and the optimization of medical resources.

[0054] In one embodiment of the present embodiment, the key business state parameters are combined and encrypted hash operation according to the business operation identification to construct the instantaneous state vector, including the following steps: S310, retrieving the business rules corresponding to the business operation identification in the pre-configured business rule library; S320, parsing the key parameter definitions affecting transaction execution from the business rules; S330, extracting parameter key names according to the key parameter definitions, and obtaining a key name list according to a pre-set priority order; S340, extracting values corresponding to the key name list from the global transaction request to obtain a key-value pair set; S350, sorting and concatenating the key-value pair set to obtain a string; S360, concatenating the string with the globally unique transaction ID to obtain a combined string; S370, performing a first hash operation on the combined string using the SHA-256 hash algorithm to obtain an initial hash value; S380, appending the current timestamp to the initial hash value and performing a second hash operation to obtain a time-sensitive hash value; S390, Base64 encodes the time-sensitive hash value to obtain an encoded hash value, and takes the encoded hash value as the instantaneous state vector.

[0055] When retrieving the business rule corresponding to the business operation identifier in the pre-configured business rule library, the business rule library adopts a hierarchical storage architecture, including a rule definition layer, a rule index layer, and a rule cache layer. The rule definition layer stores detailed rule configurations of various medical businesses in XML or JSON format, and each rule item contains complete information such as applicable business operation identifier, key parameter definition, constraint condition, priority setting, and validity period. The rule index layer establishes a fast mapping relationship from the business operation identifier to the specific rule, and realizes fast search with O(log n) time complexity by using B+ tree index structure.

[0056] In specific implementation, the retrieval process standardizes the input business operation identifier, removes redundant spaces, converts case, and verifies format legality. Then, accurate matching search is performed in the rule index, and the retriever adopts prefix matching strategy to support hierarchical matching from specific to general. For example, for the identifier "SURGERY_PREP_001", first try to match it accurately, if not found, try to match the "SURGERY_PREP_ " wildcard rule, and finally try to match the "SURGERY_ " general rule.

[0057] The retrieval process also includes rule validity verification to ensure that the returned rule is valid at the current time point and has not been marked as obsolete. In order to improve the retrieval performance, the rule cache layer adopts LRU (Least Recently Used) strategy to cache hot rules, reducing the retrieval time of frequently used rules to milliseconds. The retrieval result contains a complete business rule object, which not only defines the key parameters affecting transaction execution, but also contains important information such as parameter dependency, constraint condition, and processing priority, providing comprehensive guidance for subsequent parameter analysis.

[0058] The structured parameter definition format is adopted inside the business rule, and each parameter definition contains parameter name, data type, value range, importance level, dependency relationship, and change sensitivity. The parsing process performs syntax analysis on the business rule to identify all parameter definition blocks, and then parses the detailed attributes of each parameter one by one. For the business rule of surgery preparation type, the typical key parameters include patient basic information, surgery related parameters, resource demand parameters, personnel configuration parameters, etc.

[0059] The parsing algorithm uses recursive descent analysis technology and can handle nested parameter definitions and complex constraint expressions. In implementation, the parser classifies parameters according to their importance levels, dividing them into three levels: core parameters, important parameters, and auxiliary parameters. Core parameters are key factors that directly affect the executability of transactions, such as patient ID and surgery type. Important parameters are important factors that affect the execution effect of transactions, such as surgery duration and resource demand. Auxiliary parameters are factors that provide additional information but do not directly affect execution, such as notes and historical records.

[0060] The parsing process also identifies dependencies between parameters and constructs a parameter dependency graph to ensure that the correlation between parameters is correctly handled in subsequent processing. The parsing result forms a structured parameter definition set, each parameter definition containing not only basic name and type information but also weight coefficients, hash seeds, encoding methods and other technical parameters for state vector construction, providing complete metadata support for accurate state representation.

[0061] The parameter key name extraction process traverses the parameter definition set obtained from the previous step and extracts standardized key name identifiers from each parameter definition. Key name standardization adopts a unified naming specification, usually following the format "domain_name_category_attribute", such as "patient_basic_id". The extraction process also includes a key name verification mechanism to ensure that all key names conform to the predefined naming specification, and non-compliant key names will be automatically corrected or marked as exceptions.

[0062] The sorting process is based on a multi-level priority strategy, sorting parameters according to their importance levels, with core parameters having the highest priority, important parameters second, and auxiliary parameters lowest. Within the same importance level, parameters are sorted according to their change sensitivity, with high change sensitivity parameters ranked first. Finally, parameters are sorted according to their lexicographical order to ensure the stability and reproducibility of the sorting result.

[0063] In implementation, the sorting algorithm uses stable multi-key sorting technology to ensure that parameters with the same priority maintain the same relative position in multiple sorting. The sorting process also considers the business semantics of parameters, such as patient identity information usually having higher priority than auxiliary information, and resource demand information being more important than historical record information. The sorting result forms an ordered key name list, and the order of this list directly affects the generation result of the subsequent state vector. Through fixed sorting rules, the state vector generated at different times for the same business state has consistency, which is crucial for state comparison and conflict detection in a distributed environment.

[0064] The global transaction request is usually encapsulated in a structured data format such as JSON, XML, or ProtocolBuffers, containing all the parameter information required to execute a specific medical business. The extraction process performs format verification and integrity check on the global transaction request to ensure that the request data is structured correctly and contains all the required fields. Then, according to the key name list obtained in the previous step, the corresponding data values are found one by one in the transaction request.

[0065] The search process adopts a multi-level matching strategy, trying to match the key name accurately, and if not found, trying to match the synonym and fuzzy match. For example, for the key name "patient_basic_id", if the field is not found in the request, it will try to find "patientId", "patient_identifier", "pid", and other possible synonym fields. The extraction process also includes data type conversion and format standardization to ensure that all extracted values meet the predefined data format requirements. For numerical type parameters, precision standardization is performed; for string type parameters, case normalization and special character processing are performed; for date and time type parameters, conversion to a unified time format is performed.

[0066] In the extraction process, if missing required parameters are found, default value filling or exception handling process is triggered according to business rules. After extraction, a complete set of key-value pairs is formed, each containing a standardized key name and corresponding data value. These key-value pairs are organized in the order of the key name list, ensuring consistency and predictability of subsequent processing.

[0067] As described in detail in the previous S130 step, the process of sorting and splicing the key-value pair set uses a fixed splicing format, formats each key-value pair as "key name: value" in the order of the key name list, and then uses the pipe symbol "|" to connect, forming a standardized parameter string, ensuring that the same business state can generate consistent string representations. The process of splicing the parameter string with the globally unique transaction ID forms a combined string containing business state information and transaction identification by adding the transaction ID at the end of the parameter string, providing complete input data for subsequent hash operations. The process of using the SHA-256 hash algorithm to perform the first hash operation on the combined string converts the variable-length combined string to a fixed-length 256-bit hash value using the standard SHA-256 algorithm, ensuring the uniqueness and irreversibility of the state representation.

[0068] As has been described in detail in the foregoing S130 step, the process of appending the current time stamp accurate to milliseconds after the initial hash value and performing a second SHA-256 hash operation generates a hash value with time-sensitive characteristics, effectively preventing replay attacks and enhancing the timeliness of the state vector. In addition to this, the process of Base64 encoding the time-sensitive hash value converts the binary hash value into a readable string format, generating the final instantaneous state vector, which has good transmission and storage properties and is suitable for state comparison and verification in a distributed environment.

[0069] In this embodiment, the intelligent retrieval and analysis mechanism based on the 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, effectively solving the problem of inaccurate and incomplete state representation in traditional solutions. The structured parameter extraction and standardization process ensures the consistency and integrity of the state data, and through the multi-level verification and conversion mechanism, it ensures that business data from different systems and different formats can be uniformly processed and represented. The parameter sorting based on priority and the fixed format string concatenation mechanism ensure the reproducibility of the state vector generation, and the same business state can generate the same intermediate representation at any time, providing a reliable foundation for state consistency checking in a distributed environment. The double hash encryption and timestamp mechanism not only ensures the uniqueness and unforgeability of the state vector, but also adds time-sensitive features, effectively preventing the misuse of expired states and malicious replay attacks. The entire instantaneous state vector construction process has high automation and intelligence characteristics, and can adapt to the complexity and dynamics of medical services, providing accurate state awareness for distributed transaction processing of 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, and has important significance for promoting the in-depth development of medical informatization and ensuring the high-quality operation of medical services.

[0070] In one of the implementation manners of the embodiment, each distributed medical service participant is configured to perform executability verification on the transaction pre-check request in the pre-check stage and generate a pre-check response, including the following steps: S410, for each distributed medical service participant, receiving and analyzing the transaction pre-check request in the pre-check stage to obtain a globally unique transaction ID and an instantaneous state vector; S420, according to the globally unique transaction ID, checking the local transaction log to confirm whether there is a duplicate transaction request; S430, based on the instantaneous state vector, verifying whether the current local data state meets the precondition of transaction execution; S440, check local resource availability to confirm whether the transaction operation can be completed, wherein the local resources include database connections, memory space and computing resources; S450, in the case where there is no repeated transaction request, the current local data state satisfies the precondition of transaction execution, and the transaction operation can be completed, reserve local resources and generate a pre-check response containing a success identifier, otherwise generate a pre-check response containing a failure reason.

[0071] When the distributed medical service participants receive and parse the transaction pre-check request, each participant deploys a dedicated pre-check request listening service, adopts a multi-thread asynchronous processing mode, and can simultaneously process concurrent requests from multiple transaction coordinators. The listening service is implemented based on TCP long connection or HTTP / 2 protocol, ensuring the reliability and low delay characteristics of network communication. When the participant receives the transaction pre-check request, message format verification is performed to confirm the integrity and legality of the request data.

[0072] The parsing process adopts a streaming parsing technology to avoid memory overflow problems caused by large amounts of data requests. In specific implementation, the parser extracts key information in the request field by field according to the pre-defined message format specification. The extraction of the globally unique transaction ID is implemented by searching the fixed message header field, and after extraction, format verification is performed to ensure that the ID meets the UUID standard format requirements. The extraction of the instantaneous state vector needs to process the Base64 encoded hash string, and the parsing process includes encoding verification, length checking and character legality verification.

[0073] The parsing process also includes a timestamp verification mechanism to ensure that the received pre-check request is within a valid time window, and expired requests will be directly rejected. In order to improve parsing efficiency, the participant adopts a message caching and reuse mechanism, and for the same request type, the parsing template will be reused to reduce repeated parsing overhead. After parsing is completed, the participant will generate an internal pre-check task object, which contains the extracted global transaction ID, instantaneous state vector and other related execution parameters, providing standardized input data for the subsequent verification process. This efficient receiving and parsing mechanism ensures that the distributed medical service can quickly respond to the pre-check request of the transaction coordinator, providing an important guarantee for the timeliness of the entire distributed transaction.

[0074] The local transaction log adopts a high-performance persistent storage system, usually implemented based on a storage engine with LSM-Tree structure, supporting high-concurrency read-write operations and fast range queries. The transaction log record contains complete life cycle information such as transaction ID, execution status, start time, completion time, execution result, etc. The checking process is performed in the main index of the transaction log, which is constructed based on B+ tree structure, and can complete the lookup operation within O(log n) time complexity.

[0075] In implementation, 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 found to be in execution (state RUNNING), it indicates a concurrent conflict, and the current request needs to be rejected; if the transaction ID corresponds to a historical record with a state of COMPLETED or FAILED, it means that the transaction has already been processed, and similarly, the repeated execution needs to be rejected. The checking process also includes time window verification, which ensures that there is a sufficient time interval between the current request and the similar historical request, preventing abnormal high-frequency repeated requests, even if the transaction ID is not repeated.

[0076] To optimize the checking performance, the participant maintains an in-memory cache based on the LRU strategy, saving the recently processed transaction IDs in memory, which greatly improves the checking speed in common cases. The checking process also supports cross-instance deduplication in distributed scenarios, by sharing transaction state information with other service instances, preventing repeated execution problems in load balancing environments. The checking results are recorded in the audit log, including checking time, result status, related historical record information, etc., providing detailed tracking data for subsequent problem diagnosis and system monitoring. Through this comprehensive repeated checking mechanism, repeated operations in medical business are effectively prevented, avoiding repeated medication, repeated charging, repeated examination, and other abnormal situations that may harm patients.

[0077] The verification process needs to parse the instantaneous state vector and restore the feature information of the key business state parameters from the Base64 encoded hash value through reverse engineering. Although the hash operation is irreversible, the participant can judge the state consistency through comparison verification. In implementation, the participant extracts the business operation identifier and parameter features from the received instantaneous state vector, and then queries the local data storage system to obtain the real-time state of the current related business data.

[0078] The verification process includes multiple levels of checks: data existence verification, confirming that the core business data required by the transaction (such as patient records, drug information, device 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 the version number, modification timestamp, or checksum of the data; business rule compliance verification, checking whether the current data state meets the prerequisites for business execution, such as whether the drug inventory is sufficient, whether the device is available, whether the patient's state is appropriate, etc.

[0079] The verification process also includes a data lock state check to confirm that the relevant data records are not locked or occupied by other transactions. To ensure the atomicity of the verification, the entire check process is performed under the protection of the database transaction, preventing changes in the data state during verification. The verification result is divided into three states: VALID indicates that all preconditions are met, INVALID indicates that there are unsatisfied conditions, and UNCERTAIN indicates that the state cannot be determined due to system load or network problems. For INVALID and UNCERTAIN states, the participants generate detailed error reports explaining the specific failure reasons and recommended handling measures, providing complete state feedback information for the transaction coordinator's decision.

[0080] The resource check process adopts a multi-level evaluation strategy to perform basic resource availability checks, including CPU utilization, memory usage, disk space occupation, network bandwidth, and other system-level indicators. In specific implementation, the check process obtains real-time resource usage data through system calls, CPU utilization checks ensure that the current processor load is below the preset threshold (usually 80%), reserving sufficient computing power for transaction execution; memory space checks not only confirm that there is sufficient available memory, but also evaluate memory fragmentation and cache hit rate to ensure that memory shortage does not occur during transaction execution.

[0081] The database connection check verifies the number of available connections in the connection pool, the health status of the connection, the response time of the database server, and other key indicators. The check process creates a test connection and performs a simple query operation to verify the availability and performance of the database service. For resources specific to medical business, such as professional medical device interfaces, external system connections, and special data format processing capabilities, special availability checks are also required.

[0082] Resource checks also include business-level capacity evaluation, which predicts the required resource consumption based on the expected execution complexity and data volume of the transaction, and compares it with the current available resources. The check process uses a dynamic threshold adjustment mechanism to intelligently adjust the resource sufficiency judgment standard based on historical execution data and current system load. To avoid excessive burden on the system caused by resource checks, the check process uses sampling and caching mechanisms, using cached data for slowly changing resource indicators and real-time sampling for rapidly changing indicators. The check results are generated in a structured report format, containing detailed information such as the current state of various resources, availability, and the size of transactions that can be supported, providing a comprehensive resource status evaluation for the participants' pre-check decisions.

[0083] The response generation process summarizes the results of the aforementioned checks, including repeatability checks, state verification checks, resource availability checks, and feedback information from all verification links. The summary process uses logical AND operation. Only when all checks return success, the overall pre-check is determined to be successful. In specific implementation, if the pre-check is successful, the participant will immediately start the resource reservation process, which is an important step to ensure the success of subsequent transaction execution.

[0084] Resource reservation includes multiple levels of operations: at the database level, a reservation lock is added to the relevant data records to prevent other transactions from modifying these data; at the memory level, the cache space and processing buffer required for transaction execution are pre-allocated; at the connection level, a database connection is reserved from the connection pool to ensure sufficient connection resources for transaction execution; at the business level, specific medical resources (such as drugs, blood, equipment, etc.) are temporarily reserved to prevent resources from being occupied by other transactions. The reservation process sets a reasonable timeout mechanism, usually 30-60 seconds, and automatically releases the reserved resources after timeout to avoid long-term resource occupation.

[0085] A successful pre-check response contains success identifier, reserved resource list, estimated execution time, maximum waiting time, and other information, providing reference for subsequent decision-making of the transaction coordinator. If any check fails, the participant will generate a response containing detailed failure reasons, including specific error type, error code, error description, suggested solution, retry feasibility assessment, and other complete information. The failure response also contains snapshot information of the current system state, helping the transaction coordinator understand the specific reasons for failure and the current load of the system. The response generation process also includes response message formatting and encryption to ensure the integrity and security of the response data. The generated response is sent to the transaction coordinator through a reliable network channel, and an acknowledgement mechanism is set to ensure that the response message is successfully delivered.

[0086] In this embodiment, the standardized request receiving and parsing process ensures that different types of medical services can uniformly handle pre-check requests from the transaction coordinator. Through the high-performance asynchronous processing mechanism, the system's concurrent processing capacity and response speed are greatly improved. The transaction log-based duplicate check mechanism effectively prevents the risk of repeated operations in medical business, avoiding repeated medication, repeated examination, and repeated billing, which may cause harm or economic loss to patients, providing an important guarantee for medical safety. The data state verification mechanism based on the instantaneous state vector realizes accurate business state consistency checking, which can discover potential state conflicts before transaction execution, avoiding the dilemma of discovering problems halfway through transaction execution in traditional solutions, and greatly reducing the risk of medical accidents. The multi-dimensional resource availability check and intelligent resource reservation mechanism ensures the reliability and efficiency of transaction execution. Through dynamic resource evaluation and reservation strategies, the system resource utilization efficiency is maximized, while ensuring the priority execution right of critical medical business. The entire pre-check verification process not only improves the success rate and execution efficiency of distributed medical transactions, but also enhances the fault tolerance and self-adaptation of the system. When facing high-concurrency medical business requests or complex resource competition situations, the 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.

[0087] In one embodiment of the present embodiment, based on the instantaneous state vector, it is verified whether the current local data state satisfies the precondition of transaction execution, including the following steps: S510, parse the instantaneous state vector to obtain the key business state parameter; S520, according to the key business state parameter, query the current state of the corresponding data record in the local data storage; S530, compare the current state with the key business state parameter to determine whether the data version is consistent, and verify whether the local data record is locked by other transactions; S540, in the case that the data version is consistent and not locked by other transactions, it is determined that the current local data state satisfies the precondition of transaction execution.

[0088] The analysis of the instantaneous state vector reconstructs the key business state parameters through pre-stored business rules and parameter mapping relationships. Although the instantaneous state vector is generated through irreversible hash operation, the analysis process can reconstruct key business state parameters through pre-stored business rules and parameter mapping relationships. In specific implementation, the parser decodes the Base64 encoded instantaneous state vector to obtain the original hash byte sequence. Then, by matching with the locally stored business rule library, the business operation type and parameter structure corresponding to the state vector are determined.

[0089] The analysis process adopts pattern matching technology, and according to the generation time stamp of the state vector and the business context information, the corresponding parameter definition template is located in the business rule library. The parameter reconstruction process includes parameter key name extraction, data type inference, value range determination and other links. For medical business scenarios, typical key business state parameters include patient identifier, medical resource demand, operation time window, execution priority and other core information.

[0090] The analysis process also needs to handle the parameter hierarchy and dependency relationship, and some composite parameters need to be further decomposed into basic parameter items. In order to ensure the accuracy of analysis, the parser adopts multiple verification mechanisms, including parameter integrity check, data type check, value range verification and other links. The analysis process also supports vector version compatibility processing, which can handle state vectors generated by different versions of business rules. The analysis result is output in the form of structured parameter object, each parameter contains name, type, value, priority, verification rule and other complete metadata information. This intelligent analysis mechanism ensures that even in complex medical business scenarios, all key state parameters that affect transaction execution can be accurately extracted, providing a reliable data foundation for subsequent state verification.

[0091] Local data storage usually adopts multi-layer storage architecture, including relational database, cache layer, index service and other components, and the query process needs to comprehensively utilize these storage resources to realize efficient data retrieval. In specific implementation, the query process constructs query conditions according to key business state parameters, and converts parameters into corresponding SQL statements, NoSQL query expressions or cache key values. For patient-related parameters, the query process will access patient basic information table, medical record table, current state table and other data sources; for medical resource related parameters, it will query equipment state table, drug inventory table, blood reserve table, personnel scheduling table and other professional data tables.

[0092] The query optimizer selects the optimal query path and index strategy based on the importance of parameters and query frequency. For high-frequency access to key data, it is preferred to obtain from the memory cache; for data with high real-time requirements, directly access the main database; for historical data or statistical information, it can be obtained from the data warehouse or read-only copy. The query process uses parallel query technology, and for independent parameters, the query operation can be performed in parallel to improve overall query efficiency.

[0093] The query result includes the complete content of the data record, version information, last modification time, modification user, lock state and other metadata. In order to ensure data consistency, the query process is executed under the protection of transaction isolation level to prevent data from being modified by other transactions during the query period. The query process also includes data integrity verification to confirm that the queried data record meets the expected format and constraint conditions. For query failure or data missing, the query process will generate a detailed error report, including failure reason, impact range, and recommended handling measures.

[0094] As partially described in the previous S430 step, the comparison process of the current state and the key business state parameter adopts a multi-dimensional consistency verification strategy. In specific implementation, the comparison process not only includes accurate matching of data content, but also covers verification of multiple dimensions such as data version, timestamp, checksum, etc. Data version consistency check confirms 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 parameter. Version comparison adopts semantic version control strategy, supporting hierarchical comparison of major version number, minor version number and revision version number.

[0095] Timestamp verification ensures that the last modification time of the local data is within an acceptable time window, and excessively old data will be marked as inconsistent. Lock state verification needs to check whether the related data record is holding an exclusive lock or a shared lock by other transactions. Lock check includes row-level lock, table-level lock, application-level lock and other multi-level lock state verification. For distributed locks, it also needs to verify the distributed consistency and validity of the lock.

[0096] The comparison process also includes business rule compliance verification to confirm that the current data state meets the execution prerequisites of business logic. For example, for surgical business, it needs to verify that the patient state is suitable for surgery, the operating room is available, the medical staff is on site, and other business conditions. The comparison result is output in the form of Boolean value and detailed report, providing accurate basis for the final precondition judgment.

[0097] The implementation of determining that the current local data state meets the transaction execution precondition under the condition that the data version is consistent and is not locked by other transactions is based on a comprehensive evaluation and logical reasoning mechanism, which needs to comprehensively consider the results of the foregoing checks and special requirements of business rules. In specific implementation, the decision-making process summarizes the results of the comparison checks in the foregoing steps, and adopts a weighted scoring mechanism to differentially process the importance of different check items. The consistency check of the core business parameters has the highest weight, the resource availability check is next, and the check weight of the auxiliary parameters is relatively low.

[0098] The decision-making algorithm adopts a combination of threshold judgment and expert rules, which not only requires that all key check items pass, but also ensures that the comprehensive score reaches a preset safety threshold. The decision-making process also includes a risk assessment link, which analyzes the risk factors that may be faced in executing the transaction under the current state, such as data competition risk, resource conflict risk, and business logic conflict risk. For high-risk situations, even if the technical check passes, it may be determined as not meeting the precondition.

[0099] The decision-making process supports a multi-level decision-making mechanism, which can trigger manual review or expert system intervention for boundary conditions or complex scenarios. The final decision result includes explicit meet / don't meet judgment, detailed decision basis, risk assessment report, execution suggestion, and other complete information. The decision-making process also generates a decision audit log, which records the time, basis, process, result, and other information 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 only in the safest and most reliable conditions, the distributed medical transaction will be allowed to execute, maximizing the safety and reliability of medical business.

[0100] In this embodiment, the intelligent state vector analysis technology breaks through the limitation of the irreversibility of hash operation, accurately reconstructs the key business state parameters through business rule base and pattern matching technology, provides complete parameter basis for subsequent verification, and effectively solves the technical problems of state information transmission and analysis in distributed environment. The multi-dimensional local data query mechanism fully utilizes the advantages of modern data storage architecture, realizes millisecond-level fast data retrieval through cache layer, index optimization, parallel query and other technical means, greatly improves the response speed of state verification, and meets the strict requirements of medical business on real-time. The comprehensive state comparison and locking verification mechanism not only ensures the strict consistency of data version, but also effectively prevents resource conflicts between concurrent transactions. Through multi-level lock state checking and business rule verification, the unexpected risks in the transaction execution process are maximized. The scientific precondition judgment mechanism adopts advanced decision support technologies such as weighted scoring, risk assessment and multi-level decision-making to ensure that transactions are only allowed to execute under the safest and most reliable conditions, providing a solid guarantee for the safety of medical business. The entire verification process has high automation and intelligence characteristics, and can adapt to complex and variable medical business scenarios, supporting state verification requirements of 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 rollback and resource waste caused by inconsistent states, providing strong technical support for the digital transformation and intelligent upgrading of medical institutions. It 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.

[0101] In one of the implementation manners of the embodiment, under the condition that all pre-check responses are successful responses, the transient state vector is used as a lock identifier to obtain an exclusive lock in the distributed lock service, including the following steps: S610, creating a lock request including the transient state vector under the condition that all pre-check responses are successful responses; S620, sending the lock request to the distributed lock service, wherein the distributed lock service uses the transient state vector as a lock path to create a temporary sequential node; S630, determining whether the temporary sequential node is a minimum sequence number node; S640, if the temporary sequential node is the minimum sequence number node, obtaining an exclusive lock in the distributed lock service.

[0102] Under the condition that all pre-check responses are successful responses, the creation of a lock request including a transient state vector is based on a structured data packaging and a secure transmission protocol, ensuring the integrity and uniqueness of the lock identification information. In implementation, the lock request creation process aggregates all pre-check successful responses returned by the participants, verifies the integrity and consistency of the responses, and confirms that each participant has the ability and resources to execute the transaction. The creation process uses a standardized lock request data structure, which includes core fields such as the transient state vector, global transaction ID, request timestamp, lock type identification, timeout setting, priority, and other key information.

[0103] The transient state vector, as the core component of lock identification, ensures that transactions with the same business state characteristics compete for the same lock resource, while transactions with different states can be executed in parallel. The lock request also includes additional metadata information, such as the request initiator's identity, business type identification, expected execution duration, resource requirement list, etc., providing a reference basis for intelligent scheduling of distributed lock services. The creation process uses digital signature technology to ensure the non-tamperability of the request and prevent data damage during network transmission.

[0104] The format of the lock request uses compact binary encoding or standardized JSON format, taking into account the transmission efficiency and readability requirements. The creation process also includes request validity verification, ensuring that the transient state vector is correctly formatted, the timestamp is within the valid range, and the business parameters meet the expected constraints. To improve the efficiency of request processing, the creation process supports batch request mode, which allows multiple related transactions to obtain locks by sending requests in batches. The created lock request is temporarily stored in the local queue and waits to be sent to the distributed lock service, while starting a timeout monitoring mechanism to prevent the request from being unresponsive for a long time.

[0105] The distributed lock service is usually implemented based on mature distributed coordination systems such as Apache Zookeeper, etcd, or Consul, with strong consistency, high availability, and automatic fault recovery capabilities. In implementation, the lock request sending process uses a reliable network transmission protocol, such as TCP long connection or HTTP / 2, to ensure that the request can accurately and correctly reach the distributed lock service. The sending process includes connection establishment, identity authentication, data transmission, and confirmation of receipt.

[0106] After receiving the request, the distributed lock service parses the transient state vector and uses it as a key component of the lock path. The lock path adopts a hierarchical structure, usually in the format of “ / distributed-locks / medical-tx / {hash-prefix} / {full-vector}”, where hash-prefix is the 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 temporary sequential nodes is a core feature of coordination systems such as Zookeeper, which automatically assigns an incremental sequence number during node creation, ensuring that all requests under the same lock path are uniquely identified by a sequence number.

[0107] The characteristics of temporary nodes ensure that related lock requests are automatically cleaned up when the client connection is disconnected or abnormally exited, avoiding the problem of deadlocks. The characteristics of sequential nodes ensure the fairness of lock acquisition, with the first arriving request obtaining a smaller sequence number and having a higher lock acquisition priority. The node creation process also records detailed information of the request, including request time, client identification, business type, and other metadata, providing complete audit information for lock management and monitoring. After creation, the distributed lock service returns the complete path and sequence number information of the node, providing the basis for subsequent lock state judgment.

[0108] The process of determining whether the temporary sequential node is the minimum sequence number node is based on the sequential node feature of Zookeeper to achieve a fair lock competition mechanism. In specific implementation, the judgment process queries all temporary sequential nodes under the current lock path to obtain the complete node list and corresponding sequence number information. The query operation is implemented through the API interface of the distributed lock service, such as the getChildren() method of Zookeeper, which returns the name and basic attributes of all child nodes.

[0109] The node sequence number extraction process parses the sequence number suffix in the node name, usually in the format of “lock-{sequence-number}”, and obtains the actual sequence number value through string processing and numerical conversion. The sequence number comparison uses numerical sorting algorithm to determine the relative position of the current node among all active nodes. The judgment process needs to consider the life cycle state of the node, filtering out nodes that have been invalidated or are being deleted, to ensure the accuracy of the comparison result.

[0110] To handle network latency and timing issues, the judgment process adopts a multi-round verification mechanism, with a secondary confirmation after the initial judgment to prevent misjudgments caused by network jitter or node state changes. The judgment process also includes an exception handling mechanism that triggers a retry process or error reporting when encountering exceptions such as network timeouts, unavailable services, or inconsistent data. For edge cases such as nodes with the same sequence number created simultaneously, the judgment process introduces additional tie-breaking rules such as node creation timestamps, client identifier hash values, etc., to ensure the uniqueness and certainty of the judgment result.

[0111] The judgment result not only includes a Boolean value indicating whether it is the smallest sequence number, but also includes detailed information such as the current node's queue position, the previous node's identifier, and the estimated waiting time, providing complete state feedback for the client's subsequent processing. This sequence-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.

[0112] As described in the aforementioned S150 step, when the temporary sequence node is confirmed as the smallest sequence number node, it indicates that the current transaction has obtained an exclusive lock based on the instantaneous state vector, with the right to execute exclusively. In specific implementation, the process of acquiring an exclusive lock includes lock state confirmation, lock information recording, timeout setting, and monitoring start. The lock state confirmation process verifies the validity and exclusivity of the node again to ensure that no other client has obtained the same lock simultaneously.

[0113] Lock information recording persists key information such as lock acquisition time, holder identifier, lock identifier, and expected release time, providing data support for lock management and fault recovery. Timeout setting sets a reasonable timeout threshold for the lock based on the transaction's expected execution time and system configuration parameters, preventing long-term lock occupation caused by client exceptions. Monitoring start creates a dedicated monitoring thread to regularly check the lock's state and the client's health status, achieving automatic lock management and exception recovery. After 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 lock mechanism based on state vectors not only ensures transaction exclusivity but also enables parallel execution of different state transactions, significantly improving the system's concurrent processing capacity and resource utilization efficiency.

[0114] In this embodiment, the structured lock request creation mechanism ensures the integrity and security of the lock identification information, effectively prevents malicious requests and data tampering through digital signature and format verification technology, and provides trusted request input for distributed lock services. The temporary sequential node creation mechanism based on mature distributed coordination systems fully utilizes the strong consistency and high availability features of systems such as Zookeeper, and through automatic serial number allocation and temporary node features, it realizes fair lock competition and automatic deadlock prevention. The minimum node judgment mechanism based on serial number comparison ensures the fairness and orderliness of lock acquisition, avoiding the common starvation and priority inversion problems in traditional lock mechanisms, ensuring that all transaction requests can get a fair opportunity for processing. The fine-grained exclusive lock mechanism based on state vectors achieves unprecedented concurrency control granularity, transactions of different business states can be executed in parallel, and transactions of the same business state are strictly mutually exclusive. This design ensures data consistency while maximizing the system's concurrent processing capability. The entire lock acquisition process has high automation and intelligence features, 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, and can effectively coordinate resource competition problems in surgical, emergency, outpatient, and inpatient medical processes, ensuring the rational allocation and safe use of critical medical resources. Through this advanced distributed lock mechanism, not only the efficiency and success rate of medical business are significantly improved, but also the system's scalability and fault tolerance are enhanced, providing strong technical support for the digital transformation and intelligent upgrade of medical institutions, and having important practical value for promoting the improvement of medical service quality and the optimization of medical resource allocation.

[0115] In one embodiment of the present embodiment, the method further comprises the following steps: S710, according to the global transaction request, obtaining the estimated execution time, and calculating the basic timeout duration according to the estimated execution time; S720, based on the preset average execution time, correcting the basic timeout duration to obtain a corrected timeout duration; S730, obtaining the current network delay, and further correcting the corrected timeout duration based on the current network delay to obtain a final duration; S740, setting the final duration as the timeout time of the exclusive lock, and starting a timeout monitoring thread to release the exclusive lock before the final duration is reached.

[0116] When acquiring the estimated execution time and calculating the base timeout duration according to the global transaction request, the acquisition process of the estimated execution time analyzes the business operation identifier, the number of participants, the data size, the operation complexity and other key indicators in the global transaction request. In specific implementation, the estimation algorithm uses a multi-dimensional evaluation model. The business operation identifier determines the basic execution time range. For example, the basic execution time of a simple outpatient registration business is 1-2 seconds, and the basic execution time of a complex operation 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 execution time increases accordingly.

[0117] The data size evaluation uses an empirical formula to predict the time by analyzing factors such as the number of data records involved in the transaction, data transmission volume, and computational complexity. The estimation process also takes into account the urgency and priority of the business. High-priority medical businesses can get more resource allocation and have relatively shorter execution times. The calculation of the base timeout duration uses a safety factor amplification strategy, usually set to 2-3 times the estimated execution time, with the formula: base timeout duration = estimated execution time x safety factor + fixed buffer time.

[0118] The safety factor is dynamically adjusted according to 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. The fixed buffer time is used to deal with unexpected situations and system overhead, usually set to 2-5 seconds. The calculation process also includes boundary value processing to ensure that the timeout duration is not too short (to avoid normal transactions being killed) or too long (to avoid abnormal transactions occupying resources for a long time), and sets reasonable minimum and maximum limits.

[0119] The average execution time data comes from the system's historical execution records, which are classified and counted according to business type, time period, system load and other dimensions. In specific implementation, the correction process queries similar historical transaction records to the current transaction, and similarity is determined based on multiple dimensions such as business operation identifier matching, participant number range, data size level, etc. The historical data statistics use a sliding window mechanism, focusing on the execution situation in the recent period, usually selecting data from the last 7 or 30 days to ensure that the statistical results reflect the current performance status of the system.

[0120] The average execution time calculation uses a weighted average algorithm, giving higher weights to more recent data, with the formula: weighted average time = Σ (execution time i x weight i) / Σ weight i. The correction algorithm uses an adaptive adjustment strategy. When the historical average execution time is significantly less than the estimated execution time, the base timeout duration is reduced moderately 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 increased moderately to improve the execution success rate.

[0121] The correction formula is: corrected timeout duration = base timeout duration x (1 + correction factor), wherein the correction factor is dynamically calculated according to the statistical characteristics of historical data, and the range is usually between -0.3 and +0.5. The correction process also considers the confidence and sample size of the data. In the case of sufficient sample size and stable distribution, the correction range can be larger; in the case of insufficient sample size or large fluctuation, the correction range is relatively conservative. The correction process also includes outlier filtering to remove obviously abnormal historical execution records to avoid excessive influence of extreme cases on the correction result.

[0122] The network delay acquisition process adopts a combination of active probing and passive monitoring. Active probing measures the round-trip time by sending lightweight ping or heartbeat messages to each participant to evaluate the network delay. In specific implementation, the network delay measurement adopts a multi-point sampling strategy, simultaneously measuring the network delay to all participants, and taking the average, maximum and standard deviation as comprehensive indicators of network conditions. The measurement process uses parallel probing technology to avoid time accumulation caused by serial measurement. The measurement results include minimum delay, maximum delay, average delay, packet loss rate and other key parameters.

[0123] Passive monitoring establishes a time series model of network delay by analyzing network performance data in historical communication records to predict the current network condition. The network delay correction algorithm is based on the delay influence factor, and the formula is: final duration = corrected timeout duration x (1 + network delay correction coefficient). The network delay correction coefficient is calculated according to the ratio of the current network delay to the baseline delay. When the network delay is significantly higher than the baseline value, the timeout duration is increased to cope with network instability; when the network delay is lower than the baseline value, the timeout duration can be appropriately reduced to improve resource turnover efficiency.

[0124] The correction process also considers the trend of network delay. If the network delay shows a deteriorating trend, the timeout duration will be increased in advance; if the network delay remains stable or improves, the correction will be made according to the current condition. The correction algorithm also includes an adaptive learning mechanism that dynamically adjusts the correction strategy and parameters based on feedback from historical correction effects to achieve self-optimization of the correction algorithm. The final duration also needs to be subjected to a reasonableness test to ensure that the result is within the preset boundary range, avoiding excessive deviation of the timeout duration from the normal range due to network anomalies.

[0125] The timeout setting process configures the final duration calculated into the distributed lock service, usually through the API interface of the lock service to set the timeout parameter. In implementation, the timeout setting adopts a hierarchical management strategy, setting a hard timeout limit at the distributed lock service level and a soft timeout warning at the application level. The hard timeout ensures that the lock resource will not be occupied indefinitely, and when the timeout time is reached, the lock service will forcibly release the lock resource; the soft timeout provides an early warning mechanism, actively releasing the lock before approaching the timeout to avoid being forcibly terminated.

[0126] The start of the timeout monitoring thread adopts an independent thread mode, separated from the main business logic to ensure the stable operation of the monitoring function. The monitoring thread adopts a timing check mechanism, and the check interval is usually set to 5%-10% of the timeout duration, which ensures timely response and avoids excessive consumption of system resources. The monitoring process includes multiple check dimensions: checking the execution progress of the transaction to assess whether it can be completed before the timeout; checking the holding state of the lock to confirm that the lock is still valid and has not been abnormally released; checking the health status of the client to ensure that the lock process is running normally.

[0127] The pre-release mechanism is automatically triggered when the monitoring thread detects that the timeout is approaching, usually starting when the remaining time is less than 10%-20%. The pre-release process includes complete processes such as transaction state checking, resource cleaning, and lock release, ensuring that the lock resource can be given to other waiting transactions in time. The monitoring thread also supports dynamic timeout adjustment functions, which can adjust the remaining timeout time when detecting that the transaction execution progress is ahead of or behind the expected time, achieving more precise resource management. The monitoring process generates detailed log records, including monitoring time points, lock states, transaction progress, adjustment operations, and other information, providing data support for system optimization and problem diagnosis.

[0128] In this embodiment, the prediction algorithm based on business complexity and historical data provides personalized timeout configuration for different types of medical services. Through multi-dimensional evaluation model and safety factor amplification strategy, the timeout length can meet the normal execution demand and effectively prevent resource long-term occupation, effectively solving the problem that traditional fixed timeout strategy cannot adapt to business diversity. The correction mechanism based on historical statistical data fully utilizes the execution experience accumulated during system operation, and through the weighted average algorithm and adaptive adjustment strategy, the timeout setting can dynamically reflect the real performance status of the system, greatly improving the accuracy and rationality of the timeout setting. The dynamic correction mechanism based on network delay effectively responds to the influence of network status changes in a distributed environment. Through the combination of active detection and passive monitoring, the changes in network performance are sensed in time and the timeout strategy is adjusted accordingly, ensuring that distributed transactions can be reliably executed even in unstable network conditions. Independent timeout monitoring and pre-release mechanism provides multi-level resource protection, through the combination of soft and hard timeouts, regular checks, dynamic adjustments and other technical means, the waste of lock resources and deadlock problems are maximized, while ensuring the continuity of critical medical services. The entire timeout management mechanism has high intelligence and adaptive characteristics, and can dynamically optimize the timeout strategy according to system load, network status, business characteristics and other factors, adapt to the special requirements of 7x24 continuous operation and sudden load of medical services. This technical scheme not only improves the execution success rate and resource utilization efficiency of distributed medical transactions, but also enhances the self-management and fault recovery capability of the system, providing a more stable and reliable technical foundation for the digital operation of medical institutions. It has important significance for ensuring the high-quality operation of medical services and promoting the in-depth development of medical informatization.

[0129] In one of the implementation manners of the embodiment, the method further includes the following steps: S810, if any one of the distributed medical service participants fails to pre-check or fails to acquire an exclusive lock, a transaction cancellation instruction is issued to all distributed medical service participants to release the reserved resources and the acquired lock, wherein the reserved resources are the database connections, memory caches and temporary storage spaces locked by each participant in the pre-check stage, and the acquired lock is an exclusive lock created in the distributed lock service based on the instantaneous state vector.

[0130] The transaction cancellation instruction and resource release ensure the rational use of distributed medical system resources and avoid resource leakage. The implementation principle is based on fast fault detection, cascading cancellation and resource recycling technology. Specifically, the triggering conditions for transaction cancellation include two core scenarios: pre-check failure of any distributed medical service participant and distributed lock acquisition failure. Pre-check failure detection is achieved by aggregating and analyzing the pre-check responses returned by all participants. When a failure response is returned by any participant, the system will immediately start the transaction cancellation process.

[0131] The failure detection algorithm adopts a fast failure strategy, does not wait for all responses to return, triggers the cancellation operation as soon as a failure response is found, and maximizes the reduction of resource occupation time. The detection of distributed lock acquisition failure is achieved by monitoring the state of lock request, including lock service unavailable, lock competition timeout, network communication exception and other failure scenarios. The construction of transaction cancellation instruction adopts standardized message format, including global transaction ID, cancellation reason, cancellation timestamp, resource release list and other key information.

[0132] The instruction issuing process adopts a parallel broadcast mechanism, simultaneously sends cancellation instructions to all distributed medical service participants who have participated in pre-check, ensures the timeliness and consistency of the cancellation operation. The issuing process adopts a reliable transmission protocol, retries for participants who fail to send, and sets reasonable retry times and timeout limits. After receiving the cancellation instruction, the participant immediately starts the local resource release process, including releasing the database connection locked in the pre-check stage, cleaning the allocated memory cache, deleting temporary storage files, and canceling the reserved state of data records.

[0133] The resource release process adopts atomic operation to ensure the consistency of resource state, avoiding data inconsistency caused by partial release. At the same time, the transaction coordinator will release the acquired distributed exclusive lock, by sending a lock release request to the distributed lock service, deleting the corresponding temporary order node, so that the lock resource can be immediately acquired by other waiting transactions. The whole cancellation and release process also includes operation log recording, which records the cancellation reason, impact range, release result and other information in detail, providing data support for subsequent problem analysis and system optimization.

[0134] In this embodiment, the fast failure detection and parallel cancellation instruction issuing mechanism ensures that the transaction can be terminated in time when it cannot be executed normally, avoiding long-term invalid occupation of resources, especially during peak medical business hours. This fast release mechanism can significantly improve the overall throughput and response capability of the system. The multi-level resource release strategy covers various system resources such as database connections, memory caches, temporary storage, data reservations, distributed locks, etc. Through atomic release operations, the consistency and integrity of resource states are ensured, effectively preventing resource leaks and deadlock problems. The unified cancellation mechanism based on global transaction ID achieves cross-system coordination and consistency, ensuring that all participating medical services can synchronize related operations, avoiding data inconsistency and business confusion caused by partial system execution. Detailed operation logs and audit mechanisms provide complete data support for system monitoring, optimization, and troubleshooting. Administrators can analyze transaction cancellation reasons, frequency characteristics, and impact through logs, thereby optimizing system configuration and business processes. This mechanism is particularly suitable for complex business scenarios in medical environments, effectively addressing transaction interruption needs caused by sudden patient condition changes, medical resource emergency allocation, equipment failures, and other unexpected situations. By ensuring fast recovery and reallocation of system resources, the reliability and availability of medical information systems are improved, providing strong technical support for efficient operation and high-quality services of medical institutions, and having important practical value for improving medical service quality and optimizing medical resource allocation.

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

[0136] As described in the aforementioned S160 step, the final execution instruction contains a globally unique transaction ID as the core identifier, ensuring accurate delivery 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 misexecution. The transaction ID is encapsulated in the instruction using a fixed field position and standardized data format, usually in the first field of the message header, using UTF-8 encoding to ensure cross-platform compatibility.

[0137] The transaction ID is used for association matching with the temporary state in the pre-check stage. After receiving the final execution instruction, the participant searches for the corresponding pre-check record according to the transaction ID, and verifies the legality and continuity of the instruction. The association verification process includes format checking, existence verification, and state consistency confirmation of the transaction ID, ensuring that only transactions that have completed the pre-check process can enter the final execution stage. The transaction ID in the final execution instruction also contains execution context information, such as transaction creation time, expected completion time, and execution priority, providing comprehensive guidance for local execution by the participant.

[0138] During execution, the participant establishes a local execution log based on the transaction ID, recording the detailed process and results of the execution, providing a complete data link for subsequent audit tracing and fault diagnosis. The transaction ID in the final execution instruction also supports the feedback mechanism of the execution result. After completing the local transaction, the participant feeds back the execution result together with the transaction ID to the transaction coordinator, ensuring real-time synchronization and global consistency of the transaction state.

[0139] As described in the aforementioned S810 step, the transaction cancellation instruction also contains a globally unique transaction ID, ensuring the accuracy and integrity of the cancellation operation. In specific implementation, the mechanism of the transaction ID in the cancellation instruction is similar to that in the final execution instruction but is more stringent. The transaction ID is used to accurately locate the transaction instance that needs to be canceled. After receiving the cancellation instruction, the participant searches for the corresponding pre-check record and reserved resources according to the transaction ID, ensuring the accuracy and accuracy of the cancellation operation.

[0140] The precise matching mechanism of the cancellation operation prevents the risk of mistakenly canceling other transactions, which is particularly important in a high-concurrency medical business environment. The transaction ID in the cancellation instruction carries cancellation reasons and context information, including the trigger time of the cancellation, the identifier of the failed participant, and detailed information such as the specific failure reason, providing complete decision-making basis for local cancellation processing by the participant. The transmission of cancellation reasons not only helps the participant understand the necessity of cancellation, but also provides valuable feedback information for subsequent problem analysis and process optimization.

[0141] The transaction ID in the cancellation instruction also ensures the idempotency of the cancellation operation, so that even if the participant repeatedly receives the same cancellation instruction, it can correctly identify and avoid repeated cancellation operations. The idempotency guarantee mechanism is realized through state tracking of the transaction ID. The participant maintains a record of processed cancellation instructions, and for repeated cancellation requests, it directly returns the processed state, avoiding repeated resource release or abnormal operations. The transaction ID in the transaction cancellation instruction supports the cascading cancellation mechanism. When the main transaction is canceled, all related sub-transactions and dependent transactions will also be automatically canceled according to the association relationship of the transaction ID, ensuring the integrity and consistency of distributed transactions.

[0142] The consistent use of globally unique transaction IDs in both final execution instructions and transaction cancellation instructions embodies the consistency design principle of distributed transaction processing, which is implemented based on strict ID generation, transmission, and verification mechanisms. In specific implementation, the uniformity of transaction IDs is guaranteed in the standardization of ID generation, and both final execution instructions and transaction cancellation instructions use the same transaction ID generation algorithm and format specification to ensure the uniqueness and consistency of IDs throughout the transaction lifecycle. The ID generation process adopts the UUID version 4 standard, combining server identification, timestamps, and random numbers, to ensure global uniqueness in a distributed environment.

[0143] The transmission mechanism of transaction IDs adopts end-to-end integrity protection. From the transaction coordinator to the transmission of instructions to each participant, the transaction ID remains unchanged, and the transmission protocol uses checksum verification to ensure that the ID is not tampered with or damaged during network transmission. The verification mechanism of transaction IDs runs through the entire instruction processing flow. Participants will verify the format legality, uniqueness, and relevance of transaction IDs when receiving any instructions. Only instructions that pass the verification will be executed or processed. The verification process includes ID format checking, existence verification, and state consistency confirmation at multiple levels to ensure the reliability and security of instructions.

[0144] The audit tracking mechanism of transaction IDs ensures that all related operations from transaction creation to final completion or cancellation can be associated and traced through transaction IDs, providing a complete data link for system monitoring 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.

[0145] In this embodiment, the unified transaction ID design greatly simplifies the complexity of transaction management in a distributed environment, and all participants can accurately identify and process related instructions through the same identifier, avoiding instruction confusion or execution errors caused by inconsistent identifiers. In particular, in the complex scenario of medical business, this uniformity is crucial to ensure the accuracy and security of operations. The instruction delivery mechanism based on the unified transaction ID realizes end-to-end operation traceability and state synchronization. From the initiation of the transaction to the final completion or cancellation of the entire life cycle, all related operations can be accurately associated through the transaction ID, providing complete data support for audit compliance and quality control of medical business. The idempotency guarantee mechanism of the transaction ID effectively prevents repeated operations and resource waste, and whether it is an execution instruction or a cancellation instruction, it can correctly handle network exceptions, message duplication and other abnormal situations, ensuring the stable operation of the system in various fault scenarios. The unified transaction ID design also enhances the scalability and interoperability of the system, and new medical services or business scenarios can seamlessly access 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 and can effectively support various medical transaction scenarios from simple single operations to complex cross-system collaboration, providing a standardized and standardized technical foundation for the digital transformation and business process optimization of medical institutions. By ensuring the consistency and reliability of distributed transaction processing, not only does it improve the efficiency and success rate of medical services, but also enhances the integrity and accuracy of medical data, which has important practical value and far-reaching significance for patient safety and improving the quality of medical services.

[0146] The embodiments of the present application also provide a server, comprising: a memory configured to store instructions; and a processor configured to call the instructions from the memory and implement the above-mentioned medical information integration-oriented distributed transaction consistency guarantee method when executing the instructions.

[0147] Those skilled in the art will appreciate that the embodiments of the present application can be provided as a method, system or computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0148] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof.

[0149] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof.

[0150] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof.

[0151] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0152] The memory can include non-persistent memory and / or volatile memory, such as a random access memory (RAM) including a cache area for the temporary storage of data. The memory can also include non-volatile memory, such as read only memory (ROM) for storing structural information and / or instruction code to boot an operating system. The memory can also include solid state non-volatile memory (e.g., flash memory), disk drives, disk arrays, optical storage devices, tape storage devices, etc.

[0153] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0154] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article or apparatus that includes a list of elements does not only include those elements, but also includes other elements not explicitly listed, or further includes elements inherent in such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0155] The above only is an embodiment of the present application, and is not used to limit the present application. For those skilled in the art, the present application can have various changes and variations. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A distributed transaction consistency assurance method for medical information integration, characterized in that: Applicable to servers, including: Responding to a global transaction request received from a business initiator, obtaining a business operation identifier; 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; Extract key business status parameters from global transaction requests and pre-configured business rules, and combine and cryptographically hash the key business status parameters based on the business operation identifier to construct an instantaneous state vector. The instantaneous state vector is used to represent the current transaction execution condition. Generate a transaction pre-check request containing a globally unique transaction ID and an instantaneous state vector, and distribute the transaction pre-check request in parallel to all distributed medical service participants. Each distributed medical service participant verifies the feasibility of the transaction pre-check request during the pre-check phase and generates a pre-check response. Summarize all pre-check responses returned from distributed medical service participants, and if all pre-check responses are successful, use the instantaneous state vector as the lock identifier to obtain an exclusive lock in the distributed lock service; A final execution instruction is issued to all distributed medical service participants to commit local transactions. The final execution instruction is used to instruct each distributed medical service participant to convert the temporary state of the pre-examination stage 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, multiple distributed medical service participants participating in the global transaction are parsed and determined in the preset participant configuration file, including: Parse the business operation identifier to obtain the business type and operation type combination; The corresponding service mapping table is retrieved based on the business type and operation type combination in the participant configuration file; Extract the participant service list from the service mapping table; Multiple distributed medical service participants participating in the global transaction are determined based on the participant service list.

3. The method according to claim 1, characterized in that Combine and hash the key business status parameters based on the business operation identifier to construct an instantaneous state vector, including: Retrieving the business rule corresponding to the business operation identifier from the preconfigured business rule library; Analyze the business rules to obtain the key parameter definitions that affect transaction execution; According to the key parameter definition, the parameter key names are extracted and sorted according to the preset priority to obtain a key name list; Extract the values ​​corresponding to the key name list from the global transaction request to obtain a key-value pair set; Sort and concatenate the key-value pair sets to obtain a string; Concatenate the string with the globally unique transaction ID to obtain a combined string; Use the SHA-256 hash algorithm to perform the first hash operation on the combined string 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 an encoded hash value, and the encoded hash value is used as the instantaneous state vector.

4. The method according to claim 1, wherein Each distributed medical service participant verifies the feasibility of the transaction pre-check request during the pre-check phase and generates a pre-check response, including: For each distributed medical service parameter party, receive and parse the transaction pre-check request in the pre-check phase to obtain the globally unique transaction ID and instantaneous state vector; Based on the globally unique transaction ID, check the local transaction log 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 repeated transaction requests, the current local data status meets the preconditions for transaction execution and the transaction operation can be completed, local resources are reserved and a preflight response containing a success indicator is generated; otherwise, a preflight response containing the reason for failure is generated.

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, query the local data storage to obtain the current status of the corresponding data record; Compare the current state with key business state parameters to determine whether the data version is consistent and verify whether the local data record is locked by other transactions; When the data versions are consistent and 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 If all pre-check responses are successful, use the instantaneous state vector as the lock identifier to obtain an exclusive lock in the distributed lock service, including: If all pre-check responses are successful, creating a lock request including a transient state vector; Send the lock request to the distributed lock service, where the distributed lock service uses the instantaneous state vector as the lock path and creates a temporary sequence node; Determine whether the temporary sequence node is the node with the minimum sequence number; If the temporary sequence node is the node with the smallest sequence number, an exclusive lock is acquired in the distributed lock service.

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

8. The method according to claim 1, characterized in that The method further includes: If any distributed medical service participant fails the pre-check or fails to obtain an exclusive lock, a transaction cancellation instruction will be issued to all distributed medical service participants to release reserved resources and release the acquired locks. The reserved resources are the database connection, memory cache and temporary storage space locked by each participant in the pre-check phase, and the acquired lock refers to the exclusive lock 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: a memory configured to store instructions; as well as A processor is configured to call the instructions from the memory and to implement the distributed transaction consistency assurance method for medical information integration according to any one of claims 1 to 9 when executing the instructions.

Images