A method and system for pre-submission isolation verification and self-correction of large model generated medical order data

Abstract

The application discloses a large model generates a pre-submission isolation verification and self-correction method and system of medical order data. The database agent intercepts the candidate medical order write request before it is sent to the backend database, and temporarily stores the write intention load without starting the backend physical transaction. The candidate medical order data is structurally analyzed, and deterministic assertion verification is performed according to the session-bound rule library version. When the verification fails, it belongs to the correctable type, and the iteration upper limit is not reached, the correction task is generated according to the violation rule metadata, the large model generates the revised data and re-verifies. After the verification is passed, the first independent physical transaction is written into the signed table, and the second independent physical transaction is written into the core medical order table after receiving the electronic signature of the doctor; when the iteration upper limit, the analysis failure upper limit or the uncorrectable verification result is reached, the writing is refused. The application reduces the transaction and lock occupation during reasoning verification, and prevents unverified or unsigned data from entering the core medical order table.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence-generated data processing, medical information system data security, database protocol proxy and database transaction control technology, specifically to a method and system for pre-submitting and isolating candidate medical order data generated by a large model, performing deterministic rule verification, feedback self-correction and phased database write control. Background Technology

[0002] With the application of large language models in hospital information systems and clinical decision support systems, these models can generate candidate medical order data based on patient basic information, allergy history, concomitant medications, and existing medical orders. Before entering the core medical order table of the hospital information system, this candidate medical order data needs to be converted into structured data and undergo validation according to rules such as dosage, frequency, route of administration, contraindications, and drug interactions.

[0003] Current large model output validation typically involves checking the generated text or displaying warning messages to the user at the application layer, but this may not necessarily be linked to the backend database write process. If backend physical transactions are started prematurely during large model generation or validation, database connection and lock resources may be occupied for an extended period. If only frontend prompts are used without mandatory interception before database writes, unvalidated candidate medical order data may still enter the backend write process.

[0004] When existing rule review systems detect dosage violations, drug contraindications, or missing fields, they typically output warnings or rejections. They may not be able to convert specific violation rules, violation fields, rule limits, and candidate values ​​into structured correction tasks that can be processed by large models. Therefore, manual re-editing of candidate medical orders is still required.

[0005] When multiple candidate medical order requests enter the system at the same time, if the correction task and the newly generated task use the same scheduling priority, requests that are already in the database write pending state may wait for a long time. In addition, if the rule base is updated during multiple rounds of correction, different rule versions may be used in different rounds, which may lead to inconsistencies in the verification conditions of the same candidate medical order data.

[0006] Therefore, there is a need for a method and system that can isolate candidate medical order writing intents before the backend physical transaction starts, perform structured parsing and deterministic rule verification in the isolated state, convert the metadata of the violation rules into high-priority correction tasks, and write them into the database in stages after the verification is passed and the physician signs them.

[0007] (I) Technical problems to be solved The technical problems to be solved by this invention are as follows: (1) Solve the problem of writing intent isolation of candidate medical order data before entering the backend database, so that backend physical transactions are not started during the large model inference and rule verification, and database locks and long-term active connections are not occupied; (2) Solve the problem of data conversion between natural language candidate medical order data and deterministic medical rules, and map drug name, dosage, unit, frequency, route of administration and patient constraints into a structured candidate feature set that can be deterministically verified; (3) Solve the problem of the disconnect between rule verification results and large model revision process, convert the metadata of illegal rules into structured correction tasks, and achieve bounded iterative self-correction through high-priority scheduling; (4) Solve the problem of state consistency between candidate medical order data verification, physician signature and core database writing, and complete the writing of data to be signed and the writing of core medical order data through two independent physical transactions respectively.

[0008] (II) Technical Solution To solve the above-mentioned technical problems, this invention provides a pre-commit isolation verification and self-correction method for large-scale model-generated medical order data, comprising the following steps: Step S1: Receiving a candidate medical order write request issued by an upstream medical order application. The candidate medical order write request includes candidate medical order data generated by a large model and patient constraint data associated with the candidate medical order data. The candidate medical order data includes at least one or more of the following: drug name, dosage value, dosage unit, administration frequency, and administration route; the patient constraint data includes at least one or more of the following: age, weight, allergy history, liver and kidney function information, and concomitant medication information. Step S2: The database agent intercepts the candidate medical order write request before it is sent to the backend database, parses and extracts the write intent payload, establishes a session control block associated with the candidate medical order write request; without sending a transaction start instruction and a data write instruction to the backend database, the write intent payload is temporarily stored in a temporary write buffer isolated from the core medical order table, and the candidate medical order write request is set to a pre-commit pending state. Step S3 involves performing structured parsing and data reduction on the candidate medical order data in the written intent payload to form a structured candidate feature set. The structured parsing and data reduction include at least: mapping drug names to standard drug codes; extracting dosage values ​​and units; converting mass units to standard units; converting volumetric doses to mass doses when drug concentration can be uniquely determined; extracting fields for dosing frequency, route of administration, combined medication information, and patient constraints; and performing completeness, uniqueness, and consistency checks on key clinical fields. When key clinical fields are missing, multiple candidate results exist, they conflict with each other, or deterministic unit conversion cannot be completed, default values ​​are not used to directly complete the key clinical fields; instead, a format correction task is generated. When the structured parsing fails, the number of structured parsing failures is incremented. If the incremented number of structured parsing failures does not reach the preset parsing failure limit, a format correction task is generated based on the parsing failure fields, parsing failure reasons, candidate values, and target output data structure. The format correction task is sent to the large model inference module. The revised candidate medical order data returned by the large model inference module is received, and the write intent payload in the temporary write buffer is updated using the revised candidate medical order data. Step S3 is then returned. When the incremented number of structured parsing failures reaches or exceeds the preset parsing failure limit, step S7 is executed. In step S4, based on the rule base version bound to the session control block, rule items applicable to the structured candidate feature set are selected from the structured medical rule base, and deterministic assertion verification is performed to generate a verification result. The verification result includes at least: whether it passes, the triggered rule identifier, the violation field, the rule limit value, the candidate value, and the violation type.Step S5: When the verification result is "failed," the violation type belongs to a preset correctable violation type, and the current iteration count has not reached the preset iteration limit, a structured correction task is generated based on the verification result and the current candidate medical order data. The structured correction task includes at least a session identifier, rule base version, current candidate medical order data, triggered rule identifier, violation field, rule limit value, candidate value, violation type, set of allowed modified fields, set of prohibited modified fields, and target output data structure. The structured correction task is sent to the large model inference module with a scheduling priority higher than that of ordinary inference tasks; the revised candidate medical order data generated by the large model inference module is received, the write intent payload in the temporary write buffer is updated using the revised candidate medical order data, the current iteration count is incremented, and the process returns to step S3 to re-execute the structured parsing and deterministic assertion verification. Step S6: When the verification result is "passed," the database write request is reconstructed based on the verified write intent payload in the temporary write buffer, and the verified candidate medical order data is written to the pending signature table through the first independent physical transaction. After the first independent physical transaction is submitted, the pre-submission pending state of the candidate medical order write request ends, and the database connection and lock resources occupied by the first independent physical transaction are released. After receiving the physician electronic signature signal corresponding to the candidate medical order data, the corresponding medical order data in the to-be-signed table is written to the core medical order table through the second independent physical transaction. Step S7: When the number of structured parsing failures reaches or exceeds the preset parsing failure limit, or the current iteration count reaches the preset iteration limit and still fails to pass the verification, or the verification result belongs to the rule missing type, rule conflict type, or other preset uncorrectable violation type, the session control block is set to the failure state, the candidate medical order data is refused to be written to the to-be-signed table and the core medical order table, and the pre-submission pending state of the candidate medical order write request ends.

