A CT scanning parameter remote cooperative configuration method for smart medical treatment

Abstract

This invention discloses a remote collaborative configuration method for CT scan parameters in smart healthcare, belonging to the field of intelligent control of medical devices. The method first constructs an abstract model layer for CT equipment parameters, defining a unified hierarchical data structure and core scan parameters; establishes a constraint rule base including equipment physical limits, patient safety thresholds, and clinical application guidelines, and performs compliance checks through an intelligent verification engine; develops a brand protocol conversion adapter using a plug-in architecture to achieve bidirectional conversion between standardized parameters and various brand-specific protocols; generates standardized configuration instructions, converts them to the target device's private format after verification, and remotely distributes them; deploys a parsing and execution engine on the device side to complete instruction reception, parsing, and execution. Furthermore, a parameter association model and configuration permission and history management are established. This invention achieves unified parameter description and remote collaborative configuration across brand CT equipment, ensuring the security, compliance, and efficiency of configuration.

Description

Technical Field

[0001] This invention belongs to the field of intelligent control of medical devices, specifically relating to a remote collaborative configuration method for CT scan parameters for smart healthcare. Background Technology

[0002] With the development of smart healthcare, telemedicine technology is increasingly being applied to the management and collaboration of medical imaging equipment. As a crucial diagnostic tool, the precise configuration of CT scan parameters directly determines image quality and patient radiation safety. However, currently, the configuration of CT scan parameters mainly relies on localized software tools provided by equipment manufacturers. Operators must manually adjust these parameters for different brands of equipment, resulting in low configuration efficiency, heavy reliance on personal experience, and difficulty in ensuring standardization.

[0003] While some telemedicine solutions exist, most are designed for general remote consultations or data transmission scenarios and are not adapted to the specific parameters of CT scanning equipment. They lack standardized descriptions and unified management of core parameters. More critically, different brands of CT equipment generally use proprietary communication protocols with incompatible parameter formats, making unified remote collaborative configuration impossible across brands. Furthermore, existing parameter configuration processes lack automatic verification mechanisms for critical constraints such as equipment physical limits, patient radiation safety thresholds, and clinical application guidelines, posing risks of equipment damage or patient safety due to parameters exceeding limits.

[0004] Therefore, how to establish a standardized CT scan parameter description system and security constraint mechanism while being compatible with multiple brand proprietary protocols, so as to achieve safe, efficient, and cross-brand remote collaborative configuration, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this invention is to provide a remote collaborative configuration method for CT scan parameters for smart healthcare, which can effectively solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A method for remote collaborative configuration of CT scan parameters for smart healthcare includes the following specific steps: An abstract model layer for CT equipment parameters is constructed. This layer defines a hierarchical data structure and defines core scanning parameters, including tube voltage parameters, tube current parameters, exposure time parameters, slice thickness parameters, pitch parameters, and reconstruction algorithm parameters. It also specifies the value range and default values ​​of the core scanning parameters, thus forming a standardized parameter description system. Establish a parameter constraint rule base, which includes equipment physical limit rules, patient safety threshold rules, and clinical application guideline rules. The patient safety threshold rules include dose length multiplication accumulation limit and single CT dose index limit. The clinical application guideline rules define recommended rules for parameter configuration in different clinical scenarios. Develop a brand protocol conversion adapter. The brand protocol conversion adapter adopts a plug-in architecture, which encapsulates the private communication protocols of different brands of CT equipment into independent protocol conversion plug-ins. The protocol conversion plug-ins perform bidirectional conversion between standardized parameters and private protocol formats. Standardized configuration instructions are generated based on the CT equipment parameter abstract model layer. The standardized configuration instructions are then validated for compliance using a parameter constraint rule base. Finally, the brand protocol conversion adapter converts the validated standardized configuration instructions into configuration instructions in the target CT equipment's private protocol format before issuing them.

[0007] In summary, this application includes at least one of the following beneficial technical effects: 1. This invention constructs a unified abstract model covering core parameters such as tube voltage, tube current, exposure time, slice thickness, pitch, and reconstruction algorithm, thereby achieving standardized description and unified management of parameters for CT equipment from different brands, laying a technical foundation for cross-brand equipment collaborative configuration; 2. This invention develops a bidirectional protocol conversion adapter for mainstream brands such as Siemens, GE, Philips, and Neusoft, enabling automatic conversion between standardized configuration commands and the proprietary protocols of each brand, thus solving the technical problem of poor interoperability caused by different brands of equipment using proprietary communication protocols; 3. This invention establishes a mathematical model of the linkage between tube voltage and tube current, the matching relationship between layer thickness and reconstruction algorithm, and the mathematical relationship between pitch and scanning time, thereby achieving overall coordinated configuration of parameters and avoiding the problem of decreased scanning quality caused by neglecting the coupling relationship between parameters when adjusting a single parameter. 4. This invention uses a role- and qualification-level driven permission management mechanism to ensure that only medical personnel with the corresponding qualifications can perform parameter configuration operations at the corresponding level, thus preventing security risks caused by unqualified personnel's misoperation. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the overall technical solution for a remote collaborative configuration method of CT scan parameters for smart healthcare.

[0009] Figure 2 A schematic diagram of the hierarchical data structure for the CT equipment parameter abstraction model layer.

[0010] Figure 3 This is a schematic diagram illustrating the plug-in architecture and bidirectional conversion principle of a multi-brand protocol conversion adapter.

[0011] Figure 4 A schematic diagram illustrating the core principles of modeling parameter relationships.

[0012] Figure 5 A schematic diagram illustrating the system functions for configuring historical record management and parameter configuration permission management. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this invention clearer, the following description is provided in conjunction with the appendix. Figure 1 To be continued Figure 5 The present invention will be further described in detail below with reference to specific embodiments.

[0014] This invention provides a remote collaborative configuration method for CT scan parameters in smart healthcare, encompassing six core steps. It establishes a standardized parameter model, builds a constraint rule base, develops a protocol conversion adapter, enables remote parameter distribution and device-side parsing, and establishes a parameter association model, forming a complete remote collaborative configuration technology system for CT scan parameters. This method supports unified management and collaborative configuration of CT equipment from multiple brands, ensuring the security, compliance, and efficiency of parameter configuration. Specifically, it includes the following steps.

[0015] First, for step S1, a CT equipment parameter abstraction model layer is constructed. This layer addresses the heterogeneous nature of multi-brand equipment by defining a unified hierarchical data structure, core parameter specifications, and inherent relationship rules between parameters, forming a standardized parameter description system. This system allows for unified access, verification, and configuration of scanning parameters from different manufacturers and models of CT equipment, providing a consistent data foundation for subsequent constraint rule base matching, brand protocol conversion, and remote collaborative distribution. The following sections elaborate on these sub-steps.

[0016] Step S101: Construct a hierarchical data structure for the CT equipment parameter abstract model layer. The CT equipment parameter abstract model layer is divided into three levels from top to bottom: the top-level equipment abstract model, the middle-level protocol abstract model, and the bottom-level brand proprietary protocol model.

[0017] Step S102: At the top level, define the specific content of the device abstract model. The device abstract model is used to characterize the common attributes of CT equipment and the functional interfaces exposed to upper-level applications. Common attribute information includes equipment identifier, equipment model, manufacturer, department, installation location, and network address.

[0018] The functional interfaces include parameter reading, parameter writing, status query, and execution control interfaces. Through this layer, different brands and models of CT equipment can be accessed from a unified view without needing to be aware of the underlying communication differences.

[0019] Step S103: In the intermediate layer, a protocol abstraction layer is constructed. The protocol abstraction layer defines standard data structures and semantic descriptions for CT scan parameters, independent of specific brands. Parameter encoding can use a unified XML text format or a compact binary format, enabling parameter data from different devices and systems to be uniformly parsed and exchanged. The protocol abstraction layer provides a standardized parameter access view upwards and a conversion basis downwards for adapting to various brands' proprietary protocols.

