Control methods, equipment and storage media for pathological slide scanning equipment

Abstract

This application discloses a control method, device, and storage medium for a pathology slide scanning device. This application relates to the field of medical device control technology. The control method for the pathology slide scanning device includes: acquiring a preset protocol construction sequence and the direction of a protocol reconstruction cursor, where the protocol reconstruction cursor is the index of the current attempt position in the protocol construction sequence; determining the evidence type based on the direction of the protocol reconstruction cursor, and matching the protocol template of the evidence type, where the evidence type includes a barcode pathology number, slide type, and default protocol; when no protocol template is matched or the current evidence value is empty, performing protocol reconstruction, pointing the protocol reconstruction cursor to the next evidence type, re-determining the evidence type based on the direction of the protocol reconstruction cursor, and matching the protocol template of the evidence type; and instantiating the protocol template as a candidate scanning protocol. This application has the technical effect of improving the quality of pathology slide scanning.

Description

Technical Field

[0001] This application relates to the field of medical device control technology, and in particular to a control method, device and storage medium for a pathological slide scanning device. Background Technology

[0002] Currently, automated pathology slide scanning equipment requires full-field image acquisition of the slides. Before the slides are actually scanned, macroscopic positioning images and barcode images are typically acquired to identify the pathology number or sample identifier of the slide, determine the slide type, and then determine scanning parameters such as objective magnification and scanning mode. Traditional technical solutions, after determining the scanning parameters, treat them as several independent fields, modifying only individual scanning parameters, such as magnification, without organizing all scanning parameters into a complete scanning protocol. This leads to inconsistencies between the backend hardware and software operation, resulting in asynchronous execution results and consequently, a decline in scan quality. Summary of the Invention

[0003] The main objective of this application is to provide a control method, device, and storage medium for a pathological slide scanning device, aiming to solve the technical problem that the independent scanning parameter fields lead to a decrease in scanning quality.

[0004] To achieve the above objectives, this application provides a control method for a pathological slide scanning device, the control method comprising: Obtain the preset protocol construction sequence and the pointer of the protocol reconstruction cursor, where the protocol reconstruction cursor is the index of the current attempt position in the protocol construction sequence; The evidence type is determined based on the pointer of the protocol reconstruction cursor. The protocol template of the evidence type is matched. The evidence types include barcode pathology number, slide type and default protocol. When the pointer of the protocol reconstruction cursor is to barcode pathology number, the set of barcode mapping protocol templates is traversed and the matching protocol template is selected based on the starting position, matching length and prefix conditions. When the pointer of the protocol reconstruction cursor is to slide type, the set of type mapping protocol templates is traversed and the matching protocol template is selected based on slide type and target type label. When the pointer of the protocol reconstruction cursor is to default protocol, the preset default protocol template is selected. When the protocol template is not matched or the current evidence value is empty, the protocol is reconstructed, the protocol reconstruction cursor is pointed to the next evidence type, the evidence type is re-determined based on the direction of the protocol reconstruction cursor, and the protocol template of the evidence type is matched. Instantiate the protocol template as a candidate scanning protocol.

[0005] In one embodiment, after instantiating the protocol template as a candidate scanning protocol, the process includes: Generate the full vector of the target device's operating state based on the candidate scanning protocol; Write the candidate scanning protocol into the operation unit of each device; The actual equipment operating state full vector is collected from each equipment operating unit, and it is verified field by field with the target equipment operating state full vector to determine whether the equipment has entered the target operating state. If the device enters the target operating state, it accepts the candidate scan protocol and performs a scan.

[0006] In one embodiment, after collecting the actual device operating state full vector from each device operating unit, performing field-by-field verification with the target device operating state full vector to determine whether the device has entered the target operating state, the process includes: If the device does not enter the target operating state, perform protocol reconfiguration.

[0007] In one embodiment, instantiating a protocol template as a candidate scanning protocol includes: If the candidate scanning protocol obtained by instantiating the protocol template has missing fields, the protocol is completed according to the priority of the scenario basic protocol field, the device default protocol field, and the security fallback field.

[0008] In one embodiment, protocol reconfiguration includes: Determine if a next evidence type exists in the protocol construction sequence. If it exists, generate a candidate scanning protocol and a full vector of the target device's running state based on the next evidence type. If it does not exist, enter the blocking state.

[0009] In one embodiment, generating candidate scanning protocols and the target device runtime full vector based on the next evidence type includes: Construct an empty shadow session, which has the same parameter structure as the actual running session; Based on the next evidence type, generate candidate scanning protocols and the full vector of the target device's operating state, write the candidate scanning protocols into the shadow session, and obtain the full vector of the actual device's operating state based on the parameters of the shadow session. The full vector of the actual device's running state is verified field by field with the full vector of the target device's running state to obtain the verification result in the shadow session, and to determine whether the device has entered the target running state. If the device enters the target running state, the parameters of the shadow session are overwritten to the actual running session, the candidate scanning protocol is accepted and scanned. If the device does not enter the target running state, the shadow session is rolled back and the next protocol reconstruction is performed.

[0010] In one embodiment, before obtaining the preset protocol construction sequence and the pointer of the protocol reconstruction cursor, the process includes: Acquire macroscopic positioning images of the target slide, identify the slide location, tissue region, and label region, and determine the slice type based on the macroscopic positioning images; Move the label area to the barcode imaging field of view, acquire the barcode label image, generate barcode candidate regions based on the barcode label image, and perform cascade recognition on the barcode candidate regions to obtain the barcode pathology number.

[0011] In addition, to achieve the above objectives, this application also provides a pathological slide scanning device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the control method for the pathological slide scanning device described above.

[0012] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the control method for the pathological slide scanning device described above.

[0013] This application provides a control method for a pathological slide scanning device. The method involves acquiring a preset protocol construction sequence and a protocol reconstruction cursor, where the cursor is the index of the current attempt position within the protocol construction sequence. Based on the cursor's position, the method determines the evidence type and matches its protocol template. Evidence types include barcode pathology number, slide type, and default protocol. When a protocol template is not matched or the current evidence value is empty, protocol reconstruction is performed. The cursor is then pointed to the next evidence type, and the evidence type is re-determined based on the cursor's position, matching its protocol template again. Finally, the protocol template is instantiated as a candidate scanning protocol. By constructing protocol templates based on multiple evidence types and instantiating them as candidate scanning protocols, the internal consistency of the parameter set in the candidate scanning protocols is ensured. This allows the instantiated candidate scanning protocols to be written into the device as a whole, thus improving the quality of pathological slide scanning. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating the control method for the pathological slide scanning equipment of this application is provided in Embodiment 1. Figure 2 A flowchart illustrating the control method for the pathological slide scanning equipment of this application, provided in Embodiment 2. Figure 3 A flowchart illustrating the control method for the pathological slide scanning device of this application, provided in Embodiment Seven; Figure 4 A simplified flowchart illustrating the control method for the pathological slide scanning device provided in this application embodiment; Figure 5 This is a schematic diagram of the pathological slide scanning device in the embodiments of this application.

[0017] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0018] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0019] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments.

[0020] Currently, automated pathology slide scanning equipment requires full-field image acquisition of the slides. Before the slides are actually scanned, macroscopic positioning images and barcode images are typically acquired to identify the pathology number or sample identifier of the slide, determine the slide type, and then determine scanning parameters such as objective magnification and scanning mode. Traditional technical solutions, after determining the scanning parameters, treat them as several independent fields, modifying only individual scanning parameters, such as magnification, without organizing all scanning parameters into a complete scanning protocol. This leads to inconsistencies between the backend hardware and software operation, resulting in asynchronous execution results and consequently, a decline in scan quality.

