A method for real-time processing of heterogeneous medical data sources based on distributed deployment

Abstract

This invention discloses a real-time processing method for heterogeneous medical data sources based on distributed deployment, relating to the field of edge computing technology. The method includes: distributing standardized FHIR resource data streams to target edge computing nodes according to routing allocation instructions; launching lightweight medical data processing containers on the target edge computing nodes; performing multimodal clinical analysis for different clinical manifestations and dynamically switching analysis paths to generate analysis results; and synchronizing the analysis results to clinician terminal devices and hospital data centers via a distributed message bus on the target edge computing nodes. The analysis paths include a rapid response path for critical care, a research-level image depth analysis path, and an emergency multimodal collaborative path. This invention utilizes a shared syntax tree protocol conversion model, constructing an abstract syntax tree static structure based on protocol definition documents, to achieve field mapping and automatic alignment between source protocol nodes and target FHIR protocol nodes.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, and in particular to a method for real-time processing of heterogeneous medical data sources based on distributed deployment. Background Technology

[0002] With the continuous development of medical informatization and intelligentization, multi-source heterogeneous medical data is generated during clinical diagnosis and treatment, including data streams from imaging equipment, monitors, testing equipment, and wearable devices. This data has real-time requirements in the temporal dimension, distributed characteristics in the spatial dimension, and differences in protocol formats, data structures, and expression methods at the semantic level. To achieve cross-device and cross-scenario data sharing and interoperability, medical information standardization has gradually gained importance. FHIR, as a new generation of medical information exchange standard, has attracted widespread attention due to its resource-based, scalable, and streaming processing support characteristics. However, how to achieve real-time access, standardized conversion, and distributed processing of heterogeneous medical data at the edge still requires the collaborative advancement of technologies such as network computing architecture and data semantic parsing.

[0003] In existing research and applications, the access of heterogeneous medical devices typically relies on predefined protocol adapters or interface frameworks. This approach may suffer from low adaptation efficiency and insufficient conversion flexibility when facing new medical devices or complex multimodal data scenarios. Furthermore, during cross-node transmission and processing, data flow may be affected by differences in node load and geographical distribution, impacting real-time performance and resource utilization efficiency. To address the issues of protocol identification and semantic conversion, existing technologies generally rely on establishing protocol adaptation plugins or template-based semantic mapping to overcome interoperability barriers caused by protocol diversity. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a method for real-time processing of heterogeneous medical data sources based on distributed deployment to solve the problems of low adaptation efficiency and insufficient conversion flexibility.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] This invention provides a method for real-time processing of heterogeneous medical data sources based on distributed deployment, comprising:

[0008] Establish medical device access interfaces on distributed edge computing nodes to receive raw medical device data streams sent by medical devices. By analyzing the time interval and payload length characteristics of the raw medical device data streams, match them with a pre-set device protocol fingerprint database to generate device type identifiers.

[0009] The device type identifier and the original medical device data stream are input into the shared syntax tree protocol conversion model. The corresponding syntax tree conversion rule is called according to the device type identifier. The syntax tree node automatic alignment mechanism of the syntax tree conversion rule is used to convert the original medical device data stream into a standardized FHIR resource data stream.

[0010] Using the physical location parameters and resource load parameters of edge computing nodes, a distributed routing decision is performed on the standardized FHIR resource data stream to generate a routing allocation instruction; the routing allocation instruction includes a unique location identifier of the target edge computing node;

[0011] According to the routing allocation instructions, the standardized FHIR resource data stream is distributed to the target edge computing node. A lightweight medical data processing container is launched on the target edge computing node to perform multimodal clinical analysis for different clinical manifestations, dynamically switch analysis paths, and generate analysis results. The analysis results are synchronized to the clinician terminal device and the hospital data center through the distributed message bus of the target edge computing node. The analysis paths include a rapid response path for critical care, a research-grade image depth analysis path, and an emergency multimodal collaborative path.

[0012] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the step of establishing a medical device access interface on the distributed edge computing node to receive the raw medical device data stream sent by the medical device specifically involves:

[0013] Establish medical device access interfaces on distributed edge computing nodes;

[0014] The system continuously receives a sequence of data packets from medical devices through the medical device access interface. The data packet sequence is arranged in chronological order to form the original medical device data stream.

[0015] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, wherein: the generation of the device type identifier specifically refers to...

[0016] Capture continuous medical data packets in the original medical device data stream and extract the time interval values ​​between adjacent medical data packets as time interval features;

[0017] The payload portion of each medical data packet in the original medical device data stream is measured to obtain the payload byte length value, which is used as the payload length feature.

[0018] The time interval feature and the load length feature are combined into a medical feature vector group;

[0019] The medical feature vector group is compared one by one with the medical standard feature combination stored in the device protocol fingerprint database;

[0020] If, during the comparison process, it is found that the matching degree between the medical feature vector group and a certain medical standard feature combination is completely consistent, then the protocol type identification is confirmed to be successful.

