Blockchain and distributed-based emergency first-aid medical information management method and system

Abstract

The application provides a kind of emergency first-aid medical information management method and system based on blockchain and distribution, it is related to medical information management technical field, including obtaining first-aid event information and generating identification code, push to blockchain node through distributed network, generate trusted record using hierarchical consensus and rule engine, determine the optimal rescue path in combination with real-time data, and trigger rescue instruction and execute tracking through smart contract.The application improves the security of first-aid information transmission, optimizes the efficiency of rescue resource allocation, and ensures the traceability of cross-agency collaboration rescue process.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical information management, and in particular to an emergency first-aid medical information management method and system based on blockchains and distribution. BACKGROUND

[0002] With the acceleration of social development and urbanization, public safety incidents and emergency medical needs are increasing. Emergency medical services, as an important part of the medical system, the efficiency and accuracy of its information management are directly related to the safety of patients. Traditional emergency medical information management mainly relies on centralized dispatching systems and information platforms, coordinating rescue resources through telephone, radio and other communication means. In recent years, with the development of emerging technologies such as the Internet of Things, big data, and blockchains, new technical support and solutions have been provided for emergency medical information management.

[0003] The current emergency medical information management system usually adopts a centralized database architecture, with a single center responsible for data storage, processing and distribution. This architecture has accumulated rich experience in information processing, resource allocation and emergency response, and has formed a relatively mature workflow. However, as the complexity of emergency events increases and cross-regional collaboration needs strengthen, traditional emergency medical information management methods have exposed some technical defects. However, the existing technology still has defects, and the information credibility is difficult to guarantee. In the multi-party emergency process, the information generated by each link lacks effective verification mechanism, and the information inconsistency or tampering may occur, affecting the accuracy of rescue decision; the resource scheduling efficiency is low, and the traditional dispatching system fails to fully consider the dynamic factors such as real-time traffic and medical resource distribution, resulting in suboptimal rescue path selection and delayed rescue opportunity; cross-institutional collaboration is difficult, and there are obvious information barriers between different medical institutions and emergency units, lacking unified collaboration standards and trusted execution mechanisms, making it difficult to achieve efficient collaboration in complex emergency events.

[0004] With the development of blockchain technology and its increasing advantages in data security, distributed collaboration, and other aspects, applying blockchain and distributed technology to emergency medical information management has become a new way to solve the above problems. SUMMARY

[0005] The present application provides an emergency first-aid medical information management method and system based on blockchains and distribution, which can solve the problems in the prior art.

[0006] In a first aspect of the present application, an emergency first-aid medical information management method based on blockchains and distribution is provided, comprising:

[0007] Obtain emergency event information and perform initial processing, extract event timestamps and geographic location coordinates, extract feature vectors from on-site images and audio data, and generate emergency event identification codes;

[0008] The emergency event identification code is pushed to the blockchain network node through a distributed network protocol, and the event information is signed using an asymmetric encryption algorithm to ensure data transmission security;

[0009] Calculate node trust based on historical node interaction records, verify events through a layered consensus mechanism, and use a rule engine for confirmation to generate trusted event records.

[0010] Based on the time information of credible event records, combined with real-time traffic data and the distribution status of emergency vehicles, a multi-objective planning method is used to determine the optimal rescue route and select the target medical institution;

[0011] Based on the smart contract trigger mechanism, rescue instructions are issued to the target medical institutions, and the state machine design is used to track the execution status of rescue instructions;

[0012] A rescue mission tracking mechanism is built based on the emergency event identification code, rescue process data is recorded through a distributed hash table, and a smart contract-driven state migration method is used to adjust the rescue plan. Cross-agency collaboration instructions are executed according to preset threshold rules.

[0013] In an optional embodiment, calculating node trust based on historical node interaction records and performing event verification through a hierarchical consensus mechanism includes:

[0014] Collect historical interaction records of network nodes, construct a multi-dimensional interaction feature vector that includes node response time, transaction verification accuracy, and block generation stability, establish a time decay function based on the multi-dimensional interaction feature vector, and perform time-weighted processing on the historical interaction records of network nodes to obtain the node trust level;

[0015] In the first phase of the consensus mechanism, a node whose trustworthiness exceeds the master node trust threshold is selected as the master node, and the master node pre-processes the event information and generates a pre-processed message;

[0016] In the second phase of the consensus mechanism, a verification task quota of each network node is determined according to the node trustworthiness, and each network node verifies the pre-processed message and generates a preparation message according to the verification task quota;

[0017] In the third stage of the consensus mechanism, an information transmission sequence table is set according to the node trust of the network node, a message transmission channel between the nodes is established according to the information transmission sequence table, and the network node generates a commit message after verifying the prepare message;

[0018] The consensus reaching standard is set based on the node trust, the required number of verification nodes is adjusted from a fixed value to a threshold number calculated based on the node trust, the verification weight of each node is determined according to the trust weight calculation rules, and the final verification result of the event is generated when the consensus reaching standard is met.

[0019] In an optional embodiment, using a rule engine for confirmation, generating a trusted event record includes:

[0020] Receive event verification results, extract verification indicator data, node capability data, and verification process data, and build a verification strength model based on the verification indicator data;

[0021] Constructing a four-layer neural network structure based on the verification strength model, wherein the input layer of the four-layer neural network structure receives the verification process data, uses the node capability data as the processing weight of the hidden layer, and generates a rule trigger threshold through the four-layer neural network structure;

[0022] Inputting the verification process data into the four-layer neural network structure to generate an event confirmation strategy including confirmation weight parameters, trigger rule parameters and record generation parameters;

[0023] Performing layered compression processing on the blockchain data based on the confirmation weight parameters to generate a layered data packet, and calculating a verification integrity score for the layered data packet based on the trigger rule parameters;

[0024] When the verification completeness score exceeds the rule triggering threshold, generating a data verification record;

[0025] Aggregating the event verification result, the verification process data, and the data verification record according to the record generation parameters to generate a blockchain event data packet;

[0026] Generate a trusted event record containing a trusted timestamp based on the blockchain event data packet.

[0027] In an optional embodiment, based on the time information of the credible event record, combined with real-time traffic data and the distribution status of emergency vehicles, a multi-objective planning method is used to determine the optimal rescue route. The target medical institution is selected including:

[0028] The time distribution characteristics of rescue events are collected from the trusted event records, the average response time of each time period is calculated, the distribution locations are marked on the electronic map, and the regional distribution map is obtained through density analysis;

[0029] Combined with real-time traffic data, the road network structure of the target area is extracted, and the current travel time of each road section is determined based on traffic flow data;

[0030] According to the distribution of emergency vehicles, with the accident site as the starting point and the medical institution as the end point, multiple paths are initialized based on the road network structure, and the total travel time, time fluctuation range and end point capacity parameters of each path are calculated;

[0031] Using a multi-objective planning method, the total travel time, time fluctuation range, and terminal capacity parameters are substituted into the scoring function to generate a comprehensive score for each path. A preset number of paths with the highest comprehensive scores are selected as candidate paths.

[0032] For any two candidate paths, the intersection point is determined. The path before the intersection of the first path is combined with the path after the intersection of the second path, and the path before the intersection of the second path is combined with the path after the intersection of the first path to determine two new paths. At the same time, for each candidate path, the section to be optimized is determined. Based on the road network structure, other passable sections are selected to replace them to obtain new paths. The comprehensive score of all new paths is recalculated.

[0033] Repeat the iteration until the comprehensive score no longer increases, select the path with the highest comprehensive score, determine the optimal rescue path, and determine the corresponding target medical institution.

[0034] In an optional embodiment, the method further includes:

[0035] Establish a path candidate pool and store the non-optimal rescue paths whose comprehensive scores in each round of path optimization reach the preset score threshold in the path candidate pool;

[0036] When the optimal rescue path is blocked, the path with the highest comprehensive score and the starting point that best matches the current location is retrieved from the path alternative pool as the alternative path based on the current location;

[0037] Update the comprehensive score of each path in the path candidate pool based on real-time traffic data, and remove the alternative paths with a comprehensive score below the preset score threshold;

[0038] During the rescue process, the comprehensive score changes of the paths in the path alternative pool are continuously monitored. When an alternative path with a higher comprehensive score than the current execution path appears, a path switching instruction is issued to the decision terminal.

