Medical data sharing method based on block chain

Abstract

The invention relates to the technical field of medical data sharing, in particular to a medical data sharing method based on a block chain, comprising the following steps: collecting block chain data storage and access frequency conditions and network traffic based on data state information monitored by block chain nodes in real time, and obtaining a current network state overview; and processing data by using a support vector machine model based on the current network state overview. According to the invention, intelligent prediction is carried out on the real-time network state data, so that the precision and timeliness of load prediction of the block chain system are effectively improved, and the real-time transmission demand of the medical data can be identified more accurately; in the process of determining the priority of the medical data sharing task, frequency domain resource allocation is dynamically adjusted through a priority adjustment instruction, differentiation requirements of different medical data tasks are responded in real time, dynamic adaptation and real-time optimization of a frequency domain resource allocation strategy are achieved, and the problems of delay and packet loss of the medical data sharing task are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of medical data sharing, and particularly to a medical data sharing method based on blockchain. Background Art

[0002] Blockchain technology in the field of medical data sharing aims to ensure the secure and efficient sharing of medical data among different participants through characteristics such as decentralization and immutability. However, current medical data sharing faces many challenges, such as high data security risks, where data is easily leaked or tampered with; inconsistent data formats between different medical institutions, resulting in difficulties in data sharing; and the lack of an effective trust mechanism, leading to insufficient reliability and transparency in data sharing. Traditional medical data sharing methods lack effective solutions to these problems and are difficult to meet the growing demand for medical data sharing. Therefore, improvements are needed. Summary of the Invention

[0003] The purpose of the present invention is to solve the drawbacks existing in the prior art and propose a medical data sharing method based on blockchain.

[0004] To achieve the above purpose, the present invention adopts the following technical solutions. A medical data sharing method based on blockchain includes the following steps: Based on the data status information real-time monitored by blockchain nodes, collect the blockchain data storage and access frequency and network traffic, and obtain an overview of the current network status; based on the overview of the current network status, use a support vector machine model to process the data, predict the blockchain system load and data transmission requirements, and obtain the blockchain system load prediction result; Based on the blockchain system load prediction result, analyze the data transmission requirements, determine high-priority medical data sharing tasks, and generate a priority adjustment instruction; according to the priority adjustment instruction, dynamically adjust the frequency domain resource allocation strategy, reconfigure the use of frequency resources, and generate a frequency domain resource allocation strategy; Apply the blockchain-based data sharing resource allocation strategy to the blockchain system environment, monitor the adjusted transmission delay and data packet loss rate, and obtain the adjusted network performance data; analyze the adjusted network performance data, evaluate the effect of the frequency domain resource adjustment, and generate an evaluation result of the blockchain data sharing resource adjustment effect; Based on the evaluation result of the blockchain data sharing resource adjustment effect, continue to optimize the frequency domain resource allocation, and continuously monitor the network status and medical data transmission efficiency.

[0005] Preferably, the step of obtaining the overview of the current network status is: Based on the data status information monitored in real time by blockchain nodes, the data storage occupancy of blockchain nodes is monitored in real time, the storage occupancy ratios corresponding to different data storage areas are recorded, and the occupancy ratios of each frequency band are classified and sorted to establish network frequency occupancy ratio information, and the blockchain data storage and access frequency conditions are generated; Based on the blockchain data storage and access frequency conditions, the total amounts of data uploaded and downloaded in the blockchain are statistically calculated in real time, the data upload amount and download amount are respectively recorded, and real-time network traffic information is established; Based on the real-time network traffic information, the stability of data transmission, the data conflict level, and the data transmission accuracy rate between blockchain nodes are detected in real time, the signal strength, interference level, and signal-to-noise ratio are recorded, and an overview of the current network state is formed.

[0006] Preferably, the steps for obtaining the prediction result of the blockchain system load are as follows: Based on the overview of the current network state, according to information such as the blockchain data storage and access frequency conditions, data upload and download amounts, and data transmission stability, time series features are established, the blockchain data storage and access frequency conditions and network traffic are respectively smoothed, and the network signal quality information is denoised to form network state feature information; Based on the network state feature information, the historical blockchain system load and historical data transmission requirements are called, and the regression relationships between the network state feature information and the historical blockchain system load, and between the network state feature information and the historical data transmission requirements are respectively calculated through a support vector machine model to form a prediction model for the blockchain system load and data transmission requirements; Based on the prediction model for the blockchain system load and data transmission requirements, the network state feature information is called, and the blockchain system load and data transmission requirements for future time periods are respectively calculated to generate a prediction result of the blockchain system load.

[0007] Preferably, the steps for obtaining the priority adjustment instruction are as follows: Based on the prediction result of the blockchain system load, the data sharing tasks are classified and sorted according to the urgency of medical data sharing requirements, and the bandwidth requirements and latency requirements corresponding to each medical data sharing task are extracted to form medical data task classification information; According to the medical data task classification information, the priority index of the medical data sharing task is calculated, and the expression is: ; Wherein, is the priority index of the medical data sharing task, is the urgency of the task, is the requirement of the task for the blockchain data storage space and transmission rate, is the maximum delay allowed for the task, is the size of the task data volume, is the currently available network bandwidth; Based on the priority index of the medical data sharing task, arrange them in descending order of the priority index of the medical data sharing task, and generate a priority adjustment instruction.

[0008] Preferably, the obtaining step of the frequency domain resource allocation strategy is: According to the priority adjustment instruction, extract the blockchain data storage space and transmission rate requirement values corresponding to the medical data sharing task and the current blockchain data storage and access frequency situation values, analyze the remaining space and rate range of the currently available blockchain data storage space and transmission resources, and generate frequency domain resource occupancy information; Based on the frequency domain resource occupancy information, calculate the frequency domain resource dynamic configuration index, and the calculation formula is: ; Wherein, represents the frequency domain resource dynamic configuration index, represents the priority index of the medical data sharing task, represents the amount of resources required by the medical data sharing task in the frequency domain, represents the real-time packet loss rate of the medical data sharing task, represents the amount of data storage space and transmission resources already occupied in the current blockchain, represents the total amount of data storage space and transmission resources of the current blockchain, represents the transmission delay fluctuation value of the current medical data sharing task within a unit time; Sort the frequency domain resource dynamic configuration indexes of the medical data sharing tasks from large to small, and reallocate the frequency domain resources required by the medical data sharing tasks in turn according to the sorting results, and generate a frequency domain resource allocation strategy.

[0009] Preferably, the obtaining step of the adjusted network performance data is: Apply the blockchain-based data sharing resource allocation strategy to the blockchain system environment, execute the data storage space and transmission resource reallocation actions in the blockchain-based data sharing resource allocation strategy, and record the packet sending time and receiving time after the execution of the medical data sharing task in real time, calculate the transmission delay, and record the number of lost packets during the transmission at the same time, and generate task transmission monitoring information; According to the task transmission monitoring information, calculate the network performance fluctuation index, and the calculation formula is: ; Wherein, represents the network performance fluctuation index, represents the latency of the medical data sharing task transmission, represents the number of data packet losses during the transmission of the medical data sharing task, represents the average rate of the medical data sharing task under the adjusted frequency domain resources, represents the theoretically expected data transmission rate of the medical data sharing task, represents the bandwidth occupied by the network during the execution of the medical data sharing task, represents the total number of data packets transmitted by the medical data sharing task, represents the real-time signal-to-noise ratio during the execution of the medical data sharing task; Determine the stability of the network performance after the execution of the frequency domain resource allocation strategy according to the amplitude of the change of the network performance fluctuation index, and generate the adjusted network performance data.

[0010] Preferably, the steps for obtaining the evaluation result of the data sharing resource adjustment effect of the blockchain are as follows: Calculate the stability index of the frequency domain adjustment effect according to the adjusted network performance data, and the calculation formula is: ; Wherein, represents the stability index of the frequency domain adjustment effect, represents the standard deviation of the latency of the medical data sharing task before the frequency domain resource adjustment, represents the standard deviation of the latency of the adjusted medical data sharing task, represents the standard deviation of the number of packet losses of the medical data sharing task before the adjustment, represents the standard deviation of the number of packet losses of the adjusted medical data sharing task, represents the congestion ratio of the adjusted blockchain data transmission resources, represents the average throughput of the network performance before the adjustment, represents the average throughput of the network performance after the adjustment, represents the network performance fluctuation index; Based on the stability index of the frequency domain adjustment effect, judge the stability of the network performance after the frequency domain adjustment, conduct effect level classification, analyze whether the effect of the frequency domain resource adjustment reaches the optimization expectation, and generate the evaluation result of the data sharing resource adjustment effect of the blockchain.

