A check-based medical data synchronization processing method and system

Abstract

The application provides a check-based medical data synchronization processing method and system, belonging to the technical field of big data processing. The method adopts a fast hash check algorithm to complete lightweight and efficient checking for small amount of text data, which can guarantee the integrity of the text data while improving the checking efficiency of small amount of data; the large amount of image data is processed in blocks to generate multiple image data subblocks, so that the number of checks corresponding to the image data subblocks of different data amounts is dynamically adjusted, which not only avoids resource waste and efficiency loss caused by uniform high-intensity checking, but also guarantees the integrity of the image data through targeted checking. At the same time, based on the priority transmission sequence, each image data subblock is sent in multiple channels in parallel, which improves the overall medical data synchronization speed, especially meets the fast transmission demand of medical data in the emergency treatment scene, and significantly improves the data sharing efficiency and medical service response speed between medical institutions.

Description

Technical Field

[0001] This application belongs to the field of big data processing technology, specifically relating to a verification-based medical data synchronization processing method and system. Background Technology

[0002] Currently, in the field of medical informatics, data synchronization and sharing have irreplaceable value in improving diagnostic and treatment efficiency and ensuring patient safety. Medical data, as the foundation of collaboration between medical institutions, encompasses various types, from medical records to imaging data, and its accuracy and completeness directly affect the reliability of medical decisions. However, existing methods for medical data synchronization cannot dynamically adjust verification strategies based on data volume, leading to excessive time and resources consumed when processing data of different scales. This severely reduces the speed of medical data synchronization and may even affect the timeliness of medical services.

[0003] The information described in the background section is only for enhancing the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] To address the above issues, this application provides a verification-based medical data synchronization processing method and system to solve the problem of not being able to dynamically adjust the verification strategy according to the data volume.

[0005] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0006] In a first aspect, embodiments of this application provide a verification-based medical data synchronization processing method, the method comprising: acquiring medical data to be synchronized, the medical data to be synchronized including text data and image data; determining each text verification data group based on the text data; and determining each image verification data group based on the image data; if the data volume of the text verification data group does not exceed a preset text data volume threshold, then the current text verification data group is considered as a qualified text; if the data volume of the image verification data group exceeds a preset image data volume threshold, then the current image verification data group is segmented to generate multiple image data sub-blocks, and the data volume of each image data sub-block is determined as a qualified text. The system determines the number of verifications for each image data sub-block; obtains the emergency treatment response value for each image data sub-block, and determines the comprehensive score for each image data sub-block based on the number of verifications and the emergency treatment response value; sorts the comprehensive scores from maximum to minimum to generate a priority transmission sequence, and sends each image data sub-block using multiple transmission channels based on the priority transmission sequence; if the image data sub-block in the current transmission channel passes verification, the current image data sub-block is determined as a qualified image data sub-block; and generates a complete synchronous medical data packet based on each qualified text and each qualified image data sub-block.

[0007] Secondly, embodiments of this application provide a verification-based medical data synchronization processing system, comprising: an acquisition module, a first determination module, a second determination module, a third determination module, a fourth determination module, a first generation module, a fifth determination module, and a second generation module. The acquisition module is used to acquire medical data to be synchronized, including text data and image data; the first determination module is used to determine each text verification data group based on the text data and each image verification data group based on the image data; the second determination module is used to, if the data volume of the text verification data group does not exceed a preset text data volume threshold, then consider the current text verification data group as a valid text; the third determination module is used to, if the data volume of the image verification data group exceeds a preset image data volume threshold, then divide the current image verification data group to generate multiple image data sub-blocks, and determine the number of verifications corresponding to each image data sub-block based on the data volume of each image data sub-block; the fifth determination module is used to, if the data volume of the image verification data group exceeds a preset image data volume threshold, then divide the current image verification data group to generate multiple image data sub-blocks, and determine the number of verifications corresponding to each image data sub-block based on the data volume of each image data sub-block; the sixth determination module is used to, if the data volume of the image verification data group exceeds a preset image data volume threshold, divide the current image verification data group to generate multiple image data sub-blocks, and determine the number of verifications corresponding to each image data sub-block based on the data volume of each image data sub-block; the fifth determination module is used to, if the data volume of the image data sub-block exceeds a preset image data volume threshold, divide the image data sub-block into multiple image data sub-blocks, and determine the number of verifications corresponding to each image data sub-block. The fourth determination module is used to obtain the emergency treatment response value corresponding to each of the image data sub-blocks, and determine the comprehensive score corresponding to each of the image data sub-blocks based on the number of verifications and the emergency treatment response value; the first generation module is used to sort the comprehensive scores in order from the maximum value to the minimum value to generate a priority transmission sequence, and send each of the image data sub-blocks using multiple transmission channels based on the priority transmission sequence; the fifth determination module is used to determine the current image data sub-block as a qualified image data sub-block if the image data sub-block in the current transmission channel passes the verification; the second generation module is used to generate a complete synchronous medical data packet based on each qualified text and each qualified image data sub-block.

[0008] This application provides a verification-based medical data synchronization processing method and system. It can perform lightweight and efficient verification using a fast hash algorithm for small-volume text data, maximizing verification efficiency for small data sets while ensuring data integrity. For large-volume image data, it divides the data into blocks to generate multiple image data sub-blocks, dynamically adjusting the verification count based on the size of each sub-block. This avoids the resource waste and efficiency loss caused by uniform high-intensity verification, while ensuring image data integrity through targeted verification. Furthermore, based on a priority transmission sequence, it uses multi-channel parallel transmission of each image data sub-block, improving the overall medical data synchronization speed, especially meeting the rapid transmission needs of medical data in emergency treatment scenarios, and significantly improving data sharing efficiency and medical service response speed between medical institutions. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in an exemplary embodiment of this application; Figure 2 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in another exemplary embodiment of this application; Figure 3 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in another exemplary embodiment of this application; Figure 4 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in another exemplary embodiment of this application; Figure 5 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in another exemplary embodiment of this application; Figure 6 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in another exemplary embodiment of this application; Figure 7 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in another exemplary embodiment of this application; Figure 8 This is a flowchart illustrating a verification-based medical data synchronization processing method provided in another exemplary embodiment of this application. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solution, the present application will be described in detail below with reference to the embodiments. The description in this section is only exemplary and explanatory, and should not be used to limit the scope of protection of the present application in any way.

[0012] Currently, in the field of medical informatics, data synchronization and sharing have irreplaceable value in improving diagnostic and treatment efficiency and ensuring patient safety. Medical data, as the foundation of collaboration between medical institutions, encompasses various types, from medical records to imaging data, and its accuracy and completeness directly affect the reliability of medical decisions. However, existing methods for medical data synchronization cannot dynamically adjust verification strategies based on data volume, resulting in excessive time and resources consumed when processing data of different scales. This severely reduces the speed of medical data synchronization, impacts the timeliness of medical services, and consequently reduces the efficiency of data sharing between medical institutions and the responsiveness of medical services.

[0013] Specifically, the requirements and resource consumption for verification are completely different for a few gigabytes of text reports and several gigabytes of image files. This difference makes it difficult for a uniform verification method to meet the needs, leading to a situation where, when dealing with large-scale data, the verification process may severely slow down the synchronization speed due to excessive resource consumption, and even affect the timeliness of medical services. This difference in data volume also brings about a contradiction between verification strength and efficiency. The higher the verification strength, the more guaranteed the data integrity, but the synchronization time will also be significantly extended, especially when processing image data. If every part is meticulously verified, the transmission efficiency will drop significantly. For example, in an emergency, a hospital needs to quickly obtain patient image data from another institution for consultation. If the transmission is delayed due to excessive verification time, it may directly affect the timing of treatment.

[0014] Therefore, how to dynamically adjust the verification strategy according to the size of medical data in order to minimize the synchronization time while ensuring the integrity of medical data has become a technical problem that needs to be solved in the field of big data processing technology.

