Asynchronous segmented base64 decoding method and system for hospital-wide clinical rehabilitation integration system

Abstract

This invention discloses an asynchronous segmented Base64 decoding method and system for a hospital-wide integrated clinical rehabilitation system. The method includes: S1: Dynamic segmentation; parsing the Base64 encoded string to identify the data type, and dividing the segment length according to the data type and the total data length; S2: Asynchronous task scheduling; dividing the decoding task into multiple levels according to the priority of medical business, and allocating the decoding task to the core thread pool and elastic thread pool according to the level; S3: Parallel decoding; precompiling the mapping relationship between Base64 encoded characters and their corresponding binary values ​​into a hash table, and using SIMD instructions to perform parallel operations on the segmented encoded data; S4: Fault tolerance verification; verifying integrity; S5: Result merging and callback; thereby improving decoding efficiency and ensuring integrity.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical data processing, in particular to an asynchronous segmented Base64 decoding method and system for a hospital-wide clinical rehabilitation integrated system. BACKGROUND

[0002] The hospital-wide clinical rehabilitation integrated system is a core medical system that integrates outpatient rehabilitation, inpatient rehabilitation, rehabilitation assessment, rehabilitation training, data traceability, and other full-process businesses. During its operation, a large amount of binary medical data needs to be frequently transmitted and stored, including rehabilitation images (such as X-ray films, magnetic resonance images), dynamic rehabilitation action videos, structured electronic medical records, and multi-dimensional assessment index data. To ensure the compatibility and integrity of data during network transmission, such binary data is usually converted into ASCII character streams using Base64 encoding before transmission and temporary storage, and then restored to the original binary data through Base64 decoding at the data usage end.

[0003] Existing Base64 decoding technologies mainly include synchronous single-thread decoding and simple multi-thread decoding, which have obvious technical defects in the application scenario of the clinical rehabilitation integrated system: 1. Insufficient decoding performance, difficult to adapt to real-time processing requirements of medical big data: Clinical rehabilitation images, dynamic training videos, and other data are large in size, and the length of a single data after Base64 encoding can reach tens of megabytes to hundreds of megabytes. Traditional synchronous decoding methods require sequential processing of each byte, which takes a long time to decode, resulting in interface lag, data loading delay, and other problems when rehabilitation doctors retrieve image data and view real-time assessment reports, affecting rehabilitation efficiency; Simple multi-thread decoding can handle multiple threads in parallel, but it lacks adaptation to the association of medical data segments, and is prone to decoding fragmentation and loss of data integrity.

[0004] 2. Synchronous blocking characteristics, affecting the overall concurrency capability of the system: Existing decoding functions are mostly in synchronous execution mode, which occupies system core thread resources during decoding, resulting in a decrease in the concurrency processing capability of the clinical rehabilitation integrated system. When multiple departments and multiple terminals simultaneously initiate decoding requests (such as rehabilitation department doctors retrieving historical images, nurses entering real-time assessment data, and rehabilitation devices synchronizing training parameters), thread blocking and system response delay may occur, and even cause data transmission timeout and other faults.

[0005] 3. Lack of medical data adaptability and low decoding fault tolerance: Medical data has extremely high requirements for integrity and accuracy, and there are abnormal scenarios such as data fragment loss, transmission delay, and minor deviations in encoding format. Existing Base64 decoding tools do not have fault tolerance mechanisms designed for the characteristics of medical data. Once a data anomaly occurs, the decoding process is terminated, resulting in the inability to restore the original medical data and affecting the continuity of rehabilitation diagnosis and treatment decisions. At the same time, existing technologies cannot dynamically allocate decoding resources according to the priority of medical data (such as emergency rehabilitation images and general rehabilitation assessment reports).

[0006] 4. Resource imbalance and poor adaptability: The hardware resources of the integrated clinical rehabilitation system need to be dynamically allocated among multiple modules such as decoding processing, business logic operation, data storage, and terminal interaction. Traditional decoding technology lacks resource scheduling optimization, and is prone to excessive consumption of CPU and memory resources during the decoding process. This affects the operation of core business modules such as data synchronization of rehabilitation training equipment and real-time updates of electronic medical records, resulting in a decrease in the overall stability of the system. Summary of the Invention

