A method for processing trauma triage data

Abstract

The application provides a trauma first aid data processing method, comprising the following steps: step 1; real-time collection and aggregation of resource state data in multiple dimensions in a medical environment, construction of a dynamic resource state model based on a time sequence diagram database; wherein the dynamic resource state model abstracts medical resources as nodes, the correlation between resources as edges, and maintains an attribute list with a time stamp for each node to record the change flow of resource state over time; step 2: obtaining multi-source physiological parameters and injury mechanism information of a patient, calculating the risk score and injury mode of the patient based on a preset scoring rule; step 3: according to the risk score, the injury mode and the dynamic resource state model, the receiving unit and the expected treatment path are determined through algorithm calculation.

Description

Technical Field

[0001] This invention relates to the field of medical emergency information technology, specifically to a method for processing trauma emergency data. Background Technology

[0002] Trauma emergency care is a crucial aspect of emergency medicine, aiming to provide decisive treatment to critically ill patients in the shortest possible time. An efficient emergency care process typically requires seamless integration of multiple stages, including pre-hospital emergency care, emergency triage, imaging examinations, surgery, and hospitalization, and relies on close collaboration among various medical personnel. Therefore, the timeliness and accuracy of the emergency care process directly impact patient safety, placing extremely high demands on information systems.

[0003] Although modern hospitals have widely adopted information systems, existing emergency information systems face severe technical bottlenecks. On the one hand, there is a serious "information silo" phenomenon within hospitals. HIS, LIS, PACS, and operating room management systems are often developed by different vendors, resulting in heterogeneous data structures and inconsistent interface standards. Existing systems mostly use timed polling or manual data entry to obtain data, leading to significant delays of several minutes. This makes it impossible to reflect the instantaneous status of critical resources such as operating rooms and CT rooms in real time, causing triage decisions to be based on "past" resource information.

[0004] On the other hand, the process control logic of existing technologies is mostly serial. That is, triage is completed first, then resources are notified, and the examination is carried out only after the resources are ready. This software architecture based on serial logic results in an excessively long overall system response time when handling high-concurrency emergency requests due to the large amount of I / O waiting time, making it difficult to meet the timeliness requirements of the "golden hour" of trauma emergency treatment. At the same time, path planning is mostly based on simple rule matching and lacks the ability to quantitatively calculate complex constraints, making it difficult to generate globally optimal treatment paths.

