Medical coma calculation model service platform and implementation method thereof

Abstract

The invention relates to the technical field of data management, in particular to a medical coma calculation model service platform and an implementation method thereof. The method comprises the following steps: collecting a multi-source historical medical data set, and executing structural consistency processing to obtain a basic data set; calculating the feature correlation degree and the distribution difference degree between the modes based on the basic data set, and establishing a feature mapping relationship corresponding to each mode; determining a node security boundary range of each data source by using the feature mapping relationship; inputting the feature mapping relation and the basic data set into a medical coma calculation model framework to train a medical coma calculation model; dividing the medical coma calculation model into a plurality of function containers, and setting an encryption cooperation mechanism between each function container and a data source link according to a node security boundary range; and uploading the function container with the encryption cooperation mechanism to a cloud platform to execute containerization deployment. According to the invention, the reliability and overall safety of medical data processing are enhanced.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to a medical intelligence computing model service platform and its implementation method. Background Technology

[0002] Medical data encompasses diverse and heterogeneous information from multiple sources, including electronic medical records, imaging data, genomic data, wearable device data, and various laboratory indicators. This data is characterized by high dimensionality, strong temporal sequence, complex structure, and privacy sensitivity. Current medical data processing and analysis methods primarily rely on single algorithms or traditional statistical methods, which struggle to effectively support the heterogeneity, massive volume, and real-time nature of the data.

[0003] Existing intelligent medical service platforms have the following shortcomings in practical applications: On the one hand, the platforms usually rely on discrete models or isolated algorithms and lack a unified computing framework across data sources and tasks, resulting in low efficiency in model training, deployment and updates, and an inability to adapt to the dynamic changes in clinical simulation scenarios; on the other hand, data security, privacy protection and compliance issues restrict data sharing and collaborative computing among multiple institutions and scenarios, hindering the improvement of model performance. Summary of the Invention

[0004] Based on this, it is necessary for the present invention to provide a medical intelligence computing model service platform and its implementation method to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, a method for implementing a medical intelligence computing model service platform includes the following steps: Step S1: Collect multi-source historical medical datasets and perform structural consistency processing on the multi-source historical medical data to obtain the basic dataset; Step S2: Based on the feature vectors of each modality in the basic dataset, calculate the feature correlation and distribution difference between modalities, and establish the feature mapping relationship corresponding to each modality; Step S3: Perform feature risk classification on each data source in the basic dataset using feature mapping relationships, and determine the node security boundary range of each data source based on the feature risk classification results; Step S4: Input the feature mapping relationship and basic dataset into the Medical Intelligence Computing Model Framework to train the Medical Intelligence Computing Model; Step S5: Divide the medical intelligence computing model into several functional containers, and set up an encrypted collaboration mechanism between each functional container and the data source link according to the node security boundary range; upload the functional containers with the encrypted collaboration mechanism set to the cloud platform for containerized deployment.

[0006] This application achieves multimodal fusion and intelligent parsing of text medical records, image frames, and physiological monitoring data by structuring, feature mapping, and risk classification of multi-source heterogeneous medical data. It effectively integrates data from different sources and formats, significantly improving the efficiency of model training and inference. After dividing the model into functional containers and combining node security boundaries and encrypted collaboration mechanisms, the platform can achieve data access and collaborative computing across multiple institutions and scenarios while ensuring data security and privacy, reducing the risk of data leakage and compliance costs. Through dynamic scheduling of computing resources and a mechanism for adjusting inference path deviations and latency deviations based on user feedback, the platform can continuously optimize model performance, improving the accuracy and response speed of diagnostic predictions. Furthermore, the multimodal feature mapping and risk control mechanism can identify and isolate abnormal features and high-risk nodes in real time, thereby enhancing the reliability of medical data processing and the overall security of the system. Overall, it achieves intelligent, efficient, secure, and sustainably optimized medical computing service capabilities.

[0007] Optionally, this application provides a medical intelligence computing model service platform for executing the medical intelligence computing model service platform implementation method described above. This medical intelligence computing model service platform includes: The data acquisition module is used to collect multi-source historical medical datasets and perform structural consistency processing on the multi-source historical medical data to obtain the basic dataset; The feature analysis module is used to calculate the feature correlation and distribution difference between modes based on the feature vectors of each mode in the basic dataset, and to establish the feature mapping relationship corresponding to each mode. The boundary determination module is used to perform feature risk classification on each data source in the basic dataset using feature mapping relationships, and to determine the node safety boundary range of each data source based on the feature risk classification results. The model training module is used to input the feature mapping relationship and the basic dataset into the Medical Intelligence Computing model framework to train the Medical Intelligence Computing model. The functional container deployment module is used to divide the medical intelligence computing model into several functional containers and set up an encrypted collaboration mechanism between each functional container and the data source based on the node security boundary; the functional containers with the encrypted collaboration mechanism set are then uploaded to the cloud platform for containerized deployment.

[0008] The medical intelligence computing model service platform of the present invention can implement any of the medical intelligence computing model service platform implementation methods of the present invention. It is used as a medium for connecting the operation and signal transmission between various modules to complete the medical intelligence computing model service platform implementation method. The modules within the platform cooperate with each other, thereby realizing intelligent, efficient, secure and continuously optimized medical intelligence computing service capabilities. Attached Figure Description

[0009] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating the steps of a method for implementing a medical intelligence computing model service platform according to the present invention. Figure 2 This is a schematic diagram illustrating an application scenario of an embodiment of this application; Figure 3 This is a schematic diagram of the modules of the TCM Wisdom Calculation Model Service Platform of the present invention; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

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

[0011] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0012] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0013] To achieve the above objectives, please refer to Figures 1 to 3 This invention provides a method for implementing a medical intelligence computing model service platform, the method comprising the following steps: Step S1: Collect multi-source historical medical datasets and perform structural consistency processing on the multi-source historical medical data to obtain the basic dataset; In this embodiment, a multi-source historical medical dataset, including historical electronic medical records, historical imaging examination reports, and historical physiological monitoring data, is collected from a regional medical data center. The spatial resolution of the imaging data is 512×512 pixels, the text records use UTF-8 encoding, and the time series data sampling frequency is 1Hz. Due to differences in the structure, fields, and timestamp formats of medical data from different sources, field alignment, timestamp standardization, and data redundancy removal are performed on each data source. During field alignment, the unified patient unique identifier from the historical electronic medical records is used as the primary key to perform inner join matching on the multi-source data tables. Timestamp standardization resamples time series data with different sampling frequencies to a unified time step. Redundancy removal is based on the Euclidean distance threshold between adjacent data within the time window. Perform deduplication to generate a basic dataset with a uniform format, providing consistent input for subsequent feature mapping calculations.