[0015] This application provides a verification-based medical data synchronization processing method, such as... Figure 1 The illustrated method is a verification-based medical data synchronization process. This method may include the following steps: Step S110: Obtain the medical data to be synchronized, which includes text data and image data; Step S120: Determine each text verification data group based on the text data, and determine each image verification data group based on the image data; Step S130: If the amount of data in the text verification data group does not exceed the preset text data amount threshold, then the current text verification data group is regarded as the text that has passed verification. Step S140: If the amount of data in the image verification data group exceeds the preset image data amount threshold, the current image verification data group is divided into multiple image data sub-blocks, and the number of verifications corresponding to each image data sub-block is determined according to the amount of data in each image data sub-block. Step S150: Obtain the emergency treatment response value corresponding to each image data sub-block, and determine the comprehensive score corresponding to each image data sub-block based on the number of verifications and the emergency treatment response value; Step S160: Sort the comprehensive scores in order from the maximum value to the minimum value to generate a priority transmission sequence, and send each image data sub-block using multiple transmission channels based on the priority transmission sequence; Step S170: If the image data sub-block in the current transmission channel passes the verification, then the current image data sub-block is determined as a qualified image data sub-block. Step S180: Generate a complete synchronized medical data package based on each valid text and each valid image data sub-block.

[0016] According to the verification-based medical data synchronization processing method provided in this application, this method can perform lightweight and efficient verification of small-volume text data using a fast hash algorithm, maximizing the verification efficiency of small data volumes while ensuring the integrity of text data. For large-volume image data, it divides the data into blocks to generate multiple image data sub-blocks, dynamically adjusting the verification count based on the size of each sub-block. This avoids the resource waste and efficiency loss caused by uniform high-intensity verification, while ensuring the integrity of image data through targeted verification. Furthermore, based on a priority transmission sequence, it uses multi-channel parallel transmission of each image data sub-block, improving the overall medical data synchronization speed, especially meeting the rapid transmission needs of medical data in emergency treatment scenarios, and significantly improving the data sharing efficiency and medical service response speed between medical institutions.

[0017] The steps of the verification-based medical data synchronization processing method provided in this application are described in detail below: In one embodiment of this application, step S110 involves acquiring medical data to be synchronized, which includes text data and image data. Specifically, the medical data to be synchronized can be acquired through the medical big data processing system of a medical institution. For example, taking the cross-institutional medical data synchronization of a tertiary hospital as an example, the hospital needs to synchronize the patient diagnosis and treatment data of the Department of Cardiology to a remote consultation center for remote expert consultation. By connecting with the hospital information system and the laboratory information system, the patient's text data is extracted, which may include structured text reports of electronic medical records, complete blood routine and biochemical test reports, text reports of cardiac ultrasound examinations, treatment plan records, medication lists, etc. Specifically, through standard medical data exchange protocols (such as HL7, FHIR) or database middleware, a data connection channel with each system is established, patient identifier mapping rules are configured, and cross-system data query and extraction based on patient ID is realized. Using the patient's unique medical record number or visit number as the query key, a structured query request is sent to the connected hospital information system and laboratory information system, the returned result set is received, and converted into text data in a unified format according to the data field mapping table. The text data can be in formats such as PDF, TXT, and Excel, with a total data size of approximately 9.2MB. Then, the patient's image data is extracted through the image archiving and communication system. This data may include, for example, coronary artery imaging files and cardiac MRI images. The coronary artery images consist of 320-slice scans, totaling approximately 15GB, while the cardiac MRI images consist of 128-slice scans, totaling approximately 8GB. Both images are in medical imaging-specific DCM and DICOM formats. Finally, the text and image data are structured and categorized to generate a synchronized medical dataset containing both types of data. Specifically, the extracted text and image data are parsed, field-mapped, and labeled according to a pre-defined data model (such as JSON or XML). The text data is categorized into a "text data" subset, and the image data into an "image data" subset. These subsets are then merged to generate a synchronized medical dataset containing both types of data. The medical institution's big data processing system refers to a comprehensive platform that integrates data sources such as hospital information systems, laboratory information systems, and image archiving and communication systems for the collection, storage, processing, and analysis of medical data. The hospital information system is used to manage the hospital's clinical, administrative, and financial operations. In this embodiment, it is mainly used to acquire text data such as electronic medical records, treatment plans, and medication lists. The laboratory information system is used to manage data from the laboratory department. In this embodiment, it is mainly used to acquire test report data such as complete blood counts and comprehensive biochemical assays. The image archiving and communication system is used to store, manage, and transmit medical imaging data. In this embodiment, it is used to acquire image data such as coronary artery images and cardiac MRI images.

[0018] In one embodiment of this application, in step S120, each text verification data group is determined based on the text data. Specifically, preprocessing operations can be performed on all separated text data. First, the storage format of the text data is unified, and text data containing different formats such as PDF, TXT, and Excel is processed for format compatibility. Then, invalid text data that is incomplete, damaged, or missing content is removed. The separated text data refers to text-type data obtained after classifying and processing the medical data to be synchronized according to data type. Specifically, this includes parsing the medical data to be synchronized using data type identification rules, identifying structured or semi-structured data in file formats such as PDF, TXT, and Excel as text data, and storing them separately from the image data. Format compatibility processing includes converting text data of different formats into a unified data parsing structure. Specifically, this involves using a format parser to extract text from PDF files, parse cells from Excel files, and perform encoding standardization processing on TXT files, and then uniformly converting them into structured JSON or XML format data for subsequent unified verification processing. Invalid text data that is incomplete, damaged, or lacks content is removed. This means that a file is marked as "damaged" if it cannot be opened or parsed normally by the corresponding parsing library; marked as "missing content" if the parsed content length is 0 or key fields (such as patient ID) are completely missing; and marked as "incomplete" if the file size is abnormal (smaller than the minimum threshold for a normal file). Data meeting any of these conditions is removed from the verification queue. For example, text data may include electronic medical records, laboratory test reports, clinical medication lists, and treatment protocol records from internal medicine, surgery, or orthopedics departments. The above text data underwent preprocessing. PDF electronic medical records, Excel lab reports, and TXT medication lists were format-compatible. Three biochemical lab reports with incomplete content due to system malfunctions were removed. The valid text data was then divided into three groups based on the department of visit: internal medicine, surgery, and orthopedics. The internal medicine group contained 80 electronic medical records, 50 blood routine test reports, and 30 medication lists; the surgery group contained 60 electronic medical records, 40 biochemical test reports, and 25 medication lists; and the orthopedics group contained 55 electronic medical records, 35 imaging examination reports, and 20 medication lists.

[0019] In one embodiment of this application, step S120, which determines each image verification data group based on the image data, further includes the following steps: Figure 2 As shown, the specific content is as follows: Step S210: Based on the image data, use a fast hash algorithm to perform integrity verification and generate the first verification data; Step S220: Based on the first verification data, use a DICOM parser to perform compliance verification and generate the second verification data; Step S230: Determine the pixel matrix based on the second verification data, and determine each image verification data group based on the pixel matrix using fast sampling verification.

[0020] Specifically, all separated image data can be obtained, preserving the complete binary content and original DICOM format structure of the image files, while removing incomplete image files caused by storage corruption or transmission interruption. Then, a fast hash algorithm adapted to the characteristics of medical image big data is selected to perform byte-by-byte operations on the complete binary content of each image data, generating a unique and irreversible hash value for each image data. This hash value serves as the first verification data, a unique digital identifier for the integrity of the image data. Finally, the generated first verification data is compared with the pre-stored standard hash value of the image data. If they match, it indicates that the image data content has not been tampered with, is missing, or damaged, and the integrity verification is passed. The standard hash value refers to the hash value pre-calculated and stored from the original data using the same fast hash algorithm during the generation or storage of medical data, serving as a benchmark for subsequent integrity verification. In this embodiment, the standard hash value can be stored in the metadata database of the medical big data system or a blockchain evidence storage platform.

[0021] Furthermore, image data matching the first verification data with the standard hash value can be selected as the data to be processed for compliance verification. Specifically, the first verification data result set of all image data is traversed, and the "match" flag for each record is checked to ensure it is true. The matching record ID is then stored in the compliance verification queue. Subsequently, a DICOM parser specifically for the medical imaging field can be used to parse and verify the DICOM file header metadata and data structure of each image data to be processed. The verification content includes whether the image sequence number is continuous, whether the patient ID and image identifier are consistent, and whether the image acquisition parameters (such as slice thickness, tube voltage, and scan frame rate) comply with clinical examination standards. Next, the parsing and verification results are structured and quantified to generate structured data including core information such as metadata compliance identifiers, sequence number continuity identifiers, and acquisition parameter compliance identifiers. This structured data is the second verification data. Structured quantification includes converting the parsing and verification results into structured field identifiers, where each verification item corresponds to a status identifier bit, which includes "compliant" or "abnormal," and is stored in key-value pairs to form the second verification data. If all identifiers in the second verification data are "compliant", then the compliance verification has passed. The DICOM parser is a parsing module used to parse DICOM standard format files. It reads the DICOM file header tag information, parses the image metadata fields, and extracts image sequence information, patient identification information, and acquisition parameter information.