[0021] The main solution of this application is as follows: A preset protocol construction sequence and the pointer of the protocol reconstruction cursor are obtained, with the protocol reconstruction cursor serving as the index of the current attempt position in the protocol construction sequence. Based on the pointer of the protocol reconstruction cursor, the evidence type is determined, and a protocol template for that evidence type is matched. Evidence types include barcode pathology number, slide type, and default protocol. Specifically, when the pointer of the protocol reconstruction cursor is a barcode pathology number, the barcode mapping protocol template set is traversed, and a matching protocol template is selected based on the starting position, matching length, and prefix conditions. When the pointer of the protocol reconstruction cursor is a slide type, the type mapping protocol template set is traversed, and a matching protocol template is selected based on the slide type and target type label. When the pointer of the protocol reconstruction cursor is a default protocol, a preset default protocol template is selected. When no protocol template is matched or the current evidence value is empty, protocol reconstruction is performed, the protocol reconstruction cursor is pointed to the next evidence type, and the evidence type is re-determined based on the pointer of the protocol reconstruction cursor, matching the protocol template for that evidence type. The protocol template is then instantiated as a candidate scanning protocol. By constructing protocol templates in an orderly manner based on multiple evidence types and instantiating them into candidate scanning protocols, the internal consistency of the parameter set in the candidate scanning protocols is ensured. The instantiated candidate scanning protocols can be written into the device as a whole, which has the technical effect of improving the scanning quality of pathological slides.

[0022] It should be noted that the executing entity in this embodiment can be a pathological slide scanning device, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a pathological slide scanning device capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses a pathological slide scanning device as the executing entity to describe this embodiment and the following embodiments.

[0023] Based on this, Embodiment 1 of this application proposes a control method for a pathological slide scanning device. Please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the control method for the pathological slide scanning device of this application. The control method for the pathological slide scanning device includes steps S10 to S40: Step S10: Obtain the preset protocol construction sequence and the pointer of the protocol reconstruction cursor. The protocol reconstruction cursor is the index of the current attempt position in the protocol construction sequence.

[0024] In this embodiment, the protocol construction sequence is a predefined sequential sequence in the device configuration, denoted as Q=[q1,q2,...,qn], indicating the order in which the system attempts to construct candidate scanning protocols in the protocol generation loop, where q1, q2, and qn represent different evidence types. The protocol reconstruction cursor is a dynamic pointer or index used during the protocol construction process, denoted as K_rebuild, which refers to the index of the current attempt position in the protocol construction sequence Q. The protocol reconstruction cursor initially points to q1, which is the first element of the protocol construction sequence.

[0025] As an optional implementation, the elements of the protocol construction sequence are taken from the arrangement of the barcode pathology number, slide type, and default protocol.

[0026] Specifically, the system reads the preset protocol construction sequence of the current device, such as from a configuration file or database. The elements of the protocol construction sequence Q are the barcode pathology number, slide type, and default protocol, i.e., q1 is the barcode pathology number, q2 is the slide type, and q3 is the default protocol. The initial pointer of the protocol reconstruction cursor is q1, i.e., the barcode pathology number. The preset evidence attempt order ensures the orderliness and completeness of the protocol construction process.

[0027] As an alternative implementation, the protocol construction sequence includes fields related to device capabilities and scenario requirements, and the protocol construction sequence supports expansion.

[0028] Specifically, the elements in the protocol construction sequence Q can include not only barcode pathology number, slide type, and default protocol, but can also be expanded according to device capabilities and scenario requirements. For example, the protocol construction sequence includes, but is not limited to, experimental project type, department code, reagent batch, historical case template, operator identity, or results returned by the higher-level information system. By supporting the expansion of the protocol construction sequence, evidence from multiple dimensions and sources, such as information systems, environment, and operators, can be integrated and utilized in an orderly manner, improving the adaptability and intelligence level in different application environments.

[0029] Step S20: Determine the evidence type based on the pointer of the protocol reconstruction cursor, and match the protocol template of the evidence type. The evidence type includes barcode pathology number, slide type, and default protocol. Specifically, when the pointer of the protocol reconstruction cursor is a barcode pathology number, traverse the barcode mapping protocol template set and select the matching protocol template based on the starting position, matching length, and prefix conditions. When the pointer of the protocol reconstruction cursor is a slide type, traverse the type mapping protocol template set and select the matching protocol template based on the slide type and target type label. When the pointer of the protocol reconstruction cursor is a default protocol, select the preset default protocol template.

[0030] In this embodiment, the evidence type refers to the category of input information used to determine and construct the scanning protocol. A protocol template is a predefined, parameterized scanning protocol framework or set of rules, denoted as T. Each protocol template includes at least one or more of the following: evidence matching conditions, objective magnification, scanning mode, number of layers, interlayer spacing, image mode, focus point density, naming rules, image quality, output format, save path, and file sorting method.

[0031] The pathology barcode number refers to the pathology number string or equivalent barcode content identified from the barcode label image or its candidate area, denoted as E_bar. It is typically a serial number or barcode containing patient pathology examination information. For example, in 20230815-BX-LUNG-001, 20230815 indicates the examination date is August 15, 2023; BX (Biopsy, biopsy) indicates the type of examination is biopsy; LUNG indicates the tissue source is lung; and 001 indicates the serial number, i.e., the first case of the day. Different hospitals may use different encoding methods; common rules also include hospital codes and department codes. The barcode mapping protocol template set refers to the set of templates pre-stored in the device and associated with barcode rules, denoted as T_bar(j). The starting position refers to the starting index of the key substring used for matching in the complete barcode string. For example, a starting position of 0 indicates that the matching starts from the first character of the barcode. The matching length refers to the number of characters that need to be extracted for matching starting from the starting position. Prefix conditions refer to the prerequisite character conditions that a barcode string must meet before attempting a match; these usually refer to the fixed prefix portion of the barcode.

[0032] Slice type refers to the category label or equivalent type identifier of the slice identified from the macroscopic positioning image, denoted as E_type, such as HE staining (hematoxylin-eosin), immunohistochemical slice, fluorescent slice, etc. Type mapping protocol template set refers to the set of templates pre-stored in the device and associated with slice type rules, denoted as T_type(k). Target type label refers to the type label in the type mapping protocol template.

[0033] As an optional implementation, when the protocol reconstruction cursor points to a barcode pathology number, the barcode mapping protocol template set is traversed. Let the j-th barcode mapping protocol template T_bar(j) contain the starting position s_j, matching length l_j, and prefix condition p_j. When Len(E_bar) >= s_j + l_j - 1 and Sub(E_bar, s_j, l_j) satisfies the preset prefix condition p_j, the hit state H_bar(j) = 1; otherwise, H_bar(j) = 0. This ensures the accuracy, consistency, and configurability of the protocol matching process. When the slice type E_type matches the target type label, the hit state H_type(k) is 1; otherwise, H_type(k) is 0. When barcode pathology number evidence is missing or invalid, image analysis identifies the slice type and matches the corresponding scanning protocol, ensuring the continuity of the scanning process. When the protocol reconstruction cursor points to the default protocol, the preset default protocol template is selected. For example, the elements of the protocol construction sequence Q are the barcode pathology number, slide type, and default protocol. If protocol construction based on the barcode pathology number and slide type fails, the protocol reconstruction cursor moves to the last element, pointing to the default protocol. Without relying on external evidence, it directly calls the preset default protocol template as the current hit template. By setting the default protocol, an executable scanning protocol is ensured, maintaining the automation and continuity of the scanning process.