[0009] This invention also provides a pre-submission isolation verification and self-correction system for generating medical order data using a large model, including a database proxy module, a structured parsing module, a rule base management module, a rule verification module, a correction task generation module, a correction scheduling module, a large model inference module, a transaction writing module, and a failure control module.The database proxy module is used to intercept the candidate medical order write request before it is sent to the backend database, before the request containing candidate medical order data generated by the large model is sent to the backend database. It then parses and extracts the write intent payload, establishes a session control block associated with the candidate medical order write request, and temporarily stores the write intent payload in a temporary write buffer without sending transaction start instructions and data write instructions to the backend database. The module also sets the candidate medical order write request to a pre-commit pending state. The structured parsing module is used to parse the candidate medical order data into a structured candidate feature set containing drug codes, dosage values, dosage units, dosing frequency, route of administration, combined medication information, and patient constraint fields. The rule base management module is used to store and manage the structured medical rule base and the corresponding rule base version. The rule verification module is used to select rule items applicable to the structured candidate feature set from the structured medical rule base according to the rule base version associated with the session control block, perform deterministic assertion verification on the structured candidate feature set, and generate a verification result including at least whether it passes, violation type, triggered rule identifier, violation field, rule limit value, and candidate value. The correction task generation module is used to generate a structured correction task according to the verification result when the verification result is a failure and the violation type in the verification result belongs to a preset correctable violation type. A partial scheduling module is used to send the structured correction task to the large model inference module with a higher scheduling priority than ordinary inference tasks; the large model inference module is used to generate revised candidate medical order data based on the structured correction task; the database proxy module is also used to update the write intent payload in the temporary write buffer using the revised candidate medical order data to re-perform structured parsing and deterministic assertion verification; the transaction writing module is used to write the verified candidate medical order data into the pending signature table through a first independent physical transaction after the verification passes, and write the corresponding medical order data into the core medical order table through a second independent physical transaction after receiving the physician electronic signature signal corresponding to the candidate medical order data; the failure The control module is configured to set the session control block to a failed state, terminate the pre-submission pending state, and refuse to write the candidate medical order data into the pending signature table and the core medical order table when, before the first independent physical transaction is initiated, the number of iterations reaches a preset iteration limit and the verification fails, the number of structured parsing failures reaches a preset parsing failure limit, the violation type in the verification result belongs to a preset uncorrectable violation type, or the processing time exceeds a preset processing time limit. The failure control module is also configured to retain the corresponding pending signature record, set the session control block to a failed state, and prohibit the candidate medical order data in the pending signature record from being written into the core medical order table when the candidate medical order data has been written into the pending signature table and the preset signature waiting time limit has been exceeded.

[0010] (III) Beneficial Effects Compared with the prior art, the present invention has at least the following technical effects: (1) By intercepting the candidate medical order write request before the backend database physical transaction starts, the backend physical transaction and its database lock resources are not occupied during the large model inference and rule verification, thus reducing the pressure of database connection and lock waiting caused by long-term inference. (2) By converting candidate medical order data into a structured candidate feature set and performing deterministic assertion verification according to the rule base version, the verification process and its rule source can be recorded and reproduced; (3) By converting the metadata of the violation rules into structured correction tasks and prioritizing the scheduling of correction tasks in the pending state, the waiting time caused by the competition between correction tasks and new tasks is reduced. (4) By setting an iteration limit and a parsing failure limit, the self-correction process can be terminated under preset conditions, and the candidate medical order data will be rejected when it fails; (5) The writing of data to be signed and the writing of core medical order data after physician signature are completed by the first physical transaction and the second physical transaction, which are independent of each other, to avoid maintaining the database physical transaction for a long time while waiting for physician signature. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the overall architecture and module relationships of the pre-submission isolation verification and self-correction system for generating medical order data from a large model in this embodiment of the invention; Figure 2 This is a schematic diagram of the pre-submission isolation verification and self-correction method for generating medical order data using a large model in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the double-buffer hot update of the structured medical rule base and the binding of session rule versions in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the pre-submission pending state of the candidate medical order writing request and the timing of the two-stage independent physical transaction writing in an embodiment of the present invention. Summary of the Invention

[0012] The specific implementation methods are described in detail below with reference to specific data flow control processes and engineering implementation schemes. In one specific implementation, TensorRT-LLM, RocksDB, Caffeine Cache, and JavaNetty can be used, but the implementation is not limited to the above.

[0013] I. System Deployment Architecture and Software Architecture (Please refer to [link / reference]) Figure 1 , Figure 1This paper illustrates the overall architecture and functional module relationships of a pre-submission isolation verification and self-correction system for generating medical order data using a large model, as described in an embodiment of the present invention. The system interacts with an upstream medical order application 100, a backend database 200, and a physician terminal 300. Internally, the system includes an access and database proxy layer L1, an isolation verification and control layer L2, an inference and scheduling layer L3, and a rule and audit persistence layer L4. The upstream medical order application 100 acquires patient-related data, calls the large model to generate candidate medical order data, and forms a candidate medical order write request based on the candidate medical order data. The backend database 200 includes at least a pending signature table 210 and a core medical order table 220; the pending signature table 210 stores candidate medical order data that has passed deterministic assertion verification but has not yet been electronically signed by the physician, while the core medical order table 220 stores medical order data that has passed deterministic assertion verification and has been electronically signed by the physician. The physician terminal 300 displays the pending signature medical order data, receives physician review operations, and generates a physician electronic signature signal. The system can be deployed in a distributed manner, consisting of a security gateway, inference nodes, and backend database nodes. Alternatively, depending on the system's processing capacity and the hospital's information technology deployment conditions, the logical layers can be deployed on the same computing node or different computing nodes.

