A medical image data automatic compression uploading system and method

Abstract

The application discloses a kind of medical image data automatic compression upload system and method, the present application is by background main program regularly executed disk patrol and with last patrol result comparison, automatically perceive the insertion event of optical disk, U disk or mobile hard disk etc. In addition, the present application further includes the automatic translation mechanism of bottom error information to user-friendly prompt, and the safety protection method when uploading mode switches.The present application realizes the full-process automation from storage device insertion to data upload, effectively reduces the manual operation burden and error risk of medical image data upload.

Description

Technical Field

[0001] This invention relates to the field of medical information technology and instant messaging technology, specifically to an automatic compression and uploading system and method for medical image data. Background Technology

[0002] With the rapid development of internet-based healthcare, the demand for online communication between doctors and patients is increasing. Currently, doctors and patients mainly rely on common instant messaging tools such as WeChat and QQ for daily communication, with WeChat group chats being widely used—doctors create patient groups to post announcements, answer patient questions, and conduct health education. Some healthcare information platforms also provide in-app messaging and SMS notification functions.

[0003] However, existing technologies have the following shortcomings:

[0004] First, the high frequency and repetitive questions from patients lead to repetitive work for doctors. Different patients often ask highly similar or even identical questions, such as postoperative dietary precautions, medication administration methods, and pre-examination preparations. Doctors need to manually type the same answers repeatedly in group chats or search through historical replies to copy and paste. This not only significantly increases the workload of doctors, but also means that manually written replies may vary at different times and under different circumstances, making it impossible to guarantee the accuracy and completeness of each answer. At the same time, doctors lack a systematic management and easy-to-use channel for their accumulated high-quality science popularization content, hindering the effective preservation and transfer of knowledge assets. Furthermore, complex medical science popularization content often requires mixed text and images and structured layouts, but general chat tools have limited support for rich text messages, making it impossible to present professional science popularization article formats.

[0005] Secondly, there is a disconnect between viewing medical reports and group chat communication. After patients upload their examination reports via a mini-program, the system typically only stores the reports in the backend database. Doctors need to manually log in periodically to check for new reports awaiting review, resulting in a significant time delay. Since report data is stored in the backend system, which is separate from group chat communication, doctors need to switch to the chat tool to reorganize their explanations if they wish to communicate with patients after viewing the reports. Some systems offer in-app push notifications, but doctors may miss important notifications if they haven't opened the app. While SMS notifications have high coverage, current solutions are mostly simple text reminders that don't include crucial information such as report type, making it difficult for doctors to quickly assess urgency. Furthermore, medical examination reports are diverse, including genetic testing reports, PET-CT reports, CT reports, MRI reports, ultrasound reports, pathology reports, discharge summaries, etc. Current systems lack a mechanism to present different types of reports in a differentiated and structured manner within the group chat.

[0006] Third, there is insufficient protection for doctors' privacy. In common instant messaging tools, every message sent by doctors directly displays their real name or WeChat nickname, posing a risk of leakage of their personal identity information. Simultaneously, patients cannot clearly distinguish which messages in group chats are from doctors, patients, and systems, resulting in low information identification. Systems do not support automatically and selectively displaying different sender identifiers based on the recipient's identity, failing to achieve dynamic protection of doctors' privacy. Furthermore, while some systems offer administrator deletion functions, they use physical deletion methods, which do not comply with medical data retention compliance requirements. Summary of the Invention

[0007] The purpose of this invention is to provide an automatic medical image data compression and uploading system and method, so as to realize the fully automated operation of device identification, image file compression and remote uploading without manual intervention after an external storage device is inserted into a computer, while ensuring that the system can properly handle abnormal situations and that the data is safe and lossless when switching modes.

[0008] To achieve the above objectives, the present invention adopts the following technical solution:

[0009] A method for automatically compressing and uploading medical image data includes:

[0010] Step S1: The background main program performs disk patrol at preset time intervals to obtain the first disk status information of all accessible disks in the current computer system and compares it with the second disk status information saved during the last timed patrol.

[0011] Step S2: When the comparison result shows that there is a newly added accessible drive letter containing file content, it is determined that an external storage device has been inserted, and the operating system interface is called to obtain the identifiable device type information of the external storage device.

[0012] Step S3: When the identifiable device type information indicates that the external storage device belongs to a preset set of automatically processed device types, the background main program automatically starts a compression processing subroutine independent of the foreground interface. The compression processing subroutine reads the medical image files in the external storage device according to the drive letter path and performs compression processing to generate a compressed package file.

[0013] Step S4: After the compression subroutine completes the compression process, the background main program obtains the storage path and file information of the compressed file and automatically transmits the file information to the upload component.

[0014] Step S5: The upload component reads the compressed file in a block-by-block manner according to the file information, and uploads the read data blocks to the remote server.

[0015] In some embodiments, step S2, after determining that an external storage device has been inserted and before triggering the compression processing subroutine to start, further includes a device type identification step:

[0016] Call the operating system interface to identify the driver type of the external storage device;

[0017] If the device is identified as an optical drive or a removable disk, it is determined to belong to the preset set of automatically processed device types, and a prompt to insert the corresponding output device is given.

[0018] If the device is identified as another type, only a device access prompt will be output, and step S3 will not be executed.

[0019] In some embodiments, the background main program and the front-end interface communicate through three independent IPC message channels established by a security bridging layer;

[0020] The first channel is used to transmit disk insertion and removal events, the second channel is used to transmit error events during disk inspection, and the third channel is used to transmit progress events, completion events, and error events related to compression processing.

[0021] In some embodiments, during the compression process, the compression subroutine reports the current compression progress data to the background main program at a preset period. The background main program forwards the compression progress data to the front-end interface through the third channel. The front-end interface updates and displays the compression percentage, the amount of data processed, the total amount of data to be processed, and the time consumed in real time.

[0022] In some embodiments, step S4, in which the background main program obtains the storage path and file information of the compressed file, specifically includes:

[0023] After compression is completed, the compression subroutine sends a compression completion message to the background main program. The compression completion message carries the complete path of the compressed file, the total size of the original file, and the size of the compressed file.

[0024] The background main program reads the filename and size of the compressed file based on the complete path, and uses this as the file information;

[0025] In step S5, before the upload component reads the compressed file in a block-based reading manner according to the file information, the method further includes: if it is detected that the user has enabled the "automatic upload after compression" function, the upload component is automatically triggered to perform the upload after a preset delay.

[0026] In some embodiments, an automatic error message translation step is also included:

[0027] When the compression processing subroutine or disk inspection module generates a low-level technical error, it captures the original error information returned by the operating system.

[0028] The original error message is converted to lowercase characters and matched with a set of preset error keywords in descending order of priority.

[0029] If a keyword set with the current priority is matched, the corresponding user prompt is displayed and subsequent matching is terminated; if no preset keyword set is matched, the first N characters of the original error message are extracted and concatenated with a default prompt for display.

[0030] In some embodiments, the preset set of multiple error keywords is arranged in descending order of priority as follows:

[0031] The first priority is the first set of keywords that indicate insufficient disk storage space, and the corresponding prompt is "Insufficient disk space on your computer. Please clean up the disk and try again."

[0032] The second priority includes a set of second keywords that indicate that access permissions have been denied, with the corresponding message being "No permission to access the CD-ROM. Please contact the administrator to check the permission settings."