[0039] In an optional embodiment, a rescue mission tracking mechanism is constructed based on the emergency event identification code, and recording rescue process data through a distributed hash table includes:

[0040] Using the emergency event identification code as the primary key, a hash table data structure is established to obtain a unique index identification for the rescue task;

[0041] Based on the unique index identifier, the rescue mission data is classified and stored according to three levels: basic information, real-time status, and historical records to obtain a structured mission data set;

[0042] For the structured task data set, a timestamp is added to each rescue process data, and the data update time and modification content are recorded to obtain a data record with version information;

[0043] For the data records, the data storage location is calculated according to the consistent hashing algorithm, and the data is distributed to different nodes to obtain a distributed storage solution;

[0044] Based on the distributed storage solution, data copies are created on multiple network nodes and kept synchronously updated, eventually forming a rescue process tracking database.

[0045] In an optional embodiment, a smart contract-driven state transition method is used to adjust the rescue plan, and executing cross-institutional collaboration instructions according to preset threshold rules includes:

[0046] Based on the rescue process tracking database, the rescue process is divided into three state nodes: rescue start, rescue en route, and hospital handover. The three nodes are coded and the rescue state transition sequence is obtained.

[0047] Based on the rescue state transition sequence, a state transition rule diagram is constructed and the corresponding smart contract code is adapted to obtain an executable contract program;

[0048] The executable contract program reads the real-time status in the structured task data set, and when an abnormality is detected, combines the optimal rescue path and the target medical institution to obtain a set of alternative rescue solutions;

[0049] Based on the set of alternative rescue solutions, a collaboration request is sent to other medical institutions according to preset rules and an interaction record is generated to obtain a cross-institutional rescue collaboration solution;

[0050] The cross-agency rescue coordination plan is written into a distributed storage solution as a data record with version information and broadcasted to form a traceable rescue adjustment record.

[0051] A second aspect of an embodiment of the present invention provides a blockchain-based and distributed emergency medical information management system, comprising:

[0052] The first unit is used to obtain emergency event information and perform initialization processing, extract event timestamps and geographic location coordinates, extract feature vectors from on-site images and audio data, and generate an emergency event identification code;

[0053] The second unit is used to push the emergency event identification code to the blockchain network node through the distributed network protocol and use an asymmetric encryption algorithm to sign the event information to ensure the security of data transmission;

[0054] The third unit is used to calculate the node trust based on the node's historical interaction records, verify events through a layered consensus mechanism, and use a rule engine for confirmation to generate trusted event records;

[0055] The fourth unit is used to determine the optimal rescue route and select the target medical institution based on the time information of the credible event record, combined with real-time traffic data and the distribution status of emergency vehicles using a multi-objective planning method;

[0056] The fifth unit is used to issue rescue instructions to target medical institutions based on the smart contract trigger mechanism, and uses a state machine design to track the execution status of rescue instructions;

[0057] The sixth unit is used to build a rescue mission tracking mechanism based on the emergency event identification code, record the rescue process data through a distributed hash table, use the smart contract-driven state migration method to adjust the rescue plan, and execute cross-agency collaboration instructions according to preset threshold rules.

[0058] According to a third aspect of an embodiment of the present invention, an electronic device is provided, including:

[0059] processor;

[0060] a memory for storing processor-executable instructions;

[0061] The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0062] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described above is implemented.

[0063] In an embodiment of the present invention, by combining blockchain and distributed technology, secure and reliable management of emergency event information is achieved, and an asymmetric encryption algorithm and a layered consensus mechanism are used to ensure the security and credibility of data transmission and verification, effectively preventing information tampering and forgery, and improving the reliability of emergency medical information management; based on multi-objective planning methods and real-time data analysis, the system can intelligently determine the optimal rescue path and target medical institution, significantly improving the emergency response speed and resource allocation efficiency, reducing rescue delay time, and providing patients with more timely treatment services; using a smart contract-driven state migration method and a distributed hash table recording mechanism, a complete rescue mission tracking system is constructed, which realizes the automated management and dynamic adjustment of the rescue process, supports the precise execution of cross-institutional collaborative instructions, and enhances the collaborative ability and emergency response effect of the emergency medical system. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Figure 1This is a flowchart of a method for managing emergency medical information based on blockchain and distributed systems according to an embodiment of the present invention;

[0065] Figure 2 This is a comparative analysis chart of the comprehensive scores of the path alternative pool;

[0066] Figure 3 Adjust the smart contract flowchart for the rescue plan. DETAILED DESCRIPTION

[0067] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0068] The following specific embodiments are used to describe the technical solution of the present invention in detail. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0069] Figure 1 This is a flowchart of an embodiment of the present invention based on blockchain and distributed emergency medical information management method, as shown in FIG. Figure 1 As shown, the method includes:

[0070] Obtain emergency event information and perform initial processing, extract event timestamps and geographic location coordinates, extract feature vectors from on-site images and audio data, and generate emergency event identification codes;

[0071] The emergency event identification code is pushed to the blockchain network node through a distributed network protocol, and the event information is signed using an asymmetric encryption algorithm to ensure data transmission security;

[0072] Calculate node trust based on historical node interaction records, verify events through a layered consensus mechanism, and use a rule engine for confirmation to generate trusted event records.

[0073] Based on the time information of credible event records, combined with real-time traffic data and the distribution status of emergency vehicles, a multi-objective planning method is used to determine the optimal rescue route and select the target medical institution;

[0074] Based on the smart contract trigger mechanism, rescue instructions are issued to the target medical institutions, and the state machine design is used to track the execution status of rescue instructions;

[0075] A rescue mission tracking mechanism is built based on the emergency event identification code, rescue process data is recorded through a distributed hash table, and a smart contract-driven state migration method is used to adjust the rescue plan. Cross-agency collaboration instructions are executed according to preset threshold rules.

[0076] In a specific embodiment, the acquisition and initialization of emergency event information is the starting link of this method. When an emergency event occurs, on-site information is collected through a mobile terminal or emergency equipment, including the timestamp of the event, geographic location coordinates, on-site images and audio data. The timestamp uses the UTC standard time format, accurate to the millisecond level, such as "2025-06-30T14:25:36.789Z"; the geographic location coordinates use the WGS84 coordinate system, accurate to six decimal places, such as longitude "120.385642" and latitude "36.072453". For on-site image data, a convolutional neural network model is used to extract feature vectors. The model contains 5 convolutional layers and 3 fully connected layers, and outputs a 2048-dimensional feature vector; for audio data, Mel-frequency cepstral coefficients are used to extract features and generate a 128-dimensional feature vector. Based on the above information, a 64-bit emergency event identification code is generated, of which the first 8 bits are the area code, the middle 48 bits are the hash value of the timestamp and location information, and the last 8 bits are the check code. For example, the generated event identification code might be "A7D90F62E35B7C841D9A6E50B28F3C7D".

[0077] During the blockchain push phase for emergency incident information, a distributed network protocol is used to push the emergency incident identification code and related information to blockchain network nodes. This network utilizes a peer-to-peer (P2P) architecture, with each node maintaining a complete copy of the ledger. Prior to push, the event information is signed using the elliptic curve digital signature algorithm, with a 256-bit private key and a 512-bit signature output to ensure data transmission security. The signing process involves generating a message digest using the SHA-256 algorithm, which is then encrypted using the private key to generate the signature. Network transmission utilizes the TLS 1.3 protocol, with the TLS_AES_256_GCM_SHA384 cipher suite, to establish a secure communication channel. Data packet size is kept below 1500 bytes to prevent IP fragmentation and minimize transmission latency.

[0078] The node trust calculation and event verification phase calculates each node's trust based on historical interaction records. This trust calculation considers three factors: historical data accuracy, response time, and node activity. Historical data accuracy is weighted 0.5, response time is weighted 0.3, and node activity is weighted 0.2. For example, if a node has 95% historical data accuracy, an average response time of 200 milliseconds, and a monthly activity rate of 98%, its overall trust is 0.5 × 0.95 + 0.3 × (1-200 / 1000) + 0.3 × 0.98 = 0.769. Based on node trust, a layered consensus mechanism is used for event verification. Nodes with a trust level above 0.8 form the core verification layer, while nodes with a trust level between 0.5 and 0.8 form the auxiliary verification layer. The core verification layer uses a rules engine, replacing the traditional voting mechanism for validation. The rule set includes 20 verification rules, covering aspects such as temporal consistency, geographic location plausibility, and data integrity. When the rule pass rate exceeds 90%, a trusted event record is generated and written into the blockchain with a block size of 1MB and a block generation time of 15 seconds.