[0014] Step S2: Based on the feature vectors of each modality in the basic dataset, calculate the feature correlation and distribution difference between modalities, and establish the feature mapping relationship corresponding to each modality; In a further embodiment, the feature correlation and distribution difference between modalities are calculated based on the feature vectors of each modality in the basic dataset. Specifically, image edge feature vectors, including gray-level co-occurrence matrix, texture energy, and morphological boundary features, are extracted for image modalities; text semantic tag embedding vectors of diagnostic keywords are extracted for text modalities; and physiological monitoring time series vectors, including the moving average and fluctuation amplitude of parameters such as heart rate and blood oxygen, are extracted from historical physiological monitoring data. Using the feature vectors as input, the Pearson correlation coefficient r and the distribution difference index KL divergence are calculated between modalities. If r > 0.7 and KL divergence is less than 0.3 between two modalities, they are considered to have high mapping potential. Based on the above calculation results, the feature mapping relationship corresponding to each modality is determined.

[0015] Step S3: Perform feature risk classification on each data source in the basic dataset using feature mapping relationships, and determine the node security boundary range of each data source based on the feature risk classification results; In a further embodiment, feature risk classification is performed on each data source in the basic dataset based on the feature mapping relationship corresponding to each modality. A risk index is calculated based on the value range and frequency of occurrence of each feature. Subsequently, based on the risk index and the strength of the risk propagation path, features of different risk levels are divided into independent security boundary ranges on the data interaction nodes in the cloud platform. High-risk features are only allowed to be accessed within local nodes, medium-risk features are shared within edge nodes, and low-risk features can be encrypted and propagated within cloud nodes, thereby forming a hierarchical security protection node boundary range.

[0016] Step S4: Input the feature mapping relationship and basic dataset into the Medical Intelligence Computing Model Framework to train the Medical Intelligence Computing Model; In a further embodiment, the obtained feature mapping relationship is input into the Medical Intelligence Computing model framework for training. This model framework consists of an input feature layer, a feature fusion layer, a cognitive reasoning layer, and a risk discrimination layer. The feature fusion layer employs a multimodal cross-attention structure, mapping and fusing input features from different modalities through a weighted connection matrix. The cognitive reasoning layer constructs the logical path between pathological states and conclusions using hierarchical reasoning units. The risk discrimination layer outputs the risk confidence of each conclusion node. During the training phase, the feature mapping relationship is used as a multimodal feature alignment constraint in the Medical Intelligence Computing model training process, guiding the weight allocation and attention parameter initialization within the feature fusion layer. This ensures that different modal inputs have feature correspondence from the initial stage of model training, thereby avoiding feature drift caused by modal differences. Subsequently, 80% of the samples in the basic dataset are used for training, and 20% are used for validation. The iteration rounds are set to 100, the learning rate is 0.001, and the model parameters are updated using adaptive gradient descent. After training, the Medical Intelligence Computing model develops reasoning and risk judgment capabilities covering multimodal medical data.

[0017] Step S5: Divide the medical intelligence computing model into several functional containers, and set up an encrypted collaboration mechanism between each functional container and the data source link according to the node security boundary range; upload the functional containers with the encrypted collaboration mechanism set to the cloud platform for containerized deployment.

[0018] In a further embodiment, the trained medical intelligence computing model is divided into several functional containers, each corresponding to an independent functional unit within the model, such as a feature fusion subunit, a pathology reasoning subunit, and a risk output subunit. Based on the aforementioned node security boundary range, an encrypted collaborative mechanism is implemented for the communication channel between the containers and the data source: the transmission channel for high-risk features uses an asymmetric encryption method based on RSA-2048, medium-risk features use AES-256 symmetric encryption combined with a dynamic key update mechanism, and low-risk features use a SHA-512 digest verification anti-tampering mechanism. Before deployment, each functional container is verified for integrity through container signature verification. Subsequently, the configured functional containers are uploaded to the cloud platform, and containerized deployment and collaborative management are performed through Kubernetes orchestration strategies, enabling the model to achieve secure and controllable inference and decision-making computation in a multi-node environment.

[0019] Most importantly, the medical intelligence computing model is divided into several functional containers, including: Analyze the data flow and processing order of each computing unit in the medical intelligence computing model, and extract the bidirectional data dependency graph between each computing unit; In this embodiment, after training, the Medical Intelligence Computing Model forms a multi-layered reasoning structure consisting of an input feature layer, a feature fusion layer, a cognitive reasoning layer, and a risk discrimination layer. Therefore, the operational relationships between the various computational units within the model must first be systematically analyzed. By tracing the tensor transfer paths between the layers of the model, the input source and output target of each unit are recorded, and a directed connection table is established based on the time step and data flow direction. Subsequently, forward and reverse path matching is performed on all connection tables to ensure that the dependencies of input propagation and gradient backpropagation are consistent, thereby extracting a functional unit data dependency graph containing bidirectional edge relationships. Each node in the dependency graph represents a basic computational unit or feature fusion unit of the model. The edge weight is represented by the weighted average of data transmission volume and information gain, and the dependency strength is set between 0 and 1, serving as the basis for subsequent aggregation calculations.

[0020] It is worth noting that the computing units are the basic operational structures in the Medical Intelligence Computing Model that have independent data input and output interfaces, including but not limited to convolutional feature extraction units, attention weighting units, feature fusion transformation units, logical reasoning units, and risk assessment units. Each computing unit corresponds to a set of parameter weight matrices and nonlinear activation functions in the model, and is used to complete specific feature mapping, semantic aggregation, or reasoning judgment tasks. It is the smallest operational unit that constitutes the hierarchical relationship and reasoning path of the model.

[0021] The computational units in the bidirectional data dependency graph whose data dependency strength is higher than the preset dependency strength threshold are aggregated into the same initial functional container, and the output results of the initial functional container are determined. In a further embodiment, based on the established bidirectional data dependency graph, the dependency strength matrix between each computing unit is calculated, and computing unit pairs with dependency strength higher than the preset dependency strength threshold of 0.7 are selected. For these computing unit pairs, an aggregation operation is performed according to their data transmission direction and the degree of coupling between input and output features to combine them into an initial functional container. Each initial functional container contains at least one main processing unit and two or more auxiliary feature units to implement local semantic fusion or pathological risk calculation functions. During the aggregation process, the output result format of the container is determined by tracking the output interface of the last unit in the container. The output result is usually a high-dimensional embedding vector or a confidence matrix, serving as the standard interface data structure for interaction between containers.