[0007] The purpose of this invention is to provide an asynchronous segmented Base64 decoding method and system for an integrated clinical rehabilitation system for the whole hospital, so as to solve one or more of the above-mentioned technical problems.

[0008] To achieve this objective, the present invention adopts the following technical solution: The asynchronous segmented Base64 decoding method for the hospital-wide integrated clinical rehabilitation system includes: S1: Dynamic segmentation; Parse Base64 encoded strings to identify data types, divide the data into segments based on the data type and the total data length, and generate a unique identifier for each segment; S2: Asynchronous task scheduling; Decoding tasks are divided into multiple levels according to the priority of medical business, and then allocated to the core thread pool and elastic thread pool according to the level; and the enqueueing and dequeueing of decoding tasks are implemented through message queues. S3: Parallel decoding; The mapping relationship between Base64 encoded characters and their corresponding binary values ​​is pre-compiled into a hash table, and SIMD instructions are used to perform parallel processing on the segmented encoded data. S4: Fault tolerance check; Verify the integrity of each data segment, correct encoding format deviations, and verify the integrity of the merged segments. S5: Result merging and callback; The ordered merging of decoded segments is achieved based on segment identifiers, and the results are fed back using an asynchronous callback method.

[0009] In some implementations, step S1 specifically includes: S11: Data type identification; Data types can be identified by parsing the prefix identifier of the Base64 encoded string or associating it with business context; S12: Dynamic calculation of segment length; Calculate the segment length based on the data type and the total data length; S13: Boundary alignment processing; Based on the 6-bit grouping characteristic of Base64 encoding, it is ensured that the segment boundary falls at the 4-byte alignment position of Base64 encoding; S14: Fragment identifier generation; Each segment is assigned a unique identifier.

[0010] In some implementations, the data types in step S11 include: rehabilitation images, dynamic videos, electronic medical records, and assessment reports; In step S12, the segment length of rehabilitation images and dynamic videos is set to 4MB-8MB; the segment length of electronic medical records and assessment reports is set to 1MB-2MB. When the total data length is ≤4MB, decode directly without segmentation; When 4MB < total data length ≤ 32MB, divide the data into segments of 4MB each. When the total data length is greater than 32MB, it should be divided into segments of 8MB each. In step S14, the unique identifier includes: data ID, segment number, length, and checksum.

[0011] In some implementations, step S2 specifically includes: S21: Priority ranking; Decoding tasks are divided into three levels based on medical service priorities: emergency, routine, and low priority. S22: Dynamic expansion of the thread pool; Decoding tasks are assigned to the core thread pool and the elastic thread pool based on their priority level. The core thread pool is used to handle urgent and regular tasks, while the elastic thread pool is used to handle low-priority tasks. The number of core threads is fixed, while the number of elastic threads can be dynamically changed according to the length of the task queue. S23: Asynchronous scheduling; Tasks are enqueued and dequeued using a message queue, and asynchronous task debugging does not occupy business threads; S24: Status monitoring; Monitor the execution status of each decoding task in real time and automatically retry tasks that time out.

[0012] In some implementations, in step S21, the emergency level includes: emergency rehabilitation images and training data for critically ill patients; Standard level includes: general outpatient rehabilitation assessment report, medical history; Low priority includes: rehabilitation data archiving and backup; In step S22, the core thread pool has a fixed number of 8 threads; the elastic thread pool has a maximum number of 16 threads and dynamically expands and shrinks according to the queue length of low-priority tasks. In step S24, the execution status includes: waiting, executing, completed, and exception. When the task timeout reaches 5 seconds, a retry is performed, and the number of retries does not exceed 3.

[0013] In some implementations, step S3 specifically includes: S31: Precompiled decoding table; The mapping relationship between Base64 encoded characters and their corresponding binary values ​​is pre-compiled into a hash table; S32: SIMD instruction acceleration; Based on the CPU architecture, the single instruction multiple data (SIMD) instruction set is used to perform parallel operations on the segmented encoded data, and a GPU-accelerated decoding interface is configured. Specifically, GPU resources can be called to accelerate decoding for the core thread pool, or GPU resources can be called to accelerate decoding for rehabilitation image data and dynamic video. S33: Medical data processing; During the decoding process, invalid spaces and newline characters in the encoded string are automatically filtered out.