[0021] Based on the successfully identified protocol type, the system searches the preset encoding rule mapping table and obtains the corresponding unique encoded string as the device type identifier.

[0022] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the payload portion is the data content of the actual medical data after removing header information, check bits, and protocol control fields.

[0023] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the device protocol fingerprint database is a database that stores combinations of medical standard features and corresponding medical device protocol type identifiers.

[0024] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the step of inputting the device type identifier and the original medical device data stream into a shared syntax tree protocol conversion model, and calling the corresponding syntax tree conversion rule according to the device type identifier, specifically involves...

[0025] Input the device type identifier and the raw medical device data stream into the shared syntax tree protocol conversion model;

[0026] The shared syntax tree protocol conversion model searches for the corresponding syntax tree conversion rule in the preset syntax tree rule mapping table based on the device type identifier, and obtains the mapping relationship between the source protocol node structure and the target protocol node structure defined in the syntax tree conversion rule.

[0027] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the shared syntax tree protocol conversion model is a processing framework built on an abstract syntax tree framework, which includes multiple abstract syntax trees, field mapping rules and a preset syntax tree rule mapping table, and is used to perform structured conversion from source protocol to target protocol.

[0028] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the step of converting the original medical device data stream into a standardized FHIR resource data stream specifically involves:

[0029] The medical data fields in the original medical device data stream are structurally aligned according to the mapping relationship to form an aligned medical data structure.

[0030] The aligned medical data structure is encapsulated in the FHIR standard to generate medical data entries that conform to FHIR resources;

[0031] All medical data entries that conform to FHIR resources are organized in chronological order by timestamp to form a standardized FHIR resource data stream.

[0032] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the generation of routing allocation instructions specifically includes:

[0033] Obtain the physical location parameters and resource load parameters of the edge computing nodes;

[0034] Based on physical location parameters and resource load parameters, a distributed routing decision is performed on the standardized FHIR resource data stream;

[0035] During the distributed routing decision-making process, medical service types and clinical urgency priorities are extracted from the standardized FHIR resource data stream;

[0036] Match the medical service types with the preset latency mapping table to determine the corresponding data transmission latency requirements;

[0037] The clinical emergency priority is matched with a pre-defined quality grading table to determine the corresponding quality grade;

[0038] Based on data transmission latency requirements, candidate edge computing nodes whose physical location parameters meet the distance threshold are selected;

[0039] Among the candidate edge computing nodes that meet the distance threshold, available edge computing nodes with resource load parameters lower than the load capacity threshold are selected according to the quality level requirements.

[0040] From the selected available edge computing nodes, select the available edge computing node with the lowest resource load parameter as the target edge computing node;

[0041] Write the unique location identifier of the target edge computing node into the routing assignment instruction structure to complete the construction of the routing assignment instruction.

[0042] As a preferred embodiment of the real-time processing method for heterogeneous medical data sources based on distributed deployment described in this invention, the step of performing multimodal clinical analysis for different clinical manifestations specifically includes:

[0043] Vital signs data, medical imaging data, and clinical text data are extracted from the standardized FHIR resource data stream as multimodal input data;

[0044] Feature extraction is performed on multimodal input data to identify critical illness features, imaging abnormalities, and emergency core terms;

[0045] For critical illness characteristics, a rapid response path for critical illness is selected, a vital sign threshold comparison operation is performed, and a critical illness early warning report is generated; for abnormal imaging characteristics, a research-grade image depth analysis path is selected, an image edge detection and region growing segmentation operation is performed, and an image analysis report is output; for critical illness characteristics, abnormal imaging characteristics, and emergency core terms, an emergency multimodal collaboration path is selected, a multi-source data rule matching operation is performed, and an emergency collaborative analysis report is generated.

[0046] The beneficial effects of this invention are as follows: By using a shared syntax tree protocol conversion model, an abstract syntax tree static structure is constructed based on the protocol definition document. Combined with the device type identifier to call the corresponding conversion rules, the field mapping and automatic alignment of the source protocol node and the target FHIR protocol node are realized without relying on the dynamic training process. This avoids the dependence of traditional models on a large amount of labeled data and continuous parameter tuning, ensuring the determinism and timeliness of protocol conversion. Furthermore, by directly guiding the structural reorganization and format encapsulation of the original medical data stream through a preset field mapping relationship table, the accuracy and consistency of the conversion of multi-source heterogeneous medical data to standardized FHIR resources are effectively improved, ensuring the high efficiency and reliability of data interoperability between clinical systems. Attached Figure Description

[0047] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a flowchart illustrating a real-time processing method for heterogeneous medical data sources based on distributed deployment.

[0049] Figure 2 A flowchart for generating device type identifiers.

[0050] Figure 3 This is a flowchart of protocol conversion and routing decisions.

[0051] Figure 4 This is a flowchart for multimodal clinical analysis. Detailed Implementation

[0052] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0053] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0054] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0055] Reference Figures 1-4 This is one embodiment of the present invention, which provides a method for real-time processing of heterogeneous medical data sources based on distributed deployment, including the following steps:

