A multi-source medical record closed-loop quality control method and system based on diuresis treatment event anchor point

Abstract

The application discloses a multi-source medical record closed-loop quality control method and system based on diuresis treatment event anchor points. Multi-source medical records are standardized into event nodes, a diuresis treatment event graph is constructed, and diuresis treatment exposure events are aggregated. The credibility of actual execution and strategy change candidate anchor points is scored, and the main candidate anchor points and alternative candidate anchor points are subjected to evidence attribution, gap detection and review time limit determination to determine actual execution anchor points, strategy change anchor points or anchor point uncertain states. Based on the anchor points, a dynamic monitoring window is generated, candidate evidence is attributed and credibility is evaluated, actual evidence sets, low-credibility actual evidence sets and evidence gap sets are formed, and a closed-loop state machine is driven. When record supplementing, correction, revocation, manual confirmation or delayed return occurs, the affected objects are incrementally recalculated, and state paths and traceable quality control evidence chains are output. The application can improve the accuracy, traceability and processing efficiency of diuresis treatment closed-loop quality control.

Description

Technical Field

[0001] This invention relates to a medical record quality control method and system, and in particular to a multi-source medical record closed-loop quality control method and system based on diuretic treatment event anchor points. Background Technology

[0002] Existing hospital information systems, electronic medical record systems, laboratory information systems, nursing systems, and intelligent infusion devices typically employ different data structures, business identifiers, and time fields. For the same diuretic treatment session, medical orders, actual execution, infusion pump status, urine output, fluid intake and output, laboratory tests, weight, vital signs, and verification records are scattered across different systems, making it difficult to establish stable and accurate correlations.

[0003] The time of prescription issuance, planned execution, actual execution, specimen sampling, reporting, measurement, and recording in records from different sources have different meanings and may be asynchronously written due to interface delays, manual data entry, or device upload delays. Existing processing methods typically categorize data according to the prescription plan time, record generation time, or calendar day, which can easily lead to mismatches between treatment events and monitoring records, incorrect attribution across windows, and repeated use of the same evidence.

[0004] Furthermore, numerical, temporal, or source conflicts may exist between multi-source records, and data additions, corrections, withdrawals, and delayed returns may also affect existing quality control conclusions. Existing systems struggle to simultaneously achieve conflict retention, gap differentiation, result traceability, and partial updates of affected data. Therefore, it is necessary to provide a closed-loop quality control method and system that can accurately correlate diuretic treatment events with multi-source monitoring records. Summary of the Invention

[0005] The technical problem this invention aims to solve is that the data structures, event identifiers, and temporal semantics among existing hospital information systems, electronic medical record systems, nursing systems, laboratory information systems, and intelligent infusion devices are inconsistent, making it difficult to accurately associate actual diuretic treatment events with corresponding monitoring records. This easily leads to mismatched monitoring evidence, duplicate attribution, incorrect attribution across windows, and overlapping of conflicting records from multiple sources. Furthermore, when medical records are supplemented, corrected, withdrawn, or returned with delays, existing processing methods typically require repeated processing of a large range of historical data, making it difficult to guarantee the consistency and traceability of quality control results.

[0006] To address the aforementioned technical problems, this invention provides a closed-loop quality control method for multi-source medical records based on diuretic therapy event anchors, comprising:

[0007] Collect multi-source medical records and perform standardized processing to generate standardized event nodes. Construct a diuretic treatment event map based on the correlation between standardized event nodes.

[0008] The diuretic prescription node, actual execution node, and continuous infusion status change node in the diuretic therapy event map are correlated and aggregated to form the diuretic therapy exposure event (DEE).

[0009] Candidate anchors are extracted from the medical records corresponding to the diuretic therapy exposure event (DEE), anchor confidence scores are calculated and effective candidate anchors are screened, and the actual execution anchor T0, strategy change anchor Tn or anchor uncertainty state is determined based on the effective candidate anchors.

[0010] A dynamic monitoring window is generated based on the actual execution anchor point T0 or the strategy change anchor point Tn. Candidate evidence is retrieved, and the candidate evidence is judged by the dynamic monitoring window attribution and data credibility, forming a set of actual evidence and a set of low-credibility actual evidence.

[0011] Based on the diuretic treatment exposure event DEE, anchor point, dynamic monitoring window, and required evidence template, a set of required evidence key is generated. Actual evidence is mapped to the corresponding evidence key, and an evidence gap set is generated based on the set difference between the required evidence key set and the set of satisfied evidence key.

[0012] The closed-loop state machine is driven by actual evidence, low-credibility actual evidence, evidence gaps, conflict records, review records, and subsequent review evidence, and outputs the state path and a traceable quality control evidence chain.

[0013] When medical records are supplemented, corrected, withdrawn, manually confirmed, or test results are returned late, the affected objects are determined based on the dependencies between the processing objects, and incremental recalculation is performed on the affected objects.

[0014] Furthermore, the diuretic treatment event map includes standardized event nodes and event edges; the event edges include at least the following: order association edge, execution attribution edge, diuretic treatment exposure event attribution edge, time window attribution edge, anchor point-confirmation relationship edge, and trigger-review relationship edge.

[0015] Furthermore, the diuretic prescription nodes, actual execution nodes, and continuous infusion status change nodes belonging to the same patient and the same visit are sorted according to the event time. When the event nodes have the same prescription identifier, execution identifier, or pump event identifier, or the event time interval does not exceed the preset maximum merging time interval and belongs to the same treatment chain, the corresponding event nodes are aggregated into the same diuretic treatment exposure event (DEE).

[0016] Furthermore, when there are two or more valid candidate anchor points, the valid candidate anchor points with the highest and second highest anchor point credibility scores are determined as the main candidate anchor point and the alternative candidate anchor point, respectively. Dynamic monitoring windows are generated using the candidate times of the two anchor points, and evidence attribution, evidence gap detection, and review time limit determination are performed. When at least one of the two sets of determination results is inconsistent, the anchor point is set to an uncertain state and a task awaiting manual confirmation is generated. When the two sets of determination results are consistent and the main candidate anchor point meets the preset conditions, the main candidate anchor point is determined as the actual execution anchor point T0 or the strategy change anchor point Tn.

[0017] Furthermore, the time of the medical order plan or the time of the course of treatment that has not been manually confirmed is not separately determined as the actual execution anchor point T0 or the strategy change anchor point Tn.

[0018] Furthermore, the anchor point credibility score is calculated based on the reliability of the source of the candidate anchor point, the reliability of the event type, the correlation strength of the medical order or execution order, the consistency of the time sequence, the consistency of the time chain structure of subsequent monitoring records, the consistency of the nursing link, the consistency of equipment records, and the candidate time conflict.

[0019] Furthermore, based on the anchor point type, diuretic category, route of administration, continuous infusion status, combined diuresis status, and diuretic treatment strategy, a corresponding monitoring window template is selected from the versioned monitoring window template library; the monitoring window template includes window start and end offsets, allowed delay, type of evidence to be retrieved, minimum confidence level, gap judgment rules, and loop closure time limit.

[0020] Furthermore, based on the degree of matching between the candidate evidence time and the dynamic monitoring window, the degree of matching between the candidate evidence type and the window task, the reliability of the evidence source, the correlation strength between the candidate evidence and the diuretic therapy exposure event (DEE), the consistency of the time sequence, the results of manual confirmation, and the delay or mismatch, the evidence attribution score of the candidate evidence is calculated. When the evidence attribution scores of the same candidate evidence for multiple dynamic monitoring windows all reach the preset attribution threshold, it is assigned to the dynamic monitoring window with the highest score, and the other dynamic monitoring windows are recorded as candidate windows.

[0021] Furthermore, based on the reliability of the source of candidate evidence, the completeness of key time fields, the consistency of similar evidence, the consistency of upstream and downstream records, the validity of the unit, the results of manual confirmation, the degree of record structuring, the data conflict situation, and the missing key time, the data credibility score of candidate evidence is calculated; candidate evidence that reaches the preset credibility threshold and has no unconfirmed conflicts is written into the actual evidence set, and other candidate evidence is written into the low credibility actual evidence set.

[0022] Furthermore, for numerical conflicts, temporal conflicts, or source conflicts among multiple source records, each conflicting record and its source tracing information are retained; when a conflict affects the determination result of the dynamic monitoring window attribution, evidence gap status, or whether the review has timed out, a task to be manually confirmed or a data supplement task is generated.

[0023] Furthermore, the evidence requirement key includes at least a diuretic treatment exposure event identifier, an anchor point identifier, a dynamic monitoring window identifier, an evidence type, and a requirement identifier; the required evidence requirement keys are formed into a set of required evidence requirement keys, the evidence requirement keys that have been satisfied by actual evidence are formed into a set of satisfied evidence requirement keys, and the evidence requirement keys in the set of required evidence requirement keys that are not included in the set of satisfied evidence requirement keys are determined as a set of evidence gaps.

[0024] Furthermore, when evidence exists but its data credibility is lower than the preset requirement, a low-credibility evidence marker is recorded in the evidence gap set; when evidence cannot be obtained because the data source system is not deployed, the interface is interrupted, or the key fields are unavailable, the corresponding evidence requirement key is separated from the ordinary evidence gap and written into the system unavailable exception set.

[0025] Furthermore, independent closed-loop state machines are established for the actual execution anchor point T0 and each strategy change anchor point Tn. State transitions are performed based on the dynamic monitoring window state, actual evidence, low-confidence actual evidence, evidence gaps, system unavailable exceptions, conflict records, review records, and subsequent review evidence. The state before the state transition, the state after the state transition, the triggering rule, the associated evidence, the transition time, the rule version, and the reason for not closing the loop are saved.

[0026] Furthermore, an index of affected objects is established based on the dependencies between standardized event nodes, diuretic therapy exposure events (DEE), anchor points, dynamic monitoring windows, evidence requirement keys, and state transition records. When medical records are supplemented, corrected, withdrawn, manually confirmed, or test results are returned late, only the affected diuretic therapy exposure events (DEE), anchor points, dynamic monitoring windows, evidence attribution results, evidence gap sets, and state paths are recalculated, and the quality control conclusions and state paths before and after the recalculation are retained.

[0027] The present invention also provides a multi-source medical record closed-loop quality control system based on diuretic therapy event anchor points, including a multi-source medical record processing module, a diuretic therapy exposure event aggregation module, an anchor point processing module, a dynamic monitoring window and evidence processing module, a gap detection module, a closed-loop status control module, and an incremental recalculation module;

