ICU data security sharing exchange method and system

Abstract

This invention relates to the field of data analysis technology, specifically disclosing a method and system for secure sharing and exchange of ICU data. The method and system are characterized by the following steps: Patient status data is input into a pre-built clinical pathway prediction model to generate predicted pathway data; based on key department identifiers in the predicted pathway data, a pre-authorization token is generated for each key department identifier, and the generated pre-authorization token is sent to the corresponding department's server; according to the pre-authorized data range identifier, matching target patient data is filtered from the patient status data, and the target patient data is pre-fetched to the edge cache node corresponding to the department server; access intent data is extracted from data access requests; it is determined whether there is a target pre-authorization token that matches the department identifier and is in a valid state; and it is determined whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token. The advantage is that it improves the efficiency of secure data sharing and exchange.

Description

Technical Field

[0001] This application relates to the field of data analysis technology, and in particular to a method and system for secure sharing and exchange of ICU data. Background Technology

[0002] In clinical practice within the Intensive Care Unit (ICU), efficient and secure data sharing is the lifeline supporting multidisciplinary collaboration and timely intervention. Traditional data access mechanisms typically follow a passive response model, where the system only performs real-time identity verification, permission checks, and data retrieval when doctors need to access patient information. While this model may function adequately in routine scenarios, its inherent lag and rigid processes have become a critical bottleneck restricting the efficiency of resuscitation and the improvement of medical quality in the rapidly changing environment of the ICU. The existing technological framework struggles to meet the extreme real-time requirements of ICU data, constituting a core contradiction that urgently needs to be addressed.

[0003] The drawbacks of existing technology are primarily manifested in the significant delays caused by its serialized processing flow. When a doctor, such as a cardiac surgeon, needs to assess a patient's coagulation function and echocardiogram results during an emergency consultation, their access request must sequentially pass through multiple checkpoints, including identity verification, role-based access control, and authorization of specific data items. Each step involves interaction with the central server, logical judgment, and response return, and the accumulated delay throughout the process can reach minutes. In the ICU, where time is of the essence for saving lives, these few minutes of waiting can mean missing a critical decision window, leading to delays in clinical intervention. Secondly, this model lacks foresight regarding clinical workflow. The system responds to requests entirely passively, unable to prepare a green channel for data access for the most likely intervention team based on the patient's current severe condition and clear evolution trajectory. Every access, no matter how urgent, requires repeating the entire authorization process, consuming valuable system resources and the time and energy of medical staff.

[0004] A deeper flaw lies in the severe disconnect between this static authorization mechanism and the dynamic complexity of clinical pathways. A patient's condition can have a potentially directional progression; for example, a severe infection may rapidly advance to respiratory failure or septic shock. However, traditional systems cannot proactively predict the next few hours' treatment stage and required support departments based on current diagnoses and examination results. Therefore, the system cannot proactively deploy temporary data access permissions for respiratory therapists or nephrologists in advance, nor can it pre-store critical imaging reports and vital sign trend data on network nodes near their work areas. As a result, data remains in a remote standby state, unable to be prepared in person. Every critical cross-departmental data retrieval involves unnecessary network round trips and processing delays, failing to deeply integrate information technology with clinical early warning mechanisms.

[0005] To address the aforementioned issues, there is an urgent need in this field for a novel data sharing and exchange method that can deeply integrate clinical medical knowledge and information technology, transform passive response into proactive preparation, and significantly reduce the latency of critical data access in intensive care scenarios while ensuring safety. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides a method and system for secure sharing and exchange of ICU data.

[0007] Firstly, this application provides a method for secure sharing and exchange of ICU data, comprising the following steps: Step 1: Obtain the patient status data corresponding to the patient. The patient status data includes at least the current diagnosis data, examination result data, and treatment history data. Step 2: Input the patient status data into the pre-built clinical pathway prediction model to generate predicted pathway data; wherein, the clinical pathway prediction model is built based on the ICU domain knowledge graph, and the predicted pathway data includes at least one predicted treatment stage that the patient will enter within a preset time period in the future, at least one corresponding key department identifier, and the associated probability; Step 3: Based on the key department identifiers in the predicted path data, generate a pre-authorization token for each key department identifier and send the generated pre-authorization token to the department server of the corresponding department; wherein, each pre-authorization token is associated with at least one patient identifier, one department identifier, one pre-authorized data range identifier, and one validity period; Step 4: Based on the pre-authorized data range identifier, filter out matching target patient data from the patient status data, and prefetch the target patient data to the edge cache node corresponding to the department server; Step 5: Receive a data access request for the patient from the doctor's terminal, and extract access intent data from the data access request; wherein, the access intent data includes at least the department identifier of the doctor's terminal that initiated the request, the data type identifier of the requested access, and the patient identifier; Step 6: Determine whether there is a target pre-authorization token that matches the department identifier and is in a valid state, and determine whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token; Step 7: If all the above judgments are true, then obtain the prefetched data that matches the data type identifier and the patient identifier of the requested access from the edge cache node corresponding to the department server, and return the prefetched data to the doctor terminal.