[0020] Step S104: At the bottom layer, establish a brand-specific protocol layer. This layer is responsible for encapsulating the communication formats and data encoding rules specific to each brand of CT equipment. Specifically, this includes frame structure design, byte order definition, verification rules, and the underlying transmission control protocol. The brand-specific protocol layer is the direct target of the protocol adapter's format conversion, supporting the bidirectional mapping between standardized parameters and proprietary protocol frames.

[0021] Step S105: Define six types of core scanning parameters in the device parameter abstract model layer, and specify their respective value ranges and default values.

[0022] The first type is the tube voltage parameter, which reflects the accelerating voltage of the X-ray tube. The value ranges from 60kVp to 150kVp, with a default value of 120kVp. The tube voltage directly affects the penetration ability of X-rays and tissue contrast.

[0023] The second category is tube current parameters, which reflect the intensity of the anodic current of the X-ray tube. The value ranges from 10mA to 800mA, with a default value of 200mA. The tube current and tube voltage together determine the radiation dose level.

[0024] The third category is the exposure time parameter, which describes the duration of ray emission in a single scan. The value ranges from 10ms to 5000ms, with a default value of 500ms. The exposure time parameter affects the control of image signal-to-noise ratio and motion artifacts.

[0025] The fourth category is the slice thickness parameter, which represents the thickness of the tomographic slice. The value ranges from 0.5 mm to 10 mm, with a default value of 5 mm. Slice thickness affects spatial resolution and the degree of suppression of some volumetric effects.

[0026] The fifth category is the pitch parameter, which is defined as the ratio of the scanning bed movement speed to the collimator width. The value ranges from 0.2 to 2.0, with a default value of 0.8. The pitch affects the scanning coverage and image noise level.

[0027] The sixth category is the reconstruction algorithm parameters, which specify the core algorithm used for image reconstruction. This method supports two major modes: filtered back projection and iterative reconstruction.

[0028] Among them, the filtered back projection method can further select variants such as standard filtering function, soft tissue filtering function or bone filtering function; the iterative reconstruction method can select implementation methods such as statistical iterative reconstruction or deep learning iterative reconstruction.

[0029] For the deep learning iterative reconstruction algorithm option, the reconstruction model used internally needs to be pre-trained. The training data is constructed by collecting a large amount of low-dose projection data generated from clinical CT scans, and correspondingly obtaining high-quality reconstructed images of the same location at high doses as the gold standard, forming one-to-one registration training sample pairs.

[0030] The network structure primarily employs a deep convolutional neural network. The input is a noisy image reconstructed through preliminary filtering and backprojection, and the output is a clear image after denoising and detail restoration. The loss function is designed as a weighted combination of mean squared error loss and perceptual loss, and the training objective is to minimize the overall difference between the network's output image and the gold standard high-quality image.

[0031] By iteratively updating the network weights through error backpropagation, a reconstruction model that can be used for inference is finally obtained. When deep learning iterative reconstruction is selected in the configuration parameters, the device calls the trained reconstruction model to complete the image reconstruction during the reconstruction step.

[0032] Step S106: Parameter correlation modeling is performed within the parameter abstraction model layer. First, the linkage relationship between tube voltage and tube current is established. This linkage follows the principle of maintaining a relatively constant radiation dose output. While ensuring acceptable image noise levels, the product of tube voltage and tube current is kept approximately constant. From this, the calculation method for linkage adjustment is derived: the new tube current value is equal to the original tube current multiplied by the ratio of the original tube voltage to the new tube voltage.

[0033] For example, when the tube voltage is increased from 100kVp to 120kVp, the tube current needs to be adjusted from 250mA to approximately 208mA to maintain a similar radiation output. When the tube voltage decreases, the tube current is increased in the opposite direction according to the same rule.

[0034] Furthermore, the linkage model adaptively adjusts according to the diagnostic quality requirements of the examination site. For head scans, soft tissue contrast needs to be prioritized, with a typical tube voltage setting range of 100kVp to 120kVp; for chest scans, penetration of lung tissue and bone structure is required, with a typical tube voltage setting range of 120kVp to 140kVp; for abdominal scans, changes in soft tissue thickness need to be overcome, with a typical tube voltage setting range of 110kVp to 130kVp.

[0035] These constraints ensure that, during the process of adjusting the parameters in a coordinated manner, the final combination of parameters always meets the clinical imaging quality standards for the corresponding site.

[0036] Step S1 completes the construction of the CT equipment parameter abstract model layer. The CT equipment parameter abstract model layer decouples equipment attributes, parameter semantics, and communication protocols, not only unifying the six types of core parameters and their value specifications, but also establishing linkage and coordination rules between parameters, enabling the standardized management of cross-brand equipment.

[0037] In subsequent steps, the parameter constraint rule base will directly reference the parameter description system to perform security verification of the configuration. The brand protocol conversion adapter will also perform bidirectional format conversion using the CT equipment parameter abstract model layer as an intermediate representation. The standardized remote configuration distribution and device-side parsing and execution are also based on the CT equipment parameter abstract model layer, thereby realizing the remote collaborative configuration of scanning parameters of different brands of CT equipment as a whole.

[0038] The next step, S2, is to establish a parameter constraint rule base. From the three dimensions of equipment hardware capabilities, patient radiation safety, and clinical diagnostic standards, a multi-level constraint rule system covering equipment physical limits, patient safety thresholds, and clinical application guidelines is constructed. This includes the following steps.

[0039] Step S201 defines the physical limit rules for the equipment, specifying the upper and lower limits of the safe operating range for each CT scan parameter. If a parameter configuration exceeds the corresponding range, the hardware is deemed unexecutable. The physical limit range for the tube voltage is 50kVp to 150kVp. Below the lower limit, the X-ray generation efficiency is too low; above the upper limit, the X-ray tube faces the risk of overload damage.

[0040] The physical limits for tube current range from 5mA to 1000mA. Below the lower limit, the signal strength is insufficient to generate diagnostic images, while above the upper limit, there is a risk of X-ray tube overheating or anode damage. The physical limits for exposure time range from 1ms to 10000ms. Below the lower limit, sampling data is insufficient, while above the upper limit, motion artifacts are exacerbated. The physical limits for slice thickness range from 0.25mm to 20mm, determined by both the detector's physical structure and the reconstruction algorithm's capabilities.

[0041] The physical limits of the pitch range from 0.1 to 3.0, constrained by the gantry's mechanical structure and the requirements of the reconstruction algorithm for the integrity of the projected data. The range of selectable reconstruction algorithms is limited by both the device's software license and hardware configuration. Some advanced reconstruction algorithms require onboard graphics processing unit (GPU) accelerator cards to provide computing power. If the target CT device does not have the corresponding accelerator card installed, the corresponding reconstruction algorithm option will be unavailable.

[0042] Step S202: Establish patient safety threshold rules, including two levels: dose length multiplied by the cumulative limit and single-examination CT dose index limit. For the dose length multiplied by the cumulative limit, the limit for a single adult CT examination is set in the range of 800 mGy·cm to 1500 mGy·cm, with the actual value differentiated according to the examination type and patient body size; for pediatric CT examinations, the limit is lowered to 50% to 70% of the adult limit based on the child's age and weight.

[0043] For single CT dose index limits, the limits are differentiated by the examination site: 80 mGy for head examination, 30 mGy for chest examination, and 35 mGy for abdominal examination.

[0044] The verification logic for the patient safety threshold is as follows: When a parameter configuration request is received, the parameters affecting the radiation dose, such as tube voltage, tube current, exposure time, and scan length, are extracted first. Then, the expected dose-length product value is automatically calculated using the dose calculation model. The dose-length product is calculated using an integral summation model, specifically according to formula (1): ; in, The product of dose and length is represented by a unit of 1000. ; Indicates the position along the scanning axis Volumetric CT dose index at the location, in units of ; It is a position variable along the scanning axis; Indicates the range of scan length.