[0028] The multi-source medical record processing module is used to collect multi-source medical records, generate standardized event nodes, and construct a diuretic treatment event map.

[0029] The diuretic therapy exposure event aggregation module is used to associate and aggregate diuretic prescription nodes, actual execution nodes, and continuous infusion status change nodes to form a diuretic therapy exposure event (DEE).

[0030] The anchor point processing module is used to extract candidate anchor points, calculate anchor point credibility scores, and determine the actual execution anchor point T0, the strategy change anchor point Tn, or the anchor point uncertainty state.

[0031] The dynamic monitoring window and evidence processing module are used to generate a dynamic monitoring window based on the anchor point, and to perform dynamic monitoring window attribution judgment and data credibility judgment on candidate evidence.

[0032] The gap detection module is used to generate the required evidence key set and the satisfied evidence key set, and to determine the evidence gap set and the system-unobtainable exception set.

[0033] The closed-loop state control module is used to drive the closed-loop state machine based on evidence, gaps, conflicts, review records and subsequent review evidence, and output the state path and traceable quality control evidence chain.

[0034] The incremental recalculation module is used to identify the affected objects and perform incremental recalculation on the affected objects when medical records are supplemented, corrected, withdrawn, manually confirmed, or test results are delayed.

[0035] Beneficial effects:

[0036] This invention converts medical order records, actual execution records, monitoring records, and review records generated from different systems into unified event nodes, and uses the actual execution anchor point T0 or the strategy change anchor point Tn as the time reference for the dynamic monitoring window. This can reduce the mismatch, duplicate attribution, and cross-window incorrect attribution caused by the inconsistency of time semantics between different systems in terms of treatment events and monitoring evidence.

[0037] This invention performs evidence attribution, gap detection, and review time limit determination by using primary candidate anchor points and alternative candidate anchor points respectively. It identifies anchor point uncertainty based on whether the results of the two sets are consistent. Compared with determining anchor points based on only a single candidate anchor point or the highest score, this invention can improve the accuracy of anchor point determination and subsequent quality control conclusions.

[0038] This invention performs evidence attribution judgment and data credibility judgment separately, and retains multi-source conflict records and their source tracing information, which can distinguish different problems such as incorrect evidence attribution, insufficient evidence credibility and data conflict, and improve the interpretability and traceability of quality control results.

[0039] This invention determines evidence gaps by the set difference between the required evidence key set and the satisfied evidence key set, and improves the reproducibility and auditability of quality control conclusions by combining system unobtainable exceptions and closed-loop state machine recording of state paths, manual confirmation, data supplementation and subsequent review processes.

[0040] This invention establishes an index of affected objects based on the dependencies between various processing objects. When medical records are supplemented, corrected, withdrawn, manually confirmed, or test results are delayed, only the affected objects are incrementally recalculated, reducing the repetitive processing of irrelevant historical medical records and improving the data processing efficiency and consistency of calculation results in asynchronous data update scenarios. Attached Figure Description

[0041] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0042] Figure 1 This is a schematic diagram of the overall process of the present invention.

[0043] Figure 2 This is a schematic diagram of the event spectrum.

[0044] Figure 3 This is a schematic diagram of anchor point sensitivity processing. Detailed Implementation

[0045] This invention adopts the overall approach of "first event, then anchor point, then window, then evidence, then closed loop," and uses unified event nodes, event graph edges, diuretic exposure events (DEE), anchor point confidence scores, evidence attribution scores, data confidence scores, gap detection based on demand key difference sets, and closed-loop state machines as interrelated computational objects. Specifically, DEE is used to determine the current processing object, the actual execution anchor point T0 and the strategy change anchor point Tn are used to determine the monitoring time base, the dynamic monitoring window is used to determine the evidence retrieval range, and AttrScore and DataConfidence are used to determine whether the evidence enters the actual evidence set or the low-confidence actual evidence set; by calculating the set difference between the required evidence demand key set K_req and the satisfied evidence demand key set K_act, the evidence gap set Gap is generated; the closed-loop state machine is used to determine the unclosed path and output state. The overall process and the sequential relationship between data objects in this invention are as follows: Figure 1 As shown.

[0046] Step S0: System Initialization and Dictionary Configuration

[0047] Establish a diuretic drug dictionary, which should include at least loop diuretics, thiazide or thiazide-like diuretics, tolvaptan, aldosterone receptor antagonists, and other diuretic-related drugs that can be dispensed in the hospital.

[0048] Establish a drug administration route dictionary, including intravenous push, intravenous drip, continuous infusion, oral administration, subcutaneous injection, etc.; establish a continuous infusion status dictionary, including start, rate adjustment, pause, resumption, and stop.

[0049] Establish an event type dictionary, a source system dictionary, an evidence type dictionary, a review semantic dictionary, and an evidence template appending tag dictionary.

[0050] Establish a monitoring window template library, a required evidence template library, data source priority, credibility scoring parameters, conflict threshold, state machine transition rules, and trigger priority rules.

[0051] Establish a rule version dictionary and parameter version table, and at least save the rule version number (rule_version), template version number (template_version), evidence template tag version number (template_tag_version), parameter version number (parameter_version), activation time, deactivation time, creator, reviewer, and applicable ward and department for subsequent evidence chain and review tracing.

[0052] Establish a dictionary for manual confirmation and supplementary entry status, including statuses such as pending confirmation, confirmed primary evidence, confirmed auxiliary evidence, rejected, supplementary entry completed, and exceptions outside the rules.

[0053] The evidence template addition tag is used to mark the windows or evidence requirements that need to be added based on the existing structured records, such as continuous infusion, combined diuresis, intravenous to oral administration, existing discharge plan, missing key time, or unavailable specific data sources; the tag is only used to select the monitoring window template or the required evidence template, and does not form a disease diagnosis, efficacy judgment or treatment instruction.

[0054] In one feasible algorithm parameter configuration, the effective threshold for candidate anchors can be set to 0.50, the minimum confidence threshold for anchors can be set to 0.70, the sensitivity threshold for anchors δ_anchor can be set to 0.05, the evidence attribution threshold can be set to 0.60, the data confidence threshold can be set to 0.60, and Δ_merge can be set to 24 h; the allowed delay can be set according to the monitoring window template. The above values ​​are only used to illustrate the parameter calling and calculation process and do not represent clinical thresholds, efficacy standards, or treatment standards. The actual configuration is recorded by parameter_version. When ratio calculations are involved, if the number of comparable records or the number of comparable records is 0, the corresponding sub-item takes the default value preset by parameter_version and records the incomparable mark; when there are fewer than 2 comparable pieces of evidence of the same type, the numerical conflict penalty item is set to 0; the thresholds used for normalization or division are all greater than 0.

[0055] Step S1: Access to Multi-Source Medical Records

[0056] Multi-source medical record data includes:

[0057] Obtain diuretic prescriptions, dosages, frequencies, routes of administration, initiation times, planned administration times, discontinuation times, and prescription status from the HIS.

[0058] Obtain information from the nursing system, including drug administration via barcode scanning, administration confirmation, intravenous push time, urine output, fluid intake and output, urine bag changes, catheterization records, shift records, and handover records.

[0059] The results of tests such as urine sodium, urine creatinine, creatinine, blood urea nitrogen, estimated glomerular filtration rate (eGFR), potassium, sodium, chloride, and magnesium are obtained from the LIS, along with the sampling time, receiving time, and reporting time.

[0060] Blood pressure, heart rate, oxygen saturation, daily weight, and time of weight change were obtained from the vital signs and weight system.

[0061] Obtain medical records, consultation records, follow-up medical orders, discharge records, and follow-up arrangements from EMR.

[0062] Acquire pump start, rate change, pause, resume, stop, and alarm events from infusion pumps or smart infusion devices.

[0063] Obtain records such as manual confirmation, gap exceptions, rule exceptions, and status feedback from the quality control platform.

[0064] When accessing each record, the system saves the time of the business occurrence, the time of system entry, the time of last modification, the interface batch number, and the unique message identifier message_id to distinguish between the actual event time, the supplementary entry time, and the data synchronization time.

[0065] When the same business event has different records in multiple systems, the system does not directly overwrite the old record, but retains the original record, generates a source index, and handles it uniformly in the subsequent evidence credibility scoring and conflict retention confirmation stages.

[0066] The multi-source medical records entering the high-confidence closed-loop quality control calculation must come from at least two source systems and include at least: (1) actual diuretic administration events, or equivalent records that can be manually confirmed to represent actual administration; (2) at least one type of monitoring or review record among urine volume, urine sodium, intake and output, weight, laboratory tests, vital signs, or review records. When only the time of the medical order plan, the time of reference for the course of treatment, or a single-source record is available, the system may generate low-confidence candidate clues or data to be supplemented prompts, but will not output the high-confidence closed-loop completion status.

[0067] Step S2: Standardize the raw data fields

[0068] Patient identifiers from different systems are uniformly mapped to the unique patient identifier patient_id, and a single outpatient or inpatient process is uniformly mapped to the unique outpatient / inpatient identifier encounter_id.

[0069] Map fields such as unique identifier of medical order, drug code, drug name, dosage, unit, route of administration, and execution status to a unified field.

[0070] Convert all time fields to a unified time zone and a unified time format, such as yyyy-MM-dd HH:mm:ss, and record the time source fields, including order_time, planned_time, scan_time, execute_time, administration_confirm_time, referenced_treatment_time (parsed from the medical record), sample_time, receive_time, report_time, measurement_time, device_upload_time, and record_time; while retaining the original time zone or source system time zone for backtracking.

[0071] Numerical fields are converted to preset target units within the hospital, such as urine volume in mL, weight in kg, urine sodium in mmol / L, and creatinine in μmol / L; the original values, original units, conversion formulas, and conversion identifiers are retained. When other target units are used within the hospital, the corresponding conversion rules are recorded in the parameter version log. The terms "intake" and "output" in this manual include both input and output volumes, with output volumes including urine volume and other recorded output volumes.

[0072] Retain the original record ID, source system, original table name or interface name, operator role, record creation time, and original path for evidence chain tracing.

[0073] Map the order number (order_id), administration number (administration_id), specimen number (specimen_id), lab item number (lab_item_id), pump event number (pump_event_id), nursing record number (nursing_record_id), and note number (note_id) to traceable fields respectively, and do not merge or overwrite the original IDs from different sources.