[0022] Furthermore, image data that meets the second verification criteria can be filtered out. A DICOM parser is used to extract the core pixel matrix from the image data. Specifically, the DICOM parser reads the Pixel Data tags in the image data and parses them into a two-dimensional or three-dimensional matrix data structure to represent the pixel grayscale value distribution of the image. This pixel matrix is ​​the visual core of the image data, directly reflecting key visual information such as lesions and tissues required for clinical diagnosis and treatment. Subsequently, a fast sampling verification algorithm is used to randomly sample the pixel matrix. Specifically, based on a random number generation algorithm, a number of pixels are randomly selected from the pixel matrix according to a preset sampling ratio, and the values ​​of the selected pixels are verified to evaluate the data validity of the overall pixel matrix. The sampling ratio can be set according to medical image verification principles; for example, it can be set to 0.1% to ensure accurate reflection of the numerical validity of the entire pixel matrix without consuming excessive computing resources. Then, the extracted pixel values ​​are verified to determine whether they are within the reasonable medical numerical range for the corresponding image type. Reasonable medical numerical ranges are determined based on a pre-defined medical imaging parameter standard library. Different image types correspond to different numerical ranges; CT images use the Hounsfield unit range standard, while MRI images use the signal intensity range standard corresponding to the scanning sequence. For example, the CT value of CT image pixels must be between -1000 and 3000 HU, and the signal value of MRI image pixels must conform to the normal range of the corresponding scanning sequence. Finally, all verification results are integrated, and the image data that has passed the triple verification of integrity, compliance, and pixel validity are grouped according to clinical business dimensions such as image examination type, patient department, and examination time. Each group is marked with a standardized "verification passed" label, which is then identified as an image verification data group. In this way, big data processing technology is used to achieve standardized and lightweight verification of massive amounts of medical image data. The image verification data group is a collection of image data that has passed integrity verification, compliance verification, and pixel validity verification simultaneously.

[0023] For example, taking the synchronization of chest CT image data from a top-tier general hospital to a remote chest consultation center as an example, the hospital has separated three DICOM format chest CT image data sets from the medical data to be synchronized: CT1 (128-slice chest plain CT, 8GB), CT2 (256-slice chest enhanced CT, 15GB), and CT3 (64-slice chest low-dose CT, 4GB). SHA-256 can be selected as the fast hash algorithm to calculate the hash value byte-by-byte for the complete binary content of the three chest CT image data sets. The first checksums are: CT1 hash value: 7a2f9c4d8e1b3e5f0a6b8c9d0e; CT2 hash value: 1b2c3d4e5f6a7b8c9d0e1; CT3 hash value: 8c9d0e1f2a3b4c5d6e7f8a. Comparing these with the standard hash value shows that the first checksums of CT1, CT2, and CT3 all match the standard value, completing the integrity verification. Subsequently, the DICOM parser was invoked to perform compliance verification on the three image datasets. The DICOM file header metadata was parsed and verified. The results showed that the image sequence numbers for CT1 and CT2 were continuous, the patient IDs and image identifiers were consistent, and the acquisition parameters conformed to the clinical examination guidelines for chest CT. The generated second verification data was marked as "compliant" across all categories. The compliance verification involved comparing the parsed image metadata with a preset medical image standard library. If the image sequence numbers were continuous, the patient identifiers were consistent, and the acquisition parameters were within a preset range, the data was deemed compliant; otherwise, it was deemed non-compliant. CT3 was marked as "non-compliant" in the second verification data because its image sequence number was missing three levels and the slice thickness setting in the acquisition parameters did not conform to the low-dose CT guidelines. Pixel matrices could also be extracted from CT1 and CT2, and a fast sampling verification algorithm could be used to randomly select 0.1% of the pixels to verify whether their CT values ​​were within the reasonable range of -1000 to 3000 HU. The results showed that the CT values ​​of the 1048 pixels extracted from CT1 and the 2097 pixels extracted from CT2 were within the reasonable medical range, indicating that the pixel validity verification passed. Subsequently, the chest CT images were grouped according to the examination type (plain CT, enhanced CT). The plain CT group containing CT1 was labeled "Verification Passed - Chest Plain CT" and identified as the chest plain CT image verification data group. The enhanced CT group containing CT2 was labeled "Verification Passed - Chest Enhanced CT" and identified as the chest enhanced CT image verification data group.

[0024] In one embodiment of this application, in step S130, if the data volume of the text verification data group does not exceed a preset text data volume threshold, then the current text verification data group is considered a valid text. Specifically, the total number of bytes in all text data files within each text verification data group can be counted. Specifically, this can be done by traversing all text data files within the text verification data group, calling the file system interface to obtain the file size corresponding to each text data file, and summing all file size counts to obtain the total number of bytes in the text verification data group. This is achieved through the standard conversion between bytes and MB (1MB = 1024KB = 1024MB). The actual data size of each text verification data group is obtained by dividing the total number of bytes in the file by 1024 × 1024 using a preset unit conversion rule to obtain the actual data size in MB, or by directly obtaining the corresponding MB value by calling the system's capacity conversion interface. The actual data size of each text verification data group is compared with a preset text data size threshold. If the data size of a text verification data group does not exceed the preset threshold, it indicates that the size of the text data group is suitable for the transmission bandwidth and processing resource requirements of cross-institutional synchronization of medical data, and therefore the text verification data group is determined to be a valid text. If the actual data size of a text verification data group exceeds the preset threshold, it indicates that the data size of the group is large, and direct transmission may easily cause network congestion and excessive synchronization time. In this case, the current text verification data group can be allocated to a backup transmission channel with greater bandwidth for transmission, and a fast hash verification algorithm can be used for verification. Alternatively, the current text verification data group can be divided into multiple text data sub-blocks, and each text data sub-block can be allocated to different transmission channels for transmission, and a fast hash verification algorithm can be used for verification. The preset text data volume threshold can be pre-stored in the system configuration parameters and should be set in accordance with the actual application characteristics of medical text data and the engineering principles of cross-institutional data synchronization in medical institutions. It can also be set based on the clinical needs for text data, combined with the network transmission bandwidth, data storage resources, and typical size range of text data for routine cross-institutional synchronization within medical institutions. Furthermore, it can be adjusted according to actual transmission scenarios, such as intra-hospital LAN synchronization, cross-regional WAN synchronization, and the network resource conditions of medical institutions, to adapt to different medical data synchronization needs.

[0025] For example, with a preset text data size threshold of 10MB, three text verification data groups were identified: the Cardiovascular Medicine Electronic Medical Records group, the Cardiovascular Specialty Laboratory Test Reports group, and the Clinical Medication List group. The total number of bytes in all text files within each group was counted and converted to MB, resulting in a total data size of 8.2MB for the Cardiovascular Medicine Electronic Medical Records group, 3.5MB for the Cardiovascular Specialty Laboratory Test Reports group, and 12.8MB for the Clinical Medication List group. Comparing the actual data size of each group with the preset text data size threshold, it can be seen that the Cardiovascular Medicine Electronic Medical Records group (8.2MB ≤ 10MB) and the Cardiovascular Specialty Laboratory Test Reports group (3.5MB ≤ 10MB) both did not exceed the preset text data size threshold, while the Clinical Medication List group (12.8MB > 10MB) exceeded the preset text data size threshold. Based on the comparison results, the Cardiovascular Medicine Electronic Medical Records group and the Cardiovascular Specialty Laboratory Test Reports group were determined to be valid texts.

[0026] In one embodiment of this application, in step S140, if the data volume of the image verification data group exceeds a preset image data volume threshold, the current image verification data group is divided to generate multiple image data sub-blocks. The method also includes the following steps: Figure 3 As shown, the specific content is as follows: Step S310: Obtain the total file size of the image verification data group; Step S320: Determine the number of image data sub-blocks based on the total file size of the image verification data group; Step S330: Divide the image verification data group into multiple image data sub-blocks according to the number of image data sub-blocks.

