An anti-tumor drug individualized dose recommendation system based on multi-source clinical data

Abstract

The application relates to the technical field of medical information processing, and discloses an anti-tumor drug individualized dose recommendation system based on multi-source clinical data, which comprises a clinical data access module, a dose basis determination module, a clinical state segmentation module, a recommended version management module and a pre-configuration review module. According to each dose basis, the system searches for an associated treatment execution event whose completion time is not later than the planned administration time and whose reacquisition time point is not earlier than the starting point of an effective period, forms a state boundary with the starting point of the effective period and the latest reacquisition time point of the associated event, generates a candidate dose by using only the clinical records which are audited after the boundary, and binds the used records, the state boundary and the rule version into an immutable recommended version; if the clinical records, the task primary key or the rule version are updated before the configuration, the input is changed, the original version is invalidated and withdrawn. The application can reduce the cross-state data mixing, prevent the invalid dose from continuing to circulate, and improve the consistency and traceability of the recommendation.

Description

Technical Field

[0001] This invention relates to the field of medical information processing technology, and in particular to a personalized dosage recommendation system for antitumor drugs based on multi-source clinical data. Background Technology

[0002] Candidate doses of antitumor drugs are typically related to treatment regimens, treatment duration, patient weight or body surface area, blood cell counts, liver function, kidney function, electrolytes, and past adverse reactions. This data is generated from electronic medical record systems, laboratory information systems, nursing systems, and prescription systems, and the sampling time, generation time, review time, and update method of the data are inconsistent. Some systems use a fixed validity period or directly select the latest record for each data item. Therefore, while multiple dose estimates obtained may meet the time requirements, they may correspond to different clinical states of the patient.

[0003] Prior to planned medication administration, patients may have received blood purification, transfusions, hydration therapy, continuous drainage, diuretics, or contrast agents. These treatment events can alter the applicable status of dosage criteria, such as blood cell counts, volume status, weight, renal function, or electrolytes. For example, a test result completed before the event may still be the most up-to-date result in the database after the event, but it no longer represents the state after the event. If data is selected solely based on fixed durations or reporting times, it is easy to combine clinical records before and after the event into the same dosage criteria set.

[0004] Furthermore, there is a time interval between the formation and manual review of candidate doses and the actual commencement of chemotherapy drug preparation. During this interval, test results may be corrected, medical orders may be changed, and the treatment execution status may change from planned to completed. If the recommended result is not bound to the records, status boundaries, and rule versions on which it is based, or if the configuration terminal stores a separate copy of the dose, the old recommended result may remain in the configuration queue, making it difficult to accurately withdraw and trace it based on subsequent updates.

[0005] Therefore, a dosage recommendation system is needed for the asynchronous generation and continuous updating of multi-source clinical data, so that each candidate dose corresponds to effective data in the same clinical state, and the recommended version is continuously reviewed before drug preparation begins, in order to solve the problems of cross-state data mixing and the continued circulation of invalid recommendation results. Summary of the Invention

[0006] The purpose of this invention is to provide a personalized dosage recommendation system for anti-tumor drugs based on multi-source clinical data. This system determines the state boundaries of various dosage bases for treatment execution events that can change the applicable state of dosage bases, reconstructs a set of dosage bases with consistent states after the corresponding state boundaries, and prevents invalid candidate doses from being called by the chemotherapy drug configuration terminal through immutable version binding and pre-configuration review.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A personalized dosage recommendation system for antitumor drugs based on multi-source clinical data includes: The clinical data access module is used to obtain the treatment plan, treatment cycle, planned dosing time and clinical records of the target patient; The dosage basis determination module is used to determine the required dosage basis and corresponding effective period of the antitumor drug to be recommended; The clinical status segmentation module is used to retrieve completed treatment events whose completion time is no later than the planned dosing time and whose data re-collection time is no earlier than the start time of the effective period. It determines the latest time point between the start time of the effective period and the data re-collection time of the associated event as the status boundary, and selects records between the status boundary and the planned dosing time that are valid and whose collection time is closest to the planned dosing time, forming a dose basis set with consistent status. The dose basis determination module is also used to generate candidate doses when the dose basis set is complete. The recommended version management module is used to bind the candidate dose with the version of the record, state boundary and dose rule used to an immutable recommended version; The pre-configuration review module is used to redefine the state boundaries and reselect records based on updates to clinical records, recommended task keys, and dosage rule versions. When the state boundaries, selected records, recommended task keys, or dosage rule versions change, the original version becomes invalid and the pending configuration queue item is withdrawn. Only valid versions confirmed by physicians and reviewed by pharmacists are allowed to be called.

[0008] Optionally, the clinical data access module is specifically used for: Extract diagnosis, treatment cycle, height, weight, allergy history, and previous adverse reaction records from electronic medical records; Extract blood cell count, liver function, kidney function and electrolyte test results from the test records, and retain the specimen collection time, report time and review status of each test result; Extract fluid resuscitation, blood transfusion, blood purification, drainage, urine output, and the corresponding start and end times and status of the procedure from the nursing records. Extract drug identification, dispensing unit, planned dosing time, and preparation status from medical order records; The source system, record identifier, source record version, generation time, update time, and validity status are retained for the electronic medical records, laboratory records, nursing records, and medical order records, respectively.

[0009] Optionally, the dose basis determination module is specifically used for: Read the dosage calculation type, required data items, and limited dosage units of the recommended antitumor drug from the dosage rules; When the dose calculation type is a fixed dose, a dose based on body weight, a dose based on body surface area, or a dose based on renal function parameters, the dose calculation rules corresponding to the dose calculation type are invoked respectively. The units of the required data items are converted to the units defined by the dose calculation rules. The base dose is generated after the dose basis set with consistent status is complete and the unit conversion is successful. The baseline dose is associated with the drug label, treatment duration, planned dosing time, and version of the dosage rule used for the recommended antitumor drug.

[0010] Optionally, the dose-based determination module is further configured to: Read from the dosage rules the liver function adjustment conditions, kidney function adjustment conditions, previous cycle adverse reaction adjustment conditions, condition merging method, dose level mapping method, allowable dose level and discontinuation recommendation conditions corresponding to the recommended antitumor drug; The dose adjustment result is determined according to the condition priority and condition merging method defined by the dose rule, and the dose level corresponding to the dose adjustment result is selected from the allowed dose levels according to the dose level mapping method. The base dose is adjusted to the selected dose level to obtain the candidate dose. When the aforementioned stop recommendation conditions are met, the recommendation task is set to a pending manual processing state, and no dose recommendation version is generated that can be sent; the dose rule also records the rule source, applicable drug, applicable treatment plan, effective time, expiration time, rule status, and rule version.

[0011] Optionally, the clinical data access module is further used for: Verify the correspondence between the target patient, the treatment cycle, and the planned dosing time in the records from each source; Exclude revoked, corrected, or unaudited clinical records, and identify duplicate records, records with missing units, and records with inconsistent unit dimensions; when necessary data items are missing, record correspondences are inconsistent, or units cannot be converted, generate a list of data to be supplemented and prevent the formation of dose basis sets with the aforementioned status; When the required data items are complete and the corresponding records are consistent, the verified clinical records and their metadata will be transmitted to the clinical status segmentation module.

[0012] Optionally, the clinical state segmentation module includes an event association rule unit, which is used for: For each required dose, the registration includes treatment execution event types that can change their applicable status, affected data items, event completion conditions, and data re-collection waiting intervals; blood purification, blood transfusion, hydration therapy to achieve drug-specific fluid replacement volume, continuous drainage, diuresis therapy, and contrast agent administration are registered as the aforementioned treatment execution event types; When the treatment execution record meets the corresponding event completion conditions, a completed treatment execution event is generated, and the sum of the completion time of the event and the corresponding data re-acquisition waiting interval is determined as the data re-acquisition time point; The execution record identifier, start time, completion time, execution status, and data re-collection time of the treatment execution event are associated with the affected required dose.