[0074] For each standardized record, a source traceability information field, `provenance`, is generated. This field records the source system (`source_system`), the source table or interface name (`source_table`), the source record identifier (`source_record_id`), the original record location (`raw_location`), the unique message identifier (`message_id`), the data access time (`ingest_time`), the last update time (`last_update_time`), and the rule version number (`rule_version`). This is used to support the backtracking of original records, identification of supplementary entries or corrections, traceability of rule versions, and review of the chain of evidence.

[0075] Step S3: Identification of Diuretic-Related Candidate Data Objects

[0076] Based on existing structured diagnostic records, disease course keywords, B-type natriuretic peptide (BNP), N-terminal pro-B-type natriuretic peptide (NT-proBNP) test records, echocardiogram records, inpatient department fields, and diuretic use records, candidate medical records or candidate data objects that need to be included in this data processing workflow are screened.

[0077] When there are existing records in the medical records related to heart failure, acute decompensated heart failure, pulmonary edema, increased volume overload, pleural effusion, edema, diuretic use, or other diuretic treatments, the system will only include the corresponding patient_id and encounter_id in the candidate data object set.

[0078] This step is only used to trigger the computer system to enter the closed-loop quality control process for diuresis-related monitoring, and the output is the candidate data object identification result; the system does not automatically generate a heart failure diagnosis because of this step, does not generate a clinical status judgment on intake and output, weight or urine output, does not make a judgment on diuretic resistance, and does not generate a treatment plan or drug dosage adjustment instruction.

[0079] Existing medical records or data items used for candidate data object identification include existing diagnostic records, BNP and NT-proBNP test records, echocardiogram records, inpatient department fields, and medical history keywords. These can generate candidate scenario event nodes for DIAGNOSIS (diagnostic record category), BIOMARKER (biomarker record category), IMAGING (imaging record category), DEPARTMENT (department record category), or HISTORY_KEYWORD (medical history keyword category). These candidate scenario event nodes are only used to initiate data processing, filter candidate data objects, or select evidence templates; they are not considered as automatically output disease diagnoses, treatment plans, medication plans, or discharge decisions.

[0080] Step S4: Standardized event node generation

[0081] Each medical order, execution record, continuous infusion status change, urine output record, fluid intake / output summary record, urine sodium sampling, laboratory report, weight record, vital signs record, progress note review record, consultation record, nursing handover record, discharge record, and follow-up arrangement is converted into a standardized event node. Execution events are event nodes generated from standardized actual medication records such as nursing barcode scanning, execution confirmation, intravenous push records, or infusion pump startup. Manual confirmations and status transition records generated in subsequent steps are appended as standardized event nodes upon their generation. Records containing diagnostic, biomarker, imaging, departmental, or medical history keywords used only for candidate scenario identification can be converted into scenario identification event nodes, and marked in the event_subtype field as being used only for data processing object identification.

[0082] Each event node must contain at least the following: node_id (unique identifier), patient_id (unique identifier), visitor_id (unique identifier for outpatient or inpatient care), event_type (event_type), event_subtype (event_subtype), source_system (source_system), source_record_id (source_record_id), event_time (event_time, empty if missing and marked with time_missing), time_type (time_type) or time source type (time_type), value and unit (unit, empty if not applicable), operator_role (operator_role), and raw_location (raw_location).

[0083] For records with multiple times, such as urine sodium results, the `sample_time`, `receive_time`, and `report_time` are saved separately, and a master event time and multiple auxiliary times are generated. The master event time is determined according to the time priority corresponding to the event type. For example, for actual drug administration events, `execute_time`, `administration_confirm_time`, and `scan_time` are used in order of priority. The `referenced_treatment_time` parsed from the course of treatment records is used as a low-confidence auxiliary time, and its original text location and parsed confidence level are saved. For test events, `sample_time`, `receive_time`, and `report_time` are used in order of priority. Time fields not selected as master event times are retained as auxiliary times.

[0084] Step S5: Construction of a Diuretic Therapy Event Map

[0085] Using standardized event nodes as graph nodes V and the relationships between events as edges E, a patient-level diuretic treatment event graph (hereinafter referred to as the event graph) G=(V,E) is constructed. Corresponding nodes and edges are incrementally added when subsequent window assignments, triggers, reviews, supplementary entries, or manual confirmations occur. The organization of event nodes and event edges is as follows: Figure 2 As shown.

[0086] The event edges mentioned above include at least the following: order association edges, execution attribution edges, chronological order edges, diuretic therapy exposure event attribution edges, time window attribution edges, anchor point-confirmation edges, evidence-confirmation edges, trigger-review edges, trigger data-review edges, gap-supplementation edges, gap-exception edges, and conflict-confirmation edges. Hereinafter, the order association edges, execution attribution edges, chronological order edges, diuretic therapy exposure event attribution edges, and time window attribution edges will be referred to as order association edges, execution attribution edges, chronological order edges, DEE attribution edges, and window attribution edges, respectively.

[0087] When two nodes belong to the same patient_id and the same encounter_id, and meet at least one of the following conditions, the system establishes a corresponding medical order association edge, execution attribution edge, or time sequence edge: the medical order identifier is the same; the nursing execution sheet is the same; or the medication is the same, the time is adjacent, and the preset treatment link rules are met. If only the medication is the same or only the time is adjacent, a high-weight execution attribution edge is not established separately.

[0088] The event graph is used for subsequent DEE aggregation, anchor point candidate extraction, evidence time window attribution, matching of trigger and review records, conflict confirmation, and supplementary recording and recalculation.

[0089] Step S6: DEE Construction

[0090] In the diuretic treatment event graph G, the system sorts diuretic prescription nodes, actual execution nodes, and continuous pumping status change nodes according to event time. Then, it aggregates the corresponding event nodes into diuretic treatment exposure events (DEEs) along the prescription association edges, execution attribution edges, and time sequence edges that meet preset time intervals. Nodes missing `event_time` are not included in the automatic aggregation based solely on time sequence. If a node has a strong association with an existing node (e.g., `order_id`, `administration_id`, or `pump_event_id`), it is merged into the corresponding DEE along with the associated node; otherwise, it is retained as a candidate node to be confirmed.

[0091] The system scans diuretic prescription events and actual execution events in chronological order, and aggregates events with continuous treatment relationships within a certain time range for the same patient_id and the same encounter_id into a single round of DEE.

[0092] A single DEE can include diuretic therapy events such as single intravenous administration, continuous infusion, infusion rate adjustment, pause, resumption, booster administration, combination therapy, and intravenous-to-oral conversion.

[0093] The preset maximum merging interval is denoted as Δ_merge, configured by the hospital's rule base and recorded by the parameter version number (parameter_version). If the time interval between the current diuresis-related event node and the last aggregated event node in the current DEE does not exceed Δ_merge, and there are no interruptions in the continuous treatment relationship such as stopping the prescription, missing execution, pause exceeding the preset duration, discharge, transfer to another department, different treatment links, or negative semantic hits, then it is merged into the current DEE; otherwise, a new DEE is created. For strategy conversions such as intravenous to oral, combined medication, or other strategies explicitly marked as belonging to the same treatment link by the template, stopping the original route of administration is not itself considered a treatment link interruption; it is only considered an interruption when no associated alternative or conversion execution event is detected.

[0094] Each DEE includes: a unique identifier (dee_id), start and end times, involved drugs, dose sequence, pathway sequence, strategy change node, corresponding monitoring window, and closed-loop status.

[0095] Step S7: Identification of actual execution anchor point T0 and policy change anchor point Tn

[0096] For each DEE, the system extracts candidate anchor points, including nurse scanning time, execution confirmation time, intravenous push time, infusion pump start time, pump infusion rate adjustment time, pause time, recovery time, stop time, first actual execution time after dose or route of administration change, first actual execution time of combined medication, first oral administration time after intravenous to oral conversion, doctor's order planning time, and course of treatment reference time. Among these, doctor's order planning time and course of treatment reference time are only considered as low-confidence candidates and should not be used alone to form high-confidence T0 or Tn without manual confirmation.

[0097] AnchorScore(c)=clip[0,1](0.22×S_source(c)+0.16×S_type(c)+0.18×S_order_link(c)+0.14×S_time_consistency(c)+0.1 2×S_follow_monitor(c)+0.10×S_nursing_consistency(c)+0.08×S_device_consistency(c)-0.15×P_anchor_conflict(c)).

[0098] Wherein, AnchorScore is the confidence score of the candidate anchor; c is the candidate anchor; clip[0,1] indicates that the calculation result is limited to the range of 0 to 1, with 0 for a result less than 0 and 1 for a result greater than 1; S_source represents the reliability of the source; S_type represents the reliability of the event type; S_order_link represents the association strength with the same medical order or execution order; S_time_consistency represents the consistency of the time sequence; S_follow_monitor represents the consistency of the subsequent record time chain structure; S_nursing_consistency represents the consistency of the nursing link; S_device_consistency represents the consistency of device records; P_anchor_conflict represents the penalty for conflicts between the candidate time and other sources. Each sub-item takes a value from 0 to 1, and the weight and threshold are recorded by parameter_version. The above coefficients are one example.

[0099] In one feasible assignment method, S_source is assigned a value according to the source level: 1.0 for automatic device recording or barcode scanning execution, 0.9 for nursing execution confirmation, 0.4 for medical order planning time, and 0.3 for disease treatment reference time; S_order_link is assigned 1.0 when the medical order number or execution order number is exactly the same, 0.6 when only the same medication, the same visit, and the time are adjacent, otherwise 0; S_time_consistency is assigned 1.0 when there is no conflict in the time sequence, and linearly decreases according to the proportion of delay to the threshold when there is a delay but it does not exceed the preset threshold, and is assigned 0 when it exceeds the threshold; P_anchor_conflict is normalized according to the difference between the candidate time and the time of other sources relative to the conflict threshold. S_follow_monitor can be the proportion of the number of subsequent records that meet the template time sequence to the total number of comparable subsequent records; S_nursing_consistency and S_device_consistency can be the proportions of the number of records in the nursing link or device link that are consistent with the candidate anchor point in time and association identifier to the total number of comparable records, respectively. Other items can be calculated using discrete assignment or normalization from the versioned rule table, and the specific assignment basis can be saved.