[0011] Preferably, based on the evaluation result of the data sharing resource adjustment effect of the blockchain, the steps for continuously optimizing the frequency domain resource allocation and continuously monitoring the network status and medical data transmission efficiency are as follows: Based on the evaluation result of the data sharing resource adjustment effect of the blockchain, record the task information that fails to reach the optimization target and generate a list of tasks to be optimized; According to the to-be-optimized task list, analyze the transmission delay value, the number of data packet losses, and the frequency band congestion ratio value corresponding to the medical data sharing task, and readjust the frequency domain resource allocation method corresponding to each medical data sharing task.

[0012] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In the present invention, by intelligently predicting the real-time network state data, the accuracy and timeliness of the blockchain system load prediction are effectively improved, so that the real-time transmission requirements of medical data can be more accurately identified; in the process of determining the priority of medical data sharing tasks, the frequency domain resource allocation is dynamically adjusted through the priority adjustment instruction, and the differential requirements of different medical data tasks are responded to in real time, realizing the dynamic adaptation and real-time optimization of the frequency domain resource allocation strategy, and improving the delay and packet loss problems of medical data sharing tasks; after executing the frequency domain resource allocation strategy, by monitoring and analyzing the actual network performance data, deeply evaluating the effect of frequency domain adjustment, and continuously optimizing and adjusting the frequency domain resource allocation process, the long-term stability of the network state and medical data transmission efficiency is realized. The real-time performance, stability and resource utilization efficiency of medical data transmission are improved, the configuration of wireless frequency domain resources is made more accurate and flexible, the delay and data packet loss in medical data transmission are reduced, and the intelligence and self-adaptability of wireless resource allocation are enhanced. Description of the Drawings

[0013] Figure 1 It is a step schematic diagram of the present invention. Detailed Embodiment

[0014] In order to make the purpose, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0015] Please refer to Figure 1 , the present invention provides a technical solution, a blockchain-based medical data sharing method, including the following steps: Based on the data state information real-time monitored by the blockchain node, collect the blockchain data storage and access frequency and network traffic, and obtain an overview of the current network state; based on the overview of the current network state, use the support vector machine model to process the data, predict the blockchain system load and data transmission requirements, and obtain the blockchain system load prediction result; Based on the blockchain system load prediction result, analyze the data transmission requirements, determine the high-priority medical data sharing tasks, and generate a priority adjustment instruction; according to the priority adjustment instruction, dynamically adjust the frequency domain resource allocation strategy, reconfigure the use of frequency resources, and generate a frequency domain resource allocation strategy; Apply the blockchain-based data sharing resource allocation strategy to the blockchain system environment, monitor the adjusted transmission delay and data packet loss rate, and obtain the adjusted network performance data; analyze the adjusted network performance data, evaluate the effect of frequency domain resource adjustment, and generate the evaluation result of the blockchain data sharing resource adjustment effect; Based on the evaluation result of the blockchain data sharing resource adjustment effect, continue to optimize the frequency domain resource allocation, and continuously monitor the network status and the medical data transmission efficiency.

[0016] The steps for obtaining the overview of the current network status are as follows: Based on the data status information real-time monitored by the blockchain nodes, real-time monitor the data storage occupancy of the blockchain nodes, record the storage occupancy ratios corresponding to different data storage areas, classify and sort out the occupancy ratios of each frequency band, establish the network frequency occupancy ratio information, and generate the blockchain data storage and access frequency situation; Based on the blockchain data storage and access frequency situation, real-time count the total upload and download amounts of the data in the blockchain, record the data upload amount and download amount respectively, and establish the real-time network traffic information; Based on the real-time network traffic information, real-time detect the stability of data transmission, the data conflict level and the data transmission accuracy rate among the blockchain nodes, record the signal strength, interference level and signal-to-noise ratio, and form the overview of the current network status.

[0017] Specifically, based on the data status information real-time monitored by blockchain nodes, first, parse the network channel occupancy records collected per second to extract the usage information in each time period and different frequency ranges. Several frequency bands can be divided from 800 MHz to 2600 MHz and the occupancy time within each band can be counted. Then, compare the frequency band occupancy time with the total monitoring duration of the corresponding time period to calculate the corresponding frequency occupancy ratio, which ranges from 0% to 100%. If the occupancy ratio of a certain frequency band continuously exceeds 80%, it is marked as a high occupancy segment. Here, the 80% threshold can be obtained by analyzing the typical occupancy situation in the past three months and taking the average value plus 10%. After the occupancy ratios of all frequency bands are determined, these ratios need to be classified and sorted one by one. For example, the ratios from 0% to 30% are classified as low occupancy categories, the ratios from 30% to 60% are classified as medium occupancy categories, the ratios from 60% to 80% are classified as relatively high occupancy categories, and those higher than 80% are classified as the highest occupancy categories. Then, horizontally summarize these classification results on a daily or weekly basis. During this process, if it is found that some frequency bands remain in relatively high occupancy categories for a long time, the peak usage situation at the same time of each day can be further referred to determine whether there is interference or unreasonable allocation. Finally, compare the final classification results with the historical statistical data. After clarifying the differences in the long-term and short-term occupancy rates of each frequency band, all information is merged and recorded as network frequency occupancy ratio information, and further organized into a unified blockchain data storage and access frequency situation for subsequent analysis.

[0018] Based on the blockchain data storage and access frequency situation, first, conduct real-time monitoring on the uploaded and downloaded data respectively within the confirmed available frequency bands. For example, record the total amount of uploaded data at the current moment every 10 seconds and synchronously record the total amount of downloaded data. In order to more intuitively compare it with the all-day usage cycle, 24 hours can be evenly divided into 144 time slices and the uploaded and downloaded data of all frequency bands are collected in sequence. If the uploaded data at a certain moment exceeds the reference value of 20 MB, it is marked as high traffic. This reference value can be determined by combining the average uploaded value at the same time of each day last month and adding a 20% redundancy on this basis. Similarly, if the downloaded data at a certain moment also exceeds the set threshold, it is also marked as high traffic. When there are five consecutive high traffic records and the interval between each time does not exceed 10 seconds, it is considered that the usage demand in this time period may increase abnormally. After merging and summarizing all the collected uploaded and downloaded values, the data can be statistically analyzed according to the traffic range. For example, 0 MB to 10 MB is set as the low traffic area, 10 MB to 20 MB is set as the medium traffic area, and exceeding 20 MB is recorded as the high traffic area. During the judgment process, if the uploaded or downloaded data of a certain frequency band breaks through 50 MB multiple times, it is classified as ultra-high traffic. Finally, uniformly organize these marked values of high traffic, low traffic, and abnormal fluctuations and arrange them in a table in chronological order. After collecting all monitoring indicators in this way, real-time network traffic information can be established.

[0019] Based on real-time network traffic information, first, the signal strength of the current network connection is collected at intervals. The measured signal power is compared with the reference range from 0 dBm to -100 dBm. If the signal strength remains below -80 dBm for more than 20 minutes in a certain period, it is considered that the signal is weak in this area. Here, -80 dBm can be obtained by taking the average value of the device's receiving sensitivity and the scene test results and then reducing it by 5 dB. Then, the interference level is evaluated. The superimposed value of other signals can be measured within the same frequency or adjacent frequency range and compared with the empirical threshold of -70 dBm. This empirical threshold can be set according to the receiving limits of different devices and the operational service requirements. When the interference level is higher than -70 dBm, it is marked. At the same time, the signal-to-noise ratio is measured at the same interval and compared with the reference value of 15 dB. This 15 dB can be obtained by combining the actual network structure and historical observations. In all the acquisition processes, if there are repeated fluctuations in the signal strength, interference level, or signal-to-noise ratio with the aforementioned reference values, then the corresponding time period and the real-time network traffic information are compared together. In this way, the change relationship of each index when the traffic increases or decreases can be evaluated. When all the measured values are recorded in chronological order and integrated with the previously collected upload and download situations, the analysis basis for the overall current network state can be summarized, and finally, an overview of the current network state is formed.