[0027] Specifically, the preset image data volume threshold refers to a threshold set in advance based on the typical size of medical image data (e.g., a single CT scan takes several hundred MB to several GB), network transmission bandwidth, and the efficiency requirements for synchronous transmission of medical data. This threshold can be set based on network transmission bandwidth, the storage scale of medical CT and MRI images, and the efficiency requirements for synchronous transmission of medical data. Image verification data sets exceeding the preset threshold are split into multiple smaller image data sub-blocks adapted to the network transmission bandwidth, avoiding problems such as network congestion, excessive transmission time, and high data loss rates caused by direct transmission of large-scale image data. If the data volume of the image verification data set does not exceed the preset threshold, a fast hash verification algorithm can be directly used to verify the current image verification data set to generate a corresponding hash value, which is then compared with the original hash value before verification. If the hash values ​​match perfectly, the current image verification data set is considered valid.

[0028] Furthermore, a fixed size for preset image data sub-blocks can be obtained. Specifically, this fixed size value can be read from the system configuration file or parameter table. The fixed size of the image data sub-blocks can be set according to the load capacity of the transmission channel. For example, it can be set to 512MB to ensure that the image data sub-blocks are compatible with conventional medical data transmission links, while avoiding redundancy caused by overly small sub-blocks and transmission lag caused by overly large sub-blocks. The load capacity of the transmission channel refers to the maximum amount of data that a single transmission channel can stably transmit per unit time. This is used to determine the fixed size of the image data sub-blocks, avoiding channel blockage caused by overly large sub-blocks or redundancy caused by overly small sub-blocks. Then, using the rounding-up calculation rule, the number of image data sub-blocks = (total file size of the image verification data group / fixed size of the image data sub-blocks). The rounding-up calculation rule ensures that the remaining image data in the last part of the original image verification data group that is less than the fixed size can also form independent image data sub-blocks, avoiding the inability to restore the original image due to incomplete data splitting, while ensuring that all the sub-blocks after splitting can completely cover all the data in the original image verification data group. The rounding-up rule refers to directly carrying over the decimal part of the division result to the next integer, which is the ceil function in mathematics.

[0029] Furthermore, based on the determined number of image data sub-blocks, the image verification data group can be divided into byte-level ordered segments, generating multiple uniquely identified, traceable, and reproducible image data sub-blocks. A preset fixed size for the image data sub-blocks can be used as the segmentation standard. Starting from the storage beginning position of the image verification data group, byte-level continuous segmentation is performed. The first N-1 sub-blocks (N being the calculated number of sub-blocks) are of the preset fixed size, and the Nth sub-block is the remaining image data after the original image verification data group has been divided into the first N-1 sub-blocks. Finally, a unique sub-block index identifier is generated for each segmented image data sub-block, and basic verification information can be appended to each image data sub-block. Byte-level ordered segmentation refers to using bytes as the smallest unit, sequentially extracting fixed-size data segments from the starting offset according to the byte order of the original image file, ensuring that the byte content of each image data sub-block is continuous and non-overlapping in the original file, thus guaranteeing lossless reconstruction of the original file. Each segmented image data sub-block is assigned a globally unique sequence number (e.g., from 1 to N), which can be combined with the original file ID to form a composite identifier (e.g., "file ID_sub-block sequence number"), used to reassemble the original image data in order after transmission. Basic verification information refers to auxiliary data attached to each image data sub-block for quick integrity verification, including but not limited to sub-block size, sub-block sequence number, and CRC32 checksum. This is used to verify whether sub-blocks are corrupted or lost after transmission.

[0030] For example, the preset image data size threshold is 5GB, and the fixed size of the image data sub-block is 512MB. The total number of bytes in the chest enhanced CT image verification data group is 16106127360 bytes, and the total file size is calculated to be 15GB according to the standard unit conversion rules. Therefore, based on the total file size of 15GB and the fixed size of the image data sub-blocks of 512MB, the number of image data sub-blocks is calculated to be 15GB / 0.512GB ≈ 29.296875. Using the rounding up rule, the number of image data sub-blocks is determined to be 30. Finally, the segmentation order is determined according to the scanning sequence of the chest enhanced CT. Specifically, the image data can be sorted according to the image sequence number or sequence identifier field recorded in the DICOM file, and the segmentation operation is performed according to the sorted order, thereby ensuring that the segmented image data sub-blocks are logically consistent with the original image sequence. The image verification data group is divided starting from the beginning of its storage location. The first 29 sub-blocks are all fixed in size at 512MB. The 30th sub-block is the remaining 0.152GB of image data. A unique index identifier is generated for each sub-block after the division, and a CRC32 check code is attached to each sub-block.

[0031] In one embodiment of this application, step S140, which determines the number of verifications corresponding to each image data sub-block based on the data volume of each image data sub-block, further includes the following steps: Figure 4 As shown, the specific content is as follows: Step S410: Calculate the pixel entropy value of each image data sub-block, and determine the verification strength corresponding to each image data sub-block based on the pixel entropy value and the amount of data; Step S420: Obtain the verification correction coefficient, multiply the verification correction coefficient by the verification strength, and use the multiplication result as the verification number corresponding to each image data sub-block.

[0032] Specifically, a pixel matrix can be extracted from each image data sub-block to preserve the complete pixel value distribution information within the sub-block. The pixel matrix directly reflects key clinical information such as image texture and lesions. Subsequently, the information entropy calculation method is used to calculate the pixel matrix of each image data sub-block, obtaining the pixel entropy value of each sub-block. Specifically, the pixel grayscale values ​​in the pixel matrix can be statistically analyzed, the probability distribution of each grayscale value can be calculated, and the probability distribution can be calculated based on the information entropy formula to obtain the pixel entropy value. The pixel entropy value is the negative of the sum of the products of the probability of each grayscale value and its logarithmic value, used to characterize the dispersion of pixel distribution. The pixel entropy value reflects the complexity of pixel distribution in the image data sub-block. The higher the pixel entropy value, the more discrete the pixel grayscale value distribution within the image data sub-block, the more complex the image texture or lesion area, the higher the requirement for data integrity, and the higher the corresponding verification strength needs to be. Conversely, the lower the pixel entropy value, the more uniform the image area, and the lower the verification strength can be accordingly reduced. Next, the system reads pre-set values ​​from the system configuration file to obtain the baseline data volume and baseline pixel entropy value. Therefore, the verification strength = (data volume of image data sub-block / baseline data volume) + (pixel entropy value / baseline pixel entropy value). Furthermore, a matching verification correction coefficient can be obtained based on the actual scenario of different medical data synchronization. Specifically, the system reads the corresponding verification correction coefficient from the scenario parameter mapping table or configuration file based on the scenario identifier of the current transmission task. The verification strength of each image data sub-block is multiplied by the verification correction coefficient to obtain the verification count. Finally, the initial verification count is rounded up to obtain the final verification count, which is a positive integer. The baseline data volume is consistent with the fixed segment size of the image data sub-block; the baseline pixel entropy value can be set according to the pixel distribution complexity of medical images such as CT, MRI, and ultrasound. The baseline data volume refers to the size of the reference data used for normalizing the verification strength calculation, and it is usually consistent with the fixed segment size of the image data sub-block. The baseline pixel entropy value refers to the reference pixel entropy value used for normalizing the calculation of verification strength. It can be preset according to the typical pixel distribution complexity of different medical image types such as CT, MRI, and ultrasound. The number of verifications is used to control the number of times the integrity verification is performed on the corresponding image data sub-block. That is, multiple hash verifications or consistency verifications are performed on each image data sub-block to improve the verification reliability of complex image data.