[0008] Preferably, the step of inputting the patient status data into a pre-built clinical pathway prediction model to generate predicted pathway data is executed when a preset trigger condition is met; the preset trigger condition includes at least one of the following: the patient status data undergoes a predefined key indicator update, a manual trigger command is received, or a preset periodic execution time point is reached.

[0009] Preferably, the step of generating a pre-authorization token for each key department identifier based on the key department identifier in the predicted path data includes: For each key department identifier combined with the associated predicted treatment stage, the ICU domain knowledge graph is queried to obtain a set of predefined standard data items required for the key department identifier under the predicted treatment stage; The data types of the standard data item set are matched with those of the patient status data to obtain the intersection data item set; The set of intersecting data items is used as the identifier of the pre-authorized data range, and a pre-authorization token is generated by combining the patient identifier, the key department identifier, and the effective duration determined based on the predicted path data.

[0010] Preferably, the step of filtering matching target patient data from the patient status data according to the pre-authorized data range identifier, and pre-fetching the target patient data to the edge cache node corresponding to the department server includes: Based on each data item in the intersection data item set, the corresponding data content is filtered and extracted from the patient status data to form target patient data; The target patient data and the corresponding data item identifier are stored in the edge cache node in the form of key-value pairs, where the key is a combination of the patient identifier and the data item identifier.

[0011] Preferably, the step of determining whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token employs a semantic matching algorithm, which performs a synonym expansion comparison between the data type identifier of the requested access and the pre-authorized data range identifier.

[0012] Preferably, it also includes a token invalidation step: Continuously monitor the patient status data corresponding to each patient; When a change in the patient status data is detected, causing the clinical pathway prediction model to regenerate new predicted pathway data, and the difference between the new predicted pathway data and the predicted pathway data on which the currently valid pre-authorization token is based exceeds a preset threshold, all associated pre-authorization tokens are marked as invalid. When the validity period of any of the pre-authorized tokens expires, it is automatically marked as invalid.

[0013] Preferably, the clinical pathway prediction model is updated in the following ways: Collect historical ICU case data, each historical ICU case data includes a patient status data sequence arranged in time series and the actual treatment pathway sequence; The ICU domain knowledge graph is used to extract features and associate annotations on the patient status data sequence and the treatment path sequence to form a training sample set; The initial prediction model is trained and validated using the training sample set to obtain the clinical pathway prediction model.

[0014] Preferably, the association probability in the predicted path data is used to filter the key department identifiers, and only departments with an association probability greater than a preset probability threshold are identified as key department identifiers and used to generate the pre-authorization token.

[0015] Preferably, when it is determined that the data type identifier requested for access does not fall within the pre-authorized data range identifier, a regular authorization process is triggered. The regular authorization process includes: sending an authorization request containing complete access context information to the authorization server, and obtaining the requested data from the central medical data server after receiving an explicit authorization response from the authorization server.

[0016] Secondly, this application provides an ICU data secure sharing and exchange system, comprising: The data acquisition module is used to acquire patient status data corresponding to the patient, and the patient status data includes at least current diagnosis data, examination result data and treatment history data; The path prediction module is used to input the patient status data into a pre-built clinical path prediction model to generate predicted path data; wherein, the clinical path prediction model is built based on an ICU domain knowledge graph, and the predicted path data includes at least one predicted treatment stage that the patient will enter within a preset time period in the future, at least one corresponding key department identifier, and the associated probability; The token generation and distribution module is used to generate a pre-authorization token for each key department identifier based on the key department identifier in the predicted path data, and send the generated pre-authorization token to the department server of the corresponding department; wherein, each pre-authorization token is associated with at least a patient identifier, a department identifier, a pre-authorized data range identifier, and a validity period; The data prefetching module is used to filter out matching target patient data from the patient status data according to the pre-authorized data range identifier, and prefetch the target patient data to the edge cache node corresponding to the department server; The access intent extraction module is used to receive a data access request for the patient from a doctor's terminal and extract access intent data from the data access request; wherein, the access intent data includes at least the department identifier of the doctor's terminal that initiated the request, the data type identifier of the requested access, and the patient identifier. The access control module is used to determine whether there is a target pre-authorization token that matches the department identifier and is in a valid state, and to determine whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token; The data response module is used to retrieve prefetched data matching the data type identifier of the requested access and the patient identifier from the edge cache node corresponding to the department server when the judgment result of the access control module is yes, and return the prefetched data to the doctor terminal.