[0079] The optimal rescue route planning phase determines the optimal rescue route based on the time information in trusted event records, combined with real-time road condition data and emergency vehicle distribution. Road condition data includes congestion index, average driving speed, and traffic light status, and is updated every 30 seconds. Emergency vehicle distribution information includes vehicle GPS location, equipment configuration, and medical staffing. A multi-objective planning approach is used to calculate the optimal route, considering three objectives: minimizing arrival time, maximizing route reliability, and optimizing medical resource matching. For a 100-square-kilometer urban area, a road network graph model with 5,000 nodes and 8,000 edges is constructed. In the route planning example, the optimal route from the emergency vehicle's current location (longitude 120.372561, latitude 36.086742) to the accident site (longitude 120.385642, latitude 36.072453) is calculated in under 200 milliseconds. The resulting plan includes 15 route nodes, with an estimated arrival time of 8 minutes. At the same time, the target medical institution is selected based on the patient's condition and the specialist capabilities and bed availability of nearby medical institutions. Medical institution matching factors include specialist matching (weight 0.4), distance (weight 0.3), and resource availability (weight 0.3).

[0080] The rescue order issuance phase uses a smart contract trigger mechanism to issue rescue orders to target medical institutions. The smart contract code, comprising approximately 300 lines of code, includes triggering conditions, execution logic, and state transition rules. Once a trusted event record is written to the blockchain and confirmed (typically requiring three blocks of confirmation, approximately 45 seconds), the smart contract is automatically triggered, generating a rescue order. The rescue order contains information such as the event identifier, patient information, estimated time of arrival, and required medical resources, and is approximately 5KB in size. The order issuance utilizes a state machine design with five states: "Generated," "Received," "Preparing," "Executing," and "Completed." State transition conditions are clearly defined; for example, transitioning from "Received" to "Preparing" requires the medical institution to confirm receipt and begin preparing relevant resources. Complete state transition records are stored on the blockchain, ensuring traceability throughout the entire process.

[0081] The rescue mission tracking phase utilizes a tracking mechanism based on the emergency incident identification code, recording rescue progress data in a distributed hash table. This hash table utilizes a consistent hashing algorithm to distribute data across 256 virtual nodes, ensuring data availability and load balancing. Rescue progress data includes vehicle location, patient vital signs, and medical interventions, updated every 10 seconds. A smart contract-driven state transition approach enables dynamic adjustment of rescue plans. The contract includes 15 pre-set threshold rules. For example, if a patient's blood oxygen saturation remains below 90% for 30 seconds, the system automatically increases the rescue priority; if the estimated time of arrival (ETA) exceeds 5 minutes, the system automatically re-evaluates the target medical facility. For complex rescue scenarios requiring multi-agency collaboration, cross-agency coordination instructions are executed based on pre-set threshold rules, such as invoking remote consultation resources from specialized hospitals or coordinating multiple ambulances to respond simultaneously. Coordination instructions are broadcast to relevant agencies via the blockchain, ensuring information synchronization and clear accountability. Throughout the rescue process, all key data and decisions are recorded on the blockchain, forming a complete rescue record that provides a reliable basis for subsequent medical management, quality assessment, and medical insurance settlement.

[0082] In an optional embodiment, calculating node trust based on historical node interaction records and performing event verification through a hierarchical consensus mechanism includes:

[0083] Collect historical interaction records of network nodes, construct a multi-dimensional interaction feature vector that includes node response time, transaction verification accuracy, and block generation stability, establish a time decay function based on the multi-dimensional interaction feature vector, and perform time-weighted processing on the historical interaction records of network nodes to obtain the node trust level;

[0084] In the first phase of the consensus mechanism, a node whose trustworthiness exceeds the master node trust threshold is selected as the master node, and the master node pre-processes the event information and generates a pre-processed message;

[0085] In the second phase of the consensus mechanism, a verification task quota of each network node is determined according to the node trustworthiness, and each network node verifies the pre-processed message and generates a preparation message according to the verification task quota;

[0086] In the third stage of the consensus mechanism, an information transmission sequence table is set according to the node trust of the network node, a message transmission channel between the nodes is established according to the information transmission sequence table, and the network node generates a commit message after verifying the prepare message;

[0087] The consensus reaching standard is set based on the node trust, the required number of verification nodes is adjusted from a fixed value to a threshold number calculated based on the node trust, the verification weight of each node is determined according to the trust weight calculation rules, and the final verification result of the event is generated when the consensus reaching standard is met.

[0088] In one specific implementation, efficient and reliable medical information management is achieved by constructing a multi-dimensional interaction feature vector, calculating node trust based on a time-decay function, and applying it to a three-stage consensus mechanism. In emergency medical scenarios, the accuracy and real-time nature of medical data are crucial. To ensure the trustworthiness of each node in the network, historical node interaction records are collected, including key parameters such as node response time, transaction verification accuracy, and block generation stability. For each network node, its response time for processing medical emergency information over the past 24 hours is recorded, such as an average response time of 125 milliseconds for processing patient vital signs data. The accuracy of node verification of medical data transactions is also calculated, such as a node's accuracy rate of 98.6% in the past 500 transaction verifications. Furthermore, the node's stability during the block generation process is recorded, such as a 97.2% success rate for continuous block generation participation. Using this data, a multi-dimensional interaction feature vector is constructed to create a characteristic profile for each node.

[0089] Based on the constructed multidimensional interaction feature vector, a time decay function is established to time-weight historical interaction records. In practical applications, recent interaction records have a greater impact on a node's current trustworthiness, so a time decay function with a half-life of 4 hours is set. For example, if a medical network node's response time for emergency data processed one hour ago was 110 milliseconds, and its response time six hours ago was 145 milliseconds, the former would be weighted 2.25 times that of the latter in calculating the node's trustworthiness. By time-weighting historical interaction records, a trust score is ultimately derived for each node, ranging from 0 to 100.

[0090] In the first phase of the consensus mechanism, master nodes are selected based on a preset master node trust threshold. The master node trust threshold is set at 85 points, and only nodes with a trust score exceeding this threshold can be selected as master nodes. In an emergency medical network, assuming there are 120 nodes, 15 of which have a trust score exceeding 85 points will be selected as master nodes. The master node is responsible for preprocessing medical event information. For example, after receiving patient electrocardiogram data uploaded by an ambulance, the master node will standardize the data format, check data integrity, remove obvious outliers, and add a timestamp and source identifier to ultimately generate a preprocessed message.

[0091] Entering the second phase of the consensus mechanism, verification task quotas are determined based on the trustworthiness of each network node. Assuming there are 120 nodes in the network and a total of 600 verification tasks, tasks are allocated proportionally to the node's trustworthiness. A node with a trustworthiness score of 90 might receive 8 verification tasks, while a node with a trustworthiness score of 75 might receive 5. Each node verifies the pre-processed message based on its assigned verification task quota, verifying aspects such as the authenticity of the data source, the integrity of the data structure, and the validity of the timestamp. Upon completion of verification, the node generates a preparation message containing the verification result, the verification time, and a digital signature.

[0092] In the third phase of the consensus mechanism, a sequence table for information transmission is established based on node trust. Nodes with higher trust scores receive and participate in message dissemination preferentially. For example, nodes with trust scores between 95-100 are placed in the first tier of the sequence table, nodes with trust scores between 85-95 are placed in the second tier, and so on. Message transmission channels are established between nodes according to this sequence table, forming an efficient information dissemination network. Upon receiving a prepare message, a node verifies the message, confirming the consistency of the verification results, the validity of the signature, and the authenticity of the source. Upon successful verification, a commit message is generated.

[0093] The consensus reaching standard is set based on the node trust. Traditional consensus mechanisms usually require a fixed number or a fixed proportion of nodes to reach a consensus, such as requiring two-thirds of the nodes to pass verification. The method of this embodiment adjusts the number of verification nodes required to be calculated based on the node trust. The basic threshold is set to 40 nodes passing verification, and at the same time, different verification weights are assigned to each node according to the trust weight calculation rules. The node weight for a trust of 95 points is 1.9, the node weight for a trust of 85 points is 1.7, and the node weight for a trust of 75 points is 1.5. When the cumulative weight reaches 68, it can be considered that the consensus reaching standard is met, and the final verification result of the event is generated at this time.