[0033] For example, consider a tertiary hospital synchronizing four image data sub-blocks generated from the segmentation of a chest enhanced CT image verification data set to a remote chest consultation center. Assume the baseline data size is 512MB, the baseline pixel entropy value is 5.0, and the verification correction coefficient is 10. The first three image data sub-blocks are fixed at 512MB, and the fourth has a remaining size of 256MB. Pixel entropy values ​​are calculated for the pixel matrix of the four image data sub-blocks, yielding pixel entropy values ​​of 4.8 for image data sub-block 1, 5.5 for image data sub-block 2, 3.2 for image data sub-block 3, and 4.5 for image data sub-block 4. Subsequently, the verification strength of each image data sub-block was calculated as follows: verification strength of image data sub-block 1 = (512 / 512) + (4.8 / 5.0) = 1.96, verification strength of image data sub-block 2 = (512 / 512) + (5.5 / 5.0) = 2.1, verification strength of image data sub-block 3 = (512 / 512) + (3.2 / 5.0) = 1.64, and verification strength of image data sub-block 4 = (256 / 512) + (4.5 / 5.0) = 1.4. The verification correction factor is 10. Multiplying the verification strength of each image data sub-block by 10 yields the initial verification count: Image data sub-block 1 verification count = 1.96 × 10 = 19.6, Image data sub-block 2 verification count = 2.1 × 10 = 21, Image data sub-block 3 verification count = 1.64 × 10 = 16.4, Image data sub-block 4 verification count = 1.4 × 10 = 14. Finally, the initial verification count is rounded up to obtain the final verification count for each image data sub-block: Image data sub-block 1 verification count = 20, Image data sub-block 2 verification count = 21, Image data sub-block 3 verification count = 17, Image data sub-block 4 verification count = 14. The verification correction factor is an adjustable multiplier factor pre-set according to different actual medical data synchronization scenarios (such as intra-hospital LAN synchronization, cross-regional WAN synchronization, emergency treatment scenarios, or routine consultation scenarios), used to convert the verification strength into the actual verification count.

[0034] In one embodiment of this application, step S150, which involves obtaining the emergency treatment response value corresponding to each image data sub-block and determining the comprehensive score corresponding to each image data sub-block based on the number of verifications and the emergency treatment response value, further includes the following steps: Figure 5 As shown, the specific content is as follows: Step S510: Obtain the weight value corresponding to the number of verifications and the weight value corresponding to the emergency treatment response value, respectively; Step S520: Based on the weight value corresponding to the number of verifications and the weight value corresponding to the emergency treatment response value, perform a weighted calculation on the number of verifications and the emergency treatment response value, and use the result of the weighted calculation as the comprehensive score corresponding to each image data sub-block.

[0035] Specifically, the emergency response value can be used to quantify the degree of emergency treatment in the clinical treatment scenario corresponding to the image data sub-block. The emergency response value can be set as a continuous value from 0 to 100. The higher the value, the stronger the clinical emergency treatment demand corresponding to the image data sub-block, and the more priority it needs to be transmitted; the lower the value, the more likely the corresponding treatment scenario is routine consultation, data archiving, etc., without an emergency treatment demand. The emergency response value can be quantitatively obtained through clinical priority information in the medical business system, specifically including: extracting the patient's triage level, treatment priority identifier, critical value marker, and whether it belongs to an emergency or severe case from the hospital information system (HIS) or emergency triage system; and converting different triage levels into corresponding values ​​based on preset mapping rules. For example, the preset mapping rule can be a four-level triage system based on the international standard "Emergency Triage and Grading Standard," mapping the patient's triage level one-to-one with the emergency response value. Among them, critically ill patients at triage level I require immediate resuscitation, therefore their corresponding emergency response value ranges from 80 to 100. Critically ill patients at triage level II require treatment within 10 minutes, therefore their corresponding emergency response value ranges from 60 to 79. Emergency patients at triage level III require treatment within 30-60 minutes, therefore their corresponding emergency response value ranges from 40 to 59. Non-emergency patients at triage level IV can be treated after 2 hours, therefore their corresponding emergency response value ranges from 0 to 39. For example, in a cross-regional emergency treatment scenario where a tertiary hospital synchronizes chest enhanced CT image data blocks to a remote chest consultation center, the weight value corresponding to the number of verifications is 0.4, and the weight value corresponding to the emergency treatment response value is 0.6. The number of verifications for the four image data blocks Block_001, Block_002, Block_003, and Block_004 are 21, 20, 17, and 14, respectively, and the emergency treatment response values ​​are 95, 80, 60, and 90, respectively. The verification count and emergency response value of each image data sub-block were weighted and calculated to obtain the following comprehensive scores: Block_001: 21×0.4+95×0.6=65.4; Block_002: 20×0.4+80×0.6=56; Block_003: 17×0.4+60×0.6=42.8; Block_004: 14×0.4+90×0.6=59.6. The final comprehensive scores of the four image data sub-blocks, from highest to lowest, are: Block_001, Block_004, Block_002, and Block_003. The weight values ​​for the verification count and emergency response value can be preset according to the business priority strategy for medical data synchronization, or obtained through historical data statistical analysis.For example, based on the relationship between transmission success rate and response time during historical medical data synchronization, weighted optimization methods (such as linear regression or empirical rules) can be used to determine the weight ratios, ensuring that the sum of all weight values ​​is 1 to meet the normalization requirements of weighted calculation. The comprehensive score is used to characterize the transmission priority of each image data sub-block in the current medical data synchronization task. The higher the comprehensive score, the higher the comprehensive weight of that image data sub-block in terms of urgency and data importance. The number of verifications, emergency response values, and comprehensive scores of each image data sub-block can be stored in a data structure in key-value pair format, where the key is the unique identifier of the image data sub-block, and the value is the corresponding set of parameters.

[0036] In one embodiment of this application, step S160 involves sorting the comprehensive scores from maximum to minimum to generate a priority transmission sequence, and then transmitting each image data sub-block using multiple transmission channels based on the priority transmission sequence. The step also includes the following steps: Figure 6 As shown, the specific content is as follows: Step S610: Obtain the bit error rate and packet loss rate of the image data sub-blocks in each transmission channel; Step S620: If the bit error rate exceeds the preset bit error rate threshold or the packet loss rate exceeds the preset packet loss rate threshold, the image data sub-blocks in the current transmission channel are allocated to the backup transmission channel.

[0037] Specifically, the generated priority transmission sequence can be obtained to determine the transmission priority order of each image data sub-block. Specifically, according to the priority order of the image data sub-blocks, the transmission channel with the largest real-time bandwidth and the lowest current load rate is selected from the set of available transmission channels for allocation. For image data sub-blocks with the same priority, a round-robin or weighted round-robin allocation method is used to evenly distribute them across multiple transmission channels. Simultaneously, information on each main transmission channel is obtained through the network management interface or operating system API, including the number of channels, the real-time bandwidth of each channel, the current load rate, and the network link type. Transmission channels can be logical data transmission links built based on the TCP / IP protocol, or independent physical or virtual transmission paths established based on different network interfaces, communication links, or ports, including but not limited to intra-hospital LAN links, cross-regional WAN links, VPN leased lines, or multipath transmission channels. Real-time bandwidth refers to the actual data transmission rate available to the transmission channel at the current moment. Affected by factors such as network congestion and link quality, the real-time bandwidth may be lower than the nominal bandwidth. The current load rate refers to the ratio of the bandwidth currently occupied by the transmission channel to the total bandwidth. Network link type refers to the physical or logical network type upon which the transmission channel relies, such as an intra-hospital local area network (LAN), a cross-regional wide area network (WAN), a 5G private network, or a VPN tunnel. Different link types have different bit error rates, packet loss rates, and latency characteristics, affecting threshold settings. High-priority image data sub-blocks ranked higher in the priority transmission sequence are allocated to transmission channels with better real-time bandwidth and lower current load rates. Image data sub-blocks of the same priority are evenly distributed across different transmission channels to avoid transmission stuttering caused by excessive load on a single transmission channel. The priority transmission sequence can be an ordered queue structure or a priority queue structure generated according to a comprehensive score, where each image data sub-block corresponds to a unique sorting position and priority identifier. Data is collected for each transmission channel to determine the bit error rate and packet loss rate. The bit error rate is calculated as the ratio of the number of erroneous bits transmitted per unit time in the current transmission channel to the total number of transmitted bits. The packet loss rate is calculated as the ratio of the number of data packets lost per unit time in the current transmission channel to the total number of transmitted data packets, reflecting packet-level transmission integrity.

[0038] Furthermore, the real-time bit error rate and packet loss rate of each transmission channel are obtained. Specifically, this is achieved by collecting data from the network status monitoring interface of the transmission channel, or by calculating the number of bit errors and packet losses per unit time. These values ​​are then compared with preset bit error rate thresholds and preset packet loss rate thresholds, respectively. If the bit error rate or packet loss rate of a transmission channel exceeds the preset threshold, a channel switching mechanism is immediately triggered, suspending the transmission of image data sub-blocks on the current transmission channel and simultaneously acquiring information on backup transmission channels. Backup transmission channels refer to pre-configured idle transmission channel resources that are used as alternative transmission channels when the quality of the primary transmission channel is substandard. The channel switching mechanism is triggered by setting the channel status to "unavailable," suspending the allocation of new tasks to the channel; checking the list of sub-blocks currently being transmitted but not yet completed on the channel; selecting a channel with a status of "idle" from the list of idle backup channels; re-adding the incomplete sub-blocks to the transmission queue of the backup channel according to their original priority order; and resuming the transmission task on the backup channel. Subsequently, the image data sub-blocks that have not been fully transmitted in the current transmission channel are reallocated to the currently idle backup transmission channel according to their original priority transmission sequence. During the reallocation process, the original order of the image data sub-blocks in the priority transmission sequence is maintained, and they are written sequentially into the transmission queue of the backup transmission channel. The preset bit error rate threshold can be set according to the accuracy requirements of medical image data transmission, while also adapting to different network transmission environments such as cross-regional wide area networks and intra-hospital local area networks. The preset packet loss rate threshold can be set according to the integrity requirements of medical data synchronization and the actual load capacity of network transmission.