[0020] The steps to obtain the prediction result of the blockchain system load are as follows: Based on the overview of the current network state, according to information such as the blockchain data storage and access frequency, data upload and download volume, and data transmission stability, time series features are established. The blockchain data storage and access frequency and network traffic are respectively smoothed, and the network signal quality information is denoised to form network state feature information. Based on the network state feature information, the historical blockchain system load and historical data transmission requirements are called, and the regression relationships between the network state feature information and the historical blockchain system load, and between the network state feature information and the historical data transmission requirements are calculated through a support vector machine model to form a prediction model for the blockchain system load and data transmission requirements. Based on the prediction model for the blockchain system load and data transmission requirements, the network state feature information is called, and the blockchain system load and data transmission requirements for future time periods are respectively calculated to generate the prediction result of the blockchain system load.

[0021] Specifically, based on the overview of the current network state, first, all the measured values are integrated in chronological order from the previously obtained blockchain data storage and access frequency, network traffic, and network signal quality information. During this process, 24 hours a day can be divided into 144 time periods and the corresponding records are read in sequence. If it is found that the network traffic in a certain time period is higher than the upper threshold obtained from the previous statistics This part of the data is marked. The upper limit threshold can be obtained by adding a 15% margin to the average traffic in the same period in the past two weeks. Then, observe the blockchain data storage and access frequency situation, and merge the occupancy rate values in each frequency interval by minute segments. If the occupancy rate of a certain frequency band continuously exceeds 80% and the duration exceeds 20 minutes, it is recorded as a high occupancy stage. Here, both 80% and 20 minutes can be determined based on the historical usage peak and device performance evaluation. After completing the above records, use the simple moving average method to smooth all the recorded traffic data. Assume that the average value is taken within three consecutive sample intervals to reduce extreme fluctuations. At the same time, perform noise reduction operations on the signal quality information. For example, perform median filtering on the continuously collected signal strength values in the interval from -80dBm to -50dBm. If a value deviates from this interval by more than 10dB, it is replaced by the median. This 10dB screening line can be obtained by statistically analyzing the historical signal jitter range and increasing it by 5dB. When the smoothing and noise reduction are completed, arrange the cleaned time series data of frequency occupancy, traffic, and signal strength in time index and form a time series feature set. On the basis of confirming that there are no obvious omissions in each data sequence and the indicators are consistent, merge and organize them to finally form the network state feature information.

[0022] Based on the network state feature information, first pair the time series feature set obtained above with the historical blockchain system load records. For example, select available samples from the load values collected every 30 seconds daily in the past three months. Combine the traffic, frequency occupancy rate, and signal strength values at the same moment in the feature set with the corresponding historical load values to form training pairs. Perform a similar operation on the historical data transmission requirements to obtain another set of training pairs containing features and demand values. Subsequently, construct a support vector machine for regression training. Here, the radial basis function can be selected as the kernel function and the regularization parameter is determined. This parameter can be determined by combining the results of five-fold cross-validation in a small range and the mean square error evaluation process. Specifically, first randomly divide the data set and perform experiments with an increment of 0.1 in the interval from 0.5 to 2, and select the one with the smallest mean square error as the best value. During training, calculate the mapping relationship between the network state feature information and the historical blockchain system load, and the mapping relationship between the network state feature information and the historical data transmission requirements. After the training is completed, check the regression residuals. If the average value of the residuals is lower than the pre-experienced set 1% threshold after multiple iterations, stop. This 1% can refer to the calculation results of the overall impact of the average load increment in different periods and be appropriately adjusted. After the training is completed and the support vector machine model parameters are fixed, finally form the blockchain system load and data transmission demand prediction model.

[0023] Based on the blockchain system load and data transmission demand prediction model, the network state feature information obtained previously is segmented according to the time period required for prediction. For example, the traffic and signal quality values per minute within the next hour are extracted, and then they are input into the trained support vector machine model to obtain the load and data demand estimates for that hour. The predicted values for each minute in the output result are recorded one by one. If any predicted value exceeds the reference benchmark then a reconfirmation is carried out. The reference benchmark can be obtained by adding 5% to the maximum load peak in the past month. At the same time, if the demand prediction for some time periods shows a too large difference from adjacent time periods, the corresponding input can be compared with historical data to check whether the characteristic values of that time period significantly exceed the normal fluctuation range. For example, the traffic and signal strength are compared between their respective upper and lower limits. If they exceed the upper and lower limit intervals, they are marked as abnormal points and not included in this prediction. After confirming all the predicted values, they are summarized and recorded in chronological order to represent the blockchain system load and data demand in future time periods, and finally the blockchain system load prediction result is generated.

[0024] The steps to obtain the priority adjustment instruction are as follows: Based on the blockchain system load prediction result, the data sharing tasks are classified and sorted according to the urgency of the medical data sharing requirements, and the bandwidth requirements and latency requirements corresponding to each medical data sharing task are extracted to form medical data task classification information; According to the medical data task classification information, calculate the priority index of the medical data sharing task. The expression is: ; where, is the priority index of the medical data sharing task, is the urgency of the task, is the demand of the task for the blockchain data storage space and transmission rate, is the maximum latency allowed for the task, is the size of the task data volume, is the available bandwidth of the current network; Based on the priority index of the medical data sharing task, arrange them in descending order of the priority index of the medical data sharing task to generate the priority adjustment instruction.

[0025] Specifically, based on the load prediction results of the blockchain system, first read the medical data transmission requirement information obtained previously and retrieve the relevant urgency records. In the urgency records, first identify the corresponding relationship between the urgency and the event occurrence time in numerical form. For example, define the urgency of a task as the numerical value 3 indicating extremely important, the numerical value 2 indicating moderately important, and the numerical value 1 indicating ordinary. When the urgency corresponds to the event time period, the distribution of transmission tasks within a day can be classified. For the bandwidth requirement, extract the average occupancy value from the previously recorded upload and download records, and compare it with the total bandwidth of 200 Mbps. If the average occupancy value of a certain task is in the range of 50 Mbps to 100 Mbps, it is marked as a medium requirement; if it exceeds 100 Mbps, it can be marked as a high requirement; if it is less than 50 Mbps, it is marked as a low requirement. At the same time, numerically represent the latency requirement. For example, when the allowed latency is in the range of 500 ms to 2000 ms, it is marked as a medium latency requirement; if the maximum latency allowed for a task is below 500 ms, it is marked as a high-priority latency requirement; if it exceeds 2000 ms, it is marked as a low-priority latency requirement. Subsequently, comprehensively sort each task by combining the urgency, bandwidth requirement, and latency requirement. If the urgency value is large and both the bandwidth requirement and latency requirement are at a relatively high level, then this task is regarded as a priority processing object during classification. During the classification process, if multiple tasks have the same urgency, then compare their respective bandwidth requirements. If the bandwidth requirements are also the same, then compare the latency requirements. Finally, summarize these judgment results and sort them from high to low according to the urgency, and synchronously record the bandwidth requirement and latency requirement parameters, and merge the obtained results to obtain the medical data task classification information.

[0026] The benefit of the formula is that it can perform unified operations on multiple numerical values such as urgency, bandwidth requirement, maximum latency, data volume size, and available bandwidth. Through a square root expression combined with the form of product and ratio, it makes the comprehensive judgment of task priority more flexible and targeted, and can accurately distinguish the order of important tasks according to the changes of each parameter.

[0027] The steps to obtain the parameters are as follows: Through the numerical record of the urgency in the medical data transmission requirement classification information obtained previously, unify the information such as the task background and the urgency grading system into numerical forms. When using the 3-level urgency classification, they respectively correspond to the numerical values 3, 2, and 1. When the task comes from the intensive care or surgical guidance scenario, record the numerical value 3; for routine examination tasks, record the numerical value 2; for ordinary data tasks, record the numerical value 1. In a medical center monitoring platform, collect a total of 80 transmission tasks in the past week. Among them, 32 are intensive care communication requests, and their urgency levels are all recorded as 3; 40 are routine examination data transmissions, and their urgency levels are all recorded as 2; the remaining 8 are low-priority information updates, and their urgency levels are recorded as 1.

[0028] The steps for obtaining the parameter are as follows. This value is used to express the task's requirements for the blockchain data storage space and transmission rate. Specifically, in the medical data task classification information obtained previously, record how much bandwidth the task occupies at peak and average values, and take half of the sum of the peak and average values as the final value. For example, if the peak bandwidth of a certain task reaches 80 Mbps and the average bandwidth is 40 Mbps, then Mbps can be used as the bandwidth requirement for this task. If the historical observation values are not comprehensive enough, the actual bandwidth occupancy of this task can be measured at multiple time intervals within 24 hours and values can be taken. The following gives an example. After observing a real-time video monitoring task for 7 days, the peak bandwidth is 115 Mbps and the average bandwidth is about 60 Mbps, then it can be calculated Mbps as the assignment.