[0100] For example, a candidate anchor point might be the execution time of a nursing QR code scan directly related to a diuretic prescription. Each scoring item, according to the current parameter version, is assigned S_source=1.0, S_type=1.0, S_order_link=1.0, S_time_consistency=0.9, S_follow_monitor=0.75, S_nursing_consistency=1.0, S_device_consistency=0.8, and P_anchor_conflict=0.1. Substituting these values ​​into the above formula yields an AnchorScore of 0.925. This score is higher than the minimum anchor point confidence threshold of 0.70 specified in the current parameter version, and since this candidate belongs to the actual execution event category, it is determined as the actual execution anchor point T0 in the absence of anchor point sensitivity. The above assignment is only one example; the specific assignments and thresholds are recorded by parameter_version.

[0101] The valid candidate refers to a candidate anchor point that has a parsable candidate time, has not been withdrawn, has not hit the negation semantics, and whose AnchorScore reaches the valid threshold of the candidate anchor point; the valid threshold of the candidate anchor point is not higher than the minimum confidence threshold of the anchor point, and is recorded by parameter_version.

[0102] The system calculates a credibility score for each candidate anchor point and performs anchor point uncertainty screening. When there are two or more valid candidate anchor points, the valid candidate anchor point with the highest credibility score is determined as the primary candidate anchor point c1, and the valid candidate anchor point with the second highest credibility score is determined as the alternative candidate anchor point c2. The difference between their scores is recorded as ΔScore, where:

[0103] ΔScore=AnchorScore(c1)-AnchorScore(c2).

[0104] AnchorScore(c1) is the anchor credibility score of the highest-scoring candidate anchor, and AnchorScore(c2) is the anchor credibility score of the second-highest-scoring candidate anchor. When the highest score reaches the minimum credibility threshold and there is only one valid candidate, if the candidate is an actual execution event or a strategy change event with verifiable actual occurrence time, it is determined as T0 or Tn; if the candidate is only the time of medical order planning or the time of disease treatment reference, it enters manual confirmation and does not directly form a high-credibility T0 or Tn. When there are two or more valid candidate anchors, the valid candidate anchor with the highest and second-highest anchor credibility scores are determined as the primary candidate anchor and the alternative candidate anchor, respectively. Using the candidate time of the two as the time benchmark, the same version of the monitoring window template, evidence attribution rules, required evidence template, and review time limit rules are used to obtain the corresponding evidence attribution results, evidence gap status, and review timeout determination results. When at least one of the judgment results is inconsistent, the anchor point is set to the anchor point uncertainty state (anchor_uncertain), and a task awaiting manual confirmation is generated. When the judgment results are consistent, and the main candidate anchor point reaches the preset minimum anchor point confidence threshold, and belongs to an actual execution event, a policy change event with verifiable actual occurrence time, or has already been manually confirmed, the main candidate anchor point is determined as the actual execution anchor point T0 or the policy change anchor point Tn. Otherwise, the anchor point is set to the anchor point uncertainty state (anchor_uncertain), and a task awaiting manual confirmation is generated. When ΔScore is less than the preset anchor point sensitivity threshold δ_anchor, a "score close" flag is recorded. The "score close" flag is used to prompt manual review and is not used as a separate judgment condition for the anchor point uncertainty state. The anchor point candidate scoring, sensitivity screening, and manual confirmation branches are as follows: Figure 3 As shown.

[0105] T0 is typically the first actual execution time of this round of DEE; Tn represents subsequent strategy change events, such as dose adjustment, rate adjustment, pause, resumption, combined diuresis, and conversion from intravenous to oral administration.

[0106] If all candidate anchor points are below the minimum confidence threshold, output "anchor point uncertainty state" quality control defect, and retain the candidate anchor point list for manual confirmation.

[0107] If a candidate anchor point has a tie for the highest score, a missing key time field, or inconsistent candidate times from different sources, and calculating using these candidate times as anchor points results in changes to the window allocation of key evidence, the state of evidence gaps, or the conclusion regarding whether the review has timed out, then the anchor point is marked as `anchor_uncertain`, and a task awaiting manual confirmation is generated. The manual confirmation result is written to the anchor confirmation record (`AnchorConfirm`) object, and the window and state machine calculations are re-driven.

[0108] The system uses the candidate times of the primary candidate anchor point c1 and the alternative candidate anchor point c2 as time benchmarks, employing the same versions of monitoring window templates, evidence attribution rules, required evidence templates, and review time limit rules to obtain corresponding evidence attribution results, evidence gap status, and review timeout determination results. When at least one of the determination results is inconsistent, the corresponding monitoring window is identified as the affected window, the record where the attribution result or evidence status changes is identified as affected evidence, and a task awaiting manual confirmation is generated, containing the primary candidate anchor point, alternative candidate anchor points, scoring results, and difference information. The boundary differences between the two sets of monitoring windows are used to determine the comparison range and the affected window, and are not used as a separate criterion for determining the uncertain state of the anchor point.

[0109] The S_follow_monitor sub-item in AnchorScore, which evaluates the structural consistency between candidate anchors and subsequent recording time chains, is only used to evaluate the consistency between candidate anchors and subsequent recording time chains. It does not use cumulative urine volume data labels, urine sodium sampling data labels, input volume, output volume, weight-related data labels, or review trigger conclusions as scoring criteria. When different candidate anchors lead to changes in the evidence attribution conclusion, the system enters anchor_uncertain instead of inferring a unique anchor from subsequent conclusions.

[0110] The anchor selection process retains a list of candidate anchors, scoring items, sources of conflict, reasons for selection, and rule version numbers to support subsequent review, quality control spot checks, and algorithm reproduction.

[0111] Step S8: Dynamic monitoring window generation

[0112] The system selects the monitoring window template based on anchor point type, drug category, route of administration, whether it is continuous infusion, whether it is combined with diuresis, evidence template additional labels, and hospital rule base.

[0113] Each monitoring window is defined as:

[0114] W(e,k)=[T_e+a_k,T_e+b_k)

[0115] Where e represents the anchor event, k represents the monitoring window type, T_e is the time of the anchor event e, and a_k and b_k are the start and end offsets of the monitoring window type k relative to the anchor point, respectively.

[0116] The monitoring window may include, but is not limited to, the early window after T0, the intermediate window, the 24-hour summary window, the 24-48-hour stability window, the cumulative monitoring window after continuous infusion is started, the short-term response window after rate adjustment, and the conversion stability window after intravenous to oral administration; the specific start and end offsets are determined by the preset monitoring window template library.

[0117] For example, in a single intravenous administration template, windows for urinary sodium (0–2 h), urine output (0–6 h), total fluid intake and output (24 h), and renal function and electrolytes (0–24 h) can be configured after T0. In a continuous infusion or strategy-changing template, monitoring windows for 0–6 h and 0–24 h after rate adjustment can be configured. The above offsets are merely examples; actual offsets, permissible delays, and evidence requirements are determined by the versioned template.

[0118] The system generates a monitoring task list for each window, including the type of evidence to be retrieved, the allowed delay, the minimum credibility, the gap judgment rules, and the closure time limit.

[0119] Step S9: Multi-source evidence retrieval, evidence attribution score (AttrScore), and monitoring window attribution.

[0120] The system retrieves candidate evidence records near each dynamic monitoring window from the event graph G along the DEE attribution edge and the time sequence edge; after the candidate evidence is assigned, the corresponding time window attribution edge is established.

[0121] For urine output, priority should be given to records of catheterization measurements, urine bag change times, and nursing segment records; then shift summaries and 24-hour summaries should be used; written descriptions of the course of illness should only be used as supplementary evidence.

[0122] For urinary sodium, the specimen collection time allocation window is used first; if the sampling time is missing, low-confidence allocation is performed according to the specimen reception time, reporting time, and offset rules.

[0123] For test data such as renal function and electrolytes, sample_time is used first for window assignment; if sample_time is missing, receive_time is used for low-confidence assignment; report_time is used to determine result visibility and review time. For vital sign data, measurement_time is used first for window assignment; if measurement_time is missing, device_upload_time is used for low-confidence assignment; record_time is only used as a low-confidence auxiliary time.

[0124] For medical record review, the system uses keywords, structured tags, or natural language semantics to identify records related to intake and output, weight, urine output, post-diuretic monitoring data, renal function, electrolytes, vital signs, and follow-up plans. The identification results are only used as candidates or low-confidence clues for review records and do not directly form clinical judgments.

[0125] For each candidate piece of evidence d and the dynamic monitoring window W, the AttrScore is calculated according to the following formula:

[0126] AttrScore(d,W)=clip[0,1](0.30×A_time(d,W)+0.20×A_type(d,W)+0.18×A_source(d)+0.15×A_link( d,DEE)+0.10×A_temporal_order(d)+0.07×A_manual_confirm(d)-0.12×P_delay_or_mismatch(d,W)).

[0127] Wherein, A_time represents the degree of matching between the evidence time and the window, A_type represents the degree of matching between the evidence type and the window task, A_source represents the reliability of the evidence source, A_link represents the correlation strength between the evidence and the current DEE, A_temporal_order represents the consistency of the time order, A_manual_confirm represents the result of manual confirmation, and P_delay_or_mismatch represents the penalty for delay or mismatch; clip[0,1] indicates that the calculation result is limited to 0 to 1. Each sub-item takes a value from 0 to 1, and the weight and threshold are recorded by the parameter version number (parameter_version). The above coefficients are one example.

[0128] In one feasible assignment method, A_time is set to 1.0 when the main time of the evidence is within the window; when it is within the allowable delay interval, it decreases linearly according to the proportion of the time exceeding the window to the allowable delay; and it is set to 0 when it exceeds the allowable delay. A_type is set to 1.0 when the evidence type perfectly matches the task, 0.5 when it is compatible, and 0 when it does not match; A_link is set to 1.0 when the evidence is precisely associated with the same dee_id, order_id, or administration_id, 0.6 only when the same visit, the same medication, and the times are adjacent, otherwise it is set to 0; A_temporal_order is set to 1.0 when there is no conflict in the time order, decreases linearly according to the inversion duration when there is a tolerable time inversion, and is set to 0 when it exceeds a preset threshold; P_delay_or_mismatch is the larger of the delay normalization value and the field mismatch normalization value. A_manual_confirm is set to 0 when no manual confirmation is performed, 1.0 when confirming the main evidence, and 0.5 when confirming the auxiliary evidence. Rejected evidence is not included in the actual evidence set E_act. For example, if a urine sodium record is sampled within the 0-2 h urine sodium window after T0, and the evidence type, source, and association identifier all match the current window and DEE, then without manual confirmation and without delay penalty, substituting each item into the above formula yields an AttrScore of 0.93. When the attribution threshold is 0.60, the record is assigned to the corresponding urine sodium monitoring window. The above values ​​are only one example.