[0013] Optionally, when determining the state boundaries, the clinical state segmentation module is specifically used for: Regarding the first Based on the state-sensitive dosage criteria, the starting point of the drug-specific effective period is determined according to the planned dosing time and the corresponding effective duration in the dosage rules; The search is for completed treatment events whose completion time is no later than the planned dosing time, whose data re-collection time is no earlier than the start time of the drug-specific effective period, and whose patient, treatment cycle, and event type all match the event association rules. When at least one of the completed treatment execution events is retrieved, the latest time point among the start time of the drug-specific effective period and the data re-collection time point of each completed treatment execution event is determined as the first time point. The state boundary is based on the state-sensitive dose. If no completed treatment event is found, the start point of the drug-specific effective period is determined as the [number missing]. The state boundary is based on the state-sensitive dose.

[0014] Optionally, the clinical status segmentation module is further used for: For each required dosage basis, select the records from the clinical records between their corresponding status boundaries and the planned dosing time, where the review status is valid and the collection time is closest to the planned dosing time; When multiple records are collected at the same time, one record is selected in the following order: later review time, newer source record version, and higher source priority. The selected records are combined into a dose-based set that is consistent with the stated state; If any required dose basis is missing from the set of dose basis in the consistent state, no candidate dose is generated, a re-examination prompt corresponding to the missing required dose basis is generated, and the recommended state is set to waiting for update.

[0015] Optionally, the recommended version management module is specifically used for: Generate a version identifier corresponding to the target patient, treatment plan, treatment cycle, recommended antitumor drug, and planned dosing time; Record the record identifier, source record version, collection time, review status and validity status of each clinical record in the dose basis set with consistent status in an immutable version manner, and record the status boundary, dose rule version, base dose, candidate dose, physician confirmation result, pharmacist review result and version status of each required dose basis; The recommended dosage versions after the candidate dosage is formed will sequentially enter the state of awaiting physician confirmation and the state of awaiting pharmacist review, and only the versions that have passed both physician confirmation and pharmacist review will be set to the valid state. Versions that fail any review will remain unsendable, and versions that are replaced by subsequent dose-recommended versions will be set to historical invalid status.

[0016] Optionally, the pre-configuration review module is specifically used for: After the recommended dosage version is confirmed by the physician and reviewed by the pharmacist, and before the medication preparation begins, we continuously receive updates on test results, changes in medical orders, updates on treatment execution events, and updates on the dosage rule version status. Based on the received updates, we redetermine the status boundaries of each required dosage, reselect clinical records, and redetermine the currently applicable dosage rule version. When any state boundary changes, or the record identifier, source record version, collection time, review status, or validity status of any selected clinical record changes, or the dosage rule version changes or becomes invalid, or when the primary key of the recommendation task composed of the target patient, treatment plan, treatment cycle, anti-tumor drug to be recommended, planned dosing time, and source medical order identifier changes, the corresponding dosage recommendation version will be set to invalid state, the corresponding queue item will be withdrawn from the configuration queue of the chemotherapy drug configuration terminal, and a new dosage recommendation version to be reviewed will be formed based on the updated dose basis set consistent with the status and the currently applicable dosage rule version. When the chemotherapy drug configuration terminal reads the queue to be configured and confirms the start of drug configuration, it verifies the version identifier, target patient, planned dosing time, recommended antitumor drug, dosage rule version, and version status. The candidate dose is only allowed to be called when the verification results are consistent and the version status is valid.

[0017] Compared with the prior art, the present invention has the following beneficial effects: The applicable status of each dosage basis is divided according to the data re-collection time point corresponding to the treatment execution event, and the associated events that overlap with the data re-collection waiting process and the drug-specific effective period are included in the boundary calculation. Instead of relying solely on a unified fixed time window or the latest report record in the database, it can reduce the situation where data before and after the event are combined and used. Candidate doses are bound to the original record identifier, source record version, collection time, various status boundaries and rule versions, so that the input and processing rules of the recommendation results are verifiable and traceable. Before the configuration begins, incremental detection is performed on the clinical records, recommendation task primary keys and rule version updates, and invalid versions are executed to withdraw from the queue and be reviewed by the terminal. This ensures that the chemotherapy drug configuration terminal only calls the currently effective version that has been confirmed by the physician and reviewed by the pharmacist, thereby improving the consistency of multi-source clinical data processing and the reliability of dosage information before configuration. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the structure of a personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to the present invention; Figure 2 This is a schematic diagram of the clinical data access and data consistency verification process of the present invention; Figure 3 This is a schematic diagram of the basic dose calculation and candidate dose generation process of the present invention; Figure 4 This is a schematic diagram of the treatment execution event association, state boundary determination, and dosage basis reselection process of the present invention; Figure 5 This is a schematic diagram of the process for forming and reviewing the recommended dosage version of the present invention before configuration; Figure 6 This is a timeline diagram illustrating how the original recommended dosage becomes invalid and a new version is formed after the clinical records are updated, as per the present invention. Detailed Implementation

[0019] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. The following embodiments are used to explain the technical solution of the present invention and are not intended to limit the scope of protection. The candidate dose referred to herein is a calculation result generated by the information system according to authorized dosage rules and reviewed by physicians and pharmacists, and does not directly replace prescription decisions; only the recommended dosage version that has been confirmed by a physician and reviewed by a pharmacist and is still valid at the start of configuration is allowed to be called by the chemotherapy drug configuration terminal. Clinical data access is only performed through the hospital's authorized interface, and internal patient identification and clinical records are processed according to the minimum data range required for the recommended task.

[0020] like Figure 1As shown, the system in this embodiment includes a clinical data access module, a dosage basis determination module, a clinical status segmentation module, a recommended version management module, and a pre-configuration review module. Each module can be deployed on the same application server within the hospital's intranet, or separately in the interface service, rule service, version service, and configuration queue service. A common recommendation task is established using patient internal identifiers, treatment plan identifiers, treatment cycle identifiers, drug identifiers, and planned dosing times. During runtime, the dosage basis determination module first outputs the necessary data items and dosage calculation conditions from the current rule version. The clinical status segmentation module then forms a dosage basis set with consistent status. The dosage basis determination module then generates candidate doses, the recommended version management module completes version binding, and the pre-configuration review module maintains the version synchronized with the clinical records before drug configuration begins. For unstructured electronic medical record content, only diagnoses, allergy history, and past adverse reaction records that have been confirmed by physicians and written into structured fields are used; unconfirmed natural language inferences are not directly used as dosage basis.

[0021] The system executes the following data flow in a deterministic order: S1, establishing a recommended task based on the patient's internal identifier, treatment plan identifier, treatment cycle identifier, drug identifier, planned dosing time, and source medical order identifier; S2, reading the unique dosage rule version that is valid at the planned dosing time and matches both the drug and treatment plan, and outputting the required data items, effective duration, event association entries, dosage level mapping method, and dosage calculation node; S3, the source adapter receives clinical records, and writes them into the clinical record database after field standardization, patient and cycle matching, and validity verification; S4, the event retrieval unit identifies completed treatment execution events based on event association entries and calculates the data re-acquisition time point for each data item; S5, the state boundary calculation unit retrieves associated events whose completion time is no later than the planned dosing time and whose data re-acquisition time point is no earlier than the start time of the effective period, calculates the state boundary item by item, and the dosage selection unit selects records accordingly.

[0022] Following the aforementioned steps, in S6, when the set is complete, candidate doses are generated by the basic dose calculation unit and the dose level selection unit; when the set is incomplete, a list of data to be supplemented is output without generating candidate doses. In S7, the recommended version management module solidifies the input records, state boundaries, rule versions, and calculation results into immutable versions. In S8, the versions are sequentially confirmed by physicians and reviewed by pharmacists. In S9, before configuration begins, updates to clinical records, medical orders, treatment execution events, and dose rule versions are continuously received, and incremental recalculation is performed on affected data items. In S10, the state boundary set, selected record set, recommended task primary key, and rule version are compared before and after the update; if changes occur, the original version is invalidated, the corresponding queue item is withdrawn, and a new version awaiting review is formed. Each step only receives the structured data output from the previous step and does not use natural language inference or human experience to complete missing fields.

