Method and system for identifying invalid medical image data

Abstract

The invention provides a method and system for identifying invalid medical image data, and the method and system are characterized in that an object is obtained, and the system obtains data of a medical image of a patient with data on user equipment as an object; multi-stage verification: carrying out a plurality of multi-stage tests on the obtained object, i.e., the original data, and checking the basic attributes of the image: if the image passes verification, entering the next step; otherwise, marking as invalid and recording reasons; ending feedback, and providing feedback information to the user by the system according to the verification result and the conversion result; the user manually corrects the image according to the suggestion or waits for automatic correction of the system. According to the invention, a system for identifying common invalid images in medical image data of multiple modals and providing invalid reasons is provided, so that the problem can be quickly corrected in image processing, more accurate measurement is provided for observers, the working process of medical staff is simplified, and the working efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present invention belongs to the field of medical image processing and data analysis, with a particular focus on image validation and format conversion in neuroimaging. It involves the combination of computer science, medical imaging technology, and machine learning models. Through interdisciplinary innovative techniques, it aims to improve the quality and usability of image data. Specifically, it relates to a method and system for identifying invalid medical image data. BACKGROUND

[0002] I. Importance of Medical Images

[0003] Medical images (such as MRI, fMRI, DWI, etc.) play a crucial role in modern medicine. They are used not only for disease diagnosis (such as brain tumors, neurodegenerative diseases, etc.), but also for surgical planning, treatment evaluation, and basic medical research.

[0004] For example:

[0005] 1.1 MRI (Magnetic Resonance Imaging): Used to obtain high-resolution anatomical images of the brain.

[0006] 1.2 fMRI (Functional Magnetic Resonance Imaging): Used to study the functional activity of different brain regions.

[0007] 1.3 DWI (Diffusion Weighted Imaging) and DTI (Diffusion Tensor Imaging): Used to trace neural fibers in the brain, helping to understand neural connections.

[0008] II. Characteristics of Medical Image Data

[0009] Medical image data typically has the following characteristics:

[0010] High dimensionality: For example, fMRI data may contain multiple time frames, forming a four-dimensional spatiotemporal data (3D space + time).

[0011] Complexity: Large data volume and need to meet specific formats and protocols (such as DICOM standards).

[0012] Clinical relevance: Image data needs to support clinical analysis, such as brain functional connectivity analysis or neural fiber tracking.

[0013] III. Existing Challenges

[0014] In practical applications, medical image data often faces the following problems:

[0015] Data corruption or format errors: Image files may be corrupted during transmission or storage, or do not conform to standard formats (such as DICOM or NIFTI).

[0016] Data Incompleteness: For example, DWI images can lack sufficient gradient directions, and fMRI images can lack sufficient time frames, resulting in ineffective analysis.

[0017] Difficult to manually inspect: Due to the complexity and high dimensionality of the data, it is difficult for a clinician or researcher to manually inspect the validity of each image.

[0018] Time sensitivity: In emergency situations such as acute stroke, it is critical to quickly and accurately process image data, but invalid images can cause diagnostic delays.

[0019] IV. Limitations of existing solutions

[0020] Traditional solutions often rely on manual inspection or simple automated tools, but these approaches have the following limitations:

[0021] Inefficiency: Manual inspection is time-consuming and prone to error. The data related to a single patient's brain can be very complex and high-dimensional, making it very difficult for a clinician to manually inspect and interpret this data, for example, to plan surgery or diagnose a patient's brain disease or mental disorder. For example, a correlation matrix of a patient's brain functional magnetic resonance imaging (fMRI) data can be partitioned into more than a hundred partitions, for example, into 379 partitions. Therefore, a single correlation matrix can have more than 10,000 elements, for example, more than 70,000 elements.

[0022] Lack of immediate feedback: Invalid images are often not detected in real-time during image upload or processing, resulting in wasted resources for subsequent processing. When a user uploads a brain image to a processing tool or storage system, they can upload an image that is corrupted, improperly protocolled, or not what the user intended to upload. In some cases, the upload process can be time-consuming, and the user will not realize the image is invalid until the end of the time-consuming process. In other cases, for example, when a user uploads an image for storage and later processing, the user can not realize the image is invalid until hours, days, or weeks after the upload, at which point it can be difficult or impossible to recover a valid image. Using the techniques described in this specification, a system can automatically determine that one or more images are invalid during or prior to the upload process, saving time for the user and improving outcomes for the patient, user, and / or clinician, particularly when valid care is needed in a time-sensitive investigation.