[0045] After the calculation is completed, the expected The value is compared with the preset cumulative limit. If the expected value exceeds the limit, the configuration request is rejected and a warning message is returned to the operator. The warning message carries three key data: the over-limit ratio, the current limit, and the expected value.

[0046] In addition, the verification logic also supports dose limit calculation based on body shape adaptive adjustment. It automatically calculates the corresponding personalized dose limit according to the patient's height and weight data, and replaces the default limit with the personalized limit for comparison, thereby reducing the actual radiation dose received by the patient while ensuring the quality of diagnosis.

[0047] Step S203: Define recommended parameter configuration rules for different clinical scenarios in the clinical application guideline module. Adult scanning protocols are subdivided according to the examination site into head protocol, neck protocol, chest protocol, abdomen protocol, pelvic protocol, spine protocol, and limb protocol. Each protocol has a preset set of optimized parameter combinations for the diagnostic purpose.

[0048] The pediatric scanning protocols are subdivided into newborn protocols, infant protocols, preschool child protocols, and adolescent protocols according to age groups. Each protocol is based on adult parameters, multiplied by a dose reduction adjustment factor calculated based on the child's age and weight, to obtain a set of parameters applicable to the corresponding age group.

[0049] The clinical application guidelines module further distinguishes between emergency scanning protocols and routine physical examination scanning protocols. The emergency scanning protocol prioritizes shortening the scanning time and uses a fixed combination of parameters: tube voltage is fixed at 120kVp, tube current is fixed at 200mA, exposure time is fixed at 300ms, slice thickness is fixed at 5mm, pitch is fixed at 1.0, and the reconstruction algorithm is fixed to use the filtered back projection method to compress reconstruction time.

[0050] For routine physical examination scans, priority is given to improving image quality. The tube voltage is selected from 100kVp to 140kVp depending on the examination site, the tube current is selected from 100mA to 400mA depending on the patient's body size, the exposure time is selected from 200ms to 1000ms depending on the required signal-to-noise ratio, the slice thickness is selected from 1mm to 5mm depending on the diagnostic requirements, and the pitch is selected from 0.6 to 0.8. When the equipment capacity allows, the iterative reconstruction method is enabled to reduce the radiation dose.

[0051] Medical staff only need to select the examination type and enter the patient information, and the system will automatically load the parameter template that matches the selected protocol, and make local adjustments as needed based on individual patient differences.

[0052] Step S204: Construct an intelligent verification engine as the execution component of the constraint rule base, which automatically triggers compliance checks when a parameter configuration request is submitted. After receiving the configuration request, the intelligent verification engine checks each item in the order of physical limit verification, patient safety verification, and clinical guideline verification.

[0053] The physical limit check verifies whether all parameters fall within the corresponding device's physical limit range. If any parameter exceeds the physical limit, the verification fails and subsequent checks are terminated. The patient safety check calls the dose calculation model to obtain the expected dose index and compares it with the dose limit in the patient safety threshold rules. Configuration requests that exceed the limit are directly rejected or a secondary confirmation request is sent to the operator.

[0054] The clinical guidelines check whether the current parameter combination is within the recommended configuration range of the corresponding scanning protocol. If it deviates from the recommended range, the engine will give a warning but will not forcibly block it. Medical staff can decide whether to accept or continue to adjust the configuration based on the actual clinical judgment.

[0055] The intelligent verification engine is configured with both incremental and full verification modes. In incremental verification mode, the engine only checks the parameters that have changed in the current configuration request, thereby shortening the verification response time. In full verification mode, the engine performs a complete check on all parameters in the configuration request, one by one, for scenarios such as device initialization, parameter restoration, and post-fault state reconstruction, ensuring the integrity of the configuration.

[0056] In step S2, the parameter constraint rule base narrows the parameter selection space layer by layer from three dimensions: physical limits, patient safety, and clinical guidelines. This ensures that each configuration instruction has completed compliance checks before entering the subsequent protocol conversion and distribution stages, reducing the probability of device refusal to execute or patient safety incidents caused by parameter out-of-bounds errors from the source.

[0057] The next step, S3, involves developing a brand protocol conversion adapter to connect the standardized parameter model with the proprietary communication protocols of various CT equipment brands, performing bidirectional format conversion.

[0058] Step S301: Determine the plug-in architecture of the brand protocol conversion adapter. Encapsulate the protocol conversion logic for each brand into an independent plug-in. Each plug-in follows a unified data exchange interface specification, which clearly defines the parameter object structure, command frame format, and response parsing rules.

[0059] When integrating new brand CT equipment, only the corresponding protocol conversion plugin needs to be developed and registered according to the interface specification; no changes to the core logic code are required. The plugin management system is responsible for loading, initializing, monitoring the running status, and unloading plugins, and supports hot-swapping, enabling brand expansion without system downtime.

[0060] Step S302: Establish four core brand protocol conversion modules in the brand protocol conversion adapter, which can respectively adapt to the private communication protocols of Siemens, GE, Philips and Neusoft CT equipment.

[0061] The Siemens series equipment protocol conversion module is compatible with the custom binary protocol based on TCP / IP used by Siemens CT equipment. The frame structure consists of five fields: frame header, command code, data length, data field, and checksum. The parameter encoding adopts a hybrid method, with some parameters stored in BCD code format and some in binary format.

[0062] The GE series equipment protocol conversion module is adapted to the DICOM standard-based extended protocol used by GE CT equipment. It adds dedicated service classes for equipment control on top of the DICOM basic command set, and the parameter encoding follows the DICOM information object definition specification.

[0063] The Philips series equipment protocol conversion module is compatible with the configuration description language based on XML format used by Philips CT equipment. Parameters are organized in a hierarchical tag format and support complex nested relationships.

[0064] The Neusoft series equipment protocol conversion module is adapted to the simplified binary protocol used by Neusoft CT equipment. It has a compact frame structure and is suitable for high-frequency parameter interaction scenarios.

[0065] Step S303: Perform forward conversion to convert the standardized parameter model into a device-specific protocol format for issuing configuration commands to the target CT device. The forward conversion process is as follows: First, serialize the standardized parameter object to generate a unified format intermediate data stream; then, select the corresponding protocol conversion plugin based on the target device's brand identifier, and the plugin converts the intermediate data stream into a device-recognizable proprietary format data frame according to the proprietary protocol specification; finally, add control fields such as the frame header and checksum as specified by the protocol to the data frame to complete frame assembly.

[0066] The forward conversion process also includes data format mapping, value range conversion, and unit conversion operations: tube voltage is uniformly expressed in kVp, and if the proprietary protocol is expressed in V, it is converted by multiplying by 1000; tube current is uniformly expressed in mA, and if the proprietary protocol is expressed in μA, it is converted by multiplying by 1000; layer thickness is uniformly expressed in mm, and if the proprietary protocol is expressed in cm, it is converted by multiplying by 10.

[0067] Step S304: Perform reverse conversion to parse the parameter status reported by the device from the proprietary format into a standardized format for unified monitoring and management. The reverse conversion process is as follows: receive the proprietary format data frame reported by the device, split the command code and data field content according to the frame structure, perform decoding according to the data encoding format to restore the original parameter value, and finally map the parameter value to the standardized parameter object and fill it into the data model.

[0068] During the reverse conversion process, data verification, format validation, and exception handling are performed simultaneously: verifying the integrity of data frames, including frame length verification and checksum verification; verifying whether parameter values ​​fall within a reasonable range and isolating abnormal data; handling protocol version compatibility issues, logging unrecognized command codes, and returning error responses.

[0069] Step S305: Maintain a brand protocol configuration mapping table within the brand protocol conversion adapter. The mapping table records the list of parameters supported by each brand, the parameter value range, default value settings, and parameter dependencies. It also features a version management mechanism to save historical change records of the device protocols for each brand. When a device software upgrade causes a change in the protocol format, only the corresponding version's configuration item in the mapping table needs to be updated for compatibility; no modification to the protocol conversion logic code is required.