[0023] The clinical data access module includes a source adapter, a patient-cycle matching unit, a field standardization unit, and a validity verification unit. The source adapter reads incremental messages from various source systems and retains for each message the following information: source system identifier, source record identifier, source record version, patient master index, visit identifier, treatment plan identifier, treatment cycle identifier, drug identifier, collection time, report time, generation time, review time, review status, validity status, and update time. Collection time indicates the actual time of specimen collection, weight measurement, or treatment execution; report time indicates the time when test results are generated into a report; generation time indicates the time when the clinical record is written to the source system; and update time indicates the time when the source record version is added, corrected, or revoked. The system uses collection time to determine clinical status and uses source record version and update time to detect subsequent corrections, avoiding the substitution of report delays for the actual collection sequence.

[0024] The review status uses the enumerated values ​​"Unreviewed," "Reviewed," and "Reviewed," with "Reviewed Valid" only referring to a status of "Reviewed." The validity status uses the enumerated values ​​"Currently Valid," "Replaced by New Version," and "Revoked," with "Valid Record" only referring to a status of "Currently Valid." A record only enters the selectable record set when its review status is "Reviewed," its validity status is "Currently Valid," the patient and cycle match is successful, and the unit verification is successful; if any status field is missing, it is treated as unavailable. All time fields are converted to the hospital's unified time zone and accurate to the second, while preserving the original time zone offset; the collection time of the same record must not be later than its generation time, and the review time must not be earlier than its generation time; violations of this time sequence constraint will generate data quality anomalies.

[0025] The data flow between the source adapter, field standardization unit, validity verification unit, and clinical record database is fixed as follows: the source message is first converted into a unified record object by the source adapter, then the field standardization unit completes the encoding and unit conversion, followed by the validity verification unit writing the verification result, and finally the original value, standard value, metadata, and verification result are written to the clinical record database. Subsequent modules only read the currently valid version in the clinical record database and do not directly read the source message cache.

[0026] like Figure 2As shown, the clinical data access module extracts diagnosis, treatment cycle, height, weight, allergy history, and past adverse reaction records from electronic medical records; it extracts blood cell count items such as white blood cell count, absolute neutrophil count, platelet count, and hemoglobin from laboratory records; it extracts liver function items such as alanine aminotransferase, aspartate aminotransferase, and total bilirubin; it extracts kidney function items such as serum creatinine and estimated glomerular filtration rate from laboratory reports; and it extracts electrolyte items such as potassium, sodium, calcium, and magnesium. The items required for the current recommendation task are given by the dosage rules corresponding to the antitumor drugs and treatment regimens to be recommended. Test results not listed as required data items by the current rules are not included in the candidate dose calculation.

[0027] The clinical data access module also extracts information such as fluid replacement, blood transfusion, blood purification, drainage, and urine output, along with their start and end times and execution status, from nursing records. It also extracts drug identifiers, administering units, planned dosing times, and configuration status from medical order records. For correction messages from the same source record, the system adds a new version of the source record and changes the original version's validity status to invalid. For revoked records, the reason for revocation and the revocation time are written to the audit log. Records that were involved in dosage recommendations are not physically deleted, allowing for the retracing of data used at that time based on version identifiers.

[0028] The patient and cycle matching unit sequentially verifies the patient's master index, visit identifier, treatment protocol identifier, treatment cycle identifier, and planned dosing time. Patient identifiers from different systems are mapped to the same target patient through the hospital's master index, and the treatment cycle is verified by comparing the cycle number in the treatment protocol with the planned dosing date. If the patient correspondence is inconsistent, the cycle number conflicts, or there are two uncancelled planned dosing times for the same drug, the system does not merge them by speculation, but instead generates a record of correspondence anomalies and prevents the formation of a dose basis set with consistent status.

[0029] Patient and cycle matching does not use fuzzy similarity. The primary key of the recommended task consists of the patient's internal identifier, treatment protocol identifier, treatment cycle identifier, drug identifier, planned dosing time, and source order identifier in a fixed order. Patient matching is successful if all source patient identifiers, after mapping through the primary index, result in the same and unique patient internal identifier. Cycle matching is successful if both the treatment protocol identifier and cycle number are identical. Dosing task matching prioritizes identical source order identifiers. When a source record does not contain a source order identifier, a match is only considered if the patient's internal identifier, treatment protocol identifier, cycle number, drug identifier, and standardized planned dosing time are all identical and correspond to only one unrevoked order; otherwise, it is transferred to manual processing.

[0030] The field standardization unit maps drug codes, test item codes, and units to standard codes used by the rule service based on the data dictionary. The unit conversion table records at least the source unit, target unit, conversion factor, conversion offset, applicable items, and table version. The conversion relationship is expressed as the target value equals the source value multiplied by the conversion factor plus the conversion offset. The converted value retains both the original value and the original unit. Test records lacking units, with inconsistent unit dimensions, values ​​exceeding the interface's allowed representation range, or those that have not been reviewed or have been withdrawn are marked as unusable. Only one valid instance is retained for identical source record identifiers and versions; records with the same value but different source record identifiers are not automatically deduplicated but are saved separately according to source and collection time.

[0031] Unit conversion entries are represented as ordered records of source unit, target unit, dimension, conversion factor, conversion offset, and table version. The conversion relationship is as follows: .in, This represents the source value expressed in source units. This represents the target value expressed in target units. This represents the scaling factor that maps a source unit value to a target unit value. This represents the converted offset expressed in target units, and its dimensions are the same as... Same. Only when the source unit and the target unit have exactly the same dimensional designation. For a finite number greater than 0, The transformation is performed when the number of transformations is finite and the transformation entry is in a valid version.

[0032] This implementation can preset the following verifiable entries: a conversion factor of 1000 and an offset of 0 when converting kilograms to grams; a conversion factor of 0.01 and an offset of 0 when converting centimeters to meters; a conversion factor of 88.4 and an offset of 0 when converting serum creatinine from milligrams per deciliter to micromoles per liter, and a conversion factor of 1 / 88.4 when converting in reverse. The allowed range of a field is determined by the minimum, maximum, and decimal places in the interface data dictionary. This range is only used to detect interface overflows or format errors and is not used as a clinical normal value or dosage adjustment threshold. When the data dictionary does not provide a range, only the value is verified to be a finite real number and satisfies the condition that the denominator of the corresponding formula is non-zero.

[0033] The dosage baseline determination module includes a rule reading unit, a unit conversion unit, a baseline dose calculation unit, and a dose level selection unit. Each dosage rule must include at least the rule identifier, rule source, applicable drug, applicable treatment regimen, dose calculation type, required data items, validity period of each data item, limited units, liver function adjustment conditions, kidney function adjustment conditions, past adverse reaction adjustment conditions, condition priority, condition merging method, dose level mapping method, allowed dose level, cessation of recommendation conditions, effective time, expiration time, rule status, and rule version. Once a rule is published, it does not overwrite older versions. The recommendation task selects a unique rule version that is currently in effect, has a valid rule status, and matches both the applicable drug and treatment regimen based on the planned dosing time. If multiple rules with the same priority exist, no applicable rule exists, or the current rule has been withdrawn, the task will proceed to manual processing. The rule reading unit first outputs the required data items and their event association configurations. Only after the clinical status segmentation module returns a complete set of status-consistent dose bases will the baseline dose calculation unit perform the dose calculation.

