Management control method of clinical blood transfusion electronic information system

Abstract

The invention discloses a management control method of a clinical blood transfusion electronic information system, and belongs to the technical field of clinical blood transfusion electronic information management.The method comprises the following steps that existing information of a patient is received, key information in data is extracted, unneeded blood products are excluded according to the key information, and the usable blood product range is obtained; real-time inventory data of the whole hospital and regional blood stations are called, and a data set containing available blood product information and geographic positions is generated. Through cooperation of multiple steps, the problems of lagging and idle reserved blood caused by the fact that all data need to be collected in a traditional process are solved, blood transfusion screening precision and resource echelon utilization are achieved, blood use safety and compliance are guaranteed, inventory turnover and allocation efficiency is improved, treatment time is shortened, process tracing is standardized, and the method is suitable for various clinical blood use scenes.

Description

Technical Field

[0001] This invention relates to the field of clinical transfusion electronic information management technology, and more specifically, to a management and control method for a clinical transfusion electronic information system. Background Technology

[0002] Traditional clinical blood transfusion procedures have significant shortcomings and are ill-suited to the core needs of efficient and safe clinical blood use. On the one hand, the traditional model typically requires the collection of all relevant patient data before a transfusion plan can be developed and implemented. This mechanism can easily lead to delays in blood screening and allocation processes, as well as hidden waste of medical resources. On the other hand, once blood products are approved and reserved for specific patients, there is a problem of delayed release. When a patient's treatment ends or their condition improves and they no longer need the blood, but before the blood has been physically released from storage, the reserved blood often cannot be identified and returned to the inventory in a timely manner. This results in the blood remaining locked up for a long time, occupying limited resources. This not only makes it difficult for other patients with urgent needs to access this blood, causing resource waste, but also further exacerbates the imbalance between clinical blood supply and demand, seriously affecting the overall efficiency and resource utilization of the transfusion process.

[0003] No effective solutions have yet been proposed to address the problems in the relevant technologies. Summary of the Invention

[0004] To address the problems in related technologies, this invention proposes a management and control method for a clinical transfusion electronic information system, which overcomes the problems of process delays caused by the need to collect all patient data and the idle resources and supply-demand imbalance caused by the failure to release reserved blood in a timely manner.

[0005] Therefore, the specific technical solution adopted by the present invention is as follows: A management and control method for a clinical transfusion electronic information system, comprising the following steps: S1. Receive existing patient information and extract key information from the data. Based on the key information, exclude unnecessary blood products to obtain the range of usable blood products. Call the real-time inventory data of the entire hospital and regional blood banks to generate a dataset containing information on available blood products and geographical locations. S2. After receiving the patient's subsequent examination information, input it into the system and match it within the generated range to determine the blood products that need to be used; S3. Based on the blood products to be used, the intelligent matching process is automatically triggered. First, all approved but not yet physically released planned reserved blood is scanned in real time and their status is evaluated. When it is determined that these reservations are overdue, they are integrated into a dynamic inventory pool. S4. Determine the patient's blood product needs and match them with the dynamic inventory pool. Perform combination optimization calculations through the matching algorithm to obtain blood product combination scheme A. When the inventory in the dynamic inventory pool is still insufficient after combination, automatically calculate the difference and retrieve the remaining quantity from the blood bank to generate blood product combination scheme B. S5. The combined solution is transmitted to the blood bank administrator. After the medical staff confirms the solution, the data-level replacement is automatically executed.

[0006] In a preferred embodiment, the steps of receiving existing patient information and extracting key information from the data, excluding unnecessary blood products based on the key information to obtain the range of usable blood products, and calling real-time inventory data from the entire hospital and regional blood banks to generate a dataset containing information on available blood products and their geographical locations include the following steps: S11. The system receives the patient's existing information, including the entered brief medical record, vital signs, chief complaint, and known medical history, and automatically extracts and identifies key safety parameters for preliminary screening of blood products, mainly including known blood type, clear history of serious adverse transfusion reactions, history of allergy to specific blood components, and contraindications that are highly suggested in clinical diagnosis. S12. Call the preset clinical blood use safety knowledge base and rule engine, compare the extracted key safety parameters with the rules, exclude unnecessary blood product types, and obtain the range of blood products. S13. Through the data interface, call and integrate the real-time inventory data of the hospital's blood bank and regional collaborative blood stations. This data includes not only available inventory, but also detailed information on all approved blood that has been reserved for other patients' plans but has not yet been physically released. S14. Associate the range of blood products with real-time inventory data to generate a detailed dataset containing each bag of blood products. The dataset includes the unique blood code, blood type, variety, blood volume, expiration date, current inventory location, and current status.

[0007] In a preferred embodiment, the step of receiving subsequent patient examination information, inputting it into the system, and matching it within the generated range to determine the blood products to be used includes the following steps: S21. Receive the results of subsequent key examinations of the patient and transmit them to the system. Automatically parse the data and extract the decisive parameters for accurate matching, including confirmed blood type, irregular antibody screening results, and specific component transfusion requirements. S22. Compare and filter within the dataset to extract the specific blood product data and geographical location data required.