[0022] By combining the output results of each initial functional container with the data dependency graph, a complete set of inference paths for the Medical Intelligence Computing Model is obtained. In a further embodiment, the output results of each initial functional container are remapped to the previously established data dependency graph, forming a container-level data transfer network. Then, using the connection sequences output by the containers as the main lines, all inference links from input features to risk output are extracted, thereby obtaining the complete inference path set of the medical intelligence computing model. This path set consists of multiple inference chains with different modal input combinations. The node sequence of each inference path is represented by a container index number, and the total number of paths is determined based on the number of task branches in the model during training. By comparing the frequency of calls between containers and the number of intermediate feature transfers in the path set, the participation level and importance of each container in the inference process can be determined.

[0023] The initial functional containers that are not in any reasoning path of the complete reasoning path set of the Medical Wisdom Computing Model are removed to obtain the functional container set.

[0024] In a further embodiment, if it is detected that certain initial functional containers do not appear in any path of the complete inference path set, and their output results are not referenced by other containers, then the container is determined to be an isolated functional unit and does not participate in the actual inference process of the medical intelligence computing model. To maintain the minimum closure of the system structure, such isolated containers are removed from the container set to form the final functional container set. The container set after removal corresponds to the effective inference unit distribution structure of the medical intelligence computing model, which can realize functional encapsulation based on path logic, and provide clear container boundaries and data transmission interfaces for the subsequent establishment of an encrypted collaboration mechanism based on the node security boundary range.

[0025] Figure 2 A schematic diagram of an application scenario 100 according to an embodiment of this application is shown. For example... Figure 2 The data source 102 can communicate with the model training system 104 through one or more network cloud platforms 106. The data source 102 may include business databases, image acquisition terminals, or physiological monitoring devices from multiple medical institutions, used to provide raw multi-source medical data to the cloud platform. The data source 102 can perform data format recognition and feature extraction locally, generating a structured dataset including feature mapping relationships 108 and node security boundary ranges 110. The feature mapping relationships 108 are used to represent the semantic associations and temporal mapping rules between multimodal data, and the node security boundary ranges 110 are used to describe the security access boundaries and risk isolation levels between different data nodes.

[0026] The model training system 104 is used to perform the construction, training, and inference tasks of the medical intelligence computing model. The medical intelligence computing model 112 in the model training system 104 is a multi-layered structured inference model, including an input feature layer, a feature fusion layer, a cognitive inference layer, and a risk discrimination layer, which can realize the fusion analysis of multimodal medical data and intelligent risk identification. During operation, the model training system 104 can receive structured data input from the data source 102 through the cloud platform 106 and perform data access verification according to the security boundaries and encryption collaboration strategies of each data node.

[0027] The cloud platform 106 is used to realize secure communication, task scheduling, and resource allocation between the data source 102 and the model training system 104. It can dynamically allocate computing resources to ensure the real-time performance and security of model inference tasks and data transmission. In some embodiments, the cloud platform 106 adopts a distributed container architecture, scheduling different levels of functional containers according to the sensitivity of the data source and the complexity of the model task, thereby realizing efficient medical intelligent computing model services.

[0028] In some embodiments, both the data source 102 and the model training system 104 may include one or more computing devices (not shown in the figures), such as medical information servers, image processing workstations, or smart terminals. The embodiments of this application are not limited to specific device types. Examples of one or more cloud platforms 106 may be deployed based on local area networks (LANs), wide area networks (WANs), or the Internet, and can achieve data connectivity via Ethernet, Wi-Fi, 5G, or other encrypted communication protocols to provide computing resource scheduling, secure data transmission, and remote model inference services. The Medical Intelligence Computing Model Service Platform of this embodiment, through the above-described architecture, achieves secure access, intelligent analysis, and risk adaptive optimization of multi-source medical data.

[0029] Optionally, after building the medical intelligence computing model service platform, it also includes: Receive data access requests from data sources and determine the functional container that matches the data access request through the Medical Intelligence Computing Model Service Platform; In this embodiment, when the Medical Intelligence Computing Model Service Platform is online and detects a data access request initiated by an external medical data source, the platform first parses the data header of the access request. The data header contains the data source's identity identifier, data type description, and transmission encryption digest. A matching search is performed in the platform's registry based on the identity identifier. If a match is successful, the target processing type corresponding to the data access request is determined based on the data type description. At this time, the platform's built-in function container scheduler is activated, and the function container description table is searched to match the function container corresponding to the data type. The function container description table is generated by dependency graph aggregation during the model partitioning phase, and each function container records the data input format, inference output type, and computation priority. After matching is completed, the platform establishes an initial mapping relationship between the function container and the data access request to prepare for subsequent credibility assessment and task scheduling.

[0030] The credibility of data access requests is determined based on the encrypted collaboration mechanism between the matching functional container and the data source link. In a further embodiment, the Medical Intelligence Computing Model Service Platform determines the trustworthiness of a data access request based on the encrypted collaboration mechanism between the matching functional container and the data source link. The platform calculates the encryption integrity value of the data source transmission packet by reading the encryption strategy (such as RSA-based asymmetric encryption or AES-256-based symmetric encryption) and collaboration strategy (such as gradient encryption sharing or secure multi-party computation) corresponding to the link relationship. If the checksum hash value of the data packet matches the key digest generated by the platform, the encryption verification is considered successful. Subsequently, the platform performs a comprehensive trustworthiness calculation based on three parameters: transmission delay, encryption integrity, and collaboration synchronization degree. For example, if the encryption integrity weight is 0.5, the collaboration synchronization degree weight is 0.3, and the transmission delay weight is 0.2, then the trustworthiness = 0.5 × integrity score + 0.3 × synchronization score + 0.2 × delay score. The trustworthiness score range is set to 0 to 1, and the default threshold is 0.7.

[0031] The system links the data source corresponding to the data access request with a credibility level higher than the preset credibility threshold with the matching functional container, and dynamically schedules the corresponding computing resources to execute data access and model inference tasks based on the current resource allocation of the Medical Wisdom Computing Model Service Platform.