[0017] In summary, this application includes at least one of the following beneficial technical effects: 1. This application provides a secure data sharing and exchange method for ICU patients. By using a clinical pathway prediction model to proactively identify the most likely future treatment stages and key departments for patients, a pre-authorization token is generated and relevant data is pre-fetched to edge nodes. When doctors in the department need to access the data, the system does not need to perform a cumbersome real-time identity verification and permission check process. It only needs to quickly verify the validity of the pre-authorization token and the matching degree of the access intent to directly obtain the data from the near-end edge cache node. This fundamentally eliminates the minute-level delay caused by the traditional serialized authorization process, shortening the data access response time to the second or even millisecond level, providing crucial time assurance for the ICU's race-against-time rescue decisions. 2. This invention breaks away from the traditional static and rigid permission management model. Its authorization logic is tightly coupled with the dynamic and evolving predictive treatment path driven by the patient's real-time status. It can also use domain knowledge graphs to intelligently infer the required collaborative departments and data range for the next stage based on the current diagnosis and examination results. This enables refined and scenario-based pre-allocation of permissions, ensuring that just enough data access permissions are granted in advance to the departments that are most likely to need the data at the right time. This achieves accurate and efficient preparation under the premise of security. 3. By employing a dual mechanism of pre-authorization and edge prefetching, the real-time query pressure on the central server is effectively alleviated, improving the overall stability and scalability of the system. A large amount of frequently accessed data is prefetched to the edge cache nodes corresponding to each department, so that most data access requests can be satisfied at the edge layer, avoiding all requests from flooding the central medical data server. This significantly reduces the concurrent load and network bandwidth consumption of the core system, improves the overall throughput and stability of the system in a high-intensity ICU environment, and provides a technical foundation for supporting larger-scale ICU units or more complex data processing. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. 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.

[0019] Figure 1 This is a flowchart of the method for secure sharing and exchange of ICU data according to an embodiment of this application.

[0020] Figure 2 This is a schematic diagram of a system for secure sharing and exchange of ICU data according to an embodiment of this application. Detailed Implementation

[0021] The following is in conjunction with the appendix Figure 1-2 This application will be described in further detail.

[0022] Overview of this application: In existing technologies, medical data sharing within the Intensive Care Unit (ICU) largely relies on a passive response model of "request first, then authorize, then retrieve," making it difficult to balance real-time access with secure access management. In scenarios where a patient's condition changes rapidly and requires urgent multi-departmental collaboration, the sequential authorization and data retrieval processes of traditional methods result in significant access delays, failing to meet the time-sensitive needs of clinical decision-making. Existing systems cannot predict future treatment pathways based on the patient's real-time status, thus failing to pre-configure data access permissions and caching resources for potentially involved departments. This results in each critical data retrieval requiring a complete backend verification process, leading to inefficiency and an inability to adapt to dynamically changing clinical realities.

[0023] To address the aforementioned issues, analysis of clinical treatment processes revealed a potential temporal and logical correlation between the evolution of a patient's condition and the intervention needs of specific departments. Establishing a predictive model of patient status and clinical pathways allows for resource pre-configuration. The study found that a domain knowledge graph-based predictive model can effectively infer future key departments, and a pre-authorization mechanism can complete the security approval process in advance. However, a single static pre-authorization method poses security risks when the patient's condition changes. Therefore, a combined approach integrating predictive pathways, dynamic pre-authorization tokens, and edge data pre-fetching is proposed. Further system validation combines real-time patient status monitoring with an automatic token expiration mechanism to form a closed-loop access control system that balances security and efficiency.

[0024] Specifically, the system first acquires patient status data in real time, including diagnosis, examination results, and treatment history, and inputs it into a clinical pathway prediction model built on an ICU domain knowledge graph. This generates predicted pathway data containing predicted treatment stages, key department identifiers, and associated probabilities for a pre-defined time period. Subsequently, based on the predicted key department identifiers, the system dynamically generates a pre-authorization token for each department, associated with a specific patient, with a clearly defined data range and validity period, and distributes it to the corresponding department server. Simultaneously, based on the authorized data range in the token, the system extracts target data from the patient data and pre-fetches it to edge cache nodes near the department. When a doctor initiates an access request, the system extracts access intent data in real time and quickly determines whether a matching valid pre-authorization token exists and whether the request falls within the authorized data range. If both checks pass, data is returned directly from the edge cache node, achieving near real-time access. If checks fail or the system detects changes in the patient's condition causing the original predicted pathway to become invalid, the relevant token is automatically invalidated, and access is transferred to the regular authorization process, ensuring security.

[0025] Compared to existing technologies, traditional methods rely on static permission rules and passive response mechanisms, which cannot adapt to the dynamic and urgency-dependent nature of ICU clinical pathways, resulting in both access delays and rigid security. This solution innovatively integrates clinical pathway prediction, dynamic pre-authorization, and edge computing technologies. By proactively predicting treatment needs and pre-setting access resources, it moves the time-consuming processes of security verification and data retrieval to the forefront. Unlike existing fixed permission systems, this solution can dynamically generate, adjust, and revoke temporary access tokens based on the patient's real-time status, and achieve second-level data response through intent matching and cache hits. In the complex and ever-changing ICU environment, it simultaneously improves the timeliness of data sharing and the context-aware security of access control.

[0026] Example 1 This application discloses a method for secure sharing and exchange of ICU data.