[0008] As a preferred implementation, the automatic intelligent matching process based on the determined blood products to be used first scans all approved but not yet physically released planned reserved blood in real time and assesses their status. When it is determined that these reservations are overdue, they are integrated into a dynamic inventory pool, including the following steps: S31. Based on preset clinical rules for blood use reasons, including surgery, emergency rescue, and treatment of chronic anemia, the system automatically sets a differentiated reserved time window for each blood use application. S32. The system scans all planned reserved blood products in real time and assesses the blood status based on whether the associated reserved time window has expired and whether the associated clinical event has been clearly terminated. S33. When it is determined that a reserved blood product meets the conditions that the time window has passed and the clinical demand has ended, the status change process will be automatically triggered to directly change the reserved status of the blood from occupied to released. This status change operation will be fully recorded, including the triggering reason, timestamp, and associated original medical order, forming an immutable audit log for verification; S34. All blood products automatically marked as released will be integrated into the dynamic inventory pool. During integration, the original reserved patient, reason for release, and release time of each bag of blood products will be clearly marked.

[0009] In a preferred embodiment, the determination of a patient's blood product needs and matching them with a dynamic inventory pool, along with the execution of a combination optimization calculation using a matching algorithm to obtain blood product combination scheme A; when the inventory in the dynamic inventory pool is still insufficient after combination, the difference is automatically calculated, and the remaining quantity is retrieved from the blood bank to generate blood product combination scheme B, including the following steps: S41. After receiving a patient's blood use request that has been clinically approved, first match the specific requirements, including blood type, type, and quantity, with the dynamic inventory pool. At the same time, a verification request will be submitted simultaneously to determine whether the requested amount significantly exceeds the normal usage range based on the patient's diagnosis, weight, and current laboratory indicators. Abnormal requests will be marked and the blood use request will be suspended until manual review. S42. Summarize and judge the total amount of all blood units in the dynamic inventory pool that meet the blood type and variety requirements. If the total amount is sufficient, immediately call the combination optimization algorithm to calculate whether a single release unit can meet all the needs, or whether it is necessary to aggregate multiple release units from different sources for combination, select the optimal combination, and obtain blood product combination scheme A. S43. When the total amount in the dynamic inventory pool cannot meet the full amount requested, first calculate the difference between the variety and the quantity, and trigger the standard application process for this difference to generate a supplementary plan B for requisitioning blood from the central blood bank's regular inventory.

[0010] As a preferred implementation, the process of summarizing and judging the total amount of all blood units in the dynamic inventory pool that meet the blood type and variety requirements, and immediately invoking the combination optimization algorithm when the total amount is sufficient, calculates whether a single release unit can meet all the demand or whether it is necessary to aggregate multiple release units from different sources for combination, and selects the optimal combination to obtain blood product combination scheme A, including the following steps: S421. Perform a quick total quantity calculation for all blood units in the dynamic inventory pool that meet the current application, and compare it with the application total quantity. If the dynamic inventory total quantity is greater than the application total quantity, it is determined that the total quantity is sufficient. S422. Using a combinatorial optimization algorithm, perform a global scan and combination of all eligible blood units, calculate all combination methods, determine whether there is a single release unit inventory that can meet all the needs, and whether multiple units need to be combined, then list all combination schemes composed of units from different sources that can exactly meet the application quantity. S423. Score and rank all combination schemes, give priority to the combination with the shortest transportation route and fewer sources, and determine the optimal combination as blood product combination scheme A.

[0011] In a preferred embodiment, a combinatorial optimization algorithm is used to perform a global scan and combination of all eligible blood units, wherein the formula for the combinatorial optimization algorithm is: S4221, ; The constraints are as follows: The total number of selected units Must equal the total number of applications The blood type and breed of all selected units must be consistent with the application requirements. Only selectable from the dynamic inventory pool; For decision variables, take values ​​of 1 or 0, representing the first... Whether a blood unit is selected is indicated by a value of 1, which means the blood unit is selected and included in the current scheme, and a value of 0 means it is not selected. Indicates the first The time cost per blood unit; Indicates the first The shelf life of a single blood unit; Indicates the first The complexity of the blood unit's origin; the fewer units from the same patient, the lower this value. These are weighting coefficients for time cost, shelf life, and source complexity, used to balance the priorities among these factors.

[0012] In a preferred implementation, when the total amount in the dynamic inventory pool cannot meet the full amount requested, the difference between the variety and the quantity is first calculated, and a standard requisition process is triggered for this difference to generate a supplementary plan B for requisitioning blood from the central blood bank's regular inventory, including the following steps: S431. When the total amount in the dynamic inventory pool cannot meet the full quantity of the application, the remaining difference in blood type, variety and quantity of the application will be automatically calculated. S432. For the difference calculated for this purpose, an automatic blood requisition form is generated, which includes the type, quantity, and type of blood to be replenished, and is then submitted for approval.

[0013] In a preferred embodiment, the step of transmitting the combined scheme to the blood bank administrator, and after the medical staff confirms the scheme, automatically performing the data-level replacement includes the following steps: S51. The plan is pushed to the blood bank administrator and the applying doctor for final review. After the review is approved, for the blood products in the dynamic inventory pool, the system changes the status field from reserved patient C to assigned patient D, and directly replaces the value of the bound patient ID field from the ID of patient C to the ID of patient D. S52. While completing the data binding relationship switch, the system automatically generates a complete outbound instruction record. This instruction is directly associated with the blood use application form of patient D and includes blood information, new patient information, operation time and operator. The entire operation, including unbinding, rebinding and generating the instruction, is recorded synchronously in the audit log as a complete transaction, forming a complete evidence chain from unbinding patient C to binding with patient D. In the blood inventory list, the current status of this blood product is shown as having been dispatched to patient D, while its reservation history permanently retains a record of being reserved by patient C. S53. For some blood products that need to be released from the central blood bank, a standard electronic blood requisition form is automatically generated and sent to the central blood bank to initiate an independent approval and physical release process. S52. Integrate all operations, generate a final execution list, send it to the relevant departments, and lock all operation logs.