[0032] In a further embodiment, when the credibility of a data access request exceeds a preset credibility threshold (0.7), the platform automatically authorizes the data source to establish a secure link with the matching functional container. After the link is established, the corresponding computing resources are scheduled according to the current cloud platform's resource allocation table. The scheduling rules dynamically allocate resources based on the computing priority of the functional container and the number of available GPU computing units: if the GPU load rate is detected to exceed 80%, a container migration mechanism is triggered to transfer the computing tasks of low-priority containers to backup nodes to ensure the real-time performance of critical inference containers. After scheduling is completed, the platform starts the data access task, inputting the access data into the functional container for inference computation in real time through the data flow relay layer. The results generated during the inference process are synchronously transmitted back through an encrypted collaboration mechanism to ensure that the entire data access and model inference process is executed in a trusted, isolated, and secure domain.

[0033] It's worth noting that the container priority is automatically calculated during the Medical Intelligence Computing model partitioning stage based on the functional container's position and dependency strength within the model's inference path. Specifically, it first analyzes the input dependency and output contribution of each functional container in the bidirectional data dependency graph. Input dependency reflects the container's dependence on upstream data, while output contribution reflects the container's significant impact on downstream inference results. The platform follows the formula: (in and The overall priority score is calculated using weighted coefficients of 0.7 and 0.3 respectively. Generally, risk-discriminating containers located at the end of the inference path and directly affecting the final judgment result of the model have the highest priority; while containers that only perform feature preprocessing or intermediate fusion calculations have relatively lower priority.

[0034] Optionally, after performing the data access and model inference tasks, the following may also be included: Obtain user feedback data returned from the data source, and compare the model inference path deviation and inference delay deviation between the user feedback data and the model inference results; In this embodiment, user feedback data is uploaded via medical terminals and includes key indicators such as the adoption rate of treatment suggestions, the prediction result deviation rate, and response latency. The timestamp field in the user feedback data is time-series aligned with the output logs corresponding to the model inference results, and a feedback data comparison set is constructed using the model inference path as a reference. The inference path consists of an input data feature layer, a functional container mapping layer, and an output logic layer, recording the complete inference route of each input sample in the model. The model inference path deviation is calculated by comparing the mapping differences between the user feedback data and the source data items in the inference path matrix. Bias with inference delay This provides data support for subsequent model calibration. The inference delay bias is calculated as the difference between the time from input to obtaining the inference result at the medical terminal and the estimated inference time during model inference.