[0027] Reference Figure 1A method for secure sharing and exchange of ICU data includes the following steps: Step 1: Obtain the patient status data corresponding to the patient. The patient status data includes at least the current diagnosis data, examination result data, and treatment history data. In this embodiment, patient status data is obtained by continuously or periodically collecting structured information reflecting the patient's latest condition from sources such as Hospital Information Systems (HIS), Laboratory Information Systems (LIS), and Picture Archiving and Communication Systems (PACS). This ensures the timeliness and completeness of the data upon which subsequent predictions and decisions are based, providing raw materials for constructing dynamic and accurate patient profiles. For example, for a patient with severe pneumonia, the data obtained in this step may include the diagnostic label of "severe pneumonia," the latest lung CT image storage path, the oxygen partial pressure and carbon dioxide partial pressure values ​​in the blood gas analysis report, and previous antibiotic usage records.

[0028] Step 2: Input the patient status data into the pre-built clinical pathway prediction model to generate predicted pathway data; wherein, the clinical pathway prediction model is built based on the ICU domain knowledge graph, and the predicted pathway data includes at least one predicted treatment stage that the patient will enter within a preset time period in the future, at least one corresponding key department identifier, and the associated probability; The purpose of the above steps is to leverage ICU domain knowledge graphs and machine learning models to prospectively infer the possible development of a patient's condition. The technical effect is to generate structured predictive paths, providing a clear and quantifiable basis for subsequent resource pre-configuration (pre-authorization, pre-caching). A key computational logic of the clinical pathway prediction model can be embodied in a probability assessment. For example, for a patient's state data feature vector X, the model calculates the joint probability P(S_i, D_j | X) of the patient entering the treatment stage S_i and requiring department D_j in the future. This probability is derived based on the strength of relationships between entities in the knowledge graph and statistical learning from historical case data. For example, the model might output predicted path data: within the next 48 hours, the probability of entering the "invasive mechanical ventilation" stage is 75%, and the key departments associated with this stage are "Respiratory and Critical Care Medicine" (probability 80%) and "Anesthesiology" (probability 65%).

[0029] Step 3: Based on the key department identifiers in the predicted path data, generate a pre-authorization token for each key department identifier and send the generated pre-authorization token to the department server of the corresponding department; wherein, each pre-authorization token is associated with at least one patient identifier, one department identifier, one pre-authorized data range identifier, and one validity period; The purpose of the above technical solution is to create temporary, limited data access permissions for the departments most likely to participate in diagnosis and treatment based on the prediction results. The technical effect is to complete the authorization process in advance, under safe and controllable conditions, thus separating the authorization time from real-time verification and accelerating subsequent access. The pre-authorized data scope identifier is not arbitrarily assigned, but is determined by the system based on the key department identifier, querying the set of typical necessary data items for that department in the corresponding predicted diagnosis and treatment stage as defined in the ICU domain knowledge graph. For example, the token generated for "Respiratory and Critical Care Medicine" may have its data scope limited to "blood gas analysis report," "chest imaging," "ventilator parameters," and "complete blood count."

[0030] Step 4: Based on the pre-authorized data range identifier, filter out matching target patient data from the patient status data, and prefetch the target patient data to the edge cache node corresponding to the department server; The aforementioned technical solution proactively pushes the latest relevant patient data from the central server to edge nodes closer to the target department, based on the data range specified by the pre-authorization token. The technical effect is a significant reduction in network transmission latency for data retrieval, ensuring that data is already locally or nearby when access occurs. This is the main contributing factor to reducing overall access latency from minutes to seconds. For example, the system pre-stores the patient's latest blood gas analysis PDF report and thumbnails or key diagnostic descriptions of CT images in the edge server cache of the network area where the respiratory physician's workstation is located.

[0031] Step 5: Receive a data access request for the patient from the doctor's terminal, and extract access intent data from the data access request; wherein, the access intent data includes at least the department identifier of the doctor's terminal that initiated the request, the data type identifier of the requested access, and the patient identifier.

[0032] Step 6: Determine whether there is a target pre-authorization token that matches the department identifier and is in a valid state, and determine whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token; The above technical solution enables dual verification in a very short time: first, identity and basic permission verification (by matching department identifiers and token validity); second, refined access intent verification (by matching data ranges). The technical effect is to achieve rapid "intent-aware" authorization, allowing access only to those falling within the predicted range, thus ensuring the security of the pre-authorization mechanism. To determine whether an access falls within the range, in addition to precise string matching, semantic matching algorithms can be used. For example, based on a medical ontology terminology, "cardiac ultrasound" and "echocardiography" can be identified as the same data type.

[0033] Step 7: If all the above judgments are true, then obtain the prefetched data that matches the data type identifier of the requested access and the patient identifier from the edge cache node corresponding to the department server, and return the prefetched data to the doctor terminal. The purpose of this technical solution is to quickly retrieve data from the nearest cache and return it after access is granted. The technical effect is to achieve a response time of seconds for authorized access, meeting the real-time requirements of ICU clinical decision-making. Because the data is already on the edge node, the complex queries and cross-network transmission processes from the remote central database are avoided, thus achieving extremely low access latency. For example, when a pulmonologist clicks to view a patient's blood gas report, the system no longer needs to query and wait for the central database; instead, it directly reads the pre-fetched latest report file from the department's edge cache and displays it.