[0033] The third priority includes a set of third keywords that indicate that a file or device is being used, with the corresponding message being "The CD file is being used by another program. Please close the relevant program and try again."

[0034] The fourth priority contains a set of fourth keywords that indicate that a file cannot be found or cannot be opened. The corresponding prompt is "Cannot open CD. Please check if the CD is intact and reinsert it."

[0035] The fifth priority level contains a set of error keywords used to indicate file reading failure or an unknown error, with the corresponding message being "CD reading failed, please replace the CD or reinsert it".

[0036] In some embodiments, a mode switching protection step is also included:

[0037] In response to receiving an instruction to switch from the current upload mode to the target upload mode, check whether there is a compression task or upload task currently being executed;

[0038] If it exists, a user confirmation screen will pop up;

[0039] Upon receiving the user's confirmation instruction to switch, the following steps are executed in sequence: send a cancellation instruction to the current compression task and wait for the compression processing subroutine to exit safely; call the upload component to stop the current upload task; and reset all compression and upload-related status variables to their initial values.

[0040] Based on the target upload mode, start or stop the scheduled disk check function of the background main program;

[0041] After the switch is complete, clear the residual display data generated by the previous compression or upload in the front-end interface.

[0042] In some embodiments, before determining that an external storage device has been inserted and triggering the compression process, a cooling status determination step is further included:

[0043] In response to the first triggering of the compression confirmation pop-up after the external storage device is inserted and being closed or canceled, a pop-up cooling timer for the external storage device is started. During the operation of the pop-up cooling timer, the compression confirmation pop-up will not pop up repeatedly when the same external storage device is inserted again.

[0044] It also includes a space pre-check step before compression: obtaining the total size of the file to be compressed in the external storage device and detecting the available space size of the system temporary storage directory. If the available space size is less than the total size of the file to be compressed multiplied by a preset coefficient, where the preset coefficient is a value greater than 1, the temporary storage directory is automatically switched to other available storage partitions. If the available space of all available partitions is insufficient, a user prompt indicating insufficient disk space is issued and the compression process is terminated.

[0045] This embodiment also provides an automatic compression and uploading system for medical image data, including:

[0046] The front-end interface layer is used to provide the user interaction interface;

[0047] The backend main program layer includes a disk inspection module, a compression scheduling module, and a communication module;

[0048] A security bridging layer connects the front-end interface layer and the back-end main program layer, and is used to encapsulate the functions of the back-end main program layer into a secure call interface for the front-end interface layer to call.

[0049] The disk inspection module is used to perform disk inspections at preset time intervals, obtain the first disk status information of all accessible disks in the current computer system, and compare it with the second disk status information saved during the last timed inspection; when the comparison result shows that there is a newly added accessible disk containing file content, it is determined that an external storage device has been inserted, and the operating system interface is called to obtain the identifiable device type information of the external storage device.

[0050] The compression scheduling module is used to automatically start a compression processing subroutine independent of the front-end interface layer when the identifiable device type information indicates that the external storage device belongs to a preset set of automatically processable device types. The compression processing subroutine reads the medical image files in the external storage device according to the drive letter path and performs compression processing to generate a compressed package file.

[0051] The compression scheduling module is also used to obtain the storage path and file information of the compressed package file after the compression processing subroutine completes the compression processing, and automatically transmit the file information to the upload component in the front-end interface layer through the security bridging layer;

[0052] The upload component is used to read the compressed file in a block-by-block manner according to the file information, and upload the read data blocks to the remote server.

[0053] In some embodiments, the communication module and the front-end interface layer establish three independent IPC message channels through the security bridging layer;

[0054] The first channel is used to transmit disk insertion and removal events, the second channel is used to transmit error events during disk inspection, and the third channel is used to transmit progress events, completion events, and error events related to compression processing.

[0055] In some embodiments, a mode switching management module is also included, for performing:

[0056] In response to receiving an instruction to switch from the current upload mode to the target upload mode, check whether there is a compression task or upload task currently being executed;

[0057] If it exists, a user confirmation interface will pop up through the front-end interface layer;

[0058] Upon receiving the user's confirmation instruction to switch, the following steps are executed in sequence: send a cancellation instruction to the current compression task and wait for the compression processing subroutine to exit safely; call the upload component to stop the current upload task; and reset all compression and upload-related status variables to their initial values.

[0059] Based on the target upload mode, start or stop the scheduled inspection function of the disk inspection module;

[0060] After the switch is complete, clear the residual display data generated by the previous compression or upload in the front-end interface layer.

[0061] In some embodiments, the background main program layer further includes a pop-up cooling control module, which is used to start a pop-up cooling timer for the external storage device in response to the first triggering of the compression confirmation pop-up after the external storage device is inserted and the compression process is triggered before determining that the external storage device is inserted and the compression process is triggered. During the operation of the pop-up cooling timer, the compression confirmation pop-up will not pop up repeatedly when the same external storage device is inserted repeatedly.

[0062] The background main program layer also includes a space pre-detection module, which is used to obtain the total size of the files to be compressed in the external storage device before triggering the compression process, and detect the available space size of the system temporary storage directory. If the available space size is less than the total size of the files to be compressed multiplied by a preset coefficient, where the preset coefficient is a value greater than 1, the temporary storage directory is automatically switched to other available storage partitions. If the available space of all available partitions is insufficient, a user prompt indicating insufficient disk space is issued and the compression process is terminated.

[0063] Compared with the prior art, the present invention has the following key beneficial effects:

[0064] 1. It has achieved full automation of the process from inserting an external storage device to remote uploading. Medical staff only need to complete the device insertion operation, and the remaining steps are automatically executed by the system, which significantly reduces the burden of manual operation and the probability of error.

[0065] 2. Through the automatic device type identification mechanism, it is uniformly compatible with various storage media such as optical discs, USB flash drives, and portable hard drives, without the need to configure dedicated processing software for different devices.

[0066] 3. Compression and uploading are seamlessly integrated through a message-driven automatic connection mechanism, eliminating the process breakpoints that require manual confirmation between the two steps in the existing solution and improving overall processing efficiency.

[0067] 4. Underlying technical errors are automatically converted into easy-to-understand Chinese prompts through a keyword priority matching mechanism, enabling non-technical personnel to independently understand the cause of the anomaly and take corresponding measures.

[0068] 5. The upload mode switching process includes a complete active task detection, user confirmation, and sequential cleanup process to ensure that the switching operation will not cause file corruption or data loss. Attached Figure Description

[0069] Figure 1 This is the overall system architecture diagram.

[0070] Figure 2 This is a schematic diagram of a three-channel IPC communication mechanism. Detailed Implementation

[0071] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0072] See Figure 1-2 To address the technical issues of existing solutions where the system cannot proactively detect the insertion of external storage devices and the entire process relies on manual operation, this application adopts the following technical solution: The main background program periodically performs disk checks at preset time intervals, acquiring the first disk status information of all accessible drives in the current computer system and comparing it with the second disk status information saved during the last periodic check. When the comparison result indicates the presence of a newly added accessible drive containing file content, it determines that an external storage device has been inserted and calls the operating system interface to obtain the identifiable device type information of the external storage device. When the identifiable device type information indicates that the external storage device belongs to a preset set of automatically processed device types, the main background program automatically starts a compression subroutine independent of the foreground interface. This compression subroutine reads the medical image files from the external storage device according to the drive path and compresses them to generate a compressed file. After the compression subroutine completes the compression, the main background program obtains the storage path and file information of the compressed file and automatically transmits the file information to the upload component. The upload component reads the compressed file using a block-based reading method based on the file information and uploads the read data blocks to a remote server.