[0014] In some implementations, step S4 specifically includes: S41: Fragment-level verification; After each segment is decoded, the integrity of the segment data is verified using a preset checksum. S42: Formatting error handling; Fuzzy matching algorithm is used to correct encoding format deviations; S43: Result-level validation; After the decoded segments are merged, the logical relationship between the length of the original Base64 encoded string and the length of the decoded binary data is compared, and integrity verification is performed in accordance with medical data format specifications.

[0015] In some implementations, if the segment verification fails in step S41, the segment re-decoding is automatically triggered or a request is made to retransmit the corresponding segment. In step S42, if the encoding format cannot be corrected, it is marked as an abnormal segment, and the overall decoding process is not terminated.

[0016] In some implementations, step S5 specifically includes: S51: Ordered Merging; Based on the sequence number in the segment identifier, the parallel decoded segments are concatenated in their original order to generate complete binary data; S52: Data cache; Binary data is temporarily cached in memory, and a data index is generated simultaneously. S53: Asynchronous callback; The decoding result is fed back to the corresponding business module through a callback function.

[0017] The beneficial effects of this invention are: 1. Design a two-factor segmentation strategy based on data type and data length. At the same time, based on the 4-byte alignment characteristic of Base64 encoding, segment boundary calibration is achieved through modulo operation to avoid decoding errors caused by segmentation. 2. Design a dual-pool architecture of core thread pool + elastic thread pool. The core thread pool is bound to urgent and regular decoding tasks, while the elastic thread pool dynamically expands / shrinks according to the queue length of low-priority tasks. At the same time, non-blocking communication between modules is realized through message queue to avoid decoding threads occupying the core business resources of the clinical rehabilitation system. 3. The dual-engine decoding algorithm of pre-compiled hash table + SIMD instruction set optimizes the traditional "character-by-character table lookup" logic of Base64 decoding. The pre-compiled hash table mapping Base64 characters and binary values ​​reduces the table lookup time complexity from O(n) to O(1); at the same time, the CPU's SIMD single instruction multiple data instruction set is called to realize multi-character parallel decoding operation. 4. To address the high integrity requirements of medical data, a three-layer fault-tolerant verification mechanism is designed to ensure the accuracy and integrity of the decoded data; 5. Design a unique segment identifier containing a data ID, segment sequence number, and CRC-32 checksum. During the merging stage, "unordered reception and ordered merging" is achieved based on the segment sequence number, allowing splicing to begin without waiting for all segments to be decoded. At the same time, the integrity of the segments is verified by the CRC-32 checksum, and abnormal segments can be re-decoded individually without retrying the whole process, significantly reducing the retry cost of decoding medical big data. Attached Figure Description

[0018] Figure 1 This is one of the step diagrams of the asynchronous segmented Base64 decoding method of the integrated clinical rehabilitation system for the whole hospital of the present invention; Figure 2 This is the second step diagram of the asynchronous segmented Base64 decoding method of the integrated clinical rehabilitation system for the whole hospital of the present invention; Figure 3 This is a flowchart illustrating the asynchronous segmented Base64 decoding method of the integrated clinical rehabilitation system for the whole hospital according to the present invention; Figure 4This is a structural diagram of the asynchronous segmented Base64 decoding system of the integrated clinical rehabilitation system for the whole hospital of the present invention. Detailed Implementation

[0019] The present invention will now be described in further detail with reference to the accompanying drawings.

[0020] refer to Figures 1 to 3 The asynchronous segmented Base64 decoding method for the hospital-wide integrated clinical rehabilitation system includes: S1: Dynamic segmentation; Parse Base64 encoded strings to identify data types, divide the data into segments based on the data type and the total data length, and generate a unique identifier for each segment; S2: Asynchronous task scheduling; Decoding tasks are divided into multiple levels according to the priority of medical business, and then allocated to the core thread pool and elastic thread pool according to the level; and the enqueueing and dequeueing of decoding tasks are implemented through message queues.