[0034] In the above technical solution, patient status data refers to a set of structured information that reflects the current vital signs and medical progress of critically ill patients and is obtained in real time or near real time from the hospital information system. Specifically, it may include the current diagnosis code from the electronic medical record, the numerical values ​​and reports of blood gas analysis / complete blood count and other test results from the laboratory information system, the CT / MRI image index links from the image archiving system, and the treatment history summary from the nursing record, which is used to provide dynamic and multi-dimensional data input for clinical pathway prediction. The clinical pathway prediction model is a computational model that integrates ICU knowledge graphs and machine learning algorithms. Specifically, it can be trained using historical ICU case data. Its knowledge graph defines the logical and probabilistic relationships between medical entities such as diseases, symptoms, examinations, treatments, and departments, used to infer the most likely future disease progression path based on the current patient's state. The core computational logic of this model can be expressed as calculating the conditional probability P, that is, given the current patient state, predicting the joint probability that the patient will enter a specific treatment stage and require intervention from a specific department within a predetermined time period (e.g., 24-72 hours).

[0035] The predicted path data refers to the structured prediction results output by the clinical path prediction model. Specifically, it includes one or more predicted treatment stages ranked by probability, key department identifiers associated with each stage, and their association probabilities, which serve as the basis for pre-authorized resource allocation decisions. The association probability not only represents the likelihood but can also be used for filtering in the implementation, for example, only processing departments with probabilities exceeding a preset threshold.

[0036] A pre-authorization token is a digital authorization credential with time and scope limitations. Specifically, it can employ a data structure containing a token ID, patient identifier, department identifier, pre-authorized data scope identifier, and validity period. Generated and distributed by a central access control system, it is used to pre-grant a designated department temporary access to specific patient data within a specific time window. Its validity period typically matches the future time period covered by the predicted path.

[0037] The pre-authorized data scope identifier is a set of identifiers that specify the specific data types that the token is authorized to access. Specifically, it can be determined by querying the "typical necessary data items" of the department in the ICU domain knowledge graph under the predictive treatment stage, and taking the intersection with the data types that the patient currently has, in order to ensure that the authorization meets clinical needs without exceeding the necessary scope.

[0038] Edge cache nodes refer to dedicated data cache servers deployed within or physically adjacent to the target department's local area network. These can be implemented using a high-performance in-memory database and are used to temporarily store patient data pre-fetched based on pre-authorization tokens. Data is stored in key-value pairs, for example, the key is "Patient ID: Data Category," and the value is the specific data content or a quick access link, aiming to achieve localized and fast data retrieval.

[0039] Among them, access intent data refers to the core metadata parsed from the original data access request initiated by the doctor's terminal. Specifically, it includes the initiating department identifier, the data type identifier of the requested access (such as "query ECG report"), and the target patient identifier obtained by parsing HTTP request or API call parameters, which are used for quick matching and verification with the pre-authorization token.

[0040] The matching process for determining whether something falls within the specified range refers to comparing the data type identifier in the access intent data with the data range identifier in the pre-authorization token. Besides precise string matching, the core of this process lies in employing semantic matching algorithms. For example, it can expand the terminology using synonyms and hyponyms based on a medical ontology database, enabling a "cardiac ultrasound" request to match the authorization for "cardiac ultrasound" in the token. This achieves a more intelligent and flexible matching that aligns with clinical terminology.

[0041] The core innovation of this application lies in constructing a proactive data pre-authorization and distribution closed-loop system based on clinical pathway prediction. It overturns the traditional passive security model of "request-response-authorization" by proactively predicting treatment needs and pushing data permissions and the data itself to the edge nodes of clinical departments most likely to require it. When the predicted access occurs, the system does not need complex real-time permission verification and remote data retrieval; it only needs to complete a quick token and intent matching to return the data from the local cache in milliseconds, thereby reducing the latency of critical data access from minutes to seconds. Simultaneously, data security is ensured through the limitation of the prediction range and a dynamic invalidation mechanism.

[0042] The working process and principle of this application are as follows: First, the system continuously acquires real-time patient status data and inputs it into a clinical pathway prediction model built on an ICU knowledge graph, generating predicted pathway data containing future key departments and probabilities. Based on this prediction, the system proactively generates a pre-authorization token with a specific data range identifier and valid duration for each high-probability key department and distributes it to the corresponding department server. Simultaneously, based on the range identifier in the token, the latest patient-related data is pre-fetched from the central system to the local edge cache nodes of each department. When a doctor initiates a data access request, the system extracts the access intent and quickly verifies whether a valid, department-matching pre-authorization token exists, and whether the requested data type falls within the pre-authorization range. If the verification passes, data is directly returned from the local edge cache node, achieving a rapid response; if the verification fails, the process is transferred to the regular authorization process. Furthermore, the system continuously monitors the patient's status. If changes in the patient's condition lead to an update of the predicted pathway, the original pre-authorization token will automatically become invalid, thus forming a secure and efficient closed loop of "prediction-pre-setting-rapid response-dynamic adjustment".

[0043] Furthermore, the step of inputting the patient status data into the pre-built clinical pathway prediction model to generate predicted pathway data is executed when preset trigger conditions are met; the preset trigger conditions include at least one of the following: the patient status data undergoes a predefined key indicator update, a manual trigger command is received, or a preset periodic execution time point is reached.