[0094] In a real-world application, an emergency center received electrocardiogram (ECG) data from a patient with myocardial infarction. After processing using this method, the data was pre-processed by a master node with a trust score of 96. The information was then verified by 35 nodes (with a cumulative weight of 69.3). The entire process took 1.2 seconds, significantly less than the 3.5-second processing time of traditional methods. The verification results confirmed that the ECG data showed ST-segment elevation and an abnormal heart rate, and this information was automatically forwarded to the relevant specialist, buying the patient valuable time for emergency treatment.

[0095] In an optional embodiment, using a rule engine for confirmation, generating a trusted event record includes:

[0096] Receive event verification results, extract verification indicator data, node capability data, and verification process data, and build a verification strength model based on the verification indicator data;

[0097] Constructing a four-layer neural network structure based on the verification strength model, wherein the input layer of the four-layer neural network structure receives the verification process data, uses the node capability data as the processing weight of the hidden layer, and generates a rule trigger threshold through the four-layer neural network structure;

[0098] Inputting the verification process data into the four-layer neural network structure to generate an event confirmation strategy including confirmation weight parameters, trigger rule parameters and record generation parameters;

[0099] Performing layered compression processing on the blockchain data based on the confirmation weight parameters to generate a layered data packet, and calculating a verification integrity score for the layered data packet based on the trigger rule parameters;

[0100] When the verification completeness score exceeds the rule triggering threshold, generating a data verification record;

[0101] Aggregating the event verification result, the verification process data, and the data verification record according to the record generation parameters to generate a blockchain event data packet;

[0102] Generate a trusted event record containing a trusted timestamp based on the blockchain event data packet.

[0103] In one specific implementation, event verification results are first received from multiple nodes in the blockchain network. These results include verification indicator data, node capability data, and verification process data. Verification indicator data includes quantitative indicators such as verification time, computing resource consumption, verification accuracy, and consistency score. Node capability data includes the node's computing power score, historical credibility, response speed, and resource contribution. Verification process data records key parameter changes and data processing status throughout the verification process.

[0104] The collected verification metric data is standardized, converting metrics of varying dimensions into values ​​within a uniform interval, typically between 0 and 1. This processed data is then used to construct a verification strength model, which uses a weighted fusion approach to comprehensively consider the importance of each metric. For example, in one instance, verification accuracy is weighted 0.4, consistency score is weighted 0.3, and verification time and resource consumption are weighted 0.2 and 0.1, respectively, to construct a comprehensive metric reflecting verification reliability.

[0105] Based on the verification strength model, a four-layer neural network structure is constructed, consisting of an input layer, two hidden layers, and an output layer. The input layer receives verification process data, such as 512 hash calculations in a certain verification, 99.8% complete packet verification results, and 96.5% cross-validation consistency. The first hidden layer contains 16 neurons, which are mainly responsible for feature extraction; the second hidden layer contains 8 neurons, which are responsible for feature combination and abstract representation. Node capability data is used as processing weights for the hidden layer. For example, the verification results provided by a node with a historical credibility of 92% will receive a higher processing weight of 0.92, while a node with a historical credibility of only 65% ​​will receive a lower weight of 0.65. The output layer generates rule trigger thresholds, with typical values ​​ranging from 0.75 to 0.95, depending on the security requirement level of the business scenario.

[0106] After inputting the verification process data into the four-layer neural network, an event confirmation strategy is generated, consisting of confirmation weight parameters, trigger rule parameters, and record generation parameters. The confirmation weight parameters define the importance of different types of data in the verification process, such as a weight of 0.8 for transaction data, 0.6 for status data, and 0.4 for network communication data. The trigger rule parameters specify how the verification conditions are triggered, such as "confirmation is triggered when at least 85% of key nodes submit consistent verification results and the data integrity check pass rate exceeds 90%." The record generation parameters define the format and content requirements of the records, such as the need to include event hash values, timestamps, verification node identifiers, and signatures.

[0107] Blockchain data is compressed in layers based on confirmation weight parameters, dividing the raw data into multiple layers according to importance and generating hierarchical data packets. For example, in one practical application, key information such as transaction content, digital signatures, and timestamps are placed in the highest layer, verification process logs are placed in the next highest layer, and network communication records are placed in the lower layers. Data at each layer is compressed and encoded separately, maintaining the integrity of high-level data and appropriately compressing lower-level data to reduce storage overhead.

[0108] The verification integrity score for each hierarchical data packet is calculated based on the trigger rule parameters. This score comprehensively considers data integrity, consistency, and verifiability. The calculation checks the existence of key data fields, verifies the validity of digital signatures, and checks the consistency of verification results across nodes. For example, if a data packet has an integrity check score of 0.93, a signature validity score of 0.98, and a node consistency score of 0.89, its combined verification integrity score is 0.93 × 0.4 + 0.98 × 0.35 + 0.89 × 0.25 = 0.937.

[0109] When the verification integrity score exceeds the previously generated rule trigger threshold, a data verification record is generated. For example, if the threshold is set to 0.85, the score of 0.937 exceeds the threshold, so a verification record containing the verification results, participating node information, timestamp, and key parameters of the verification process is generated.

[0110] Based on the record generation parameters, event verification results, verification process data, and data verification records are aggregated to generate a blockchain event data package. This package adopts a layered structure: the core layer contains basic event information, the middle layer contains key verification process data, and the peripheral layer contains detailed verification process records. Data in each layer is hashed to ensure integrity and consistency.

[0111] Based on blockchain event data packets, a trusted event record with a trusted timestamp is generated. This timestamp is obtained from an authoritative time server and is jointly signed and confirmed by multiple trusted nodes. A complete trusted event record includes an event identifier, a summary of the event content, a verification strength indicator, a list of participating nodes, a trusted timestamp, and a multi-signature attestation. These records are permanently stored on the blockchain and can be queried and verified by anyone through a public interface, ensuring the credibility and transparency of event confirmation.

[0112] In an optional embodiment, based on the time information of the credible event record, combined with real-time traffic data and the distribution status of emergency vehicles, a multi-objective planning method is used to determine the optimal rescue route. The target medical institution is selected including:

[0113] The time distribution characteristics of rescue events are collected from the trusted event records, the average response time of each time period is calculated, the distribution locations are marked on the electronic map, and the regional distribution map is obtained through density analysis;

[0114] Combined with real-time traffic data, the road network structure of the target area is extracted, and the current travel time of each road section is determined based on traffic flow data;

[0115] According to the distribution of emergency vehicles, with the accident site as the starting point and the medical institution as the end point, multiple paths are initialized based on the road network structure, and the total travel time, time fluctuation range and end point capacity parameters of each path are calculated;

[0116] Using a multi-objective planning method, the total travel time, time fluctuation range, and terminal capacity parameters are substituted into the scoring function to generate a comprehensive score for each path. A preset number of paths with the highest comprehensive scores are selected as candidate paths.

[0117] For any two candidate paths, the intersection point is determined. The path before the intersection of the first path is combined with the path after the intersection of the second path, and the path before the intersection of the second path is combined with the path after the intersection of the first path to determine two new paths. At the same time, for each candidate path, the section to be optimized is determined. Based on the road network structure, other passable sections are selected to replace them to obtain new paths. The comprehensive score of all new paths is recalculated.

[0118] Repeat the iteration until the comprehensive score no longer increases, select the path with the highest comprehensive score, determine the optimal rescue path, and determine the corresponding target medical institution.

[0119] In a specific embodiment, timestamp information is extracted from historical rescue event records, and the 24-hour period is divided into multiple time periods, such as 0-1 am, 1-2 am, and up to 11 pm-24 am, and the event frequency and average response time in each time period are counted. Taking a certain urban area as an example, 1,208 emergency incidents in the past year were analyzed, and it was found that 8-10 am and 17-19 am were the peak incident periods, with average response times of 15.3 minutes and 18.7 minutes, respectively. These data points are mapped to an electronic map, and each event is represented by latitude and longitude coordinates, such as (123.456789, 45.678901). A heat map is generated through kernel density analysis to identify multiple high-incidence areas such as Area A and Area B.