[0023] Lack of corrective advice: Even when an invalid image is detected, it can be difficult to provide specific corrective measures. When an image is invalid, the user often does not know why the image is invalid and what steps must be taken to correct the problem. Using the techniques described in this specification, the system can automatically determine the reason why an image is invalid and show this reason to the user. In some cases, the system can provide the user with an efficient corrective suggestion to make the invalid image valid. In some implementations, the system can automatically generate an updated valid version of the image without user input. This can further save time for the user and improve the health outcomes of the patient.

[0024] Therefore, it is necessary to provide a method and system for automatically identifying invalid medical image data in time. SUMMARY

[0025] In view of the above problems, the present application provides a method and system for identifying invalid medical image data in multi-modal medical image data, which can simplify the workflow of medical staff and improve work efficiency.

[0026] The first aspect of the present application provides a method for identifying invalid medical image data, characterized in that,

[0027] The acquisition object is the data on the user device, which contains the data of the patient's medical image;

[0028] Multi-stage verification, a number of multi-stage tests are performed on the acquired object, i.e. the original data, to check the basic properties of the image: if the image passes the verification, it goes to the next step; otherwise, it is marked as invalid and the reason is recorded;

[0029] End feedback, the system provides feedback information to the user according to the above verification result and conversion result; the user manually corrects the image according to the suggestion or waits for the system to automatically correct it.

[0030] Further, the data is multi-modal medical image data.

[0031] Further, the multi-stage verification includes:

[0032] Primary verification, a number of basic tests are performed on the acquired object, i.e. the original data, to check the basic properties of the image: if the image passes the primary verification, it goes to the next step; otherwise, it is marked as invalid and the reason is recorded;

[0033] Secondary verification, the system performs a more detailed secondary test including a number of steps on the converted image data to ensure the integrity and consistency of the data before and after processing; if the image passes the secondary verification, it is marked as valid; otherwise, it is marked as invalid and the reason is recorded.

[0034] Further, the multi-stage verification includes:

[0035] Format conversion, the system converts the image from the original format to another format; during the conversion process, the integrity of the data before and after the conversion is ensured, and the consistency after the format conversion is ensured.

[0036] Further, the feedback information includes detailed error descriptions or invalid reasons, and correction suggestions related to medical images described in industry standards and professional vocabulary, helping users better understand and solve problems.

[0037] Further, automatic correction, i.e. automatically correcting invalid images, generating updated valid images, and automatically updating versions, the system will verify the corrected images again to ensure the effectiveness and accuracy of the correction measures.

[0038] Further, clinical application, after multiple verifications, automatic correction and other processes, the valid images are used for further clinical post-processing and statistical analysis, such as generating brain function connection data or inputting into machine learning models.

[0039] Further, support for local and remote processing, local processing can quickly respond to users' immediate needs, while remote processing can take advantage of the powerful computing resources of the cloud. The flexible processing mode of local and remote adaptation improves the applicability of the system.

[0040] Another aspect of the present application provides a system for identifying invalid medical image data, characterized by comprising at least one programmable processor and a non-transitory machine-readable medium storing instructions; when executed by the programmable processor, the instructions enable the programmable processor to perform any of the above-mentioned methods for identifying invalid medical image data.

[0041] The present application, relative to the prior art, the system is configured to process medical images describing a patient to determine whether the images are valid. If one or more images are invalid, the system can display (e.g., to a user of the system) data identifying the invalid images, and can prompt a reason why one or more images are invalid. Even more, an automatic processing module can be superimposed for processing one or more invalid images to generate valid updated images, which can speed up the workflow of medical personnel and further improve work efficiency. Specifically, the following beneficial effects are achieved:

[0042] 1. Automatically identify invalid images

[0043] Traditional medical image processing usually relies on manual inspection, which is inefficient and prone to errors. The present application quickly identifies invalid images in an automated manner, saving a lot of time and manpower.

[0044] 2. Support for multiple medical image formats (i.e. various image formats at the input end)

[0045] Due to the different medical imaging devices and application scenarios, different medical image formats are required. The present application supports multiple formats, improving the versatility and compatibility of the system.

[0046] 3. Introducing a multi-stage verification mechanism

[0047] Through the multi-stage verification mechanism, the present application can effectively avoid the problems that may be missed in a single verification stage, and more comprehensively detect the validity and usability of the image.

[0048] 4. Conversion format and verification

[0049] The present application effectively reduces errors introduced in the conversion process by traditional medical image processing methods through secondary verification after conversion, ensuring that the converted image is still usable.

[0050] 5. Detailed user feedback