[0070] In step S306, when the brand protocol conversion adapter establishes a connection with the CT device, it automatically performs protocol version negotiation, queries the protocol version currently running on the device, and selects a matching conversion strategy accordingly to ensure normal communication with devices of different versions.

[0071] Through steps S301 to S306, the brand protocol conversion adapter is completed. The adapter uses a plug-in architecture to accommodate multiple brand-specific protocol conversion modules. It establishes a mapping channel between the standardized parameter model and the proprietary protocols through bidirectional forward and reverse conversion, and adapts to protocol evolution using mapping table version management and automatic negotiation mechanisms. At this point, standardized configuration commands, after being verified by the constraint rule base, can be converted by the brand protocol conversion adapter into a device-recognizable proprietary format, providing data frames that can be directly delivered to the device for the standardized remote configuration distribution in subsequent step S4.

[0072] For step S4, a unified format configuration command is generated based on the standardized parameter model, and the configuration command is remotely sent to the target CT device through a network communication link to achieve standardized transmission of configuration, specifically including...

[0073] Step S401: Design the structured encoding format for configuration instructions. Configuration instructions consist of three parts: an instruction header, a parameter field, and a check field.

[0074] The command header contains three required fields and several optional fields. The required fields are the target device identifier, command type, and serial number. The target device identifier uses a uniformly assigned unique device code, with a fixed length of 12 bytes: a 2-byte manufacturer code, a 2-byte device model code, and an 8-byte serial number. This ensures that configuration commands are accurately routed to the target CT device and supports both single device identifier and device group identifier addressing modes. The device group identifier is implemented by setting a multicast mask bit in the unique device code, allowing for both point-to-point and group-based batch delivery.

[0075] The instruction type is a 1-byte enumeration value used to define the specific semantics of this configuration operation: 0x01 represents a parameter setting instruction, 0x02 represents a parameter query instruction, 0x03 represents a parameter restore to default settings instruction, and 0x04 represents a batch parameter execution instruction. The sequence number uses a 2-byte unsigned integer incrementing mechanism, with an initial value of 0x0001, incrementing by 1 for each new instruction sent, used for instruction deduplication and response matching. Optional fields include a 1-byte protocol version number and a 4-byte Unix timestamp.

[0076] Step S402: Construct the parameter field. The parameter field carries the parameter name and parameter value in a key-value pair sequence format to ensure the scalability of the parameters. The parameter field as a whole adopts TLV, which is a sequence encoding of Type-Length-Value triples. Each TLV triple consists of a 2-byte parameter type identifier (Type), a 2-byte parameter value length (Length), and a variable-length parameter value (Value). Each TLV triple is a key-value pair.

[0077] The parameter type identifier Type is the parameter name field, which adopts the same standard parameter encoding as the CT equipment parameter abstract model layer. The Type encoding for tube voltage is 0x0101, tube current is 0x0102, exposure time is 0x0103, slice thickness is 0x0104, pitch is 0x0105, and reconstruction algorithm is 0x0106.

[0078] The Value field selects the corresponding data encoding format according to the parameter type. Integer parameters use big-endian binary encoding, floating-point parameters use IEEE 754 single-precision floating-point encoding, and enumerated parameters use 1-byte ordinal encoding. The Length field records the byte length of Value.

[0079] The parameter field distinguishes between required and optional parameters. The highest bit of the parameter type identifier serves as the required / optional flag; a highest bit of 0 indicates a required parameter, and a highest bit of 1 indicates an optional parameter.

[0080] Required parameters must appear in the configuration command; a configuration command is considered invalid if a required parameter is missing. Optional parameters can be selectively included according to configuration requirements. Optional parameters that are not included will retain the current values ​​of the CT equipment and will not disturb the existing operating status.

[0081] Step S403: Construct the check field and determine the check method. The check field contains a cyclic redundancy check (CRC) code for transmission integrity verification. The check code is calculated using the CRC-16-CCITT algorithm, and the generator polynomial is: ; in, The variables in the generator polynomial are represented by their exponents. powers of, This represents the 16th term of the generator polynomial. Represents the 12th term of the generator polynomial. This represents the 5th term of the generator polynomial, with a constant term of 1.

[0082] The initial value of the CRC-16-CCITT algorithm is 0xFFFF. The checksum calculation covers the complete data content of the instruction header and parameter fields. The checksum field is 2 bytes long and placed at the end of the frame structure. After receiving the configuration instruction, the receiving end also recalculates the checksum for the instruction header and parameter fields using the CRC-16-CCITT algorithm, comparing it byte-by-byte with the checksum carried in the frame. If they match, the transmission is considered complete; otherwise, a retransmission request frame is sent to the sending end. The retransmission request frame contains the original instruction sequence number. Upon receiving it, the sending end retransmits the configuration instruction with the corresponding sequence number.

[0083] The verification field also supports an optional digital signature field for verifying the source of the instruction. The activation of the digital signature field is controlled by the highest bit of the protocol version number in the instruction header; a value of 1 in the highest bit indicates that a digital signature is included. The digital signature generation process is as follows: first, perform a SHA-256 hash operation on the complete data concatenated from the instruction header and parameter fields to obtain a 32-byte message digest; then, use the RSA-2048 or SM2 private key held by the sender to perform a signature operation on the message digest to generate a signature value.

[0084] RSA-2048 signatures output 256 bytes, while SM2 signatures output 64 bytes. Upon receiving the configuration command, the receiving end uses the public key paired with the sender's private key to perform a signature verification operation on the signature value. The resulting digest is compared with a locally recalculated SHA-256 digest. If they match, the signature verification is successful, ensuring that the configuration command's source is undeniable and its content has not been tampered with during transmission.

[0085] Step S404: Configure the configuration delivery module with both synchronous and asynchronous delivery modes, and establish an instruction queue management mechanism. The configuration delivery module maintains a first-in-first-out instruction sending queue and a sequence number-based status tracking table at the application layer. The status tracking table records the current status of each sent instruction, including four states: pending delivery, sent but not acknowledged, executed successfully, and executed unsuccessfully.

[0086] In synchronous delivery mode, the configuration delivery module retrieves the instruction to be sent from the instruction sending queue, sends it to the target CT device through the TLS1.3 encrypted channel, sets the status of the corresponding serial number in the status tracking table to sent but not confirmed, and then starts a 2-second timer to enter a blocking wait.

[0087] If an execution result confirmation frame is received from the target CT device within 2 seconds, the sequence number and execution result status code in the confirmation frame are extracted, the corresponding record in the status tracking table is updated to execution success or execution failure, and the execution result is returned to the caller.

[0088] If no acknowledgment frame is received before the timer expires, the corresponding record in the status tracking table will be marked as an execution failure, a timeout alarm will be generated and an exception log will be recorded, and a timeout error will be returned to the caller.

[0089] In asynchronous delivery mode, the configuration delivery module retrieves the instruction to be sent from the instruction sending queue, sends it to the target CT device through the TLS1.3 encrypted channel, immediately sets the status of the corresponding serial number in the status tracking table to sent but not acknowledged, and then returns the sending success status and serial number to the caller without waiting for the execution result from the device.

[0090] The configuration delivery module maintains a separate receiving thread in the background, continuously listening for result callback messages from the device. When it receives an execution result callback frame actively reported by the device, it looks up the status tracking table based on the sequence number in the callback frame and updates the corresponding record. The caller can query the configuration delivery module for the execution status of the instruction using the sequence number.

[0091] The instruction queue management mechanism works as follows: the instruction sending queue has a maximum queue depth threshold, with a default value of 1000 entries. When the number of concurrent configuration requests exceeds the maximum queue depth, the excess requests are directly rejected, and a queue full error is returned. Instructions in the instruction sending queue are retrieved and sent one by one by worker threads in the order they were enqueued, with a minimum interval of 10ms between two adjacent instructions to avoid network congestion and overload of the target CT equipment caused by excessive instantaneous traffic.