[0039] For example, the priority transmission sequence is: Block_001, Block_004, Block_002, Block_003. The preset bit error rate threshold is 1×10⁻⁶. -5 The preset packet loss rate threshold is 0.5%, and two transmission channels are configured: Transmission Channel 1 and Transmission Channel 2. Transmission Channel 1 has a real-time load rate of 15%, and Transmission Channel 2 has a real-time load rate of 30%, with one idle backup transmission channel. Following the priority transmission sequence and adhering to the load balancing principle of prioritizing high-priority allocation, the highest-priority sub-block, Block_001, is assigned to the lower-loaded main transmission channel 1. Block_004, Block_002, and Block_003 are assigned to transmission channel 2 in priority order. Then, continuous data acquisition is performed on transmission channels 1 and 2 at a 1-second acquisition cycle. The bit error rate and packet loss rate of the image data sub-blocks in each channel are calculated and obtained in real time. The bit error rate of transmission channel 1 is 3.2 × 10⁻⁶. -6 The packet loss rate is 0.2%, and the bit error rate of transmission channel 2 is 8.5 × 10⁻⁶. -6The packet loss rate is 0.8%. The bit error rate and packet loss rate of each transmission channel are compared with their corresponding preset thresholds. If the bit error rate and packet loss rate of transmission channel 1 do not exceed the corresponding preset thresholds, the current transmission quality is considered satisfactory. However, the packet loss rate of transmission channel 2, at 0.8%, exceeds the preset packet loss rate threshold of 0.5%, indicating substandard transmission quality. Therefore, a channel switching mechanism is immediately triggered, suspending the current transmission work of transmission channel 2. The untransmitted Block_004, Block_002, and Block_003 packets from transmission channel 2 are then reassigned to the idle backup transmission channel 3 according to their original priority transmission sequence.

[0040] In one embodiment of this application, step S170, if the image data sub-block in the current transmission channel passes the verification, then the current image data sub-block is determined as a qualified image data sub-block. The step further includes the following steps: Figure 7 As shown, the specific content is as follows: Step S710: If the bit error rate does not exceed the preset bit error rate threshold and the packet loss rate does not exceed the preset packet loss rate threshold, then the fast hash verification algorithm is used to verify each image data sub-block; Step S720: If the current image data sub-block passes the verification, then the current image data sub-block is determined as a qualified image data sub-block. Step S730: If the verification of the current image data sub-block fails, mark the current image data sub-block as a verification failure sub-block and use the forward error correction lossless erasure algorithm to repair the verification failure sub-block; Step S740: Generate each qualified image data sub-block based on the repaired failed verification sub-block.

[0041] Specifically, if the bit error rate of the transmission channel does not exceed a preset bit error rate threshold, and the packet loss rate does not exceed a preset packet loss rate threshold, the transmission quality of the channel is deemed to meet the standard. After the image data sub-blocks in the compliant main transmission channel complete a full end-to-end transmission, a post-transmission integrity secondary check is performed on each sub-block. A fast hash check algorithm consistent with the image data sub-block segmentation stage is used to recalculate the hash value of the transmitted sub-block's binary content and compare it with the original hash value generated during image data sub-block segmentation. If the hash values ​​of the secondary check match perfectly, it indicates that the image data sub-block has not been tampered with, lost, or damaged during transmission. A standardized "verification qualified" identifier is added to the image data sub-block, and the sub-block's priority information, transmission channel information, and verification result information are bound to it, generating a verified image data sub-block. End-to-end transmission refers to the entire process of image data sub-blocks being transmitted from the sending system to the receiving system via the transmission channel and fully received. Priority information includes the image data sub-block's sorting position or priority level in the priority transmission sequence. The transmission channel information includes the identifier of the corresponding transmission channel, link type, and transmission path information. The verification result information includes the hash verification result identifier and verification time information. Binding can be achieved by writing the corresponding priority information, transmission channel information, and verification result information into the metadata fields of the image data sub-block, or by establishing an index mapping table for associated storage.

[0042] For example, if the verification of the current image data sub-block fails, a forward error correction lossless erasure algorithm can be used to achieve lossless recovery of the failed sub-block by adding redundant verification data before transmitting the original image data sub-block. Specifically, the number of redundant data blocks required for repair is determined. Assuming the original sub-block is divided into k data segments and m redundant segments are generated, the receiving end needs at least k segments to recover the data. For the failed sub-block Block_004, all available data segments belonging to the same erasure coding group as this sub-block (including other successfully verified sub-block data and redundant segments) are extracted from the receiving buffer. The erasure decoder (such as using the OpenFEC library or Jerasure library) is called, and the available segments and their position indices are input to perform the decoding operation. The decoder outputs the recovered original binary data of Block_004. If the number of available segments is less than k, recovery is not possible, and a retransmission is required. Here, the forward error correction lossless erasure algorithm refers to an encoding technique that adds redundant verification data before data transmission, so that when the receiving end detects partial data loss or corruption, it can recover the original data from the redundant data without retransmission. The lossless erasure algorithm used in this embodiment can be either Reed-Solomon or Tornado codes. Its core principle is to divide the original data into k data blocks, then encode them into m redundant blocks (i.e., k+m blocks). The receiving end only needs to receive any k blocks to completely recover the original data, achieving lossless repair. For example, four transmitted image data sub-blocks are acquired, and the CRC32 fast hash check algorithm is used to calculate the real-time hash checksum byte-by-byte for the complete binary content of each image data sub-block. The real-time checksum is then compared with the original hash checksum one by one. The results show that the real-time and original checksums of Block_001, Block_002, and Block_003 are completely matched, and the verification passes. The real-time hash checksum of Block_004 is inconsistent with the original value, and it is determined to be a failed verification sub-block. Next, a forward error correction lossless erasure algorithm is used, combined with the redundant check data attached to the transmission of the Block_004 sub-block, to restore the original complete binary data of Block_004. After the repair is completed, the CRC32 fast hash check algorithm is used again for verification. The generated repaired hash check code matches the original hash check code perfectly, confirming the repair is effective, and generating four verified image data sub-blocks: Block_001, Block_002, Block_003, and Block_004. Specifically, the image data sub-blocks repaired by the erasure algorithm are re-submitted for hash verification. If the verification passes again, the repaired image data sub-block and the previously verified image data sub-blocks are marked as verified and aggregated to form the final set of verified image data sub-blocks.Redundant check data is supplementary data generated by erasure coding algorithms after image data sub-blocks are segmented and before transmission. It, along with the original data, forms a coded data block used for data reconstruction in case of data loss or errors during transmission. The original hash checksum refers to the hash value pre-calculated for each sub-block using a fast hash algorithm (such as CRC32) during the image data sub-block segmentation stage or before transmission, serving as the benchmark for subsequent integrity verification. In this embodiment, the original hash checksum is stored bound to the sub-block, for example, appended to the end of the sub-block or stored in a separate checksum list. Consistency comparison can be achieved through string comparison or numerical comparison, i.e., determining whether the real-time hash checksum and the original hash checksum are completely consistent in value or encoding result, using this as the basis for determining whether the verification passes.

[0043] In one embodiment of this application, step S180, which generates a complete synchronized medical data packet based on each valid text and each valid image data sub-block, further includes the following steps: Figure 8 As shown, the specific content is as follows: Step S810: Obtain the preset data packet merging rules; Step S820: Based on the preset data packet merging rules, merge each qualified text and each qualified image data sub-block to generate a synchronized medical data packet, and use a fast hash algorithm to perform integrity verification on the synchronized medical data packet; Step S830: If the synchronized medical data packet passes the integrity check, then the current synchronized medical data packet is taken as the complete synchronized medical data packet.