[0034] Each dose rule node uses a fixed field structure: node identifier, input data item code, comparison operator, lower limit value, upper limit value, lower limit inclusion flag, upper limit inclusion flag, threshold unit, number of reviews, review observation duration, output action, output dose level, adjustment ratio, dose level mapping method, stop recommendation flag, and priority. The comparison operator is only allowed to be less than, less than or equal to, equal to, not equal to, greater than or equal to, greater than, within the interval, or outside the interval; the dose level mapping method is only allowed to be either downward mapping or the most recent mapping; the priority is an integer from 1 to 9999, with smaller values ​​indicating higher priority; the number of reviews is an integer from 1 to 99; and the review observation duration is an integer from 0 to 525600 minutes.

[0035] The validity period of each data item is saved in minutes, with an allowed range of 1 to 525,600 minutes; the data re-acquisition waiting interval is saved in minutes, with an allowed range of 0 to 525,600 minutes; the allowed dose levels are finite decimals greater than 0 with consistent units, and are sorted from highest to lowest dose value; the adjustment ratio is a finite decimal greater than 0. The above ranges are the technical storage and verification ranges for rule fields and do not represent the clinical values ​​for specific drugs. The actual validity period, waiting interval, threshold, adjustment ratio, and allowed dose levels are all read from the approved rule record containing the rule source, issuing entity, effective time, and version number. The system does not generate default clinical values; if any necessary field is missing, exceeds the field range, or has inconsistent units, the rule issuance verification fails.

[0036] Rule publication verification is performed sequentially: drug and treatment plan uniqueness verification, required data item availability verification, unit dimension verification, interval endpoint order verification, dose level uniqueness verification, dose level mapping method integrity verification, conditional branch coverage verification, and version effective interval overlap verification. Interval endpoint order verification requires the lower limit to be no greater than the upper limit; the same input condition cannot be mapped to two different output actions simultaneously. If branch overlap exists, ambiguity must be resolved by different priorities; otherwise, the rule cannot be published. When using downmapping, the rule must also specify the stop recommendation action when the target dose is below the minimum allowable dose level; when using nearest mapping, the safety side selection method under equidistant conditions must be specified.

[0037] like Figure 3 As shown, the rule reading unit reads the calculation parameters according to the dose calculation type. For fixed dose type, it reads the fixed baseline dose configured in the rule; for weight-based dose type, it reads the effective weight and dose per unit weight specified in the rule; for body surface area-based dose type, it reads height, effective weight, and dose per unit body surface area; and for dose type based on renal function parameters, it reads the types of renal function parameters, parameter acquisition methods, and classification intervals specified in the rule. Effective weight is the actual weight, ideal weight, adjusted weight, or other clinically confirmed weight value explicitly specified in the current rule; the system does not automatically select between different weight definitions.

[0038] In an alternative implementation of the body surface area-based dosage, the current rule can be implemented using the Mosteller empirical formula to calculate the body surface area: ; In the formula, This represents the body surface area, expressed in square meters. This indicates the verified height record, expressed in centimeters. This represents the valid weight record selected by the current rule, expressed in kilograms; 3600 is an empirical constant corresponding to the combination of centimeter, kilogram, and square meter values. This formula performs empirical conversions according to the specified units, requiring... and All values ​​are finite numbers greater than 0. This formula will not be executed if any input is missing, invalid, unit conversion fails, or the data collection period is outside the current rule's allowed range. If specific drug rules require the direct use of clinically confirmed body surface area, the system will read the confirmed value, unit, and record identifier, without recalculating.

[0039] The baseline doses corresponding to fixed dose, weight-based dose, and body surface area-based dose are expressed as follows: ; ; ; In the formula, Indicates the baseline dose; This indicates a fixed dose given by the rules; Indicates dosage per unit body weight; This indicates the effective weight that has been selected according to the rules and standardized into units. Indicates dose per unit body surface area; It represents the surface area of ​​a body. , The final candidate dose is administered using the prescribed drug quality units. The dimension of measurement is per kilogram of drug mass. The dimension is drug mass per square meter. and By eliminating kilograms and square meters from the denominators, the output dimension of all three basic dosage formulas is drug mass. The unit conversion unit verifies whether the calculation result can be converted to the prescribed drug mass units before calculation; if verification fails, no basic dosage is generated.

[0040] For dosing rules based on renal function parameters, the system prioritizes renal function parameters that have been reviewed by the testing system and whose method identification is consistent with the current rule. The following formula is used only when the current rule explicitly requires the use of the Cockcroft-Gault empirical formula to estimate creatinine clearance, age and effective body weight are fully recorded, serum creatinine units have been converted to mg / dL, and the conditions for determining the correction factor are met: ; In the formula, This indicates the estimated creatinine clearance rate, expressed in milliliters per minute. A numerical value representing age in years; This indicates the effective weight specified by the current rule, expressed in kilograms. It represents the value of serum creatinine in milligrams per deciliter and must be greater than 0; This represents the dimensionless correction coefficients. 140 and 72 are empirical constants corresponding to the numerical units mentioned above and the original Cockcroft-Gault empirical relationship; they have absorbed numerical scaling and unit conversions and are not considered as variables to be determined. This rule is only executed when the current rule explicitly requires the use of this empirical formula, the input is within the applicable range of the rule statement, and the conditions for determining the correction coefficients are met; when using the original form, the rule can... Configure to 1 or 0.85, and determine the value based on the audited structured demographic fields and applicable rules. (For fields missing, audit invalid, etc.) Automatic calculation will stop and manual processing will begin if the value is not greater than 0 or the input exceeds the applicable range of the rule. If the current rule requires the use of estimated glomerular filtration rate from laboratory reports, measured glomerular filtration rate, or other confirmed parameters, the system will directly use the corresponding parameter and method identifier, without substituting this formula.

[0041] After the baseline dose is generated, the dose level selection unit evaluates liver function adjustment conditions, kidney function adjustment conditions, and past cycle adverse reaction adjustment conditions according to the pre-determined priority of the current rules. Each condition consists of input items, comparison operators, threshold, threshold unit, continuity or review requirements, output dose level, and stop recommendation flag. When multiple conditions are met simultaneously, the dose adjustment result is determined according to the condition merging method configured in the rules; the condition merging method includes selecting the dose level with the largest dose reduction, or returning the first dose level that meets the condition priority. The system records the rule node identifier for each met condition, the record identifier of the referenced clinical record, and the source record version.

[0042] Dosage adjustment conditions are executed according to the following deterministic logic: First, a unique record in the dose basis set with consistent status is obtained by encoding the data item. Its value is then converted to a rule node unit, and the determination is made according to the node comparison operator. Within an interval, if the lower limit containment flag is 1, greater than or equal to the lower limit is used; otherwise, greater than the lower limit is used. If the upper limit containment flag is 1, less than or equal to the upper limit is used; otherwise, less than the upper limit is used. Outside the interval, the logical negation of the aforementioned interval conditions is applied. When the number of reviews is 1, only the currently selected record is considered. When the number of reviews is greater than 1, a specified number of valid records are obtained in reverse chronological order of collection time within the review observation period. A hit is determined only when all records meet the conditions; if the number of records is insufficient, the record is output for manual processing.

[0043] A precise mapping is used between the output actions of rule nodes and candidate doses: When the output action is KEEP, the baseline dose is maintained; when the output action is LEVEL(i), the i-th level in the set of allowed dose levels is selected; when the output action is RATIO(r), the baseline dose is multiplied by the adjustment ratio r before mapping to the allowed dose level; when the output action is STOP or the stop recommendation flag is 1, no candidate dose is formed. When multiple nodes hit simultaneously, if the condition merging method is MAX_REDUCTION, the level with the lowest dose value is selected from all hit outputs; if the condition merging method is FIRST_PRIORITY, the node with the lowest priority value is selected. When the outputs of nodes with the same highest priority are inconsistent, no automatic selection is performed, and the node is switched to manual processing.