[0129] When the AttrScore reaches the preset attribution threshold, the candidate evidence is assigned to the corresponding dynamic monitoring window. If the attribution thresholds of multiple windows are met simultaneously, the evidence is assigned to the window with the highest score, while other windows are reserved as alternative windows. Unless the template explicitly allows the reuse of the same evidence, the same evidence may not simultaneously meet multiple required evidence items. When reuse is allowed, the reuse identifier and the required key that is met should be recorded in the evidence chain.

[0130] Step S10: Data Confidence Scoring and Conflict Retention Confirmation

[0131] The system first standardizes the units, cumulative intervals, and statistical calibers of evidence, and then performs numerical conflict, temporal conflict, and source conflict detection on similar evidence with comparable statistical intervals within the same window; if a conflict is detected, a conflict penalty item P_data_conflict is generated.

[0132] For each candidate piece of evidence d, calculate DataConfidence according to the following formula:

[0133] DataConfidence(d)=clip[0,1](0.24×C_source(d)+0.18×C_time_complete(d)+0.18×C_same_type_consistency(d)+0.15×C_upstream_downstre am(d)+0.10×C_unit_valid(d)+0.10×C_manual_confirm(d)+0.05×C_structured(d)-0.20×P_data_conflict(d)-0.10×P_missing_key_time(d)).

[0134] Wherein, C_source represents source reliability, C_time_complete represents the completeness of key time fields, C_same_type_consistency represents consistency of similar evidence, C_upstream_downstream represents consistency of upstream and downstream records, C_unit_valid represents unit validity, C_manual_confirm represents manual confirmation results, C_structured represents the degree of record structuring, P_data_conflict represents conflict penalty, and P_missing_key_time represents key time missing penalty; clip[0,1] indicates that the calculation result is limited to 0 to 1. Each sub-item takes a value from 0 to 1, and the weight and threshold are recorded by the parameter version number (parameter_version). The above coefficients are one example.

[0135] In one feasible assignment method, C_time_complete is calculated as the ratio of the actual number of key time fields required for this type of evidence to the number that should exist; C_unit_valid is 1.0 when the unit is identifiable and can be converted according to versioning rules, otherwise it is 0; C_structured is 1.0 for structured fields, 0.6 for semi-structured records that can be reliably parsed, and 0.3 for records with only free text; C_upstream_downstream is the proportion of the number of record pairs with consistent association identifiers and time order among comparable upstream and downstream records to the total number of comparable record pairs; P_missing_key_time is 1.0 when the main time is missing, and is determined by the missing proportion when only auxiliary time is missing.

[0136] For similar numerical evidence, the maximum standardized difference is denoted as D_max, and the conflict threshold for the corresponding evidence type is denoted as θ_conflict. The numerical conflict penalty P_value_conflict can be min(1, D_max / θ_conflict), and C_same_type_consistency = 1 - P_value_conflict. The comprehensive conflict penalty P_data_conflict can be the maximum value among P_value_conflict, time conflict penalty, and source conflict penalty. C_manual_confirm is 0 when no manual confirmation is performed, 1.0 when confirming primary evidence, and 0.5 when confirming secondary evidence. For example, if the sub-items of a structured nursing urine output record are set as follows: C_source=1.0, C_time_complete=1.0, C_same_type_consistency=0.85, C_upstream_downstream=0.84, C_unit_valid=1.0, C_manual_confirm=1.0, C_structured=1.0, P_data_conflict=0.20, P_missing_key_time=0, substituting them into the above formula yields a DataConfidence of 0.909. When the data confidence threshold is 0.60 and the corresponding conflict has been confirmed and resolved, the record is included in the actual evidence set E_act. The above values ​​are only one example.

[0137] Evidence that meets the preset credibility threshold and has no unconfirmed conflicts is included in the actual evidence set (E_act); evidence that does not meet the preset threshold or has unconfirmed conflicts is included in the low credibility actual evidence set (E_act_low).

[0138] If the numerical differences between multiple source records exceed the preset conflict threshold, or if different time assignments cause changes in the conclusions regarding evidence window assignment, gap status, or whether the review has timed out, then the system enters an "uncertain or conflicting state." The system then distinguishes between value conflict, time conflict, source conflict, or anchor uncertainty through state subtypes, generating tasks for manual confirmation or supplementary recording.

[0139] Even if the conflict is not confirmed, the system can still output a review trigger, but the evidence chain will be marked as "data credibility is insufficient" or "data conflict to be confirmed".

[0140] When a conflict is manually confirmed, the system records the confirming operator's role (confirm_operator_role), the confirmation time (confirm_time), the confirmation result (confirm_result), the confirmed primary evidence identifier (confirmed_primary_evidence_id), the reason code (reason_code), and the comment text (comment_text). The confirmation result is used as a weighting factor in the subsequent DataConfidence score.

[0141] After data is entered into the system, the system determines whether it is a new, corrected, or revoked record based on message_id, source_record_id, and last_update_time, and recalculates the affected window, gap, and state path.

[0142] Step S11: Generate labels for cumulative urine volume data, urine sodium sampling data, and input, output, and weight-related data.

[0143] Based on the aforementioned evidence attribution score and DataConfidence, forming the actual evidence set (E_act), low-confidence actual evidence set (E_act_low), and conflict markers, the system generates cumulative urine volume data labels, urine sodium sampling data labels, and input, output, and weight-related data labels, respectively. These labels only indicate the completeness, time attribution, confidence level, preset data conditions, and conflict status of the relevant data fields within a specific monitoring window; they do not indicate clinical abnormalities, efficacy conclusions, or treatment recommendations. The preset data conditions, preset data ranges, and label priorities are all configured by a versioning rule table according to evidence type and window type. When the same label object simultaneously meets multiple conditions, the primary label is output according to the aforementioned priority, while other labels are retained as auxiliary labels.

[0144] The cumulative urine volume data labels are generated based on the cumulative urine volume value, urine volume time distribution, urine volume source reliability, and time relationship with the execution anchor point, such as "reached preset data conditions, did not reach preset data conditions, exceeded preset data range, missing, conflict".

[0145] Urine sodium sampling data labels are generated based on urine sodium value, sampling time integrity, evidence attribution score, and window matching status, including labels such as "meeting preset data conditions, not meeting preset data conditions, missing, attribution uncertain, and conflict".

[0146] Input, output, and weight-related data labels are generated based on input, output, urine volume, other recorded outputs, and weight changes, such as "meeting preset data conditions, not meeting preset data conditions, exceeding preset data range, missing, and conflicting".

[0147] Step S12: Generation of required evidence set and requirement key set, and gap detection.

[0148] The system generates a set of required evidence, E_req, based on DEE type, T0 or Tn type, drug combination, evidence template appended tags, and the hospital's rule base. Each item in E_req includes a unique requirement key and its requirement attributes; the requirement key includes at least dee_id, anchor_id, window_id, evidence_type, and requirement_id, and the requirement attributes include at least allowed delay, minimum credibility, and whether reuse is allowed.

[0149] The system maps the evidence in the aforementioned actual evidence set E_act according to the requirement key E_req, and records the requirement keys that have been satisfied by highly credible evidence as the set of satisfied evidence requirement keys K_act.

[0150] The system records the demand keys in E_req as the set of required evidence demand keys K_req, and calculates Gap=K_req∖K_act (set difference) to identify closed-loop gaps such as failure to monitor, failure to review, failure to examine, and failure to record. When there are multiple candidate evidences for the same demand key, the correspondence between the main evidence and the alternative evidence is retained.

[0151] If evidence exists but its credibility is below the minimum requirement, then the evidence is added to the low-credibility actual evidence set E_act_low, and marked as "low-credibility evidence, does not meet the closed-loop requirement" in the gap results.

[0152] The generation of E_req simultaneously records template_id, rule_version, template_tag_version (the version number of the appended tag to the evidence template), and strategy_type (the applicable strategy type for the evidence template). When the rule base version is updated, the system can either retain historical quality control conclusions according to the original version or recalculate according to the new version and retain the differences before and after.

[0153] If a piece of evidence in E_req is unavailable due to the hospital system not being deployed, the interface being interrupted, or the field being missing for a long time, the system will mark the corresponding evidence requirement key as an exception that is unavailable by the system (not_available_by_system), separate it from the evidence gap set Gap and write it into the set of exceptions that are unavailable by the system E_exc, and at the same time drive the state machine to enter ST11; this mark only indicates that the data source on the system side is unavailable, and does not determine whether the corresponding monitoring has been implemented in the clinic.

[0154] Step S13: Review record identification and matching

[0155] The system retrieves review records from medical records, consultation records, nursing handover records, and discharge records, and searches for subsequent review evidence from follow-up orders, laboratory test results, and follow-up arrangements. Subsequent review evidence is used to prove that a review action or result has been performed, but it does not replace the review records in medical records, consultation records, or nursing handover records.

[0156] Review records that simultaneously meet the following time relevance and semantic relevance conditions are recorded as review evidence. In an implementable semantic matching method, the same sentence or paragraph of text simultaneously matches at least one monitored object word and at least one review action word, without matching negation or irrelevant semantics; structured fields can be directly matched according to the corresponding tags. When the record time is within the preset review time limit after triggering, it is recorded as on-time review; if it exceeds the review time limit but still meets the semantic relevance, it is recorded as overdue review evidence and the overdue_review mark is retained. The review content may involve records related to intake and output, weight, and urine output, post-diuretic monitoring data, renal function, electrolytes, and vital signs data, and data links or follow-up plans before discharge records; generalized statements such as "continue to observe" reduce the credibility of the review and do not meet the high-credibility review closed-loop condition alone.

[0157] The trigger time (trigger_time) is defined as the time when the corresponding trigger condition is first met and the necessary data is already visible: for gap-type triggers, it is the sum of the monitoring window end time and the allowed delay; for result, conflict, or attribution uncertainty-type triggers, it is the time when the trigger condition is first met, whichever is more relevant: the result reporting time, the recording time, or the conflict detection completion time. The review deadline is obtained by adding trigger_time to the versioned review time limit.