[0056] S1. Establish a medical device access interface on the distributed edge computing node to receive the raw medical device data stream sent by the medical device. By analyzing the time interval characteristics and payload length characteristics of the raw medical device data stream, match it with the pre-set device protocol fingerprint library to generate a device type identifier.

[0057] Establish medical device access interfaces on distributed edge computing nodes;

[0058] The medical device access interface enables three physical connection channels: Ethernet port, wireless communication component, and dedicated data cable for medical devices.

[0059] The system continuously receives a sequence of data packets from medical devices through the medical device access interface. The data packet sequence is arranged in chronological order to form the original medical device data stream.

[0060] Capture continuous medical data packets in the original medical device data stream and extract the time interval values ​​between adjacent medical data packets as time interval features;

[0061] The payload portion of each medical data packet in the original medical device data stream is measured (i.e., the length of the byte sequence is determined by reading the byte sequence of the payload portion of the medical data packet and using a byte counting tool), and the payload byte length value is obtained as the payload length feature; where the payload portion refers to the data content of the medical data packet after removing header information, check bits and protocol control fields from the actual medical data.

[0062] The time interval feature and the load length feature are combined into a medical feature vector group;

[0063] The medical feature vector groups are compared one by one with the medical standard feature combinations stored in the device protocol fingerprint database; among them, the medical standard feature combinations correspond one-to-one with the known medical device protocol types.

[0064] The process of comparing the medical feature vector group with the medical standard feature combinations stored in the device protocol fingerprint database one by one is as follows: The first medical standard feature combination is retrieved from the device protocol fingerprint database. It is then checked whether the time interval feature of the medical feature vector group is the same as that of the first medical standard feature combination, and whether the load length feature of the medical feature vector group is the same as that of the first medical standard feature combination. If both the time interval and load length features are the same, a successful match is determined. If the time interval or load length features are different, the second medical standard feature combination is retrieved from the device protocol fingerprint database. The process is repeated, checking whether the time interval and load length features of the medical feature vector group are the same as those of the second medical standard feature combination. If both the time interval and load length features are the same, a successful match is determined. If the time interval or load length features are different, the next medical standard feature combination is retrieved from the device protocol fingerprint database, and the process of checking whether the time interval and load length features are the same is repeated until a successfully matched medical standard feature combination is found or all medical standard feature combinations in the device protocol fingerprint database have been traversed.

[0065] It should be noted that the device protocol fingerprint database construction process is as follows: raw medical device data streams are collected from various medical devices, data packet extraction time interval and payload length features are captured, combined into medical standard feature combinations, a unified format protocol type identifier is assigned, and stored in the database to form the device protocol fingerprint database; raw medical device data streams are periodically collected from newly connected medical devices, time interval features and payload length features are extracted, new medical standard feature combinations are generated, and the device protocol fingerprint database is updated.

[0066] If, during the comparison process, it is found that the matching degree between the medical feature vector group and a certain medical standard feature combination is completely consistent, then the protocol type identification is confirmed to be successful.

[0067] Based on the successfully identified protocol type, the system searches the preset encoding rule mapping table to obtain the corresponding unique encoded string as the device type identifier. The device type identifier is a string encoding in a unified format, which is the specific medical device type. The preset encoding rule mapping table is set based on the correspondence between medical device protocol types and unified format string encodings.

[0068] S2. Input the device type identifier and the original medical device data stream into the shared syntax tree protocol conversion model. Based on the device type identifier, call the corresponding syntax tree conversion rule. Utilize the syntax tree node automatic alignment mechanism of the syntax tree conversion rule to convert the original medical device data stream into a standardized FHIR resource data stream.

[0069] Input the device type identifier and the raw medical device data stream into the shared syntax tree protocol conversion model;

[0070] The shared syntax tree protocol conversion model searches for the corresponding syntax tree conversion rule in the preset syntax tree rule mapping table based on the device type identifier, and obtains the mapping relationship between the source protocol node structure and the target protocol node structure defined in the syntax tree conversion rule;

[0071] Specifically, the shared syntax tree protocol conversion model receives a device type identifier, retrieves the syntax tree conversion rule entry corresponding to the device type identifier from a preset syntax tree rule mapping table; accesses the index structure in the syntax tree rule mapping table to locate the entry containing the device type identifier; extracts the corresponding syntax tree conversion rule from the located entry; parses the source protocol node structure in the syntax tree conversion rule to confirm the field names, data types, and hierarchical relationships contained in the source protocol node structure; parses the target protocol node structure in the syntax tree conversion rule to confirm the field names, data types, and hierarchical relationships contained in the target protocol node structure; organizes the mapping relationship between the source protocol node structure and the target protocol node structure to form a field mapping relationship table, which records the conversion path from source protocol fields to target protocol fields; and outputs the field mapping relationship table as the mapping relationship between the source protocol node structure and the target protocol node structure.