[0073] The aforementioned timed inspection and before-and-after comparison detection method has low dependence on the operating system and good cross-platform portability. The introduction of an independent compression subprocess ensures that the compression task and interface rendering run in isolated processes, preventing interface unresponsiveness even with extremely large compressed data volumes. Simultaneously, automatic upload is triggered upon compression completion, eliminating the manual confirmation required between compression and upload in existing solutions, and integrating compression and upload steps into a continuous, automatically executed data pipeline. The chunked read-and-upload method effectively avoids the overflow risk that might occur if the entire compressed file is loaded into memory at once by splitting large files into multiple smaller chunks and reading them into memory one by one before uploading.

[0074] To address the technical problem in existing solutions that the system cannot distinguish between different types of storage media and cannot perform differentiated processing for different device types, this application further adopts the following technical solution based on the above-mentioned technical solution: After determining that an external storage device has been inserted, and before triggering the compression processing subroutine to start, a device type identification step is added. Specifically, the operating system interface is called to identify the driver type of the external storage device; if it is identified as an optical drive or removable disk, it is determined to belong to a preset set of automatically processed device types, and a device insertion prompt is output accordingly; if it is identified as another type, only a device access prompt is output, and the compression processing subroutine is not started.

[0075] This solution uses a unified device type identification logic, enabling the same system to handle optical discs, USB flash drives, and external hard drives compatibly without requiring separate processing software for each device type. For other device types not included in the automatic processing set, the system only prompts the user without performing compressed boot, avoiding accidental operation on unexpected devices.

[0076] To address the technical problems in existing solutions where different types of information are transmitted together in the same communication link, causing message interference and preventing the front-end interface from subscribing to specific message types on demand, this application further adopts the following technical solution based on the above-mentioned technical solution: the back-end main program and the front-end interface communicate through a secure bridging layer by establishing three independent IPC message channels; wherein, the first channel is used to transmit disk insertion and removal events, the second channel is used to transmit error events during disk inspection, and the third channel is used to transmit progress events, completion events, and error events related to compression processing.

[0077] For security reasons, the front-end interface running in a browser environment cannot directly access operating system resources. The security bridging layer acts as an intermediary, encapsulating back-end capabilities into standard interfaces for secure front-end calls, thus achieving effective communication between the front-end and back-end while ensuring system security. The channel separation design allows different types of messages to be transmitted in parallel without interference. The front-end interface can selectively listen to a specific channel based on its own state, reducing logical coupling. When additional events of other types are needed later, only the new channel needs to be added without modifying the existing channel logic, demonstrating excellent scalability.

[0078] To address the technical issues of existing solutions where the compression process is opaque to users, and users cannot know the compression progress or estimated waiting time, this application further adopts the following technical solution based on the above-mentioned technical solution: During the compression process, the compression processing subroutine reports the current compression progress data to the background main program at a preset cycle. The background main program forwards the compression progress data to the front-end interface through a third channel. The front-end interface updates and displays multiple indicators in real time, such as the compression percentage, the amount of data processed, the total amount of data to be processed, and the time consumed.

[0079] This real-time progress reporting mechanism allows users to intuitively grasp the execution status of the current compression task. When processing large image datasets, users can reasonably estimate the remaining waiting time based on the displayed progress and time consumption information, avoiding anxiety or misjudgment of system deadlock due to prolonged lack of feedback. Periodic progress reports, combined with the independent compression execution process, ensure that the system maintains good observability and user experience even when running large compression tasks for extended periods.

[0080] To further clarify the specific implementation logic and data flow of automatic uploading after compression, this application further refines the post-compression processing flow based on the aforementioned technical solution: The compression subroutine sends a compression completion message to the main background program after compression. This message carries the complete path of the compressed file, the total size of the original file, and the size of the compressed file. The main background program reads the filename and size of the compressed file based on the complete path as file information. Subsequently, before the upload component reads the compressed file using a chunked reading method based on the file information, if it detects that the user has enabled the "automatic upload after compression" function, it automatically triggers the upload component to perform the upload operation after a preset delay.

[0081] The purpose of setting a delay is to give users a brief window of control immediately after compression is complete—if users find the compression result abnormal, they can cancel the upcoming upload during the delay period to prevent erroneous data from being sent to the server. This delay design achieves a good balance between full automation and ultimate user control.

[0082] To address the technical problem in existing solutions where operating system error messages are incomprehensible to ordinary medical personnel, this application further employs the following technical solution: When a low-level technical error occurs in the compression processing subroutine or disk inspection module, the raw error message returned by the operating system is captured. This raw error message is converted to lowercase characters and matched against multiple preset error keyword sets in descending order of priority. If a keyword set of the current priority is matched, the corresponding user prompt is displayed and subsequent matching terminates; if no preset keyword set is matched, the first N characters of the raw error message are extracted and concatenated with a default prompt for display.

[0083] This translation mechanism ensures that regardless of the type of error, users can obtain at least one understandable problem description and handling suggestions, significantly reducing the system's reliance on professional technical support and enhancing the ability of non-technical personnel to independently handle anomalies.

[0084] To further clarify the priority order of error keyword matching and avoid conflicts caused by multiple matching rules hitting simultaneously, this application further defines the specific arrangement of multiple preset error keyword sets according to their priority from high to low, based on the above technical solution. The specific order is as follows: First priority is the first keyword set containing error keywords indicating insufficient disk storage space, with the corresponding prompt "Insufficient computer disk space, please clean up the disk and try again"; Second priority is the second keyword set containing error keywords indicating access permissions are denied, with the corresponding prompt "No permission to access the CD, please contact the administrator to check permission settings"; Third priority is the third keyword set containing error keywords indicating that a file or device is being used, with the corresponding prompt "CD files are being used by other programs, please close the relevant programs and try again"; Fourth priority is the fourth keyword set containing error keywords indicating that a file cannot be found or cannot be opened, with the corresponding prompt "Cannot open the CD, please check if the CD is intact and reinsert it"; Fifth priority is the fifth keyword set containing error keywords indicating that file reading failed or an unknown error occurred, with the corresponding prompt "CD reading failed, please replace the CD or reinsert it".

[0085] During the error message matching process, different error categories exhibit significant differences in severity and user response. When the original error message simultaneously meets the matching conditions of multiple keyword sets (e.g., the message contains keywords indicating insufficient space and read failure simultaneously), improper matching order may cause the system to prioritize secondary error messages, masking the true cause of the failure. By prioritizing the five error categories according to the principle of "fundamental hardware resource errors take precedence over application-layer access errors"—insufficient space is a hard failure at the system resource level, followed by permission denial, then occupation-related errors, then general open-related errors, and pure read-related errors are used as a fallback after excluding all the aforementioned possibilities—this ensures that the user sees the message closest to the root cause of the problem.