[0014] As a preferred embodiment, the clinical transfusion electronic information system as described in any of the above includes the following modules: blood product initial screening module, matching confirmation module, dynamic inventory pool construction module, blood product combination scheme generation module, and scheme review and execution module. The blood product screening module receives existing patient information and automatically extracts key safety parameters such as blood type, history of adverse transfusion reactions, and allergy history. By comparing these parameters with a preset clinical blood use safety knowledge base and rule engine, it excludes unnecessary blood product types and, in conjunction with component transfusion principles, identifies the range of blood components to be prioritized. Subsequently, it calls real-time inventory data from the entire hospital and regional blood banks to generate a dataset containing detailed information such as unique blood codes, blood types, expiration dates, and inventory locations. The matching confirmation module receives the patient's subsequent key examination results, automatically parses and extracts decisive matching parameters, performs precise comparison and screening within the previously generated dataset, and finally clarifies the specific type, quantity, and related geographical location data of the blood products required by the patient. The dynamic inventory pool construction module sets differentiated reservation time windows based on different blood use reasons, scans all approved but not physically released reserved blood in real time, and assesses whether the reservation time window has expired and whether the associated clinical event has been terminated; for blood products that meet both conditions, the release status is automatically triggered, integrated into the dynamic inventory pool, and the original reserved patient, release reason and time are marked. The blood product combination scheme generation module verifies the rationality of blood use applications, then matches the patient's blood use needs with the dynamic inventory pool. When the total amount is sufficient, the optimal combination with the shortest transportation path and fewer sources is selected through a combination optimization algorithm to generate scheme A. If the dynamic inventory pool is insufficient, the difference in blood type, variety, and quantity is calculated, triggering the standard application process to generate a supplementary scheme B for requisitioning blood from the central blood bank's regular inventory. The scheme review and execution module pushes the generated combination scheme to the blood bank administrator and the applying doctor for final review. After the review is approved, the data binding and replacement are completed, and unalterable audit logs including unbinding, rebinding and operator are generated simultaneously. At the same time, an outbound instruction is generated, and an electronic requisition form is sent for the blood that needs to be retrieved from the central blood bank, initiating an independent approval and physical outbound process.

[0015] The beneficial effects of this invention are as follows: 1. This invention extracts key patient safety parameters to exclude unnecessary blood products, and then integrates real-time inventory data from the entire hospital and regional blood banks to generate a dataset containing available information and geographical location. This enables precise blood screening and comprehensive resource allocation. Through a clinical blood safety knowledge base and rule engine, it completes preliminary contraindication exclusion, avoiding the risk of unsafe blood transfusions from the source. At the same time, it narrows the subsequent matching range and avoids efficiency losses caused by invalid searches. Even if the patient's initial data is incomplete, it can quickly identify safe and usable blood components.

[0016] 2. This invention achieves both efficient utilization of blood resources and safety by automatically triggering an intelligent matching process and constructing a dynamic inventory pool. It also incorporates differentiated reservation time windows and a clinical event termination judgment mechanism. The differentiated time windows are precisely set according to blood usage scenarios such as surgery and emergencies, ensuring that the original patient's blood needs during the treatment cycle are not affected and preventing the risk of reserved blood being illegally moved before the patient's blood use is completed. Blood is only released and added to the dynamic inventory pool when the reservation time expires and the clinical event is clearly terminated. This effectively solves the problem of long-term locked and idle reserved blood, preventing patients with genuine needs from using it, and also makes the use and release of blood resources more standardized, thereby maximizing the utilization value of deterministically idle resources.

[0017] 3. This invention precisely matches patients' blood needs with a dynamic inventory pool, simultaneously verifies the rationality of applications, and generates either solution A or B through combination optimization. This ensures both the compliance and safety of blood use while achieving efficient, tiered utilization of resources. The simultaneous verification mechanism judges the rationality of the application quantity by comparing patient diagnoses, weight, and other indicators, automatically marking and suspending abnormal applications, and avoiding resource waste caused by excessive applications or unreasonable blood use. Prioritizing the use of resources from the dynamic inventory pool can significantly improve the turnover efficiency of idle blood and avoid long-term resource accumulation. The combination optimization algorithm can select the optimal combination with the shortest transportation path and fewer sources, reducing the risk of blood in transit and allocation costs. Directly packaging and outputting blood when the total amount is equal further improves decision-making efficiency. Triggering the standard application process for the difference ensures that patients' blood needs are fully met, forming a tiered utilization model that prioritizes the use of idle blood and supplements routine blood use when there is a shortage, balancing resource conservation and clinical needs.

[0018] 4. This invention employs a direct data replacement model when using blood from a dynamic inventory pool, eliminating the need for additional warehousing, re-application, and approval processes. This significantly optimizes information management efficiency and the timeliness of clinical blood use. Compared to the traditional multi-step, discrete operation of releasing reservations, status rollback, re-deduction, and binding to new patients, data replacement combines multiple steps into one, eliminating the uncertainty and time lag in intermediate states. This simplifies blood information management procedures and reduces the risk of human error. Simultaneously, the entire process is recorded in an audit log, forming a complete chain of evidence from unbinding the original patient to binding the new patient, ensuring traceability and verifiability. Furthermore, eliminating redundant processes significantly shortens blood allocation time, further standardizes information management processes, and improves the overall operational efficiency of clinical blood transfusions. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in 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.

[0020] Figure 1 This is a flowchart of a management and control method for a clinical transfusion electronic information system according to an embodiment of the present invention; Figure 2 This is a block diagram of a clinical transfusion electronic information system according to an embodiment of the present invention. Detailed Implementation