[0072] It should be noted that the shared syntax tree protocol conversion model is built on the abstract syntax tree (AST) framework. The abstract syntax tree (AST) is a static structure that is directly parsed and organized based on the protocol definition document, without the need for a training process in the sense of machine learning.

[0073] The construction process of the Abstract Syntax Tree (AST) is as follows:

[0074] Protocol definition documents were collected from various medical device protocols (such as HL7, DICOM, and FHIR). These documents contained field names, data types, and hierarchical relationships. The protocol definition documents for each medical device protocol were parsed to extract field names, data types, and hierarchical relationships. The extracted field names, data types, and hierarchical relationships were organized into a set of nodes. Each node in the set contained a field name, data type, and a reference to a child field. Parent-child node connections were established in the node set according to the hierarchical relationships, with parent nodes representing upper-level fields and child nodes representing nested fields, forming a tree structure. This tree structure was stored as an abstract syntax tree (AST) for each medical device protocol. In the AST, nodes represent fields, and edges represent hierarchical relationships between fields. A corresponding device type identifier was assigned to the AST for each medical device protocol. The ASTs for all medical device protocols were then stored. The abstract syntax tree and its corresponding device type identifier are stored in a shared database. For each medical device protocol, field mapping rules are defined from the abstract syntax tree of the source protocol to the abstract syntax tree of the target protocol (such as FHIR). The field mapping rules record the conversion path from the source protocol fields to the target protocol fields. The field mapping rules are associated with the corresponding device type identifiers and stored in a preset syntax tree rule mapping table. Protocol definition documents are periodically collected from newly connected medical device protocols, and the field names, data types, and hierarchical relationships are parsed to generate new abstract syntax trees. The shared database and the preset syntax tree rule mapping table are then updated. Through the above steps, a shared syntax tree protocol conversion model is formed. The shared syntax tree protocol conversion model contains all abstract syntax trees and field mapping rules. It can retrieve the corresponding field mapping rules based on the device type identifier and perform the conversion from the original medical device data stream to the standardized FHIR resource data stream.

[0075] The medical data fields in the original medical device data stream are structurally aligned according to the mapping relationship to form an aligned medical data structure.

[0076] The aligned medical data structure is encapsulated according to the FHIR standard to generate medical data entries that conform to FHIR resources. The FHIR standard (Fast Healthcare Interoperability Resources) is a resource-based medical data exchange standard that defines the field names, data types, and structured formats of medical data to achieve interoperability of data streams from different medical devices.

[0077] All medical data entries that conform to FHIR resources are organized in chronological order by timestamp to form a standardized FHIR resource data stream.

[0078] S3. Utilize the physical location parameters and resource load parameters of the edge computing nodes to perform distributed routing decisions on the standardized FHIR resource data stream and generate routing assignment instructions; the routing assignment instructions include the unique location identifier of the target edge computing node.

[0079] Obtain the physical location parameters and resource load parameters of the edge computing node; the physical location parameters represent the deployment location of the edge computing node; the resource load parameters include processor utilization, memory usage, and network bandwidth utilization.

[0080] Based on physical location parameters and resource load parameters, a distributed routing decision is performed on the standardized FHIR resource data stream;

[0081] During the distributed routing decision-making process, medical service types and clinical urgency priorities are extracted from the standardized FHIR resource data stream;

[0082] The medical service type is matched with a preset latency mapping table to determine the corresponding data transmission latency requirements. The preset latency mapping table is set based on the correspondence between medical service type and data transmission latency requirements, and includes three latency requirements: real-time, near real-time and non-real-time, corresponding to different time thresholds.

[0083] Specifically: The first medical service type entry in the preset latency mapping table is retrieved, and it is checked whether the medical service type is the same as the first medical service type entry in the preset latency mapping table. If the medical service type is the same as the first medical service type entry in the preset latency mapping table, the data transmission latency requirement corresponding to the first medical service type entry in the preset latency mapping table is retrieved. If the medical service type is different from the first medical service type entry in the preset latency mapping table, the second medical service type entry in the preset latency mapping table is retrieved, and it is checked whether the medical service type is the same as the second medical service type entry in the preset latency mapping table. If the medical service type is different from the second medical service type entry in the preset latency mapping table... If the entries are the same, retrieve the data transmission latency requirement corresponding to the second medical service type entry in the preset latency mapping table. If the medical service type is different from the second medical service type entry in the preset latency mapping table, retrieve the next medical service type entry in the preset latency mapping table and repeat the process until a matching medical service type entry is found and the corresponding data transmission latency requirement is retrieved, or until all medical service type entries in the preset latency mapping table have been traversed. If no matching entry is found after traversing all medical service type entries in the preset latency mapping table, a default data transmission latency requirement (e.g., non-real-time) is returned.

[0084] The clinical emergency priority is matched with a preset quality level table to determine the corresponding quality level. The preset quality level table is set based on the correspondence between clinical emergency priority and quality level, and includes three quality levels: high, medium and low, corresponding to different resource load capacity thresholds.