[0051] Traditional image verification systems usually only provide simple "valid" or "invalid" error feedback. The present application provides detailed error descriptions and correction suggestions for various format medical images to help users better understand and solve problems.

[0052] 6. Automatic correction function The automatic correction function in the system can effectively reduce user manual intervention, maintain the robustness of the system and data processing itself, and further improve the automation level and efficiency of the system.

[0053] 7. Clinical relevance analysis

[0054] In addition to focusing on the validity of the image, the present application also considers the practical application value of the medical image in the clinic. By using valid images for functional connectivity analysis, the system can provide support for clinical diagnosis and treatment.

[0055] 8. Support for local and remote processing

[0056] In the present application, local processing can quickly respond to the immediate needs of users, while remote processing can take advantage of the powerful computing resources of the cloud. The flexible processing mode of local and remote adaptation improves the applicability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0057] Figure 1 is a method flowchart of an example process for determining invalidity of one or more brain images according to the present application.

[0058] Figure 2 is a method flowchart of an example process for processing brain images to determine whether the brain images are invalid according to an embodiment.

[0059] Figure 3is a logic diagram of the image validity criterion of the present application.

[0060] Figure 4 is a diagram of an example system of the medical image processing system of the present application.

[0061] Figure 5 is a diagram of an example computer hardware system of the present application for processing medical images.

[0062] Legend of the figures:

[0063] 1 medical image processor, 11a first initial medical image, 11n n-th initial medical image, 12 invalid initial medical image, 13a first reformatted medical image, 13m m-th reformatted medical image, 14 invalid reformatted medical image,

[0064] 2 user imager, 21a first valid initial medical image, 22m m-th valid initial medical image,

[0065] 3 medical image storage, 31 format conversion module, 32 medical image data storage module. DETAILED DESCRIPTION

[0066] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0067] With reference to the accompanying drawings, Figure 1 the present embodiment illustrates a method for identifying invalid medical image data, comprising the following steps:

[0068] S1, obtaining an object, the system obtains data on a user device, containing patient medical image data; the object can be in various formats, such as MRI, fMRI or DWI / DTI.

[0069] S2, multi-stage verification, a number of multi-stage tests are performed on the obtained object, i.e. the original data, to check the basic properties of the image: if the image passes the verification, it goes to the next step; otherwise, it is marked as invalid and the reason is recorded;

[0070] With reference to the accompanying drawings, Figure 2 the present embodiment illustrates a method for identifying invalid medical image data, comprising the following steps:

[0071] S2.1, preliminary verification, a number of basic tests are performed on the acquired object, i.e. the raw data, checking the basic properties of the image: if the image passes the preliminary verification, it goes to the next step; otherwise, it is marked as invalid and the reason is recorded;

[0072] S2.2, format conversion, the system converts the image from the original format to another format; during the conversion, the integrity of the data before and after the conversion and the consistency after the format conversion are ensured. For example, the system converts the image from DICOM format to NIFTI format.

[0073] S2.3, secondary verification, the system performs more detailed secondary tests on the converted image data, including a number of steps, to ensure the integrity and consistency of the data before and after processing; if the image passes the secondary verification, it is marked as valid; otherwise, it is marked as invalid and the reason is recorded.

[0074] S3, end feedback, the system provides feedback information to the user according to the above verification results and conversion results; the user manually corrects the image according to the suggestions or waits for the system to automatically correct it. In this embodiment, the feedback information on the graphical interface will provide the user with (1) each specific medical image and (2) the corresponding reason for the invalidity of each specific medical image selected from a set of possible reasons for the possible invalidity of the medical image.

[0075] Referring to the accompanying drawings Figure 1 , the following steps can be optionally added to the above method steps:

[0076] S4, automatic correction, i.e. automatically correcting invalid images, generating updated valid images, and automatically updating the version, the system will verify the corrected images again to ensure the effectiveness and accuracy of the correction measures.

[0077] S5, clinical application, after the effective image is subjected to a number of verification, automatic correction and other processes by the system, it is used for further clinical post-processing and statistical analysis, such as generating brain function connection data or inputting into a machine learning model.

[0078] In the process of S1-S5, both local and remote processing can be supported. Local processing can quickly respond to the immediate needs of the user, while remote processing can take advantage of the powerful computing resources of the cloud. The flexible processing mode of local and remote adaptation improves the applicability of the system.

[0079] Wherein the preliminary validation includes a primary test and the secondary validation includes a secondary test, the test content of each test includes several steps, and each step corresponds to the judgment of an effectiveness criterion. For example, if the brain image fails to meet one or more effectiveness criteria for storing, displaying, and / or processing the brain image, the brain image is defined as "invalid"; the invalid brain image can be (i) damaged, (ii) incorrectly formatted according to a specific formatting standard, and / or (iii) a brain image that fails to comply with one or more protocols (e.g., privacy or security protocols).