[0044] The purpose of adopting the above technical solution is to avoid unnecessary and frequent prediction calculations by defining clear triggering rules, thereby saving computing resources and enabling timely prediction at sensitive moments when the patient's condition may change. For example, the preset "key indicator update" may include "arterial blood oxygen partial pressure (PaO2) decreases beyond a preset threshold" or "newly reported chest CT shows significant expansion of pulmonary infiltrates." Once such an update is detected, the model is immediately triggered to re-predict, thereby dynamically adjusting the pre-authorization strategy.

[0045] Furthermore, the step of generating a pre-authorization token for each key department identifier based on the key department identifier in the predicted path data includes: For each key department identifier combined with the associated predicted treatment stage, the ICU domain knowledge graph is queried to obtain a set of predefined standard data items required for the key department identifier under the predicted treatment stage; In this embodiment of the application, the set of standard data items can be pre-configured in the knowledge graph by clinical experts according to the diagnosis and treatment guidelines. For example, the set of standard data items configured for "cardiology" may include "electrocardiogram", "myocardial enzyme spectrum", "echocardiography" and "coronary angiography report".

[0046] The data types of the standard data item set are matched with those of the patient status data to obtain the intersection data item set; Specifically, pre-authorization and pre-fetching are only performed on data that the patient actually has and that the department needs. This avoids granting authorizations for examinations the patient has not yet undergone or attempting to pre-fetch data that does not exist, thereby improving the robustness of the solution and the efficiency of resource utilization. For example, if the standard data item set includes "cardiac ultrasound," but the patient has not currently undergone this examination, then the intersection data item set will not include this item, and the system will not generate an invalid authorization or initiate an invalid pre-fetch request for it. The set of intersecting data items is used as the identifier of the pre-authorized data range, and a pre-authorization token is generated by combining the patient identifier, the key department identifier, and the effective duration determined based on the predicted path data.

[0047] The purpose of the above technical solution is to create a lightweight digital credential containing all necessary security and contextual information. The validity period can be directly correlated with the time window covered by the predicted path; for example, if the next 72 hours are predicted to be a critical period, the token's validity period is set to 72 hours. The generated token is a structured data object, such as a JSON string, containing all the aforementioned fields, which can be quickly verified in subsequent processes.

[0048] Furthermore, the step of filtering matching target patient data from the patient status data based on the pre-authorized data range identifier, and pre-fetching the target patient data to the edge cache node corresponding to the department server, includes: Based on each data item in the intersection data item set, the corresponding data content is filtered and extracted from the patient status data to form target patient data; The target patient data and the corresponding data item identifier are stored in the edge cache node in the form of key-value pairs, where the key is a combination of the patient identifier and the data item identifier.

[0049] Furthermore, the step of determining whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token employs a semantic matching algorithm, which performs a synonym expansion comparison between the data type identifier of the requested access and the pre-authorized data range identifier.

[0050] The purpose of the above technical solution is to address the issue of multiple expressions for the same examination or concept in clinical practice, making the matching more consistent with clinical reasoning. Alternative technical approaches include terminology standardization and relational reasoning based on medical ontology, or using word vector models to calculate semantic similarity. For example, when a doctor requests an "echocardiogram" report, the semantic matching algorithm can identify it as the same concept as "cardiac ultrasound" or "echocardiography" in the pre-authorized scope identifier, thus determining a successful match.

[0051] Furthermore, it also includes a token invalidation step: Continuously monitor the patient status data corresponding to each patient; Continuous monitoring of patient status data provides data support for determining whether a patient's condition has taken an unexpected turn. The system continuously listens to the patient status data stream and compares it with the data snapshot used to generate the current valid token; When a change in the patient status data is detected, causing the clinical pathway prediction model to regenerate new predicted pathway data, and the difference between the new predicted pathway data and the predicted pathway data on which the currently valid pre-authorization token is based exceeds a preset threshold, all associated pre-authorization tokens are marked as invalid. The purpose of the above technical solution is to promptly revoke pre-authorized permissions when a patient's condition deviates from the original predicted path, preventing abuse of privileges. The "difference exceeding a preset threshold" is the key dynamic adjustment logic. The threshold can be defined as a change in the set of key departments or a fundamental shift in the main treatment stage. For example, if the original prediction focused on respiratory support, but new data shows the patient has acute kidney injury requiring continuous renal replacement therapy, "nephrology" becomes a high-probability key department in the new predicted path, while the original "respiratory medicine" probability decreases. If this difference exceeds the threshold, all old tokens immediately become invalid. This ensures that the security strategy is dynamically updated as the patient's condition changes.

[0052] When the validity period of any of the pre-authorized tokens expires, it is automatically marked as invalid.

[0053] The purpose of employing the above technical solution is to prevent pre-authorized tokens from being retained for extended periods and potentially stolen; it serves as a fallback security measure. Once the validity period expires, the token automatically becomes invalid. Continued access requires triggering a new prediction and authorization process or following the regular authorization channel.