[0021] To further illustrate the various embodiments, the present invention provides accompanying drawings, which are part of the disclosure of the present invention. These drawings are mainly used to illustrate the embodiments and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these drawings, those skilled in the art should be able to understand other possible implementation methods and the advantages of the present invention. The components in the drawings are not drawn to scale, and similar component symbols are generally used to represent similar components.

[0022] According to embodiments of the present invention, a management and control method for a clinical transfusion electronic information system is provided.

[0023] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments, such as... Figures 1-2 As shown, the management and control method of the clinical transfusion electronic information system according to an embodiment of the present invention includes the following steps: S1. Receive existing patient information and extract key information from the data. Based on the key information, exclude unnecessary blood products to obtain the range of usable blood products. Call the real-time inventory data of the entire hospital and regional blood banks to generate a dataset containing information on available blood products and geographical locations. Furthermore, the process involves receiving existing patient information and extracting key information from the data. Based on this key information, unnecessary blood products are excluded to determine the range of usable blood products. Real-time inventory data from the entire hospital and regional blood banks is then retrieved to generate a dataset containing information on available blood products and their geographical locations. This process includes the following steps: S11. The system receives the patient's existing information, including the entered brief medical record, vital signs, chief complaint, and known medical history, and automatically extracts and identifies key safety parameters for preliminary screening of blood products, mainly including known blood type, clear history of serious adverse transfusion reactions, history of allergy to specific blood components, and contraindications that are highly suggested in clinical diagnosis. S12. Call the preset clinical blood use safety knowledge base and rule engine, compare the extracted key safety parameters with the rules, exclude unnecessary blood product types, and obtain the range of blood products. It should be noted that the clinical blood use safety knowledge base and rule engine are built through the integration of multi-source knowledge, including authoritative clinical guidelines, industry standards and expert consensus, as well as historical data. After the rule logic is established through clinical guidelines, industry standards and expert consensus, the rules can be localized and calibrated by analyzing historical blood use data, and finally a set of decision logic that meets universal safety standards and is adapted to local clinical practice and can be executed by computers is formed. When using the clinical blood safety knowledge base and rule engine, the system extracts key safety parameters of the patient, such as known blood type, history of severe allergies to specific blood components, and contraindications related to certain diseases. These parameters are then compared with preset rules to initially screen out blood product types that are absolutely contraindicated or unsafe. Subsequently, based on the core principle of supplementing what is lacking in component transfusion, and combined with limited clinical information, the system further infers and identifies the range of blood components to be prioritized. For patients with acute blood loss, red blood cells and plasma are prioritized for matching, while for patients with thrombocytopenic bleeding, platelets are prioritized for matching. This generates a safety range list containing specific blood components, including suspended red blood cells, virus-inactivated plasma, apheresis platelets, and acceptable blood types, thus defining precise targets for subsequent real-time inventory matching. S13. Through the data interface, call and integrate the real-time inventory data of the hospital's blood bank and regional collaborative blood stations. This data includes not only available inventory, but also detailed information on all approved blood that has been reserved for other patients' plans but has not yet been physically released. S14. Link the blood product range with real-time inventory data to generate a detailed dataset containing each bag of blood products. The dataset includes the unique blood code, blood type, variety, blood volume, expiration date, current inventory location, and current status. S2. After receiving the patient's subsequent examination information, input it into the system and match it within the generated range to determine the blood products that need to be used; Furthermore, after receiving the patient's subsequent examination information and inputting it into the system, the system matches it within the generated range to determine the blood products that need to be used, including the following steps: S21. Receive the results of subsequent key examinations of the patient and transmit them to the system. Automatically parse the data and extract the decisive parameters for accurate matching, including confirmed blood type, irregular antibody screening results, and specific component transfusion requirements. S22. Compare and filter within the dataset to extract the specific blood product data and geographic location data required; S3. Based on the blood products to be used, the intelligent matching process is automatically triggered. First, all approved but not yet physically released planned reserved blood is scanned in real time and their status is evaluated. When it is determined that these reservations are overdue, they are integrated into a dynamic inventory pool. Furthermore, based on the determined blood products to be used, an intelligent matching process is automatically triggered. First, all approved but not yet physically released planned blood reserves are scanned in real time, and their status is assessed. When these reserves are determined to be overdue, they are integrated into a dynamic inventory pool, including the following steps: S31. Based on preset clinical rules for blood use reasons, including surgery, emergency rescue, and treatment of chronic anemia, the system automatically sets a differentiated reserved time window for each blood use application. It should be noted that the reservation time for routine surgery starts from the planned start time of surgery and covers the postoperative observation period; while the reservation time for emergency applications is shorter. During this window period, the blood will be strictly locked by the system and absolutely cannot be used by any other application or operation, thus fundamentally eliminating the risk of being forcibly taken before the expiration date. S32. The system scans all planned reserved blood products in real time and assesses the blood status based on whether the associated reserved time window has expired and whether the associated clinical event has been clearly terminated. S33. When it is determined that a reserved blood product meets the conditions that the time window has passed and the clinical demand has ended, the status change process will be automatically triggered to directly change the reserved status of the blood from occupied to released. S34. All blood products automatically marked as released will be integrated into the dynamic inventory pool. During integration, the original reserved patient, reason for release, and release time of each bag of blood products will be clearly marked. S4. Determine the patient's blood product needs and match them with the dynamic inventory pool. Perform combination optimization calculations through the matching algorithm to obtain blood product combination scheme A. When the inventory in the dynamic inventory pool is still insufficient after combination, automatically calculate the difference and retrieve the remaining quantity from the blood bank to generate blood product combination scheme B. Determine the patient's blood product needs and match them with a dynamic inventory pool. Perform combination optimization calculations using a matching algorithm to obtain blood product combination scheme A. If the inventory in the dynamic inventory pool is still insufficient after combination, automatically calculate the difference and retrieve the remaining quantity from the blood bank to generate blood product combination scheme B, including the following steps: S41. After receiving a patient's blood use request that has been clinically approved, first match the specific requirements, including blood type, type, and quantity, with the dynamic inventory pool. At the same time, a verification request will be submitted simultaneously to determine whether the requested amount significantly exceeds the normal usage range based on the patient's diagnosis, weight, and current laboratory indicators. Abnormal requests will be marked and the blood use request will be suspended until manual review. It should be noted that the dual mechanism of synchronous intelligent verification of the rationality of applications not only achieves efficient utilization of blood resources in stages, but also controls the safety and compliance of blood use from the source: On the one hand, prioritizing the use of released reserved blood can improve the inventory turnover efficiency of the entire hospital and regional blood banks, and avoid the situation where reserved blood is locked and cannot be used; on the other hand, by comparing with the routine usage corresponding to the patient's diagnosis, weight, and laboratory indicators, abnormal applications that exceed the reasonable range can be automatically identified and marked, the process can be suspended and await manual review, which can not only avoid the problem of locking up blood in advance due to excessive applications, but also eliminate unreasonable blood use applications and promote the standardization of blood transfusion information management process; In practice, the potential for excessive blood requests in clinical transfusions, leading to ineffective resource locking, can be addressed by establishing a blood request rationality verification mechanism. This mechanism precisely compares the requested blood volume with the standard dosage established based on the patient's diagnosis, weight data, and laboratory indicators. It automatically identifies and marks abnormal requests exceeding the reasonable range, suspending subsequent blood transfusion processes and awaiting manual review. This design not only prevents resource waste caused by excessive advance requests that result in prolonged blood occupancy and prevent other patients with urgent needs from accessing the blood, but also effectively eliminates unreasonable requests such as blood transfusions without indication or exceeding the permitted volume. Through the dual safeguards of rigid verification and manual review, it promotes the standardization and normalization of clinical transfusion information management processes, laying a solid foundation for the efficient and compliant use of blood resources. S42. Summarize and judge the total amount of all blood units in the dynamic inventory pool that meet the blood type and variety requirements. If the total amount is sufficient, immediately call the combination optimization algorithm to calculate whether a single release unit can meet all the needs, or whether it is necessary to aggregate multiple release units from different sources for combination, select the optimal combination, and obtain blood product combination scheme A. Furthermore, the total quantity of all blood units in the dynamic inventory pool that meet the blood type and variety requirements is summarized and judged. If the total quantity is sufficient, the combination optimization algorithm is immediately invoked to calculate whether a single release unit can meet all the demand, or whether it is necessary to aggregate multiple release units from different sources for combination, and select the optimal combination to obtain blood product combination scheme A, which includes the following steps: S421. Perform a quick total quantity calculation for all blood units in the dynamic inventory pool that meet the current application, and compare it with the application total quantity. If the dynamic inventory total quantity is greater than the application total quantity, it is determined that the total quantity is sufficient. It should be noted that when the system determines that the total number of blood units in the dynamic inventory pool that meet the requirements of blood type and variety is equal to the total demand of the current blood application, there is no need to start a complex combination optimization algorithm for calculation. Instead, it will directly and automatically package all the blood units that meet the conditions in the inventory pool, generate and output them as Scheme A. S422. Using a combinatorial optimization algorithm, perform a global scan and combination of all eligible blood units, calculate all combination methods, determine whether there is a single release unit inventory that can meet all the needs, and whether multiple units need to be combined, then list all combination schemes composed of units from different sources that can exactly meet the application quantity. Furthermore, a combinatorial optimization algorithm is used to perform a global scan and combination of all eligible blood units, where the formula for the combinatorial optimization algorithm is: S4221, ; The constraints are as follows: The total number of selected units Must equal the total number of applications The blood type and breed of all selected units must be consistent with the application requirements. Only selectable from the dynamic inventory pool; For decision variables, take values ​​of 1 or 0, representing the first... Whether a blood unit is selected is indicated by a value of 1, which means the blood unit is selected and included in the current scheme, and a value of 0 means it is not selected. Indicates the first The time cost per blood unit; Indicates the first The shelf life of a single blood unit; Indicates the first The complexity of the blood unit's origin; the fewer units from the same patient, the lower this value. These are weighting coefficients for time cost, shelf life, and source complexity, used to balance the priorities among these factors.