[0005] Furthermore, while graph databases and parallel computing have been applied in areas such as logistics scheduling and internet resource management, directly migrating them to the field of trauma and emergency care presents significant technical obstacles. General logistics models typically only consider physical location, transportation speed, and time costs, failing to address the unique constraints of medical resources, such as "capacity matching" (e.g., doctor qualification levels, precision requirements of specialized emergency equipment) and "vital signs" (e.g., whether the patient's current physiological state can tolerate long-distance transport). Simple parallel processing, lacking feedback and decision-making mechanisms and safety checks based on medical characteristics, can easily lead to misallocation of medical resources or even medical safety accidents. Therefore, existing technologies struggle to meet the stringent requirements of both "high timeliness" and "high accuracy" in trauma and emergency care. Summary of the Invention

[0006] To address the technical challenge of real-time synchronization of heterogeneous medical data, this invention provides a method for processing trauma emergency data.

[0007] The first aspect of this invention provides a method for processing trauma emergency data, comprising the following steps:

[0008] Step 1: Collect and aggregate resource status data from multiple dimensions in the medical environment in real time, and construct a dynamic resource status model based on a time-series graph database; wherein, the dynamic resource status model abstracts medical resources as nodes, the relationships between resources as edges, and maintains an attribute list with timestamps for each node to record the changes in resource status over time;

[0009] Step 2: Obtain the patient's multi-source physiological parameters and injury mechanism information, and calculate the patient's risk score and injury pattern based on the preset scoring rules;

[0010] Step 3: Based on the risk score, damage mode, and dynamic resource status model, the receiving unit and expected disposal path are determined through algorithm calculation.

[0011] This method effectively solves core technical problems through the synergistic effect of the above steps. First, step 1, through the dynamic resource status model constructed using a time-series graph database, fundamentally breaks down data barriers between various business systems, transforming heterogeneous and discrete resource status events into a unified and continuous time-series data stream, achieving millisecond-level dynamic perception of the hospital's resource status. This provides an unprecedented real-time data foundation for subsequent decision-making, solving the fundamental pain point of data latency in traditional solutions. Second, the real-time patient information obtained in step 2 is combined with the real-time resource model from step 1 in step 3, enabling the system to make matching decisions based on the patient's condition and resource availability at the "current moment," avoiding resource conflicts and decision-making errors caused by information lag, and greatly improving the accuracy and timeliness of emergency response decisions.

[0012] Furthermore, step 1 further includes: connecting multiple medical business systems through a preset heterogeneous data interface, subscribing to change events of the resource status data; performing semantic mapping and standardization processing on the received heterogeneous data, and updating the corresponding nodes and timestamped attribute lists in the time-series graph database. This additional technical feature, through standardized interfaces and semantic mapping, enhances compatibility with different vendors and different versions of systems, making the construction of the dynamic resource status model more universal and robust.

[0013] Furthermore, in step 3, the receiving unit and the expected processing path are determined through algorithm calculation, including:

[0014] The patient's injury pattern is mapped to a patient demand vector, and the capability vector of the resource node is extracted from the dynamic resource state model.

[0015] Construct a five-dimensional feature space that includes resource category matching degree, capability level, time urgency, physical proximity, and auxiliary equipment satisfaction rate;

[0016] The matching degree between the patient demand vector and the resource capability vector is calculated based on the five-dimensional feature space. ;

[0017] The optimal path is found using a graph search algorithm, where the weight of each edge in the path is... Calculate using the following formula:

[0018]

[0019] in, The estimated transit time is based on physical distance. The estimated queuing time for the target node. These are the preset weighting coefficients.

[0020] Furthermore, the method also includes: Step 4: Performing security constraint verification; after the verification passes, initiating resource scheduling instructions and key medical examination instructions in parallel; monitoring the feedback results of the key medical examinations in real time, and determining whether to confirm the current path or trigger path adjustment based on the matching degree between the feedback results and the expected treatment path. This additional technical feature, by introducing a parallel processing mechanism, transforms the traditional "wait-decision" serial process into an asynchronous process of "parallel scheduling and inspection," significantly reducing I / O waiting time and further optimizing the response speed of the emergency response process from the software architecture level.

[0021] Furthermore, in step 4, real-time monitoring and adjudication include: utilizing asynchronous I / O and multi-threaded event monitoring technology to overlap the resource preparation process and the diagnostic verification process on the timeline; and performing automatic adjudication by calculating the similarity between the data features of the feedback results and the features of the expected damage mode. This additional technical feature clarifies the specific implementation method of parallel adjudication, ensures concurrent execution through asynchronous technology, and achieves an intelligent closed loop of the process through automatic adjudication based on feature similarity, reducing reliance on manual intervention.

[0022] A second aspect of the present invention provides a system for processing trauma emergency data, comprising:

[0023] The resource status aggregation module is used to collect and aggregate resource status data from multiple dimensions in the medical environment in real time, and to build a dynamic resource status model based on a time-series graph database. The dynamic resource status model abstracts medical resources as nodes, the relationships between resources as edges, and maintains a list of attributes with timestamps for each node to record the changes in resource status over time.

[0024] The risk assessment module is used to acquire multi-source physiological parameters and injury mechanism information of patients, and calculate the patient's risk score and injury pattern based on preset scoring rules;

[0025] The path planning module is used to determine the receiving unit and the expected disposal path through algorithm calculation based on the risk score, damage mode and dynamic resource status model.

[0026] The system achieves the functions of the above methods through the collaborative work of its various modules. The resource status aggregation module is the core of solving the problem of real-time data synchronization, while the risk assessment module and the path planning module use real-time data to make intelligent decisions, together forming an efficient and intelligent trauma emergency treatment system.

[0027] A third aspect of the present invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method for processing trauma emergency data as described in any one of claims 1-5.

[0028] A fourth aspect of the present invention provides an electronic device, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to implement the steps of the trauma first aid data processing method described above when executing the executable instructions.

[0029] The present invention has the following beneficial effects:

[0030] This solution achieves millisecond-level real-time synchronization of heterogeneous medical data by constructing a dynamic resource status model based on a time-series graph database, providing an accurate and real-time data foundation for emergency decision-making and solving the problem of decision lag caused by information silos and data delays in existing technologies.

[0031] This solution introduces a concurrent mechanism for parallel resource scheduling and medical examination, and forms a closed loop through intelligent adjudication, which significantly shortens the response time of the emergency process and improves the system's concurrent processing capability.

[0032] This solution vectorizes patient needs and resource capabilities and uses a graph search algorithm for path planning, enabling quantitative calculation of complex medical constraints and generating globally optimal treatment paths, thus improving the scientific nature and accuracy of emergency procedures. Attached Figure Description

[0033] Figure 1 A flowchart illustrating a method for processing trauma emergency data provided in an embodiment of the present invention; Detailed Implementation

[0034] 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. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0035] Please refer to Figure 1 This embodiment provides a method for processing trauma emergency data, including: Step 1: Real-time collection and aggregation of resource status data from multiple dimensions in the medical environment, and construction of a dynamic resource status model based on a time-series graph database; wherein, the dynamic resource status model abstracts medical resources as nodes, the relationships between resources as edges, and maintains a list of attributes with timestamps for each node to record the changes in resource status over time; Step 2: Obtaining multi-source physiological parameters and injury mechanism information of the patient, and calculating the patient's risk score and injury pattern based on preset scoring rules; Step 3: Determining the receiving unit and expected treatment path through algorithm calculation based on the risk score, injury pattern, and dynamic resource status model; Step 4: Parallel initiation of resource scheduling instructions and key medical examination instructions; real-time monitoring of the feedback results of the key medical examinations, and adjudicating and confirming the current path or triggering path adjustment based on the matching degree between the feedback results and the expected treatment path.