[0120] Real-time road condition data collection relies on traffic monitoring systems and in-vehicle terminals. Real-time traffic flow data, including road occupancy and average speed, is obtained from traffic management departments. For example, for a main road, the current traffic flow is recorded as 765 vehicles per hour, with an average speed of 32.5 km / h. The complete road network structure of the target area is extracted, including node (intersection) and edge (road segment) information. Each node is represented by a unique identifier and geographic coordinates, such as node N001 (123.456789, 45.678901). Each edge is represented by its start and end nodes and attribute parameters, such as edge E001 (N001-N002, length 1.2 km, number of lanes 3, speed limit 50 km / h). Based on the current traffic flow data, the actual travel time for each road segment is estimated. For example, the current travel time for edge E001 is 2.6 minutes.

[0121] The distribution of emergency vehicles is updated in real time via onboard GPS devices. Each ambulance's current location, status (on call / on call), and capability parameters are recorded. For example, at a certain moment in time, there are 12 dispatchable ambulances in the area, 8 of which are on call and distributed across 5 different locations. When a new rescue request is received, an initial path set is constructed, starting with the accident site (e.g., coordinates 123.456789, 45.678901) and all applicable medical institutions in the area as potential destinations. For each medical institution, a modified Dijkstra algorithm is used to generate multiple feasible paths based on the road network structure. For example, there may be three alternative paths from the accident site to hospital H001: P001, P002, and P003. Calculate the key parameters of each path: total travel time (e.g., P001 is 13.5 minutes), travel time fluctuation range (P001 is ±2.3 minutes, based on historical data and current road conditions), and terminal capacity parameters (H001 currently has 8 empty beds and the emergency department admission capacity is "medium").

[0122] The multi-objective planning method comprehensively considers multiple factors. A scoring function was designed to convert the total travel time (T), time fluctuation range (V), and terminal capacity parameter (C) into a standardized score. The total travel time score adopts an inverse relationship, with shorter travel time and higher scores. The time fluctuation range score is inversely proportional to the fluctuation value, with smaller fluctuations and higher scores. The terminal capacity parameter score is determined based on the hospital's current reception capacity, with larger capacity and higher scores. Taking path P001 as an example, its total travel time of 13.5 minutes is converted into a score of 0.82, the time fluctuation of ±2.3 minutes is converted into a score of 0.75, and the terminal hospital capacity parameter is converted into a score of 0.70. After weighted calculation, the comprehensive score is 0.78. All paths are sorted, and the top three with the highest comprehensive scores are selected as candidate paths.

[0123] Path optimization uses a crossover, reorganization, and partial replacement strategy. Any two candidate paths are analyzed to find their intersections. For example, P001 and P002 intersect at node N025. Two new paths are generated: NP001 (the portion of P001 from the starting point to N025 plus the portion of P002 from N025 to the end point) and NP002 (the portion of P002 from the starting point to N025 plus the portion of P001 from N025 to the end point). Congested sections within each candidate path are also identified. For example, the current travel time for edge E023 in P001 is 4.5 minutes, significantly higher than the historical average of 2.8 minutes. Alternative sections are searched for in the road network to construct a new path, NP003 (replacing E023 in P001 with the combination of E024 and E025). The comprehensive scores for all newly created paths are recalculated. For example, NP001 scores 0.81, which is higher than the 0.78 for the original path P001.

[0124] The path optimization process is repeated repeatedly, with each iteration selecting the path set with the highest overall score to advance to the next round. The algorithm terminates when the score increases by less than 0.01 over three consecutive iterations or when the maximum number of iterations, 10, is reached. Using a rescue case as an example, after seven iterations, the optimal path, OP001, is determined. It travels from the accident site (123.456789, 45.678901) via nodes N002-N015-N025-N036 to hospital H003, with an estimated travel time of 11.3 minutes, within a time fluctuation range of ±1.5 minutes. Alternative paths, OP002 and OP003, are also provided as contingency plans, reaching hospitals H003 and H005, respectively. The optimal path is transmitted to the emergency vehicle's navigation system and the hospital's emergency system, completing rescue route planning and medical institution selection.

[0125] In an optional embodiment, the method further includes:

[0126] Establish a path candidate pool and store the non-optimal rescue paths whose comprehensive scores in each round of path optimization reach the preset score threshold in the path candidate pool;

[0127] When the optimal rescue path is blocked, the path with the highest comprehensive score and the starting point that best matches the current location is retrieved from the path alternative pool as the alternative path based on the current location;

[0128] Update the comprehensive score of each path in the path candidate pool based on real-time traffic data, and remove the alternative paths with a comprehensive score below the preset score threshold;

[0129] During the rescue process, the comprehensive score changes of the paths in the path alternative pool are continuously monitored. When an alternative path with a higher comprehensive score than the current execution path appears, a path switching instruction is issued to the decision terminal.

[0130] In a specific embodiment, the establishment of the path candidate pool is achieved by screening the non-optimal rescue paths generated in each round of path optimization. The comprehensive score of the non-optimal rescue path is compared with the preset score threshold. When the comprehensive score of a non-optimal path reaches or exceeds the preset score threshold, the path will be stored in the path candidate pool. The preset score threshold can be flexibly set according to the actual application scenario. For example, it can be set to 85 points (out of 100 points) in the city center area, and can be appropriately reduced to 75 points in the suburbs or mountainous areas. The comprehensive score of the path is calculated by considering multiple factors, including path length, estimated travel time, road congestion index, road condition complexity, historical travel records, etc. Each factor is assigned a different weight, and the comprehensive score is obtained by weighted summation.

[0131] Each path in the candidate pool contains the following attributes: path identifier, starting point coordinates, end point coordinates, path point sequence, comprehensive score, timestamp, congestion index distribution, road type distribution, etc. This information is stored using blockchain technology to ensure data security and immutability. Each candidate path is written into the blockchain as a transaction record, and smart contracts are used to automatically update scores and retrieve paths.

[0132] When the optimal rescue route is blocked, the system retrieves the most suitable alternative route from a pool of candidate routes based on the rescue vehicle's current location. This retrieval process employs a two-step matching strategy: the first step is location matching, which calculates the geographic distance between the starting point of each route in the candidate pool and the current location, selecting the top five routes with the closest distances. The second step is score comparison, where the route with the highest overall score is selected from these five routes as the candidate route. For example, if a rescue vehicle encounters a road closure at coordinates (116.405, 39.915), the system calculates the distance between the starting point of each route in the candidate pool and that coordinate. Assuming that five routes with distances of 200 meters, 350 meters, 480 meters, 520 meters, and 600 meters are selected, and their overall scores are 87, 92, 85, 88, and 90, respectively, the system selects the route with an overall score of 92 and a distance of 350 meters as the candidate route.

[0133] To ensure the real-time validity of the path information in the candidate pool, a distributed architecture is used to acquire real-time traffic data from multiple data sources. These data sources include traffic surveillance camera networks, mobile vehicle terminals, intelligent traffic signal systems, and user-reported information. The system updates the comprehensive scores of the routes in the candidate pool every five minutes. This update is based on the latest real-time traffic data, recalculating factors such as the congestion index and estimated travel time for each route, and then updating the comprehensive score. After the update, the system removes candidate routes whose comprehensive scores fall below a preset threshold. For example, a candidate route originally had a comprehensive score of 88. After the real-time traffic data is updated, due to a traffic accident on a certain section of the route causing severe congestion, its comprehensive score drops to 72, falling below the preset threshold of 85. The system then removes the route from the candidate pool.

[0134] During the rescue process, the comprehensive score changes of each path in the alternative path pool are continuously monitored. The monitoring frequency is related to the vehicle speed and regional complexity. It is detected every 2 minutes in high-speed driving areas and every 1 minute in complex urban areas. When an alternative path with a higher comprehensive score than the current execution path is found in the alternative pool, the system will calculate the path switching cost, including the path adjustment distance, time loss and operation complexity. Only when the comprehensive score advantage of the new path exceeds the switching cost will the system issue a path switching instruction to the decision terminal. For example, the comprehensive score of the current execution path is 86 points, and a path with a score of 92 points is found in the alternative pool, but it requires a U-turn and a detour of about 800 meters to connect to the path. The calculated switching cost is about 5 points. Since 92-86=6 points, which is greater than the switching cost of 5 points, a path switching instruction is issued.

[0135] Route switching instructions are triggered through smart contracts within the blockchain network, ensuring reliable transmission and complete record keeping of the instructions. The instructions, including the reason for the switch, details of the new route, and expected returns, are transmitted to the rescue vehicle's navigation system and the medical dispatch center. The medical dispatch center can confirm or reject the switch suggestion based on the actual situation, ensuring professional decision-making and human-machine collaboration.