[0080] Generally, one or more effectiveness criteria can be established using a machine learning model, and in the present embodiment, if the model output represents the answer to a question that a well-trained clinician might ask when treating a patient in clinical practice, the model output is defined as "clinically relevant"; the criteria can be established from several aspects, and the logical relationship can refer to the attached Figure 3 :

[0081] 1. Technical invalid data criteria: file corruption: interruption in transmission / storage resulting in incomplete image (e.g., missing tags in DICOM files, pixel data corruption); parameter error: abnormal scan parameters (e.g., CT slice thickness too large, MRI repetition time, echo time, flip angle settings error, X-ray dose insufficient); format error: non-standard format or incorrect image format (e.g., non-DICOM files, compression format error); or determine that the image does not comply with one or more predetermined protocols; unable to access the header file or pixel data of the image file; the shape of the data describing the image is inconsistent; the image does not have enough time frames or gradient directions; the data describing the image is inconsistent with standard neuroimaging data; the image does not have the correct dimensions;

[0082] 2. Content invalid data criteria: excessive artifact interference: motion artifacts, metal artifacts, device noise (e.g., MRI magnetic field inhomogeneity resulting in banding artifacts); abnormal anatomical structure: incorrect scan site (e.g., chest CT mis-scanned abdomen), patient position offset (e.g., excessive tilt angle); low-quality image: blur (patient movement), overexposure / underexposure (e.g., insufficient X-ray penetration), abnormal contrast.

[0083] 3. Metadata problem criteria: patient information errors: ID, name, age, gender mismatched with clinical information; timestamp abnormalities: duplicate scans (identical timestamps), outdated data (e.g., pre-operative images mixed in post-operative data sets); privacy issues: sensitive information (e.g., patient name saved in plain text) not de-identified; image metadata invalid; image file does not match standard schema; image file cannot be opened using standard tools; voxel data describing the image has no valid values; or voxel data describing a diffusion-weighted image is insufficient to perform constrained spherical deconvolution (CSD). If the model does not fall within the expected range, the data can be corrupted, in which case there can be an additional validation step of fitting a constrained spherical deconvolution (CSD) model to a feature of the diffusion- weighted image.

[0084] In particular embodiments, one or more validity criteria can each be selectively included, used individually or in combination. In processing a data object, for each image, each of a plurality of predetermined tests is processed in a predetermined sequence, the image is processed according to the test to generate a corresponding test output; and a determination is made as to whether the image is invalid based on the plurality of generated test outputs.

[0085] In some embodiments, a determination that a brain image fails to meet a validity criterion can be made only if a plurality of preliminary validations each fail. As a particular example, there can be two tests, each corresponding to the same validity criterion, and if the results of both tests meet respective predetermined thresholds, then the brain image is determined to fail to meet the validity criterion, otherwise the brain image is determined to meet the validity criterion.

[0086] In some embodiments, one or more preliminary validations can have a plurality of different nominal results, such as “pass,” “fail,” and “no conclusion.” As a particular example, if a preliminary validation corresponding to a particular validity criterion has a result of “no conclusion,” then the brain image processor can use another test corresponding to the particular validity criterion to process the brain image, e.g., a test having a binary result.

[0087] In some embodiments, the brain image processor processes each initial image using a predetermined sequence of preliminary validations. The brain image processor can then determine the validity of the initial image based on the results of the predetermined sequence. As a particular example, each first test in the predetermined sequence can have a binary result, such that the initial image is determined to be valid only if the result of each first test in the predetermined sequence is “pass.”

[0088] In other embodiments, for each initial image, the brain image processor processes each first test in the first test sequence of the initial image as a function of the results of the preceding first tests in the sequence. That is, the results of the preceding first tests determine the subsequent first tests themselves. For example, the brain image processor can maintain a data model that defines the next first test or the final validity determination for each possible first test sequence and result. As a specific example, the brain image processor can maintain a tree structure in which each non-leaf node corresponds to a first test, each branch of the tree corresponds to a particular result of the first test of the parent node, and each leaf node corresponds to a particular final validity determination of the brain image. When the brain image processor processes a brain image using first tests and generates a result, the brain image processor can descend from the node corresponding to the first test to a second node in the tree structure along the branch corresponding to the result, corresponding to another first test. The brain image processor can continue traversing the tree until it reaches a leaf node, at which point the brain image processor can determine whether the brain image is valid. The brain image processor can use any appropriate data model to define how the brain image processor should behave as a function of a particular first test sequence and result.