[0086] To address the technical problem of existing solutions directly interrupting ongoing tasks during upload mode switching, leading to file corruption or data loss, this application further adopts the following technical solution based on the aforementioned technical solution: In response to receiving an instruction to switch from the current upload mode to the target upload mode, it checks whether there is currently an ongoing compression or upload task. If so, a user confirmation interface pops up. After receiving the user's confirmation instruction to switch, it executes the following in sequence: sending a cancellation instruction to the current compression task and waiting for the compression processing subroutine to exit safely; calling the upload component to stop the current upload task; and resetting all compression and upload-related status variables to their initial values. Depending on the target upload mode, it starts or stops the background main program's scheduled disk check function. After the switch is completed, it clears the residual display data generated by the previous compression or upload from the foreground interface.

[0087] The aforementioned sequential cleanup process ensures that file writing will never be forcibly interrupted under any circumstances—when canceling compression, the process must wait for the current data block to finish processing before terminating, rather than immediately killing the process; when aborting an upload, the file handle must be closed to release resources. The step of clearing residual data avoids operational confusion caused by displaying mixed old and new patient information.

[0088] To address the technical issues of repeated confirmation windows appearing on the same device under high-frequency scheduled inspections, and compression failures due to insufficient temporary storage space, this application further employs the following technical solution based on the aforementioned technical solution: Before determining that an external storage device has been inserted and triggering the compression process, a cooling status judgment step and a pre-compression space check step are included. The cooling status judgment step is as follows: In response to the first triggering of the compression confirmation pop-up after the external storage device is inserted and being closed or canceled, a pop-up cooling timer for that external storage device is started. During the pop-up cooling timer, the compression confirmation pop-up will not reappear when the same external storage device is repeatedly inserted. The space check step is as follows: The total size of the files to be compressed on the external storage device is obtained, and the available space in the system's temporary storage directory is checked. If the available space is less than the total size of the files to be compressed multiplied by a preset coefficient (which is a value greater than 1), the temporary storage directory is automatically switched to another available storage partition. If the available space in all available partitions is insufficient, a user prompt indicating insufficient disk space is issued, and the compression process is terminated.

[0089] The pop-up cooling mechanism effectively prevents repeated pop-ups from interfering with user operations when the system has not yet processed the device after insertion due to short inspection intervals (e.g., 3 seconds). The space pre-check mechanism avoids the risk of failure due to disk space exhaustion during compression by pre-checking whether the space of the temporary storage directory meets the preset coefficient condition before compression starts.

[0090] To address the system architecture challenges in deploying the aforementioned methods on actual physical devices, this application provides a three-tier architecture system corresponding to the methods described above. This system includes: a front-end interface layer providing a user interface; a back-end main program layer, comprising a disk inspection module, a compression scheduling module, and a communication module; and a security bridge layer connecting the front-end interface layer and the back-end main program layer, which encapsulates the functions of the back-end main program layer into secure call interfaces for the front-end interface layer to invoke. The disk inspection module periodically performs disk inspections at preset time intervals, acquiring the first disk status information of all accessible disks in the current computer system and comparing it with the second disk status information saved during the last periodic inspection. When the comparison result indicates the presence of a newly added accessible disk containing file content, it determines that an external storage device has been inserted and calls the operating system interface to obtain the identifiable device type information of the external storage device. The compression scheduling module automatically starts a compression processing subroutine independent of the front-end interface layer when the identifiable device type information indicates that the external storage device belongs to a preset set of automatically processable device types. The compression processing subroutine reads medical image files from the external storage device according to the disk path and performs compression processing to generate a compressed file. The compression scheduling module is also used to obtain the storage path and file information of the compressed file after the compression subroutine completes the compression process, and automatically transmit the file information to the upload component in the front-end interface layer through the security bridge layer. The upload component is used to read the compressed file in a block-by-block manner according to the file information, and upload the read data blocks to the remote server.

[0091] The front-end interface layer runs in the browser environment and is responsible for displaying all user-visible buttons, progress bars, and prompts. The back-end main program layer runs directly at the operating system level and is the core of the actual execution. The security bridging layer connects the two layers. Since the front-end interface is restricted from directly accessing operating system resources by security policies, this layer encapsulates the functionality of the back-end main program into a set of standard interfaces for the front-end to call. All communication between the front-end and back-end is relayed through this layer, ensuring system security while maintaining functional integrity.

[0092] In order to implement the above three-channel communication mechanism at the system architecture level, this application further specifies, based on the above system technical solution, that: the communication module and the front-end interface layer establish three independent IPC message channels through a security bridging layer; wherein, the first channel is used to transmit disk insertion and removal events, the second channel is used to transmit error events during disk inspection, and the third channel is used to transmit progress events, completion events, and error events related to compression processing.

[0093] The communication module, acting as the hub responsible for message routing and forwarding within the backend main program layer, maintains three long-lived and isolated message channels with the frontend interface layer. Different types of events are transmitted in an orderly manner through their respective destination channels, ensuring that messages are not out of order or interfere with each other at the application layer. This method clearly defines the role of the communication module and the division of labor among the channels in this architecture at the system implementation level.

[0094] To implement the aforementioned mode switching protection method at the system level, this application further specifies, based on the above system technical solution, that it also includes a mode switching management module, used to perform the following operations: In response to receiving an instruction to switch from the current upload mode to the target upload mode, it checks whether there is currently an executing compression task or upload task; if so, it pops up a user confirmation interface through the front-end interface layer; after receiving the user's confirmation instruction to switch, it executes the following in sequence: sending a cancellation instruction to the current compression task and waiting for the compression processing subroutine to exit safely, calling the upload component to stop the current upload task, resetting all compression and upload-related status variables to their initial values; starting or stopping the timed patrol function of the disk patrol module according to the target upload mode; and after the switch is completed, clearing the residual display data generated by the previous compression or upload in the front-end interface layer.

[0095] The mode switching management module, a functional module within the main backend program layer, is responsible for intercepting user mode switching requests, calling the status query interfaces of the compression scheduling module and upload component to detect active tasks, presenting a confirmation interface through the front-end interface layer when necessary, coordinating the sequential cleanup of tasks among various modules based on the user's confirmation, and controlling the start and stop of the disk patrol module according to the switching target. This module visualizes the above methods and steps into executable functional units at the system structure layer, ensuring the security of mode switching operations.

[0096] To implement the aforementioned pop-up cooling mechanism and space pre-check mechanism at the system architecture level, this application further specifies, based on the above system technical solution, that the background main program layer also includes a pop-up cooling control module and a space pre-check module. The pop-up cooling control module, before determining that an external storage device has been inserted and triggering the compression process, responds to the first compression confirmation pop-up being closed or canceled after the external storage device is inserted, and starts a pop-up cooling timer for that external storage device. During the pop-up cooling timer's operation, the compression confirmation pop-up will not reappear when the same external storage device is repeatedly inserted. The space pre-check module, before triggering the compression process, obtains the total size of the files to be compressed on the external storage device and checks the available space in the system's temporary storage directory. If the available space is less than the total size of the files to be compressed multiplied by a preset coefficient (which is a value greater than 1), the temporary storage directory is automatically switched to other available storage partitions. If the available space in all available partitions is insufficient, a user prompt indicating insufficient disk space is issued and the compression process is terminated.