[0034] Specifically, according to the barcode pathology number matching protocol template, Len(E_bar)>=s_j+l_j-1 is the length check condition, ensuring that the currently identified barcode pathology number E_bar has sufficient length to safely extract a substring of length l_j starting from s_j, preventing access to non-existent positions. For example, if s_j=0 and l_j=8, meaning extracting characters of length 8 starting from the first character, then the length of E_bar must be at least 7 characters. If E_bar only has 6 characters, this condition is not met, and it is directly judged as a miss. Sub(E_bar,s_j,l_j) satisfies the preset prefix condition p_j, which is the substring matching condition. It ensures that the specified substring is extracted under the premise that the length is satisfied, and judges whether the substring conforms to the template's preset rule p_j. Sub(E_bar,s_j,l_j) means extracting a string fragment of length l_j starting from the s_j position of E_bar. For example, if E_bar="20230815-BX-LUNG-001", s_j=0, and l_j=8, then the substring is 20230815. Determine if the string fragment satisfies the prefix condition p_j. For example, if p_j="20*", the substring must start with "20". The j-th barcode mapping protocol template T_bar(j) is considered a match if and only if both conditions are met, i.e., H_bar(j)=1. If either condition is not met—either the barcode length is insufficient or the extracted substring does not meet the prefix condition—H_bar(j)=0, indicating that the template was not matched. Custom configuration allows for flexible mapping of barcode pathology numbers with different encoding rules to different scanning protocol templates.

[0035] Furthermore, in barcode pathology number matching scanning protocols, fields related to scan control within the barcode pathology number are typically matched. For example, in 20230815-BX-LUNG-001, 20230815 represents the testing date, and 001 represents the serial number, a management field. The testing date is usually only suitable for saving paths, archive directories, file naming, or sorting. The serial number is typically the daily serial number or case number, suitable only for naming, sorting, and tracing. BX represents the project type, indicating the type of examination, slide preparation, staining, and scanning-related items, such as biopsy, cytology, frozen section, immunohistochemistry, and fluorescence in situ hybridization, which are related to scanning parameters. For example, certain types of specimens may require higher magnification, higher focus density, whether to perform a layer scan, or a specific output format. LUNG, indicating the tissue origin, is generally not used to determine scanning parameters. However, if the hospital or equipment configuration has validated protocol sets for lung biopsy, lung fluorescence, etc., it can be combined with fields like BX as evidence for protocol construction. Barcode pathology numbers typically follow a pattern, such as 20230815-BX-LUNG-001, sorted by testing date, item type, tissue origin, and serial number. Matching is usually based on scan control-related fields within the barcode pathology number, such as specimen type, examination type, staining type, scan item, and explicit scan configuration code. This determines the starting position, match length, and prefix conditions, thereby identifying the appropriate barcode mapping protocol template. By matching scan control-related fields, the resulting scan parameters are more suitable for the current pathology type.

[0036] As another optional implementation, suffix matching, regular expression matching, check digit matching, segment combination matching, or dictionary mapping can be used to match the barcode mapping protocol template.

[0037] Specifically, suffix matching is used to match the end of the barcode string. For example, a template must end with "X" to be matched. Regular expression matching uses regular expressions to define matching rules. For example, the matching rule p_j for the barcode mapping protocol template T_bar(j) can directly store a regular expression for judgment. Checksum matching verifies the correctness of the checksum calculated by a specific algorithm during matching. For example, the matching rule p_j for the barcode mapping protocol template T_bar(j) includes a checksum flag and a checksum algorithm identifier. Segment combination matching treats the barcode as a concatenation of multiple meaningful fields, and multiple field conditions must be met simultaneously during matching. For example, it requires that the 1st-3rd digits are the department code ABC, the 4th-9th digits are numbers, and the 10th-11th digits are the year code 26. The corresponding protocol template is determined if and only if all segment conditions are met. Dictionary mapping matching performs an exact lookup in a dictionary using the extracted barcode substring and a predefined key. For example, the substring "BX" can be used directly as the key to find its corresponding specific protocol template. By employing richer matching methods, the automation level and applicability of the entire protocol construction process have been improved.

[0038] Step S30: When no protocol template is matched or the current evidence value is empty, protocol reconstruction is performed. The protocol reconstruction cursor is pointed to the next evidence type, and the evidence type is re-determined based on the direction of the protocol reconstruction cursor, and the protocol template of the evidence type is matched.

[0039] As an optional implementation, after obtaining a valid value for the current evidence type, if no matching condition for any template is met during the traversal of the corresponding protocol template set, i.e., a protocol template is not matched. For example, if an attempt is made to scan a barcode but no barcode is found or can be recognized in the image, or an attempt is made to analyze a slice type but macroscopic image analysis fails and no classification result is given, the current evidence value is empty. When either the protocol template is not matched or the current evidence value is empty, the evidence type is marked as having failed to build a protocol, i.e., the attempt to build a protocol based on the evidence type pointed to by the current cursor has failed. After marking, protocol reconstruction is performed. The protocol reconstruction cursor K_rebuild is moved to the next evidence type in the protocol construction sequence Q, and an attempt is made to re-match based on the new evidence to find a valid scanning protocol that can enable the device to enter the target operating state, thus improving the fault tolerance rate in the protocol construction process.

[0040] Step S40: Instantiate the protocol template as a candidate scanning protocol.

[0041] In this embodiment, the candidate scanning protocol refers to a unified parameter object, denoted as P_cand, which is obtained by instantiating a certain hit protocol template and can directly drive the formal scan. P_cand includes at least the target objective magnification, scanning mode, number of layers, interlayer spacing, image mode, focus point density, image quality parameters, output format, compression linkage parameters, save path, naming rules, and file sorting method.

[0042] As an optional implementation, the parameters in the protocol template are written into the candidate scanning protocol.

[0043] Specifically, when a protocol template is hit, a boolean result indicating a successful hit is returned, and the complete configuration carried in the protocol template is instantiated as a candidate scanning protocol. A blank candidate scanning protocol with a complete data structure is initialized. The hit protocol template is read, and each parameter definition in the template is traversed and written into the corresponding field in the blank candidate scanning protocol, resulting in the instantiated candidate scanning protocol. Through structured writing, accurate conversion from a reusable general template to scan instructions customized for the current slide task and ready for immediate execution is achieved.

[0044] This embodiment provides a control method for a pathological slide scanning device. First, it acquires a preset protocol construction sequence and a protocol reconstruction cursor, where the cursor is the index of the current attempt position in the protocol construction sequence. Based on the cursor's position, it determines the evidence type and matches a protocol template for that evidence type. Evidence types include barcode pathology number, slide type, and default protocol. When a protocol template is not matched or the current evidence value is empty, protocol reconstruction is performed, the cursor is moved to the next evidence type, and the evidence type is re-determined based on the cursor's position, matching a new protocol template. The protocol template is then instantiated as a candidate scanning protocol. By constructing protocol templates based on multiple evidence types in an orderly manner and instantiating them as candidate scanning protocols, the internal consistency of the parameter set in the candidate scanning protocols is ensured. This allows the instantiated candidate scanning protocols to be written into the device as a whole, effectively improving the quality of pathological slide scanning.