[0036] This embodiment aims to address two major technical problems in existing technologies: data non-real-time performance caused by "information silos" in medical information systems, and response delays caused by serial processing. To achieve this, this embodiment provides a method for processing trauma emergency data. This method achieves high efficiency and intelligence in the emergency process by constructing a real-time dynamic resource model and introducing a concurrent adjudication mechanism.

[0037] The dynamic resource status model is a data model built on a time-series graph database, and its specific structure is defined as follows:

[0038] Node type: Defines specific node labels, such as Person (doctor / nurse), Space (operating room / CT room / bed), Equipment (ventilator / defibrillator).

[0039] Edge type: Defines the specific edge, such as: LOCATED_IN (located in), BELONGS_TO (belonging to), OPERATES (operations), NEXT_TO (physical adjacency, used to calculate transit time).

[0040] The attribute list structure with timestamps: The attribute list with timestamps is stored using a time-series tree or linked list structure. For example, for the Space node, its attributes include not only the static ID but also the dynamic attribute status_timeline. In Neo4j, this attribute can be stored as a JSON array: [{time: T1, status: "OCCUPIED", expected_end:T1+2h}, {time:T2,status:"FREE"}]. In another implementation, a "status node" chain can also be used, where resource nodes point to a series of time-ordered status nodes.

[0041] Patient Demand Vector: A mathematical vector used to quantify a patient's demand for medical resources. This vector is generated based on the patient's injury pattern and risk score, and includes quantitative requirements for dimensions such as resource type, capability level, and urgency.

[0042] Resource Capability Vector: A mathematical vector used to quantify the service capacity of healthcare resources. This vector is extracted from the node attributes of the dynamic resource status model and includes information such as resource type, capacity level, and current load.

[0043] Specifically, this embodiment includes the following steps:

[0044] Step 1: Collect and aggregate resource status data from multiple dimensions in the medical environment in real time, and build a dynamic resource status model based on a time series graph database.

[0045] This step is the core technical means to solve the problem of non-real-time data. Using a time-series graph database (Neo4j in this embodiment), the resource status data of heterogeneous systems within the hospital (such as HIS, LIS, and PACS) are transformed into a unified, computable graph structure. This model abstracts medical resources (such as operating rooms, CT scanners, and beds) as nodes, and the relationships between resources (such as transport paths and affiliated departments) as edges. It maintains a timestamped attribute list for each node to record the flow of resource status changes over time. To fully record the dynamic changes of resources in space and logical relationships, the "edges" (Relationships) in the dynamic resource status model also incorporate timeliness design. Specifically, for edges representing location relationships (:LOCATED_IN) and edges representing affiliation relationships (:BELONGS_TO), the model does not directly delete old edges, but instead adopts an "edge attribute version control" mechanism.