[0097] The pop-up cooling control module suppresses pop-ups during cooling by maintaining cooling records and timer states corresponding to the device drive letter in memory. The specific value setting of the preset coefficient in the space pre-detection module can be configured by those skilled in the art based on the redundancy requirements of the actual application scenario. For example, it can be configured to 1.2 to reserve 20% buffer space, or to 1.5 to reserve 50% buffer space. These are conventional variations that can be made by those skilled in the art without creative effort after reading the specific example of "1.2 times" in the embodiments of this application. The two modules work together to provide security guarantees before compression starts from the perspectives of user experience and system stability.

[0098] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings. The following embodiments are only used to illustrate the present invention and should not be regarded as limiting the scope of the present invention.

[0099] I. Overall System Architecture

[0100] like Figure 1 As shown, the automatic compression and uploading system for medical image data provided in this embodiment adopts a three-layer architecture design, specifically including a front-end interface layer, a security bridging layer, and a back-end main program layer.

[0101] The front-end interface layer runs in the browser environment and is responsible for presenting the interactive interface to the user. This layer includes the following functional areas: an upload mode switching tab, providing two tabs for users to choose between "Manual Upload" and "CD Upload"; a disk monitoring control area, including a start monitoring button, a stop monitoring button, an automatic compression checkbox, and an automatic upload after compression checkbox. The user-selected configuration items are persistently stored in the browser's local storage and remain effective even after the software restarts; a disk status display area, dynamically displaying the current disk status through a color-changing indicator bar—blue for monitoring, green for a device inserted, red for a device removed, and orange for a USB flash drive or external hard drive inserted; a compression progress display area, including a percentage progress bar, status text description, total original file size, amount of data processed, time consumed, a cancel compression button, the file path displayed after compression, a button to open the folder containing the file, and a file selection button; and an upload component, used to perform file chunk reading and remote upload operations.

[0102] The background main program layer runs directly at the operating system level, capable of calling low-level system interfaces to perform tasks such as disk read / write, file operations, and process management. This layer contains three core modules: a disk inspection module, driven by a timer, which periodically scans all drive letters at configurable time intervals; a compression processing subroutine, which runs as a subprocess independent of the foreground interface and is responsible for the actual image file compression and packaging; and a central scheduling module, which coordinates the startup, operation, and shutdown of each module, manages the registration and deregistration of message channels, and controls the entire lifecycle of the compression processing subroutine.

[0103] The security bridging layer acts as an intermediary between the two layers mentioned above, encapsulating the functionality of the backend main program into a set of standard interfaces for secure foreground calls. Because browsers are restricted by the same-origin policy and cannot directly access operating system resources, all foreground-backend communication must pass through the security bridging layer. The interface methods provided by this layer include, but are not limited to: starting disk monitoring, stopping disk monitoring, registering disk status change notification receiving functions, registering disk monitoring error notification receiving functions, registering background message notification receiving functions, starting compression tasks, canceling compression tasks, and reading basic file information. The encapsulation of the backend main program functionality by the security bridging layer is detailed in the appendix. Figure 1 In Chinese, this is simply referred to as "secure call interface encapsulation".

[0104] In terms of hardware operating environment, this system is deployed on a standard computer equipped with an optical drive and a USB interface. The computer has at least a central processing unit (CPU) that supports a 64-bit instruction set, a hard disk storage device (hard disk) for installing the operating system and temporarily storing compressed packages, an optical drive for reading optical discs and / or a USB interface for connecting USB flash drives or external hard drives, and a network interface (network card) for communicating with a remote server.

[0105] II. Specific Implementation of Disk Monitoring and Automatic Detection Methods

[0106] The following details the specific execution process of the disk monitoring and automatic detection method.

[0107] Step 1: Start disk inspection. When the user switches to the "CD-ROM Upload" tab or clicks the "Start CD-ROM Monitoring" button on the front-end interface, the front-end interface sends a start inspection command to the back-end through the security bridge layer, and at the same time transmits the inspection interval parameter (3 seconds in this embodiment) to the back-end.

[0108] Step two, initialize the patrol status. Upon receiving the start command, the background disk patrol module first checks the current module's status flag. If the flag indicates the module is already running, it refuses to start again, preventing the same module from being instantiated multiple times. Then, it immediately performs a complete disk scan, recording all currently accessible drive letters and their statuses as a baseline snapshot, which will serve as a reference for subsequent comparisons. After the baseline snapshot is established, a timer is started to periodically trigger the patrol task at the set intervals.

[0109] Steps three and four involve performing a single inspection. Each time the timer triggers, the inspection module first checks the "Checking" flag. If this flag is true, it indicates that the previous inspection has not yet finished, and the current inspection is skipped to prevent multiple inspection instances from running concurrently and causing state confusion. After confirming safety, the module begins simultaneously scanning all 26 drive letters from A to Z in the system. The checks on all drive letters are performed in parallel to improve scanning efficiency. For each drive letter, the system performs two checks: first, it attempts to access the drive letter to verify its accessibility; second, it attempts to read the file list in the root directory of the drive letter to confirm whether it contains file content.

[0110] Step 5: Compare differences and identify changes. The inspection module performs a comprehensive, item-by-item comparison of the disk status list obtained in this scan with the previously saved baseline snapshot. The comparison results are categorized into three cases:

[0111] First, disks appearing in this scan but not in the baseline snapshot are identified as newly inserted devices. After further verifying that the disk is accessible and that files exist in its root directory, the system retrieves its drive type information by calling the disk type query interface provided by the operating system—this interface can distinguish between optical drives, removable disks (including USB flash drives and external hard drives), and local fixed hard drives. After obtaining the type information, the system sends a "Device Inserted" message to the front-end interface through the first IPC message channel. The message payload contains complete information such as device type, volume label name, and drive letter path.

[0112] Second, disks that existed in the baseline snapshot but disappeared in this scan are considered as devices that have been unplugged. The system sends a "device unplugged" message through the first IPC message channel.

[0113] Third, for disks that exist in both scans, further compare their status changes—for example, if the disk was empty in the previous scan but has content in the current scan, or if it was accessible in the previous scan but is inaccessible in the current scan—and determine whether the event is an insertion or removal event based on the direction of the status change.

[0114] Step 6: Update the baseline snapshot. After this round of comparison is completed, the inspection module saves the scan results as a new baseline snapshot for use in the next round of inspection.

[0115] Step 7: The front-end receives and distributes messages. After receiving the disk status change notification through the receiving function registered in the security bridging layer, the front-end interface first checks the current mode of the interface—if it is currently in the "Manual Upload" tab, the message is discarded and not processed; it only proceeds to the next branch in the "CD Upload" mode.

[0116] Step 8: Process the insert event. If an insert event is received, the system resets the internal state of the upload component to clear any residual data from the previous task, clears the old data in the compression progress display area, and then proceeds to the differentiated processing branch based on the device type.

[0117] III. Specific Implementation of Equipment Type Identification and Differentiated Processing

[0118] Once it is determined in step eight that a device has been inserted, the system performs the following type identification and branching process before starting compression.

[0119] After the system calls the operating system disk type query interface to obtain driver type information, it performs the following branch judgment:

[0120] If the drive is identified as a CD / DVD drive, the disk status display area on the front-end interface will show a green "CD / DVD inserted" status. The system will save the drive letter and path of the CD / DVD in memory for later compression. It will then check if the user previously selected the "Automatic compression" checkbox. If selected, the system will directly trigger the compression process without further confirmation from the user. If not selected, a modal confirmation window will pop up asking, "CD / DVD inserted. Do you want to start compressing the files on the CD / DVD?" If the user clicks "Cancel," the interface status will update to "CD / DVD inserted. User canceled this compression," and the process will terminate.