[0014] like Figure 1As shown, the four-layer logical software architecture includes an access and database proxy layer L1, an isolation verification and control layer L2, an inference and scheduling layer L3, and a rules and audit persistence layer L4. The four-layer logical software architecture is used to logically divide the system functional modules, without limiting each functional module to be deployed on four independent physical devices. (1) The access and database proxy layer L1 includes a database proxy module 11 and a transaction writing module 13; the database proxy module is used to receive candidate medical order writing requests issued by the upstream medical order application, parse and intercept the candidate medical order writing requests before the candidate medical order writing requests are sent to the backend database, extract the writing intent payload, establish a corresponding session control block, temporarily store the writing intent payload in a temporary write buffer, and maintain the pre-submission pending state of the candidate medical order writing requests. During the pre-submission pending state, the database proxy module does not send the transaction start instruction and data write instruction corresponding to the candidate medical order writing request to the backend database. The transaction writing module is used to write the verified candidate medical order data into the pending signature table through the first independent physical transaction after the candidate medical order data passes the deterministic assertion verification; after receiving the physician's electronic signature signal, it writes the corresponding medical order data into the core medical order table through the second independent physical transaction. (2) The isolation verification and control layer L2 includes a structured parsing module 21, a rule verification module 22, a correction task generation module 23, and a failure control module 24; the structured parsing module is used to perform drug entity standardization, dose value and dose unit specification, drug administration frequency and route of administration extraction, combined drug information extraction, and patient constraint field extraction on the candidate medical order data to form a structured candidate feature set.The rule validation module is used to select rule items applicable to the structured candidate feature set from the structured medical rule base according to the rule base version associated with the session control block, perform deterministic assertion validation on the structured candidate feature set, and generate a validation result including at least whether it passes, violation type, triggered rule identifier, violation field, rule limit value, and candidate value; the correction task generation module is used to generate a structured correction task according to the validation result when the validation result is a failure and the violation type in the validation result belongs to a preset correctable violation type; the failure control module is used to iterate before the first independent physical transaction starts. If the verification fails after reaching the preset iteration limit, the structured parsing failure count reaches the preset parsing failure limit, the violation type in the verification result belongs to the preset uncorrectable violation type, or the processing time exceeds the preset processing time limit, the session control block is set to a failure state, the pre-submission pending state is ended, and the candidate medical order data is refused to be written into the pending signature table and the core medical order table; the failure control module is also used to retain the corresponding pending signature record when the candidate medical order data has been written into the pending signature table and the preset signature waiting time limit has been exceeded, set the session control block to a failure state, and prohibit the candidate medical order data in the pending signature record from being written into the core medical order table. (3) The reasoning and scheduling layer L3 includes a correction scheduling module 33 and a large model reasoning module 34; the correction scheduling module is used to manage the scheduling order of ordinary reasoning tasks and structured correction tasks; when there is a structured correction task, the structured correction task is sent to the large model reasoning module first. The large model reasoning module is used to generate candidate medical order data according to the initial generation task, or to generate revised candidate medical order data according to the structured correction task. After the large model inference module returns the revised candidate medical order data, the structured parsing module performs output structure verification and field difference verification on the revised candidate medical order data. After the verification is passed, the database proxy module updates only the changed fields in the allowed modified field set to the current write intention payload in the temporary write buffer according to the controlled merging result, and the isolation verification and control layer L2 re-executes the structured parsing and deterministic assertion verification. The initial candidate medical order data can be generated by the upstream medical order application calling the large model outside the system, or it can be generated by the large model inference module inside this system according to the initial generation task. Regardless of which one generates the initial candidate medical order data, the pre-submission isolation verification and self-correction process described in this invention starts when the candidate medical order write request containing the candidate medical order data enters the database proxy module. (4) The rule and audit persistence layer L4 includes a rule base management module 41 and an audit module 42. The rule base management module is used to store and manage the structured medical rule base, rule base version, rule source, rule effective time and rule activation status, and completes the rule base version switching through a double buffer hot update mechanism.The audit module records session identifier, request identifier, model version, rule base version, summary values ​​of candidate medical order data in each round, verification results in each round, triggered rule identifier, iteration count, first independent physical transaction processing result, physician electronic signature status, second independent physical transaction processing result, final write status, record identifier to be signed, and timestamps corresponding to each processing status. The access and database proxy layer L1, isolation verification and control layer L2, inference and scheduling layer L3, and rule and audit persistence layer L4 transmit structured data through a standardized communication interface. In one specific implementation, the layers can communicate using remote procedure call interfaces, asynchronous message queues, and serialized message formats; however, this invention does not limit the specific communication protocol, message queue, serialization method, large model inference framework, caching component, or rule base storage component.

[0015] II. For pre-submitting isolation status and session control, please refer to [link / reference]. Figure 2 Upon receiving a candidate medical order write request from the upstream medical order application, the database proxy module intercepts the request before it is sent to the backend database. The candidate medical order write request includes a request identifier and candidate medical order data generated by a large model. This data includes at least one or more of the following: drug name, dosage value, dosage unit, dosing frequency, and route of administration. The database proxy module parses the candidate medical order write request, extracts the write intent payload intended for writing to the backend database, and establishes a corresponding session control block based on the request identifier.

[0016] After establishing the session control block, the database proxy module does not send transaction start instructions, data write instructions, or transaction commit instructions to the backend database. Instead, it temporarily stores the write intent payload in a temporary write buffer and sets the candidate medical order write request to a pre-commit pending state. The pre-commit pending state is a logical processing state maintained by the database proxy module. During the pre-commit pending state, there is no physical transaction corresponding to the candidate medical order write request in the backend database, and therefore no database row lock, table lock, or persistently occupied backend database physical connection corresponding to the request is generated. Therefore, in this embodiment, "pre-commit pending" does not suspend the already started backend database physical transaction, but rather postpones sending the candidate medical order write request to the backend database before the backend database physical transaction starts. In one embodiment, the database proxy module is configured with a protocol adapter that matches the target database communication protocol. The protocol adapter is used to identify database write instructions or pre-compiled statement execution instructions, and extracts the target database identifier, target data table identifier, operation type, field-value mapping, SQL template or pre-compiled statement identifier, binding parameters, transaction mode, request identifier, and write intent payload digest value from the instructions to form the write intent payload. The database proxy module maintains client connections using an event-driven, non-blocking communication mechanism. For clients using synchronous response, the database proxy module associates the client connection identifier with the session control block and pauses the generation of the final database write response during the pre-commit pending period. For clients using asynchronous response, the database proxy module generates an asynchronous response identifier associated with the session control block and returns a pending status to the client. Neither synchronous nor asynchronous response methods require occupying a backend database physical connection during the pre-commit pending period. After the first independent physical transaction is committed, the database proxy module returns a pending signature status response based on the client connection identifier or the asynchronous response identifier. In auto-commit mode, the database proxy module intercepts the write instruction before allocating a backend database physical connection for the candidate medical order write request. In explicit transaction mode, the database proxy module maintains the logical transaction state associated with the client session and does not send the transaction start instruction, write instruction, and transaction commit instruction corresponding to the candidate medical order write request to the backend database before the candidate medical order data passes the deterministic assertion verification. Explicit transaction mode is suitable for scenarios where the candidate medical order write request is in an independent transaction. When the same client transaction includes other write instructions that have an atomic dependency on the candidate medical order write, the database proxy module will form a set of pending write instructions together and reconstruct them after all relevant data has been verified. When the transaction dependency between the relevant instructions cannot be determined, the current pre-commit processing will be rejected and the upstream medical order application will be required to split the candidate medical order write into an independent transaction.Once the candidate medical order data passes the deterministic assertion verification, the database proxy module reconstructs the parameterized database write request based on the SQL template or pre-compiled statement identifier, binding parameters, and verified field-value mapping, and starts the first independent physical transaction through the newly acquired backend database physical connection.