[0029] The steps for obtaining the parameter are as follows. This value represents the maximum allowable delay of the task. When performing hierarchical management, the range from 500 ms to 2000 ms can be set as the normal interval, less than 500 ms can be set as a higher-level delay requirement, and more than 2000 ms is recorded as a lower-level delay requirement. When obtaining it, the registration can be carried out by testing the real-time requirement of this task. For example, if a video consultation connection only allows a maximum delay of 800 ms, then , if a remote case transmission is not sensitive to delay due to the large amount of data and allows a maximum delay of 3000 ms, then .

[0030] The steps for obtaining the parameter are as follows. This value represents the size of the task data volume and can be directly obtained from the actually observed file size or video traffic. If the data volume of a certain task reaches 300 MB, then , if the data volume of another task is 1.5 GB, then MB.

[0031] The steps for obtaining the parameter are as follows. This value represents the available bandwidth of the current network. Usually, it is necessary to refer to the network status overview or real-time measurement values obtained previously, and observe the network resource occupancy before the task is about to be scheduled. For example, if it is known from previous statistics that the remaining available bandwidth of the entire network is 120 Mbps, then .

[0032] Calculation process: Set a medical data task, whose urgency , task bandwidth requirement Mbps, maximum allowable delay ms, task data volume size MB, current network available bandwidth Mbps; First calculate , then calculate , then calculate , then add these two parts together to get , and finally take the square root, that is .

[0033] This result indicates that when is 189.736, it shows that the comprehensive priority of this task under the combined action of urgency, bandwidth requirements, latency, data volume, and available bandwidth is relatively high. If the value of other tasks is smaller, then this task is at a higher priority level.

[0034] Based on the priority index of medical data tasks, first read the corresponding value of each task from the previously obtained priority calculation results. If the value is found to be greater than 100, it is marked as a high-priority task. Here, 100 can be set by statistically analyzing past experience and comprehensively considering factors such as the importance of the emergency scenario. Then, summarize the priority indices of all tasks and sort them in descending order of value. If the difference in priority indices between some tasks is less than 10, further compare their differences in urgency or bandwidth requirements. In this comparison process, the urgency level and bandwidth requirement value each account for 50% of the weight. For example, if the priority indices of two tasks are 102 and 95 respectively, and the difference between them is within 10, but the difference in urgency level is large, then the task with a slightly higher index value and higher urgency is ranked first. If the urgency is also the same, then observe the matching degree between its bandwidth requirement and available bandwidth. When the ratio of bandwidth requirement to available bandwidth is higher than 0.8, it is regarded as a task with heavy bandwidth load. When the ratio is between 0.5 and 0.8, it is medium load, and less than 0.5 is light load. Based on this ratio, further sorting is done. After sorting, list them in descending order of value. At the top of the list is the task with the highest priority index, and at the bottom is the task with a lower priority index. Finally, organize the sorted results item by item and generate a priority adjustment instruction.

[0035] The steps to obtain the frequency-domain resource allocation strategy are as follows: According to the priority adjustment instruction, extract the bandwidth requirement value corresponding to the medical data sharing task and the value of the current blockchain data storage and access frequency situation, analyze the remaining space and rate range of the available data storage space and transmission resources in the current blockchain, and generate frequency-domain resource occupancy information; Based on the frequency-domain resource occupancy information, calculate the frequency-domain resource dynamic configuration index. The calculation formula is: ; Among them, Represents the dynamic configuration index of frequency domain resources, Represents the priority index of the medical data sharing task, Represents the amount of resources required by the medical data sharing task in the frequency domain, Represents the real-time packet loss rate of the medical data sharing task, Represents the occupied data storage space and transmission resource quantity within the current blockchain, Represents the total amount of data storage space and transmission resources of the current blockchain, Represents the transmission delay fluctuation value of the current medical data sharing task within a unit of time; Sort the dynamic configuration indexes of the frequency domain resources of the medical data sharing tasks from largest to smallest, and reallocate the required frequency domain resources of the medical data sharing tasks in sequence according to the sorting result to generate a frequency domain resource allocation strategy.

[0036] Specifically, according to the priority adjustment instruction, first read the previously obtained medical data sharing task list, and retrieve the bandwidth requirement value and the blockchain data storage and access frequency value of each task item by item. When retrieving the bandwidth requirement value, it can be obtained by combining the peak value and the average value actually monitored on the same day. For example, the bandwidth peak value of 60 Mbps and the average value of 30 Mbps of a video diagnosis task are weighted to obtain its bandwidth requirement value. The blockchain data storage and access frequency value is obtained from the previously summarized occupancy rate records of each frequency band. For example, within the frequency band range of 800 MHz to 2600 MHz, it is divided into several sub-intervals and the current usage rate of each interval is recorded. If it is found that the occupancy rate of a certain interval is greater than 40%, the occupancy rate is determined to be medium or above level and the available bandwidth is further verified. After completing the retrieval of the above data, it is necessary to analyze the remaining quantity of available frequency domain resources in combination with the actual business period and department allocation. The total available frequency bands can be detected by means of segmented statistics. When the detection shows that 30 frequency bands have been occupied and the total number of frequency bands is 80, it indicates that there are still 50 frequency bands available for allocation. If it is found that 10 of the remaining frequency bands belong to high interference intervals when further checking the frequency range of each remaining frequency band, these 10 frequency bands can be marked as having interference risks and temporarily recorded in a troubleshooting list. If it is detected that the occupancy rate of the remaining 40 frequency bands is lower than 20% in each interval, it is determined that these 40 frequency bands are basically idle. During this process, if the historical interference value of any frequency band exceeds a certain reference threshold, for example, the interference value is greater than -70 dBm, the frequency band can be regarded as having significant interference and marked for exclusion. The -70 dBm threshold can be determined by summarizing the power values of the interference signals measured successively during 200 hours of continuous operation of the device. After comparing the interference risks of all frequency bands, combining the available remaining frequency band quantity and its corresponding frequency range, for example, the number of available idle frequency bands in the range of 800 MHz to 900 MHz and the range of 1800 MHz to 1900 MHz are merged together. If the merged total is confirmed, the information of these idle frequency bands is integrated and combined with the bandwidth requirement value and the blockchain data storage and access frequency value. After completing the above analysis, the obtained statistical result is marked as the frequency domain resource occupancy information, and finally the corresponding output entry is generated to generate the frequency domain resource occupancy information.

[0037] The advantage of the formula is that it can integrate multiple values such as the priority index of the medical data sharing task, the required quantity of frequency domain resources, the real-time packet loss rate, the occupied quantity of frequency domain resources, the total quantity, and the delay fluctuation into a structure combining a cube root and a square root, and balance each participating quantity in the form of an upper and lower fraction, so as to dynamically weigh different types or scales of tasks during the allocation of frequency domain resources.

[0038] The steps to obtain the parameter are as follows. This parameter represents the priority index of the medical data sharing task and can directly use the value calculated previously.

[0039] The steps to obtain the parameter are as follows. This parameter represents the amount of resources required for the medical data sharing task in the frequency domain. It can be obtained by observing the bandwidth usage patterns of each task over a period of time and converting it into the number of occupied frequency bands. For example, in the range of 1800 MHz to 1900 MHz, the bandwidth of each frequency band is 1 MHz. When a certain task confirms that it needs to use 20 MHz of bandwidth, then set it to 20. When obtaining it, it is necessary to compare each allocable frequency band item by item and merge similar ranges. If the peak demand of a certain task is greater than 20 MHz, for example, the demand is 25 MHz, then set it to 25.

[0040] The steps to obtain the parameter are as follows. This parameter represents the real-time packet loss rate of the medical data sharing task. Its value can be between 0 and 1, indicating the ratio of the number of lost packets to the total number of sent packets. For example, in a data transmission, a total of 10,000 packets are sent and 120 packets are detected as lost. Then the real-time packet loss rate .

[0041] The steps to obtain the parameter are as follows. This parameter represents the occupied data storage space and transmission resource quantity in the current blockchain. In actual measurement, it can be statistically counted in units of each 1 MHz frequency band. For example, if it is detected that the frequency bands already allocated to other tasks or basic services reach 35, then .