[0045] Based on Embodiment 1, in Embodiment 2 of this application, the content that is the same as or similar to that in Embodiment 1 can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating a second embodiment of the control method for the pathological slide scanning device of this application. After instantiating the protocol template as a candidate scanning protocol, accepting the candidate scanning protocol, and performing a scan, the process includes: Step S41: Generate the full vector of the target device's running state based on the candidate scanning protocol.

[0046] In this embodiment, the target device running state full vector refers to the set of all target states that the device should reach before allowing formal scanning, denoted as S_tar. Preferably, S_tar includes at least the objective lens state, the coordinate mapping state corresponding to the objective lens magnification, the scanning mode state, the layer scan state, the image acquisition state, the file writing state, and the path naming state.

[0047] As one implementation method, the complete operating state that the device should ideally achieve when executing the candidate scanning protocol is pre-calculated, resulting in a target device operating state full vector. This target device operating state full vector encompasses the theoretical parameter values ​​of all relevant device operating units, such as the stage, objective lens, camera, and light source. Specifically, it involves traversing each parameter in P_cand and calculating or searching for the corresponding target state value. These state values ​​constitute the various fields of the target device operating state full vector S_tar. For example, if the objective lens magnification in the candidate scanning protocol is 20x, the corresponding objective lens magnification field in the target device operating state full vector is a verifiable state value, such as the encoded value 1024 for a 20x objective lens. By organizing potentially independent parameter fields into a cohesive protocol whole, a clear and quantifiable target benchmark is created for subsequent device state verification.

[0048] Step S42: Write the candidate scanning protocol into each device operation unit.

[0049] In this embodiment, each device operation unit refers to a functional subsystem driven by candidate scanning protocol parameters that can provide measurable status feedback after execution. For example, the device operation units corresponding to objective magnification, the coordinate mapping of objective magnification, scanning mode, number of layers, interlayer spacing, image mode, focus point density, image quality, output format, save path, and naming rules in the candidate scanning protocol, namely, objective control unit, stage control unit, etc.

[0050] As one implementation method, different categories of parameter commands in the candidate scanning protocol are distributed and configured to the corresponding device operating units, i.e., physical hardware modules or software control modules. For example, magnification parameters are written to the objective lens controller, scanning path parameters are written to the stage driver, and exposure parameters are written to the camera controller. By converting the abstract protocol parameters into actual configuration commands for each device unit, the actual operating status of the device unit can be obtained.