[0046] Each edge contains three key attributes: {start_time, end_time, weight}.

[0047] start_time: Indicates the effective time of this relationship;

[0048] end_time: Indicates the expiration time of the relationship (set to infinity or NULL if it is currently valid);

[0049] weight: Indicates the weight of the relationship (such as physical distance or traffic resistance).

[0050] For example, when a mobile ventilator (Equipment_01) is moved from the emergency room (Room_A) to the operating room (Room_B), the system performs the following atomic operations:

[0051] Find the currently valid edge between Equipment_01 and Room_A, and update its end_time to the current timestamp. ;

[0052] Create a new edge between Equipment_01 and Room_B, and set its start_time to [value]. end_time is set to NULL.

[0053] When performing path planning queries, graph database queries (such as Cypher) will force the inclusion of a time constraint: WHERE edge.start_time <= T_query AND (edge.end_time IS NULL OR edge.end_time > T_query), thus ensuring that path calculation is based on the network topology of a specific time slice. This technique enables millisecond-level dynamic awareness of the entire institute's resource status, providing an unprecedented real-time data foundation for subsequent decision-making and fundamentally solving the pain point of data latency in traditional solutions.

[0054] Step 2: Obtain the patient's multi-source physiological parameters and injury mechanism information, and calculate the patient's risk score and injury pattern based on the preset scoring rules.

[0055] This step involves receiving vital sign data in real time from the ambulance or emergency room via an IoT gateway, and combining this with textual information about the "injury mechanism" extracted using NLP technology. This triggers the Modified Early Warning Score (MEWS) calculation module to obtain the patient's risk score. and initial damage pattern This step provides precise patient-side input for path planning.

[0056] Step 3: Based on the risk score, damage mode, and dynamic resource status model, determine the receiving unit and expected disposal path through algorithm calculation.

[0057] This step utilizes the real-time resource data provided in step 1 and the patient information provided in step 2 for intelligent decision-making. It overcomes the limitations of traditional triage, which relies on static information and human experience, and achieves precise resource matching based on real-time context, improving the accuracy and timeliness of decision-making.

[0058] To further enhance the robustness of data synchronization, in this embodiment, step 1 is specifically implemented in the following way:

[0059] Multiple medical business systems are connected via pre-defined heterogeneous data interfaces (HL7 and FHIR standard interfaces are used in this embodiment), and Kafka message queues are used as middleware to subscribe to resource status change events (such as surgery start, bed occupancy, and equipment failure) of each system. Simultaneously, the system has a built-in semantic mapping dictionary to standardize heterogeneous data. For example, when the HIS system reports a bed status of Status=0, the interface layer maps it to the standard status State="FREE". This semantic mapping dictionary supports dynamic configuration; when a new heterogeneous system is connected, the mapping relationship between the new system's status code and the standard status code can be established through the management configuration interface and take effect in real time.

[0060] Using Kafka message queues as middleware decouples the system from various business systems, ensuring high throughput and low latency for data subscriptions, a key step in building millisecond-level dynamic awareness capabilities. Meanwhile, the built-in semantic mapping dictionary transforms unstructured, heterogeneous data sources into a standardized, computer-processable language, greatly enhancing the system's compatibility and scalability across different vendors and versions of medical systems.

[0061] To ensure the accuracy and reproducibility of the scoring and pattern inference, the specific rules for step 2 in this embodiment are as follows:

[0062] The risk score The system uses an automated calculation method based on the Modified Early Warning Score (MEWS). It collects heart rate (HR), systolic blood pressure (SBP), respiratory rate (RR), body temperature (T), and level of consciousness (AVPU). 3 points; if 2 points; if 3 points... Total score .

[0063] The damage mode The inference process employs a combination of rule engine and keyword matching. The system has a pre-defined "injury mechanism-damage pattern mapping table." For example, when NLP extracts the keywords "fall from height" and "abdominal tenderness" from the "injury mechanism" text, and the physiological parameters show "hypotension," the rule engine triggers rule ID: TRAUMA_005 to determine... The injury pattern is defined as "suspected rupture of abdominal organs". For example, if the injury mechanism includes "car accident" AND (systolic blood pressure <90 OR pulse >120), then the injury pattern is determined to be "severe multiple injuries".