[0042] The steps to obtain the parameter are as follows. This parameter represents the total amount of data storage space and transmission resources in the current blockchain. For example, in the range of 800 MHz to 1900 MHz, 200 1 MHz frequency bands are allocated for the medical data sharing task. If all are available, then , when obtaining it, it is necessary to first understand the total range of allocable frequency bands planned for this medical environment and statistically summarize the total number of all frequency bands. If there are other high-frequency or low-frequency bands available, the total number of these frequency bands needs to be added up. In an actual situation, if it is detected that there are only 180 actually available frequency bands, then .

[0043] The steps to obtain the parameter are as follows. This parameter represents the transmission delay fluctuation value of the current medical data sharing task per unit time. It can be obtained by taking the range or standard deviation of the transmission delay records collected once per second to get a value that can characterize the degree of fluctuation. For example, during monitoring, the minimum delay value of a certain task within 5 seconds is 30 ms, and the maximum value is 70 ms. Then the difference of 40 ms can be regarded as the current delay fluctuation. If the standard deviation method is to be used, the sum of the squares of multiple collected delay values can be divided by the number of samples and then square-rooted. For instance, if the standard deviation calculated after multiple measurements of the delay value is 20 ms, then 。

[0044] Calculation process: Now in a specific medical data sharing task, take , , , , , ,first calculate the numerator part , , ,then calculate the denominator part , , , , ,finally obtain 。

[0045] This result indicates that when ,under the current conditions of priority index, frequency domain resource requirements, packet loss rate, occupied resource quantity, total resource scale, and delay fluctuation, etc., the frequency domain resource dynamic configuration index of this medical data sharing task is not very high compared to other tasks. If the value calculated for another task within the same time period is greater than 0.3, it means that the demand of this other task for frequency domain resources and the status of the network environment it is in are more urgent, and it can be ranked in a more forward reallocation order.

[0046] Sort the frequency domain resource dynamic configuration indices of medical data sharing tasks from large to small. First, read the values obtained by all tasks in the above formula. For more than a dozen existing tasks, they can be arranged in sequence according to their respective values. When the adjacent difference of the value is lower than 0.05, it is necessary to further compare its priority index and check whether the packet loss rate recorded for this task before is too high. If exceeds 0.02, it is recorded as a relatively serious packet loss situation and the position of this task in the sorting can be improved. If If it is between 0.005 and 0.02, it can be regarded as the general state. After all tasks complete this process, match them one by one with the available frequency bands. When the demand is greater than the remaining frequency bands, this task will be temporarily recorded as demand overflow and will be queued again after other tasks are released or the allocation is delayed later. After all tasks complete the preliminary sorting, the largest task starts to obtain the most prioritized frequency band allocation right, and the remaining tasks match the feasible frequency bands in turn. If there is an occupancy conflict, then refer to , and for fine-tuning according to the differences. After all allocations are completed, summarize the corresponding relationships between each task and the corresponding frequency bands finally, and finally generate the frequency domain resource allocation strategy.

[0047] The steps to obtain the adjusted network performance data are as follows: Apply the blockchain-based data sharing resource allocation strategy to the blockchain system environment, execute the data storage space and transmission resource reallocation actions in the blockchain-based data sharing resource allocation strategy, and record the packet sending time and receiving time after the execution of the medical data sharing task in real time, calculate the transmission delay, and at the same time record the number of lost packets during the transmission to generate task transmission monitoring information; According to the task transmission monitoring information, calculate the network performance fluctuation index. The calculation formula is: ; Among them, represents the network performance fluctuation index, represents the delay of the medical data sharing task transmission, represents the number of lost packets during the medical data sharing task transmission, represents the average rate of the medical data sharing task under the adjusted frequency domain resources, represents the theoretical expected data transmission rate of the medical data sharing task, represents the bandwidth occupied by the network during the execution of the medical data sharing task, represents the total number of data packets transmitted by the medical data sharing task, represents the real-time signal-to-noise ratio during the execution of the medical data sharing task; According to the change amplitude of the network performance fluctuation index, determine the stability of the network performance after executing the frequency domain resource allocation strategy, and generate the adjusted network performance data.

[0048] Specifically, applying the blockchain-based data sharing resource allocation strategy to the blockchain system environment, first record the available bandwidth range and compare it with the frequency band occupancy information corresponding to the previously obtained medical data sharing tasks. When it is found that there is insufficient bandwidth redundancy or the frequency band interference value exceeds -70 dBm, mark this frequency band as unsuitable for allocation. Here, -70 dBm can be determined by measuring and collating the interference signal power during the 300-hour observation period of continuous device operation. During this process, if the usage duration ratio of a certain bandwidth range exceeds 60%, it is recorded as moderately occupied, and when the occupancy duration ratio reaches 80%, it is recorded as severely occupied. Whenever a new task is scheduled, check again whether there is any remaining bandwidth in the moderately or severely occupied frequency bands. When the remaining bandwidth is less than 10 MHz, skip this frequency band and turn to other available ranges. After the screening is completed, call the frequency band reallocation action. During the execution of this action, capture the packet sending time and receiving time for each medical data sharing task in sequence. For example, for task A, write a high-precision timestamp at the sending end, read the arriving timestamp at the receiving end and perform a subtraction operation. If the measured delay is within the range of 300 ms to 800 ms, it can be regarded as normal delay, and if it exceeds 800 ms, it is marked as high delay. At the same time, number all the packets generated during the transmission and record their missing sequence numbers. When it is found that the number is missing or the number of lost packets is greater than the previously set threshold of 50 based on historical records, it is regarded as significant packet loss and registered separately in the monitoring list. After the entire period ends, summarize the above sending and receiving times and the number of lost packets according to the task identifier, and thus integrate them into a set of delay and packet loss data for each medical data sharing task, and finally generate task transmission monitoring information.

[0049] The advantage of the formula is that it quantifies various factors such as delay, loss quantity, transmission rate deviation, occupied bandwidth, total number of packets, and real-time signal-to-noise ratio in the form of a combination of the fourth root and the cube root, taking into account both the direct impact of delay and loss and the indirect impact of bandwidth occupancy and transmission scale, thereby characterizing the degree of network performance fluctuations in multiple dimensions.

[0050] The steps to obtain the parameter are as follows. This parameter represents the latency of the medical data sharing task transmission and can be obtained by calculating the difference between the timestamps of sending and receiving. If there are significant differences in latency in multiple time periods observed in a day, the data for all time periods can be statistically analyzed in segments, and the latency value that appears most frequently within each segment can be used as a representative. When the latency value in some time periods is observed to exceed 400 ms, it can be considered high, and when it is lower than 100 ms, it can be considered low. This threshold is obtained from the analysis of test records executed continuously for up to 200 hours. During the test, the acceptance degree of the clinical service for latency is compared successively, and combined with the records of network latency of multiple batches of devices, it is finally determined that the range of 100 ms to 400 ms is the common range, and the parts exceeding 400 ms or lower than 100 ms are marked as abnormal areas. For example, if the latency value of a surgical guidance task is stable at about 300 ms, then can be brought into subsequent operations. If the average latency measured for another interaction system is about 220 ms, then can be recorded in the database.

[0051] The steps to obtain the parameter are as follows. This parameter represents the number of lost data packets during the transmission of the medical data sharing task. A consecutive number can be assigned to each data packet at the sending end and compared one by one at the receiving end. If a missing number is detected at the receiving end, it can be counted as a lost packet. When the total number of data packets sent during the observation period is fixed, the corresponding number of missing numbers directly reflects the situation of lost packets. If the recorded number of lost packets exceeds 200 during device monitoring, it can be considered obvious packet loss. This threshold of 200 can be statistically analyzed through the packet loss distribution sequence collected in the previous actual operating environment. For example, if the majority of packet losses for the same type of transmission task recorded in the previous week are concentrated between 0 and 150, those exceeding 150 indicate abnormality. If a remote monitoring task has 175 losses in 10,000 transmissions, then .

[0052] The steps to obtain the parameter are as follows. This parameter represents the average rate of the medical data sharing task under the adjusted frequency domain resources. After the frequency domain resource allocation is completed, the actual data transmission rate can be measured in segments. For example, the rate is collected once every ten seconds within two minutes, and the sum of these rate values is divided by the number of sampling times to obtain the average value. If most of the sampled values are around 15 Mbps, then can be recorded as 15 Mbps.