[0044] When the current rule explicitly represents multiple adjustment conditions as multiplicative adjustment ratios, the intermediate target dose is calculated first, and then the allowed dose level is selected according to the dose level mapping method required by the rule. The dose level mapping method is denoted by the current rule as either downward mapping or nearest mapping; if not configured, rule publication verification will fail. The corresponding relationship is expressed as follows: ; ; ; In the formula, This indicates the adjusted intermediate target dose; Indicates the baseline dose; Indicates the first A dimensionless adjustment ratio that is explicitly set to be multiplicable by the current rules, and is a finite number greater than 0; This indicates the adjustment ratio involved in the multiplication; when it is 0, the product is 1. Indicates the index in the set of allowed dose levels. The dose value; Represents the set of allowed dose level indices; Indicates the dosage level mapping method; Indicates the target level index; This represents the independent variable that makes subsequent given conditions true or maximizes the objective function; Let represent the independent variable that minimizes the subsequent objective function; Indicates target level index The corresponding permissible dose level; Indicates downmapping; Indicates the most recent mapping; Indicates the candidate dose. When using downmapping, select doses no higher than [previous dose]. The maximum permissible dose level; if this level does not exist, the recommended action is stopped. The minimum absolute distance is selected only if the audited rule explicitly configures the nearest mapping; if two levels are equidistant, the lower value is selected. For rules that directly output discrete dose levels, proportional multiplication is not performed; instead, the level output by the rule branch is used as the minimum absolute distance. .

[0045] The stop recommendation criteria are used to handle situations where existing data cannot be reliably mapped to candidate doses by the current rules. These can be related to situations such as missing required data items, failure to re-collect state-sensitive doses after the state boundary, test results entering the manual review period set by the rules, paused medical orders, mismatch between treatment plans and medications, or non-unique applicable rules. When the stop recommendation criteria are met, the system sets the recommendation task to pending manual processing, outputs the trigger conditions, missing or abnormal items, and related records, and does not pass candidate doses to the recommendation version management module.

[0046] The manual review interval defined in the rules is not an abstract state, but rather an interval node composed of input data item codes, lower limits, upper limits, upper and lower limit inclusion flags, and threshold units. Its determination method is completely consistent with the aforementioned interval operations, and the output action upon a match is fixed as STOP_REVIEW. The specific endpoints of this interval must be saved as fields in the reviewed rule version; this system does not derive endpoints based on statistical distributions or unstructured text. The abnormal items output after stopping recommendations must include at least the rule node identifier, input value, input unit, interval endpoints, record identifier used, source record version, and trigger time.

[0047] Before clinical status segmentation, the system first performs source and format integrity checks according to the list of required data items for the current rules. This checks each record to ensure it exists, can be converted to the correct unit, has a valid audit status, and is consistent with the patient, treatment cycle, and planned dosing time. If any required data item is not met, a list of supplementary data is generated, including the data item code, missing or abnormal type, target unit, allowed collection period, and recommended task identifier. This check is used to exclude abnormal formats or correspondences. Whether a record is in the correct clinical status is determined again by the clinical status segmentation module according to the boundaries of each status.

[0048] The clinical status segmentation module addresses the issue where individual records meet the validity period requirements but, when combined, do not belong to the same clinical status. It includes an event association rule unit, an event retrieval unit, a status boundary calculation unit, and a dosage basis selection unit. The event association rule unit configures for each status-sensitive dosage basis the treatment execution event type, affected data items, event completion conditions, and data re-acquisition waiting interval that can change its applicable status. The data re-acquisition time is obtained by adding the event completion time to the corresponding waiting interval; the waiting interval is jointly determined by the current drug, treatment plan, event type, and data items, and is saved with each rule version.

[0049] Event association rules are represented by a single record for a combination of drug identifier, treatment protocol identifier, data item code, and event type. Record fields include association flag, event completion predicate, data re-acquisition wait interval, rule source, and rule version. An event only affects a data item if the drug identifier, treatment protocol identifier, data item code, and event type are all identical and the association flag is 1; unregistered combinations are considered to have an association flag of 0 and do not participate in state boundary calculations. The event completion predicate is composed of an execution state condition, a required time field condition, and an optional cumulative quantity condition, logically ANDed.

[0050] To provide directly reproducible mapping examples, the simulation event association table in this implementation can associate: blood purification with renal function, electrolytes, and effective body weight; blood transfusion with blood cell count; hydration therapy reaching drug-specific fluid replacement volumes with effective body weight, renal function, and electrolytes; continuous drainage with effective body weight and electrolytes; diuretic therapy with effective body weight, renal function, and electrolytes; and contrast agent administration with renal function. Each combination in the table is saved as an independent association entry, and event-data item combinations not listed are not associated. This mapping only illustrates the event-driven data reselection mechanism; in actual deployment, the simulation entries are replaced with the rule version confirmed by the release process.

[0051] Treatment execution events include blood purification, blood transfusion, hydration therapy reaching the drug-specific fluid resuscitation volume, continuous drainage, diuresis therapy, and contrast agent administration. Event records must include at least an execution record identifier, event type, start time, completion time, execution status, target patient, and treatment cycle. The completion predicate for blood purification, blood transfusion, and contrast agent administration is that the execution status is equal to "complete" and the completion time is not empty; the completion predicate for hydration therapy is that the cumulative fluid resuscitation volume reaches the rule threshold and at least one fluid resuscitation segment is in the "complete" state; the completion predicate for continuous drainage and diuresis therapy is that the source system sets the corresponding execution record to "complete" or "terminated," the completion time is not empty, and the final cumulative volume record has been approved. If any required field is missing, or the execution status is "planned," "in progress," "cancelled," or "revoked," a completed event is not generated; for events in progress that may affect dosage, only a "pending manual processing" prompt is generated, and the completion time is not estimated.

[0052] For hydration therapy, the cumulative fluid resuscitation volume, as confirmed by the treatment, is expressed as follows: ; In the formula, This indicates the time from the start of the current hydration therapy to the present moment. The cumulative volume of fluid replenishment performed is expressed in volume units as defined by the current rules. Indicates the first The actual input quantity of each completed fluid replenishment execution segment, after review and confirmation and completion of unit standardization, must be a finite number greater than 0; Indicates the end time A set of segments where the patient, treatment cycle, and hydration therapy identifier all match, and the execution status is completed and not revoked; This indicates the given time point at which the cumulative fluid resuscitation volume has been calculated. The drug-specific fluid resuscitation volume threshold is denoted as... The rule field allows values ​​greater than 0 and not exceeding 100,000 ml, with a minimum resolution of 0.1 ml. This range is only for preventing overflow at the interface; the actual threshold must be derived from the currently approved rule version. Greater than or equal to Events that alter hydration status during treatment should be recorded. Urine output and drainage volume should be retained as separate clinical records and should not be automatically deducted from cumulative fluid resuscitation unless explicitly required by current rules.

[0053] like Figure 4 As shown, the event retrieval unit first determines the effective period of each state-sensitive dose based on the planned dosing time and the drug-specific effective duration. For the first... The dosage basis and the start point of the drug-specific effective period are expressed as follows: ; In the formula, Indicates the first The starting point of the drug-specific effective period based on the dosage; Indicates the planned dosing time; Indicates the current medication, treatment plan, and... The dosage is based on the corresponding effective duration. Stored as positive integers from 1 to 525,600 minutes, and converted to the same duration type as timestamps during calculations; missing values, values ​​outside the range, or time unit conversion failures result in invalid periods. All times are first converted to a unified time zone and accurate to the second, including interval endpoints, i.e., the acquisition time equals... or The records can be used for subsequent screening.

[0054] The event retrieval unit's retrieval completion time shall not be later than And the data re-collection time point is no earlier than Completed treatment execution events are included, requiring that the corresponding patient, treatment cycle, event type, and affected data items all match the event association rules. Therefore, events whose completion time is earlier than the start time of the validity period, but whose data re-collection waiting process extends into the validity period, are still included to avoid omissions affecting the applicability of records within the validity period. For the [missing information], Dosage basis and events The data re-collection time point meets the requirements. .in, For the current rule targeting the first Dosage basis and events The configured data re-acquisition waiting interval is an integer ranging from 0 to 525600 minutes; a waiting interval of 0 indicates that re-acquisition can begin as soon as the event is completed. If no waiting interval is configured, the waiting interval is negative, or the unit cannot be converted, the associated entry for the event will be invalid, and the recommended task will be switched to manual processing.