[0044] Specifically, the preset data packet merging rules use patient ID and treatment order number as associated fields to group verified text and image data sub-blocks from the same patient into the same data group. A standardized internal structure for the data packets is constructed according to "metadata area - text data area - image data sub-block area," and each data packet is assigned a unique synchronization identifier ID. Simultaneously, verification information for the corresponding data is attached to each data area to ensure that the merged data packets can be compatible and parsed by information systems of different medical institutions. The preset data packet merging rules are pre-defined data organization and mapping rules. Using patient ID and treatment order number as the main associated fields, they aggregate verified text and image data sub-blocks from different data sources under the same associated field, and map and arrange fields according to a predefined data structure template, thus forming a standardized data packet construction logic to ensure consistency and parsability of data from different sources during the merging process. Pre-defined data packet merging rules can be read from system configuration files, rule engines, or databases. The standardized internal structure of a data packet refers to a hierarchical structure divided into metadata, text, and image data sub-blocks according to a pre-defined unified format. Each data area is organized according to a fixed field order, field type, and encoding rules to ensure that information systems in different medical institutions can read and parse the data packet according to unified parsing rules. The synchronization identifier (ID) is a globally unique identifier used to uniquely identify a synchronized medical data packet. It can be generated using a combination of timestamps, patient IDs, random numbers, or hashes. It is used to uniquely identify, track, and manage data packets during medical data synchronization and serves as an index field for subsequent data association and retrieval. Verification information may include the hash checksum of the corresponding data, data length information, encoding format identifier, and version identifier, used to verify the integrity and consistency of each data area during data parsing and transmission. The standard hash checksum is a reference checksum calculated based on the overall binary content of the synchronized medical data packet after its construction, according to pre-defined rules, or a baseline checksum pre-stored in the medical data synchronization system. It is used for consistency comparison with the hash checksum calculated in real time. The medical data synchronization archive is a database or storage system used to store synchronized medical data packages and their related metadata. It records information such as synchronization identifier ID, patient ID, data content list, and hash verification results to support subsequent data traceability, auditing, and querying. Specifically, based on the association fields in the preset rules, all valid text and image data sub-blocks are traversed, and data with the same patient ID and treatment order number are grouped into the same data group. A binary stream is constructed in the order of "metadata area - text data area - image data sub-block area".First, create the metadata area: write the synchronization identifier ID (generated from UUID), patient ID, treatment order number, current timestamp, total size placeholder (temporarily filled with 0), and offset placeholders for each data area; then write the text data area: sequentially write the length, content, and text checksum of each text data item; finally, write the image data sub-block area: according to the priority transmission sequence, sequentially write the length, binary content, and original hash value of each sub-block. After all data is written, backfill the total size and offsets of each data area in the metadata area. This ultimately generates a complete binary data packet, i.e., the initial synchronized medical data packet. For the complete binary content of the merged synchronized medical data packet, call the same fast hash algorithm as in the block-splitting stage to calculate the overall hash checksum. Read the pre-stored standard hash checksum corresponding to the patient and treatment from the medical data synchronization archive or source system metadata. Compare the two strings (case-insensitive). If they match completely, the checksum passes.

[0045] For example, consider the case of a tertiary hospital synchronizing emergency medical data for a patient with acute chest pain to a remote chest consultation center. This patient's data includes three verified text files (electronic medical record, myocardial enzyme spectrum test report, and electrocardiogram text report) and four verified image data sub-blocks (Block_001, Block_002, Block_003, and Block_004 from a chest enhanced CT scan). Data is grouped using the patient's unique ID "P20250610010" as the associated field. A standardized data packet structure is constructed according to preset data packet merging rules, generating the initial synchronized medical data packet. Subsequently, the MD5 fast hash verification algorithm is used to perform byte-by-byte operations on the complete binary content of the synchronized medical data packet, generating the overall hash verification code 9e107d9d372bb6826bd8. This overall hash verification code is compared with the standard hash verification code. If they match completely, the integrity of the synchronized medical data packet is verified, and a standardized identifier of "complete synchronized medical data packet" is added to it. Simultaneously, the synchronization identifier ID, patient ID, data content list, and overall hash checksum of the data packet are stored synchronously in the medical data synchronization archive. Generating a synchronized medical data packet involves serializing each data area according to a preset encoding format (such as JSON, XML, or binary encapsulation format) to form a complete, transmittable data packet file or data stream.

[0046] This application also provides a verification-based medical data synchronization processing system, which may include an acquisition module, a first determination module, a second determination module, a third determination module, a fourth determination module, a first generation module, and a second generation module. The acquisition module is used to acquire medical data to be synchronized, including text data and image data. The first determination module is used to determine each text verification data group based on the text data using a fast hash algorithm, and to determine each image verification data group based on the image data. The second determination module is used to, if the data volume of a text verification data group does not exceed a preset text data volume threshold, then consider the current text verification data group as a valid text. The third determination module is used to, if the data volume of an image verification data group exceeds a preset image data volume threshold, then divide the current image verification data group to generate multiple image data sub-blocks, and determine the sub-blocks based on each image data sub-block. The data volume of each image data sub-block determines the number of verifications for each sub-block; the fourth determination module is used to obtain the emergency treatment response value corresponding to each image data sub-block, and determine the comprehensive score corresponding to each image data sub-block based on the number of verifications and the emergency treatment response value; the first generation module is used to sort the comprehensive scores in order from the maximum value to the minimum value to generate a priority transmission sequence, and based on the priority transmission sequence, send each image data sub-block using multiple transmission channels to generate each verified image data sub-block; the second generation module is used to generate a complete synchronous medical data packet based on each verified text and each verified image data sub-block.

[0047] It should be noted that the embodiments of the verification-based medical data synchronization processing system provided in this application can be used to execute the processing flow of the embodiments of the verification-based medical data synchronization processing method in the above embodiments. Its functions will not be repeated here, but can be referred to the detailed description of the above method embodiments.

[0048] This application also provides an electronic device, which includes one or more processors and memory resources represented by memory for storing instructions executable by the processors, such as application programs. The application programs stored in the memory may include one or more modules, each module corresponding to a set of instructions. Furthermore, the processor is configured to execute the instructions to perform the aforementioned verification-based medical data synchronization processing method.

[0049] The electronic device may also include a power supply component configured to perform power management of the electronic device, a wired or wireless network interface configured to connect the electronic device to a network, and an input / output (I / O) interface. The electronic device may operate based on an operating system stored in memory, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0050] In one embodiment, a computer device, which may be a server, is also provided. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores data. The I / O interfaces of the computer device are used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a verification-based medical data synchronization processing method.

[0051] In one embodiment, a computer device is provided, which may be a terminal. The computer device includes a processor, memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface of the computer device is used for exchanging information between the processor and external devices. The communication interface of the computer device is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a verification-based medical data synchronization processing method. The display unit of the computer device is used to form a visually visible image and may be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0052] This application also provides a non-transitory computer-readable storage medium, which, when the instructions in the storage medium are executed by the processor of the aforementioned electronic device, enables the electronic device to perform a verification-based medical data synchronization processing method.

[0053] This application may take the form of a computer program product implemented on one or more storage media (including but not limited to disk storage, optical storage, etc.) containing program code. Computer-readable storage media include permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information may be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to: phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc read-only memory, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0054] It should be noted that although the steps of the verification-based medical data synchronization processing method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps, such as omitting certain steps, combining multiple steps into one step, and / or breaking down one step into multiple steps, should all be considered part of this application.

[0055] It should be understood that this application is not limited to the detailed structure and arrangement of the modules in the verification-based medical data synchronization processing system proposed in this specification. This application can have other implementations and can be implemented and executed in various ways. The foregoing variations and modifications fall within the scope of this application. It should be understood that the application and its definition in this specification extend to all alternative combinations of two or more individual features mentioned or apparent in the text and / or drawings. All these different combinations constitute multiple alternative aspects of this application. The embodiments described in this specification illustrate the best known mode for implementing this application and will enable those skilled in the art to utilize this application.