[0021] S3: Parallel decoding; The mapping relationship between Base64 encoded characters and their corresponding binary values ​​is pre-compiled into a hash table, and SIMD instructions are used to perform parallel processing on the segmented encoded data. S4: Fault tolerance check; Verify the integrity of each data segment, correct encoding format deviations, and verify the integrity of the merged segments. S5: Result merging and callback; The ordered merging of decoded segments is achieved based on segment identifiers, and the results are fed back using an asynchronous callback method.

[0022] Step S1: Dynamic segmentation, specifically including S11 to S14.

[0023] S11: Data type identification; Data types can be identified by parsing the prefix identifier of the Base64 encoded string or associating it with business context; The data types include: rehabilitation images, dynamic videos, electronic medical records, and assessment reports.

[0024] S12: Dynamic calculation of segment length; Calculate the segment length based on the data type and the total data length; The data type calculation method is as follows: The segment length of rehabilitation images and dynamic videos is set between 4MB and 8MB, which can be adapted to GPU-accelerated decoding; The segment length of electronic medical records and assessment reports is set between 1MB and 2MB to balance decoding speed and segment correlation. How to calculate the total length of data: When the total data length is ≤4MB, decode directly without segmentation; When 4MB < total data length ≤ 32MB, divide the data into segments of 4MB each. When the total data length is greater than 32MB, it is divided into segments of 8MB each.

[0025] S13: Boundary alignment processing; Based on the 6-bit grouping characteristic of Base64 encoding, it is ensured that the segment boundary falls within the 4-byte alignment position of the Base64 encoding; in particular, the segment boundary can be calibrated by using the modulo operation method, thereby avoiding decoding errors caused by segmentation.

[0026] S14: Fragment identifier generation; Each segment is assigned a unique identifier, which includes: data ID, segment number, length, and checksum (CRC-32). This prepares the ground for subsequent merging and fault tolerance checks.

[0027] Therefore, step S1 is based on a dynamic adaptive segmentation strategy of medical data type and length, which is different from the traditional fixed-length segmentation method. It designs a dual-factor segmentation strategy of data type + data length. At the same time, based on the 4-byte alignment characteristic of Base64 encoding, segment boundary calibration is achieved through modulo operation to avoid decoding errors caused by segmentation.

[0028] Step S2: Asynchronous task scheduling, specifically including S21 to S24.

[0029] S21: Priority ranking; Decoding tasks are divided into three levels based on medical service priorities: emergency, routine, and low priority. The emergency level includes: emergency rehabilitation imaging and training data for critically ill patients; Standard level includes: general outpatient rehabilitation assessment report, medical history; Low priority includes: rehabilitation data archive backup.

[0030] S22: Dynamic expansion of the thread pool; Decoding tasks are allocated to the core thread pool and the elastic thread pool based on the level. The core thread pool is used to handle urgent and regular tasks, while the elastic thread pool is used to handle low-priority tasks.

[0031] The number of core thread pools is fixed, while the number of elastic thread pools can change dynamically according to the queue length (number of tasks). For example, the core thread pool is set to a fixed 8 threads; the elastic thread pool has a maximum of 16 threads and dynamically expands and shrinks according to the queue length of low-priority tasks to avoid resource waste and improve efficiency.

[0032] S23: Asynchronous scheduling; Task enqueueing and dequeueing are implemented through a message queue, and asynchronous task debugging does not occupy business threads; thus, the system can process other business requests normally during the decoding process, avoiding thread blocking.

[0033] S24: Status monitoring; Monitor the execution status of each decoding task in real time and automatically retry tasks that time out; The execution status includes: waiting, executing, completed, and exception. When a task times out by 5 seconds, a retry is initiated, with a maximum of 3 retries. This ensures efficient task execution.