[0017] The session control block includes at least: a session identifier, used to uniquely identify the current candidate medical order processing session; a request identifier, used to identify the candidate medical order write request; a write intent payload, used to store candidate medical order data currently awaiting verification or correction; patient constraint data, used to store one or more of the following associated with the current candidate medical order: age, weight, allergy history, liver and kidney function information, and concomitant medication information; a rule base version, used to identify the version of the structured medical rule base used in the current session; a model version, used to identify the version of the large model called in the current session; an iteration count value, used to record the number of self-corrections that have been performed; a parsing failure count value, used to record the number of times the candidate medical order data failed to pass structured parsing; a session state, used to record the processing stage of the current candidate medical order write request; a write intent payload summary value; a client connection identifier or asynchronous response identifier; a record to be signed identifier; a final write state; a quality unit mapping table version; and a session deadline, used to determine whether the current processing has exceeded the preset processing time limit.

[0018] The session states include at least the following: PENDING, indicating that the candidate medical order write request has been intercepted by the database proxy module and structured parsing has not yet begun; PARSING, indicating that structured parsing is being performed on the candidate medical order data; VALIDATING, indicating that deterministic assertion verification is being performed on the structured candidate feature set; CORRECTING, indicating that the verification failed and the system is waiting for the large model to return revised candidate medical order data; WAITING_SIGNATURE, indicating that the candidate medical order data has passed verification and been written to the pending signature table, and is waiting for the physician's electronic signature; COMMITTED, indicating that the physician has completed the electronic signature and the corresponding medical order data has been written to the core medical order table; FAILED, indicating that the current candidate medical order processing has not been successfully completed. If the failure occurs before the first independent physical transaction starts, the candidate medical order data must not be written to the pending signature table or the core medical order table; if the failure occurs after the pending signature table is written, the corresponding pending signature record is retained, but it must not be written to the core medical order table.

[0019] For duplicate candidate medical order write requests with the same request identifier and the same write intent payload digest value, the database proxy module checks if a corresponding session control block already exists. If an unprocessed session control block exists, it is reused, and a new processing session is not established; if a completed result already exists, the recorded result is returned, thus preventing the same candidate medical order data from being repeatedly written to the pending signature table or the core medical order table. When the request identifier is the same but the write intent payload digest value is different, the database proxy module determines it as a request identifier conflict, refuses to reuse the original session control block, and records the conflict audit information. The candidate medical order data is normalized and serialized according to the field order specified in the target output data structure, and a preset hash algorithm is used to calculate the digest value of the candidate medical order data, while recording the digest algorithm identifier.

[0020] III. Structured Parsing of Candidate Medical Order Data After the session control block is established, the control unit sets the state of the session control block to PARSING and calls the structured parsing module to parse the candidate medical order data in the temporary write buffer. The structured parsing module converts the candidate medical order data in natural language or semi-structured form into a structured candidate feature set. The structured candidate feature set includes at least: drug standard code, dosage form, route of administration, single dose value, single dose unit, total daily dose, frequency of administration, course of treatment, set of standard codes for combined medications, set of standard codes for allergic drugs, patient constraints, and the rule base version bound to the current session.

[0021] Drug entity standardization includes: extracting drug names from candidate medical order data and querying the corresponding standard drug codes according to a pre-defined standard drug dictionary. When a drug name uniquely corresponds to a standard drug code, the standard drug code is written into a structured candidate feature set. When a drug name corresponds to multiple standard drug codes, the structured parsing module does not directly select the standard drug code with the highest fuzzy matching score, but instead writes multiple candidate codes and their differences into a format correction task. When a drug name cannot correspond to a standard drug code, the current structured parsing is marked as a failure, and the process enters the format correction process.

[0022] Dosage specification involves extracting the original dose value and the original dose unit, and processing them according to the physical quantity category to which the dose unit belongs. When the dose unit is a mass unit, the dose is converted to a preset standard mass unit according to the versioned mass unit mapping table using the following formula: In the formula, D std For standard mass dosage, D raw This is the original dose value; U raw S is the original unit of mass. mass (U) rawThe conversion ratio from the original mass unit to the standard mass unit is given; when mg is the standard unit: The versioned quality unit mapping table includes at least the mapping table version, original quality unit, standard quality unit, conversion ratio, effective time, and applicable scope. When a session control block is established, the currently used quality unit mapping table version is recorded. All structured parsing and correction iterations corresponding to the same session use the recorded quality unit mapping table version.

[0023] When the dosage unit is a volume unit, the corresponding drug concentration is obtained according to the drug code, dosage form, and drug specification, and then converted to the standard mass dose according to the following formula: Where V raw The original volumetric dose is given, where C is the concentration of the active ingredient corresponding to the drug code, dosage form, and drug specification; the units of mass and volume of C should be the same as those of D. std and V raw Matching. For example, when V raw Expressed in mL, D std When expressed in mg, C should be expressed in mg / mL. When drug concentration is missing, multiple possible concentrations exist, or the drug concentration cannot be uniquely determined based on the drug standard code, dosage form, and drug specification, the structured parsing module does not perform the default conversion but instead generates a unit correction task.

[0024] The structured parsing module also performs mandatory field integrity checks, uniqueness checks, and field consistency checks on drug standard codes, dosage values, dosage units, dosing frequency, and routes of administration. When any clinically critical field is missing, has multiple candidate values, or conflicts exist between different fields, the structured parsing module does not directly complete the clinically critical field using default values ​​or fuzzy matching results, but instead generates a format correction task. In one embodiment, the similarity matching results of drug names are only used to form a set of candidate drug codes and are not directly used as the final drug standard code.