[0158] The system establishes a "trigger-review" edge between the trigger node and the review record node in the event graph G, and establishes a "trigger data-review" edge between the data node on which the trigger is based and the subsequent review evidence node.

[0159] Step S14: Closed-loop state machine determination

[0160] The system establishes independent closed-loop state machines for each DEE's T0 closed-loop object and each Tn closed-loop object, and uses state (ST) encoding to represent each closed-loop state. The initial state is ST0, where closed-loop calculation has not started. The system performs state transitions based on monitoring window opening, evidence attribution, gap detection, review trigger generation, review record matching, and subsequent review status. The meaning of each state, entry conditions, and main transition paths are shown in Table 1.

[0161] Table 1. Definition of Closed-Loop State and Main Transition Rules

[0162]

[0163] Table 1 lists the main states and transition paths of the closed-loop state machine. When in ST10, the system can generate a review trigger record, but before uncertainties or conflicts are resolved, the main state remains ST10. After manual confirmation, supplementary recording, or correction, the state transition occurs based on the recalculation results. When ST5 subsequently matches an overdue review record, it transitions to ST6, retaining the overdue_review flag. The preset closed-loop approval conditions for transitioning to ST8 include at least the absence of unprocessed general gaps, unconfirmed conflicts, and incomplete subsequent reviews.

[0164] Subsequent transfers from ST10 are differentiated according to state_subtype: when state_subtype is anchor_uncertain, after manual confirmation, supplementation, or correction, the anchor point is redefined and a dynamic monitoring window is generated. Then, based on the window progress and the status of existing evidence, it enters ST1, ST2, ST3, or ST9; when state_subtype is value_conflict, time_conflict, or source_conflict, and the corresponding conflict does not affect the anchor point, after manual confirmation, supplementation, or correction, it enters ST3, ST9, or continues to remain in ST10.

[0165] The state machine records the state path, such as ST1→ST2→ST9→ST4→ST5, which is used to indicate the data processing stage corresponding to the current quality control defect.

[0166] Each state transition generates a StateTransition record, which includes at least the unique identifier of the diuretic treatment exposure event (dee_id), the unique identifier of the anchor point (anchor_id), the state before the transition (from_state), the state after the transition (to_state), the unique identifier of the triggering rule (trigger_rule_id), the unique identifier set of evidence (evidence_ids), the state transition time (transition_time), the rule version number (rule_version), and the reason for not closing the loop (unclosed_reason).

[0167] After supplementation, correction, cancellation, manual confirmation, delayed return of inspection results, or rule version changes, the state machine allows for rollback or retransmission based on the recalculation results, and retains the historical state paths before and after the recalculation to distinguish between original defects, supplementary repairs, and state updates caused by rule version changes.

[0168] Step S15: Review trigger generation, merging, and priority sorting.

[0169] The system generates a review trigger based on data labels, conflict detection results, gap results, kidney function, electrolytes, vital signs data rules, and state machine results.

[0170] Trigger types include: trigger tags for reviewing input / output, weight, and urine output related record chains; trigger tags for post-diuresis monitoring record chains not meeting preset record review conditions; trigger tags for multiple rounds of post-diuresis monitoring record chains that are continuously not closed; trigger tags for reviewing renal function, electrolytes, and vital signs related record chains; trigger tags for reviewing input / output, weight, and renal function and electrolyte related record chains; trigger tags for monitoring links that are not closed; and trigger tags for existing data links that are not closed after intravenous to oral administration and before discharge related records.

[0171] For triggers involving the same patient, the same DEE, the same monitoring window, or highly overlapping evidence chains, the system performs clustering and merging, outputting a comprehensive review trigger. The degree of evidence chain overlap can be calculated based on the Jaccard coefficient of the evidence_ids set associated with the review trigger. When the ratio of the number of intersection elements to the number of union elements reaches a preset clustering threshold, it is determined that the evidence chain is highly overlapping.

[0172] The system assigns display priorities P1 to P6 based on the integrity of the data chain related to renal function, electrolytes, and vital signs, time sensitivity, duration of non-closed loop, additional tags added to evidence templates, evidence credibility, number of gaps, and trigger type, where P1 is the highest priority and P6 is the lowest priority. In one implementation, the above factors are normalized to 0 to 1, and a priority score (PriorityScore) is calculated according to version weights. This score is then mapped to P1 to P6 according to five grading thresholds from high to low. Within the same priority level, the system first sorts by review deadline, then by duration of non-closed loop, number of gaps, and evidence credibility. The specific thresholds and sorting weights are recorded by parameter_version.

[0173] Step S16: Chain of Evidence, Quality Control Deficiencies, and Report Output

[0174] The system outputs a patient-level evidence chain, including DEE, T0 / Tn, monitoring window, actual evidence, gap, trigger type, closed-loop status, status path, original record source, and record location.

[0175] The system outputs a doctor's review checklist, which is used for data link review before ward rounds, shift handover, and discharge-related records.

[0176] The system outputs quality control reports, including T0 identification rate, monitoring completion rate, review response rate, closed-loop rate, data conflict rate, non-closed-loop rate after timeout, and closed-loop completion rate of preset monitoring window after intravenous to oral administration.

[0177] The report metrics adopt a versioned statistical caliber. The closed-loop object refers to the independent state machine instance corresponding to the T0 closed-loop object and the Tn closed-loop object of each DEE: the T0 identifiability rate is the ratio of the number of DEEs with a high-confidence T0 to the total number of DEEs entering the calculation; the monitoring completion rate is the ratio of the number of windows that have met all the required monitoring evidence requirements to the total number of windows that have reached their deadline; the review response rate is the ratio of the number of triggers that match review records within the review time limit to the total number of triggers that have reached the review deadline; the closed-loop rate is the ratio of the number of closed-loop objects entering ST8 to the number of objects that should enter the closed-loop calculation. The ratio of the total number of objects; the data conflict rate is the ratio of the number of closed-loop objects with value_conflict, time_conflict, or source_conflict to the total number of closed-loop objects with completed evidence attribution; the timeout non-closure rate is the ratio of the number of closed-loop objects that exceeded the review deadline and did not enter ST8 to the total number of closed-loop objects that had reached the review deadline; the closed-loop completion rate of the preset monitoring window after intravenous to oral administration is the ratio of the number of closed-loop objects that entered ST8 within the preset window in the corresponding conversion event to the total number of conversion events that had reached the window deadline. Objects that entered ST11 due to system reasons or exceptions outside the rules are listed separately and are not included in the numerator and denominator of the high-confidence closed-loop rate; among them, windows that are unavailable due to system reasons are not included in the numerator and denominator of the monitoring completion rate.

[0178] All outputs are information processing results and quality control prompts generated by the computer system, for manual review by doctors, nurses, or quality control personnel.

[0179] Step S17: Rule version, manual confirmation, and incremental recalculation

[0180] The system saves rule versions, parameter versions, template versions, and evidence template tag addition versions. The version number used is recorded for each anchor point identification, window generation, evidence attribution, gap detection, and state machine transition.

[0181] When anchor points, master evidence, conflicting evidence, or gap exceptions are manually confirmed, the system writes the confirmation result as an independent event node into the event graph and establishes "anchor point - confirmation", "evidence - confirmation", "conflict - confirmation" or "gap - exception" edges respectively; when supplementary records or review records are formed, "gap - supplementary records" or "trigger - review" edges are established respectively.

[0182] When supplementary entries, corrections, withdrawals, manual confirmations, or test results are returned late, the system locates the affected objects based on the dependency indexes between node_id, dee_id, anchor_id, window_id, and requirement_id, as well as the event graph edges. It recalculates only the affected DEEs, T0 / Tn, windows, evidence attribution, gaps, and state machine paths, preserving the differences in conclusions before and after the recalculation. If a new, corrected, or withdrawn event may lead to the splitting or merging of DEEs, then adjacent DEEs within the Δ_merge range before and after that event are included in the recalculation scope.

[0183] The aforementioned recalculation mechanism is used to ensure the reproducibility and traceability of medical data in situations involving delays, supplementary entries, and conflicts between multiple systems.

[0184] This invention also provides a multi-source medical record closed-loop quality control system based on diuretic therapy event anchors, comprising:

[0185] The multi-source data access module is used to access data from HIS, EMR, nursing, LIS, infusion pumps, weight, vital signs, and quality control platforms.

[0186] The data standardization module is used to unify the identification of patients, medical orders, medications, time, units, and original records.

[0187] The event node module is used to generate standardized event nodes.

[0188] The event graph module is used to construct G=(V,E) and establish event edges such as the same medical order, execution attribution, and time window attribution.

[0189] DEE building blocks are used to identify a round of DEE and aggregate single, continuous, joint, append, and transformation events.

[0190] The anchor point identification module is used to calculate AnchorScore and determine T0 / Tn.

[0191] The dynamic monitoring window module is used to generate monitoring windows based on anchor points and event types.

[0192] The evidence attribution module is used to assign urine volume, urine sodium, fluid intake and output, weight, vital signs, laboratory test results, and medical records to the window.

[0193] The Confidence and Conflict module is used to calculate DataConfidence and identify numerical, temporal, and source conflicts.

[0194] The data tag generation module is used to generate cumulative urine volume data, urine sodium sampling data, and input, output, and weight-related data tags.

[0195] The gap detection module is used to generate E_req, E_act, and Gap.

[0196] The review and identification module is used to identify review records such as medical history, consultation, and nursing handover, as well as subsequent review evidence such as review orders and test results.

[0197] The closed-loop state machine module is used to complete the state transition from ST0 to ST11 and output the state path.

[0198] The trigger merging module is used to merge duplicate triggers and calculate priorities.

[0199] The Evidence Chain and Reports module is used to output evidence chains, quality control defects, and statistical reports.

[0200] The rule version and recalculation module is used to configure and save rule versions, parameter versions, template versions, dictionaries and thresholds, and recalculate the affected DEE, anchors, windows, gaps and status paths when there is a delay in the return of supplementary data, corrections, cancellations, manual confirmations or test results.

[0201] Example 1: Closed-loop monitoring after conventional intravenous diuresis

[0202] Patient A was prescribed furosemide 40 mg intravenously at 08:00, scheduled to be administered at 09:00; at 09:18, the nursing system recorded the administration by scanning the code and confirmed the administration; at 10:05, a urine sodium sample was collected, and at 11:20, the urine sodium result was reported; at 13:00, the cumulative urine output after T0 was recorded; and at 09:18 the next day, a 24-hour intake and output summary record was generated.