[0064] To make path planning more scientific, in this embodiment, the algorithm calculation in step 3 specifically includes vector matching and graph search:

[0065] First, according to the damage pattern Query the "Damage Pattern-Resource Requirement Mapping Table" and map it to a patient requirement vector. , for example [Demand\_Type:OR,Demand\_Capability:3,Urgency:High].

[0066] Specifically, the "damage mode-resource requirement mapping table" is a pre-built structured dictionary used to convert medical diagnoses into computer-processable resource requirement parameters.

[0067] Table 1 shows some of the details of this mapping table:

[0068] Table 1 Damage Mode-Resource Demand Mapping Table (Fragment)

[0069] Damage Mode ID Damage mode name Core Resource Type (Type_ID) Minimum ability level (Min_Cap) Urg_Coeff Associated auxiliary devices (Aux_Eq) P_001 Suspected splenic rupture (active bleeding) 201 (Emergency Operating Room) 4 (Teams with associate professor or higher titles) 0.95 (Extremely High Risk) [Autologous blood transfusion machine, laparoscopy] P_002 Closed head injury (GCS < 8) 105 (CT Room - Head) 3 (Attending physician and above) 0.80 (High Risk) [Transport ventilator] P_003 Open tibia and fibula fracture 205 (Wound Cleaning and Suturing Room) 2 (Resident physicians and above) 0.40(normal) [C-arm X-ray machine]

[0070] Based on the injury pattern ID determined in step 2, the system directly indexes the corresponding row and extracts fields such as core resource type, minimum capability level, and urgency coefficient, which serve as the foundational data for constructing the patient needs vector.

[0071] Secondly, the capability vector of each resource node is extracted from the dynamic resource state model. .

[0072] To achieve accurate mathematical calculations, this embodiment uses the "patient demand vector" ( ) and "Resource Capability Vector" The dimensions were clearly defined and quantized. Both vectors were normalized to 5-dimensional feature vectors, specifically defined as follows:

[0073] Dimension 1: Resource Category Matching Degree )

[0074] Definition: A variant that employs one-hot coding or hierarchical coding.

[0075] Quantification formula: If the type ID of a resource node matches the Type_ID in the requirement table (or belongs to its subclass), then ;otherwise This dimension serves as a hard constraint; if the product is 0, it will be directly filtered out.

[0076] Dimension 2: Ability Level )

[0077] Definition: A quantitative value of medical service capacity.

[0078] Quantification formula: Map the doctor's title or equipment precision to integers from 1 to 5 and normalize them.

[0079]

[0080] (For example: Chief Physician = 5, Deputy Chief Physician = 4, Attending Physician = 3...).

[0081] Dimension 3: Time urgency / availability )

[0082] Definition: Reflects the matching status of time requirements.

[0083] Quantification formula:

[0084] (From the mapping table, range 0-1)

[0085] This formula uses a logarithmic function to smooth out the effect of the number of people in the queue; the longer the queue, the lower the score.

[0086] Dimension 4: Physical Proximity )

[0087] Definition: Reflects the distance advantage between the resource location and the patient's current location.

[0088] Quantification formula:

[0089] (Ideally, the distance is 0)

[0090] Distance is the shortest path distance calculated based on the edge attribute weight (physical distance) in the graph database.

[0091] Dimension 5: Auxiliary equipment satisfaction rate )

[0092] Definition: Whether the necessary associated auxiliary equipment is ready.

[0093] Quantification formula:

[0094]

[0095]

[0096] in This represents the number of available auxiliary devices associated with this resource node. This represents the total number of devices in the demand list.

[0097] Based on the definitions of the above five dimensions, the system performs cosine similarity calculation or weighted Euclidean distance calculation to obtain an accurate matching degree.

[0098] Then, the weighted cosine similarity algorithm is used to calculate the matching degree between the two. (Also recorded as) ):

[0099] Finally, based on the matching degree, an improved Dijkstra's algorithm is used to find the optimal path with the minimum total cost. .

[0100] In graph search algorithms, each edge Weight (cost) Calculated using the following formula:

[0101]

[0102] in:

[0103] This is the estimated transit time based on physical distance (calculated via the :NEXT_TO edge);