[0089] The brain image storage system 230 also includes a format conversion system 240 configured to process the valid initial brain images 224a-m and generate corresponding reformatted brain images 232a-m in a second format that is different from the first format. After generating the M reformatted brain images 232a-m, the brain image storage system 230 can provide the reformatted brain images 232a-m to the brain image processing system 210 to determine whether one or more of the brain images 232a-m is invalid. In particular, the brain image processing system 210 can process the reformatted images 232a-m according to one or more second tests corresponding to the second image format. Each second test corresponds to one or more validity criteria for the reformatted brain images.

[0090] As noted above, in some embodiments, the result of each second test is a binary validity determination. In other embodiments, one or more of the second tests can have a range of ordered results, e.g., a value between 0 and 1. In other embodiments, one or more of the second tests can have multiple different nominal results, e.g., “pass,” “fail,” and “no conclusion.”

[0091] Table 1 is a table containing some example validity criteria for determining whether a patient's brain image is invalid. Each example criterion includes an example error code and error message that can be shown to a user if the particular image does not satisfy the criterion, as well as a description of the criterion and example recommendations for updating the image that can be shown to the user. The error codes and messages are examples only; in general, the error codes can be any string of alphanumeric characters and the error messages can be any text describing the error. In some implementations, the error codes are not shown to the user and only the error messages or some other notification are shown to alert the user of the particular error. In general, each criterion corresponding to an error code starting with '1' is related to NIfTI images and each criterion corresponding to an error code starting with '2' is related to DICOM images.

[0092] Table 1 Error code examples

[0093] Encoding Error message Description Example recommendation 1001 Error accessing NIfTI content Unable to access header or data of NIfTI file Use external viewer to view image 1002 Shape of data is inconsistent Shape of diffusion weighted imaging (DWI) data series, bval file, and / or bvec file is inconsistent, bval and bvec files contain metadata including gradient directions and diffusion weighting Check that the (x,y,z,t) coordinate series of the DWI is the same shape as the bval / bvec files. 1003 DWI series does not have enough gradient directions for CSD To make DWI series suitable for constrained spherical deconvolution (CSD), it needs to have a threshold number of gradient directions Check that the DWI series has at least, e.g., 24 directions in the bval file and bvec file 1004 fMRI series does not have enough time frames To make fMRI series suitable for connectome analysis, it needs to have a threshold number of time frames Check that the fMRI series has at least, e.g., 60 time frames 1005 Image data in NIfTI image is 0 Voxel data in generated NIfTI file appears to have no valid values Check integrity of uploaded data 1006 Image data is not consistent with neuroimaging data NIfTI file appears to have no valid values, generated NIfTI image appears to be inconsistent with standard neuroimaging data Check integrity of uploaded data 1007 Image does not have correct 3D dimensions Anatomy file should typically be three-dimensional, uploaded data does not have three dimensions Check dimensions of uploaded data 1008 Image does not have correct 4D dimensions Echo planar imaging (EPI) file should typically be a four-dimensional series, uploaded data does not have four dimensions Check dimensions of uploaded data 1009 Error performing fiber tractography Error performing CSD Ensure that the gradient directions of the uploaded DWI series are roughly evenly distributed 2001 Error loading DICOM image Error opening uploaded DICOM file with standard tools Check integrity of uploaded DICOM file 2002 DICOM metadata is invalid One of the following metadata tags in the uploaded DICOM file is invalid: (0002,0001) File Meta Information Version (0002,0012) Implementation Class UID (0002,0013) Implementation Version Name (0002,0002) Media Storage SOP Class UID Check metadata tag (0002,0003) Media Storage SOP Instance UID (0002,0010) Transfer Syntax UID Check metadata tags in uploaded DICOM file 2003 DICOM file architecture is invalid Uploaded DICOM file does not match standard architecture for MR images Check architecture of uploaded DICOM file

[0094] Referring to the accompanying Figure 4 , the present embodiment recites a system for identifying invalid medical image data based on the above-described method, which is an example of a system implemented as a computer program on one or more computers, which can be implemented in one or more locations. The system, components, and techniques described below can be implemented in this system. It includes at least one programmable processor and a non-transitory machine-readable medium storing instructions; when executed by the programmable processor, the instructions enable the programmable processor to perform operations of:

[0095] Obtaining a medical image: obtaining a data object comprising one or more medical images characterizing a patient;

[0096] Processing the data object: to determine one or more particular images that are invalid; and,