[0051] Specifically, based on the target objective magnification in the candidate scanning protocol P_cand, the user layer magnification label is mapped to the actual objective number or physical objective position of the device, and the objective is switched or the current objective working status is updated. Preferably, after the objective is switched, the coordinate mapping relationship and scanning field of view conversion relationship corresponding to the magnification are refreshed synchronously. Based on the scanning mode, number of layers, and interlayer spacing in P_cand, the scanning session parameters, Z-axis stepping parameters, and related session variables of the formal scanning stage are refreshed. Preferably, the interlayer spacing is converted into units or scaled by stepping according to the device calibration coefficient before being issued. Based on the image mode, focus point density, and image quality parameters in P_cand, the camera gain, exposure, white balance, gamma value, focus evaluation parameters, or equivalent image acquisition parameters used in the formal scanning are updated. Based on the output format in P_cand, the write-side running state is set in conjunction with the output format settings. Preferably, when the output format is SDPC (Slide Digital Pathology Container), DICOM (Digital Imaging and Communications in Medicine), or compressed DICOM (DICOM with... When writing any of the following formats: DICOM (compression format), SVS (Aperio ScanScope VirtualSlide), or TIFF (Tagged Image File Format), in addition to writing the target format identifier, the corresponding compression switch, format-specific auxiliary parameters, writer type, and output session configuration are updated synchronously. Taking DICOM compression as an example, its corresponding compression flag is enabled simultaneously, rather than just modifying the extension. Based on the save path, naming rules, and file sorting method in P_cand, the file write directory, case naming rules, sorting strategy, and output session identifier are updated to complete the write chain linkage.

[0052] Preferably, the runtime fields related to the candidate scanning protocol P_cand are written as a whole, rather than only partially modifying a single failed field. If the previous round of candidate scanning protocols has affected some runtime fields, the current round of candidate scanning protocols will either overwrite the relevant fields again or restore the system to a neutral session state before writing the entire protocol, in order to avoid residual states of the old protocol affecting the verification results of the next round.

[0053] Step S43: Collect the full vector of the actual device operating state from each device operating unit, and verify it field by field with the full vector of the target device operating state to determine whether the device has entered the target operating state.

[0054] In this embodiment, the actual device operating state full vector refers to the complete set of operating states actually obtained from the objective lens switching mechanism, the coordinate mapping session corresponding to the magnification, the scanning session, the image acquisition session, and the writing session after the candidate scanning protocol is written to the device, denoted as S_act. The target operating state refers to the ideal working state that all relevant operating units of the device should theoretically achieve, as defined by the candidate scanning protocol. Preferably, the actual device operating state full vector S_act includes at least one of the following components: the actual objective lens position or actual magnification state, the coordinate mapping or field of view conversion state corresponding to the objective lens magnification, the scanning mode and layer scanning parameter state, the image acquisition parameter state, the output format and auxiliary compression parameter state, the save path and naming rule parsing state, and the key parameter state of the formal scanning session. The representation of the target device operating state full vector S_tar and the actual device operating state full vector S_act is not limited to state vectors; it can also use itemized state codes, score values, or equivalent structured state sets.

[0055] As one implementation method, after the candidate scanning protocol is written, the current actual operating parameters of each device operating unit are read back in real time. This includes reading the actual effective status from the objective lens switching mechanism, the coordinate mapping session corresponding to the magnification, the scanning session, the image acquisition session, and the file writing session. These read-back values ​​are then aggregated to form a full vector of the actual device operating state. The full vector of the actual device operating state, S_act, is compared field-by-field with the full vector of the target device operating state, S_tar, to determine the verification result and whether the device has entered the target operating state. By determining the consistency of the full status fields of the candidate scanning protocol, the consistency of the hardware and software operating states is ensured.

[0056] Specifically, the set of all runtime fields carried in the candidate scanning protocol P_cand is denoted as F(P_cand), and preferably includes at least the objective magnification field, coordinate mapping field, scanning mode field, layer scan field, image acquisition field, output format and compression linkage field, save path field, and naming rule field. The device status consistency verification result is denoted as V_cons, which can be defined as: V_cons = AND_{f in F(P_cand)} Eq(S_act(f), S_tar(f)) Here, AND_{f in F(P_cand)} represents a logical AND operation on all fields, F(P_cand) represents the set of all fields that need to be verified as defined by the candidate scan protocol P_cand, f is each field in the set, and AND means that the final result is true only if the verification of all fields in the set passes. Eq represents the consistency judgment function for the corresponding state field, Eq(S_act(f), S_tar(f)) determines whether a specific field in the full vector of the actual device running state S_act is consistent with the full vector of the target device running state S_tar. V_cons=1 is set if and only if all running state fields involved in P_cand are consistent, that is, the device enters the target running state; if any field is inconsistent, V_cons=0 is set, that is, the device has not entered the target running state. By determining the consistency of the full state fields based on the candidate scan protocol, the consistency of the hardware and software running states is ensured.

[0057] Preferably, the types of inconsistencies are recorded. Inconsistencies may include at least objective lens switching failure, coordinate mapping not refreshed, layer number or interlayer spacing not updated, image acquisition parameters not refreshed, output format and compression flag inconsistent, save path cannot be parsed, naming rules not loaded, or session key parameters not synchronized. Through a full-state consistency determination mechanism, it is ensured that formal scanning is only allowed to start when the overall device operating state has closed and converged.

[0058] Step S44: If the device enters the target operating state, it accepts the candidate scanning protocol and performs a scan.

[0059] As one implementation method, when all runtime fields involved in P_cand are consistent, and V_cons=1, indicating that the device has entered the target runtime state, it accepts candidate scanning protocols, records the evidence type used, the matched protocol template identifier, the evidence value summary, and the protocol key parameter summary. If there is a previous protocol reconstruction trajectory, it is also recorded, and the candidate scanning protocol is used as the currently effective protocol for the formal scanning phase. Formal scanning is initiated, ensuring that motion control, focus control, image acquisition, and file writing links all operate according to the parameters of the candidate scanning protocol. Scanning is performed only after verifying that the device runtime state is completely consistent with the protocol requirements, ensuring that the scanning action is performed in an ideal state of device coordination, thereby preventing a decrease in scanning quality due to inconsistent runtime states.

[0060] Preferably, before starting the formal scan, the macroscopic positioning image, barcode label image, final hit source, previous verification failure items and protocol reconstruction trajectory can also be written into the log or case session data to support subsequent tracing.

[0061] In this embodiment, by instantiating the protocol template into a candidate scanning protocol, generating the full target device runtime vector and performing a field-by-field closed-loop verification after writing, the device is ensured to fully enter the target runtime state before scanning is started. This avoids parameter inconsistencies, delivery failures, or semi-configured states from the root, thereby improving the reliability and accuracy of automatic scanning.

[0062] Based on any of the above embodiments of this application, Embodiment 3 of this application proposes a control method for a pathological slide scanning device, which can be referred to the above description and will not be repeated hereafter. Based on this, the actual device operating state full vector is collected from each device operating unit, and then compared with the target device operating state full vector field by field to determine whether the device has entered the target operating state. This includes: Step S45: If the device does not enter the target operating state, perform protocol reconfiguration.

[0063] In this embodiment, protocol reconfiguration is a control process that is automatically triggered when the device has not entered the target operating state.

[0064] As one implementation method, if any field in the actual device runtime full vector S_act and the target device runtime full vector S_tar is inconsistent (V_cons=0), indicating that the device has not entered the target runtime state, protocol reconstruction is performed. The protocol reconstruction cursor K_rebuild is moved to the next evidence type in the protocol construction sequence Q, and an attempt is made to re-match based on this new evidence to find a valid scanning protocol that can enable the device to enter the target runtime state. By automatically and orderly attempting to reconstruct the protocol when the device runtime verification fails, robustness and success rate of scanning tasks are improved in the face of abnormal situations such as unrecognizable barcodes and conflicting parameter settings, avoiding direct interruption of the scanning process due to a single point of failure.

[0065] Based on any of the above embodiments of this application, Embodiment 4 of this application proposes a control method for a pathological slide scanning device, which can be referred to the above description and will not be repeated hereafter. On this basis, the protocol template is instantiated into a candidate scanning protocol, including: Step S46: If the candidate scanning protocol obtained by instantiating the protocol template has missing fields, the protocol is completed according to the priority of the scenario basic protocol field, the device default protocol field, and the security fallback field.

[0066] In this embodiment, the scenario-based protocol field refers to a set of default parameters related to the business scenario or sample category of the current scanning task. For example, the scenario-based protocol field includes the biopsy basic protocol, which is the preset parameters for all tissue biopsy samples, such as scan mode = "regional scan" and focus point density = "standard"; the cytology basic protocol is the preset parameters for liquid-based cytology specimens, such as scan mode = "single-layer full field" and objective magnification = "40x"; the default bright field protocol is the preset universal optical parameters for all bright field staining (HE, special staining), such as light source intensity = 80%. The device default protocol field refers to the default parameters that are universal across the entire device and stored in the device firmware or global configuration file. For example, output format = "SDPC", compression linkage parameter = "SVS", and save path = "Data / Scans". The safety fallback field refers to a set of parameters that have been rigorously verified to ensure that the device can safely perform the most basic scanning functions. For example, objective magnification = "5x", which is the lowest magnification, the largest field of view, and the highest focus tolerance; scanning mode = "single point preview", which is the simplest scanning action and the least resource consumption.

[0067] As one implementation method, the protocol template can be a complete template, a difference template, or an index template, but the candidate scan protocol P_cand must be a complete protocol. For example, if a protocol template only has "matching conditions + objective magnification", the instantiated candidate scan protocol is not a complete protocol, i.e., there are missing fields, and protocol completion should be performed. The candidate scan protocol P_cand = explicit fields in the hit template + scene basic protocol fields + device default protocol fields + safety fallback fields, where the fields explicitly given in the hit protocol template take priority, and fields not given are inherited from the corresponding scene basic template, such as biopsy basic protocol, cytology basic protocol, default bright field protocol, and fields that are still missing are filled in from the device calibration default value or safety default value. If a required field cannot be filled in, a valid P_cand is not generated, and the next round of protocol reconstruction or blocking scan is entered. By automatically generating a complete, safe, and executable candidate scan protocol through protocol completion, the robustness, adaptability, and security of the entire protocol construction process are enhanced.

[0068] Based on any of the above embodiments of this application, Embodiment 5 of this application proposes a control method for a pathological slide scanning device, which can be referred to the above description and will not be repeated hereafter. On this basis, protocol reconstruction is performed, including: Step S200: Determine whether there is a next evidence type in the protocol construction sequence. If there is, generate a candidate scanning protocol and the full vector of the target device's running state based on the next evidence type. If there is no next evidence type, enter the blocking state.

[0069] As one implementation method, a protocol reconstruction operation is performed. The protocol reconstruction cursor K_rebuild increments and moves to the next evidence type, determining whether a next evidence type exists in the protocol construction sequence Q. For example, in the protocol construction sequence Q=[q1,q2,q3], if protocol construction based on q1 fails, there is a next evidence type q2. Therefore, a protocol reconstruction operation is performed based on q2, matching the protocol template of this evidence type and instantiating the template as a candidate scanning protocol, thereby generating the full vector of the target device's running state. If no next evidence type exists, it means that all evidence types have been attempted and no verified executable scanning protocol has been generated. At this point, a blocking state is entered, and protocol construction or state verification failure is output as an explicit exception type. Formal scanning is no longer allowed, a failure log is output, evidence images are retained, and manual processing or subsequent maintenance is awaited. By orderly judging and attempting the next evidence type and blocking when all sources are exhausted, the protocol construction process is ensured to automatically try other schemes to maintain continuity when it fails, and to stop in time when all schemes are invalid. This ensures the robustness of the process while avoiding sample damage and resource waste that may be caused by the device forcibly scanning under invalid or erroneous protocols.

[0070] Based on any of the above embodiments of this application, Embodiment Six of this application proposes a control method for a pathological slide scanning device, which can be referred to the above description and will not be repeated hereafter. Based on this, a candidate scanning protocol and a target device runtime full vector are generated based on the next evidence type, including: Step S201: Construct an empty shadow session. The shadow session has the same parameter structure as the actual running session.

[0071] In this embodiment, the shadow session is a temporary session copy used for security testing during the protocol reconstruction process. It can perform verification without affecting the current device state, ensuring the security of the protocol reconstruction process and avoiding the risk of device malfunction or scan failure due to the direct application of unverified protocols.

[0072] As one implementation method, when protocol reconstruction based on the next evidence type is required, a new, independent session object, known as a shadow session, is created in memory. The data structure and parameter field definitions of the shadow session are completely identical to the actual running session currently controlling the device, but all its parameter values ​​are initially empty or at default values, and it does not drive any actual actions. By creating a session isolated from the real environment, a container is provided for testing new protocols for security purposes.

[0073] Step S202: Generate candidate scanning protocols and target device runtime full vector based on the next evidence type, write the candidate scanning protocols into the shadow session, and obtain the actual device runtime full vector based on the parameters of the shadow session.

[0074] As one implementation method, a new candidate scanning protocol is instantiated based on the next evidence type and a new matching protocol template is used to generate the corresponding target device runtime full vector. The new candidate scanning protocol is then configured as a whole into a shadow session, becoming the current parameter set of the shadow session. Based on the parameters of the shadow session, calculations or simulations are performed to derive the theoretical operating states of each unit of the device when the candidate scanning protocol is actually executed, which serves as the actual device runtime full vector. By fully simulating the deployment of the new protocol in the shadow session and predicting the device state after its execution, simulated real-world data is provided for subsequent verification.

[0075] Step S203: Perform field-by-field verification between the actual device running state full vector and the target device running state full vector to obtain the verification result in the shadow session and determine whether the device has entered the target running state.

[0076] As one implementation method, the full vector of the actual device operating state obtained based on the shadow session parameters is compared and verified field by field with the full vector of the target device operating state generated by the new candidate scanning protocol. Based on the verification results in the shadow session, it is determined whether the device has entered the target operating state. By determining the current state of the device, a basis is provided for subsequent device startup or continued protocol reconstruction.

[0077] Step S204: If the device enters the target running state, the parameters of the shadow session are overwritten to the actual running session, the candidate scanning protocol is accepted and scanning is performed. If the device does not enter the target running state, the shadow session is rolled back and the next protocol reconstruction is performed.

[0078] As one implementation method, if the verification passes, the device enters the target operating state. At this point, all parameters from the shadow session completely overwrite the parameters of the current actual operating session. Based on the updated and verified actual operating session, candidate scanning protocols are accepted and scanned. If the verification fails, the device does not enter the target operating state. In this case, the shadow session is rolled back, i.e., the temporary session is directly discarded or reset, and the next protocol reconstruction is performed. By performing rigorous verification within the shadow session, the reliability and security of protocol switching are ensured, avoiding the risk of device malfunction, scan failure, or sample corruption that may result from directly applying unverified protocols.

[0079] Preferably, the reason for each protocol reconstruction failure is recorded. The reasons for failure may include barcode recognition failure, barcode mapping protocol template mismatch, slice type recognition failure, type mapping protocol template mismatch, missing default protocol template, objective lens switching failure, coordinate mapping not refreshed, layer scan parameters inconsistent, format auxiliary parameters not synchronized, save path parsing failure, or protocol application inconsistency.

[0080] As one implementation method, shadow sessions are not used. Before entering the next round of protocol reconstruction, the associated states of the previous round of candidate scanning protocols in the scanning session, such as magnification, coordinate mapping, layer scanning, image acquisition, output format, and writing target, are cleared or overwritten. Alternatively, the next round of candidate scanning protocols can be constructed in a temporary session or an equivalent transactional parameter area. Only when the device enters the target running state is it submitted as a formally effective protocol. By directly operating the actual session under controlled conditions or using a transaction area that can be committed or rolled back, efficient execution and secure state management of the protocol reconstruction process are achieved.

[0081] Specifically, the process involves clearing or overwriting associated states. When protocol reconstruction based on the next evidence type is required, all parameters related to the previous failed protocol in the actual running session are first reset. Based on the next evidence type, a new candidate scanning protocol and the target device's full runtime vector are directly generated. The new candidate scanning protocol is then written into the cleared actual running session. The device is driven directly based on the actual running session, and the full runtime vector of the actual device is collected and verified against the target vector. If the device enters the target runtime state, it accepts the candidate scanning protocol and performs a scan; otherwise, the next protocol reconstruction is performed. The temporary transactional method maintains an independent temporary session or transactional parameter area. When protocol reconstruction is required, based on the next evidence type, a new candidate scanning protocol and the target device's full runtime vector are constructed in this temporary area, which is isolated from the actual running session. The device is driven based on the parameters in this temporary area, and the full runtime vector of the actual device is collected for verification. If the device enters the target operating state, the parameters in the temporary storage area are overwritten with the actual operating session. Candidate scan protocols are accepted and scanned. If the device does not enter the target operating state, a rollback operation is performed, discarding all parameters in the temporary storage area, and the next protocol reconstruction is initiated. By actively managing the state lifecycle of the actual operating session or introducing a temporary transaction storage area, the security of the protocol reconstruction process can be improved.

[0082] In this embodiment, lossless and secure protocol reconstruction is achieved by simulating and verifying the protocol in an isolated environment and then securely overwriting the actual running session after verification. This ensures that when dynamically switching scanning protocols, the device will not malfunction or fail to scan due to the direct application of unverified protocols, thereby improving system robustness while ensuring operational security.

[0083] Based on any of the above embodiments of this application, Embodiment Seven of this application proposes a control method for a pathological slide scanning device, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating a seventh embodiment of the control method for the pathological slide scanning device of this application. Before obtaining the preset protocol construction sequence and the pointer of the protocol reconstruction cursor, the process includes: Step S101: Acquire a macroscopic positioning image of the target slide, identify the slide location, tissue region, and label region, and obtain the slice type based on the macroscopic positioning image.

[0084] In this embodiment, the macroscopic positioning image refers to a low-magnification or macroscopic image used to identify the slide location, tissue region, and label region, denoted as I_loc. The slide location refers to the coordinate range or outline area of ​​the slide itself in the image. The tissue region refers to the area on the slide that carries the pathological tissue sample. The label region refers to the area on the slide where a printed label is affixed.

[0085] In one implementation, the positioning imaging unit of the scanning device uses a low-magnification objective lens to drive the stage for rapid stitching or direct wide-field imaging, acquiring a panoramic image covering the entire slide area, i.e., a macroscopic positioning image. A series of image analyses are performed on the acquired macroscopic positioning image. For example, edge detection algorithms are used to identify the slide's outline and separate it from the image background, determining the slide's precise boundaries in the coordinate system. Within the identified slide area, significant differences in color, texture, or transmittance between the tissue and the glass background are used to segment the tissue area through thresholding, region growing, or machine learning models. Based on prior knowledge combined with text detection or fixed template matching, the label area printed with text and barcodes is located. Through low-magnification macroscopic imaging and image analysis, global perception of the slide, key area localization, and slide type identification are achieved, providing data input for subsequent protocol matching based on slide type and accurate barcode acquisition.

[0086] Preferably, the slice type E_type can be obtained by traditional image processing, feature classification models, or equivalent slice category recognizers.

[0087] Specifically, traditional image processing methods extract predefined features, including color and texture features, from the tissue regions obtained from macroscopic localization images. For example, HE-stained sections typically exhibit alternating blue and red characteristics. Based on color features, color histograms, dominant colors, or statistics in different color spaces are calculated. Based on texture features, indices such as contrast, correlation, energy, and homogeneity of the gray-level co-occurrence matrix are calculated, or local binary patterns are used to describe the microscopic texture patterns of the tissue. The extracted data are integrated into feature vectors and input into a pre-trained classifier, which outputs a category label for the section type. In the feature classification model, a convolutional neural network is used to automatically learn the most discriminative features; that is, the model automatically learns the mapping relationship between the macroscopic localization image and the section category label during training. In the inference and recognition stage, the macroscopic localization image of the current slide is input into the trained model, which outputs a predicted probability distribution for the section type. The category with the highest probability is taken as the section type E_type. In equivalent slice category recognition, methods can include end-to-end deep learning models, an ensemble system, template matching, color and morphology feature classification, lightweight neural network classification, or manually entered labels. For example, one could first attempt to identify textual clues on the labels; if that fails, then use a deep learning model based on image features for judgment. This flexible selection of technical solutions allows for adaptation to different application scenarios.

[0088] Step S102: Move the label area to the barcode imaging field of view, acquire the barcode label image, generate barcode candidate areas based on the barcode label image, and perform cascade recognition on the barcode candidate areas to obtain the barcode pathology number.

[0089] In this embodiment, the barcode label image refers to the original barcode image captured after the device moves to the label area, denoted as I_bar. The barcode imaging field of view refers to the field of view of the camera module on the device used for high-resolution barcode capture. The barcode label image refers to a partial image of the label area captured within the barcode imaging field of view. The barcode candidate region refers to one or more image sub-regions in the barcode label image that may contain a barcode, initially selected through preliminary image processing algorithms.

[0090] As one implementation method, based on the calculated label area position, the motion mechanism is controlled to move the label area below the barcode imaging field of view for acquisition, obtaining a barcode label image. Based on the barcode label image, a barcode candidate area is generated. This candidate area is then subjected to multi-engine cascaded recognition to obtain the barcode pathology number. Simultaneously, the macroscopic positioning image and the barcode label image are saved, and the protocol session for this slide is initialized. This involves creating an independent context environment for managing the protocol construction and execution process for this scanning task. This includes reading a predefined protocol construction sequence and binding it to the session; creating a protocol reconstruction cursor variable within the session and initially setting its pointer to the first element of the aforementioned protocol construction sequence; creating storage spaces within the session for various evidence types, initially empty, awaiting subsequent acquisition and filling; and creating data structures within the session to store intermediate and final protocol products such as candidate scanning protocols and the target device's operational full vector, initially empty, etc. This is to facilitate the subsequent recording of the original evidence images and session information upon which protocol construction, status verification, and protocol reconstruction are based.

[0091] Preferably, orientation correction, mirror flipping, and region alignment are performed before and after acquiring the barcode label image to reduce the impact of label orientation changes, placement direction changes, or field of view shifts on barcode recognition.

[0092] Preferably, barcode candidate regions are generated by at least one of the following methods: estimating the approximate area of ​​the barcode, expanding the boundaries of the candidate region, performing compact cropping on the local region, performing adaptive binarization on the grayscale image, and retrying the binarization results under different thresholds.

[0093] Specifically, after obtaining the barcode label image, the approximate area of ​​the barcode is estimated. For example, if the printing position of the barcode on the label is relatively fixed, a region of interest is pre-defined based on prior knowledge. After initially locating the candidate barcode region, the boundary of this region is extended outward by several pixels to ensure the integrity of the barcode boundary and avoid the barcode edge being cut off due to minor deviations in the initial location, which would affect decoding. After boundary extension, the candidate region is compactly cropped. Through edge detection or contour analysis, the precise bounding rectangle of the barcode module is found, and excess blank space or background around the region is cropped. For grayscale candidate region images, an adaptive thresholding algorithm is used to convert them into black and white binary images. When using a certain threshold parameter for binarization, if decoding fails, the threshold is automatically adjusted, a new binary image is generated, and decoding is attempted again. Through one or more enhancement processing methods, the ability to stably and accurately extract barcode regions that can be successfully read by the decoder from complex label images is improved.

[0094] Preferably, multi-engine cascaded recognition is performed on the barcode candidate region to obtain the barcode pathology number E_bar. Specifically, the first recognition engine is called to expand the boundary of the entire image or candidate region, the second recognition engine is called to perform compact cropping on the expanded candidate region, the third recognition engine is called to perform adaptive binarization on the grayscale image of the compactly cropped barcode image, the barcode recognition engine is called to recognize the binarization result, the QR code or barcode recognition is repeatedly tried under different grayscale thresholds, and the matrix code recognition path is called when necessary to improve the success rate of obtaining the barcode pathology number E_bar.

[0095] In this embodiment, if the acquisition of the barcode pathology number E_bar and the slide type E_type fails, they are recorded as null or invalid values. The protocol generation process is not terminated directly, but instead handed over to the subsequent protocol construction and reconstruction mechanism. This involves continuing to determine the evidence type based on the cursor's pointing direction, matching the protocol template for the evidence type, and marking the evidence type as "protocol construction failed" when it is determined that the current evidence value is null, thus initiating protocol reconstruction. By acquiring the two key pieces of evidence—slide type and barcode pathology number—accurate input is provided for the subsequent multi-source evidence-driven, scanning protocol construction, and closed-loop verification process.

[0096] For example, to facilitate understanding of the technical concept or principle of the control method of the pathological slide scanning device in the above embodiments, please refer to... Figure 4 , Figure 4 A simplified flowchart illustrating the control method for the pathological slide scanning device provided in this application embodiment is shown below: An acceptable scanning protocol that meets the requirements is defined as follows: following the order of the protocol construction sequence Q, each evidence type i is tried in turn, and the first candidate scanning protocol P_cand(i) that can successfully match the protocol template and whose driven device can pass the runtime consistency check is selected as the final execution protocol.

[0097] The process begins by acquiring macroscopic positioning images of the slides and performing initialization work required for protocol construction, generating barcode pathology numbers and slide types. The evidence type is then determined based on the current cursor position according to the protocol. Candidate scanning protocols and the target device's operational full vector are constructed based on the current evidence type. If a protocol template is not matched or the current state value is empty, protocol reconstruction is performed. If a protocol template is matched and the evidence value is not empty, the matched protocol template is instantiated as a candidate scanning protocol. If the instantiated candidate scanning protocol is not complete, protocol completion is performed to obtain a complete candidate scanning protocol, which is then written to each device's operational unit. The actual device's operational full vector is then acquired and compared with the target device's operational full vector to determine if the device has entered the target operational state. If the verification passes (meaning the device state is completely consistent with the protocol requirements), the candidate scanning protocol is received and a formal scan is performed. If the verification fails (meaning the device is not correctly configured according to the protocol requirements), protocol reconstruction is performed. Upon entering the protocol reconstruction operation, the system first determines whether a next evidence type exists. If a next evidence source exists, the protocol reconstruction cursor is updated, and the verification loop is restarted based on the new evidence type. If no next evidence type exists, a failure record is output, and the formal scan is blocked, ensuring that erroneous scans are not performed when a valid protocol cannot be obtained. By constructing protocol templates in an orderly manner based on multiple evidence types, the internal consistency of the parameter set is ensured. Runtime consistency verification ensures that the backend hardware and software run in a consistent manner, avoiding the use of incorrect parameters for scanning due to inconsistencies in hardware and software states. This ultimately improves the technical quality of pathological slide scanning.

[0098] This application provides a pathological slide scanning device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the control method of the pathological slide scanning device in the first embodiment described above.

[0099] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a pathological slide scanning device suitable for implementing embodiments of this application. The pathological slide scanning device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The pathological slide scanning device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of this application.

[0100] like Figure 5As shown, the pathology slide scanning device may include a processing unit 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the pathology slide scanning device. The processing unit 1001, the read-only memory 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the pathology slide scanning equipment to communicate wirelessly or wiredly with other devices to exchange data. Although a pathology slide scanning equipment with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0101] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0102] The pathological slide scanning device provided in this application, employing the control method of the pathological slide scanning device in the above embodiments, can solve the technical problem of decreased scanning quality caused by independent scanning parameter fields. Compared with the prior art, the beneficial effects of the pathological slide scanning device provided in this application are the same as those of the pathological slide scanning device provided in the above embodiments, and other technical features of this pathological slide scanning device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0103] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0104] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0105] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the control method of the pathological slide scanning device in the above embodiments.