[0056] It should be noted that, in this document, the terms "comprising," "including," and any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Specific examples have been used in this document to illustrate the principles and implementation methods of the technical solutions of this application. The above examples are only for the purpose of helping to understand the methods and core ideas of this application. The above are merely preferred embodiments of this application. It should be pointed out that, due to the limitations of written expression and the objective existence of infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this application, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes, or combinations, or the direct application of the concept and technical solutions of this application to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A verification-based medical data synchronization processing method, characterized in that, include: Acquire medical data to be synchronized, including text data and image data; Based on the text data, determine each text verification data group; and based on the image data, determine each image verification data group. The step of determining each text verification data group based on the text data includes: performing preprocessing operations on the text data to obtain valid text data; and grouping the valid text data to obtain each text verification data group. The step of determining each image verification data group based on the image data includes: Based on the image data, a hash value is generated using a fast hash algorithm, and the hash value is the first verification data; The fast hash algorithm is an algorithm that performs byte-by-byte operations on the complete binary content of the image data to generate a hash value; The first verification data is compared with the standard hash value for integrity verification; the image data that passes the integrity verification is selected, wherein the standard hash value is a pre-calculated and stored hash value; Based on the matched image data, a DICOM parser is used to perform compliance verification and generate second verification data. Image data that passes the compliance verification is then selected based on the second verification data. A pixel matrix is ​​determined based on the image data that passes the compliance verification. Based on the pixel matrix, a fast sampling verification algorithm is used to randomly sample the pixel matrix to select a number of pixels, and the values ​​of the selected pixels are verified for pixel validity. The fast sampling verification algorithm is an algorithm that randomly selects a number of pixels in the pixel matrix according to a preset sampling ratio based on a random number generation algorithm, and verifies the value of the selected pixels for pixel validity. All verification results are integrated, and the image data that passes the triple verification of completeness, compliance, and pixel validity are grouped according to clinical business dimensions to determine each image verification data group. If the amount of data in the text verification data group does not exceed the preset text data amount threshold, then the current text verification data group is regarded as a qualified text. If the amount of data in the image verification data group exceeds the preset image data amount threshold, the current image verification data group is divided into multiple image data sub-blocks. The fast hash algorithm is used to pre-calculate and store the original hash value for each image data sub-block, and the number of verifications corresponding to each image data sub-block is determined according to the amount of data in each image data sub-block. Obtain the emergency treatment response value corresponding to each of the image data sub-blocks, and determine the comprehensive score corresponding to each of the image data sub-blocks based on the number of verifications and the emergency treatment response value. The emergency treatment response value is a quantitative indicator used to quantify the degree of emergency treatment in the clinical diagnosis and treatment scenario corresponding to the image data sub-block. The comprehensive scores are sorted from the maximum to the minimum to generate a priority transmission sequence, and each image data sub-block is sent using multiple transmission channels based on the priority transmission sequence. If the image data sub-block in the current transmission channel passes the verification, then the current image data sub-block is determined to be a qualified image data sub-block. This includes: if the bit error rate of the transmission channel does not exceed a preset bit error rate threshold and the packet loss rate does not exceed a preset packet loss rate threshold, the transmission quality of the channel is determined to be up to standard. After the image data sub-block in the qualified main transmission channel completes a complete end-to-end transmission, a second integrity verification is performed on each sub-block after transmission. A fast hash algorithm consistent with the image data sub-block segmentation stage is used to recalculate the hash value of the binary content of the transmitted sub-block and compare it with the original hash value generated when the image data sub-block was segmented. If the hash value of the second verification is completely matched, a standardized identifier is added to the image data sub-block. The standardized identifier indicates that the verification is qualified. At the same time, the priority information, transmission channel information, and verification result information of the sub-block are bound to generate a qualified image data sub-block. A complete synchronized medical data packet is generated based on each of the verified text blocks and each of the verified image data sub-blocks, including: A preset data packet merging rule is obtained, wherein the preset data packet merging rule uses patient ID and medical record number as associated fields to group the verified text and verified image data sub-blocks of the same patient into the same data group; based on the preset data packet merging rule, each of the verified text and each of the verified image data sub-blocks is merged to generate a synchronized medical data packet, and a fast hash algorithm is used to perform integrity verification on the synchronized medical data packet; if the synchronized medical data packet passes the integrity verification, the current synchronized medical data packet is regarded as a complete synchronized medical data packet.

2. The verification-based medical data synchronization processing method according to claim 1, characterized in that, The step of segmenting the current image verification data group to generate multiple image data sub-blocks includes: Obtain the total file size of the image verification data group; The number of image data sub-blocks is determined based on the total file size of the image verification data group. The image verification data group is divided according to the number of image data sub-blocks to generate multiple image data sub-blocks.

3. The verification-based medical data synchronization processing method according to claim 1, characterized in that, The step of determining the number of verifications corresponding to each image data sub-block based on the data volume of each image data sub-block includes: Calculate the pixel entropy value of each of the image data sub-blocks, and determine the verification strength corresponding to each of the image data sub-blocks based on the pixel entropy value and the data volume; Obtain the verification correction coefficient, multiply the verification correction coefficient by the verification intensity, and use the multiplication result as the verification number corresponding to each image data sub-block.

4. The verification-based medical data synchronization processing method according to claim 1, characterized in that, The determination of the comprehensive score corresponding to each of the image data sub-blocks based on the number of verifications and the emergency treatment response value includes: Obtain the weight value corresponding to the number of verifications and the weight value corresponding to the emergency treatment response value, respectively. Based on the weight value corresponding to the number of verifications and the weight value corresponding to the emergency treatment response value, a weighted calculation is performed on the number of verifications and the emergency treatment response value, and the result of the weighted calculation is used as the comprehensive score corresponding to each of the image data sub-blocks.

5. The verification-based medical data synchronization processing method according to claim 1, characterized in that, After transmitting each of the image data sub-blocks using multiple transmission channels based on the priority transmission sequence, the method further includes: Obtain the bit error rate and packet loss rate of the image data sub-blocks in each of the transmission channels; If the bit error rate exceeds a preset bit error rate threshold or the packet loss rate exceeds a preset packet loss rate threshold, then the image data sub-blocks in the current transmission channel will be allocated to the backup transmission channel.

6. The verification-based medical data synchronization processing method according to claim 5, characterized in that, If the image data sub-block in the current transmission channel passes the verification, then the current image data sub-block is regarded as a qualified image data sub-block, including: If the bit error rate does not exceed the preset bit error rate threshold and the packet loss rate does not exceed the preset packet loss rate threshold, then a fast hash algorithm is used to verify each of the image data sub-blocks. If the current image data sub-block passes the verification, then the current image data sub-block is determined as a qualified image data sub-block. If the verification of the current image data sub-block fails, the current image data sub-block is marked as a verification failure sub-block, and the forward error correction lossless erasure algorithm is used to repair the verification failure sub-block; wherein, the forward error correction lossless erasure algorithm is an algorithm that divides the original data into k data blocks and encodes m redundant blocks, and the receiving end can completely recover the original data by receiving any k blocks, including Reed-Solomon code or Tornado code; Based on the repaired failed image data sub-blocks, generate each qualified image data sub-block, including: re-participating the repaired image data sub-blocks in hash verification; if the verification passes again, mark the repaired failed image data sub-blocks and the previously qualified image data sub-blocks as qualified, and summarize them to form the final set of qualified image data sub-blocks.

7. A verification-based medical data synchronization processing system, characterized in that, For implementing the method as described in any one of claims 1-6, comprising: The acquisition module is used to acquire medical data to be synchronized, which includes text data and image data. The first determining module is used to determine each text verification data group based on the text data, and to determine each image verification data group based on the image data. The second determining module is used to determine the current text verification data group as a qualified text if the amount of data in the text verification data group does not exceed a preset text data amount threshold. The third determining module is used to divide the current image verification data group into multiple image data sub-blocks if the data volume of the image verification data group exceeds a preset image data volume threshold, and determine the number of verifications corresponding to each image data sub-block based on the data volume of each image data sub-block. The fourth determining module is used to obtain the emergency treatment response value corresponding to each of the image data sub-blocks, and determine the comprehensive score corresponding to each of the image data sub-blocks based on the number of verifications and the emergency treatment response value; The first generation module is used to sort the comprehensive scores in order from the maximum value to the minimum value to generate a priority transmission sequence, and based on the priority transmission sequence, send each of the image data sub-blocks using multiple transmission channels; The fifth determining module is used to determine the current image data sub-block as a qualified image data sub-block if the verification of the current image data sub-block in the current transmission channel passes. The second generation module is used to generate a complete synchronized medical data packet based on each of the verified texts and each of the verified image data sub-blocks.

Images