[0035] If the model inference path deviation exceeds the preset path deviation threshold, iterative training and parameter updates will be performed on the medical intelligence computing model until the model inference path deviation is within the path deviation threshold. In a further embodiment, if the model inference path deviation obtained through comparison... Exceeding the preset path deviation threshold (For example If the path deviation is less than 0.15, iterative training and parameter updates of the medical intelligence computing model will be automatically triggered. During implementation, the training process uses historical inference records and user feedback data as the training sample set, employing path deviation as the main optimization objective function constraint, and dynamically correcting the parameter weight matrix in the model through a hierarchical parameter backpropagation mechanism. To ensure training convergence, a layer-by-layer gradient limiting method is used, limiting the step size of each weight update to the range of 0.001 to 0.005. After the update, the cosine similarity between the old and new path matrices of the model is compared. If the path deviation decreases to 0.15, the model will be considered for improvement. If the deviation is below the threshold, the iteration process is terminated; if it is still higher than the threshold, the next round of parameter updates is performed until the inference path deviation meets the preset standard.

[0036] If the inference delay deviation exceeds the preset delay deviation threshold, the computing resources corresponding to the matching functional container will be adjusted according to the current resource allocation of the Medical Wisdom Computing Model Service Platform in order to re-execute the data access and model inference tasks.

[0037] In another embodiment, if the inference delay deviation Exceeding the preset delay deviation threshold (For example If the timeout period is 150ms, the computing resources corresponding to the functional containers will be dynamically adjusted based on the current resource allocation table of the Medical Intelligence Computing Model Service Platform. During implementation, the resource scheduling module will be called to read the CPU utilization rate of each container. Memory usage and I / O latency Calculate the comprehensive resource load factor If a certain functional container A value higher than 0.8 indicates resource scarcity. The number of allocated cores on the corresponding compute nodes will be increased (e.g., from 4 cores to 6 cores) or the memory limit will be raised (e.g., from 8GB to 12GB) via the container orchestration control interface to improve the computational efficiency of the container for this function. After resource adjustments, the data access and model inference tasks will be re-executed, and the inference latency metric will be monitored again until the latency deviation ΔT falls back to the threshold. Within this range, adaptive optimization of model inference performance can be achieved.

[0038] Optionally, the structural consistency process in step S1 includes: The multi-source historical medical dataset was subjected to format recognition and divided into text-based medical record data, image frame data, and physiological monitoring data. In this embodiment, format recognition and classification are performed on multi-source historical medical datasets. Raw medical data from Hospital Information System (HIS), Picture Archiving and Communication System (PACS), and vital signs monitoring system are read through data access interfaces. To ensure the accuracy of format recognition, a structure recognition method based on rule templates and dictionary mapping is used to automatically determine the file header identifier, data field labels, and encoding format of each data sample. If the field labels conform to natural language text format (such as UTF-8 or GBK), it is determined to be text-based medical record data; if DICOM image identifiers and frame sequence information are detected, it is classified as image frame data; if it contains multi-dimensional time-series physiological parameters (such as ECG, BP, etc.), it is classified as physiological monitoring data. After classification, different types of data are stored in corresponding data channels to form a multimodal raw data partitioning structure to support subsequent feature extraction and semantic association analysis.

[0039] Perform pixel segmentation on the image frame data and extract edge features based on the pixel segmentation results; In this embodiment, if the image frame data is identified as a DICOM sequence, pixel segmentation is further performed to extract image edge features. A fixed-step two-dimensional sliding window (step s = 8 pixels) is used to divide the pixel region on each image frame, and the grayscale matrix of each segment is input into the Sobel operator-based edge response calculation module to extract gradient direction and intensity features. During the calculation process, values ​​below the edge threshold are processed. Pixel gradients are suppressed to eliminate background noise and irrelevant textures. After processing, the output edge feature data is stored in matrix form, with each frame corresponding to a set of edge feature tensors of size m×n×3, where m and n are the number of blocks in the image resolution. To ensure the continuity of feature extraction results, temporal smoothing is performed on the edge features of adjacent frames, so that the features have structural consistency in the sequence dimension, which facilitates subsequent semantic alignment.

[0040] The semantic descriptions of text-based medical record data are extracted in a hierarchical structure as the main modality semantic labels. Based on the main modality semantic labels, the edge features are semantically associated and matched with the noise-removed physiological monitoring data to obtain the basic dataset.

[0041] In a further embodiment, a medical terminology recognition model (using a BERT-Med pre-trained structure, fine-tuned with clinical corpus) is used to perform word segmentation and named entity recognition on medical record text, extracting key semantic units such as disease name, symptoms, medication information, and imaging conclusions. Subsequently, a semantic hierarchy tree is constructed based on the syntactic dependency graph, with symptom and lesion-related statements as the main nodes, generating a semantic tag set, where each tag corresponds to a specific clinical description. To enhance tag matching, each semantic tag is vectorized (vector dimension 512) as the embedded expression of the main modality semantic tag, providing a unified semantic space for subsequent cross-modal association. Semantic association matching is performed based on these semantic tags and the aforementioned image edge features and noise-removed physiological monitoring data. First, outlier removal and smoothing filtering are performed on the physiological monitoring data, and a time window is set. For values ​​exceeding the mean Physiological parameters within a certain range are removed to reduce monitoring noise interference. Subsequently, the processed time-series features and edge feature tensors are mapped to the semantic vector space, and the degree of matching between them and the semantic label vector is determined by calculating cosine similarity. When the similarity value... If a data fragment is found to have a strong semantic correlation with its corresponding semantic label, then the semantic matching results are considered to be integrated to generate a structured basic dataset, in which each sample record contains semantic labels, image edge features, and time-synchronized physiological monitoring features.

[0042] Optionally, step S2, calculating the feature correlation and distribution difference between modes, includes: Based on the feature vectors of each mode in the basic dataset, calculate the relative offset of the feature distribution centers between any two modes, and use this relative offset as the distribution difference degree; In this embodiment, for each modality's feature vector set, the modality feature center is calculated. Let the modality be... The set of feature vectors is , where each feature vector This indicates that the mode is in Numerical representation of the 3D feature space, This represents the number of samples for this modality. Calculate the feature centers for this modality. : As a mode The average eigenvector. Modality With mode The offset of the feature distribution center between them is defined as That is, the Euclidean distance is used to measure the relative positional difference of the means of two modal features.

[0043] The sample features of each modality in the base dataset are matched under the same time window, and the joint variance and covariance values ​​between the matched sample feature pairs are calculated to construct the inter-modal covariance matrix. In another embodiment, within the same time window The following steps involve matching sample features from different modalities to form a sample feature pair alignment matrix. Time-aligned image edge feature vectors, text semantic label embedding vectors, and physiological monitoring time series vectors are mapped one-to-one according to sample indices to form sample pairs. ,in and Representing modes With mode Calculate the joint variance of the sample pair from the eigenvectors within the given time window. and covariance .in This indicates the expectation value. The covariance values ​​of all mode pairs are organized into an inter-mode covariance matrix, where the row and column indices correspond to different modes, and the matrix elements... This is used to quantify the linear dependence strength of features between modes, providing a foundation for subsequent feature correlation calculations.

[0044] The feature correlation between modes is calculated based on the intermodal covariance matrix. If the feature correlation between modes is lower than the preset correlation threshold, sample feature pairs that are consistent with the semantic label of the main mode are reselected from the corresponding modes whose feature correlation is lower than the correlation threshold, and the feature correlation is recalculated until the feature correlation between each mode is greater than the correlation threshold.

[0045] In a further embodiment, the inter-modal feature correlation is calculated based on the inter-modal covariance matrix. ,in and Representing modes With mode The standard deviation vector length is used to normalize the covariance. In practice, if the correlation of a mode pair... If the correlation is below a preset threshold (e.g., 0.6), sample feature pairs that match the semantic labels of the main modality are reselected from the low-relevance modalities. During the reselection, the cosine similarity between the semantic label vector and the feature vector is used for screening, and sample pairs with a correlation greater than or equal to 0.85 are selected to recalculate the covariance and correlation until the feature correlation between each modality is greater than 0.85.

[0046] Optionally, establishing the feature mapping relationship corresponding to each modality in step S2 includes: Modal pairs with feature relevance higher than a relevance threshold are selected as candidate mapping pairs. Linear translation correction is then performed based on the distribution difference of the candidate mapping pairs until the distribution difference of the candidate mapping pairs is less than a preset difference threshold, thus obtaining distribution-aligned mode pairs. In this embodiment, mode pairs with a relevance higher than a preset relevance threshold of 0.85 are selected from the basic dataset as candidate mapping pairs. For each candidate mode pair... Obtain its feature mean vector and and distribution variability and based on Perform a linear translation correction operation. Specifically, linear translation correction involves translating the low-modality center vector in the feature space. The translation coefficient It can be dynamically adjusted, initially set to 0.5, with each iteration step being 0.1, until... The difference is less than the preset difference threshold of 0.15. This process ensures that candidate mode pairs tend to be consistent in statistical feature distribution, forming a distribution-aligned mode pair set.

[0047] Based on the inter-modal covariance matrix, feature correlation of distribution-aligned mode pairs is extracted, and a mapping weight function between modes is established based on the feature correlation. In a further embodiment, the feature correlation of each pair of distributed aligned modes is extracted based on the inter-modal covariance matrix. This is used to quantify the linear coupling strength between modes. Furthermore, feature correlation is used to construct an inter-modal mapping weight function. ,in Representing modes With all its candidate mapping modes The sum of coupling strengths. This weighting function will be used to control the contribution ratio of different modal features in the mapping process, so that highly coupled modalities occupy a higher weight in feature fusion or projection.

[0048] The edge features in the basic dataset and the physiological monitoring data are projected onto the corresponding semantic label range in the main modality semantic label on the time axis, and the projection position is adjusted based on the mapping weight function to obtain the feature mapping relationship corresponding to each modality.

[0049] In a further embodiment, the image edge features and physiological monitoring data in the base dataset are projected onto the time axis to the semantic label range corresponding to the main modality semantic label. For each time step... Image edge feature vector Physiological monitoring feature vector By mapping weight Adjust its projection position in the semantic tag vector space During the projection process, a time window is used. Perform sliding processing and handle outliers (those deviating more than 3 from the mean of the semantic label vector). A correction operation is performed to ensure the consistency between the projected features and the semantic label space of the main modality. Through the above steps, the feature mapping relationship corresponding to each modality is obtained.

[0050] Optionally, performing feature risk classification in step S3 includes: Based on the feature mapping relationship, the range of value fluctuation of each feature is detected, and features whose values ​​exceed the historical value range of the main modality semantic label are marked as abnormal candidate features; In this embodiment, fluctuation range detection is performed on each feature in the basic dataset based on the historical value range of the main modality semantic label. Specifically, a sliding window analysis is performed on the time series values ​​of each feature, with the window length set to [value missing]. The minimum, maximum, and mean values ​​within the statistical window are calculated and compared with the historical range of the corresponding main modality semantic label. If a feature value exceeds the upper or lower limit of the historical range, the feature is marked as an anomalous candidate feature, and the magnitude of the exceedance and the time point of occurrence are recorded. The historical range of the main modality semantic label refers to the range of historical values ​​for that feature value within the main modality semantic label.

[0051] Based on the consistency between the magnitude and frequency of abnormal candidate features in the time series and the values ​​of related mode pairs, and by performing weighted calculations according to a preset weighting ratio, a feature risk index is obtained. In a further embodiment, the frequency and average deviation of each anomalous candidate feature within the most recent 50 sampling points are statistically analyzed, and compared with the consistency of values ​​in related modal pairs, such as whether image edge features are synchronously abnormal with physiological monitoring data. A weighted score is calculated based on frequency, deviation, and consistency, where the weighting ratio can be set as follows: deviation 50%, frequency 30%, and consistency 20%. A feature risk index is obtained through weighted calculation, which is used to quantify the degree of risk that anomalous features may pose to model inference.

[0052] Based on the distribution of the characteristic risk index, interval stratification is performed, and the interval stratification results are used as the characteristic risk classification results.

[0053] In this embodiment, the risk index is divided into three intervals based on its numerical distribution: low risk (0–0.3), medium risk (0.3–0.6), and high risk (0.6–1.0). The boundaries of each interval can be dynamically adjusted according to the actual data distribution. The interval stratification results are used as the feature risk classification results and are referenced in subsequent node security boundary division and functional container encryption collaboration mechanism settings to guide the secure handling and priority scheduling of risk-sensitive features.

[0054] Optionally, determining the node security boundary range for each data source in step S3 includes: Detect the data interaction nodes of each data source in the cloud platform and extract the node behavior characteristics of the data interaction nodes; In this embodiment, data interaction nodes of each data source in the cloud platform are identified and detected. In this embodiment, data interaction nodes refer to the interface units that actually participate in data transmission and model invocation between each data source and the platform, including API gateways, data cache nodes, and message queue interfaces. Node behavior characteristics are extracted by monitoring indicators such as network connection logs, call frequency, and data packet size. The data transmission volume statistics window can be set every 5 minutes, and the node call frequency statistics window can be set every 10 minutes. Node behavior characteristics are used to characterize the node's activity level, data transmission volume, and abnormal call patterns over time.

[0055] The node's behavioral characteristics are compared with the risk classification results within the corresponding time window to calculate the node's risk response rate. In a further embodiment, the data feature vector processed by each node within the statistical window is associated with its corresponding feature risk level. The frequency of high-risk features processed by the node is counted, and the node risk response rate is calculated accordingly. The node risk response rate is defined as the proportion of the number of times a node processes high-risk features to the total number of times the node processes features. The statistical window length is set to the most recent 60 minutes, and the node risk response rate is exponentially smoothed to reduce the impact of occasional abnormal fluctuations.

[0056] The risk response rate of each node is compared with a preset response rate threshold to classify the risk level of the node. In a further embodiment, nodes are classified according to a preset response rate threshold. For example, nodes with a risk response rate higher than 0.7 are marked as high-risk nodes, those between 0.4 and 0.7 are marked as medium-risk nodes, and those below 0.4 are marked as low-risk nodes. The node risk level is used in subsequent risk propagation path analysis and security boundary delineation as a core reference for assessing node security and potential risk spread.

[0057] The node risk response rate is used to determine the strength of the risk propagation path between nodes, and the node security boundary range of each data source is divided according to the strength of the risk propagation path and the risk level of each node.

[0058] In a further embodiment, the risk propagation path strength between nodes is determined based on the node risk response rate. In this embodiment, the risk propagation path refers to the data flow path connecting two nodes. The path strength is calculated by the proportion of high-risk features transmitted along the path and the node risk level at the path endpoints (weighted at 0.6 for high-risk feature proportion and 0.4 for node risk level), and the statistical window is also the most recent 60 minutes. Based on the path strength and node risk level, the node security boundary range of each data source is divided, where high-risk nodes and their associated high-strength paths form a high-risk isolation zone, and low-risk nodes and their paths form a low-risk zone.

[0059] Of particular importance is defining the node security boundary range for each data source, including: If the intensity of any risk propagation path is higher than the preset path intensity threshold and the risk level of the endpoint nodes of the risk propagation path is high risk, then the risk propagation path is determined to be a high-risk propagation path, and the boundary area corresponding to the high-risk propagation path is designated as a high-risk isolation zone. In this embodiment, the risk propagation path refers to the actual data flow link from one node to another in the cloud platform. The path strength is obtained by comprehensively evaluating the proportion of high-risk features transmitted along the path and the risk level of the nodes, with the statistical window being the most recent 60 minutes. When the path strength of any risk propagation path exceeds a preset path strength threshold (e.g., set to 0.7), and the risk levels of the nodes at both ends of the path are both high-risk, the path is determined to be a high-risk propagation path, and the nodes involved in the path and their adjacent network areas are designated as high-risk isolation zones. Data transmission within the isolation zone requires mandatory encryption and strict access control, while functional container scheduling will prioritize resource isolation to prevent the spread of high-risk features.

[0060] If the intensity of any risk propagation path is less than or equal to the preset path intensity threshold and the risk level of the endpoint nodes of the risk propagation path is low risk, then the risk propagation path is determined to be a low-risk propagation path, and the boundary area corresponding to the low-risk propagation path is designated as a low-risk isolation zone. In a further embodiment, if the path strength of any risk propagation path is less than or equal to a preset path strength threshold (e.g., set to 0.3), and the risk levels of both ends of the path are low-risk, then the path is determined to be a low-risk propagation path, and the nodes involved in the path and their adjacent areas are designated as low-risk isolation zones. Low-risk isolation zones can support more flexible data interaction and containerized deployment, while maintaining a high degree of sharing in the allocation of computing resources to improve model inference efficiency.

[0061] The node security boundary range is determined based on the coverage relationship between the high-risk isolation zone and the low-risk isolation zone of each data source.

[0062] In a further embodiment, integration is performed based on the spatial coverage relationship between each isolation zone and the region to which the node belongs. Specifically, if a node is simultaneously located within the coverage areas of both high-risk and low-risk isolation zones, it is included in the high-risk isolation zone to prioritize security control. The node security boundary range for each data source is formed based on the coverage relationship of the isolation zones. This boundary guides the configuration of the encryption collaboration mechanism for functional containers, the scheduling of computing resources, and the restriction of data flows with high-risk characteristics, achieving full-platform security isolation and risk control.

[0063] Optionally, the cryptographic coordination mechanism between each functional container and the data source link in step S4 includes: Determine the link relationship between the functional container and the data source, and select the corresponding encryption strategy for the link relationship based on the node security boundary range; In this embodiment, the functional container refers to the divided medical intelligence computing model unit, with each functional container corresponding to a specific inference task and output result; the data source includes electronic medical record databases, image storage systems, and real-time data collected by wearable devices. First, the access information of each data source is read, including node address, access protocol, and historical interaction frequency, and matched with the inference task requirements of the functional container to establish a preliminary functional container-data source link relationship. Operational parameters considered during the matching process include data access frequency thresholds (e.g., a maximum of 100 accesses per second) and transmission bandwidth limits (e.g., no more than 500Mbps) to ensure that the link meets both data flow requirements and platform resource load. When selecting an encryption strategy, this embodiment implements it according to the node security boundary range and data sensitivity level. When the node is located in a high-risk isolation zone and the data sensitivity level is high, end-to-end encryption (e.g., AES-256) and transport layer security protocols (TLS 1.3) are preferred; for low-risk nodes and low-sensitivity data, symmetric encryption (e.g., AES-128) can be used to improve transmission efficiency. Operational parameters may include the key update cycle (e.g., every 30 minutes) and the maximum allowed data packet size (e.g., 1MB) to balance security and system performance.

[0064] Based on the sensitivity of the collected data corresponding to the data source and the sensitivity of the inference results of the functional container, the corresponding collaboration strategy for the link relationship is selected, and the communication channels of each functional container are set according to the encryption strategy and the collaboration strategy.

[0065] In a further embodiment, the sensitivity of the data collected from the data source and the sensitivity of the inference results from the functional containers are considered to determine whether a multi-party secure computation or homomorphic encryption collaboration mechanism is needed. For example, for critical diagnostic data and pathological inference conclusions, a federated computation collaboration mode is enabled, allowing each functional container to perform computation locally and only uploading encrypted intermediate results to ensure privacy. The operational parameters of the collaboration strategy include the number of federated training rounds (e.g., 10 rounds) and the local model update threshold (e.g., uploading updates only when model parameter changes exceed 0.01), ensuring computational validity and security. Based on the selected encryption and collaboration strategies, a dedicated communication channel is configured for each functional container. This channel establishes a secure tunnel with the data source node through the container's internal network interface, supporting bidirectional data transmission, encrypted authentication, and access control. Operational parameters may include the communication port range (e.g., port 40000–40100), the maximum number of concurrent connections (e.g., 10 concurrent connections), and the minimum transmission latency requirement (e.g., less than 50ms), thereby achieving a secure, reliable, and efficient communication environment between the functional containers and the data source.

[0066] It is worth noting that the sensitivity of data collected from data sources is typically determined by classifying the data type, privacy level, and potential risk of leakage. For example, electronic medical record text and genomic data are considered high-sensitivity data, imaging data are considered medium-sensitivity data, and equipment environmental monitoring data are considered low-sensitivity data. Sensitivity scores (e.g., 1–5 points, with 1 being the lowest and 5 the highest) can be assigned to each type of data based on historical usage guidelines, legal and regulatory requirements, and data anonymization procedures. The sensitivity of functional container inference results is assessed based on the clinical importance of the output information, its impact on decision-making, and potential privacy risks. For example, risk assessment results that directly affect decision-making are labeled as high-sensitivity, while outputs used only for statistical analysis or trend prediction can be labeled as low-sensitivity. Sensitivity assessment can be comprehensively determined by combining the confidence distribution of the model output, the number of associated patient information, and the identifiability of the prediction results, ultimately yielding a numerical value or level to guide the selection of encryption and collaboration strategies.

[0067] Please see Figure 3 This application provides a medical intelligence computing model service platform 200, used to execute the medical intelligence computing model service platform implementation method described above. The medical intelligence computing model service platform includes: The data acquisition module 201 is used to acquire multi-source historical medical datasets and perform structural consistency processing on the multi-source historical medical data to obtain the basic dataset; Feature analysis module 202 is used to calculate the feature correlation and distribution difference between modes based on the feature vectors of each mode in the basic dataset, and to establish the feature mapping relationship corresponding to each mode; The boundary determination module 203 is used to perform feature risk classification on each data source in the basic dataset using feature mapping relationships, and to determine the node safety boundary range of each data source based on the feature risk classification results. The model training module 204 is used to input the feature mapping relationship and the basic dataset into the Medical Intelligence Computing Model Framework to train the Medical Intelligence Computing Model. The functional container deployment module 205 is used to divide the medical intelligence computing model into several functional containers and set up an encrypted collaboration mechanism between each functional container and the data source based on the node security boundary; the functional containers with the encrypted collaboration mechanism set are uploaded to the cloud platform for containerized deployment.

[0068] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0069] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A method for implementing a medical intelligence computing model service platform, characterized in that, Includes the following steps: Step S1: Collect multi-source historical medical datasets and perform structural consistency processing on the multi-source historical medical data to obtain the basic dataset; Step S2: Based on the feature vectors of each modality in the basic dataset, calculate the feature correlation and distribution difference between modalities, and establish the feature mapping relationship corresponding to each modality; Step S3: Perform feature risk classification on each data source in the basic dataset using feature mapping relationships, and determine the node security boundary range of each data source based on the feature risk classification results; Step S4: Input the feature mapping relationship and basic dataset into the Medical Intelligence Computing Model Framework to train the Medical Intelligence Computing Model; Step S5: Divide the medical intelligence computing model into several functional containers, and set up an encrypted collaboration mechanism between each functional container and the data source link according to the node security boundary range; upload the functional containers with the encrypted collaboration mechanism set to the cloud platform for containerized deployment.

2. The method for implementing a medical intelligence computing model service platform according to claim 1, characterized in that, After building the Medical Intelligence Computing Model Service Platform, it also includes: Receive data access requests from data sources and determine the functional container that matches the data access request through the Medical Intelligence Computing Model Service Platform; The credibility of data access requests is determined based on the encrypted collaboration mechanism between the matching functional container and the data source link. The system links the data source corresponding to the data access request with a credibility level higher than the preset credibility threshold with the matching functional container, and dynamically schedules the corresponding computing resources to execute data access and model inference tasks based on the current resource allocation of the Medical Wisdom Computing Model Service Platform.

3. The method for implementing a medical intelligence computing model service platform according to claim 2, characterized in that, After performing the data access and model inference tasks, the following also includes: Obtain user feedback data returned from the data source, and compare the model inference path deviation and inference delay deviation between the user feedback data and the model inference results; If the model inference path deviation exceeds the preset path deviation threshold, iterative training and parameter updates will be performed on the medical intelligence computing model until the model inference path deviation is within the path deviation threshold. If the inference delay deviation exceeds the preset delay deviation threshold, the computing resources corresponding to the matching functional container will be adjusted according to the current resource allocation of the Medical Wisdom Computing Model Service Platform in order to re-execute the data access and model inference tasks.

4. The method for implementing a medical intelligence computing model service platform according to claim 1, characterized in that, The structural consistency process in step S1 includes: The multi-source historical medical dataset was subjected to format recognition and divided into text-based medical record data, image frame data, and physiological monitoring data. Perform pixel segmentation on the image frame data and extract edge features based on the pixel segmentation results; The semantic descriptions of text-based medical record data are extracted in a hierarchical structure as the main modality semantic labels. Based on the main modality semantic labels, the edge features are semantically associated and matched with the noise-removed physiological monitoring data to obtain the basic dataset.

5. The method for implementing a medical intelligence computing model service platform according to claim 1, characterized in that, Step S2, which calculates the feature correlation and distribution difference between modes, includes: Based on the feature vectors of each mode in the basic dataset, calculate the relative offset of the feature distribution centers between any two modes, and use this relative offset as the distribution difference degree; The sample features of each modality in the base dataset are matched under the same time window, and the joint variance and covariance values ​​between the matched sample feature pairs are calculated to construct the inter-modal covariance matrix. The feature correlation between modes is calculated based on the intermodal covariance matrix. If the feature correlation between modes is lower than the preset correlation threshold, sample feature pairs that are consistent with the semantic label of the main mode are reselected from the corresponding modes whose feature correlation is lower than the correlation threshold, and the feature correlation is recalculated until the feature correlation between each mode is greater than the correlation threshold.

6. The method for implementing a medical intelligence computing model service platform according to claim 1, characterized in that, Step S2, establishing the feature mapping relationship for each modality, includes: Modal pairs with feature relevance higher than a relevance threshold are selected as candidate mapping pairs. Linear translation correction is then performed based on the distribution difference of the candidate mapping pairs until the distribution difference of the candidate mapping pairs is less than a preset difference threshold, thus obtaining distribution-aligned mode pairs. Based on the inter-modal covariance matrix, feature correlation of distribution-aligned mode pairs is extracted, and a mapping weight function between modes is established based on the feature correlation. The edge features in the basic dataset and the physiological monitoring data are projected onto the time axis to the corresponding semantic label range in the main modality semantic label, and the projection position is adjusted based on the mapping weight function to obtain the feature mapping relationship corresponding to each modality.

7. The method for implementing a medical intelligence computing model service platform according to claim 1, characterized in that, Step S3 involves performing feature risk grading, including: Based on the feature mapping relationship, the range of value fluctuation of each feature is detected, and features whose values ​​exceed the historical value range of the main modality semantic label are marked as abnormal candidate features; Based on the consistency between the magnitude and frequency of abnormal candidate features in the time series and the values ​​of related mode pairs, and by performing weighted calculations according to a preset weighting ratio, a feature risk index is obtained. Based on the distribution of the characteristic risk index, interval stratification is performed, and the interval stratification results are used as the characteristic risk classification results.

8. The method for implementing a medical intelligence computing model service platform according to claim 1, characterized in that, Step S3, which determines the node security boundary range for each data source, includes: Detect the data interaction nodes of each data source in the cloud platform and extract the node behavior characteristics of the data interaction nodes; The node's behavioral characteristics are compared with the risk classification results within the corresponding time window to calculate the node's risk response rate. The risk response rate of each node is compared with a preset response rate threshold to classify the risk level of the node. The node risk response rate is used to determine the strength of the risk propagation path between nodes, and the node security boundary range of each data source is divided according to the strength of the risk propagation path and the risk level of each node.

9. The method for implementing a medical intelligence computing model service platform according to claim 1, characterized in that, Step S4 involves setting up an encrypted collaboration mechanism between each functional container and the data source link, including: Determine the link relationship between the functional container and the data source, and select the corresponding encryption strategy for the link relationship based on the node security boundary range; Based on the sensitivity of the collected data corresponding to the data source and the sensitivity of the inference results of the functional container, the corresponding collaboration strategy for the link relationship is selected, and the communication channels of each functional container are set according to the encryption strategy and the collaboration strategy.

10. A medical intelligence computing model service platform, characterized in that, For executing the medical intelligence computing model service platform implementation method as described in claim 1, the medical intelligence computing model service platform includes: The data acquisition module is used to collect multi-source historical medical datasets and perform structural consistency processing on the multi-source historical medical data to obtain the basic dataset; The feature analysis module is used to calculate the feature correlation and distribution difference between modes based on the feature vectors of each mode in the basic dataset, and to establish the feature mapping relationship corresponding to each mode. The boundary determination module is used to perform feature risk classification on each data source in the basic dataset using feature mapping relationships, and to determine the node safety boundary range of each data source based on the feature risk classification results. The model training module is used to input the feature mapping relationship and the basic dataset into the Medical Intelligence Computing model framework to train the Medical Intelligence Computing model. The functional container deployment module is used to divide the medical intelligence computing model into several functional containers and set up an encrypted collaboration mechanism between each functional container and the data source based on the node security boundary; the functional containers with the encrypted collaboration mechanism set are then uploaded to the cloud platform for containerized deployment.

Images