[0106] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0107] The aforementioned computer-readable storage medium may be included in the pathology slide scanning device or may exist independently without being assembled into the pathology slide scanning device.

[0108] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a pathology slide scanning device, the pathology slide scanning device: acquires a preset protocol construction sequence and the pointer of a protocol reconstruction cursor, where the protocol reconstruction cursor is the index of the current attempt position in the protocol construction sequence; determines the evidence type based on the pointer of the protocol reconstruction cursor, and matches the protocol template of the evidence type. The evidence type includes a barcode pathology number, slide type, and default protocol. Specifically, when the pointer of the protocol reconstruction cursor is a barcode pathology number, it iterates through the barcode mapping protocol template set and selects a matching protocol template based on the starting position, matching length, and prefix conditions. When the pointer of the protocol reconstruction cursor is a slide type, it iterates through the type mapping protocol template set and selects a matching protocol template based on the slide type and target type label. When the pointer of the protocol reconstruction cursor is a default protocol, it selects a preset default protocol template. When no protocol template is matched or the current evidence value is empty, it performs protocol reconstruction, points the protocol reconstruction cursor to the next evidence type, re-determines the evidence type based on the pointer of the protocol reconstruction cursor, and matches the protocol template of the evidence type. It then instantiates the protocol template as a candidate scanning protocol.