[0203] The system converts the 08:00 medical order, 09:18 actual execution, 10:05 urine sodium sampling, 13:00 urine volume record, and the next day's 09:18 intake and output into event nodes and constructs a diuretic treatment event graph. Because the 09:18 nursing code scanning execution time is directly related to the diuretic medical order and meets the preset anchor point confirmation conditions, the system determines 09:18 as the actual execution anchor point T0 for this round of DEE.

[0204] T0 generates early urinary sodium window, mid-term urine volume window, 24-hour intake and output, weight, urine volume related data window, and renal function, electrolyte, and vital signs related data window. The system assigns the 10:05 urinary sodium sampling record, the 13:00 urine volume record, and the next day's 09:18 summary intake and output record to the corresponding windows, forming the corresponding parts of the actual evidence set E_act.

[0205] Assuming that all other required evidence except for the progress review record has been met, after the monitoring window ends and the allowed delay expires, the system will switch to ST9 and generate a review trigger due to the missing progress review record; if no review record is matched by the review deadline, it will switch to ST5, output the review evidence gap and the post-diuretic monitoring data chain pending review label, and the status path is ST1→ST2→ST9→ST4→ST5.

[0206] Example 2: Continuous pumping, speed regulation, pause and resumption

[0207] Patient B received a continuous infusion of diuretics. The infusion started at 08:00, the rate was increased at 12:00, it was paused at 15:00 due to hypotension, and resumed at 18:00. The system identified 08:00 as T0, and 12:00, 15:00, and 18:00 as T1, T2, and T3, respectively.

[0208] T0 generates cumulative urine output, renal function, and electrolyte window; T1 generates a window for reviewing urine output, renal function, electrolytes, and vital signs data after speed adjustment; T2 generates a window for reviewing changes in intake, output, weight, and urine output data after pause; T3 generates a window for monitoring renal function, electrolytes, vital signs, and urine output after recovery.

[0209] If the system finds that there is no urine output attribution record 6 hours after T1, no data chain verification record related to intake / output, weight, and urine output 12 hours after T2, and electrolyte-related data that meet the preset verification conditions after T3 has not formed a course verification record, then it will output the monitoring gap after speed adjustment, the data chain verification trigger for intake / output, weight, and urine output after diuresis interruption, and the data chain verification trigger for renal function, electrolytes, and vital signs.

[0210] Example 3: Closed-loop data of renal function, electrolytes, and vital signs after combined diuresis

[0211] Patient C was given a thiazide diuretic in addition to a loop diuretic. The system identified the "combined diuresis" event in the event graph and generated a new Tn.

[0212] The system generates a set of required evidence based on the combined diuresis template: urine volume, potassium (K), sodium (Na), magnesium (Mg), creatinine (Cr), and related data on renal function, electrolytes, and vital signs during the course of the disease for verification.

[0213] The actual evidence set includes urine volume, potassium (K), sodium (Na), and chromium (Cr), but lacks Mg testing or monitoring records. Furthermore, after the K-related results are returned, there is no verification of renal function, electrolyte, and vital signs data related to the disease progression. Under the parameter configuration of this embodiment, the system displays this renal function, electrolyte, and vital signs related data chain with P1 priority and outputs a renal function, electrolyte, and vital signs related data chain verification trigger tag, with the status path being ST1→ST2→ST9→ST4→ST5.

[0214] Example 4: Reliability of Urine Sodium Sampling Time Attribution

[0215] Patient D's T0 was 09:18. The urine sodium report time was 12:30, but the sample collection time was 10:05. The system prioritized assigning the urine sodium to the 0-2 h window after T0 based on the sampling time and marked that the evidence attribution score for this urine sodium evidence had reached the preset attribution threshold.

[0216] If the sampling time of another patient is missing, and only the specimen reception time and reporting time are available, the system will assign the sample based on the specimen reception time and reporting time as low confidence. If it is impossible to determine whether the sample belongs to the 0-2 h window, the system will output an uncertain urinary sodium assignment message and will not use it as high confidence closed-loop evidence.

[0217] Example 5: Confirmation of Conflicts in Urine Volume Records

[0218] Within the same 24-hour window, the total urine output in nursing segments was 1200 mL, the total intake and output showed a urine output of 900 mL, and the progress note stated "urine output approximately 600 mL".

[0219] The system calculated the confidence levels for each of the following: segmented urine output in nursing care (0.82), total intake and output (0.70), and written medical history (0.40). Due to discrepancies exceeding the conflict threshold, the system output an ST10 status indicating uncertainty or conflict. Simultaneously, segmented urine output in nursing care was listed as primary evidence, total intake and output as secondary evidence, and the medical history description as low-confidence evidence. The primary evidence was ultimately determined by manual verification.

[0220] If the conflict affects the triggering of the post-diuretic monitoring data chain review, the triggering result will be marked as "data conflict pending confirmation", and the data conflict rate will be included in the quality control report.

[0221] Example 6: Closed-loop data link for monitoring window after intravenous to oral administration

[0222] Patient F started oral torasemide after discontinuing intravenous furosemide, with discharge planning clues. The system identified the intravenous-to-oral conversion event and generated a monitoring window of 0–24 h and a stability monitoring window of 24–48 h after the conversion.

[0223] The system reviewed urine output, weight, fluid intake and output, renal function, electrolytes, discharge records, and follow-up arrangements after the conversion. It was found that there was no weight record 24 hours after the conversion, electrolytes were not retested, and there was no description of verification of fluid intake and output, weight, or urine output data in the discharge records.

[0224] The system outputs a data link failure trigger tag before the discharge record related to intravenous to oral administration. The status path includes ST9→ST4→ST5, and the current status is ST5 review overdue and unmatched.

[0225] Example 7: Retrospective Validation

[0226] To verify the processing capabilities of this invention in identifying diuretic therapy event anchor points, generating monitoring windows, attributing evidence, detecting gaps, and tracing closed-loop paths, a retrospective verification was conducted on 50 desensitized inpatient cases containing multi-source data such as diuretic prescriptions, nursing execution, urine output, fluid intake and output, laboratory results, and medical records. A total of 128 diuretic therapy exposure events (DEEs) and 176 actual execution anchor points or strategy change anchor points were manually labeled. The traditional processing method, which uses the prescription time as the anchor point and summarizes data by calendar day, was used as a control.

[0227] The verification results show that the anchor point identification consistency rate of the present invention is 91.5%, compared to 73.3% in the control method; the monitoring window mismatch rate is 6.3%, compared to 21.9% in the control method; the consistency rate of urine volume and intake / output evidence attribution is 93.3%, compared to 78.6% in the control method; the accuracy rate of monitoring gap location is 91.2%, compared to 64.8% in the control method; and the traceability rate of unclosed-loop paths is 94.4%, compared to 54.2% in the control method. These results indicate that the present invention can improve the consistency and reproducibility of anchor point identification, evidence attribution, gap location, and closed-loop path tracing in multi-source medical records.

[0228] Among them, the anchor point identification consistency rate is the proportion of the number of anchor points identified by the system that are consistent with those manually labeled to the total number of manually labeled anchor points; the monitoring window mismatch rate is the proportion of the number of evidence that is assigned to a non-manually labeled target window to the total number of assigned evidence; the evidence attribution consistency rate is the proportion of the number of evidence whose attribution results are consistent with those manually labeled to the total number of labeled evidence; the monitoring gap location accuracy rate is the proportion of the number of gap locations in the system that are consistent with those manually confirmed to be consistent to the total number of gaps output by the system; and the unclosed path traceability rate is the proportion of the number of objects whose unclosed links can be restored from the state transition records to the total number of unclosed objects.

[0229] In its specific implementation, this application provides a computer storage medium and a corresponding data processing unit. The computer storage medium is capable of storing a computer program, which, when executed by the data processing unit, can run the invention's content and some or all of the steps in various embodiments regarding the multi-source medical record closed-loop quality control method and system based on diuretic treatment event anchors. The storage medium can be a disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0230] Those skilled in the art will clearly understand that the technical solutions in the embodiments of the present invention can be implemented using computer programs and their corresponding general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium and includes several instructions to cause a device containing a data processing unit (which may be a personal computer, server, microcontroller, MCU, or network device, etc.) to execute the methods described in various embodiments or certain parts of the embodiments of the present invention.

[0231] This invention provides a method and system for closed-loop quality control of multi-source medical records based on diuretic therapy event anchors. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A closed-loop quality control method for multi-source medical records based on diuretic therapy event anchors, characterized in that, Includes the following steps: Step 1: Collect multi-source medical records and perform standardized processing to generate standardized event nodes containing patient identifier, visit identifier, event type, event time, source system, and source record identifier. Construct a diuretic treatment event map based on the correlation between the standardized event nodes. Step 2: Associate and aggregate the diuretic prescription node, actual execution node, and continuous infusion state change node in the diuretic treatment event map to form a diuretic treatment exposure event (DEE). Step 3: Extract candidate anchor points from the actual execution events, strategy change events, medical order records, and course treatment reference records corresponding to each diuretic treatment exposure event (DEE). Calculate the anchor point credibility score and screen valid candidate anchor points. When no valid candidate anchor point exists, set the anchor point to an uncertain state. When only one valid candidate anchor point exists, if the valid candidate anchor point reaches the preset minimum anchor point credibility threshold and belongs to an actual execution event, a strategy change event with verifiable actual occurrence time, or has been manually confirmed, then determine it as an actual execution anchor point T0 or a strategy change anchor point Tn; otherwise, set the anchor point as an anchor point. Uncertain state: When there are two or more valid candidate anchor points, monitoring windows are generated based on the highest and second-highest rated valid candidate anchor points, and evidence attribution, gap detection, and review time limit determination are performed. If the results are inconsistent, the anchor point is set to an uncertain state. If the results are consistent, and the highest-rated valid candidate anchor point reaches the preset minimum confidence threshold for anchor points, and belongs to an actual execution event, a strategy change event with verifiable actual occurrence time, or has been manually confirmed, the highest-rated valid candidate anchor point is determined as the actual execution anchor point T0 or the strategy change anchor point Tn. Otherwise, the anchor point is set to an uncertain state. Step 4: Generate a dynamic monitoring window based on the actual execution anchor point T0 or the strategy change anchor point Tn, retrieve candidate evidence, and perform dynamic monitoring window attribution judgment and data credibility judgment respectively to form an actual evidence set and a low-credibility actual evidence set. Step 5: Generate a set of required evidence keys based on the diuretic treatment exposure event DEE, anchor point, dynamic monitoring window, and required evidence template; map actual evidence to the corresponding evidence requirement keys; and generate a set of evidence gaps by the set difference between the set of required evidence key and the set of evidence requirement keys that have been satisfied. Step 6: Based on the actual evidence set, low-confidence actual evidence set, evidence gap set, conflict record, review record, and subsequent review evidence, drive the closed-loop state machine and output the state path and traceable quality control evidence chain. When medical records are supplemented, corrected, withdrawn, manually confirmed, or test results are returned late, the affected objects are identified and incremental recalculated based on the dependencies between event nodes, diuretic therapy exposure events (DEE), anchor points, dynamic monitoring windows, evidence requirement keys, and state transition records.