[0136] The entire dynamic route optimization system is also self-learning, continuously optimizing its comprehensive scoring model and switching decision-making strategy by recording the actual results of each route selection. After each rescue mission is completed, the predicted travel time is compared with the actual travel time to analyze the accuracy of the scoring model and adjust the weighting of various factors accordingly to make the score more accurate.

[0137] Compared with existing technologies, traditional emergency rescue path planning usually adopts static planning or simple real-time navigation solutions. Once the path is determined, it is difficult to adjust flexibly, which can easily lead to rescue delays when encountering sudden road conditions. In existing technologies, path planning mostly relies on a single optimal path and lacks an effective alternative solution management mechanism. This embodiment establishes a dynamically managed path alternative pool to achieve multi-path parallel evaluation and intelligent switching, thereby improving the robustness and adaptability of the rescue path. Blockchain technology is used to ensure the security and immutability of path data, and a distributed architecture is used to obtain multi-source real-time road condition data to achieve more accurate path evaluation and decision-making. The timeliness and reliability of emergency medical rescue are significantly improved.

[0138] like Figure 2The figure shows the dynamic evolution of the comprehensive scores of different path solutions over the 40-minute emergency rescue mission. The optimal path score of this solution starts at 92.4 points, fluctuates during the rescue process as road conditions change, rebounds to 87.2 points at 20 minutes, and finally reaches 85.2 points at 40 minutes. Simultaneously, the two alternative paths of this solution also fluctuate over time, demonstrating their advantages at different points in time: Alternative Path 1 reaches a high of 89.3 points at 15 minutes, surpassing the optimal path's score of 85.7; Alternative Path 2 reaches a peak of 90.2 points at 25 minutes, significantly exceeding the optimal path's score of 84.5. This is the critical moment when this solution enables intelligent path switching. In contrast, the single-path scores of the traditional A* algorithm and Dijkstra's algorithm both show a significant downward trend, particularly in the middle and late stages of the rescue mission, where their scores drop to lows of 70.6 and 68.9, respectively. The chart intuitively demonstrates that this technical solution can maintain a high comprehensive score and ensure rescue efficiency when road conditions change through dynamic path evaluation and alternative pool mechanism, while the traditional single-path algorithm performs poorly due to the lack of an adaptive adjustment mechanism.

[0139] In an optional embodiment, a rescue mission tracking mechanism is constructed based on the emergency event identification code, and recording rescue process data through a distributed hash table includes:

[0140] Using the emergency event identification code as the primary key, a hash table data structure is established to obtain a unique index identification for the rescue task;

[0141] Based on the unique index identifier, the rescue mission data is classified and stored according to three levels: basic information, real-time status, and historical records to obtain a structured mission data set;

[0142] For the structured task data set, a timestamp is added to each rescue process data, and the data update time and modification content are recorded to obtain a data record with version information;

[0143] For the data records, the data storage location is calculated according to the consistent hashing algorithm, and the data is distributed to different nodes to obtain a distributed storage solution;

[0144] Based on the distributed storage solution, data copies are created on multiple network nodes and kept synchronously updated, eventually forming a rescue process tracking database.

[0145] In one embodiment, a unique identification code is generated for each emergency event. This 16-character code consists of a timestamp prefix, a geolocation code mid-segment, and a random sequence suffix. For example, for a car accident that occurred in a certain area at 10:30 AM on May 15, 2023, the system generates the identification code "2023051510-GS782-RT45," where "2023051510" represents the time of the accident, "GS782" is the geolocation code, and "RT45" is a randomly generated sequence number. This ensures uniqueness across multiple events in the same area at the same time.

[0146] A hash table is constructed using key-value pairs, with the emergency event identification code as the key and the associated rescue mission data as the value. The system hashes the identification code using the SHA-256 hash algorithm, generating a fixed-length hash value that serves as a unique index for the data within the distributed system. For example, in the aforementioned car accident, the hashed identification code "2023051510-GS782-RT45" might generate an index of "7a8b9c0d1e2f3g4h5i6j7k8l9m0n," which is used to quickly locate relevant rescue data within the system.

[0147] Based on a generated unique index identifier, rescue mission-related data is structured and stored in three levels. The first level is basic information, including fixed attributes such as event type (such as car accident, fire, sudden illness, etc.), location coordinates (accurate to longitude and latitude, such as 116.3° East longitude, 40.2° North latitude), alarm time (accurate to seconds, such as 2023-05-15 10:30:45), number of victims (such as 3), and urgency level (categorized as urgent, emergency, and routine). The second level is real-time status information, recording the current rescue progress. This includes dynamically changing information such as the dispatched rescue vehicle number (such as A-201, B-105), estimated arrival time (such as 10:42), on-site person in charge (such as Dr. Zhang), and patient vital signs (such as blood pressure 120 / 80 mmHg, heart rate 85 beats / minute). The third level is the historical record, which stores the key node information of the rescue process in chronological order, such as the time of receiving the alarm (10:30:45), the time of departure of the rescue vehicle (10:33:20), the time of arrival at the scene (10:41:30), the time of starting treatment (10:42:15), the time of leaving the scene (11:05:40), the time of arrival at the hospital (11:20:10), etc.

[0148] For structured task datasets, the system adds version control attributes to each piece of data. Each data record includes a creation timestamp, a last modification timestamp, and a summary of the modification details. For example, when on-site medical staff update a patient's vital signs, the system records: the original data "blood pressure 120 / 80 mmHg, heart rate 85 beats / min" was modified to "blood pressure 115 / 75 mmHg, heart rate 90 beats / min," the modification time was "2023-05-15 10:50:30," and the modifier was "Nurse Li." All historical versions of the data are retained and stored in a version chain, making it easy to trace data change history and assign responsibilities.

[0149] A consistent hashing algorithm is used to determine the storage location of data in a distributed environment. For example, consider a rescue network with five storage nodes, labeled Node-1 through Node-5. The hash space is mapped to a virtual ring with a range of 0-360 degrees. Nodes and data are mapped to locations on the ring using the same hash function. For example, Node-1 might be mapped to the 45-degree position, Node-2 to the 90-degree position, and so on. When data with the identification code "2023051510-GS782-RT45" is hashed and mapped to the 70-degree position, it is automatically assigned to Node-2, the closest node clockwise on the ring, for storage.

[0150] To improve data reliability, two nodes in a clockwise direction, in addition to the primary storage node, are selected as replica storage nodes. In the above example, in addition to the primary node Node-2, data is also replicated to Node-3 and Node-4. When rescue data is updated, a two-phase commit protocol is used to ensure data consistency. In the first phase, a pre-commit request is sent to all relevant nodes. If all nodes respond successfully, the second phase begins. In the second phase, a formal commit command is sent to complete the data update. For example, if an on-site rescuer reports an update from "3 minor injuries" to "2 minor injuries, 1 serious injury," an update request is first sent to Node-2, Node-3, and Node-4. After confirming that all three nodes can execute the update, the formal update command is sent to ensure data consistency across the three nodes.

[0151] The result is a comprehensive rescue process tracking database that supports multi-dimensional queries and real-time monitoring. The rescue command center can use the identification code "2023051510-GS782-RT45" to query the entire rescue mission process, including the complete timeline from alarm receipt to patient delivery to the hospital, information on the personnel and equipment involved in the rescue, and key decisions and measures taken during the rescue process. Statistical analysis is also supported by geographical region, event type, time period, and other criteria, providing data support for optimizing emergency rescue resource allocation and improving rescue processes.

[0152] In an optional embodiment, a smart contract-driven state migration method is used to adjust the rescue plan, and the execution of cross-agency collaboration instructions according to preset threshold rules includes:

[0153] Based on the rescue process tracking database, the rescue process is divided into three state nodes: rescue start, rescue en route, and hospital handover. The three nodes are coded and the rescue state transition sequence is obtained.

[0154] Based on the rescue state transition sequence, a state transition rule diagram is constructed and the corresponding smart contract code is adapted to obtain an executable contract program;

[0155] The executable contract program reads the real-time status in the structured task data set, and when an abnormality is detected, combines the optimal rescue path and the target medical institution to obtain a set of alternative rescue solutions;