[0109] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0111] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0112] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the control method of the pathological slide scanning device described above, which can solve the technical problem that the scanning parameter fields independently cause a decrease in scanning quality. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the control method of the pathological slide scanning device provided in the above embodiments, and will not be repeated here.

[0113] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the control method for a pathological slide scanning device as described above.

[0114] The computer program product provided in this application can solve the technical problem that the independent scanning parameter fields lead to a decrease in scanning quality. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this application are the same as the beneficial effects of the control method of the pathological slide scanning equipment provided in the above embodiments, and will not be repeated here.

[0115] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A control method for a pathological slide scanning device, characterized in that, The control method for the pathological slide scanning device includes: Obtain a preset protocol construction sequence and the pointer of a protocol reconstruction cursor, wherein the protocol reconstruction cursor is the index of the current attempt position in the protocol construction sequence; Based on the pointer of the protocol reconstruction cursor, the evidence type is determined, and the protocol template of the evidence type is matched. The evidence type includes barcode pathology number, slide type, and default protocol. When the pointer of the protocol reconstruction cursor is the barcode pathology number, the barcode mapping protocol template set is traversed, and the matching protocol template is selected based on the starting position, matching length, and prefix conditions. When the pointer of the protocol reconstruction cursor is the slide type, the type mapping protocol template set is traversed, and the matching protocol template is selected based on the slide type and target type label. When the pointer of the protocol reconstruction cursor is the default protocol, a preset default protocol template is selected. When the protocol template is not matched or the current evidence value is empty, protocol reconstruction is performed. The protocol reconstruction cursor is pointed to the next evidence type, and the evidence type is re-determined based on the direction of the protocol reconstruction cursor, and the protocol template of the evidence type is matched. Instantiate the protocol template as a candidate scanning protocol.