[0092] Step S405 involves co-deploying the configuration distribution module and the network security module to ensure the security of the transmission channel. The transport layer uses the TLS 1.3 protocol to encrypt network communication. During the TLS 1.3 handshake phase, the ECDHE (Elliptic Curve Diffie-Hellman Key Exchange Algorithm) is used for key negotiation. The encryption suite uses TLS_AES_256_GCM_SHA384 to provide forward security and data integrity verification.

[0093] The configuration command is encrypted and an authentication tag is attached by the TLS 1.3 record layer before leaving the sending TCP socket, and decrypted and the authentication tag is verified by the TLS 1.3 record layer after arriving at the receiving TCP socket, to prevent the configuration command from being eavesdropped or tampered with during transmission.

[0094] The network layer deploys an access control list (ACCUP) mechanism. ACCUPs store authorized entries in triples, each containing the allowed client IP address, subnet mask, and permission policy action. When a TCP port configured to listen for the service receives a SYN connection request, the network layer first extracts the source IP address of the request and matches it against entries in the ACCUP in sequence. If a match is found and the policy action is "allow," the TCP three-way handshake is allowed to continue. If a match fails or the policy action is "deny," an RST packet is sent to reset the connection request. Connection requests that do not match the ACCUP are discarded before reaching the application layer.

[0095] The application layer implements operation auditing functionality, maintaining complete logs of all configuration command transmissions. The logs are in structured JSON format, with each entry containing an ISO 8601 format string indicating the transmission time (accurate to milliseconds), the source IP address, the target CT device identifier, the command sequence number, the command type enumeration value, a complete copy of all parameter key-value pairs in the parameter field, and the operator's identifier.

[0096] Log data is appended to the audit log file in chronological order. The audit log file is rolled over hourly. Historical log files are stored in the security audit database with read-only permissions for post-event auditing and problem tracing. The write operation of the audit log is completed in the same transaction context as the configuration deployment operation. When the configuration is successfully deployed, the audit log is guaranteed to be written to disk to prevent inconsistencies between the log and the operation record.

[0097] In step S4, the standardized remote configuration distribution module is completed. This module encapsulates the configuration commands, verified by the constraint rule base and converted by the protocol conversion adapter, in TLV encoding format. After CRC-16 integrity verification and RSA-2048 / SM2 digital signature protection, and filtering through a TLS 1.3 encrypted channel and access control list, it distributes the commands to the target CT device in synchronous or asynchronous mode via a command queue management mechanism. Once the commands arrive at the device, they are received, parsed, and executed by the device-side parsing and execution engine in subsequent step S5, thus completing the actual parameter changes on the device side.

[0098] Then, in step S5, an adapter component is deployed on the device side as the receiver and executor of configuration instructions. It is responsible for receiving standardized configuration instructions and parsing the protocol, converting the standardized parameters into a private protocol instruction sequence that the device can recognize, and triggering the device to perform parameter change operations.

[0099] Step S501: Build a device-side parsing and execution engine in the device-side adapter component, and set two working modes: incremental configuration and full configuration.

[0100] The incremental configuration mode works as follows: The device-side parsing and execution engine reads the instruction type field from the instruction header of the configuration request. When the instruction type is a parameter setting instruction and the parameter field only carries some parameter key-value pairs, the current request is determined to be an incremental configuration type. The device-side parsing and execution engine only extracts the TLV triples that actually appear in the parameter field for parsing and processing. For parameter items not carried in the parameter field, the current operating value of the CT device remains unchanged, and no modification command for the corresponding parameter is sent to the device control system. Incremental configuration mode is suitable for routine parameter fine-tuning operations, and the amount of data that needs to be transmitted can usually be reduced to 20% to 30% of the full configuration.

[0101] The full configuration mode works as follows: when the instruction type is a parameter recovery default instruction or a parameter batch execution instruction, or when the parameter field carries the TLV triplet corresponding to all six types of core scan parameters, the device-side parsing and execution engine determines that the current request is of the full configuration type. In full configuration mode, the device-side parsing and execution engine transmits the complete set of parameters, covering the current operating parameters of the CT device item by item, for device initialization, parameter recovery, and post-fault recovery state reconstruction scenarios.

[0102] Step S502: The device-side parsing and execution engine executes the instruction receiving stage. The device-side parsing and execution engine listens on the TCP port of the configured distribution channel on the device side and receives data streams from the network. The device-side parsing and execution engine maintains a receive buffer in memory and appends arriving TCP data segments sequentially to the end of the receive buffer.

[0103] The device-side parsing and execution engine performs packet fragmentation and frame boundary identification according to the frame format definition in the configuration instructions: Frame boundaries are defined by a frame start marker and a frame end marker. The frame start marker is a fixed 2-byte value 0xA5C3, and the frame end marker is a fixed 2-byte value 0xD63B. Data before the frame start marker is residual or invalid data from the previous frame and is discarded; data after the frame end marker is temporarily stored in the receive buffer to await the arrival of the next frame. The consecutive bytes between the frame start marker and the frame end marker constitute the complete frame data. The device-side parsing and execution engine retrieves the complete frame data from the receive buffer and proceeds to the subsequent parsing stage.

[0104] Step S503: The device-side parsing and execution engine performs the protocol parsing process. The device-side parsing and execution engine first performs frame structure integrity verification and checksum correctness verification on the complete frame data. The frame structure integrity verification checks whether the length of each field within the frame is consistent with the field definition, including whether the cumulative value of the instruction header length, parameter field length, and checksum length is equal to the total length of the frame data.

[0105] The verification of the correctness of the check code is performed according to the CRC-16-CCITT algorithm defined in step S403. The check code is recalculated in the instruction header and parameter field of the frame and compared byte by byte with the check code carried in the check field. If the two are inconsistent, the verification is determined to be unsuccessful and a retransmission request frame is returned to the sending end.

[0106] After successful verification, the device-side parsing and execution engine parses the target device identifier, instruction type, and serial number according to the instruction header format. If the instruction type is a parameter query instruction, the device-side parsing and execution engine reads the current parameter status of the CT device, assembles it into a parameter field, and directly jumps to the result feedback stage. If the instruction type is a parameter setting instruction, a parameter restore default instruction, or a parameter batch execution instruction, the device-side parsing and execution engine continues to the parameter field parsing stage.

[0107] The parameter field parsing process works as follows: the device-side parsing execution engine extracts each TLV triplet from the parameter field according to the TLV encoding rules, reads the 2-byte Type field to obtain the parameter type identifier, reads the 2-byte Length field to obtain the byte length of the subsequent Value, and then reads the Value field according to the length indicated by Length to obtain the standardized parameter key-value pair data. The above steps are repeated until the end of the parameter field.

[0108] Step S504: The device-side parsing and execution engine performs the parameter conversion process. The device-side parsing and execution engine maintains a protocol mapping table locally. The protocol mapping table is indexed by the parameter type identifier Type. Each record in the protocol mapping table contains five fields: standard parameter type identifier, CT device local parameter identifier, local parameter encoding format, lower limit of local parameter value range, and upper limit of local parameter value range.

[0109] When the adapter component on the device side starts up for the first time, the protocol mapping table is automatically populated by reading the device description file of the target CT device. The device description file contains a complete list of parameters supported by the target CT device, the corresponding local identifier, the encoding format and the physical limit range. The protocol mapping table is a structured memory representation of the parameter information in the device description file.

[0110] During parameter conversion, the device-side parsing and execution engine looks up the protocol mapping table based on the Type value of each TLV triple, mapping the standard parameter name to a local parameter identifier that the CT device control system can recognize. Then, according to the encoding format recorded in the protocol mapping table, the parameter value is converted from the standardized representation in the TLV triple to the local representation of the CT device.

[0111] During the conversion process, parameter boundary checks are performed: the device-side parsing and execution engine compares the converted local parameter values ​​with the parameter value ranges recorded in the protocol mapping table. If the converted local parameter values ​​fall within the parameter value range, subsequent processing is allowed to continue.