[0024] It should be noted that the weighting coefficients It is set up through historical data verification and iterative optimization. In addition, when generating the plan, a hierarchical priority rule will be strictly implemented. The primary consideration is the source of blood, giving priority to the use of available blood products in the hospital's blood bank or departmental blood preparation points. This ensures that the blood is kept within the hospital's strictly supervised cold chain and safety system throughout the process, with the strictest quality control and the fastest allocation speed. When the hospital's stock cannot meet the demand, the second-best option is to prioritize the retrieval of blood from external blood banks that are geographically closest and can guarantee that the transportation conditions meet the standards. This will minimize the blood's transit time and reduce potential risks during transportation, thereby achieving the optimal balance between rescue timeliness and resource costs while strictly adhering to the bottom line of safety. S423. Evaluate and rank all combinations, prioritizing those with the shortest transportation routes and the fewest sources, and determine the optimal combination as blood product combination A. S43. When the total amount in the dynamic inventory pool cannot meet the full amount requested, first calculate the difference between the variety and the quantity, and trigger the standard application process for this difference to generate a supplementary plan B for requisitioning blood from the central blood bank's regular inventory. Furthermore, when the total amount in the dynamic inventory pool cannot meet the full amount requested, the difference between the variety and the quantity is first calculated, and the standard requisition process is triggered for this difference to generate a supplementary plan B for requisitioning blood from the central blood bank's regular inventory, including the following steps: S431. When the total amount in the dynamic inventory pool cannot meet the full quantity of the application, the remaining difference in blood type, variety and quantity of the application will be automatically calculated. S432. For the calculated difference, an automatic blood requisition form will be generated, which includes the type, quantity, and type of blood to be replenished, and will be submitted for approval. S5. The combined solution is transmitted to the blood bank administrator. After the medical staff confirms the solution, the data-level replacement is automatically executed.