[0025] If structured parsing succeeds, the session control block state is set to VALIDATING, and the structured candidate feature set is sent to the rule validation module. If structured parsing fails, the parsing failure count is incremented, and a format correction task containing the failed fields, failure reasons, candidate values, and the target output data structure is generated. When the parsing failure count is less than the preset parsing failure limit, the format correction task is sent to the large model inference module; when the parsing failure count reaches the preset parsing failure limit, the session control block state is set to FAILED, and the writing of candidate medical order data is rejected.

[0026] The structured candidate feature set can be stored and transmitted using objects, structures, key-value pairs, JSON data, Protobuf data, or continuous byte data. This invention does not limit the structured candidate feature set to have a fixed byte length.

[0027] IV. Rule Base Matching and Deterministic Assertion Validation The structured medical rule base includes multiple rule items, each corresponding to a deterministic constraint. Each rule item includes at least: rule identifier, drug standard code, dosage form, route of administration, patient applicability conditions, rule type, rule limit value, limit value unit, conflicting drug set, rule source, rule version, effective time, expiration time, activation status, correctable flag, set of modifiable fields, and corrective output data structure identifier. Patient applicability conditions may include one or more of the following: age range, weight range, renal function range, liver function classification, pregnancy status, lactation status, and allergic status.

[0028] Different drugs, dosage forms, routes of administration, and patient conditions correspond to different rule items. The rule verification module does not use the same set of age, weight, renal function, and liver function correction coefficients to uniformly calculate the safe dosage threshold for all drugs. Instead, it selects specific rule items whose applicable conditions are met based on the current candidate medical order data and patient constraint data.

[0029] The rule verification module selects applicable rules in the following order: retrieval of candidate rule items based on drug standard codes; exclusion of inapplicable rule items based on dosage form and route of administration; screening of applicable rule items based on patient age, weight, liver and kidney function, and other patient constraints; determination of currently valid rule items based on their effective time, expiration time, and activation status; and execution of dose, frequency, allergy, contraindication, and drug interaction verifications on the determined valid rule items.

[0030] Please see Figure 3 , Figure 3This diagram illustrates the dual-buffer hot update mechanism and session rule version binding relationship of the structured medical rule base. Each session control block is bound to a rule base version upon creation. The initial validation and all self-correction iterations corresponding to the same session control block use the bound rule base version, thus avoiding the use of different rule conditions in different iteration rounds for the same candidate medical order processing session. When the rule base is updated, newly created session control blocks use the updated rule base version; session control blocks created before the update continue to use the original bound rule base version until the session is completed. The rule base management module sets up active and inactive buffers and sets an atomic pointer pointing to the currently active buffer. When updating the rule base, the new rule version is written to the inactive buffer, and file integrity, required field integrity, rule version consistency, and rule index availability checks are performed on the new rule version; after the checks pass, the atomic pointer is switched to the buffer containing the new rule version through an atomic operation. When a session control block is created, its bound rule base version is recorded, and the session reference count for the corresponding rule base version is incremented; after the session enters the COMMITTED or FAILED state, the session reference count is decremented. Before the session reference count of the old rule base version drops to zero, the buffer storing the old rule base version is not overwritten; after the reference count drops to zero, the buffer can be converted into an inactive buffer for writing to the next rule version.

[0031] The rule validation module performs deterministic assertion validation on the structured candidate feature set. Let the structured candidate feature set be F, and the rule base version bound to the current session be R. v The rule set applicable to the structured candidate feature set is J(F, R). v The verification result can then be expressed as: The verification passes when all applicable rules are true; it fails when at least one applicable rule is false. When no rule applicable to the current drug code, dosage form, route of administration, and patient constraints is found, or when a pre-defined required rule type is missing, the rule verification module does not classify the candidate medical order data as passed, but instead generates a verification result for the rule missing type. When multiple valid rule items with the same applicable conditions but conflicting limits exist in the same rule base version, the rule verification module generates a verification result for the rule conflict type and rejects the candidate medical order data from entering the pending signature table. Rule missing type and rule conflict type are set as uncorrectable violation types. When an uncorrectable violation type verification result is generated, the failure control module sets the session control block to FAILED, does not generate a structured correction task, and rejects the candidate medical order data from entering the pending signature table and the core medical order table. Each rule item is set with a correctable flag to indicate whether the candidate medical order data is allowed to be revised through the large model after the rule is triggered. For rule items with a correctable flag set to true, a structured correction task is generated based on the set of allowed-modification fields associated with that rule item. For rule items with a false correctable flag, the corresponding violation type is determined to be an uncorrectable violation type. Missing rule types and conflicting rule types are considered uncorrectable violation types by default. All violation types output by the rule validation module are divided into correctable and uncorrectable violation types, which do not overlap and cover all violation types that the rule validation module can output.

[0032] The validation results output by the rule validation module include at least: whether the validation passed, the triggered rule identifier, the violation field, the rule limit value, the current candidate value, the violation type, the rule source, and the rule version. When the validation passes, the phased database write process begins; when the validation fails and the violation type belongs to a preset correctable violation type, the structured correction process begins; when the violation type belongs to a preset uncorrectable violation type, the failure control process begins.

[0033] In one embodiment, the system can use a Bloom filter to quickly pre-screen the combined drug set. When the Bloom filter determines that the current drug does not conflict with the combined drug set, other checks can continue; when the Bloom filter determines that a conflict may exist, the rule check module further calls the complete drug standard code set for precise set comparison. The result of the Bloom filter is not directly used as the final incompatibility conclusion; the final check result is based on the precise set comparison result.

[0034] V. Structured Correction Tasks and Priority Scheduling When the deterministic assertion verification fails and the violation type belongs to a preset correctable violation type, the correction task generation module generates a violation metadata record based on the verification result. The violation metadata record includes at least: session identifier, triggered rule identifier, rule version, violation type, violation field, rule limit value, current candidate value, conflicting drug set, and rule source.

[0035] The error correction task generation module generates a structured error correction task based on the violation metadata record and the current candidate medical order data. The structured error correction task includes at least: session identifier, rule base version, current candidate medical order data, triggered rule identifier, violation field, rule limit value, candidate value, violation type, set of fields that can be modified, set of fields that cannot be modified, and target output data structure.

[0036] The set of fields that can be modified is used to limit the data fields that the large model can adjust. For example, when the violation field is "single dose," "single dose" can be set as a modifiable field; patient age, weight, allergy history, liver and kidney function information, and confirmed drug standard codes can be set as prohibited fields. When the large model inference module generates revised candidate medical order data based on the structured correction task, it can only modify fields in the set of fields that can be modified, and cannot modify fields in the set of prohibited fields. The structured parsing module aligns the fields of the current candidate medical order data and the revised candidate medical order data returned by the large model according to the target output data structure. Let X be the current candidate medical order data in the k-th round. (k) The large model returned revised candidate medical orders data as follows: Then the set of changing fields Represented as: in, f Let A represent the fields in the target output data structure. Fields that can be modified are set A, and fields that cannot be modified are set B. The set of fields that can be modified (A) and the set of fields that cannot be modified (B) are disjoint, and their union covers all fields in the target output data structure. The candidate medical order data for revision is deemed to have passed the field difference validation when the following condition is met: when When the revised candidate medical order data is deemed an invalid correction result, the current write intent payload is not updated, and the current iteration number is incremented. When the revised candidate medical order data is discarded, the result is marked as a structured parsing failure, and the failure handling process described in