[0055] ; In the formula, Indicates the first The state boundary of the dose-based treatment; This indicates the start point of the drug-specific effective period based on this dosage; Indicates completion time no later than Data re-collection time should not be earlier than A set of completed events that matches the patient, treatment cycle, event type, and affected data items; Indicates an event Completion time; This represents a data re-acquisition point mapping function determined by the event completion time and waiting interval; Indicates the non-negative data re-acquisition waiting interval; This indicates taking the latest time point (maximum value) among the items in the parentheses or the items in the set. When empty, the innermost maximum value is not included in the calculation. Pick If the data recollection time for a certain event is later than If there are no available records for this dosage before the planned dosing, the recommended task should be put into a state of waiting for update or manual processing.

[0056] When multiple required data points are used in the calculation of the same candidate dose, the system calculates the state boundaries for each data point separately and selects records based on the state boundaries of each data point itself. The system then organizes the state boundaries, sorted by data point encoding, into a state boundary set. Simultaneously, the latest time point is recorded as the aggregated state boundary. The aggregated state boundary is used to quickly filter recommended tasks that may be affected by new events. The specific record selection and version failure determination are still based on the complete set of state boundaries. To ensure accuracy and prevent boundary changes of a particular data item from being masked by the aggregated maximum value.

[0057] The dosage selection unit selects records that have been approved, are currently valid, and whose data collection time is closest to the planned dosing time from the corresponding status boundaries to the planned dosing time. The deterministic selection relationship based on dosage is expressed as follows: ; ; In the formula, Indicates the first The final selected record; This represents a set of optional records that meet the conditions of time range, review status, and validity status. Indicates the target patient, treatment cycle, and number of treatments. A set of candidate records for matching item data encoding; Representing records The collection time; Indicates the review status; Indicates a valid state; Indicates the first Item state boundary; This indicates the planned dosing time; the First operation in the formula means retrieving the first record after sorting according to the total order comparison key described later. Indicates that for the first Total sequence comparison key for dosage data; This represents any clinical record to be screened from the candidate record set; Indicates that the review has been approved; Indicates the current valid state.

[0058] The selection order of multiple records is fixed according to the following total order comparison key: descending order of collection time, descending order of review time, descending order of source record version, ascending order of source priority, and ascending order of record identifier dictionary order. This total order ensures that even if multiple records have the same collection time, the final selected record remains unique. The source priority is an integer from 1 to 999, with smaller values ​​indicating higher priority. The data dictionary for each data item must set a unique highest priority for the source system that directly generated the data, followed by verified synchronous copies and manually entered structured data. If the source system does not provide a monotonically increasing version number, the source adapter generates a monotonically increasing integer version based on the update time and arrival sequence number of the same source record identifier. If the source priority is missing or the record identifier cannot form a stable dictionary order, the selection will not be automatic and will be pending manual processing.

[0059] After all necessary data items have been selected, the system assembles these records into a dose basis set with consistent status. Consistent status here means that each record is located after the corresponding status boundary and before the planned dosing time, and has a valid review status; it is not required that all records be collected in the same minute. When the set is complete, the clinical status segmentation module transmits the set and the status boundaries of each item to the dose basis determination module to perform baseline and candidate dose calculations. If no record is selected for any item, no candidate dose is generated, a corresponding re-examination prompt is generated, and the recommended status is set to "awaiting update." Upon receiving a new record, the clinical data access module triggers incremental recalculation based on the recommended task identifier.

[0060] It is recommended that the version management module use immutable versioning to save calculation results. For example... Figure 5As shown, a recommendation task can sequentially generate multiple dosage recommendation versions. The database uses conditional unique constraints to override callable states such as valid and sent, and performs atomic conditional updates in state transition transactions, ensuring that at any given time, at most one version is in a valid and callable state. Version states include waiting for data, awaiting physician confirmation, awaiting pharmacist review, valid, sent, configuration started, invalid, and historical invalid. Allowed forward transitions are: waiting for data to await physician confirmation, awaiting physician confirmation to awaiting pharmacist review, awaiting pharmacist review to valid, valid to sent, and sent to configuration started; a version becomes invalid if any review fails. If input, boundary, recommendation task primary key, or rule version changes occur before configuration starts, the states of awaiting physician confirmation, awaiting pharmacist review, valid, or sent can all become invalid; invalid versions cannot be restored to valid, but can only be used to create new versions based on updated data.

[0061] Version identifiers correspond to target patients, treatment regimens, treatment cycles, recommended anti-tumor drugs, and planned dosing times. To detect whether the same input has generated the same version, version fingerprints can be generated for key fields: ; In the formula, Represents the version fingerprint; SHA-256 represents the deterministic digest operation; This indicates the deterministic length prefix encoding described later; Indicates the internal identifier of the target patient; Indicates treatment plan identification; Indicates the treatment cycle; Indicates the labeling of anti-tumor drugs to be recommended; Indicates the planned dosing time; This represents the set of state boundaries sorted by data item encoding; This represents the set of selected record identifiers, source record versions, collection times, review statuses, and valid statuses after sorting by data item codes. Indicates the version of the dosage rule.

[0062] Before performing SHA-256, deterministic encoding is used: fields are arranged in the order listed in the formula, and each field sequentially contains a 2-byte field type, a 4-byte unsigned length, and a UTF-8 field value; time is uniformly encoded as an ISO 8601 second-level string in the UTC time zone; decimal numbers are stripped of meaningless trailing zeros and retain at least one decimal place; null values ​​are represented by a length of 0xFFFFFFFF, and the byte length of non-null fields must not exceed 0xFFFFFFFE. Both the state boundary set and the selected record set are first sorted in ascending order by data item encoding. With this encoding, the same input will inevitably produce the same fingerprint, and different field combinations will not cause parsing ambiguity due to simple string concatenation. The version fingerprint is only used for consistency comparison and deduplication hints; it is not used as a unique collision-free identifier, nor does it replace the version identifier generated by the database.

[0063] Each recommended dose version simultaneously saves the base dose, adjustment conditions for hits, allowed dose levels, candidate doses, unit conversion paths, selected record sets, complete state boundary sets, summary state boundaries, associated event record identifiers, rule versions, physician confirmation results, pharmacist review results, authorization identifiers for each operator, and operation times. When a physician or pharmacist modifies a candidate dose, the original version is not directly overwritten. Instead, the modified value and the reason for the modification are recorded to form a new version awaiting review, while the old version is relegated to a historical invalidation state.

[0064] The pre-configuration review module includes an update receiving unit, an impact index unit, a boundary recalculation unit, a record reselection unit, a rule review unit, a version comparison unit, and a queue withdrawal unit. The update receiving unit receives updates on test results, medical orders, treatment execution events, and dosage rule version status through incremental subscription or polling. The polling period can be configured from 1 to 300 seconds and is determined by the interface throughput. Subscription or polling only affects the time it takes to discover an update and does not affect eventual consistency, because the configuration terminal re-verifies the version status and rule version when confirming the start of configuration. Update messages must include at least the source record identifier or rule version identifier, source record version, update time, update type, and data item code or event type. The impact indexing unit builds an inverted index from the data item code, event type, source record identifier, and rule version identifier to the recommended task identifier; the boundary recalculation unit only recalculates the data items hit by the index; the record reselection unit re-executes the same selection order; the rule review unit redetermines the current applicable rule version corresponding to the planned dosing time; the version comparison unit compares the set, task primary key, and rule version before and after the update; and the queue withdrawal unit sends a withdrawal message after the failed transaction is committed.