[0025] Furthermore, the combined treatment plan is transmitted to the blood bank administrator. After the medical staff confirms the plan, the automatic data-level replacement includes the following steps. S51. The plan is pushed to the blood bank administrator and the applying doctor for final review. After the review is approved, for the blood products in the dynamic inventory pool, the system changes the status field from reserved patient C to assigned patient D, and directly replaces the value of the bound patient ID field from the ID of patient C to the ID of patient D. S52. While completing the data binding relationship switch, the system automatically generates a complete outbound instruction record. This instruction is directly associated with the blood use application form of patient D and includes blood information, new patient information, operation time and operator. The entire operation, including unbinding, rebinding and generating the instruction, is recorded synchronously in the audit log as a complete transaction, forming a complete evidence chain from unbinding patient C to binding with patient D. S53. For some blood products that need to be released from the central blood bank, a standard electronic blood requisition form is automatically generated and sent to the central blood bank to initiate an independent approval and physical release process. It should be noted that this method of directly replacing data, compared to returning and reapplying, which requires multiple discrete data operation steps that may have time differences, such as releasing reservations, reverting the status to available, deducting inventory again, and rebinding new patients, not only eliminates the uncertainty of intermediate states and combines multiple operations into one step, but also greatly simplifies the steps of blood information management. S52. Integrate all operations, generate a final execution list, send it to the relevant departments, and lock all operation logs; Furthermore, the clinical transfusion electronic information system according to any of the above includes the following modules: blood product initial screening module, matching confirmation module, dynamic inventory pool construction module, blood product combination scheme generation module, and scheme review and execution module; The blood product screening module receives existing patient information and automatically extracts key safety parameters such as blood type, history of adverse transfusion reactions, and allergy history. By comparing these parameters with a pre-set clinical blood use safety knowledge base and rule engine, it excludes unnecessary blood product types and, in conjunction with component transfusion principles, identifies the range of blood components to be prioritized. Subsequently, it calls upon real-time inventory data from the entire hospital and regional blood banks to generate a dataset containing detailed information such as unique blood codes, blood types, expiration dates, and inventory locations. The matching and confirmation module receives the patient's subsequent key examination results, automatically parses and extracts the decisive matching parameters, performs precise comparison and screening within the previously generated dataset, and finally clarifies the specific type, quantity, and related geographical location data of the blood products required by the patient. The dynamic inventory pool construction module sets differentiated reservation time windows based on different blood use reasons, scans all approved but not physically released reserved blood in real time, and assesses whether the reservation time window has expired and whether the associated clinical event has been terminated; for blood products that meet both conditions, the release status is automatically triggered, integrated into the dynamic inventory pool, and the original reserved patient, release reason and time are marked. The blood product combination scheme generation module verifies the rationality of blood use applications, then matches the patient's blood use needs with the dynamic inventory pool. When the total amount is sufficient, the combination optimization algorithm selects the optimal combination with the shortest transportation path and fewer sources to generate scheme A. If the dynamic inventory pool is insufficient, the difference in blood type, variety and quantity is calculated, triggering the standard application process to generate a supplementary scheme B that retrieves blood from the central blood bank's regular inventory. The scheme review and execution module pushes the generated combination scheme to the blood bank administrator and the applying doctor for final review. After the review is approved, the data binding and replacement are completed, and unalterable audit logs including unbinding, rebinding and operator are generated simultaneously. At the same time, an outbound instruction is generated, and an electronic requisition form is sent for the blood that needs to be retrieved from the central blood bank, initiating an independent approval and physical outbound process.

[0026] It should be noted that the traditional blood requisition process follows a fixed closed loop of planning, application, approval, and batch release. Clinical medical staff first formulate a blood use plan based on the patient's condition and surgical arrangements, and then submit a written or electronic application. After approval through multiple levels, including departmental review and blood bank verification, the blood bank processes the physical release procedures for patients in batches according to the approved blood type and quantity. The entire process is relatively independent and rigid. Once blood is approved and reserved for a patient, it is locked by the system, lacking dynamic tracking of the actual usage status of the reserved blood, even if the patient's subsequent treatment ends. When patients no longer need the blood due to illness or recovery, and the blood has not yet been physically released from storage, it is difficult to release and redistribute it quickly. This invention precisely addresses this problem by targeting blood products that have been approved and reserved but are no longer needed by the original patients and have not yet been physically released from storage. By scanning their reservation status in real time, combined with differentiated reservation time window verification and clinical event termination judgment, once the release conditions are confirmed, they are integrated into a dynamic inventory pool. This prevents the blood from being locked up for a long time and instead prioritizes it as a deterministic idle resource to meet the blood needs of new patients, thus achieving efficient activation and precise reuse of idle blood that has not yet been released from storage. The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A management and control method for a clinical transfusion electronic information system, characterized in that, The method includes the following steps: S1. Receive existing patient information and extract key information from the data. Based on the key information, exclude unnecessary blood products to obtain the range of usable blood products. Call the real-time inventory data of the entire hospital and regional blood banks to generate a dataset containing information on available blood products and geographical locations. S2. After receiving the patient's subsequent examination information, input it into the system and match it within the generated range to determine the blood products that need to be used; S3. Based on the blood products to be used, the intelligent matching process is automatically triggered. First, all approved but not yet physically released planned reserved blood is scanned in real time and their status is evaluated. When it is determined that these reservations are overdue, they are integrated into a dynamic inventory pool. S4. Determine the patient's blood product needs and match them with the dynamic inventory pool. Perform combination optimization calculations through the matching algorithm to obtain blood product combination scheme A. When the inventory in the dynamic inventory pool is still insufficient after combination, automatically calculate the difference and retrieve the remaining quantity from the blood bank to generate blood product combination scheme B. S5. The combined solution is transmitted to the blood bank administrator. After the medical staff confirms the solution, the data-level replacement is automatically executed.