[0054] Furthermore, the clinical pathway prediction model is updated in the following ways: Collect historical ICU case data, each historical ICU case data includes a patient status data sequence arranged in time series and the actual treatment pathway sequence; The ICU domain knowledge graph is used to extract features and associate annotations on the patient status data sequence and the treatment path sequence to form a training sample set; The initial prediction model is trained and validated using the training sample set to obtain the clinical pathway prediction model.

[0055] Furthermore, the association probability in the predicted path data is used to filter the key department identifiers. Only departments with an association probability greater than a preset probability threshold are identified as key department identifiers and used to generate the pre-authorization token.

[0056] The purpose of this technical solution is to filter out departments that are predicted by the model but have a low probability of occurrence by setting a probability threshold, and only pre-allocate resources for high-probability events. The technical effect is to improve the accuracy of pre-authorization and pre-fetching operations, avoid wasting computational, storage, and network resources caused by preparing for low-probability events, and reduce unnecessary permission diffusion. For example, if the preset probability threshold is 60%, a token will be generated for "Anesthesiology" with a 65% correlation probability, but not for "Hematology" with a 40% correlation probability, unless subsequent changes in the patient's condition increase its probability.

[0057] Furthermore, when it is determined that the data type identifier requested for access does not fall within the pre-authorized data range identifier, a regular authorization process is triggered. The regular authorization process includes: sending an authorization request containing complete access context information to the authorization server, and obtaining the requested data from the central medical data server after receiving an explicit authorization response from the authorization server.

[0058] The purpose of the above technical solution is to handle access requests that fall outside the predicted range but are still potentially legitimate. This ensures the system's functional integrity and prevents necessary medical access from being blocked due to inaccurate predictions. The technical effect is that while pursuing high efficiency, the solution retains complete and rigorous traditional security processes as a backup, forming a flexible security system with both a "fast track" and a "standard track" operating in parallel. When the fast track verification fails, the system seamlessly switches to the standard track, providing dual protection for user experience and medical safety.

[0059] Example 2 This application also discloses an ICU data security sharing and exchange system.

[0060] Reference Figure 2An ICU data security sharing and exchange system includes: The data acquisition module is used to acquire patient status data corresponding to the patient, and the patient status data includes at least current diagnosis data, examination result data and treatment history data; The path prediction module is used to input the patient status data into a pre-built clinical path prediction model to generate predicted path data; wherein, the clinical path prediction model is built based on an ICU domain knowledge graph, and the predicted path data includes at least one predicted treatment stage that the patient will enter within a preset time period in the future, at least one corresponding key department identifier, and the associated probability; The token generation and distribution module is used to generate a pre-authorization token for each key department identifier based on the key department identifier in the predicted path data, and send the generated pre-authorization token to the department server of the corresponding department; wherein, each pre-authorization token is associated with at least a patient identifier, a department identifier, a pre-authorized data range identifier, and a validity period; The data prefetching module is used to filter out matching target patient data from the patient status data according to the pre-authorized data range identifier, and prefetch the target patient data to the edge cache node corresponding to the department server; The access intent extraction module is used to receive a data access request for the patient from a doctor's terminal and extract access intent data from the data access request; wherein, the access intent data includes at least the department identifier of the doctor's terminal that initiated the request, the data type identifier of the requested access, and the patient identifier. The access control module is used to determine whether there is a target pre-authorization token that matches the department identifier and is in a valid state, and to determine whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token; The data response module is used to retrieve prefetched data matching the data type identifier of the requested access and the patient identifier from the edge cache node corresponding to the department server when the judgment result of the access control module is yes, and return the prefetched data to the doctor terminal.

[0061] The above content is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described or use similar methods to replace them, as long as they do not deviate from the concept of the invention, they should all fall within the protection scope of the present invention.

[0062] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0063] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. A method for secure sharing and exchange of ICU data, characterized in that, Includes the following steps: Step 1: Obtain the patient status data corresponding to the patient. The patient status data includes at least the current diagnosis data, examination result data, and treatment history data. Step 2: Input the patient status data into the pre-built clinical pathway prediction model to generate predicted pathway data; wherein, the clinical pathway prediction model is built based on the ICU domain knowledge graph, and the predicted pathway data includes at least one predicted treatment stage that the patient will enter within a preset time period in the future, at least one corresponding key department identifier, and the associated probability; Step 3: Based on the key department identifiers in the predicted path data, generate a pre-authorization token for each key department identifier and send the generated pre-authorization token to the department server of the corresponding department; wherein, each pre-authorization token is associated with at least one patient identifier, one department identifier, one pre-authorized data range identifier, and one validity period; Step 4: Based on the pre-authorized data range identifier, filter out matching target patient data from the patient status data, and prefetch the target patient data to the edge cache node corresponding to the department server; Step 5: Receive a data access request for the patient from the doctor's terminal, and extract access intent data from the data access request; wherein, the access intent data includes at least the department identifier of the doctor's terminal that initiated the request, the data type identifier of the requested access, and the patient identifier; Step 6: Determine whether there is a target pre-authorization token that matches the department identifier and is in a valid state, and determine whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token; Step 7: If all the above judgments are true, then obtain the prefetched data that matches the data type identifier and the patient identifier of the requested access from the edge cache node corresponding to the department server, and return the prefetched data to the doctor terminal.