[0104] The estimated queuing time for the target node (obtained from the node's status_timeline attribute);

[0105] The matching degree of the target resource (i.e., the matching degree calculated above) );

[0106] The weighting coefficients are preset, and in this embodiment, the preferred coefficients are... .

[0107] The goal of the above algorithm is to find a path. , making Minimum.

[0108] This method transforms the complex medical matching problem into a computable mathematical model. Compared with traditional rule matching, it can handle multi-dimensional constraints more accurately, thereby generating the globally optimal treatment path and improving the scientific nature and accuracy of the emergency response process.

[0109] To address the response latency issue, this embodiment also includes step 4:

[0110] Step 4: Initiate resource scheduling instructions and key medical examination instructions in parallel; monitor the feedback results of the key medical examinations in real time, and decide whether to confirm the current path or trigger path adjustment based on the matching degree between the feedback results and the expected treatment path.

[0111] The above approach transforms the traditional serial process of "waiting-decision-scheduling" into an asynchronous process of "scheduling and checking in parallel," allowing the resource preparation process and the diagnostic verification process to overlap on the timeline, significantly reducing I / O waiting time and improving the response speed of the emergency response process from the software architecture level.

[0112] It should be noted that, to ensure medical safety and avoid unnecessary radiation or contraindication risks caused by automated processes, a security gateway module is built into the system before parallel instructions are issued. This module executes the following logic:

[0113] Automatic contraindication screening: The system retrieves the patient's historical electronic medical record (EMR) data to check whether there are any absolute contraindications to the proposed examination. For example, for a patient scheduled for enhanced CT, the system will automatically check their most recent renal function data (such as eGFR value) and history of contrast agent allergy; if any abnormalities are found, the system will automatically intercept the parallel instruction and issue a pop-up warning.

[0114] Radiation dose threshold control: The system calculates the patient's cumulative radiation exposure over a period of time. If the current examination will cause the total amount to exceed the limit, an early warning will be triggered, and the procedure can only be performed after authorization from a senior physician.

[0115] Lightweight doctor confirmation: For high-risk or high-cost examinations, the system pushes a "one-click confirmation" card to the attending physician's mobile terminal. Only after the doctor quickly authorizes the procedure through biometrics (such as fingerprints) will the system actually use asynchronous I / O technology to issue instructions.

[0116] Only after all the above security constraints are met will the system proceed to the next step of the monitoring and adjudication process.

[0117] To achieve an intelligent closed-loop process, in this embodiment, the real-time monitoring and adjudication in step 4 are implemented in the following ways:

[0118] Asynchronous I / O and multi-threaded event listening are implemented using the Java-based CompletableFuture framework. Simultaneously, automatic adjudication is performed by calculating the feature similarity between feedback data and the expected model, specifically employing a hybrid algorithm. This algorithm includes the following steps:

[0119] Keyword matching: Utilizing regular expressions to extract key medical entities from the examination report text. For example, if the expected injury pattern contains the word "spleen," and the report text contains keywords such as "spleen" or "spleen," then the keyword matching score will be... ,otherwise .

[0120] Semantic vector computation: If Then, the pre-trained medical BERT model is invoked. The expected injury description text is then used. and inspection report text Inputting each element into the model yields a 768-dimensional semantic vector. The cosine similarity between two vectors is calculated as a semantic score. .

[0121] Overall assessment: Final match rate In some embodiments, the weighting coefficient It can be set to any value between 0.3 and 0.5. It can be set to any value between 0.5 and 0.7, and is preferred in this embodiment. .

[0122] Threshold decision: If If the value is greater than a preset threshold, it is considered a "match" and path confirmation is triggered; if If the value is within the preset threshold range, it is judged as "suspected" and manual review is triggered; if... If the value is below a preset threshold, it is determined to be a "mismatch," triggering a path adjustment. Specifically, the system marks the currently mismatched resource node as unavailable and, starting from the current patient's location, re-invokes the path planning algorithm from step 3 to generate a new treatment path. In some embodiments, the preset threshold can be set to any value between 0.8 and 0.9; in this embodiment, the preferred threshold is 0.85.