[0085] Specifically: The first clinical urgency priority item in the preset quality level table is retrieved, and its clinical urgency priority is checked against the first clinical urgency priority item in the preset quality level table. If the clinical urgency priority is the same as the first clinical urgency priority item in the preset quality level table, the corresponding quality level is retrieved. If the clinical urgency priority is different from the first clinical urgency priority item in the preset quality level table, the second clinical urgency priority item in the preset quality level table is retrieved, and its clinical urgency priority is checked against the second clinical urgency priority item in the preset quality level table. If the clinical urgency priority is different from the second clinical urgency priority item in the preset quality level table, the second clinical urgency priority item in the preset quality level table is retrieved, and its clinical urgency priority is checked against the second clinical urgency priority item in the preset quality level table. If the emergency priority entries are the same, retrieve the quality level corresponding to the second clinical emergency priority entry in the preset quality level table. If the clinical emergency priority is different from the second clinical emergency priority entry in the preset quality level table, retrieve the next clinical emergency priority entry in the preset quality level table and repeat the process of checking whether the clinical emergency priority is the same as the next clinical emergency priority entry in the preset quality level table until a matching clinical emergency priority entry is found and the corresponding quality level is retrieved, or until all clinical emergency priority entries in the preset quality level table have been traversed. If no matching entry is found after traversing all clinical emergency priority entries in the preset quality level table, return a default quality level (such as a low quality level).

[0086] Based on data transmission latency requirements, candidate edge computing nodes whose physical location parameters meet the distance threshold are selected. Meeting the distance threshold means that the physical distance between the edge computing node and the data source is less than or equal to the distance threshold. The distance threshold is set based on data transmission latency requirements and network transmission speed. For example, the distance threshold range for real-time medical services is 0 to 100 kilometers, for near real-time medical services it is 0 to 500 kilometers, and for non-real-time medical services it is 0 to 1000 kilometers.

[0087] Among the candidate edge computing nodes that meet the distance threshold, available edge computing nodes with resource load parameters lower than the load capacity threshold are selected according to the quality level requirements. The load capacity threshold is set based on the quality level requirements and the hardware performance of the edge computing node. For example, high, medium and low quality levels correspond to load capacity thresholds with resource load parameters lower than 80%, 60% and 40%, respectively.

[0088] From the selected available edge computing nodes, select the available edge computing node with the lowest resource load parameter as the target edge computing node;

[0089] Write the unique location identifier of the target edge computing node into the routing assignment instruction structure to complete the construction of the routing assignment instruction; the routing assignment instruction contains the unique location identifier of the target edge computing node.

[0090] It should be noted that the routing assignment instruction includes the unique location identifier of the target edge computing node because, in the distributed routing decision, the target edge computing node is determined by filtering physical location and resource load parameters, and the unique location identifier of the target edge computing node is written into the routing assignment instruction structure to guide data distribution.

[0091] S4. Distribute standardized FHIR resource data streams to target edge computing nodes according to routing allocation instructions. Start lightweight medical data processing containers on target edge computing nodes, perform multimodal clinical analysis for different clinical manifestations, dynamically switch analysis paths, and generate analysis results. Synchronize the analysis results to clinician terminal devices and hospital data centers through the distributed message bus of target edge computing nodes. Analysis paths include critical care rapid response path, research-grade image depth analysis path, and emergency multimodal collaboration path.

[0092] The unique location identifier of the target edge computing node is parsed by the routing allocation instruction to determine the target location for data distribution;

[0093] Specifically, the process involves: extracting a unique location identifier from the routing assignment instruction. This unique location identifier uses a hierarchical encoding structure, connecting multiple levels with separators; reading the portion of the unique location identifier from the beginning to the first separator as the area location; reading the portion from after the first separator to the second separator as the building location; reading the portion from after the second separator to the third separator as the floor location; and reading the portion from after the third separator to the end as the node identifier. The extracted area location, building location, floor location, and node identifier are then integrated to form the complete data distribution target location.

[0094] Transmit the standardized FHIR resource data stream to the data receiving buffer of the target edge computing node corresponding to the data distribution target location;

[0095] A lightweight medical data processing container is launched in the data receiving buffer of the target edge computing node. The lightweight medical data processing container loads a pre-built multimodal analysis toolset to extract vital sign data, medical image data, and clinical text data from the standardized FHIR resource data stream as multimodal input data. The pre-built multimodal analysis toolset is a collection of software tools built on the Apache Kafka stream processing framework, DICOM processing library, and NLTK natural language processing toolset, used to extract vital sign data, medical image data, and clinical text data from the standardized FHIR resource data stream.

[0096] Feature extraction is performed on multimodal input data to identify critical illness features, imaging abnormalities, and emergency core terms;

[0097] Based on the identified critical illness characteristics, imaging abnormality characteristics, and emergency core terms, the corresponding analysis path is selected from the preset set of analysis paths. The preset set of analysis paths is set based on the correspondence between critical illness characteristics, imaging abnormality characteristics, and emergency core terms and critical illness rapid response path, scientific research-level imaging in-depth analysis path, and emergency multimodal collaborative path.