[0053] The steps for obtaining the parameter are as follows: this parameter is the theoretical expected data transmission rate of the medical data sharing task. The business requirements of the task itself need to be assessed before actual deployment. For example, taking the remote video inspection task as an example, the ideal rate range of 20Mbps to 30Mbps can often be calculated by referring to the video resolution and frame rate requirements, and combined with the detection data of the past two weeks for statistics. If most of such tasks hope to achieve 25Mbps, 25Mbps can be regarded as the theoretical expected rate. It is also possible to increase the value after conversion for higher resolution or more channels. In a typical case, the multiplex transmission of 1920×1080 resolution and 30 frames / s can be converted to an ideal value of about 25Mbps.

[0054] The parameter acquisition steps are as follows: this parameter represents the bandwidth occupied by the network during the execution of the medical data sharing task. The bandwidth usage can be monitored and the bandwidth occupied by the task over a period of time can be summed up in real time. When it is observed that the task connection is maintained in the 20MHz to 40MHz segment, the average value of 30MHz can be selected as records.

[0055] The steps to obtain the parameter are as follows: This parameter represents the total number of data packets transmitted by the medical data sharing task. When obtaining, the sender can count the number of all encapsulated and sent data packets. If the sender records 20,000 packets, then .

[0056] The steps for obtaining the parameter are as follows: the parameter represents the real-time signal-to-noise ratio during the execution of the medical data sharing task. When obtaining, the ratio of signal power to noise power is measured regularly at the receiving end, for example, once every five minutes within an hour, and these measured values ​​are averaged. If the overall signal-to-noise ratio is greater than 18dB, it can be considered relatively stable. When it is lower than 10dB, it is considered to require special attention. This division can refer to the common standards of communication equipment in this field. For example, in a certain medical scenario, 15dB to 25dB is generally recorded as a medium range, more than 25dB is recorded as high quality, and less than 15dB is recorded as low. If the measured average value in a certain period of time reaches 20dB, then In the following example, let .

[0057] Calculation process: In this example, let , , , , , , , first calculate the molecular part : , , , , and then calculate the denominator part :[[]] , , , .

[0058] Comprehensively obtain ; This result indicates that the current network performance fluctuation index is around 0.001375, tending to a relatively small degree of fluctuation. When the value exceeds 0.01, it can be prompted that there are obvious fluctuations in the network. When the value is lower than 0.001, it indicates slight fluctuations. By comparing with the values calculated during other time periods or other medical data sharing tasks, the network stability degree under the current frequency domain resource allocation strategy can be further evaluated.

[0059] According to the amplitude of the change in the network performance fluctuation index, first summarize the values within multiple time periods, and then quantify its change degree based on the difference between adjacent time periods. When the difference between the values of a certain time period and the previous time period is greater than 0.002, record this time period as a sharp increase in fluctuations. If the difference is between 0.001 and 0.002, it is marked as medium fluctuations, and if it is within 0.001, it is recorded as slight fluctuations. The 0.001 and 0.002 used here are obtained from the 200-hour long-term monitoring done before, and the common fluctuation range of the network under typical load is statistically analyzed and the mean value is used to determine the upper and lower floating values. After marking the fluctuation index for each time period within a day or a week, it is also necessary to combine the loss quantity and delay records of each medical data sharing task in the same time period. If there is a situation where the fluctuation index and the loss quantity are both high, a warning registration is carried out for this time period. If it is also observed that the delay exceeds 500 ms, it is further moved into the high-concern queue. After the network performance fluctuation analysis for all time periods is completed, the fluctuation levels and loss situations of each time period will be compared in chronological order, and finally a comprehensive record of the overall network performance after implementing the frequency domain resource allocation strategy will be obtained. After integrating all the results, the adjusted network performance data can be output.

[0060] The steps to obtain the evaluation result of the data sharing resource adjustment effect of the blockchain are as follows: According to the adjusted network performance data, calculate the stability index of the frequency domain adjustment effect. The calculation formula is: ; Among them, represents the stability index of the frequency domain adjustment effect, represents the standard deviation of the delay of the medical data sharing task before the frequency domain resource adjustment, represents the standard deviation of the delay of the medical data sharing task after the adjustment, represents the standard deviation of the number of packet losses of the medical data sharing task before the adjustment, represents the standard deviation of the number of packet losses of the medical data sharing task after the adjustment, represents the congestion ratio of the blockchain data transmission resources after the adjustment, represents the average throughput of the network performance before the adjustment, represents the average throughput of the network performance after the adjustment, represents the network performance fluctuation index; Based on the stability index of the frequency domain adjustment effect, judge the stability of the network performance after the frequency domain adjustment, conduct effect level division, analyze whether the effect of the frequency domain resource adjustment reaches the optimization expectation, and generate the evaluation result of the adjustment effect of the blockchain data sharing resources.

[0061] Specifically, the benefit of the formula is that it can comprehensively consider multi-level indicators such as the standard deviation of delay, the standard deviation of the number of packet losses, the network congestion ratio, the throughput, and the network performance fluctuation index. By combining the cube root and the square root, key elements such as delay improvement and packet loss variation are coupled with throughput growth and network fluctuation amplitude into the same expression, so as to measure the overall stability of the network performance after the frequency domain adjustment in different scenarios and output a value that is easy to compare in a quantitative manner.

[0062] The steps for obtaining the parameter are as follows. This parameter represents the standard deviation of the delay of the medical data sharing task before the frequency domain resource adjustment. It can be obtained by collecting the transmission delay values of the same medical data sharing task for a long time in the state without frequency domain resource adjustment and calculating the standard deviation. The delay is recorded every 10 seconds during the collection. If a total of 8640 transmission delays are observed in a day, these 8640 values can be statistically segmented and the results can be combined to obtain the overall distribution. In the final statistics, the calculation formula is used, where is the total number of samples, is the th delay value, is the average of all delay values. When is obtained, this value is assigned to . For example, in a remote imaging diagnosis scenario, the average value of the collected delay distribution is about 300 ms, and the calculated standard deviation is about 45 ms. Then can be set.

[0063] The steps to obtain the parameter are as follows. This parameter represents the adjusted standard deviation of the latency of the medical data sharing task. After the frequency-domain resource reallocation is completed, observations of the same task need to be carried out for the same duration and sampling frequency, and the standard deviation is calculated using the same formula to ensure comparability, the same observation interval as that during measurement should be maintained. If it is found at the end of the observation after adjustment that the average latency decreases or the fluctuation shrinks, the standard deviation may become smaller. For example, in comparison with the aforementioned remote imaging diagnosis scenario, after adjustment, 8640 data points are collected under the same conditions. If the average latency is around 280 ms and the fluctuation further decreases, and the standard deviation obtained through the same statistical process is 30 ms, then record .

[0064] The steps to obtain the parameter are as follows. This parameter represents the standard deviation of the number of lost packets in the medical data sharing task before adjustment. In an unoptimized network environment, the sender can be set to add consecutive numbers to each data packet and continuously monitor the corresponding reception situation. After collecting the number of lost packets for a period of time (such as 24 hours), calculate its standard deviation. If 10,000 packets are sent per hour for the same task, then 240,000 packets are sent in 24 hours. The number of lost packets can be counted at the end of each hour, and the standard deviation of these 24 data points of the number of lost packets is calculated. If the finally obtained standard deviation of the number of lost packets is 8 (indicating that the number of lost packets per hour fluctuates around its average value by about 8 packets), then let , and the specific calculation also uses , where represents the number of lost packets in the th hour, is the average value of the number of lost packets.

[0065] The steps to obtain the parameter are as follows. This parameter represents the standard deviation of the number of lost packets in the medical data sharing task after the frequency-domain resource adjustment. It is the same as the acquisition process, and the lost packets are also statistically counted hourly. It is only executed in a network environment where the frequency-domain resources have been optimized. If the average number of lost packets per hour of the collected transmission tasks decreases and the fluctuation decreases under the same transmission volume, and the standard deviation obtained after statistics is, for example, 4, then assign this result to . If 10,000 packets are sent per hour within a day, 240,000 packets are aggregated in 24 hours, and the same standard deviation operation is performed on the number of lost packets per hour. Finally, if the calculated result is 4, then let .