2. The multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 1, characterized in that, The diuretic therapy event map includes standardized event nodes and event edges. The event edges include at least the following: order association edge, execution attribution edge, diuretic therapy exposure event attribution edge, time window attribution edge, anchor point-confirmation relationship edge, and trigger-review relationship edge. The diuretic prescription nodes, actual execution nodes, and continuous pumping status change nodes belonging to the same patient and the same visit are sorted according to the event time. When the event nodes have the same prescription identifier, execution identifier, or pump event identifier, or the event time interval does not exceed the preset maximum merging time interval and belongs to the same treatment chain, they are aggregated into the same diuretic treatment exposure event (DEE). Event nodes that are missing event times and do not have the same identifier are retained as candidate nodes to be confirmed.

3. The multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 1, characterized in that, When there are two or more valid candidate anchor points, the valid candidate anchor points with the highest and second highest anchor point credibility scores are determined as the main candidate anchor point and the alternative candidate anchor point, respectively. The candidate time of the two is used as the time benchmark, and the same version of the monitoring window template, evidence attribution rules, required evidence template and review time limit rules are used to obtain the corresponding evidence attribution results, evidence gap status and review timeout judgment results. When at least one of the determination results is inconsistent, the anchor point is set to an uncertain state and a task awaiting manual confirmation is generated; when the determination results are consistent, and the main candidate anchor point reaches the preset minimum confidence threshold for anchor points, and belongs to an actual execution event, a strategy change event with verifiable actual occurrence time, or has been manually confirmed, the main candidate anchor point is determined as the actual execution anchor point T0 or the strategy change anchor point Tn. Among them, the time of medical order planning or the time of disease course treatment reference that has not been manually confirmed are not separately determined as the actual execution anchor point T0 or the strategy change anchor point Tn.

4. The multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 3, characterized in that, The anchor point credibility score is calculated according to the following formula: AnchorScore(c)=clip[0,1](0.22×S_source(c)+0.16×S_type(c)+0.18×S_order_link(c)+0.14×S_time_consistency(c)+0.1 2×S_follow_monitor(c)+0.10×S_nursing_consistency(c)+0.08×S_device_consistency(c)-0.15×P_anchor_conflict(c)); Wherein, AnchorScore(c) represents the anchor credibility score of candidate anchor c; clip[0,1] indicates that the calculation result is limited to the range of 0 to 1; S_source represents the source reliability; S_type represents the event type reliability; S_order_link represents the association strength with the medical order or execution order; S_time_consistency represents the time sequence consistency; S_follow_monitor represents the consistency of the subsequent monitoring record time chain structure; S_nursing_consistency represents the nursing link consistency; S_device_consistency represents the device record consistency; P_anchor_conflict represents the candidate time conflict penalty item.

5. The multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 1, characterized in that, Based on anchor point type, diuretic type, route of administration, continuous infusion status, combined diuresis status, and diuretic treatment strategy, select a monitoring window template from the versioned monitoring window template library; The dynamic monitoring window is represented as follows: W(e,k)=[T_e+a_k, T_e+b_k); Where W(e, k) represents the k-th type of dynamic monitoring window corresponding to anchor event e, T_e represents the anchor event time, and a_k and b_k represent the starting offset and ending offset, respectively; the monitoring window template includes allowed delay, type of evidence to be retrieved, minimum confidence level, gap judgment rule and closed loop time limit.

6. The multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 5, characterized in that, The evidence attribution score between candidate evidence d and the dynamic monitoring window W is calculated using the following formula: AttrScore(d, W)=clip[0,1](0.30×A_time(d, W)+0.20×A_type(d, W)+0.18×A_source(d)+0.15×A_link( d, DEE) + 0.10 × A_temporal_order (d) + 0.07 × A_manual_confirm (d) - 0.12 × P_delay_or_mismatch (d, W)); Wherein, A_time represents the degree of matching between the evidence time and the dynamic monitoring window; A_type represents the degree of matching between the evidence type and the window task; A_source represents the reliability of the evidence source; A_link represents the strength of the association between the evidence and the diuretic therapy exposure event (DEE); A_temporal_order represents the consistency of the time sequence; A_manual_confirm represents the result of manual confirmation; and P_delay_or_mismatch represents the penalty for delay or mismatch. When the evidence for the same candidate reaches the preset attribution threshold for evidence attribution in multiple dynamic monitoring windows, it is assigned to the dynamic monitoring window with the highest score, and the other dynamic monitoring windows are recorded as candidate windows.

7. The multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 6, characterized in that, The data credibility score of candidate evidence d is calculated using the following formula: DataConfidence(d)=clip[0,1](0.24×C_source(d)+0.18×C_time_complete(d)+0.18×C_same_type_consistency(d)+0.15×C_upstream_downstre am(d)+0.10×C_unit_valid(d)+0.10×C_manual_confirm(d)+0.05×C_structured(d)-0.20×P_data_conflict(d)-0.10×P_missing_key_time(d)); Wherein, C_source represents source reliability; C_time_complete represents the completeness of key time fields; C_same_type_consistency represents the consistency of similar evidence; C_upstream_downstream represents the consistency of upstream and downstream records; C_unit_valid represents unit validity; C_manual_confirm represents the result of manual confirmation; C_structured represents the degree of record structuring; P_data_conflict represents the data conflict penalty; and P_missing_key_time represents the key time missing penalty. Candidate evidence whose data credibility score reaches the preset credibility threshold and has no unconfirmed conflicts is written into the actual evidence set, and other candidate evidence is written into the low credibility actual evidence set; when a conflict affects the judgment result of window attribution, gap status or review timeout, a task to be manually confirmed or a data supplement task is generated.

8. The multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 7, characterized in that, The evidence requirement key should include at least the diuretic treatment exposure event identifier, anchor point identifier, dynamic monitoring window identifier, evidence type, and requirement identifier; The required evidence keys are used to form a set of required evidence keys K_req, and the evidence keys that have been satisfied by actual evidence are used to form a set of satisfied evidence keys K_act. The evidence gap set Gap is then generated according to the following formula: Gap = K_req∖K_act; When evidence exists but the data credibility is lower than the preset requirement, a low credibility evidence marker is recorded in the evidence gap set; when evidence cannot be obtained because the data source system is not deployed, the interface is interrupted, or the key fields are unavailable, the corresponding evidence requirement key is separated from the evidence gap set and written into the system unavailable exception set.

9. A multi-source medical record closed-loop quality control method based on diuretic therapy event anchor points according to claim 8, characterized in that, Independent closed-loop state machines are established for the actual execution anchor point T0 and the anchor points Tn of each strategy change. State transitions are performed based on the dynamic monitoring window state, actual evidence, low-confidence actual evidence, evidence gaps, exceptions that are not available to the system, conflict records, review records, and subsequent review evidence. The state before the state transition, the state after the state transition, the triggering rule, the associated evidence, the transition time, the rule version, and the reason for not closing the loop are saved. When medical records are supplemented, corrected, withdrawn, manually confirmed, or test results are returned late, based on the affected object index, only the affected diuretic treatment exposure event DEE, anchor point, dynamic monitoring window, evidence attribution result, evidence gap set, and state path are recalculated, and the state path and quality control conclusions before and after recalculation are retained.

10. A multi-source medical record closed-loop quality control system based on diuretic therapy event anchors, used to implement the method described in any one of claims 1-9, characterized in that, include: The multi-source medical record processing module is used to collect multi-source medical records, generate standardized event nodes, and construct a diuretic treatment event map; The diuretic therapy exposure event aggregation module is used to associate and aggregate diuretic prescription nodes, actual execution nodes, and continuous infusion status change nodes to form a diuretic therapy exposure event (DEE). The anchor point processing module is used to extract candidate anchor points, calculate anchor point credibility scores, and filter valid candidate anchor points. When no valid candidate anchor point exists, the anchor point is set to an uncertain state. When only one valid candidate anchor point exists, the actual execution anchor point T0, the strategy change anchor point Tn, or the uncertain state is determined based on whether the valid candidate anchor point reaches the preset minimum credibility threshold and whether it belongs to an actual execution event, a strategy change event with verifiable actual occurrence time, or has been manually confirmed. When two or more valid candidate anchor points exist, the one with the highest and second-highest scores is selected. Anchor points serve as time benchmarks. Monitoring windows are generated according to the same rules, and evidence attribution, gap detection, and review time limit determination are performed. When at least one of the two sets of determination results is inconsistent, the anchor point is set to an uncertain state. When the two sets of determination results are consistent, and the highest-scoring valid candidate anchor point reaches the preset minimum confidence threshold for anchor points, and belongs to an actual execution event, a strategy change event with verifiable actual occurrence time, or has been manually confirmed, the highest-scoring valid candidate anchor point is determined as the actual execution anchor point T0 or the strategy change anchor point Tn. Otherwise, the anchor point is set to an uncertain state. The dynamic monitoring window and evidence processing module is used to generate a dynamic monitoring window based on anchor points, perform window attribution judgment and data credibility judgment on candidate evidence, and form a set of actual evidence and a set of low-credibility actual evidence. The gap detection module is used to generate the set of required evidence keys and the set of satisfied evidence keys, generate the set of evidence gaps by the difference between the sets, and identify exceptions that the system cannot obtain. The closed-loop state control module is used to drive the closed-loop state machine based on evidence, gaps, conflicts, review records and subsequent review evidence, and output the state path and traceable quality control evidence chain. The incremental recalculation module is used to identify the affected objects and perform incremental recalculation on the affected objects when medical records are supplemented, corrected, withdrawn, manually confirmed, or test results are delayed.

Images