[0025] increments the parsing failure count by one time, and records the fields that have changed and are prohibited from modification. When the field difference verification passes, the next round of candidate medical order data is formed according to the following formula: Therefore, only the changed fields in the set of fields that can be modified are merged into the current write intent payload, while other fields continue to use the original field values ​​in the current candidate medical order data.

[0037] The target output data structure is used to define the field names, field types, and required fields of the data returned by the large model. In one embodiment, the structured correction task is serialized into JSON or Protobuf messages and converted into model input messages according to the requirements of the large model interface. When the data returned by the large model does not conform to the target output data structure, the result is marked as a structured parsing failure, and the failure handling process described in

[0025] increments the parsing failure count by one time.

[0038] The system sets up a regular inference task queue and a correction task queue. The regular inference task queue stores model inference tasks that are not yet in the correction stage; the correction task queue stores correction tasks that have entered the pre-submission pending stage but have failed validation. When the correction task queue is not empty, the inference scheduler prioritizes retrieving correction tasks from the correction task queue; only when the correction task queue is empty does the inference scheduler retrieve regular inference tasks from the regular inference task queue.

[0039] The inference module may include one or more inference work units, the number of which is configured according to the available inference resources. Therefore, this invention does not limit the inference module to single-threaded processing.

[0040] After the revised candidate medical order data passes the output structure check and field difference check, the control unit only merges the changed fields from the allowed modified field set into the current write intent payload in the temporary write buffer, increments the iteration count, and re-executes the structured parsing and deterministic assertion check. When the revised candidate medical order data passes the check, it enters the process of writing the pending signature table. If the iteration count reaches the preset iteration limit and still fails to pass the check, the large model is no longer called, the session control block state is set to FAILED, and the writing of candidate medical order data is rejected. The iteration control enables the self-correction process to terminate within a preset finite number of steps, but does not mean that every candidate medical order data will necessarily be corrected successfully within the iteration limit.

[0041] VI. For the phased writing of the pending signature form and the core medical order form, please refer to [link / reference needed]. Figure 4 , Figure 4The sequence of events for a candidate medical order write request is illustrated, from the pre-submission pending state, through the first independent physical transaction writing to the pending signature table, awaiting physician electronic signature, to the second independent physical transaction writing to the core medical order table. After the structured candidate feature set passes the deterministic assertion verification, the transaction write module reconstructs the first database write request based on the verified write intent payload in the temporary write buffer. The transaction write module obtains the first database connection from the backend database connection pool, initiates the first physical transaction on the first database connection, and writes the verified candidate medical order data to the pending signature table.

[0042] like Figure 4 As shown, after the candidate medical order data is successfully written to the pending signature table, the transaction writing module commits the first independent physical transaction, releases the first database connection and the database lock resources occupied by the first physical transaction, and sets the session control block state to WAITING_SIGNATURE. The first physical transaction ends immediately after the candidate medical order data is written to the pending signature table and does not persist until the physician's electronic signature. At this time, although the candidate medical order data has passed the rule verification, it has not yet been written to the core medical order table.

[0043] Each candidate medical order record in the pending signature table includes at least a pending signature record identifier, a session identifier, a request identifier, candidate medical order data, a candidate medical order data summary value, a rule base version, a model version, a verification result summary, a write time, and a signature status. The signature status is initially set to unsigned. After the first physical transaction is successfully committed, the database proxy module returns a pending signature status response to the upstream medical order application. The pending signature status response includes at least a session identifier, a pending signature record identifier, and a pending signature status code; the pending signature status response does not indicate that the candidate medical order data has been written to the core medical order table.

[0044] When the system receives a physician's electronic signature signal, it queries the corresponding record to be signed based on the session identifier and the record identifier to be signed, and verifies the correspondence between the physician's electronic signature signal and the record to be signed. The physician's electronic signature signal includes at least the record identifier to be signed, the signing physician identifier, the candidate medical order data digest value, the signature value, and the signature time. Before initiating the second independent physical transaction, the transaction write module verifies the validity of the record identifier to be signed, the candidate medical order data digest value, the signing physician's permissions, and the signature value. After successful verification, the transaction write module re-acquires a second database connection from the backend database connection pool and initiates the second physical transaction on the second database connection.

[0045] In the second physical transaction, the transaction write module writes the medical order data in the corresponding record to be signed into the core medical order table and updates the signature status of the record to be signed to signed. After the second physical transaction is successfully committed, the second database connection and its database lock resources are released, and the session control block status is set to COMMITTED. The first physical transaction and the second physical transaction are independent database transactions. There is no persistent database physical transaction or database lock between them.

[0046] If a record awaiting signature does not receive a physician's electronic signature signal, the record will not be added to the core medical order form. Therefore, rule validation only constitutes a condition for writing to the pending signature form, while the physician's electronic signature constitutes a further condition for writing to the core medical order form.

[0047] VII. Anomaly Handling and Failure Safety Control This embodiment adopts a failure safety control principle. When the system cannot confirm that the candidate medical order data has passed structured parsing, deterministic assertion verification, and physician electronic signature, the candidate medical order data will not be written into the core medical order table.

[0048] When the large model inference module fails to return revised candidate medical order data within the preset processing time limit, the control unit sets the session control block status to FAILED, records the reason for the inference timeout, and refuses to write candidate medical order data.

[0049] When the rule library version bound to the current session is unavailable, the rule verification fails to be read, or the rule verification module malfunctions, the system does not automatically switch to another rule library version to continue verification, but instead sets the current session to a failed state.

[0050] When the client network connection is lost during the pre-submission pending period, the system retains or clears the current processing state according to the session control block. Regardless of whether the client network connection is maintained, the system must not automatically write the candidate medical order data into the core medical order table before the candidate medical order data has passed verification and been electronically signed by the physician.

[0051] When the first physical transaction fails to write to the pending signature table, the system rolls back the first independent physical transaction, releases the corresponding database connection and lock resources, sets the session control block to FAILED, ends the pre-commit pending state, and returns a write failure status to the upstream medical order application. The session state is not set to WAITING_SIGNATURE, and the reason for the write failure is recorded.

[0052] When the second independent physical transaction fails to write to the core medical order table, the system rolls back the second independent physical transaction, releases the corresponding database connection and lock resources, sets the final write status to core write failed, and retains the record to be signed and the verified electronic signature information, but does not mark the record to be signed as having completed core write. If the preset number of retries is reached and the idempotency verification condition is met, the second independent physical transaction is re-executed; if the preset retry limit is reached and the transaction still fails, the session control block status is set to FAILED.