2. The ICU data secure sharing and exchange method according to claim 1, characterized in that, The step of inputting the patient status data into a pre-built clinical pathway prediction model to generate predicted pathway data is executed when preset trigger conditions are met; the preset trigger conditions include at least one of the following: the patient status data undergoes a predefined key indicator update, a manual trigger command is received, or a preset periodic execution time point is reached.

3. The ICU data secure sharing and exchange method according to claim 1, characterized in that, The step of generating a pre-authorization token for each key department identifier based on the key department identifier in the predicted path data includes: For each key department identifier combined with the associated predicted treatment stage, the ICU domain knowledge graph is queried to obtain a set of predefined standard data items required for the key department identifier under the predicted treatment stage; The data types of the standard data item set are matched with those of the patient status data to obtain the intersection data item set; The set of intersecting data items is used as the identifier of the pre-authorized data range, and a pre-authorization token is generated by combining the patient identifier, the key department identifier, and the effective duration determined based on the predicted path data.

4. The ICU data secure sharing and exchange method according to claim 3, characterized in that, The steps of filtering matching target patient data from the patient status data according to the pre-authorized data range identifier, and pre-fetching the target patient data to the edge cache node corresponding to the department server, include: Based on each data item in the intersection data item set, the corresponding data content is filtered and extracted from the patient status data to form target patient data; The target patient data and the corresponding data item identifier are stored in the edge cache node in the form of key-value pairs, where the key is a combination of the patient identifier and the data item identifier.

5. The ICU data secure sharing and exchange method according to claim 1, characterized in that, The step of determining whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token employs a semantic matching algorithm, which performs a synonym expansion comparison between the data type identifier of the requested access and the pre-authorized data range identifier.

6. The ICU data secure sharing and exchange method according to claim 1, characterized in that, It also includes a token invalidation step: Continuously monitor the patient status data corresponding to each patient; When a change in the patient status data is detected, causing the clinical pathway prediction model to regenerate new predicted pathway data, and the difference between the new predicted pathway data and the predicted pathway data on which the currently valid pre-authorization token is based exceeds a preset threshold, all associated pre-authorization tokens are marked as invalid. When the validity period of any of the pre-authorized tokens expires, it is automatically marked as invalid.

7. The ICU data secure sharing and exchange method according to claim 1, characterized in that, The clinical pathway prediction model is updated in the following ways: Collect historical ICU case data, each historical ICU case data includes a patient status data sequence arranged in time series and the actual treatment pathway sequence; The ICU domain knowledge graph is used to extract features and associate annotations on the patient status data sequence and the treatment path sequence to form a training sample set; The initial prediction model is trained and validated using the training sample set to obtain the clinical pathway prediction model.

8. The ICU data secure sharing and exchange method according to claim 1, characterized in that, The association probability in the predicted path data is used to filter the key department identifiers. Only departments with an association probability greater than a preset probability threshold are identified as key department identifiers and used to generate the pre-authorization token.

9. The ICU data secure sharing and exchange method according to claim 1, characterized in that, When it is determined that the data type identifier requested for access does not fall within the pre-authorized data range identifier, a regular authorization process is triggered. The regular authorization process includes: sending an authorization request containing complete access context information to the authorization server, and obtaining the requested data from the central medical data server after receiving an explicit authorization response from the authorization server.

10. An ICU data secure sharing and exchange system, applied to the ICU data secure sharing and exchange method described in any one of claims 1-9, characterized in that, include: The data acquisition module is used to acquire patient status data corresponding to the patient, and the patient status data includes at least current diagnosis data, examination result data and treatment history data; The path prediction module is used to input the patient status data into a pre-built clinical path prediction model to generate predicted path data; wherein, the clinical path prediction model is built based on an ICU domain knowledge graph, and the predicted path data includes at least one predicted treatment stage that the patient will enter within a preset time period in the future, at least one corresponding key department identifier, and the associated probability; The token generation and distribution module is used to generate a pre-authorization token for each key department identifier based on the key department identifier in the predicted path data, and send the generated pre-authorization token to the department server of the corresponding department; wherein, each pre-authorization token is associated with at least a patient identifier, a department identifier, a pre-authorized data range identifier, and a validity period; The data prefetching module is used to filter out matching target patient data from the patient status data according to the pre-authorized data range identifier, and prefetch the target patient data to the edge cache node corresponding to the department server; The access intent extraction module is used to receive a data access request for the patient from a doctor's terminal and extract access intent data from the data access request; wherein, the access intent data includes at least the department identifier of the doctor's terminal that initiated the request, the data type identifier of the requested access, and the patient identifier. The access control module is used to determine whether there is a target pre-authorization token that matches the department identifier and is in a valid state, and to determine whether the data type identifier of the requested access falls within the pre-authorized data range identifier associated with the target pre-authorization token; The data response module is used to retrieve prefetched data matching the data type identifier of the requested access and the patient identifier from the edge cache node corresponding to the department server when the judgment result of the access control module is yes, and return the prefetched data to the doctor terminal.

Images