[0097] Providing, for display on a graphical interface to a user: data characterizing (1) each particular medical image and (2) a respective reason for the invalidity of each particular medical image selected from a set of possible reasons for which the medical image can be invalid.

[0098] wherein processing the data object to determine one or more particular medical images that are invalid includes, for each medical image: for each of a plurality of predetermined tests, processing the medical image according to the test to generate a respective test output; and determining whether the image is invalid based on the plurality of test outputs generated.

[0099] Referring to the accompanying Figure 4, specifically illustrating an example system for identifying invalid medical image data. The system includes a brain image processor, a user imager, and a brain image store, which are in communication over a network;

[0100] In some embodiments, both the user imager and the brain image store are local to the user, e.g., as components of the same user device. In other implementations, both the user imager and the brain image store are non-local to the user, e.g., both are hosted in a data center, which can be a distributed computing system distributed across one or more locations, with a large number of computers, e.g., hundreds, thousands, or millions of computers in one or more locations. In implementations where the user imager and the brain image store are co-located, the brain image processor can also be co-located.

[0101] In other embodiments, the user imager is local to the user, e.g., as a component of the user device, while the brain image store is non-local to the user, e.g., hosted in the cloud. In these embodiments, the brain image processor can include two components: a first component local to the user in communication with the user imager, and a second component in the cloud in communication with the brain image store. For convenience, the following description will refer to the brain image processor as a single entity, but it will be understood that the brain image processor can have multiple components in multiple different locations.

[0102] The present embodiments use brain imaging data as an example. The user imager can obtain one or more brain images that describe a patient's brain, e.g., the brain images can include one or more MRI images, one or more fMRI images, and / or one or more diffusion tensor images. In some embodiments, the user imager obtains the brain images from one or more devices that capture the brain images, e.g., brain imaging devices. In other implementations, the user imager obtains the brain images from a pre-processing system that has pre-processed the brain images.

[0103] The user imager provides the N initial brain images to the brain image processor, which is configured to process the initial images to determine whether the initial images are valid.

[0104] The brain image store includes a brain image database configured to store brain images of patients. One or more users, such as clinicians treating the patients, can access the brain images of the patients stored on the brain image store. For example, a user can send a request to the brain image database to retrieve a brain image of a patient and display the brain image on a display device of the user. As another example, a user can request that a brain image of a patient stored in the brain image database be processed by one or more machine learning models to generate model outputs that are clinically relevant to the patient.

[0105] From a hardware perspective, as shown in Figure 5 The server computer module 101 can also include a communications interface 110 such as an Ethernet card or wireless modem. Communications interface 110 permits data to be transferred between computer server module 101 and external devices via communications path 120. External devices can include printers, disk drives, routers and other computers coupled to network 120. Communications path 120 can be a standard wired link at one time or a wireless link at another time, depending on the implementation of the system. Communications path 120 can be implemented using Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, or any other communications protocol.

[0106] The server computer module 101 typically includes at least one processor unit 105 and a memory unit 106. The memory unit 106 might include, for example, semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The remote terminal 168 typically includes at least one processor 169 and a memory 172. The computer server module 101 also includes a number of input / output (I / O) interfaces including: an audio-video interface 107 that connects to a video display 114, speakers 117 and microphone 180; an I / O interface 113 for connection to a keyboard 102, mouse 103, scanner 126, camera 127, and optionally a joystick or other human interface device (not shown); and an interface 108 for connection to a storage device 109 such as a hard drive 110, a floppy disk drive and a CD-ROM drive 112. The storage device 109 can also include other storage means such as a floppy disk drive and a tape drive (not shown). An optional modem 116 can be included for connection to a computer network 121, such as an Internet Global Computer Network, or a local area network at a business or an institution, through a network communications channel 123. The modem 116 can be an internal modem, an external modem or a port for connecting an external modem, e.g. through USB. The computer module 101 has a bus 104 for passing data between the above components. The bus 104 can be implemented using any suitable type, as is known in the art. Figure 5 As shown, the local communications network 122 can also be connected through a connection 124 to a wide area network 120, which typically includes a so-called "firewall" device or a device with similar functionality. The local network interface 111 can include an Ethernet circuit card, a BluetoothR wireless arrangement or an IEEE 802.11 wireless arrangement; however, many other types of interfaces can be implemented as the interface 111.