[0156] Based on the set of alternative rescue solutions, a collaboration request is sent to other medical institutions according to preset rules and an interaction record is generated to obtain a cross-institutional rescue collaboration solution;

[0157] The cross-agency rescue coordination plan is written into a distributed storage solution as a data record with version information and broadcasted to form a traceable rescue adjustment record.

[0158] In one specific implementation, the emergency rescue information management system constructs a rescue process tracking database. This database utilizes a distributed storage architecture and uses key-value pairs to record data from the entire rescue process. The rescue process is divided into three state nodes: rescue initiation (state code S1), rescue en route (state code S2), and hospital handover (state code S3). The rescue state transition sequence consists of the time-series changes of these three state nodes, with a typical sequence of S1 → S2 → S3. Each state node contains information such as a timestamp, geographic coordinates, rescuer identification, and patient vital signs. In actual applications, the status node S1 of a rescue mission may record the following content: {Timestamp: "2025-06-01 08:30:15", Geographic location: "116.3°E, 39.9°N", Rescuer: "R20250601A", Patient ID: "P20250601001", Vital signs: {Blood pressure: "120 / 80 mmHg", Heart rate: "85 bpm", Blood oxygen: "96%"}}.

[0159] Based on the above rescue state transition sequence, a state transition rule graph is constructed. This rule graph uses a directed graph structure, with nodes representing states and edges representing transition conditions between states. For example, the transition condition from state S1 to S2 is the departure of the rescue vehicle, and the transition condition from S2 to S3 is the arrival at the hospital. This rule graph is implemented through smart contract coding, with the executable contract program developed in the Solidity language. The contract contains state variables, event triggers, and state transition functions. The sample code structure defines the state enumeration types (S1, S2, S3), implements the state transition function transitionToState(), sets up a permission control mechanism, and implements event logging. This contract is deployed in a permissioned blockchain network, with each medical institution participating in the consensus process as a network node to ensure data consistency and reliability.

[0160] The executable contract program reads real-time status data from the structured task dataset, including information such as the location of the rescue vehicle, traffic conditions, and changes in the patient's vital signs. The anomaly detection mechanism is implemented based on preset thresholds and rules. For example, anomaly detection is triggered when the rescue vehicle deviates from the planned route by more than 500 meters or when the patient's vital signs deteriorate (such as blood pressure falling below 90 / 60 mmHg). After detecting an anomaly, the rescue path optimization algorithm calculates the optimal rescue path, taking into account three factors: distance, time, and medical resource matching. The algorithm first selects suitable target medical institutions based on the severity of the patient's condition and the specialist needs. It then calculates the estimated time of arrival at each alternative hospital and finally generates a set of alternative rescue plans. Each alternative plan includes the target medical institution, estimated time of arrival, specialist matching score, and path details. For example, the set of alternative plans for a rescue operation is: Plan 1 {Hospital ID: "H001", ETA: "15 minutes", Specialty matching: "0.92", Path: "Route A"}; Plan 2 {Hospital ID: "H003", ETA: "18 minutes", Specialty matching: "0.95", Path: "Route B"}.

[0161] Based on the set of alternative rescue plans, collaboration requests are sent to other medical institutions according to pre-set rules. These rules consider factors such as hospital bed availability, specialist availability, and emergency department load. Collaboration requests are automatically sent via smart contracts within the blockchain network, using asynchronous communication mechanisms to ensure real-time delivery. Receiving medical institutions respond based on their own resource availability, with responses including confirmation of receipt, estimated preparation time, and specialist appointment. Each interaction generates an interaction record, which includes the time the request was sent, the receiving institution, the response status, and the response time. Based on each institution's response, the system automatically generates a cross-institutional rescue collaboration plan, including the final selected medical institution, transfer route, estimated arrival time, and a list of medical resources to be prepared. For example, a cross-institutional rescue collaboration plan might be: {Target hospital: "H003", Transfer route: "Route B", ETA: "2025-06-01 09:05:00", Medical resources to be prepared: ["1 emergency bed", "1 neurosurgeon", "CT scan appointment"]}.

[0162] The cross-agency rescue coordination plan is written to the distributed storage system as a data record with version information. This data record uses JSON format and includes the plan details, generation time, version number, and digital signature. The version number format is "major version number.minor version number.revision number," for example, "1.0.0." The digital signature is generated using an asymmetric encryption algorithm to ensure data integrity and immutability. Data writing utilizes a two-phase commit protocol to ensure data consistency across distributed nodes. After the data record is written, it is broadcast to all participating agencies via the blockchain network, creating a traceable record of rescue adjustments. Upon receiving the broadcast, each agency performs local verification and storage to complete data synchronization. This process ensures information transparency and traceability during the rescue process, providing data support for subsequent rescue quality assessment and process optimization.

[0163] Existing emergency medical information management technologies primarily rely on centralized systems, resulting in information silos, low data reliability, and inefficient cross-institutional collaboration. Traditional methods typically rely on telephone or radio communications for emergency coordination, lacking real-time data sharing and decision support capabilities. Compared to existing technologies, this embodiment introduces blockchain technology to achieve secure sharing and immutable recording of rescue data; employs smart contracts to automate rescue state transitions and exception handling; designs a distributed storage solution to improve data availability; and establishes a cross-institutional collaboration mechanism to optimize resource allocation. This addresses information asymmetry and inefficient collaboration during emergency response, improving the utilization of medical resources in emergency situations.

[0164] like Figure 3Figure 2 illustrates the smart contract-driven rescue plan adjustment process in this technical solution. The entire process begins with real-time monitoring of the rescue status. The system continuously collects data such as the rescue vehicle's location and the patient's vital signs. Anomaly detection is a key decision point. When the system detects a pre-defined anomaly (such as a patient's blood pressure falling below 90 / 60 mmHg or the rescue vehicle deviating from the planned route by more than 500 meters), the smart contract automatically triggers the exception handling function. Exception handling is divided into two parallel sub-processes. The left-hand process calculates the optimal rescue route based on the latest data, taking into account factors such as hospital distance and specialist matching, and generates a set of alternative rescue plans, such as Plan 1 (Hospital H001, estimated arrival time of 15 minutes, specialist matching time of 0.92). The right-hand process sends collaboration requests to other medical institutions, taking into account factors such as hospital load, specialist doctors, and bed availability. After the two sub-processes converge, the system confirms the final rescue coordination plan (for example, selecting Hospital H003, estimated arrival time of 9:05, and a CT scan scheduled), writes this plan into the blockchain storage as a data record with version number 1.0.0, and broadcasts it to all participating institutions. Compared to the linear processing flow of traditional rescue dispatch systems (such as telephone coordination systems based on manual decision-making), this technical solution enables automated detection and parallel processing of abnormal situations, significantly improving the response speed and decision-making quality of rescue plan adjustments. In particular, in emergencies such as sudden changes in patient conditions or blocked rescue routes, smart contracts can automatically execute cross-agency collaboration instructions based on preset rules, avoiding the delays and communication problems of manual coordination in traditional systems, ensuring that rescue resources can be quickly redeployed and maximizing patient safety.

[0165] The embodiment of the present invention is based on blockchain and distributed emergency medical information management system, including:

[0166] The first unit is used to obtain emergency event information and perform initialization processing, extract event timestamps and geographic location coordinates, extract feature vectors from on-site images and audio data, and generate an emergency event identification code;

[0167] The second unit is used to push the emergency event identification code to the blockchain network node through the distributed network protocol and use an asymmetric encryption algorithm to sign the event information to ensure the security of data transmission;

[0168] The third unit is used to calculate the node trust based on the node's historical interaction records, verify events through a layered consensus mechanism, and use a rule engine for confirmation to generate trusted event records;

[0169] The fourth unit is used to determine the optimal rescue route and select the target medical institution based on the time information of the credible event record, combined with real-time traffic data and the distribution status of emergency vehicles using a multi-objective planning method;

[0170] The fifth unit is used to issue rescue instructions to target medical institutions based on the smart contract trigger mechanism, and uses a state machine design to track the execution status of rescue instructions;

[0171] The sixth unit is used to build a rescue mission tracking mechanism based on the emergency event identification code, record the rescue process data through a distributed hash table, use the smart contract-driven state migration method to adjust the rescue plan, and execute cross-agency collaboration instructions according to preset threshold rules.

[0172] According to a third aspect of an embodiment of the present invention, an electronic device is provided, including:

[0173] processor;

[0174] a memory for storing processor-executable instructions;

[0175] The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0176] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described above is implemented.