2. The management and control method for the clinical transfusion electronic information system according to claim 1, characterized in that, The process of receiving existing patient information, extracting key information from the data, excluding unnecessary blood products based on the key information to obtain the range of usable blood products, and generating a dataset containing information on available blood products and their geographical locations by calling real-time inventory data from the entire hospital and regional blood banks includes the following steps: S11. The system receives the patient's existing information, including the entered brief medical record, vital signs, chief complaint, and known medical history, and automatically extracts and identifies key safety parameters for preliminary screening of blood products, mainly including known blood type, clear history of serious adverse transfusion reactions, history of allergy to specific blood components, and contraindications that are highly suggested in clinical diagnosis. S12. Call the preset clinical blood use safety knowledge base and rule engine, compare the extracted key safety parameters with the rules, exclude unnecessary blood product types, and obtain the range of blood products. S13. Through the data interface, call and integrate the real-time inventory data of the hospital's blood bank and regional collaborative blood stations. This data includes not only available inventory, but also detailed information on all approved blood that has been reserved for other patients' plans but has not yet been physically released. S14. Associate the range of blood products with real-time inventory data to generate a detailed dataset containing each bag of blood products. The dataset includes the unique blood code, blood type, variety, blood volume, expiration date, current inventory location, and current status.

3. The management and control method for the clinical transfusion electronic information system according to claim 1, characterized in that, The process of receiving subsequent patient examination information, inputting it into the system, and matching it within a generated range to determine the required blood products includes the following steps: S21. Receive the results of subsequent key examinations of the patient and transmit them to the system. Automatically parse the data and extract the decisive parameters for accurate matching, including confirmed blood type, irregular antibody screening results, and specific component transfusion requirements. S22. Compare and filter within the dataset to extract the specific blood product data and geographical location data required.

4. The management and control method for the clinical transfusion electronic information system according to claim 1, characterized in that, The process of automatically triggering an intelligent matching workflow based on the determined blood products to be used first involves scanning all approved but not yet physically dispatched planned blood reserves in real time and assessing their status. When these reserves are determined to be overdue, they are integrated into a dynamic inventory pool, including the following steps: S31. Based on preset clinical rules for blood use reasons, including surgery, emergency rescue, and treatment of chronic anemia, the system automatically sets a differentiated reserved time window for each blood use application. S32. The system scans all planned reserved blood products in real time and assesses the blood status based on whether the associated reserved time window has expired and whether the associated clinical event has been clearly terminated. S33. When it is determined that a reserved blood product meets the conditions that the time window has passed and the clinical demand has ended, the status change process will be automatically triggered to directly change the reserved status of the blood from occupied to released. S34. All blood products that are automatically marked as released will be integrated into the dynamic inventory pool. During integration, the original reserved patient, reason for release, and release time of each bag of blood products will be clearly marked.

5. The management and control method for the clinical transfusion electronic information system according to claim 1, characterized in that, The determination involves matching the patient's blood product needs with a dynamic inventory pool, and performing combination optimization calculations through a matching algorithm to obtain blood product combination scheme A. When the inventory is still insufficient after combining the dynamic inventory pool, the difference is automatically calculated, and the remaining quantity is retrieved from the blood bank to generate blood product combination scheme B, which includes the following steps: S41. After receiving a patient's blood use request that has been clinically approved, first match the specific requirements, including blood type, type, and quantity, with the dynamic inventory pool. At the same time, a verification request will be submitted simultaneously to determine whether the requested amount significantly exceeds the normal usage range based on the patient's diagnosis, weight, and current laboratory indicators. Abnormal requests will be marked and the blood use request will be suspended until manual review. S42. Summarize and judge the total amount of all blood units in the dynamic inventory pool that meet the blood type and variety requirements. If the total amount is sufficient, immediately call the combination optimization algorithm to calculate whether a single release unit can meet all the needs, or whether it is necessary to aggregate multiple release units from different sources for combination, select the optimal combination, and obtain blood product combination scheme A. S43. When the total amount in the dynamic inventory pool cannot meet the full amount requested, first calculate the difference between the variety and the quantity, and trigger the standard application process for this difference to generate a supplementary plan B for requisitioning blood from the central blood bank's regular inventory.