[0107] The I / O interfaces 108 and 113 can provide serial or parallel connectivity, e.g. using a Universal Serial Bus (USB) standard in some implementations. Storage memory devices 109 are provided, typically including a hard disk drive (HDD) 110. Other storage devices can be used, e.g. floppy disk drives, and tape drives (not shown). An optical disk drive 112 is typically provided as a non-volatile source of data. Portable memory devices, such as floppy disks, e.g. in the form of CD-ROM, DVD, Blu-ray disk, USB-RAM, portable external hard drives and floppy disks, can be used as appropriate sources of data to the system 100.

[0108] The components 105 to 113 of the computer module 101 typically communicate via an interconnected bus 104 and in a manner that results in a conventional personal computer functioning, which is well understood in the art. For example, the processor 105 communicates with the memory 106, which stores the software that is executed by the processor 105. The software can include a client application 130 that includes a user interface 131, and a server application 140 that includes a user interface 141. The client application 130 and server application 140 are in communication with one another and with the other components of the computer module 101 via the bus 104. The server application 140 can include a web server that operates as a client of the client application 130.

[0109] The technology described in this specification can be implemented to operate with a computer system, for example, as one or more software applications executable within a computer system. In certain implementations, the one or more software applications execute on a computer server module 101 (remote terminal 168 can also execute processing in conjunction with computer server module 101), and a browser 171 executes on a processor 169 of the remote terminal, thereby enabling a user of the remote terminal 168 to access the software applications executing on the server 101 using the browser 171 (commonly referred to as "the cloud"). In particular, the technology described in this specification can be implemented by instructions in software that execute within the computer system 100. The software instructions can form one or more code modules, each of which performs a specific task. The software can also be divided into two separate parts, where a first part and corresponding code modules perform the described technology, and a second part and corresponding code modules manage a user interface between the first part and a user.

[0110] The software can be stored in a computer readable medium, including the storage devices described below. The software is loaded into the computer system from the computer readable medium, and then executed by the computer system. A computer readable medium having such software or computer program recorded on it is a computer program product. The software modules for implementing the technology described in this specification can also be distributed via a web browser.

[0111] The software is typically stored in the hard disk drive 110 or the memory 106 (and possibly to some extent in the memory 172 of the remote terminal 168). The software is loaded from the computer readable medium into the computer system and executed by the computer system. Thus, for example, the software can include one or more programs stored on an optically readable magnetic disk storage medium (e.g., CD-ROM) 125, read by the optical drive 112. A computer readable medium having such software or computer program recorded on it is a computer program product.

[0112] In some cases, the application programs can be coded in one or more CD-ROMs 125 and read via the appropriate drive 112 by a user, or the user can read the application programs from the network 120 or 122. In addition, the software can be loaded into the computer system 100 from other computer readable media. A computer readable storage medium refers to any non-transitory, physical storage medium that provides recorded instructions and / or data to computer system 100 for execution and / or processing. Examples of such storage media include a floppy disk, magnetic tape, CD-ROM, DVD, Blu-ray disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not these devices are internal or external to computer module 101. Examples of

[0113] The second part of the application programs and the corresponding code modules implementing the one or more graphical user interfaces (GUIs) can be executed to present various applications and / or direct the user through a sequence of steps as guided by one or more computers modules 101. For example, the user of the computer system 100 and the application programs can manipulate the interfaces in a functionally adaptive manner based on drop down menus, context-sensitive menus, or screens provided by the application programs. Other forms of functionally adaptive user interfaces can also be implemented, such as audio interfaces using voice prompts that are output via the speaker 117 and voice commands that are input by the user via the microphone 180.

[0114] Memory represents the collective logic of all the memory modules (including the hard disk drive 109 and the semiconductor memory 106) that can be accessed by the computer module 101.

[0115] When the computer module 101 is first powered on, a power-on self-test (POST) program can be executed. The POST program can be stored in the ROM of the semiconductor memory 106. Hardware devices that store software, such as ROM, are sometimes referred to as firmware. The POST program checks the hardware within the computer module 101 to ensure that it is functioning properly, typically checking the processor 105, the memory (109, 106), and the basic input output system software (BIOS) module, which is also typically stored in ROM, for proper operation. Once the POST program has successfully run, the BIOS can activate the hard disk drive 110. Activating the hard disk drive 110 causes the boot loader program, which resides on the hard disk drive 110, to be executed by the processor 105. This loads the operating system into the RAM memory 106, after which the operating system begins running. The operating system is a system-level application that can be executed by the processor 105 to fulfill various high-level functions, including processor management, memory management, device management, storage management, software application interfaces, and general user interfaces.