[0123] It should be noted that the aforementioned weighting coefficients and preset thresholds are configurable, and their specific values ​​directly affect the system's sensitivity and accuracy. For example, setting the preset threshold S higher (e.g., 0.9) will improve the accuracy of the system's automatic decision-making and reduce false positives, but may increase the number of "suspected" cases requiring manual review, thus increasing the workload of maintenance personnel. Conversely, setting the threshold lower (e.g., 0.8) will increase the degree of automation, but may reduce the accuracy of the decision-making. In battlefield or disaster scenarios where medical resources are extremely scarce, the threshold can be set at a lower level (e.g., 0.6) to prioritize ensuring that the wounded can be quickly admitted to the hospital rather than pursuing the best match. Those skilled in the art can weigh and optimize the threshold within the range of 0.8 to 0.9 based on the hospital's specific maintenance capabilities, expectations for the degree of automation, and the statistical characteristics of historical data to achieve the best technical effect. This threshold range (0.8-0.9) is based on statistical analysis of thousands of historical emergency examination reports and final diagnostic results, aiming to balance the accuracy and recall rate of automatic decision-making.

[0124] First, by constructing a dynamic resource state model based on a time-series graph database, millisecond-level real-time synchronization of heterogeneous medical data was achieved, solving the problem of decision-making lag caused by information silos in existing technologies. Second, by introducing a concurrent mechanism of parallel initiation and intelligent adjudication, the response time of the emergency procedure was significantly shortened, and the system's concurrent processing capability was improved. Finally, by vectorizing patient needs and resource capabilities and using a graph search algorithm for path planning, the quantitative calculation of complex medical constraints was achieved, improving the scientific nature and accuracy of the emergency procedure.

[0125] Example 2: This example provides a system for processing trauma emergency data.

[0126] This embodiment provides a trauma emergency data processing system for implementing the method described in Embodiment 1. The system solves the technical problems of non-real-time data processing and process response delay through modular design and clear inter-module interaction.

[0127] This system is deployed on a server cluster in the hospital's emergency command center. In a preferred deployment, the resource status aggregation module and risk assessment module can be deployed on a separate data acquisition server to achieve highly available data access. The path planning module and parallel decision-making module, as the core of the computation, can be deployed on a high-performance computing server cluster, with the computational pressure distributed through a load balancing mechanism. The modules communicate synchronously via gRPC or RESTful APIs. For real-time status pushes with large data volumes, asynchronous communication using a Kafka message queue is employed to ensure high concurrency and low response latency.

[0128] This system includes:

[0129] The resource status aggregation module performs the function of step 1 in Example 1. This module collects multi-source data in real time through a preset heterogeneous data interface and constructs a dynamic resource status model based on a time-series graph database. The module pushes the constructed dynamic resource status model data stream, which includes structured information such as node ID, resource type, real-time status, location information, and capability vectors, to the system's internal data bus in real time.

[0130] The risk assessment module performs the function of step 2 in Example 1. This module acquires multi-source patient information through the IoT gateway, calculates risk scores and injury patterns, and sends the generated patient assessment data stream, which includes patient ID, risk score, injury pattern, key vital signs, and other information, to the data bus.

[0131] The path planning module subscribes to the dynamic resource status model and patient assessment information in the data bus. When new patient assessment information is received, the module immediately triggers path calculation, determines the optimal receiving unit and treatment path through an algorithm, and sends the calculation results (a data stream of the expected treatment path containing information such as the target receiving unit ID, expected path node sequence, and estimated time) to the parallel decision-making module through the data bus.

[0132] The parallel adjudication module performs the function of step 4 in Example 1. This module receives the expected treatment path from the path planning module and initiates resource scheduling and medical examination instructions in parallel via an asynchronous task scheduler. The feature similarity calculator within this module monitors examination feedback in real time, performs automatic adjudication, and sends the final adjudication result (confirmed path or adjusted path data stream) to the collaborative execution module (not shown in the figure, but part of the management module). If the adjudication result is path adjustment, this module also sends a recalculation request containing the "avoidance node ID" back to the path planning module, triggering path recalculation.

[0133] The aforementioned modules are decoupled and communicate efficiently via a data bus, working collaboratively to form a dynamic and intelligent trauma emergency treatment system. The resource status aggregation module is the core solution to the real-time data synchronization problem, providing real-time and accurate data input for the entire system. The risk assessment and path planning modules utilize real-time data to make intelligent decisions. The parallel adjudication module further reduces process response time through optimized software architecture. This system, through a clear modular interaction mechanism, achieves the same technical effects as the method in Example 1, providing stable and reliable technical support for trauma emergency treatment.