[0112] When the converted local parameter value exceeds the parameter value range, if the excess is within 10% of the upper or lower limit of the parameter value range, the device-side parsing and execution engine will truncate the out-of-bounds value to the boundary value and record the truncation log; if the excess exceeds 10%, the device-side parsing and execution engine will refuse to execute the corresponding parameter item, return detailed error information to the sending end, and continue to process the remaining parameter items in the parameter field.

[0113] Step S505: The device-side parsing and execution engine performs the command assembly and command issuance stages. In the command assembly stage, the device-side parsing and execution engine assembles the converted local parameter data according to the frame format of the CT device's proprietary protocol, adds the command code, control fields, and frame end marker specified by the proprietary protocol, and generates a command frame that the device control system can directly parse.

[0114] During the command issuance phase, the device-side parsing and execution engine sends the assembled command frame to the device control system via the device's local control interface. This local control interface is an internal application programming interface provided by the CT equipment manufacturer. The device-side parsing and execution engine writes the command frame into the device control system's command receiving queue by calling this internal application programming interface. The device control system then reads the command frames in queue order, parses the commands, and executes the corresponding parameter change operations.

[0115] After the parameter change operation is completed, the equipment control system returns the execution result status code to the equipment-side parsing execution engine. A status code of 0 indicates successful execution, while a non-zero status code indicates execution failure with an error reason code.

[0116] Step S506: Device-side parsing and execution engine execution result feedback. After receiving the execution result status code returned by the device control system, the device-side parsing and execution engine generates a standardized response message based on the status code. The standardized response message uses the same structured encoding format as the configuration command, with the command type field set to 0x05 to indicate an execution result response, and the parameter field carrying the execution result status code and error reason code. The device-side parsing and execution engine sends the standardized response message to the configuration distribution server through a TLS 1.3 encrypted channel, completing a full configuration command loop.

[0117] Step S507: The device-side parsing and execution engine establishes an exception handling mechanism to cover three types of exception scenarios: network communication exceptions, device response exceptions, and data verification exceptions.

[0118] The handling of network communication anomalies is as follows: When a connection is interrupted, the device-side parsing and execution engine detects a TCP connection disconnection event and immediately initiates a reconnection process. Following an exponential backoff strategy, it attempts to rebuild the TCP connection at intervals of 1 second, 2 seconds, and 4 seconds, with a maximum of 3 retries. After a successful reconnection, the device-side parsing and execution engine queries the state tracking table for the sequence number of the last sent but unacknowledged instruction and sends a state synchronization request to the sender to restore the configuration context. When data packets are lost, the sender triggers a retransmission after a timeout if no acknowledgment frame is received. The device-side parsing and execution engine identifies the retransmission instruction based on the sequence number. If an instruction with the same sequence number has already been received, the duplicate frame is discarded, and the execution result is returned.

[0119] In the event of a timeout, the device-side parsing and execution engine starts a device response timeout timer when each instruction enters the command issuance stage. The timeout limit is set to 5 seconds. If the status code returned by the device control system is not received after the timeout, the device-side parsing and execution engine triggers a timeout alarm, records the exception log, and returns a timeout error response to the sending end.

[0120] The handling method for abnormal device response is as follows: When the device is busy, the device-side parsing and execution engine receives the device busy status code returned by the device control system, puts the current configuration request into the retry queue, and sets the maximum number of retries in the retry queue to 3, with a retry interval of 2 seconds. Before the number of retries is exhausted, the command is resubmitted after the device is ready. After the maximum number of retries is exceeded, a device unavailable error is returned to the sending end.

[0121] When equipment malfunctions, the device-side parsing and execution engine receives the fault status code returned by the equipment control system, immediately reports a fault alarm, marks the target CT equipment as unavailable, stops sending new configuration requests to the target CT equipment, and returns a device fault error to the sending end. When the protocol is not supported, the device-side parsing and execution engine finds an unrecognizable parameter type identifier (Type) during the protocol parsing process, records the unsupported parameter type identifier and generates a warning log, skips the corresponding parameter item and continues to process subsequent recognizable parameter items in the parameter field, and carries some execution flags in the result feedback.

[0122] The handling method for data verification exceptions is as follows: when the check code does not match, the device-side parsing and execution engine requests the sending end to resend the configuration command; when the data format is incorrect, the device-side parsing and execution engine generates an error report containing the error offset and error type, refuses to execute the current configuration command, and returns a format error response to the sending end; when the parameter value goes out of bounds, the truncation or rejection operation is performed according to the parameter boundary check processing logic in step S504.

[0123] Through step S5, the device-side parsing and execution engine is completed and possesses the capabilities of command reception, parsing, conversion, distribution, feedback, and exception handling. The device-side parsing and execution engine parses the configuration commands decrypted by TLS 1.3 and allowed by the access control list frame by frame, converts them into command frames that can be executed locally on the device through the protocol mapping table, drives the device control system to complete parameter changes through the device's local control interface, and sends the execution results back to the configuration distribution server.

[0124] The construction of the device-side parsing and execution engine provides the execution foundation for the linkage conflict detection of parameter association modeling in the subsequent step S6. Feedback information such as whether the parameter change was successful and whether the parameter value went out of bounds can be directly recorded and traced by the configuration history management module in step S6.

[0125] Finally, in step S6, the coupling constraint relationship between CT scanning parameters is defined, a linkage model between tube voltage and tube current, a matching relationship table between slice thickness and reconstruction algorithm, and a mathematical calculation formula for pitch and scanning time are established to achieve overall coordinated configuration of parameters and avoid mismatch problems between parameters caused by adjusting a single parameter.

[0126] Step S601: Establish a linkage model between tube voltage and tube current. This linkage model follows the principle of constant radiation dose; under the condition of maintaining approximately consistent noise levels, there is a definite mathematical relationship between the proportion of increase in tube voltage and the proportion of decrease in tube current. The linkage model defines a typical proportionality coefficient for the decrease in tube current when the tube voltage increases by 10 kVp. This proportionality coefficient is calibrated to 15% to 20% based on clinical validation data.

[0127] The linkage model also considers the differences in the sensitivity of image noise to changes in tube voltage. When the tube voltage is low, the noise is more significantly affected by the tube current, while when the tube voltage is high, the noise is relatively less affected by the tube current.

[0128] The linkage model parameters support personalized calibration based on the characteristics of CT equipment. The calibration process obtains the noise-dose characteristic curve through actual scanning tests and fits it to obtain accurate linkage coefficients. The fitting method adopts the least squares method, using the noise and dose values ​​measured under multiple combinations of tube voltage and tube current as sample points, solving the regression parameters of the noise-dose characteristic curve, extracting the tube current adjustment coefficient corresponding to the tube voltage change from the regression curve, and storing it as a personalized linkage coefficient in the linkage model.

[0129] Step S602: Establish a matching table between slice thickness and reconstruction algorithm. The matching table is stored in the form of a two-dimensional lookup table, with row indexes representing slice thickness intervals, column indexes representing clinical preference options, and table entry values ​​being enumerated values ​​of recommended reconstruction algorithm types.

[0130] In thin-slice scanning scenarios, with a slice thickness ranging from 0.5mm to 1.5mm, iterative reconstruction algorithms are recommended to reduce the noise amplification effect caused by thin-slice reconstruction. Iterative reconstruction algorithms can suppress noise in thin-slice images while maintaining spatial resolution.

[0131] In thick-slice scanning scenarios, with slice thickness ranging from 3.0 mm to 10 mm, the filtered back-projection algorithm is recommended to achieve higher computational efficiency and image contrast. The filtered back-projection algorithm also offers faster reconstruction speeds in thick-slice reconstruction. In medium-slice-thickness scanning scenarios, with slice thickness ranging from 1.5 mm to 3.0 mm, the reconstruction algorithm can be flexibly selected based on clinical needs. The filtered back-projection algorithm is preferred when efficiency is paramount, while the iterative reconstruction algorithm is preferred when low dose is required.