[0116] The operating system manages the memory (109, 106) to ensure that each process or application running on the computer module 101 has enough memory to execute without conflicting with the memory allocated to another process. In addition, the different types of memory available in the system must be used properly so that each process can run efficiently. Accordingly, the aggregate memory is not meant to illustrate how a particular segment of memory is allocated (unless otherwise noted), but rather to provide a general view of the memory accessible to the computer system and how it is used.

[0117] The processor includes a number of functional modules, including a control unit, an arithmetic logic unit (ALU), and a local or internal memory, sometimes referred to as cache memory. The cache memory typically includes a number of storage registers in a register section. One or more internal buses functionally connect these functional modules. The processor 105 also typically has one or more interfaces for communicating with external devices over the system bus 104, using the connection 118. The memory is connected to the bus 104 by the connection 119.

[0118] An application program includes a series of instructions, possibly including conditional branch and loop instructions. The program also includes data used in executing the program. The instructions and data are stored in memory locations. Depending on the relative size of the instructions and memory locations, a particular instruction can be stored in a single memory location, as shown by the instruction stored in memory location. Alternatively, an instruction can be split into multiple parts, each part stored in a separate memory location, instruction fragment stored in memory location.

[0119] Although the present system is exemplified by the brain, it can be further extended to other parts of the human body in practice, such as the heart, liver, spleen, lungs, kidneys, etc.

[0120] Although shown separately, in some embodiments, the functionality of two or more systems, devices, or servers can be provided by a single system or server. In some embodiments, the functionality of one shown system, server, or engine can be provided separately by multiple systems, servers, or engines.

[0121] The above description is merely illustrative of the application, and is not intended to limit the scope of the application that is defined by the appended claims. Since numerous modifications and changes can be devised by those skilled in the art, it is intended that all such modifications and changes be considered as within the scope of the application as defined by the appended claims and their equivalents. It is therefore desired that what is claimed be what is desired. It is also intended that each of the individual elements as recited in the claims be implemented by one or more systems, devices, or engines.

Claims

1. A method for identifying invalid medical image data, characterized in that: The system acquires data from the user's device, including patient medical images. Multi-stage verification involves performing several multi-stage tests on the acquired object, i.e., the raw data, to check the basic attributes of the image: if the image passes the verification, proceed to the next step; otherwise, it is marked as invalid and the reason is recorded. Once the feedback is complete, the system will provide feedback information to the user based on the verification and conversion results. The user can then manually correct the image according to the suggestions or wait for the system to correct it automatically.

2. The method for identifying invalid medical image data according to claim 1, characterized in that, The data consists of medical image data in multiple modalities.

3. The method for identifying invalid medical image data according to claim 1, characterized in that, The multi-stage verification includes: Preliminary verification involves performing several basic tests on the acquired object, i.e., the raw data, to check the basic attributes of the image. If the image passes the preliminary verification, proceed to the next step; otherwise, mark it as invalid and record the reason. Secondary verification involves the system performing a more detailed secondary test on the converted image data, including several steps, to ensure the data's integrity and consistency before and after processing. If the image passes the secondary verification, it is marked as valid; otherwise, it is marked as invalid and the reason is recorded.

4. The method for identifying invalid medical image data according to claim 3, characterized in that, The multi-stage verification includes: Format conversion: The system converts images from their original format to another format; during the conversion process, it ensures the integrity of the data before and after conversion and the consistency of the converted format.

5. The method for identifying invalid medical image data according to claim 1, characterized in that, The feedback information includes detailed descriptions of errors or reasons for ineffectiveness, as well as corrective suggestions related to medical images that conform to industry standards and professional terminology, to help users better understand and resolve problems.

6. The method for identifying invalid medical image data according to claim 1, characterized in that: Automatic correction means automatically correcting invalid images, generating updated valid images, and automatically updating the version. The system will then re-verify the corrected images to ensure the effectiveness and accuracy of the corrective measures.

7. The method for identifying invalid medical image data according to claim 1, characterized in that: In clinical applications, after multiple systematic verifications and automatic correction processes, the effective images are used for further clinical post-processing and statistical analysis, such as generating brain functional connectivity data or inputting them into machine learning models.

8. The method for identifying invalid medical image data according to claim 1, characterized in that, It supports both local and remote processing. Local processing can quickly respond to users' immediate needs, while remote processing utilizes the powerful computing resources of the cloud. This flexible processing method, which adapts to both local and remote processing, improves the system's applicability.

9. A system for identifying invalid medical image data, characterized in that, It includes at least one programmable processor and a non-transitory machine-readable medium storing instructions; when executed by the programmable processor, the instructions enable the programmable processor to perform the method for identifying invalid medical image data as described in any one of claims 1-8.

Images