[0066] The steps to obtain the parameter are as follows. This parameter represents the congestion ratio of the adjusted blockchain data transmission resources. After reallocating the frequency domain resources, it is necessary to continuously monitor the occupancy of each frequency band and record the ratio of the actual occupancy duration to the total available duration of each frequency band. For example, several 1 MHz bandwidth cells are divided within the range of 800 MHz to 1800 MHz, and the number of minutes each cell is occupied by medical data tasks within one hour is counted. Then, the sum of the occupancy minutes of all cells is compared with the total available minutes to obtain an overall congestion ratio. The congestion ratio can be obtained by dividing the occupancy minutes by the available minutes. If the ratio of the occupancy minutes to the available minutes is observed to be 0.35, then 。

[0067] The steps to obtain the parameter are as follows. This parameter represents the average throughput of the network performance before adjustment. It can be obtained by comparing the total transmission volume with the total time interval within a period of time before the network is optimized. If a total of 180 GB of data (including various medical files and audio / video streams) is successfully transmitted in one day, and the total duration of this day is 24 hours, then it can be obtained by dividing the total available transmission volume (bits) by the total time (seconds). If the result is converted to 35 Mbps, then ,if another hospital has an average throughput of 60 Mbps due to its larger scale, then 。

[0068] The steps to obtain the parameter are as follows. This parameter represents the average throughput of the network performance after adjustment. After completing the adjustment of the frequency domain resource allocation, the same interval needs to be statistically analyzed, and the throughput is obtained by dividing the total transmission volume (bits) by the total time (seconds). If the total transmission volume reaches 220 GB on an optimized day and is also measured in 24 hours, and the result is converted to 50 Mbps, then 。

[0069] The steps to obtain the parameter are as follows. This parameter represents the network performance fluctuation index, which has been calculated in the previous link.

[0070] Calculation process: In this example, let , , , , , , , ,first calculate the numerator part : , , , , ; Multiply the above parts , , then calculate the denominator part : , , , , and comprehensively obtain: .

[0071] This result indicates that the stability index of the current frequency-domain adjustment effect is 0.3766, which expresses the comprehensive balance of multiple factors such as the change range of delay and packet loss, network congestion ratio, throughput, and fluctuation index after the adjustment of frequency-domain resources. If the value exceeds 0.5, it can be regarded as a significant improvement in network stability. If it is less than 0.2, it may indicate that there is still much room for improvement in the adjustment effect. Here, 0.3766 belongs to the upper-middle level, and it can be compared horizontally with the values of other tasks and determine the next resource optimization method.

[0072] Based on the stability index of the frequency-domain adjustment effect, first, align all the recorded standard deviations of the delay before and after adjustment, the standard deviation of the packet loss quantity, and the change value of the network throughput of each medical data sharing task in the past 24 hours in terms of time. Segment all the records at hourly intervals, and respectively read the standard deviation value of the delay, the standard deviation value of the packet loss, and the average throughput within this time period, and correlate them with the existing network performance fluctuation index on the same time line. After completing the alignment of the monitoring data in units of every hour or every two hours, calculate the value for each time period according to the above formula, and arrange the calculation results hour by hour to form a time series. When the value in any time period is below 0.2, mark this time period as having a low adjustment result. If is higher than 0.5, mark it as having a good adjustment result, and divide the part between 0.2 and 0.5 into the general level. Here, 0.2 and 0.5 are set by analyzing the results of multiple network environment tests in the past three months and selecting the numerical range that can best distinguish the network stability. When the values and their grade assignments for all time periods are completed, the details of the low-grade time periods can be taken out and re-verified in combination with the congestion ratio and throughput of this time period. If it is found that most low-grade time periods have experienced insufficient bandwidth or increased packet loss fluctuations, summarize these problem time periods and create a list of requirements for subsequent resource readjustment or bandwidth expansion. It is also possible to generate an overall adjusted network performance graph after marking all time periods, showing the The curve is plotted on the same coordinate axis as other transmission performance indicators, from which the stability change trend after the adjustment of frequency domain resources can be clearly presented and whether each period is optimized can be compared. Finally, the evaluation conclusions of several links are sorted out from all the data, and according to the evaluation conclusions, it is judged whether the current adjustment effect of frequency domain resources meets the pre-determined service requirements. If it is satisfied, it is recorded as the result of passing the optimization. Otherwise, the unqualified links are listed in the requirement list, and finally the evaluation result of the adjustment effect of the data sharing resources of the blockchain is generated.

[0073] Based on the evaluation result of the adjustment effect of the data sharing resources of the blockchain, the steps to continue optimizing the frequency domain resource allocation and continuously monitoring the network status and the medical data transmission efficiency are as follows: Based on the evaluation result of the adjustment effect of the data sharing resources of the blockchain, record the task information that fails to meet the optimization target and generate a list of tasks to be optimized; According to the list of tasks to be optimized, analyze the transmission delay values, the number of lost data packets, and the frequency band congestion ratio values corresponding to the medical data sharing tasks, and re-adjust the frequency domain resource allocation methods corresponding to each medical data sharing task.

[0074] Specifically, based on the evaluation results of blockchain-based data sharing resource adjustment effects, first, extract all the medical data sharing task identifiers that do not meet the preset targets in terms of latency, packet loss quantity, or throughput metrics from the previously obtained evaluation conclusions. Then, summarize these task identifiers according to task type, demand level, and business scenario. During the summarization process, it is necessary to check the collection date and running period of each non-compliant task. For example, if the average latency value of a certain surgical assistance task continuously exceeds 300 ms within a day and its allowable range is 300 ms to 500 ms, then the latency performance of this task can be marked as not meeting the initially set qualified range. If its average packet loss quantity is more than 200 packets per 10,000 packets and exceeds the floating standard of 150 to 200 packets statistically obtained in the previous tests of this hospital, this task should also be listed as having abnormal packet loss. At the same time, compare the throughput of this task with the previously set range of 10 Mbps to 30 Mbps. If the result is below 10 Mbps or above 30 Mbps, it is necessary to recheck whether there is a conflict between its actual rate and medical needs. After all tasks have completed similar comparisons, it is possible that multiple tasks do not meet the standards on the same day or in adjacent time periods. At this time, arrange all these tasks in a comparison list and mark their specific reasons for non-compliance. If some tasks only deviate from the range in terms of the packet loss index, while the latency and throughput are within the normal range, they are separately recorded as packet loss to be optimized. If some tasks do not meet the standards in both the latency and packet loss indicators, they are grouped into multiple items to be optimized. After summarizing all the marked tasks, generate a list of tasks to be optimized, and attach the specific values and time periods seen in the previous evaluation to each task in this list. In this way, these non-compliant items can be quickly called when these tasks are managed or adjusted again later, and finally obtain a list of tasks to be optimized.

[0075] According to the task list to be optimized, first read the transmission delay values recorded in each task in sequence, and then compare these delays with the established target range. For example, if the target range is between 200 ms and 600 ms and a certain task exceeds 800 ms multiple times during a one-hour monitoring, it needs to be listed separately and check whether there has been a sudden increase in the sending bandwidth during this period. At the same time, retrieve the packet loss quantity corresponding to these tasks and compare it with the benchmark of 200 to 300 packets set during the previous statistics. If the actual packet loss quantity is around 500 packets, it is marked as a high packet loss state. Combine this state with the task urgency and bandwidth requirements for analysis. Then, check the frequency band congestion ratio value. The congestion ratio can be summarized by time period in several frequency bands within the range of 800 MHz to 1800 MHz. When the congestion ratio of a certain frequency band exceeds 0.6 continuously for one hour and the bandwidth requirement relied on by this task is greater than 20 MHz during the same period, it indicates that the frequency band resource scheduling in this paragraph is insufficient and needs to be preferentially allocated or switched to other intervals with lower congestion ratios. If it is detected that the transmission delay of this task also fluctuates violently within the same hour period, it can be judged that there is an obvious resource imbalance in this service. After completing the cross-comparison of parameters such as delay, packet loss, congestion ratio, and bandwidth requirements, re-evaluate the frequency domain resources currently used by this task according to the superimposed information and search for idle or low-congestion intervals in the available frequency band list. If a more suitable interval is found, switch the frequency domain resource configuration of this task to this interval and record the switching time and the expected allocation duration. When all tasks have completed the analysis of delay, packet loss, and congestion indicators and implemented resource reallocation according to this process, integrate the final allocation results of each task and the corresponding allocation time period sequence to obtain the frequency domain resource allocation method corresponding to each medical data sharing task after readjustment.