[0034] Therefore, step S2 utilizes an asynchronous task scheduling mechanism based on priority queues, combined with the business priority requirements of the integrated clinical rehabilitation system, to achieve dynamic resource allocation. A dual-pool architecture of a core thread pool and an elastic thread pool is designed. The core thread pool is bound to urgent and regular decoding tasks, while the elastic thread pool dynamically expands / shrinks based on the queue length of low-priority tasks. Simultaneously, non-blocking communication between modules is achieved through a message queue, preventing decoding threads from consuming core business resources of the clinical rehabilitation system.

[0035] Step S3: Parallel decoding, specifically including S31 to S33.

[0036] S31: Precompiled decoding table; The mapping relationship between Base64 encoded characters and their corresponding binary values ​​is pre-compiled into a hash table; thus, it replaces the traditional character-by-character search method, improving decoding speed and efficiency by more than 30%.

[0037] S32: SIMD instruction acceleration; Based on the CPU architecture, the Single Instruction Multiple Data (SIMD) instruction set is used to perform parallel processing on the segmented encoded data, and a GPU-accelerated decoding interface is configured. Specifically, GPU resources can be used to accelerate decoding for the core thread pool, or for rehabilitation image data and dynamic videos; thus, GPU resources can be used to accelerate decoding, further reducing decoding time.

[0038] S33: Medical data processing; During the decoding process, invalid spaces and newline characters in the encoded string are automatically filtered out; thus, interference characters that are easily introduced into medical data transmission are reduced, eliminating the need for additional preprocessing steps for filtering and improving decoding efficiency.

[0039] Therefore, step S3 improves decoding performance and medical data adaptability by using pre-compiled decoding tables and SIMD instruction acceleration. The dual-engine decoding algorithm of pre-compiled hash tables and SIMD instruction sets optimizes the traditional "character-by-character table lookup" logic of Base64 decoding. The pre-compiled hash table mapping Base64 characters to binary values ​​reduces the table lookup time complexity from O(n) to O(1). At the same time, it calls the CPU's SIMD single instruction multiple data instruction set to realize multi-character parallel decoding operations. Combined with the "invalid character filtering" function of medical data, the decoding speed is improved by more than 30% compared with the traditional solution.

[0040] Step S4: Fault tolerance verification, specifically including S41 to S43.

[0041] S41: Fragment-level verification; After each segment is decoded, the integrity of the segment data is verified using a preset checksum (CRC-32). If the segment verification fails, the segment will be automatically re-decoded or a request will be made to retransmit the corresponding segment.

[0042] S42: Formatting error handling; Fuzzy matching algorithms are used to correct encoding format deviations, including character loss and case confusion. If the encoding format deviation cannot be corrected, it is marked as an abnormal segment, and the overall decoding process is not terminated. This ensures that decoding is uninterrupted.

[0043] S43: Result-level validation; After the decoded segments are merged, the logical relationship between the length of the original Base64 encoded string and the length of the decoded binary data is compared, and integrity verification is performed in accordance with medical data format specifications. The medical data format specifications include: image file header identifiers and medical record structured tags. This ensures that the restored medical data can be parsed and used correctly.

[0044] Therefore, step S4 designs a three-layer fault-tolerant verification mechanism to ensure the accuracy and integrity of the decoded data, in response to the high integrity requirements of medical data.

[0045] Step S5: Result merging and callback, specifically including S51 to S53.

[0046] S51: Ordered Merging; Based on the sequence number in the segment identifier, the parallel decoded segments are concatenated in their original order to generate complete binary data; S52: Data cache; Binary data is temporarily cached in memory, and a data index is generated at the same time, which facilitates rapid retrieval by the integrated clinical rehabilitation system.

[0047] S53: Asynchronous callback; The decoding result is fed back to the corresponding business module through a callback function; The decoding results include: complete data, status identifier, verification information, etc. The business modules include: image viewing module, medical record management module, etc. Therefore, the callback process adopts a non-blocking mode, which does not affect the operation of other business functions of the system.

[0048] Therefore, step S5 achieves ordered merging of decoded segments based on segment identifiers, and uses an asynchronous callback method to provide feedback results, avoiding blocking the business process. A unique segment identifier is designed, consisting of a data ID, segment sequence number, and CRC-32 checksum. During the merging phase, "unordered reception and ordered merging" is achieved based on the segment sequence number, allowing splicing to begin without waiting for all segments to be decoded. Simultaneously, the integrity of the segments is verified using the CRC-32 checksum; abnormal segments can be re-decoded individually without requiring a complete retry, significantly reducing the retry cost of decoding medical big data.