[0121] If the device is identified as a removable disk, the interface will display an orange notification indicating that a USB flash drive / external hard drive has been inserted. The drive path will be saved, and the automatic compression switch status will be checked using the same logic to determine whether to prompt the user with a pop-up window.

[0122] If the device is identified as another type that does not belong to the above two categories, the interface will only display a prompt that a new device has been found, and will not perform any subsequent compression operations. The user will have to handle the device himself.

[0123] When the device is unplugged, whether it is a CD or a USB flash drive, the interface displays the message "Device ejected". The system clears the drive letter path saved in memory and resets the device's pop-up cooling timer state to ensure that the confirmation window can pop up normally the next time the device is reinserted, without being blocked by the previous cooling state.

[0124] IV. Specific Implementation of the Integrated Compression-Upload Automated Pipeline

[0125] The following details the specific implementation methods for compressing the startup, progress reporting, completion, and cancellation processes.

[0126] When the conditions for starting compression are met after the device is inserted, the front-end interface first restores the compression progress display area to its initial state—progress percentage resets to zero, status text is cleared, and statistical data is reset. Then, it sends a "Start Compression" command to the back-end via the security bridge layer, with the disk drive letter and path to be compressed included in the command parameters. Upon receiving the command, the back-end scheduling module starts a separate compression processing subroutine. This subroutine, upon startup, first checks whether the current operating system is 32-bit or 64-bit, and selects the corresponding compression tool executable file path based on the detection result, ensuring compatibility between the compression tool and the system architecture.

[0127] After the compression subroutine starts, it traverses the disk directory. Unlike conventional compression tools that need to scan all files to obtain the total size before starting compression, this subroutine uses a pipelined compression method—compressing while scanning. As soon as the scanner finds a file, it is added to the compression queue for immediate processing, without waiting for the full disk scan to complete. In this way, even if the disk contains a large number of scattered small files, the compression program can gradually output compressed data during the scanning process, avoiding long periods of no progress feedback caused by excessively long initial scanning times.

[0128] During the compression process, the compression subroutine sends a progress report message to the main background program after compressing a certain amount of data. The message includes the percentage of total data compressed, the total size of all files to be compressed, the amount of data processed, the elapsed time since compression began, and the complete path to the temporary compressed file. The main background program receives this data and forwards it to the front-end interface via a third channel. Upon receiving this data, the front-end interface updates the compression progress bar to the corresponding percentage, displays the status text "Compressing," and dynamically shows the total size of the original files, the amount of data processed, and the elapsed time. Users can use this data to accurately determine the current compression progress and estimate the remaining waiting time.

[0129] Once the compression subroutine has finished compressing all valid files on the disk, it sends a compression completion message to the background main program. This message carries the following statistical fields: total size of the original files, size of the compressed archive file, total time consumed from start to finish, and the full path of the final compressed archive file. After the background main program forwards the message to the foreground via a third channel, the foreground performs the following automatic connection operations:

[0130] The front-end drags the progress bar to 100%, updates the status text to "CD compression complete," sets the status flag to success, and displays the original size, compressed size, and total time in the statistics display area. The front-end calls the "Read File Information" interface to the back-end through the security bridge layer, passing in the complete path of the compressed file. The back-end returns three basic pieces of information: the file name, size, and path. After obtaining the file information, the front-end passes it to the upload component.

[0131] After receiving the file information, the upload component opens the file handle and processes the compressed package using a chunked reading strategy—reading the entire file into fixed-size data blocks one by one into a memory buffer. Each data block read is forwarded to the backend network sending module for upload via a secure bridge layer. Because only one data block is stored in memory at any given time, even if the compressed package is several gigabytes in size or larger, the application's memory usage remains low, preventing memory overflow due to excessively large files.

[0132] Once the upload component starts, if it detects that the user has checked the "Automatically upload after compression" checkbox in the interface, the system will automatically trigger the upload process described above after waiting for 1 second. This 1-second delay provides the user with a final opportunity to control the automatic upload—if the user wishes to cancel the automatic upload, they can manually intervene within 1 second after compression is complete.

[0133] If a user clicks the "Cancel Compression" button during compression, the system first displays a confirmation dialog box titled "Are you sure you want to cancel the current compression task?" to prevent accidental clicks. After user confirmation, the foreground sends a cancellation command to the background via a security bridge layer. The background then forwards this command to the running compression subroutine. Upon receiving the cancellation command, the compression subroutine does not immediately terminate the process but continues to complete the compression and writing operation of the currently processed data block. Only after confirming that the current data block has been safely written to the temporary compressed file does it release resources and exit the process. Before exiting, the compression subroutine sends a "Compression Cancelling" status message to the background; after completely exiting, the background sends a "Compression Cancelled" message. After receiving the cancellation message, the foreground completely restores the compression progress display area to its initial blank state before compression started.

[0134] V. Specific Implementation of the Three-Channel IPC Communication Mechanism

[0135] The following combination Figure 2 This section details the implementation of three independent IPC message channels.

[0136] The IPC message channels in this system are implemented based on the publish-subscribe mechanism provided by the security bridging layer. Channel establishment is automatically executed when the front-end page finishes loading. The front-end registers three independent callback functions through the security bridging layer, and each callback function is bound to a corresponding channel.

[0137] The first channel, the disk status change channel, is dedicated to transmitting disk insertion and removal events. The first receiving function registered by the front-end through the security bridging layer is bound to this channel. When the background disk inspection module detects a disk status change, the central scheduling module encapsulates the event into a data structure containing the event type and device information, and sends it to the front-end through this channel. Once triggered, the front-end's first receiving function parses the device type, device name, and drive letter path from the data, and then calls the corresponding interface update logic based on the event type—insertion events call the device insertion processing function, and removal events call the device removal processing function.

[0138] The second channel, the disk monitoring error channel, is dedicated to transmitting errors that occur during disk inspection. The second receiving function registered by the front-end through the security bridge layer is bound to this channel. When the disk inspection module encounters an anomaly while accessing a drive letter, such as the drive letter being inaccessible or a read list timeout, the main scheduling module sends the raw error information to the front-end through this channel. After the front-end's second receiving function is triggered, it first hands the raw error information to an automatic error translator for processing, translating it into plain Chinese before updating the interface status and pop-up prompts.

[0139] The third channel, or background message channel, is dedicated to transmitting various messages related to compression processing. The third receiving function registered by the front-end through the security bridging layer is bound to this channel. Internally, this function implements a message routing and dispatching function, which can distribute different messages to different processing sub-functions based on the type field in the message: messages of type "progress" are sent to the progress update processing function, messages of type "complete" are sent to the completion processing function, messages of type "error" are sent to the error handling function, and messages of type "cancelling" and "cancelled" are sent to the cancellation status handling function.

[0140] All three channels register simultaneously when the front-end page loads, and simultaneously perform a deregistration operation to release resources when the page is closed or the user logs out of the system. This unified lifecycle management ensures that no message is lost due to an unregistered receiving function, nor does it cause exceptions due to a deactivated receiving function still receiving messages.

[0141] VI. Specific Implementation of the Automatic Error Message Translation Method