6. The management and control method for the clinical transfusion electronic information system according to claim 5, characterized in that, The process of summarizing and judging the total amount of all blood units in the dynamic inventory pool that meet the blood type and variety requirements, and immediately calling the combination optimization algorithm when the total amount is sufficient, calculates whether a single release unit can meet all the demand or whether it is necessary to aggregate multiple release units from different sources for combination, and selects the optimal combination to obtain blood product combination scheme A, including the following steps: S421. Perform a quick total quantity calculation for all blood units in the dynamic inventory pool that meet the current application, and compare it with the application total quantity. If the dynamic inventory total quantity is greater than the application total quantity, it is determined that the total quantity is sufficient. S422. Using a combinatorial optimization algorithm, perform a global scan and combination of all eligible blood units, calculate all combination methods, determine whether there is a single release unit inventory that can meet all the needs, and whether multiple units need to be combined, then list all combination schemes composed of units from different sources that can exactly meet the application quantity. S423. Score and rank all combination schemes, give priority to the combination with the shortest transportation route and fewer sources, and determine the optimal combination as blood product combination scheme A.

7. The management and control method for the clinical transfusion electronic information system according to claim 6, characterized in that, The method employs a combinatorial optimization algorithm to perform a global scan and combination of all eligible blood units. The formula for the combinatorial optimization algorithm is as follows: S4221、 ； The constraints are as follows: The total number of selected units Must equal the total number of applications The blood type and breed of all selected units must be consistent with the application requirements. Only selectable from the dynamic inventory pool; For decision variables, take values ​​of 1 or 0, representing the first... Whether a blood unit is selected is indicated by a value of 1, which means the blood unit is selected and included in the current scheme, and a value of 0 means it is not selected. Indicates the first The time cost per blood unit; Indicates the first The shelf life of a single blood unit; Indicates the first The complexity of the blood unit's origin; the fewer units from the same patient, the lower this value. These are weighting coefficients for time cost, shelf life, and source complexity, used to balance the priorities among these factors.

8. The management and control method for the clinical transfusion electronic information system according to claim 5, characterized in that, When the total amount in the dynamic inventory pool cannot meet the full amount requested, the difference between the type and the quantity is first calculated, and the standard requisition process is triggered for this difference to generate a supplementary plan B for requisitioning blood from the central blood bank's regular inventory, including the following steps: S431. When the total amount in the dynamic inventory pool cannot meet the full quantity of the application, the remaining difference in blood type, variety and quantity of the application will be automatically calculated. S432. For the difference calculated for this purpose, an automatic blood requisition form is generated, which includes the type, quantity, and type of blood to be replenished, and is then submitted for approval.

9. The management and control method for the clinical transfusion electronic information system according to claim 1, characterized in that, The process of transmitting the combined solution to the blood bank administrator, and then automatically performing the data-level replacement after the medical staff confirms the solution, includes the following steps: S51. The plan is pushed to the blood bank administrator and the applying doctor for final review. After the review is approved, for the blood products in the dynamic inventory pool, the system changes the status field from reserved patient C to assigned patient D, and directly replaces the value of the bound patient ID field from the ID of patient C to the ID of patient D. S52. While completing the data binding relationship switch, the system automatically generates a complete outbound instruction record. This instruction is directly associated with the blood use application form of patient D and includes blood information, new patient information, operation time and operator. The entire operation, including unbinding, rebinding and generating the instruction, is recorded synchronously in the audit log as a complete transaction, forming a complete evidence chain from unbinding patient C to binding with patient D. S53. For some blood products that need to be released from the central blood bank, a standard electronic blood requisition form is automatically generated and sent to the central blood bank to initiate an independent approval and physical release process. S52. Integrate all operations, generate a final execution list, send it to the relevant departments, and lock all operation logs.

10. The clinical transfusion electronic information system according to any one of claims 1-9, characterized in that, It includes the following modules: blood product initial screening module, matching confirmation module, dynamic inventory pool construction module, blood product combination scheme generation module, and scheme review and execution module; The blood product screening module receives existing patient information and automatically extracts key safety parameters such as blood type, history of adverse transfusion reactions, and allergy history. By comparing these parameters with a preset clinical blood use safety knowledge base and rule engine, it excludes unnecessary blood product types and, in conjunction with component transfusion principles, identifies the range of blood components to be prioritized. Subsequently, it calls real-time inventory data from the entire hospital and regional blood banks to generate a dataset containing detailed information such as unique blood codes, blood types, expiration dates, and inventory locations. The matching confirmation module receives the patient's subsequent key examination results, automatically parses and extracts decisive matching parameters, performs precise comparison and screening within the previously generated dataset, and finally clarifies the specific type, quantity, and related geographical location data of the blood products required by the patient. The dynamic inventory pool construction module sets differentiated reservation time windows based on different blood use reasons, scans all approved but not physically released reserved blood in real time, and assesses whether the reservation time window has expired and whether the associated clinical event has been terminated; for blood products that meet both conditions, the release status is automatically triggered, integrated into the dynamic inventory pool, and the original reserved patient, release reason and time are marked. The blood product combination scheme generation module verifies the rationality of blood use applications, then matches the patient's blood use needs with the dynamic inventory pool. When the total amount is sufficient, it uses a combination optimization algorithm to select the optimal combination with the shortest transportation path and fewer sources to generate scheme A. If the dynamic inventory pool is insufficient, the difference in blood type, variety and quantity is calculated, triggering the standard application process and generating a supplementary plan B to retrieve blood from the central blood bank's regular inventory. The scheme review and execution module pushes the generated combination scheme to the blood bank administrator and the applying doctor for final review. After the review is approved, the data binding and replacement are completed, and unalterable audit logs including unbinding, rebinding and operator are generated simultaneously. At the same time, an outbound instruction is generated, and an electronic requisition form is sent for the blood that needs to be retrieved from the central blood bank, initiating an independent approval and physical outbound process.

Images