[0132] Step S603: Establish a mathematical model relating the screw pitch and the scanning time. The scanning time is equal to the scanning range divided by the screw pitch and multiplied by the time required for the gantry to rotate one revolution. The calculation formula is as follows: ; in, This indicates the scan time, in seconds. The scan range is indicated in millimeters and is determined by clinical examination needs; typical values ​​range from 100 mm to 500 mm. This represents the pitch value, which is dimensionless. The rotation period is the time required for the gantry to rotate one revolution, measured in seconds. It is determined by the mechanical properties of the CT equipment, with a typical value of 0.35 seconds to 1.0 seconds.

[0133] When the user sets the target scan time Subsequently, the mathematical relationship model supports the reverse calculation of the required pitch value. The reverse calculation formula is as follows: ; Step S604: Establish a parameter linkage conflict detection function. When medical staff configure parameters, the parameter linkage conflict detection function automatically detects whether there is a conflict in the linkage relationship between the current parameter and other parameters. Taking the linkage between tube voltage and tube current as an example, after setting the tube voltage to a specific value, the parameter linkage conflict detection function calculates the theoretical range of tube current under the current tube voltage value according to the linkage relationship model in step S601, compares the current tube current value with the theoretical range, and determines that there is a conflict if it exceeds the range.

[0134] When a conflict is detected, a prompt message is sent to medical staff. The message includes the name of the conflicting parameter, its current value, and a suggested range. Medical staff can choose to accept the suggested value for automatic correction or retain the current value and record the conflict in the log. Parameter-linked conflict detection is completed before the configuration command is submitted to the intelligent verification engine.

[0135] Step S605: Construct the configuration history management module. After each parameter configuration operation is completed, the configuration history management module automatically records a complete log. Log data items include the configuration timestamp, operator ID and name, target CT device ID and installation location, a snapshot of parameter values ​​before configuration, a snapshot of parameter values ​​after configuration, the configuration operation type, and the configuration result status. Log data is stored in the security audit database using an append-only write method to ensure the authenticity and immutability of the records.

[0136] The configuration history management module provides a log query interface, supporting queries by time range, target CT device identifier, operator identifier, and parameter name. When abnormal image quality issues are detected, the parameter change sequence within the retrospective time window is obtained through the log query interface, and compared and analyzed with the timeline of the abnormal images to pinpoint the parameter configuration operation that caused the anomaly.

[0137] Step S606: Construct the parameter configuration permission management module. This module assigns different parameter configuration permissions based on the role and qualification level of medical personnel. Interns can only view the current parameter configuration status and cannot perform modification operations.

[0138] The attending physician can make routine parameter adjustments, including adjusting the tube voltage within ±10% of the current value, adjusting the tube current within ±20% of the current value, and adjusting the slice thickness within the selectable range. Routine adjustments do not require secondary confirmation.

[0139] The head of radiology has the authority to configure all parameters, including special configurations that exceed the normal adjustment range and the permission to modify constraint rules. Modification of constraint rules requires secondary authentication and recording of the reason for the modification. Permission verification is performed before the configuration command is issued, checking whether the current operator has the necessary permissions to modify the target parameters of the target device. If the permission verification passes, the configuration issuance process begins; if the permission verification fails, the configuration is rejected and an insufficient permission message is returned.

[0140] Through step S6, the parameter correlation modeling and supporting configuration management functions are completed. The tube voltage and tube current linkage model, the layer thickness and reconstruction algorithm matching table, and the pitch and scan time mathematical relationship model together constitute the coupling constraint rules between parameters. The parameter linkage conflict detection function automatically detects and prompts parameter conflicts before configuration submission. The configuration history management module provides operation auditing and anomaly backtracking capabilities. The parameter configuration permission management module controls the operation scope hierarchically according to roles.

[0141] These functions work in conjunction with steps S1 to S5, forming a complete technical solution for remote collaborative configuration of CT scan parameters for smart healthcare, from parameter model definition, security verification, protocol conversion, remote distribution, device execution to parameter coordination and operation management.

[0142] The remote collaborative configuration method for CT scan parameters of this invention demonstrates significant technical advantages and application value in practical applications. By constructing a unified parameter abstraction model layer, it achieves standardized description and management of parameters from different brands of CT equipment, providing a technical foundation for unified management of multi-brand equipment in medical institutions. By establishing a multi-dimensional parameter constraint rule base, it ensures the security and compliance of parameter configuration, effectively preventing equipment damage or patient radiation overdose risks caused by parameters exceeding limits. By developing a plug-in brand protocol conversion adapter, it solves the technical problem of poor interoperability caused by different brands of equipment using proprietary communication protocols, eliminating the need to modify core code when adding new brand support. By establishing a parameter correlation model, it achieves overall coordinated parameter configuration, avoiding scan quality problems caused by neglecting the coupling relationship between parameters when adjusting a single parameter. Through configuration history management and access control mechanisms, it provides complete data support for medical quality management and compliance auditing.

[0143] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.

[0144] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for remote collaborative configuration of CT scan parameters for smart healthcare, characterized in that, include: An abstract model layer for CT equipment parameters is constructed. This layer defines a hierarchical data structure and defines core scanning parameters, including tube voltage parameters, tube current parameters, exposure time parameters, slice thickness parameters, pitch parameters, and reconstruction algorithm parameters. It also specifies the value range and default values ​​of the core scanning parameters, thus forming a standardized parameter description system. Establish a parameter constraint rule base, which includes equipment physical limit rules, patient safety threshold rules, and clinical application guideline rules. The patient safety threshold rules include dose length multiplication accumulation limit and single CT dose index limit. The clinical application guideline rules define recommended rules for parameter configuration in different clinical scenarios. Develop a brand protocol conversion adapter. The brand protocol conversion adapter adopts a plug-in architecture, which encapsulates the private communication protocols of different brands of CT equipment into independent protocol conversion plug-ins. The protocol conversion plug-ins perform bidirectional conversion between standardized parameters and private protocol formats. Standardized configuration instructions are generated based on the CT equipment parameter abstract model layer. The standardized configuration instructions are then validated for compliance using a parameter constraint rule base. Finally, the brand protocol conversion adapter converts the validated standardized configuration instructions into configuration instructions in the target CT equipment's private protocol format before issuing them.

2. The remote collaborative configuration method for CT scan parameters for smart healthcare according to claim 1, characterized in that: The parameter constraint rule base also includes an intelligent verification engine, which checks each parameter configuration request in the order of device physical limit value verification, patient safety verification, and clinical guideline verification when the request is submitted. The logic of patient safety verification includes: extracting tube voltage parameters, tube current parameters, exposure time parameters and scan length from the parameter configuration request; automatically calculating the expected dose-length product value using the dose calculation model; comparing the expected dose-length product value with the dose-length product accumulation limit value; if the dose-length product accumulation limit value is exceeded, rejecting the parameter configuration request and returning a warning message to the operator terminal; the warning message carries the over-limit ratio, the current limit value and the expected value. The dose calculation model calculates the dose-length product by integral accumulation, and the dose-length product is equal to the integral of the volumetric CT dose index along the scanning axis. Patient safety verification also supports dose limit calculation based on body shape adaptive adjustment. It automatically calculates the corresponding personalized dose limit based on the patient's height and weight data, and replaces the dose length multiplied by the accumulator limit with the personalized dose limit for comparison.

3. The method for remote collaborative configuration of CT scan parameters for smart healthcare according to claim 1, characterized in that: Clinical application guidelines include adult scanning protocols categorized by examination site, pediatric scanning protocols categorized by age group, emergency scanning protocols, and routine physical examination scanning protocols. The adult scanning protocol uses a preset optimized parameter combination based on the examination site. The pediatric scanning protocol uses adult parameters multiplied by a dose reduction adjustment factor calculated based on the child's age and weight. The emergency scanning protocol uses a fixed parameter combination. The routine physical examination scanning protocol selects parameters within a preset range based on the examination site and the patient's body type.