[0142] The following details the automatic mapping process from underlying error messages to user-friendly prompts.

[0143] When an exception occurs during the execution of low-level operations by the compression subroutine or disk inspection module, the operating system returns a raw error message containing a specific error code or error description text. This raw message is captured and first converted to lowercase characters.

[0144] After conversion, the system checks the lowercase error messages in descending order of defined priority to see if they contain keywords of a specific semantic category. The specific comparison order is as follows:

[0145] The system first checks if the error message contains semantic keywords indicating insufficient disk storage space, such as "enospc," "space," or "disk full" commonly found in English environments. The vocabulary for indicating insufficient space may differ across operating systems and language environments; the English keywords given in the embodiments of this application are specific examples rather than exhaustive limitations. If a match is found, the system directly outputs "Insufficient computer disk space, please clean up the disk and try again," and terminates all subsequent matching checks.

[0146] If the insufficient space category is not found, the system then checks for semantic keywords indicating that access permissions are denied, such as "eperm", "access", or "permission". If a match is found, the system outputs "No permission to access the CD-ROM. Please contact the administrator to check permission settings" and terminates the check.

[0147] If no match is found, continue checking for semantic keywords indicating that a file or device is in use, such as "ebusy," "in use," or "locked." If a match is found, output "The CD file is being used by another program. Please close the relevant program and try again" and terminate the check.

[0148] Continue checking for semantic keywords indicating that a file cannot be found or opened, such as "open," "cannot find," "not found," or "enoent." If a match is found, output "Unable to open CD. Please check if the CD is intact and reinsert it" and terminate the check.

[0149] The final check will detect the presence of semantic keywords indicating file read failure or an unknown error, such as "read," "unknown error," or "unexpected." If a match is found, the message "CD read failed. Please replace the CD or reinsert it" will be output, and the check will terminate.

[0150] If none of the above five semantic keywords are matched in the original error message, the system will extract the first 100 characters of the original error message and concatenate them with "Please try again or contact technical support" as the final default prompt message.

[0151] Once the translation is complete, the front-end interface will update the compression status to "Abnormal", display a simplified translation prompt in the progress display area, and pop up a modal error message box for user confirmation.

[0152] VII. Specific Implementation of Security Protection Methods for Upload Mode Switching

[0153] The following details the execution process of the upload mode switching security protection method.

[0154] When a user clicks the upload mode switching tab—for example, switching from the "Manual Upload" tab to the "CD Upload" tab, or vice versa—the system's event interceptor first captures the click event, temporarily suspends the switching action, and enters the security check process.

[0155] The security check process is executed as follows: the system reads the compression task status variable and the upload task status variable respectively. The compression task status variable indicates whether there is an active compression processing subroutine currently running and whether the current compression progress has reached 100%; the upload task status variable indicates whether the internal transmission status of the upload component is "uploading". If the compression progress has not reached 100% or the upload status is "uploading", it is determined that there is an active task.

[0156] If an active task exists, the system will display a confirmation dialog box on the foreground interface, stating, "Switching upload mode will interrupt the currently running compression / upload task. Do you want to continue?" The dialog box provides "OK" and "Cancel" buttons. If the user clicks "Cancel," the switching operation is intercepted and terminated, the system remains in the current mode, and the current task continues to execute unaffected.

[0157] If the user clicks "OK", the system will execute the task cleanup in the prescribed order:

[0158] The first step is to send a cancellation command to the background through the security bridge layer if the compression task status variable indicates that there is active compression. Then, the system waits for the background to return a "compression has been cancelled" confirmation message. The system will not perform the next operation until the confirmation is received, so as to ensure that the compression processing subroutine has completed the writing of the current data block and exited safely, and there is no situation where the file is accidentally truncated.

[0159] The second step involves the system invoking the abort method of the upload component if the upload task status variable indicates active uploads. Upon receiving the abort command, the upload component stops sending the current data block, closes the file handle, and releases the occupied system resources.

[0160] The third step involves resetting all status variables related to compression and uploading to their initial values, including but not limited to the compression percentage variable, the amount of data processed variable, the total file size variable, the timer, and the status flag.

[0161] After the cleanup is complete, the system performs start / stop management of the monitor according to the target mode: if the target mode is "CD upload" and the current disk patrol timer is not started, the system calls the background start patrol interface to activate the timer; if the target mode is "manual upload" and the current timer is running, the system calls the stop patrol interface to shut down the timer and release the timer resources.

[0162] Finally, regardless of whether there are currently active tasks, the system performs an interface cleanup operation after each switch, resetting all values ​​in the compression progress display area to zero, clearing text, resetting the progress bar to 0%, eliminating all residual traces of the previous patient's data on the interface, and avoiding misjudgments caused by the mixing of old and new data.

[0163] VIII. Specific Implementation of Compression Confirmation Anti-Duplicate Pop-up and Space Pre-inspection

[0164] Regarding the specific implementation of the pop-up cooling mechanism: When an external storage device is inserted, the system determines whether a compression confirmation pop-up needs to be displayed based on the user's automatic compression switch settings. Specifically, when the pop-up is displayed, a cooling record entry for that device's drive letter is created in memory. When the pop-up is closed by the user or canceled, the timer for this cooling record entry starts counting from the current moment for a preset cooling time value, set to 15 seconds in this embodiment. Before the timer reaches zero, if the disk inspection module detects another device inserted with the same drive letter, the system, after entering the device type identification branch and before triggering the compression confirmation pop-up, first checks the cooling record entry corresponding to that drive letter. If the record exists and the timer has not yet reached zero, the pop-up process is skipped, and no repeated confirmation window is displayed to the user. After the timer reaches zero, the system automatically deletes the cooling record entry, allowing a normal pop-up for the next insertion. This mechanism avoids interference caused by repeated pop-ups when the user has inserted a device but has not yet performed any operations due to the short interval between periodic inspections (3 seconds in this embodiment).

[0165] Regarding the specific implementation of the space pre-check mechanism: When the system determines that a device belongs to the type that can be automatically processed and meets the compression trigger conditions, the system executes the space pre-check process before starting the compression processing subroutine. Specifically, the disk inspection module has obtained the total size of all files on the device when it is inserted, and records this value as the total amount of data to be compressed, S. Subsequently, the system calls the operating system interface to query the available space size of the temporary storage directory specified by the current system, and records this value as the available space, F. The system compares F with the product of S and a preset coefficient K, where K is a value greater than 1, and in this embodiment, K is set to 1.2. If F ≥ S×K, it indicates that the available space of the current temporary directory is at least 20% more than the total amount of data to be compressed, which is sufficient to accommodate the temporary files generated during the compression process and the final compressed package. The system directly creates a compression task in this directory. If F < S×K, it indicates that the remaining space in the current temporary directory may not be sufficient to support the complete execution of the compression process. The system iterates through all available storage partitions via the operating system interface, querying the available space of each partition one by one, and recording the available space of that partition as F_i. The same condition of F_i ≥ S×K is then applied. After finding the first storage partition that meets the condition, the path of that partition is set as the temporary working directory for this compression task. If, after iterating through all available partitions, no partition meets the above condition, the system prompts the user with a pop-up window on the front-end interface: "Disk space is insufficient. Please release storage space and try again," and terminates the current compression process without starting the compression subroutine. This space pre-check mechanism effectively avoids accidents such as compression failure or even corruption of compressed data due to disk fullness during the compression process.