[0053] When a duplicate physician electronic signature signal or a duplicate core write request is received, the system performs idempotent verification based on the session identifier, the identifier of the record to be signed, and the final write status; the identifier of the record to be signed or the request identifier is set with a unique constraint in the core medical order table. For data that has already been successfully written to the core medical order table, a second physical transaction is not executed again.

[0054] If a record awaiting signature fails to receive a physician's electronic signature signal within the preset waiting time limit, the system sets the signature status of the record to TIMEOUT and the session status of the corresponding session control block to FAILED. Candidate medical order data with a signature status of TIMEOUT must not be automatically written into the core medical order table.

[0055] VIII. Complete Processing Example In this embodiment, the upstream medical order application generates a candidate medical order write request. The candidate medical order data includes fictitious drug A, a single dose of 0.5g, twice-daily administration, and an oral administration route. The database proxy module intercepts the candidate medical order write request before it is sent to the backend database, establishes a session control block SCB-001, and sets the candidate medical order write request to a pre-commit pending state. At this time, the database proxy module does not send a transaction start instruction or write instruction to the backend database, and there is no physical transaction corresponding to this request in the backend database.

[0056] The structured parsing module maps the fictitious drug A to the standard drug code D001 and converts 0.5g to 500mg, forming a structured candidate feature set. The rule base version bound to the current session control block is RV-01. In the fictitious rule base used in this embodiment, rule R-D001-01 specifies that, under the patient conditions set in this embodiment, the single dose limit for drug D001 is 400mg.

[0057] The rule verification module determines that the candidate value of 500mg is greater than the rule limit of 400mg and generates a verification failure result. The verification result includes: rule identifier R-D001-01; violation field is single dose; rule limit is 400mg; current candidate value is 500mg; violation type is dose exceeding the limit; this violation type belongs to the correctable violation type.

[0058] The error correction task generation module generates a structured error correction task based on the verification results. The error correction task sets the single dose as an allowed-to-modify field, and sets the drug standard code, patient constraint data, and route of administration as prohibited-to-modify fields, and requires the large model to return revised candidate medical orders data in a preset structured format.

[0059] The inference scheduler prioritizes scheduling the correction task. The large model inference module returns revised candidate medical order data according to the target output data structure, where the single dose is revised to 400mg. The structured parsing module compares the current candidate medical order data and the revised candidate medical order data, determining that the set of changed fields only includes the single dose field, and that none of the fields in the prohibited modification field set have changed. The database proxy module only merges the revised single dose field into the current write intent payload and re-executes structured parsing and deterministic assertion verification. After the re-verification passes, the system generates a record identifier to be signed and a candidate medical order data summary value. The transaction write module initiates the first independent physical transaction, writing the verified candidate medical order data into the to-be-signed table; after the first independent physical transaction is committed, the corresponding database connection and lock resources are released, and the session control block state is set to WAITING_SIGNATURE.

[0060] Upon receiving the physician's electronic signature signal, the transaction writing module initiates a second physical transaction, writing the record to be signed into the core medical order form. The drug codes, rule limits, and candidate dosages are fictitious data used to illustrate the system's data processing flow and do not constitute any specific clinical medication advice.

Claims

1. A method for pre-submission isolation verification and self-correction of medical order data generated by a large model, characterized in that, include: Step S1: Receive a candidate medical order writing request from the upstream medical order application. The candidate medical order writing request includes candidate medical order data generated by the large model and patient constraint data associated with the candidate medical order data. Step S2: The database agent intercepts the candidate medical order write request before it is sent to the backend database, parses and extracts the write intent payload, and establishes a session control block associated with the candidate medical order write request. Without sending transaction start and write instructions to the backend database, the write intent payload is temporarily stored in a temporary write buffer isolated from the core medical order table, and the candidate medical order write request is set to a pre-commit pending state. Step S3: Perform structured parsing on the candidate medical order data in the intent payload, map drug names to standard drug codes, reduce dosage values ​​and units, and extract dosing frequency, route of administration, combined medication information, and patient constraint fields to form a structured candidate feature set; associate the structured candidate feature set with the rule base version bound to the current session control block; when the structured parsing fails, increment the number of structured parsing failures; when the incremented number of structured parsing failures does not reach the preset parsing failure limit, generate a format correction task based on the parsing failure fields, parsing failure reasons, candidate values, and target output data structure, and send the format correction task to the large model inference module; Receive the revised candidate medical order data returned by the large model inference module, update the write intent payload in the temporary write buffer using the revised candidate medical order data, and return to step S3; when the incremented number of structured parsing failures reaches or exceeds the preset parsing failure limit, execute step S7; Step S4: Call the structured medical rule base corresponding to the rule base version, perform deterministic assertion verification on the structured candidate feature set, and generate verification results; The verification result includes at least whether it passed, the triggered rule identifier, the violation field, the rule limit value, the candidate value, and the violation type; Step S5: When the verification result is unsuccessful, the violation type belongs to the preset correctable violation type, and the current iteration number has not reached the preset iteration limit, a correction task is generated based on the verification result and the current candidate medical order data. The correction task is sent to the large model inference module with a scheduling priority higher than that of the ordinary inference task. The revised candidate medical order data generated by the large model inference module is received. The write intent payload in the temporary write buffer is updated using the revised candidate medical order data. The current iteration number is incremented, and the process returns to step S3. Step S6: When the verification result is passed, the database write request is reconstructed according to the verified write intention payload in the temporary write buffer, the verified candidate medical order data is written to the pending signature table through the first independent physical transaction, and the pre-submission pending state of the candidate medical order write request is ended. After receiving the physician's electronic signature signal corresponding to the candidate medical order data, the corresponding medical order data in the to-be-signed table is written into the core medical order table through a second independent physical transaction. Step S7: When the number of structured parsing failures reaches or exceeds the preset parsing failure limit, or the current iteration count reaches the preset iteration limit and still fails to pass the verification, or the verification result belongs to the rule missing type, rule conflict type, or other preset uncorrectable violation type, the session control block is set to a failure state, the candidate medical order data is refused to be written to the pending signature table and the core medical order table, and the pre-submission pending state of the candidate medical order writing request is ended.

2. The method according to claim 1, characterized in that, The database proxy maintains the pre-submission pending state of candidate medical order write requests using an event-driven non-blocking communication method. During the pre-submission pending state, the database proxy maintains the client network session or saves the asynchronous response identifier, but does not initiate backend database physical transactions for the candidate medical order write request, does not hold database locks generated by the candidate medical order write request, and does not continuously occupy the backend database active connection for the candidate medical order write request. The session control block records at least the session identifier, current candidate medical order data, current iteration number, number of parsing failures, processing status, and creation time.