2. The control method for the pathological slide scanning device as described in claim 1, characterized in that, After instantiating the protocol template into a candidate scanning protocol, the process includes: Generate the full vector of the target device's operating state based on the aforementioned candidate scanning protocol; The candidate scanning protocol is written into each device operation unit; The actual device operating state full vector is collected from each of the device operating units, and it is compared with the target device operating state full vector by field to determine whether the device has entered the target operating state. If the device enters the target operating state, it accepts the candidate scanning protocol and performs a scan.

3. The control method for the pathological slide scanning device as described in claim 2, characterized in that, The step of collecting the actual device operating state full vector from each of the device operating units, performing field-by-field verification with the target device operating state full vector to determine whether the device has entered the target operating state includes: If the device does not enter the target operating state, a protocol reconfiguration is performed.

4. The control method for the pathological slide scanning device as described in claim 1, characterized in that, Instantiating the protocol template into a candidate scanning protocol includes: If the candidate scanning protocol obtained by instantiating the protocol template has missing fields, the protocol is completed according to the priority of the scenario basic protocol field, the device default protocol field, and the security fallback field.

5. The control method for the pathological slide scanning device as described in claim 1 or 3, characterized in that, The protocol refactoring includes: Determine whether there is a next evidence type in the protocol construction sequence. If there is, generate the candidate scanning protocol and the full vector of the target device's running state based on the next evidence type. If there is no next evidence type, enter the blocking state.

6. The control method for the pathological slide scanning device as described in claim 5, characterized in that, The step of generating the candidate scanning protocol and the target device runtime full vector based on the next evidence type includes: Construct an empty shadow session, which has the same parameter structure as the actual running session; Based on the next evidence type, the candidate scanning protocol and the target device runtime full vector are generated. The candidate scanning protocol is written into the shadow session as a whole. Based on the parameters of the shadow session, the actual device runtime full vector is obtained. The actual device running state full vector and the target device running state full vector are verified field by field to obtain the verification result in the shadow session, and to determine whether the device has entered the target running state. If the device enters the target running state, the parameters of the shadow session are overwritten with those of the actual running session. The candidate scanning protocol is accepted and a scan is performed. If the device does not enter the target running state, the shadow session is rolled back and the next protocol reconstruction is performed.

7. The control method for the pathological slide scanning device as described in claim 1, characterized in that, Before obtaining the preset protocol construction sequence and the pointer of the protocol reconstruction cursor, the following steps are included: Acquire macroscopic positioning images of the target slide, identify the slide location, tissue region, and label region, and obtain the slice type based on the macroscopic positioning images; The label area is moved to the barcode imaging field of view, a barcode label image is acquired, a barcode candidate area is generated based on the barcode label image, and the barcode candidate area is cascaded for recognition to obtain the barcode pathology number.

8. A pathological slide scanning device, characterized in that, The pathological slide scanning device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for the pathological slide scanning device as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the control method for the pathological slide scanning device as described in any one of claims 1 to 7.

Images