[0065] When comparing the complete set of state boundaries before and after the update with the selected set of records, the failure determination is expressed as: ; ; In the formula, Indicates failure status; and These represent the complete set of state boundaries between the updated and original versions; and These represent the selected record sets after the update and those in the original version, respectively. and These represent the currently applicable dosage rule version after the update and the dosage rule version bound to the original version, respectively. and These represent the recommended task primary keys after the update and the original version, respectively. The status boundary set is composed of an ordered list based on data item encoding and second-level status boundaries; the selected record set is composed of an ordered list based on data item encoding, record identifier, source record version, second-level collection time, review status, and valid status.

[0066] Set equality is determined by element-wise complete equality, without setting time or numerical tolerance. If the state boundary of any data item changes, or the record identifier, source record version, collection time, review status, or validity status of any selected record changes, or the current applicable dosage rule version differs from the original version, or the original rule version is withdrawn, or the recommended task primary key changes, then the failure flag is set to 1, and the original dosage recommendation version becomes invalid; the failure flag is set to 0 when all corresponding elements, rule versions, and task primary keys are equal. Even if the candidate dosage values ​​are the same before and after the update, as long as the input record version, state boundary, rule version, or task primary key is different, a new version to be reviewed is still formed. When the drug identifier, planned dosing time, treatment cycle, source medical order identifier, or configuration status in a medical order changes, it is treated as a change in the recommended task primary key, and the original version becomes invalid.

[0067] like Figure 6 As shown, after the recommended dosage version enters an effective state, the pre-configuration verification module sends a queue item containing a version identifier to the chemotherapy drug configuration terminal, instead of sending the dosage text that can be used independently of version management. When reading the queue item and confirming the start of drug configuration, the chemotherapy drug configuration terminal verifies the version identifier, target patient, planned dosing time, recommended antitumor drug, and version status with the recommended version management module. After the pre-configuration verification module sets the version to invalid, it withdraws the queue item using the same version identifier; the terminal refuses to return the candidate dose when reading or confirming the start of configuration again.

[0068] Version invalidation and queue withdrawal can be completed within the same database transaction, or using a message with a version number and an idempotent withdrawal interface. When using the message method, the withdrawal message must at least include the recommended task identifier, the invalidated version identifier, and a monotonically increasing event sequence number. The terminal rejects messages with event sequence numbers less than the locally processed sequence number, and performs idempotent processing on messages with the same event sequence number to prevent network out-of-order delivery or retransmission from overwriting the new invalidated state with the old valid state. When the terminal confirms the start of drug configuration, the recommended version management module verifies through atomic condition updates that the version is still valid and the configuration status is still "not started." If the verification passes, the configuration status is updated to "started"; if the verification fails, candidate doses are not allowed to be called.

[0069] In one data processing example, the system configures simulation rules based on body surface area for the desensitized simulated drug identifier ONC-X01. This example is only for illustrating the system's data processing procedure and does not represent the clinical dosage of any real anti-tumor drug. All times are within the same hospital's unified time zone, the planned dosing time is 18:00 on the same day, and the effective duration of renal function data is 24 hours. The target patient's height record is 168 cm, and the effective weight record is 62 kg. Both records match the current treatment cycle and are valid. The body surface area is calculated using the aforementioned formula to be 1.700980… square meters, displayed as 1.701 square meters to three decimal places. The unit body surface area dose in the simulation rules is 100 mg / m², and the baseline dose is 170.098… mg, displayed as 170.1 mg to one decimal place. The rules allow dose levels of 170 mg, 150 mg, and 130 mg, respectively. When a previous cycle adverse reaction condition configured by the simulation rules is met, the second dose level is directly output, thus forming a candidate dose of 150 mg.

[0070] The initial candidate dose was generated at 08:00 on the same day, and the system used a renal function record collected and verified at 07:30 on the same day. Subsequently, the nursing system wrote the contrast agent administration execution record, which was completed at 09:10 on the same day. The event association rules registered the contrast agent administration as a treatment execution event that could change the applicable state of the renal function dose, and configured the corresponding data re-collection waiting interval to 6 hours. Therefore, the data re-collection time was 15:10 on the same day. Since the completion time of this event was no later than 18:00, and the data re-collection time was no earlier than the start time of the valid period at 18:00 on the previous day, it was included in the event set. The state boundary of the renal function dose was the later of the start time of the valid period and 15:10, i.e., 15:10 on the same day. The record collected at 07:30 was located before this state boundary. The configuration pre-review module invalidated the original dose recommendation version, withdrew the pending configuration queue item, and generated a renal function re-examination prompt.

[0071] After the testing system writes a new, approved, and currently valid renal function record at 16:00 on the same day, this record is within the selectable range from 15:10 to 18:00. The system selects it into the updated state-consistent dose basis set according to deterministic total ordering, and calls the same effective dose rule version to generate a new candidate dose and a new recommended version of the dose to be reviewed. The new version can only enter the effective state and be called by the chemotherapy drug preparation terminal after being reconfirmed by the physician and reviewed by the pharmacist. This process reflects the linkage between treatment execution events, data re-collection time points, state boundaries, record selection, version invalidation, queue withdrawal, and manual dual review.

[0072] In another data update instance, the system corrects a platelet count record that was already included in the recommendation. The correction message retains the same source record identifier and adds a source record version, while marking the old version as invalid. The pre-configuration review module locates the recommended dose version referencing this record based on the record identifier and re-executes the record selection. Even if the corrected value still maps to the same candidate dose, if the source record version or review status changes, the original recommended dose version is still invalidated and a new version awaiting review is formed, ensuring that physician confirmation and pharmacist review are based on a specific data version.

[0073] The system is configured with role permissions, data access control, and audit control. Clinical data access, rule publishing, physician confirmation, pharmacist review, version expiration, and configuration initiation each use independent permissions; the interface service only reads fields required for the current recommended task, and configuration terminal messages do not carry clinical records unrelated to the task. Rule publishing saves the rule source, effective time, and version; rule versions already referenced by the dosage recommendation version cannot be deleted. Audit logs record the recommended task identifier, version identifier, operation type, operation time, authorized entity, and operation result.

[0074] This implementation method employs deterministic rule parsing, time boundary calculation, record filtering, and version state transitions to generate all candidate doses and determine failures. It does not use statistical models, machine learning models, or neural networks to output candidate doses, state boundaries, record selection results, or version states. Therefore, each input value, hit condition, calculation path, and version transition of a candidate dose can be reproduced using rule node identifiers, record identifiers, and audit logs.

[0075] Each module of this invention can be implemented by a processor executing computer programs stored in memory, or by a combination of interface services, a rule engine, a database transaction component, and a message queue component. The processor reads clinical records and rule data, performs state boundary calculations, record filtering, dose calculations, version comparisons, and state transitions, and exchanges queue messages containing version identifiers with the chemotherapy drug configuration terminal through the hospital intranet interface. Module names are used to describe functional divisions and do not limit physical deployment locations.

[0076] The database used to implement the above process includes at least a clinical record table, a rule version table, an event association table, a treatment execution event table, a recommended task table, a recommended version table, a version input record table, a state boundary table, and a queue event table. The clinical record table is associated with the version input record table through record identifiers and source record versions; the rule version table is associated with the recommended version table through rule versions; the event association table and the treatment execution event table jointly generate the state boundary table; the state boundary table and the version input record table jointly generate the recommended version fingerprint; the queue event table only stores the recommended task identifier, recommended version identifier, event sequence number, and queue status. This association direction ensures that the configuration terminal cannot directly obtain a sourceless dose copy without the recommended version.

[0077] The above description describes embodiments of the present invention and serves to illustrate the technical concept of the invention. Those skilled in the art can make equivalent substitutions for the data interface format, rule storage method, message transmission method, or module deployment method without departing from the technical solution defined in the claims.

Claims