4. The method for remote collaborative configuration of CT scan parameters for smart healthcare according to claim 1, characterized in that: The brand protocol conversion adapter performs both forward and reverse conversions; The forward conversion process includes: serializing the standardized parameter object to generate an intermediate data stream in a unified format; selecting the corresponding protocol conversion plugin according to the brand identifier of the target CT equipment; converting the intermediate data stream into a private format data frame according to the private protocol specification by the protocol conversion plugin; adding frame headers and check codes; and performing data format mapping, value range conversion and unit conversion during the forward conversion process. The reverse conversion process includes: receiving private format data frames reported by the receiving device, splitting the command code and data field according to the frame structure, decoding and restoring the original parameter values ​​according to the data encoding format, mapping the parameter values ​​to standardized parameter objects and filling them into the data model, and performing data verification, format verification and exception handling simultaneously during the reverse conversion process; The brand protocol conversion adapter internally maintains a brand protocol configuration mapping table. The brand protocol configuration mapping table records the list of parameters supported by each brand, the range of parameter values, the default value settings, and the parameter dependencies. The brand protocol configuration mapping table has a version management mechanism. When establishing a connection with a CT device, the brand protocol conversion adapter automatically performs protocol version negotiation, queries the protocol version currently running on the device, and selects a matching conversion strategy accordingly.

5. The remote collaborative configuration method for CT scan parameters for smart healthcare according to claim 1, characterized in that: Within the CT equipment parameter abstract model layer, parameter correlation modeling is performed, establishing a linkage model between tube voltage parameters and tube current parameters, a matching table between slice thickness parameters and reconstruction algorithm parameters, and a mathematical relationship model between pitch parameters and scanning time. The linkage model between tube voltage and tube current parameters follows the principle of constant radiation dose output, keeping the product of tube voltage and tube current parameters constant. The linkage model defines a proportionality coefficient that reduces tube current parameters by 15% to 20% for every 10kVp increase in tube voltage. The linkage model also adaptively adjusts according to the diagnostic quality requirements of the examination site. The typical tube voltage setting range for head scanning is 100kVp to 120kVp, for chest scanning it is 120kVp to 140kVp, and for abdominal scanning it is 110kVp to 130kVp. The matching table between slice thickness parameters and reconstruction algorithm parameters is stored in the form of a two-dimensional lookup table. The row index is the slice thickness range, the column index is the clinical priority option, and the table entry value is the recommended reconstruction algorithm type enumeration value. Among them, the iterative reconstruction algorithm is recommended when the slice thickness range is 0.5mm to 1.5mm, and the filtered back projection algorithm is recommended when the slice thickness range is 3.0mm to 10mm. The mathematical relationship model between pitch parameter and scanning time is defined as scanning time equal to scanning range divided by pitch and then multiplied by gantry rotation cycle. The mathematical relationship model between pitch parameter and scanning time supports the reverse calculation of the required pitch value based on the target scanning time.

6. The method for remote collaborative configuration of CT scan parameters for smart healthcare according to claim 5, characterized in that: A parameter linkage conflict detection function is constructed. When medical staff configure parameters, the parameter linkage conflict detection function calculates the theoretical range of tube current parameter under the current tube voltage parameter value based on the linkage relationship model between tube voltage parameter and tube current parameter, and compares the current tube current parameter value with the theoretical range. If it exceeds the theoretical range, a conflict is determined, and a prompt message is issued to the medical staff. The prompt message includes the name of the conflicting parameter, the current value, and the suggested value range. The parameter linkage conflict detection function is completed before the configuration command is submitted to the intelligent verification engine.

7. The method for remote collaborative configuration of CT scan parameters for smart healthcare according to claim 1, characterized in that: Standardized configuration instructions adopt a structured coding format and consist of an instruction header, parameter fields, and a check field. The instruction header includes the target device identifier, instruction type, and serial number. Instruction types include parameter setting instructions, parameter query instructions, parameter restore default instructions, and parameter batch execution instructions. The parameter field adopts the TLV encoding format. The parameter field consists of multiple TLV triples. Each TLV triple includes the parameter type identifier Type, the parameter value length Length, and the parameter value Value. The tube voltage parameter corresponds to the Type code 0x0101, the tube current parameter corresponds to the Type code 0x0102, the exposure time parameter corresponds to the Type code 0x0103, the layer thickness parameter corresponds to the Type code 0x0104, the pitch parameter corresponds to the Type code 0x0105, and the reconstruction algorithm parameter corresponds to the Type code 0x0106. The check field contains a cyclic redundancy check code calculated using the CRC-16-CCITT algorithm, which covers the complete data content of the instruction header and parameter field. The verification field also supports an optional digital signature field. The digital signature is obtained by generating a message digest through SHA-256 hashing and then signing the message digest using the sender's RSA-2048 or SM2 private key.

8. The method for remote collaborative configuration of CT scan parameters for smart healthcare according to claim 1, characterized in that: Deploy a device-side parsing and execution engine on the device side. The device-side parsing and execution engine supports incremental configuration mode and full configuration mode. In incremental configuration mode, the device-side parsing and execution engine only extracts the TLV triples that actually appear in the parameter field for parsing and processing, and keeps the current running value of the CT device unchanged for parameter items that are not carried. In full configuration mode, the device-side parsing and execution engine transmits a complete set of parameters, covering each of the current operating parameters of the CT device. The device-side parsing and execution engine performs packet fragmentation and frame boundary identification when receiving data. The frame start mark is 0xA5C3 and the frame end mark is 0xD63B. The device-side parsing and execution engine maintains a protocol mapping table locally. The protocol mapping table is indexed by the parameter type identifier Type and stores the mapping between standard parameter type identifiers and local parameter identifiers of the CT device. When the device-side parsing and execution engine performs parameter conversion, it performs parameter boundary checks. When the converted local parameter value exceeds the upper or lower limit of the parameter value range by less than 10%, the out-of-bounds value is truncated to the boundary value and the truncation log is recorded. When the excess exceeds 10%, the corresponding parameter item is rejected and an error message is returned to the sending end.

9. The method for remote collaborative configuration of CT scan parameters for smart healthcare according to claim 1, characterized in that: Build a configuration history management module and a parameter configuration permission management module; The configuration history management module automatically records the configuration timestamp, operator ID and name, target CT device ID and installation location, parameter value snapshot before configuration, parameter value snapshot after configuration, configuration operation type and configuration result status after each parameter configuration operation is completed. The log data is stored in the security audit database in an append-only write mode. The parameter configuration permission management module assigns parameter configuration permissions based on the roles and qualification levels of medical staff. Intern roles can only view the current parameter configuration status, attending physician roles can perform routine parameter adjustments, including adjusting tube voltage parameters within ±10% of the current value, tube current parameters within ±20% of the current value, and slice thickness parameters within the selectable range. Radiology department director roles can configure all parameters and modify constraint rules. Modification of constraint rules requires secondary authentication and recording of the reason for modification.

10. The method for remote collaborative configuration of CT scan parameters for smart healthcare according to claim 1, characterized in that: The reconstruction algorithm parameters include a deep learning iterative reconstruction algorithm. When the deep learning iterative reconstruction algorithm is selected in the configuration parameters, the CT device calls the pre-trained reconstruction model to complete the image reconstruction when performing the reconstruction step. The training data for the reconstruction model is obtained by collecting low-dose projection data generated by clinical CT scans and correspondingly acquiring high-dose, high-quality reconstructed images of the same location as the gold standard, forming a one-to-one registration training sample pair. The reconstruction model uses a deep convolutional neural network. The input is a noisy image reconstructed by backprojection after initial filtering, and the output is a clear image after denoising and detail restoration. The loss function is a weighted combination of mean squared error loss and perceptual loss. During training, the network weights are iteratively updated through error backpropagation to obtain the reconstruction model used for inference.

Images