[0049] refer to Figure 4 The asynchronous segmented Base64 decoding system of the hospital's integrated clinical rehabilitation system includes: Dynamic segmentation module 1 is used to receive Base64 encoded string data and perform dynamic segmentation according to the data type and total data length; that is, it is used to perform step S1: dynamic segmentation. Asynchronous task scheduling module 2 is used to allocate decoding thread resources according to the priority of medical services; that is, it is used to execute step S2: asynchronous task scheduling. Parallel decoding module 3 is used to perform parallel decoding on segments; that is, it is used to execute step S3: parallel decoding. Fault tolerance verification module 4 is used to verify the integrity of data and correct encoding format deviations; that is, it is used to execute step S4: fault tolerance verification. The result merging and callback module 5 is used to merge decoded segments in an orderly manner and to return the results in an asynchronous callback manner; that is, it is used to execute step S5: result merging and callback. It also includes a real-time monitoring and feedback module 6 for rehabilitation scenarios. This module 6 can work with monitoring tools to collect core indicators and rehabilitation business scenario information from the system or mini-program, providing data support for load adjustment.

[0050] Implementation of dynamic segmentation module 1: Implemented in Java, the system identifies data types by parsing the prefix identifier of the Base64 encoded string (e.g., image data prefix "data:image / dicom;base64,"). It then calculates the segment length based on the total data length: when the data length is ≤4MB, it decodes directly without segmentation; when 4MB < length ≤ 32MB, it is divided into 4MB segments; when the length > 32MB, it is divided into 8MB segments. During segmentation, the system ensures that the boundaries fall within the 4-byte alignment position of the Base64 encoding. Boundary calibration is achieved through modulo operations, generating segment identifiers containing the data ID, segment number, length, and CRC-32 checksum.

[0051] Implementation of asynchronous task scheduling module 2: Implemented using the event loop mechanism of the Netty framework, it maintains three priority queues (urgent, normal, and low priority). The core thread pool has a fixed number of 8 threads (handling urgent and normal tasks), while the elastic thread pool has a maximum of 16 threads, dynamically expanding / shrinking based on the length of the low-priority task queue. A scheduled task monitors the status of each queue, automatically retrying tasks that time out (exceeding 5 seconds), with a maximum of 3 retries.

[0052] Implementation of parallel decoding module 3: The core decoding logic is implemented in C++, with a pre-compiled Base64 character mapping hash table. Parallel computation is performed using the CPU's AVX2SIMD instruction set to improve decoding speed. For rehabilitation imaging data, a GPU acceleration interface is provided, enabling batch decoding by utilizing GPU resources via CUDA. Invalid characters are automatically filtered during decoding, requiring no additional preprocessing.

[0053] Implementation of fault tolerance verification module 4: A CRC-32 checksum algorithm is implemented for fragment-level verification. To address the issue of missing Base64 encoded characters, an adjacent character context inference algorithm is used for correction. For case confusion, all characters are uniformly converted to uppercase before decoding. Result-level verification verifies the integrity of the DICOM identifier in the image file header and the structured tags in the medical record, ensuring that the decoded data is usable.

[0054] Result merging and implementation of callback module 5: The decoding results for each segment are stored using a ConcurrentHashMap. These segments are then concatenated in order of their sequence numbers to generate complete binary data, which is temporarily cached in memory (cache duration: 10 minutes, automatically released when not called). The results are fed back to the business module via an asynchronous callback interface. The callback parameters include a data byte array, decoding status (success / failure), and verification information.

[0055] This application constructs a modular decoupled architecture for the entire medical data decoding process, breaking through the traditional "decoding-verification-merging" coupled design pattern of decoding tools. It designs and constructs a five-layer decoupled architecture of dynamic data segmentation, asynchronous scheduling, parallel decoding, fault-tolerant verification, and result callback. Each module can be deployed independently and upgraded separately, adapting to the "multi-terminal, multi-service" expansion requirements of clinical rehabilitation systems. For example, the parallel decoding module can be replaced with a GPU-accelerated version without modifying other modules.