[0098] Select the corresponding analysis path from the preset set of analysis paths, specifically:

[0099] Based on the characteristics of critically ill patients, a rapid response pathway for critically ill patients is selected, and a vital sign threshold comparison operation is performed to generate a critically ill patient warning report containing abnormal indicators and timestamps. The vital sign thresholds are set based on clinical medical standards and medical device protocols, including upper and lower limits for heart rate, respiratory rate, systolic blood pressure, diastolic blood pressure, and body temperature. For example, the lower limit for heart rate is 60 beats per minute, and the upper limit is 100 beats per minute; the lower limit for respiratory rate is 12 breaths per minute, and the upper limit is 18 breaths per minute; the lower limit for systolic blood pressure is 90 mmHg, and the upper limit is 120 mmHg; the lower limit for diastolic blood pressure is 60 mmHg, and the upper limit is 80 mmHg; the lower limit for body temperature is 97.8 degrees Fahrenheit, and the upper limit is 99.1 degrees Fahrenheit.

[0100] The vital signs threshold comparison operation is performed by retrieving vital signs data from the multimodal input data, which includes heart rate, respiratory rate, blood pressure, and body temperature.

[0101] Extract the heart rate value and corresponding timestamp from the vital signs data; check whether the heart rate value is lower than the lower heart rate threshold or higher than the upper heart rate threshold; if the heart rate value is lower than the lower heart rate threshold or higher than the upper heart rate threshold, mark the heart rate as an abnormal indicator and record the heart rate value and corresponding timestamp in the critical illness early warning report;

[0102] Extract the respiratory rate value and corresponding timestamp from the vital signs data; check whether the respiratory rate value is lower than the lower respiratory rate threshold or higher than the upper respiratory rate threshold; if the respiratory rate value is lower than the lower respiratory rate threshold or higher than the upper respiratory rate threshold, mark the respiratory rate as an abnormal indicator and record the respiratory rate value and corresponding timestamp in the critical illness early warning report;

[0103] Extract the blood pressure value and corresponding timestamp from the vital signs data. The blood pressure value includes systolic and diastolic blood pressure. Check whether the systolic blood pressure is lower than the lower limit threshold or higher than the upper limit threshold. If the systolic blood pressure is lower than the lower limit threshold or higher than the upper limit threshold, mark the systolic blood pressure as an abnormal indicator and record the systolic blood pressure value and corresponding timestamp in the critical illness early warning report.

[0104] Check whether the diastolic blood pressure is lower than the lower limit threshold or higher than the upper limit threshold. If the diastolic blood pressure is lower than the lower limit threshold or higher than the upper limit threshold, mark the diastolic blood pressure as an abnormal indicator and record the diastolic blood pressure value and the corresponding timestamp in the critical illness warning report.

[0105] Extract the body temperature value and corresponding timestamp from the vital signs data; check whether the body temperature value is lower than the lower limit threshold or higher than the upper limit threshold; if the body temperature value is lower than the lower limit threshold or higher than the upper limit threshold, mark the body temperature as an abnormal indicator and record the body temperature value and corresponding timestamp in the critical illness early warning report;

[0106] All marked abnormal indicators and their corresponding timestamps are organized into a structured format to form a critical illness early warning report containing abnormal indicators and timestamps.

[0107] For abnormal features in images, a research-grade image depth analysis path is selected to perform image edge detection and region growth segmentation operations, and output an image analysis report with lesion area measurement data;

[0108] The image edge detection and region growing segmentation operation is performed as follows: medical image data is extracted from the multimodal input data, which includes pixel grids and grayscale values;

[0109] The pixel grid in medical image data is smoothed. By examining the grayscale difference between each pixel and its neighboring pixels, the locations of pixels with large grayscale differences are marked as potential edge points. Adjacent potential edge points are connected to form continuous edge lines, which enclose the boundaries of objects in the image.

[0110] Select a seed pixel within the object boundary as the starting point. The seed pixel is located in the image anomalous feature region. Check the gray value of the seed pixel and check whether the gray values ​​of adjacent pixels are similar to the gray value of the seed pixel. If the gray values ​​of adjacent pixels are similar to the gray value of the seed pixel, then add the adjacent pixels to the growth region.

[0111] Repeatedly check whether the gray values ​​of adjacent pixels on the boundary of the growth region are similar to the gray values ​​of the seed pixels, and add pixels with similar gray values ​​to the growth region until there are no more pixels with similar gray values ​​to add; mark the growth region as the lesion region; count the number of pixels in the lesion region as the lesion area measurement data; integrate the lesion area measurement data with the edge line description to form an image analysis report with lesion area measurement data.

[0112] Based on the characteristics of critical illness, abnormal imaging features, and core emergency terms, an emergency multimodal collaborative path is selected, multi-source data rule matching is performed, and an emergency collaborative analysis report containing treatment suggestions and emergency priority markers is generated.