3. The method according to claim 1, characterized in that, The correction task is written into a correction task queue that is independent of the ordinary inference task queue. When the correction task queue is not empty, the inference scheduler preferentially obtains correction tasks from the correction task queue. When the correction task queue is empty, the inference scheduler obtains ordinary inference tasks from the ordinary inference task queue.

4. The method according to claim 1, characterized in that, The structured parsing includes checking the completeness of required fields for drug name, dosage value, dosage unit, dosing frequency, and route of administration. When any required field is missing, corresponds to multiple candidate values, or conflicts exist between different fields, the required field is not directly filled using default values ​​or fuzzy matching results. Instead, a format correction task is generated and sent to the large model inference module. When the number of structured parsing failures reaches the preset parsing failure limit, the candidate medical order writing request is rejected.

5. The method according to claim 1, characterized in that, Specification of dose values ​​and dose units includes: When the dosage unit is a mass unit, the dosage is converted to a preset standard mass unit according to the versioned mass unit mapping table and the following formula: In the formula, D std For standard mass dosage, D raw This is the original dose value; U raw S is the original unit of mass. mass (U) raw The conversion ratio from the original mass unit to the standard mass unit is given; when mg is the standard unit: When the dosage unit is a volume unit, the corresponding drug concentration is obtained according to the drug code, dosage form, and drug specification, and then converted to the standard mass dose according to the following formula: Where V raw The original volumetric dose is given, where C is the concentration of the active ingredient corresponding to the drug code, dosage form, and drug specification; the units of mass and volume of C should be the same as those of D. std and V raw Matching. For example, when V raw Expressed in mL, D std When expressed in mg, C should be expressed in mg / mL; when the dosage unit is unidentifiable, ambiguous, or the drug concentration cannot be uniquely determined, the default conversion is not performed, and a unit correction task is generated.

6. The method according to claim 1, characterized in that, The dosage rule items in the structured medicine rule base include at least the drug code, dosage form, route of administration, patient applicable conditions, constraint type, limit value, limit value unit, rule source identifier, rule version, and effective time. The patient eligibility criteria include at least one of age range, weight range, renal function range, and liver function classification; based on the candidate medical order data and patient constraint fields, a dosage rule item whose patient eligibility criteria are met is selected, and the deterministic assertion verification is performed based on the selected dosage rule item.

7. The method according to claim 1, characterized in that, The correction task includes at least a session identifier, rule base version, current candidate medical order data, triggered rule identifier, violation field, rule limit value, candidate value, violation type, set of fields that can be modified, set of fields that cannot be modified, and target output data structure; The large model inference module generates revised candidate medical order data according to the target output data structure; The structured parsing module performs output structure verification and field difference verification on the revised candidate medical order data. When any field in the prohibited modification field set changes, the revised candidate medical order data is discarded and counted as a structured parsing failure. When at least one field changes, all changed fields belong to the allowed modification field set, and none of the fields in the prohibited modification field set have changed, only the changed fields in the allowed modification field set are merged into the current write intent payload.

8. A pre-submission isolation verification and self-correction system for generating medical order data from a large model, characterized in that, It includes a database proxy module, a structured parsing module, a rule base management module, a rule validation module, a correction task generation module, a correction scheduling module, a large model inference module, a transaction writing module, and a failure control module; The database proxy module is used to intercept the candidate medical order writing request before the candidate medical order writing request containing candidate medical order data generated by the large model is sent to the backend database, parse and extract the writing intent payload, and establish a session control block associated with the candidate medical order writing request. Without sending transaction start instructions and data write instructions to the backend database, the write intent payload is temporarily stored in a temporary write buffer, and the candidate medical order write request is set to a pre-submit pending state. The structured parsing module is used to parse the candidate medical order data into a structured candidate feature set containing drug code, dosage value, dosage unit, dosing frequency, dosing route, combined medication information and patient constraint fields; The rule base management module is used to store and manage the structured medical rule base and the rule base version corresponding to the structured medical rule base; The rule verification module is used to select rule items applicable to the structured candidate feature set from the structured medical rule base according to the rule base version associated with the session control block, perform deterministic assertion verification on the structured candidate feature set, and generate a verification result including at least whether it passes, violation type, triggered rule identifier, violation field, rule limit value, and candidate value. The correction task generation module is used to generate a structured correction task based on the verification result when the verification result is "fail" and the violation type in the verification result belongs to a preset correctable violation type. The error correction scheduling module is used to send the structured error correction task to the large model inference module with a higher scheduling priority than ordinary inference tasks. The large model inference module is used to generate revised candidate medical order data based on the structured correction task; The database proxy module is also used to update the write intent payload in the temporary write buffer using the revised candidate medical order data, so as to re-perform structured parsing and deterministic assertion verification; The transaction writing module is used to write the verified candidate medical order data into the pending signature table through a first independent physical transaction after the verification is passed, and to write the corresponding medical order data into the core medical order table through a second independent physical transaction after receiving the physician electronic signature signal corresponding to the candidate medical order data. The failure control module is used to set the session control block to a failure state, end the pre-submission pending state, and refuse to write the candidate medical order data into the pending signature table and the core medical order table when the following conditions are met before the first independent physical transaction is started: the number of iterations reaches the preset iteration limit and still fails to pass the verification; the number of structured parsing failures reaches the preset parsing failure limit; the violation type in the verification result belongs to the preset uncorrectable violation type; or the processing time exceeds the preset processing time limit. The failure control module is also used to retain the corresponding record to be signed when the candidate medical order data has been written into the record to be signed and the preset signing waiting time limit has been exceeded, set the session control block to a failure state, and prohibit the candidate medical order data in the record to be signed from being written into the core medical order table.

9. The system according to claim 8, characterized in that, The rule base management module adopts a dual-buffer hot update mechanism, wherein the dual buffers include an active buffer and an inactive buffer. After the new rule version is written to the inactive buffer and completes the integrity check, the inactive buffer is switched to the new active buffer through an atomic switch. Each session control block is bound to the rule base version corresponding to the active buffer at that time when it is established. All rule selection, deterministic assertion verification and correction task generation corresponding to the same session control block use the bound rule base version. Before all session control blocks bound to the old rule base version have been processed, the rule data corresponding to the old rule base version is retained; newly established session control blocks are bound to the new rule base version after the atomic switch.

10. The system according to claim 8, characterized in that, It also includes an auditing module, which records the session identifier, request identifier, model version, rule base version, summary value of candidate medical order data in each round, verification results in each round, triggered rule identifier, iteration number, processing result of the first independent physical transaction, record identifier to be signed, physician electronic signature status, processing result of the second independent physical transaction, final write status, and timestamps corresponding to each processing status.

Images