[0166] In summary, this application, through the coordinated operation of various modules and steps in the above-mentioned system architecture, method flow, and specific implementation methods, realizes the fully automated uploading of medical image data from external storage media such as optical discs, USB flash drives, or portable hard drives to remote servers, effectively solving the technical problems of high reliance on manual labor, poor equipment compatibility, fragmented processes, unfriendly error feedback, and insecure mode switching in existing solutions.

[0167] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for automatically compressing and uploading medical image data, characterized in that, include: Step S1: The background main program performs disk patrol at preset time intervals to obtain the first disk status information of all accessible disks in the current computer system and compares it with the second disk status information saved during the last timed patrol. Step S2: When the comparison result shows that there is a newly added accessible drive letter containing file content, it is determined that an external storage device has been inserted, and the operating system interface is called to obtain the identifiable device type information of the external storage device. Step S3: When the identifiable device type information indicates that the external storage device belongs to a preset set of automatically processed device types, the background main program automatically starts a compression processing subroutine independent of the foreground interface. The compression processing subroutine reads the medical image files in the external storage device according to the drive letter path and performs compression processing to generate a compressed package file. Step S4: After the compression subroutine completes the compression process, the background main program obtains the storage path and file information of the compressed file and automatically transmits the file information to the upload component. Step S5: The upload component reads the compressed file in a block-by-block manner according to the file information, and uploads the read data blocks to the remote server.

2. The method according to claim 1, characterized in that, In step S2, after determining that an external storage device has been inserted, and before triggering the compression processing subroutine to start, a device type identification step is also included: Call the operating system interface to identify the driver type of the external storage device; If the device is identified as an optical drive or a removable disk, it is determined to belong to the preset set of automatically processed device types, and a prompt to insert the corresponding output device is given. If the device is identified as another type, only a device access prompt will be output, and step S3 will not be executed.

3. The method according to claim 1, characterized in that, The background main program and the front-end interface communicate through three independent IPC message channels established by a security bridging layer; The first channel is used to transmit disk insertion and removal events, the second channel is used to transmit error events during disk inspection, and the third channel is used to transmit progress events, completion events, and error events related to compression processing.

4. The method according to claim 3, characterized in that, During the compression process, the compression subroutine reports the current compression progress data to the background main program at a preset cycle. The background main program forwards the compression progress data to the front-end interface through the third channel. The front-end interface updates and displays the compression percentage, the amount of data processed, the total amount of data to be processed, and the time consumed in real time.

5. The method according to claim 1, characterized in that, In step S4, the background main program obtaining the storage path and file information of the compressed file specifically includes: After compression is completed, the compression subroutine sends a compression completion message to the background main program. The compression completion message carries the complete path of the compressed file, the total size of the original file, and the size of the compressed file. The background main program reads the filename and size of the compressed file based on the complete path, and uses this as the file information; In step S5, before the upload component reads the compressed file in a block-based reading manner according to the file information, the method further includes: if it is detected that the user has enabled the "automatic upload after compression" function, the upload component will be automatically triggered to perform the upload after a preset delay.

6. The method according to claim 1, characterized in that, It also includes an automatic error message translation step: When the compression processing subroutine or disk inspection module generates a low-level technical error, it captures the original error information returned by the operating system. The original error message is converted to lowercase characters and matched with a set of preset error keywords in descending order of priority. If a keyword set with the current priority is matched, the corresponding user prompt is displayed and subsequent matching is terminated; if no preset keyword set is matched, the first N characters of the original error message are extracted and concatenated with a default prompt for display.

7. The method according to claim 6, characterized in that, The preset sets of multiple error keywords are arranged in descending order of priority as follows: The first priority is the first set of keywords that indicate insufficient disk storage space, and the corresponding prompt is "Insufficient disk space on your computer. Please clean up the disk and try again." The second priority includes a set of second keywords that indicate that access permissions have been denied, with the corresponding message being "No permission to access the CD-ROM. Please contact the administrator to check the permission settings." The third priority includes a set of third keywords that indicate that a file or device is being used, with the corresponding message being "The CD file is being used by another program. Please close the relevant program and try again." The fourth priority contains a set of fourth keywords that indicate that a file cannot be found or cannot be opened. The corresponding prompt is "Cannot open CD. Please check if the CD is intact and reinsert it." The fifth priority contains a set of error keywords used to indicate file reading failure or an unknown error, with the corresponding message being "CD reading failed, please replace the CD or reinsert it".

8. The method according to claim 1, characterized in that, It also includes mode switching protection steps: In response to receiving an instruction to switch from the current upload mode to the target upload mode, check whether there is a compression task or upload task currently being executed; If it exists, a user confirmation screen will pop up; Upon receiving the user's confirmation instruction to switch, the following steps are executed in sequence: send a cancellation instruction to the current compression task and wait for the compression processing subroutine to exit safely; call the upload component to stop the current upload task; and reset all compression and upload-related status variables to their initial values. Based on the target upload mode, start or stop the scheduled disk check function of the background main program; After the switch is complete, clear the residual display data generated by the previous compression or upload in the front-end interface.

9. The method according to claim 1, characterized in that, Before determining that an external storage device has been inserted and triggering the compression process, a cooling status determination step is also included: In response to the first triggering of the compression confirmation pop-up after the external storage device is inserted and being closed or canceled, a pop-up cooling timer for the external storage device is started. During the operation of the pop-up cooling timer, the compression confirmation pop-up will not pop up repeatedly when the same external storage device is inserted again. It also includes a space pre-check step before compression: obtaining the total size of the file to be compressed in the external storage device and detecting the available space size of the system temporary storage directory. If the available space size is less than the total size of the file to be compressed multiplied by a preset coefficient, where the preset coefficient is a value greater than 1, the temporary storage directory is automatically switched to other available storage partitions. If the available space of all available partitions is insufficient, a user prompt indicating insufficient disk space is issued and the compression process is terminated.

10. An automatic compression and uploading system for medical image data, characterized in that, include: The front-end interface layer is used to provide the user interaction interface; The backend main program layer includes a disk inspection module, a compression scheduling module, and a communication module; A security bridging layer connects the front-end interface layer and the back-end main program layer, and is used to encapsulate the functions of the back-end main program layer into a secure call interface for the front-end interface layer to call. The disk inspection module is used to perform disk inspections at preset time intervals, obtain the first disk status information of all accessible disks in the current computer system, and compare it with the second disk status information saved during the last timed inspection; when the comparison result shows that there is a newly added accessible disk containing file content, it is determined that an external storage device has been inserted, and the operating system interface is called to obtain the identifiable device type information of the external storage device. The compression scheduling module is used to automatically start a compression processing subroutine independent of the front-end interface layer when the identifiable device type information indicates that the external storage device belongs to a preset set of automatically processable device types. The compression processing subroutine reads the medical image files in the external storage device according to the drive letter path and performs compression processing to generate a compressed package file. The compression scheduling module is also used to obtain the storage path and file information of the compressed package file after the compression processing subroutine completes the compression processing, and automatically transmit the file information to the upload component in the front-end interface layer through the security bridging layer; The upload component is used to read the compressed file in a block-by-block manner according to the file information, and upload the read data blocks to the remote server.

Images