[0177] The present invention may be a method, an apparatus, a system and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present invention.

[0178] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based and distributed emergency medical information management method, characterized in that: include: Obtain emergency event information and perform initial processing, extract event timestamps and geographic location coordinates, extract feature vectors from on-site images and audio data, and generate emergency event identification codes; The emergency event identification code is pushed to the blockchain network node through a distributed network protocol, and the event information is signed using an asymmetric encryption algorithm to ensure data transmission security; Node trust is calculated based on historical node interaction records, events are verified through a layered consensus mechanism, and confirmed using a rule engine to generate trusted event records, including: Collect historical interaction records of network nodes, construct a multi-dimensional interaction feature vector that includes node response time, transaction verification accuracy, and block generation stability, establish a time decay function based on the multi-dimensional interaction feature vector, and perform time-weighted processing on the historical interaction records of network nodes to obtain the node trust level; In the first phase of the consensus mechanism, a node whose trustworthiness exceeds the master node trust threshold is selected as the master node, and the master node pre-processes the event information and generates a pre-processed message; In the second phase of the consensus mechanism, a verification task quota of each network node is determined according to the node trustworthiness, and each network node verifies the pre-processed message and generates a preparation message according to the verification task quota; In the third stage of the consensus mechanism, an information transmission sequence table is set according to the node trust of the network node, a message transmission channel between the nodes is established according to the information transmission sequence table, and the network node generates a commit message after verifying the prepare message; A consensus-reaching standard is set based on the node trustworthiness, and the required number of verification nodes is adjusted from a fixed value to a threshold number calculated based on the node trustworthiness. The verification weight of each node is determined according to the trustworthiness weight calculation rules. When the consensus-reaching standard is met, a final verification result of the event is generated; Receive event verification results, extract verification indicator data, node capability data, and verification process data, and build a verification strength model based on the verification indicator data; Constructing a four-layer neural network structure based on the verification strength model, wherein the input layer of the four-layer neural network structure receives the verification process data, uses the node capability data as the processing weight of the hidden layer, and generates a rule trigger threshold through the four-layer neural network structure; Inputting the verification process data into the four-layer neural network structure to generate an event confirmation strategy including confirmation weight parameters, trigger rule parameters and record generation parameters; Performing layered compression processing on the blockchain data based on the confirmation weight parameters to generate a layered data packet, and calculating a verification integrity score for the layered data packet based on the trigger rule parameters; When the verification completeness score exceeds the rule triggering threshold, generating a data verification record; Aggregating the event verification result, the verification process data, and the data verification record according to the record generation parameters to generate a blockchain event data packet; Generate a trusted event record containing a trusted timestamp based on the blockchain event data packet; Based on the time information of credible event records, combined with real-time traffic data and the distribution status of emergency vehicles, a multi-objective planning method is used to determine the optimal rescue route and select the target medical institution; Based on the smart contract trigger mechanism, rescue instructions are issued to the target medical institutions, and the state machine design is used to track the execution status of rescue instructions; A rescue mission tracking mechanism is built based on the emergency event identification code, rescue process data is recorded through a distributed hash table, and a smart contract-driven state migration method is used to adjust the rescue plan. Cross-agency collaboration instructions are executed according to preset threshold rules.

2. The method according to claim 1, characterized in that Based on the time information of credible event records, combined with real-time traffic data and the distribution status of emergency vehicles, a multi-objective planning method is used to determine the optimal rescue route. The target medical institutions selected include: The time distribution characteristics of rescue events are collected from the trusted event records, the average response time of each time period is calculated, the distribution locations are marked on the electronic map, and the regional distribution map is obtained through density analysis; Combined with real-time traffic data, the road network structure of the target area is extracted, and the current travel time of each road section is determined based on traffic flow data; According to the distribution of emergency vehicles, with the accident site as the starting point and the medical institution as the end point, multiple paths are initialized based on the road network structure, and the total travel time, time fluctuation range and end point capacity parameters of each path are calculated; Using a multi-objective planning method, the total travel time, time fluctuation range, and terminal capacity parameters are substituted into the scoring function to generate a comprehensive score for each path. A preset number of paths with the highest comprehensive scores are selected as candidate paths. For any two candidate paths, the intersection point is determined. The path before the intersection of the first path is combined with the path after the intersection of the second path, and the path before the intersection of the second path is combined with the path after the intersection of the first path to determine two new paths. At the same time, for each candidate path, the section to be optimized is determined. Based on the road network structure, other passable sections are selected to replace them to obtain new paths. The comprehensive score of all new paths is recalculated. Repeat the iteration until the comprehensive score no longer increases, select the path with the highest comprehensive score, determine the optimal rescue path, and determine the corresponding target medical institution.

3. The method according to claim 2, characterized in that Also includes: Establish a path candidate pool and store the non-optimal rescue paths whose comprehensive scores in each round of path optimization reach the preset score threshold in the path candidate pool; When the optimal rescue path is blocked, the path with the highest comprehensive score and the starting point that best matches the current location is retrieved from the path alternative pool as the alternative path based on the current location; Update the comprehensive score of each path in the path candidate pool based on real-time traffic data, and remove the alternative paths with a comprehensive score below the preset score threshold; During the rescue process, the comprehensive score changes of the paths in the path alternative pool are continuously monitored. When an alternative path with a higher comprehensive score than the current execution path appears, a path switching instruction is issued to the decision terminal.

4. The method according to claim 1, wherein A rescue mission tracking mechanism is built based on the emergency event identification code, and the rescue process data is recorded through a distributed hash table, including: Using the emergency event identification code as the primary key, a hash table data structure is established to obtain a unique index identification for the rescue task; Based on the unique index identifier, the rescue mission data is classified and stored according to three levels: basic information, real-time status, and historical records to obtain a structured mission data set; For the structured task data set, a timestamp is added to each rescue process data, and the data update time and modification content are recorded to obtain a data record with version information; For the data records, the data storage location is calculated according to the consistent hashing algorithm, and the data is distributed to different nodes to obtain a distributed storage solution; Based on the distributed storage solution, data copies are created on multiple network nodes and kept synchronously updated, eventually forming a rescue process tracking database.

5. The method according to claim 4, characterized in that The state migration method driven by smart contracts is used to adjust the rescue plan and execute cross-agency collaboration instructions according to preset threshold rules, including: Based on the rescue process tracking database, the rescue process is divided into three state nodes: rescue start, rescue en route, and hospital handover. The three nodes are coded and the rescue state transition sequence is obtained. Based on the rescue state transition sequence, a state transition rule diagram is constructed and the corresponding smart contract code is adapted to obtain an executable contract program; The executable contract program reads the real-time status in the structured task data set, and when an abnormality is detected, combines the optimal rescue path and the target medical institution to obtain a set of alternative rescue solutions; Based on the set of alternative rescue solutions, a collaboration request is sent to other medical institutions according to preset rules and an interaction record is generated to obtain a cross-institutional rescue collaboration solution; The cross-agency rescue coordination plan is written into a distributed storage solution as a data record with version information and broadcasted to form a traceable rescue adjustment record.

6. A blockchain-based and distributed emergency medical information management system for implementing the method of any one of claims 1 to 5, characterized in that: include: The first unit is used to obtain emergency event information and perform initialization processing, extract event timestamps and geographic location coordinates, extract feature vectors from on-site images and audio data, and generate an emergency event identification code; The second unit is used to push the emergency event identification code to the blockchain network node through the distributed network protocol and use an asymmetric encryption algorithm to sign the event information to ensure the security of data transmission; The third unit is used to calculate the node trust based on the node's historical interaction records, verify events through a layered consensus mechanism, and use a rule engine for confirmation to generate trusted event records; The fourth unit is used to determine the optimal rescue route and select the target medical institution based on the time information of the credible event record, combined with real-time traffic data and the distribution status of emergency vehicles using a multi-objective planning method; The fifth unit is used to issue rescue instructions to target medical institutions based on the smart contract trigger mechanism, and uses a state machine design to track the execution status of rescue instructions; The sixth unit is used to build a rescue mission tracking mechanism based on the emergency event identification code, record the rescue process data through a distributed hash table, use the smart contract-driven state migration method to adjust the rescue plan, and execute cross-agency collaboration instructions according to preset threshold rules.

7. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images