[0076] The above is only a preferred embodiment of the present invention, and it does not limit the present invention in other forms. Any person skilled in the art may use the technical content disclosed above to make changes or modifications into equivalent embodiments with equivalent changes and apply them to other fields. However, as long as it does not depart from the technical solution content of the present invention, any simple modification, equivalent change, and modification made to the above embodiments based on the technical essence of the present invention still fall within the protection scope of the technical solution of the present invention.

Claims

1. A medical data sharing method based on blockchain, characterized in that: The following steps are involved: Based on the data status information monitored in real time by blockchain nodes, collect blockchain data storage, access frequency and network traffic, and obtain an overview of the current network status; Based on the current network status overview, a support vector machine model is used to process data, predict the blockchain system load and data transmission requirements, and obtain a blockchain system load prediction result; Based on the load prediction results of the blockchain system, the data transmission requirements are analyzed, high-priority medical data sharing tasks are determined, and priority adjustment instructions are generated; according to the priority adjustment instructions, the frequency domain resource allocation strategy is dynamically adjusted, the use of frequency resources is reconfigured, and the frequency domain resource allocation strategy is generated; Apply the blockchain-based data sharing resource allocation strategy to the blockchain system environment, monitor the adjusted transmission delay and data packet loss rate, and obtain the adjusted network performance data; analyze the adjusted network performance data, evaluate the effect of frequency domain resource adjustment, and generate the blockchain data sharing resource adjustment effect evaluation result; Based on the evaluation results of the data sharing resource adjustment effect of the blockchain, the frequency domain resource allocation is continuously optimized, and the network status and medical data transmission efficiency are continuously monitored.

2. The blockchain-based medical data sharing method according to claim 1, characterized in that: The steps for obtaining the current network status overview are: Based on the data status information monitored in real time by the blockchain nodes, the data storage occupancy of the blockchain nodes is monitored in real time, the storage occupancy ratios corresponding to different data storage areas are recorded, and the occupancy ratios of each frequency band are classified and sorted, and network frequency occupancy ratio information is established to generate blockchain data storage and access frequency information; Based on the data storage and access frequency of the blockchain, the total amount of data uploaded and downloaded in the blockchain is counted in real time, the data upload amount and download amount are recorded respectively, and real-time network traffic information is established; Based on the real-time network traffic information, the stability of data transmission between blockchain nodes, the data conflict level and the data transmission accuracy are detected in real time, and the signal strength, interference level and signal-to-noise ratio are recorded to form an overview of the current network status.

3. The blockchain-based medical data sharing method according to claim 1, characterized in that: The steps for obtaining the load prediction result of the blockchain system are as follows: Based on the current network status overview, according to information such as blockchain data storage and access frequency, data upload and download volume, and data transmission stability, time series features are established, data smoothing is performed on blockchain data storage and access frequency and network traffic, and data noise reduction is performed on network signal quality information to form network status feature information; Based on the network status characteristic information, the historical blockchain system load and the historical data transmission demand are called, and the regression relationship between the network status characteristic information and the historical blockchain system load, and the regression relationship between the network status characteristic information and the historical data transmission demand are respectively calculated through the support vector machine model to form a blockchain system load and data transmission demand prediction model; Based on the blockchain system load and data transmission demand prediction model, the network status characteristic information is called to calculate the blockchain system load and data transmission demand in the future period respectively, and generate a blockchain system load prediction result.

4. The blockchain-based medical data sharing method according to claim 1, characterized in that: The steps of obtaining the priority adjustment instruction are as follows: Based on the load prediction result of the blockchain system, the data sharing tasks are divided and sorted according to the urgency of the medical data sharing needs, and the bandwidth requirements and delay requirements corresponding to each medical data sharing task are extracted to form medical data task classification information; According to the medical data task classification information, the priority index of the medical data sharing task is calculated, and the expression is: ； in, is the priority index of medical data sharing tasks, The urgency of the task, The task requires blockchain data storage space and transmission rate. is the maximum delay allowed for the task, is the task data size, The current network available bandwidth; Based on the priority indexes of the medical data sharing tasks, the priority indexes of the medical data sharing tasks are arranged in descending order to generate a priority adjustment instruction.

5. The blockchain-based medical data sharing method according to claim 1, characterized in that: The steps for acquiring the frequency domain resource allocation strategy are: According to the priority adjustment instruction, the blockchain data storage space and transmission rate requirement values ​​corresponding to the medical data sharing task and the current blockchain data storage and access frequency values ​​are extracted, the remaining space and rate range of the current blockchain available data storage space and transmission resources are analyzed, and the frequency domain resource occupancy information is generated; Based on the frequency domain resource occupancy information, the frequency domain resource dynamic configuration index is calculated, and the calculation formula is: ； in, represents the frequency domain resource dynamic configuration index, Represents the priority index of medical data sharing tasks, represents the number of resources required for the medical data sharing task in the frequency domain, The real-time packet loss rate of the medical data sharing task. Represents the amount of data storage space and transmission resources currently occupied in the blockchain. Represents the total amount of current blockchain data storage space and transmission resources. Represents the transmission delay fluctuation value of the current medical data sharing task per unit time; The frequency domain resource dynamic configuration indexes of the medical data sharing tasks are sorted from large to small, and the frequency domain resources required by the medical data sharing tasks are reallocated in turn according to the sorting results to generate a frequency domain resource allocation strategy.

6. The blockchain-based medical data sharing method according to claim 1, characterized in that: The steps for obtaining the adjusted network performance data are as follows: The blockchain-based data sharing resource allocation strategy is applied to the blockchain system environment, the data storage space and transmission resource reallocation action in the blockchain-based data sharing resource allocation strategy is executed, and the data packet sending time and receiving time after the execution of the medical data sharing task are recorded in real time, the transmission delay is calculated, and the number of data packets lost during the transmission is recorded, and task transmission monitoring information is generated; According to the task transmission monitoring information, the network performance fluctuation index is calculated, and the calculation formula is: ； in, Represents the network performance fluctuation index, represents the delay in the transmission of medical data sharing tasks, Represents the number of data packets lost during the transmission of medical data sharing tasks, represents the average rate of the medical data sharing task under the adjusted frequency domain resources, represents the theoretical expected data transmission rate for medical data sharing tasks, represents the bandwidth occupied by the network during the execution of the medical data sharing task, Represents the total number of data packets transmitted by the medical data sharing task, represents the real-time signal-to-noise ratio of the medical data sharing task during execution; According to the amplitude of the change of the network performance fluctuation index, the stability of the network performance after executing the frequency domain resource allocation strategy is determined, and the adjusted network performance data is generated.

7. The blockchain-based medical data sharing method according to claim 1, characterized in that: The steps for obtaining the evaluation results of the adjustment effect of the data sharing resources of the blockchain are as follows: According to the adjusted network performance data, the frequency domain adjustment effect stability index is calculated, and the calculation formula is: ； in, Represents the stability index of frequency domain adjustment effect, represents the standard deviation of medical data sharing task delay before frequency domain resource adjustment, represents the adjusted standard deviation of medical data sharing task delay, represents the standard deviation of the number of packet losses in the medical data sharing task before adjustment, represents the standard deviation of the number of packet losses in the medical data sharing task after adjustment, Represents the adjusted congestion ratio of blockchain data transmission resources, Represents the average throughput of the network performance before adjustment, Represents the average throughput of the adjusted network performance, Represents the network performance fluctuation index; Based on the frequency domain adjustment effect stability index, the network performance stability after the frequency domain adjustment is judged, the effect level is divided, and it is analyzed whether the frequency domain resource adjustment effect meets the optimization expectations, and the data sharing resource adjustment effect evaluation result of the blockchain is generated.

8. The blockchain-based medical data sharing method according to claim 1, characterized in that: Based on the evaluation results of the data sharing resource adjustment effect of the blockchain, the steps of continuing to optimize frequency domain resource allocation and continuously monitoring network status and medical data transmission efficiency are as follows: Based on the evaluation results of the adjustment effect of the data sharing resources of the blockchain, record the task information that has not reached the optimization target and generate a list of tasks to be optimized; According to the list of tasks to be optimized, the transmission delay values, the number of packet losses and the frequency band congestion ratio values ​​corresponding to the medical data sharing tasks are analyzed, and the frequency domain resource allocation methods corresponding to each medical data sharing task are readjusted.

Images