[0113] Perform multi-source data rule matching operation, specifically: extract critical illness features, imaging abnormality features, and emergency core words from multimodal input data; call the first rule in the preset multi-source data rule list, the first rule defines a specific combination of critical illness features, imaging abnormality features, and emergency core words to correspond to specific treatment suggestions and emergency priority markers;

[0114] Check whether the critical illness features match the requirements of the first rule, whether the imaging abnormality features match the requirements of the first rule, and whether the emergency core terms match the requirements of the first rule. If all three—critical illness features, imaging abnormality features, and emergency core terms—match the requirements of the first rule, then retrieve the treatment recommendations and emergency priority markers corresponding to the first rule. If any one of the critical illness features, imaging abnormality features, or emergency core terms does not match the requirements of the first rule, then retrieve the second rule from the preset multi-source data rule list. The second rule defines specific combinations of critical illness features, imaging abnormality features, and emergency core terms that correspond to specific treatment recommendations and emergency priority markers.

[0115] Check whether the critical illness characteristics match the requirements of the second rule, whether the imaging abnormality characteristics match the requirements of the second rule, and whether the emergency core terms match the requirements of the second rule. If the critical illness characteristics, imaging abnormality characteristics, and emergency core terms all match the requirements of the second rule, then retrieve the treatment suggestions and emergency priority markers corresponding to the second rule. If any one of the critical illness characteristics, imaging abnormality characteristics, or emergency core terms does not match the requirements of the second rule, then continue to retrieve the next rule from the preset multi-source data rule list.

[0116] Repeatedly check whether the critical illness characteristics match the requirements of the next rule, whether the imaging abnormality characteristics match the requirements of the next rule, and whether the emergency core words match the requirements of the next rule, until a matching rule is found and the corresponding treatment suggestions and emergency priority tags are extracted, or all rules in the preset multi-source data rule list are traversed; integrate the extracted treatment suggestions and emergency priority tags into the report structure to form an emergency collaborative analysis report containing treatment suggestions and emergency priority tags; wherein, the preset multi-source data rules are set based on clinical medical guidelines and emergency diagnosis and treatment standards, and include the mapping relationship between the combination of critical illness characteristics, imaging abnormality characteristics and emergency core words and the corresponding treatment suggestions and emergency priority tags.

[0117] Perform corresponding multimodal clinical analysis operations based on the selected analysis path to generate structured analysis results (including critical illness early warning reports, image analysis reports, or emergency collaborative analysis reports).

[0118] The generated structured analysis results are submitted to the distributed message bus of the target edge computing node;

[0119] In the distributed message bus, the receiving addresses of the clinician terminal device and the hospital data center are determined according to a preset distribution list. The preset distribution list is set based on the registration information of the clinician terminal device and the hospital data center, and includes the IP address and port number of the clinician terminal device and the IP address and port number of the hospital data center.

[0120] The structured analysis results are sent to the receiving addresses of clinicians' terminal devices and hospital data centers via a distributed message bus, thus synchronizing the structured analysis results with the clinicians' terminal devices and hospital data centers.

[0121] This embodiment also provides a computer device applicable to the real-time processing method of heterogeneous medical data sources based on distributed deployment, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the real-time processing method of heterogeneous medical data sources based on distributed deployment as proposed in the above embodiment.

[0122] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0123] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the real-time processing method for heterogeneous medical data sources based on distributed deployment as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0124] In summary, this invention achieves field mapping and automatic alignment between source protocol nodes and target FHIR protocol nodes by using a shared syntax tree protocol conversion model, constructing an abstract syntax tree static structure based on protocol definition documents, and combining device type identifiers to call corresponding conversion rules. This eliminates the need for dynamic training processes, avoids the reliance on large amounts of labeled data and continuous parameter tuning found in traditional models, and ensures the determinism and timeliness of protocol conversion. Furthermore, by directly guiding the structural reorganization and format encapsulation of the original medical data stream through a pre-defined field mapping relationship table, this invention effectively improves the accuracy and consistency of converting multi-source heterogeneous medical data to standardized FHIR resources, ensuring efficient and reliable data interoperability between clinical systems.

[0125] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A real-time processing method based on a distributed deployment of heterogeneous medical data sources, characterized in that: The application relates to a medical device access interface established at an edge computing node in a distributed deployment, which receives an original medical device data stream sent by a medical device, matches a preset device protocol fingerprint library by analyzing time interval characteristics and load length characteristics of the original medical device data stream, and generates a device type identifier. The device type identifier and the original medical device data stream are input into a shared syntax tree protocol conversion model, a corresponding syntax tree conversion rule is called according to the device type identifier, and the original medical device data stream is converted into a standardized FHIR resource data stream by using a syntax tree node automatic alignment mechanism of the syntax tree conversion rule. Distributed routing decisions are performed on the standardized FHIR resource data stream by using physical location parameters and resource load parameters of the edge computing node to generate routing allocation instructions; the routing allocation instructions include a unique location identification code of a target edge computing node. The standardized FHIR resource data stream is distributed to the target edge computing node according to the routing allocation instructions, a lightweight medical data processing container is started at the target edge computing node, multi-modal clinical analysis is performed for different clinical manifestations, an analysis path is dynamically switched, and analysis results are generated; the analysis results are synchronized to a clinical physician terminal device and a hospital data center through a distributed message bus of the target edge computing node; the analysis path includes a critical illness rapid response path, a scientific research level image deep analysis path and an emergency multi-modal collaborative path. The medical device access interface is established at the edge computing node in the distributed deployment, and the original medical device data stream sent by the medical device is received.