[0134] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. 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 Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0135] 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 method for processing trauma emergency data, characterized in that, include: Step 1: Collect and aggregate resource status data from multiple dimensions in the medical environment in real time, and construct a dynamic resource status model based on a time-series graph database; wherein, the dynamic resource status model abstracts medical resources as nodes, the relationships between resources as edges, and maintains an attribute list with timestamps for each node to record the changes in resource status over time; Step 2: Obtain the patient's multi-source physiological parameters and injury mechanism information, and calculate the patient's risk score and injury pattern based on the preset scoring rules; Step 3: Based on the risk score, damage mode, and dynamic resource status model, the receiving unit and expected disposal path are determined through algorithm calculation.

2. The method for processing trauma emergency data according to claim 1, characterized in that, Step 1 further includes: Connect to multiple medical business systems through a preset heterogeneous data interface, and subscribe to change events of the resource status data; The received heterogeneous data is semantically mapped and standardized, and then updated to the corresponding nodes and timestamped attribute list in the time series graph database.

3. The method for processing trauma emergency data according to claim 1, characterized in that, In step 3, the receiving unit and the expected processing path are determined by algorithm calculation, including: The patient's injury pattern is mapped to a patient demand vector, and the capability vector of the resource node is extracted from the dynamic resource state model. Construct a five-dimensional feature space that includes resource category matching degree, capability level, time urgency, physical proximity, and auxiliary equipment satisfaction rate; The matching degree between the patient demand vector and the resource capability vector is calculated based on the five-dimensional feature space. ; The optimal path is found using a graph search algorithm, where the weight of each edge in the path is... Calculate using the following formula: in, The estimated transit time is based on physical distance. The estimated queuing time for the target node. These are the preset weighting coefficients.

4. The method for processing trauma emergency data according to claim 1, characterized in that, Also includes: Step 4: Perform security constraint verification. After the verification is passed, initiate resource scheduling instructions and key medical examination instructions in parallel. Monitor the feedback results of the key medical examinations in real time, and decide whether to confirm the current path or trigger path adjustment based on the matching degree between the feedback results and the expected treatment path.

5. The method for processing trauma emergency data according to claim 4, characterized in that, Step 4, in which real-time monitoring and adjudication are performed, includes: By utilizing asynchronous I / O and multi-threaded event listening techniques, the resource preparation process and the diagnostic verification process can overlap on the timeline; An automatic decision is made by calculating the similarity between the data features of the feedback results and the features of the expected damage pattern.

6. The method for processing trauma emergency data according to claim 5, characterized in that, The calculation of feature similarity includes: A keyword matching algorithm is used to calculate the keyword matching score between the feedback result and the expected damage pattern; A pre-trained semantic vector model is used to calculate the semantic vector scores of the feedback result and the expected damage pattern. The keyword matching score and semantic vector score are weighted and summed according to preset weights to obtain the final matching degree.

7. A trauma emergency data processing system, characterized in that, include: The resource status aggregation module is used to collect and aggregate resource status data from multiple dimensions in the medical environment in real time, and to build a dynamic resource status model based on a time-series graph database. The dynamic resource status model abstracts medical resources as nodes, the relationships between resources as edges, and maintains a list of attributes with timestamps for each node to record the changes in resource status over time. The risk assessment module is used to acquire multi-source physiological parameters and injury mechanism information of patients, and calculate the patient's risk score and injury pattern based on preset scoring rules; The path planning module is used to determine the receiving unit and the expected disposal path through algorithm calculation based on the risk score, damage mode and dynamic resource status model.

8. The trauma emergency data processing system according to claim 7, characterized in that, Also includes: The parallel adjudication module is used to initiate resource scheduling instructions and key medical examination instructions in parallel; monitor the feedback results of the key medical examinations in real time, and adjudicate and confirm the current path or trigger path adjustment based on the matching degree between the feedback results and the expected treatment path.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the trauma emergency data processing method as described in any one of claims 1-6.

10. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to implement the steps of the trauma emergency data processing method as described in any one of claims 1-6 when executing the executable instructions.

Images