1. A personalized dosage recommendation system for antitumor drugs based on multi-source clinical data, characterized in that, include: The clinical data access module is used to obtain the treatment plan, treatment cycle, planned dosing time and clinical records of the target patient; The dosage basis determination module is used to determine the required dosage basis and corresponding effective period of the antitumor drug to be recommended; The clinical status segmentation module is used to retrieve completed treatment events whose completion time is no later than the planned dosing time and whose data re-collection time is no earlier than the start time of the effective period. It determines the latest time point between the start time of the effective period and the data re-collection time of the associated event as the status boundary, and selects records between the status boundary and the planned dosing time that are valid and whose collection time is closest to the planned dosing time, forming a dose basis set with consistent status. The dose basis determination module is also used to generate candidate doses when the dose basis set is complete. The recommended version management module is used to bind the candidate dose with the version of the record, state boundary and dose rule used to an immutable recommended version; The pre-configuration review module is used to redefine the state boundaries and reselect records based on updates to clinical records, recommended task keys, and dosage rule versions. When the state boundaries, selected records, recommended task keys, or dosage rule versions change, the original version becomes invalid and the pending configuration queue item is withdrawn. Only valid versions confirmed by physicians and reviewed by pharmacists are allowed to be called.

2. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 1, characterized in that, The clinical data access module is specifically used for: Extract diagnosis, treatment cycle, height, weight, allergy history, and previous adverse reaction records from electronic medical records; Extract blood cell count, liver function, kidney function and electrolyte test results from the test records, and retain the specimen collection time, report time and review status of each test result; Extract fluid resuscitation, blood transfusion, blood purification, drainage, urine output, and the corresponding start and end times and status of the procedure from the nursing records. Extract drug identification, dispensing unit, planned dosing time, and preparation status from medical order records; The source system, record identifier, source record version, generation time, update time, and validity status are retained for the electronic medical records, laboratory records, nursing records, and medical order records, respectively.

3. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 1, characterized in that, The dose-based determination module is specifically used for: Read the dosage calculation type, required data items, and limited dosage units of the recommended antitumor drug from the dosage rules; When the dose calculation type is a fixed dose, a dose based on body weight, a dose based on body surface area, or a dose based on renal function parameters, the dose calculation rules corresponding to the dose calculation type are invoked respectively. The units of the required data items are converted to the units defined by the dose calculation rules. The base dose is generated after the dose basis set with consistent status is complete and the unit conversion is successful. The baseline dose is associated with the drug label, treatment duration, planned dosing time, and version of the dosage rule used for the recommended antitumor drug.

4. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 3, characterized in that, The dose-based determination module is also used for: Read from the dosage rules the liver function adjustment conditions, kidney function adjustment conditions, previous cycle adverse reaction adjustment conditions, condition merging method, dose level mapping method, allowable dose level and discontinuation recommendation conditions corresponding to the recommended antitumor drug; The dose adjustment result is determined according to the condition priority and condition merging method defined by the dose rule, and the dose level corresponding to the dose adjustment result is selected from the allowed dose levels according to the dose level mapping method. The base dose is adjusted to the selected dose level to obtain the candidate dose. When the aforementioned stop recommendation conditions are met, the recommendation task is set to a pending manual processing state, and no dose recommendation version is generated that can be sent; the dose rule also records the rule source, applicable drug, applicable treatment plan, effective time, expiration time, rule status, and rule version.

5. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 2, characterized in that, The clinical data access module is also used for: Verify the correspondence between the target patient, the treatment cycle, and the planned dosing time in the records from each source; Exclude revoked, corrected, or unaudited clinical records, and identify duplicate records, records with missing units, and records with inconsistent unit dimensions; when necessary data items are missing, record correspondences are inconsistent, or units cannot be converted, generate a list of data to be supplemented and prevent the formation of dose basis sets with the aforementioned status; When the required data items are complete and the corresponding records are consistent, the verified clinical records and their metadata will be transmitted to the clinical status segmentation module.

6. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 1, characterized in that, The clinical status segmentation module includes an event association rule unit, which is used for: For each required dose, the registration includes treatment execution event types that can change their applicable status, affected data items, event completion conditions, and data re-collection waiting intervals; blood purification, blood transfusion, hydration therapy to achieve drug-specific fluid replacement volume, continuous drainage, diuresis therapy, and contrast agent administration are registered as the aforementioned treatment execution event types; When the treatment execution record meets the corresponding event completion conditions, a completed treatment execution event is generated, and the sum of the completion time of the event and the corresponding data re-acquisition waiting interval is determined as the data re-acquisition time point; The execution record identifier, start time, completion time, execution status, and data re-collection time of the treatment execution event are associated with the affected required dose.

7. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 6, characterized in that, When determining the state boundaries, the clinical state segmentation module is specifically used for: Regarding the first Based on the state-sensitive dosage criteria, the starting point of the drug-specific effective period is determined according to the planned dosing time and the corresponding effective duration in the dosage rules; The search is for completed treatment events whose completion time is no later than the planned dosing time, whose data re-collection time is no earlier than the start time of the drug-specific effective period, and whose patient, treatment cycle, and event type all match the event association rules. When at least one of the completed treatment execution events is retrieved, the latest time point among the start time of the drug-specific effective period and the data re-collection time point of each completed treatment execution event is determined as the first time point. The state boundary is based on the state-sensitive dose. If no completed treatment event is found, the start point of the drug-specific effective period is determined as the [number missing]. The state boundary is based on the state-sensitive dose.

8. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 7, characterized in that, The clinical status segmentation module is also used for: For each required dosage basis, select the records from the clinical records between their corresponding status boundaries and the planned dosing time, where the review status is valid and the collection time is closest to the planned dosing time; When multiple records are collected at the same time, one record is selected in the following order: later review time, newer source record version, and higher source priority. The selected records are combined into a dose-based set that is consistent with the stated state; If any required dose basis is missing from the set of dose basis in the consistent state, no candidate dose is generated, a re-examination prompt corresponding to the missing required dose basis is generated, and the recommended state is set to waiting for update.

9. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 8, characterized in that, The recommended version management module is specifically used for: Generate a version identifier corresponding to the target patient, treatment plan, treatment cycle, recommended antitumor drug, and planned dosing time; Record the record identifier, source record version, collection time, review status and validity status of each clinical record in the dose basis set with consistent status in an immutable version manner, and record the status boundary, dose rule version, base dose, candidate dose, physician confirmation result, pharmacist review result and version status of each required dose basis; The recommended dosage versions after the candidate dosage is formed will sequentially enter the state of awaiting physician confirmation and the state of awaiting pharmacist review, and only the versions that have passed both physician confirmation and pharmacist review will be set to the valid state. Versions that fail any review will remain unsendable, and versions that are replaced by subsequent dose-recommended versions will be set to historical invalid status.

10. The personalized dosage recommendation system for antitumor drugs based on multi-source clinical data according to claim 9, characterized in that, The pre-configuration review module is specifically used for: After the recommended dosage version is confirmed by the physician and reviewed by the pharmacist, and before the medication preparation begins, we continuously receive updates on test results, changes in medical orders, updates on treatment execution events, and updates on the dosage rule version status. Based on the received updates, we redetermine the status boundaries of each required dosage, reselect clinical records, and redetermine the currently applicable dosage rule version. When any state boundary changes, or the record identifier, source record version, collection time, review status, or validity status of any selected clinical record changes, or the dosage rule version changes or becomes invalid, or when the primary key of the recommendation task composed of the target patient, treatment plan, treatment cycle, anti-tumor drug to be recommended, planned dosing time, and source medical order identifier changes, the corresponding dosage recommendation version will be set to invalid state, the corresponding queue item will be withdrawn from the configuration queue of the chemotherapy drug configuration terminal, and a new dosage recommendation version to be reviewed will be formed based on the updated dose basis set consistent with the status and the currently applicable dosage rule version. When the chemotherapy drug configuration terminal reads the queue to be configured and confirms the start of drug configuration, it verifies the version identifier, target patient, planned dosing time, recommended antitumor drug, dosage rule version, and version status. The candidate dose is only allowed to be called when the verification results are consistent and the version status is valid.

Images