2. The real-time processing method based on distributed deployment of heterogeneous medical data sources according to claim 1, characterized in that: The medical device access interface is established at the edge computing node in the distributed deployment. A data packet sequence from the medical device is continuously received through the medical device access interface, the data packet sequence is arranged in chronological order to form the original medical device data stream. The device type identifier is generated by capturing continuous medical data packets in the original medical device data stream, extracting time interval values between adjacent medical data packets as time interval characteristics, measuring payload parts of each medical data packet in the original medical device data stream to obtain payload byte length values as load length characteristics, combining the time interval characteristics and the load length characteristics into a medical feature vector group, comparing the medical feature vector group with medical standard feature combinations stored in a device protocol fingerprint library one by one, confirming that protocol type identification is successful when the medical feature vector group and a certain medical standard feature combination are found to be completely consistent in matching degree, and obtaining a corresponding unique code string as the device type identifier according to the identified successful protocol type by searching a preset encoding rule mapping table.

3. The method of claim 1, wherein: The payload part is the data content of actual medical data after removing header information, check bits and protocol control fields. The device protocol fingerprint library is a database for storing medical standard feature combinations and corresponding medical device protocol type identifiers. The device type identifier and the original medical device data stream are input into a shared syntax tree protocol conversion model, a corresponding syntax tree conversion rule is called according to the device type identifier, and the original medical device data stream is converted into a standardized FHIR resource data stream by using a syntax tree node automatic alignment mechanism of the syntax tree conversion rule. ​ ​ ​ ​ 4. The method of claim 3, wherein: ​ 5. The method of claim 3, wherein: ​ 6. The method of claim 1, wherein: ​ inputting the device type identifier and the original medical device data stream into a shared syntax tree protocol conversion model; the shared syntax tree protocol conversion model looks up a corresponding syntax tree conversion rule in a preset syntax tree rule mapping table according to the device type identifier, and obtains a mapping relationship between a source protocol node structure and a target protocol node structure defined in the syntax tree conversion rule.

7. The method of claim 6, wherein: The shared syntax tree protocol conversion model is a processing framework based on an abstract syntax tree framework, including multiple abstract syntax trees, field mapping rules and a preset syntax tree rule mapping table, and is used for performing structured conversion from a source protocol to a target protocol.

8. The method of claim 1, wherein: The original medical device data stream is converted into a standardized FHIR resource data stream, specifically, aligning the medical data fields in the original medical device data stream in structure according to the mapping relationship to form an aligned medical data structure; formatting and packaging the aligned medical data structure according to the FHIR standard to generate a medical data entry conforming to the FHIR resource; organizing all medical data entries conforming to the FHIR resource in chronological order to form a standardized FHIR resource data stream.

9. The method of claim 1, wherein: The routing allocation instruction is generated, specifically, obtaining physical location parameters and resource load parameters of the edge computing nodes; performing distributed routing decision on the standardized FHIR resource data stream based on the physical location parameters and the resource load parameters; extracting medical service types and clinical emergency priorities from the standardized FHIR resource data stream during the distributed routing decision process; matching the medical service types with a preset time delay mapping table to determine corresponding data transmission time delay requirements; matching the clinical emergency priorities with a preset quality level table to determine corresponding quality levels; According to the data transmission time delay requirement, the candidate edge computing nodes whose physical location parameters meet the distance threshold are screened out; According to the quality level requirement, the available edge computing nodes whose resource load parameters are lower than the load capacity threshold are screened out from the candidate edge computing nodes that meet the distance threshold; selecting the available edge computing node with the lowest resource load parameter as the target edge computing node from the screened available edge computing nodes; write the unique location identifier of the target edge computing node into the routing allocation instruction structure to complete the construction of the routing allocation instruction.

10. The method of claim 1, wherein: For different clinical manifestations, multi-modal clinical analysis is performed, specifically, extracting vital sign data, medical image data and clinical text data from the standardized FHIR resource data stream as multi-modal input data; performing feature extraction on the multi-modal input data to identify critical illness features, image abnormal features and emergency core words; for critical illness features, select a critical illness rapid response path, perform vital sign threshold comparison operation, and generate a critical illness warning report; for image abnormal features, select a research-level image deep analysis path, perform image edge detection and region growing segmentation operation, and output an image analysis report; for critical illness features, image abnormal features and emergency core words, select an emergency multi-modal collaborative path, perform multi-source data rule matching operation, and generate an emergency collaborative analysis report.

Images