[0056] The beneficial technical effects of this application are as follows: 1. Significantly improved decoding performance to meet the needs of medical big data: Through optimizations such as dynamic adaptive segmentation, SIMD instruction acceleration, and GPU adaptation, the decoding speed is 2-5 times faster than traditional synchronous decoding. For 100-megabyte rehabilitation image data, the decoding time is reduced to less than a second, solving the problem of data loading delay in clinical rehabilitation diagnosis and treatment and improving the efficiency of diagnosis and treatment.

[0057] 2. Asynchronous non-blocking design to ensure system concurrency: The asynchronous task scheduling and message queue mechanism is adopted. The decoding process does not occupy the core business thread of the system, avoiding thread blocking. This enables the integrated clinical rehabilitation system to handle multiple terminals and multiple types of decoding requests at the same time, improving the system's concurrency processing capability by more than 40% and ensuring the smooth operation of multi-department collaborative diagnosis and treatment.

[0058] 3. Strong adaptability to medical scenarios and high fault tolerance: The dynamic segmentation strategy and three-layer fault tolerance verification mechanism are designed for the characteristics of medical data. It can adapt to various medical data types such as images, medical records, and videos, effectively handle data transmission anomalies and format deviations, and achieve decoding integrity and accuracy of over 99.9%, meeting the high reliability requirements of medical data.

[0059] 4. Optimized resource scheduling and improved system stability: Dynamically allocate thread resources based on medical business priorities, and elastically expand / shrink the thread pool to avoid excessive consumption of system resources during the decoding process, ensuring the stable operation of core business modules such as rehabilitation equipment synchronization and medical record updates, and reducing the system failure rate.

[0060] 5. High compatibility and easy integration: This tool adopts a standardized interface design, which can be seamlessly integrated into the existing hospital-wide integrated clinical rehabilitation system without large-scale modification of the system architecture. It also supports multi-language (Java, Python, C++) calls, adapts to the technical stack requirements of medical systems, and is highly practical.

[0061] The above description only discloses some embodiments of the present invention. For those skilled in the art, various modifications and improvements can be made without departing from the inventive concept of the present invention, and these all fall within the scope of protection of the invention.

Claims

1. An asynchronous segmented Base64 decoding method for a hospital-wide integrated clinical rehabilitation system, including: S1: Dynamic segmentation; Parse Base64 encoded strings to identify data types, divide the data into segments based on the data type and the total data length, and generate a unique identifier for each segment; S2: Asynchronous task scheduling; Decoding tasks are divided into multiple levels according to the priority of medical business, and then allocated to the core thread pool and elastic thread pool according to the level; and the enqueueing and dequeueing of decoding tasks are implemented through message queues. S3: Parallel decoding; The mapping relationship between Base64 encoded characters and their corresponding binary values ​​is pre-compiled into a hash table, and SIMD instructions are used to perform parallel processing on the segmented encoded data. S4: Fault tolerance check; Verify the integrity of each data segment, correct encoding format deviations, and verify the integrity of the merged segments. S5: Result merging and callback; The ordered merging of decoded segments is achieved based on segment identifiers, and the results are fed back using an asynchronous callback method.

2. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 1, characterized in that, Step S1 specifically includes: S11: Data type identification; Data types can be identified by parsing the prefix identifier of the Base64 encoded string or associating it with business context; S12: Dynamic calculation of segment length; Calculate the segment length based on the data type and the total data length; S13: Boundary alignment processing; Based on the 6-bit grouping characteristic of Base64 encoding, it is ensured that the segment boundary falls at the 4-byte alignment position of Base64 encoding; S14: Fragment identifier generation; Each segment is assigned a unique identifier.

3. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 2, characterized in that, In step S11, the data types include: rehabilitation images, dynamic videos, electronic medical records, and assessment reports; In step S12, the segment length of rehabilitation images and dynamic videos is set to 4MB-8MB; the segment length of electronic medical records and assessment reports is set to 1MB-2MB. When the total data length is ≤4MB, decode directly without segmentation; When 4MB < total data length ≤ 32MB, divide the data into segments of 4MB each. When the total data length is greater than 32MB, it should be divided into segments of 8MB each. In step S14, the unique identifier includes: data ID, segment number, length, and checksum.

4. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 1, characterized in that, Step S2 specifically includes: S21: Priority ranking; Decoding tasks are divided into three levels based on medical service priorities: emergency, routine, and low priority. S22: Dynamic expansion of the thread pool; Decoding tasks are assigned to the core thread pool and the elastic thread pool based on their priority level; the core thread pool is used to handle urgent and normal tasks, while the elastic thread pool is used to handle low-priority tasks. The number of core thread pools is fixed, while the number of elastic thread pools can change dynamically according to the length of the task queue. S23: Asynchronous scheduling; Tasks are enqueued and dequeued using a message queue, and asynchronous task debugging does not occupy business threads; S24: Status monitoring; Monitor the execution status of each decoding task in real time and automatically retry tasks that time out.

5. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 4, characterized in that, In step S21, the emergency level includes: emergency rehabilitation images and training data for critically ill patients; Standard level includes: general outpatient rehabilitation assessment report, medical history; Low priority includes: rehabilitation data archiving and backup; In step S22, the core thread pool has a fixed number of 8 threads; the elastic thread pool has a maximum number of 16 threads and dynamically expands and shrinks according to the queue length of low-priority tasks. In step S24, the execution status includes: waiting, executing, completed, and exception; when the task timeout reaches 5 seconds, a retry is performed, and the number of retries does not exceed 3.

6. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 1, characterized in that, Step S3 specifically includes: S31: Precompiled decoding table; The mapping relationship between Base64 encoded characters and their corresponding binary values ​​is pre-compiled into a hash table; S32: SIMD instruction acceleration; Based on the CPU architecture, the single instruction multiple data (SIMD) instruction set is used to perform parallel operations on the segmented encoded data, and a GPU-accelerated decoding interface is configured. Specifically, GPU resources can be called to accelerate decoding for the core thread pool, or GPU resources can be called to accelerate decoding for rehabilitation image data and dynamic video. S33: Medical data processing; During the decoding process, invalid spaces and newline characters in the encoded string are automatically filtered out.

7. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 1, characterized in that, Step S4 specifically includes: S41: Fragment-level verification; After each segment is decoded, the integrity of the segment data is verified using a preset checksum. S42: Formatting error handling; Fuzzy matching algorithm is used to correct encoding format deviations; S43: Result-level validation; After the decoded segments are merged, the logical relationship between the length of the original Base64 encoded string and the length of the decoded binary data is compared, and integrity verification is performed in accordance with medical data format specifications.

8. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 7, characterized in that, In step S41, if the segment verification fails, the segment re-decoding is automatically triggered or a request is made to retransmit the corresponding segment. In step S42, if the encoding format cannot be corrected, it is marked as an abnormal segment, and the overall decoding process is not terminated.

9. The asynchronous segmented Base64 decoding method for the integrated clinical rehabilitation system of the whole hospital according to claim 1, characterized in that, Step S5 specifically includes: S51: Ordered Merging; Based on the sequence number in the segment identifier, the parallel decoded segments are concatenated in their original order to generate complete binary data; S52: Data cache; Binary data is temporarily cached in memory, and a data index is generated simultaneously. S53: Asynchronous callback; The decoding result is fed back to the corresponding business module through a callback function.

10. An asynchronous segmented Base64 decoding system for the hospital-wide integrated clinical rehabilitation system, including: The dynamic segmentation module is used to receive Base64 encoded string data and perform dynamic segmentation based on the data type and the total length of the data. The asynchronous task scheduling module is used to allocate decoding thread resources according to the priority of medical services; The parallel decoding module is used to perform parallel decoding on segments; The fault tolerance verification module is used to verify the integrity of data and correct encoding format deviations. The Result Merging and Callback module is used to merge decoded segments in an orderly manner and uses an asynchronous callback method to return the results.

Images