Outpatient Companion Robot Method and System Based on Multimodal Perception and Intelligent Decision Making

Abstract

This invention relates to the field of medical service resource scheduling and robot task control technology, and particularly to an outpatient companion robot method and system based on multimodal perception and intelligent decision-making. The method includes: generating a set of mandatory nodes, task instances, and task execution status based on patient visit identifiers, current valid medical orders and their versions, medical order-node mapping relationships, and node dependencies; verifying node status records to form node status snapshots and target node access sequences; decomposing the task instance to be executed into robot guidance tasks and terminal business sub-tasks, and matching terminal capability records to determine the target terminal; updating the task execution status based on terminal receipts and terminal execution results, maintaining the task instance identifier and generating a task migration record when the terminal malfunctions; and dynamically rearranging the nodes to be executed to generate an adjusted node access sequence and sequence version record. This invention effectively improves the continuity of outpatient task status and the traceability of process adjustments.

Description

Technical Field

[0001] This invention relates to the field of medical service resource scheduling and robot task control technology, and in particular to an outpatient companion robot method and system based on multimodal perception and intelligent decision-making. Background Technology

[0002] In the field of medical service resource scheduling and robot task control technology, existing outpatient companionship solutions typically consist of a hospital information system, a queuing and calling system, self-service terminals, and a companionship robot. The hospital information system provides patient registration and medical order information; the queuing and calling system maintains department queues and equipment occupancy status; self-service terminals handle check-in, payment, and report printing; and the companionship robot generates guidance tasks based on the department or target location entered by the patient. Some solutions also adjust the calling order or robot movement route based on the current queue length, equipment operating status, or patient priority.

[0003] Existing solutions often rely on fixed outpatient workflows, individual business node statuses, or the current navigation target for processing. Medical order data, node queuing status, terminal execution status, and robot task status are typically maintained by different systems. When medical orders are added, modified, or revoked, node statuses expire, or the target terminal fails to receive the task or execution fails, there is a lack of continuous correlation between the original task and subsequent tasks. This can easily lead to inconsistencies between task status and actual execution results, simultaneous effects of old and new access sequences, and difficulty in matching terminal feedback with the original task.

[0004] For the continuous processing of the same patient across multiple outpatient workflow nodes, existing technologies still suffer from problems such as difficulty in continuing to use the results of completed nodes after workflow adjustments, difficulty in distinguishing between tasks in progress and tasks yet to be executed, and discontinuous task transitions after terminal malfunctions. Furthermore, in scenarios where medical order versions and node states continuously change, the access order of subsequent nodes can easily become disconnected from the existing task execution state. Therefore, it is necessary to address the issues of task instance continuity, retention of completed node execution results, and updating of the access order of subsequent nodes when dealing with patient visit tasks handled by outpatient companion robots, in the face of changes in medical order versions, node state failures, or terminal execution malfunctions. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for an outpatient companion robot based on multimodal perception and intelligent decision-making, comprising:

[0006] S100: Obtain the patient's visit identifier, current valid medical order, medical order version, medical order-node mapping relationship, and node dependency relationship; generate a set of required nodes, task instance, and task execution status based on the medical order-node mapping relationship and the node dependency relationship;

[0007] S200. Obtain the node status records of the set of nodes that must be visited, verify the validity of the status and generate a node status snapshot; sort the set of nodes that must be visited according to the node dependency relationship and the node status snapshot, and generate a target node access sequence;

[0008] S300: Determine the node to be executed based on the target node access sequence and task execution status, decompose the corresponding task instance into robot guidance task and terminal business sub-task; match the terminal capability record to determine the target terminal, generate task delegation record and issue task;

[0009] S400: The receiving terminal receives the receipt and the terminal execution result, and updates the task execution status; if the target terminal does not return the terminal receipt or the terminal execution result is execution failure, the task instance identifier is maintained, the terminal capability record is re-matched and a task migration record is generated.

[0010] When S500 detects changes in medical order versions, node status failures, or task migration records, it inherits the execution results of completed nodes, dynamically rearranges the nodes to be executed, and generates adjusted node access sequences and sequence version records.

[0011] Furthermore, the generation of the required node set, task instance, and task execution status includes:

[0012] Based on the medical order-node mapping relationship, match the outpatient process node corresponding to the currently valid medical order;

[0013] Based on the node dependencies, supplement outpatient process nodes with node prerequisite constraints;

[0014] Obtain historical completion records and exclude completed nodes from the matched outpatient process nodes in the historical completion records;

[0015] The task instance is generated for the excluded outpatient process nodes, and the patient visit identifier, the medical order version, the outpatient process node identifier, and the task execution status are associated with the task instance.

[0016] Furthermore, the node status record includes the current queue length, average processing time, current node occupancy, available node capacity, status collection time, and status validity period.

[0017] The validity of the status record of each node is determined based on the status acquisition time and the status validity period.

[0018] Filter the node status records that meet the status validity conditions, generate the node status snapshot, and associate the node status snapshot with the medical order version.

[0019] Further, the generation of the target node access sequence includes:

[0020] The set of mandatory nodes is sorted according to the node dependencies to generate multiple candidate access sequences;

[0021] Obtain the node time window, and filter the candidate access sequence based on the node time window and resource usage constraints;

[0022] Based on the current queue length, the average processing time, the current node occupancy, and the available node capacity, the filtered candidate access sequences are sorted to determine the target node access sequence, and the target node access sequence is associated with the node state snapshot.

[0023] Furthermore, the terminal capability record includes executable business types, authentication methods, payment capabilities, printing capabilities, terminal operating status, and resource load data;

[0024] The service type and authentication method of the terminal service sub-task are matched with the terminal capability record to generate a candidate terminal set;

[0025] Candidate terminals whose operating states meet the validity conditions are selected from the candidate terminal set;

[0026] The selected candidate terminals are sorted according to the resource load data to determine the target terminal.

[0027] Furthermore, the task delegation record includes a task instance identifier, a target terminal identifier, a delegation time, a delegation validity period, a medical order version, and a delegation status;

[0028] The task sent to the target terminal includes a delegation request that binds the task instance identifier, the medical order version, and the delegation validity period;

[0029] When a delegation request with the same task instance identifier is received, the delegation request is associated with an existing task delegation record, and the delegation status is updated.

[0030] Further, the re-matching of terminal capability records and generation of task migration records includes:

[0031] If the target terminal fails to return a receipt within the time limit for receiving the assignment, returns a rejection status, the execution result of the terminal is an execution failure, or the terminal's running status is unavailable, the original task assignment record shall be revoked.

[0032] Maintain the task instance identifier, re-match the terminal service sub-task with the terminal capability record, and determine the alternative terminal;

[0033] The terminal service subtask is sent to the alternative terminal, and a task migration record is generated that associates the original execution subject, the target execution subject, the task instance identifier, the migration reason, and the migration status.

[0034] Furthermore, the estimated arrival time is determined based on the robot's current location and the node information of the outpatient process nodes;

[0035] The available capacity of a node is determined based on the estimated arrival time, node capacity, and existing node occupancy records.

[0036] When the available capacity of a node meets the node capacity constraint, a node occupancy record is generated. The node occupancy record includes the task instance identifier, the outpatient process node identifier, the estimated arrival time, the resource occupancy lease term, and the node occupancy status.

[0037] When the task execution status is completed, a robot task abnormality occurs, or the resource occupation lease term expires, the available node capacity corresponding to the node occupation record is released or reclaimed.

[0038] Furthermore, the inheritance of the completed node execution results and the dynamic rearrangement of nodes to be executed includes:

[0039] Based on the task execution status, the target node access sequence is divided into completed nodes, executing nodes, and pending nodes;

[0040] Retain the completed nodes and their execution results, process the nodes in execution according to the execution status inheritance conditions, and revoke the task delegation records that are no longer applicable;

[0041] The outpatient process nodes resulting from changes in the medical order version are combined with the retained pending execution nodes to form a set of remaining nodes;

[0042] The adjusted node access sequence is generated based on the remaining node set and the updated node state snapshot;

[0043] Generate a sequence version record that associates the original sequence version with the adjusted sequence version, and update the pending node corresponding to the original sequence version to an invalid state.

[0044] Furthermore, the outpatient companion robot system based on multimodal perception and intelligent decision-making includes: a medical order node parsing module, a node status processing module, a node access sequence generation module, a subtask orchestration module, a terminal capability management module, a task delegation and execution feedback processing module, a task migration module, and a dynamic reordering module; the system is used to implement the method described in any one of the above.

[0045] The following are its main beneficial effects:

[0046] (1) To address the problem of discontinuous task source and access sequence due to separate maintenance of medical order data, outpatient process nodes and node operation status, node mapping driven by medical order version, node dependency supplementation, historical completion record filtering and node status snapshot constraint are used to convert the current valid medical order into a set of mandatory nodes with clear task instances and execution status, and to make the target node access sequence have corresponding medical order version and node status basis.

[0047] (2) To address the issues of the independent nature of the companion robot tasks and the lack of correlation between the receiving and execution statuses after the terminal tasks are issued, the robot guide tasks and terminal business sub-tasks are decomposed, the terminal capabilities are matched, and the task delegation records and execution receipts are processed to ensure that the delegation status, receiving status and execution results of the same task instance are continuously correlated. When the target terminal is abnormal, the execution results of the substitute terminal continue to belong to the original task instance.

[0048] (3) To address the issue of completed business being repeatedly arranged and new and old access sequences taking effect simultaneously after changes in the version or node status of medical orders, the adjusted node access sequence is made to organize only the task instances that still need to be executed, and to ensure that the unexecuted tasks in the original sequence have a clear invalidation and validity relationship with the adjusted sequence by inheriting the execution results of completed nodes, distinguishing between nodes in execution and nodes to be executed, and establishing a sequence version record. Attached Figure Description

[0049] Figure 1 A flowchart illustrating the outpatient companion robot method based on multimodal perception and intelligent decision-making provided in this application embodiment;

[0050] Figure 2 This is a structural block diagram of an outpatient companion robot system based on multimodal perception and intelligent decision-making, provided in an embodiment of this application. Detailed Implementation

[0051] Example 1: Refer to Figure 1 This is a flowchart illustrating the outpatient companion robot method based on multimodal perception and intelligent decision-making provided in an embodiment of the present invention. The process may include at least steps S100-S500:

[0052] S100: Obtain the patient's visit identifier, current valid medical order, medical order version, medical order-node mapping relationship, and node dependency relationship; generate a set of required nodes, task instance, and task execution status based on the medical order-node mapping relationship and the node dependency relationship;

[0053] S200. Obtain the node status records of the set of nodes that must be visited, verify the validity of the status and generate a node status snapshot; sort the set of nodes that must be visited according to the node dependency relationship and the node status snapshot, and generate a target node access sequence;

[0054] S300: Determine the node to be executed based on the target node access sequence and task execution status, decompose the corresponding task instance into robot guidance task and terminal business sub-task; match the terminal capability record to determine the target terminal, generate task delegation record and issue task;

[0055] S400: The receiving terminal receives the receipt and the terminal execution result, and updates the task execution status; if the target terminal does not return the terminal receipt or the terminal execution result is execution failure, the task instance identifier is maintained, the terminal capability record is re-matched and a task migration record is generated.

[0056] When S500 detects changes in medical order versions, node status failures, or task migration records, it inherits the execution results of completed nodes, dynamically rearranges the nodes to be executed, and generates adjusted node access sequences and sequence version records.

[0057] S100: Obtain the patient's visit identifier, current valid medical order, medical order version, medical order-node mapping relationship, and node dependency relationship; generate a set of required nodes, task instance, and task execution status based on the medical order-node mapping relationship and the node dependency relationship.

[0058] This step is executed by the medical order node parsing module in the outpatient companion robot system. This module can be deployed in the processor of the digital healthcare service system and connected to the companion robot, the medical order system, the medical record storage unit, and the outpatient process node configuration unit via communication modules. When the patient begins receiving companion services, the companion robot reads the patient's visit identifier and sends it to the medical order node parsing module. The module then queries the currently valid medical orders, their versions, and historical completion records based on the patient's visit identifier, while simultaneously reading the pre-configured medical order-node mapping relationship and node dependency relationship.

[0059] The patient visit identifier is a data identifier that distinguishes a patient's current medical visit. It can be formed by a visit code, a medical card identifier, an outpatient serial number, or a combination thereof. In one embodiment, the patient visit identifier consists of a patient identifier and a visit batch identifier. The patient identifier distinguishes individual patients, and the visit batch identifier distinguishes different outpatient visits for the same patient. The companion robot can read the visit code via a scanning component or receive the medical card identifier input by the patient via a human-computer interaction module. After reading the patient visit identifier, the companion robot does not store the complete medical order content locally. Instead, it sends the patient visit identifier to the medical order node parsing module, which then calls the medical order system interface to obtain the corresponding currently valid medical order.

[0060] The currently valid medical order refers to a medical order record in the medical order system that is associated with the patient's visit identifier, is in effect, and has not yet been revoked. The currently valid medical order may include examination orders, laboratory orders, prescription orders, and follow-up visit orders. Each currently valid medical order may include a medical order identifier, medical order type, issuance time, effective time, revocation status, and execution status. The medical order version is used to distinguish the set of medical orders before and after addition, modification, or revocation during the same visit. In one embodiment, each time the medical order system receives an addition, modification, or revocation operation from a doctor on the set of medical orders, it updates the medical order version and associates the updated medical order version with the current set of valid medical orders.

[0061] The order-node mapping relationship records the correspondence between order types and outpatient process nodes. These outpatient process nodes include check-in nodes, sign-in nodes, doctor consultation nodes, payment nodes, appointment nodes, examination nodes, blood collection nodes, medication dispensing nodes, and report retrieval nodes. A currently valid order can be matched with one or multiple outpatient process nodes. For example, a blood test order can correspond to the payment node, blood collection check-in node, blood collection node, and report retrieval node; an imaging examination order can correspond to the payment node, examination appointment node, examination sign-in node, imaging examination node, and report retrieval node. The order-node mapping relationship can be configured according to order type, executing department, cost status, and report retrieval method, and the version field can distinguish mapping relationships within different effective time intervals.

[0062] The node dependency relationship represents the pre-constraints between multiple outpatient process nodes; the node dependency relationship may include the pre-node identifier, the post-node identifier, the pre-node completion status, and the dependency activation condition. For example, the pre-nodes of the imaging examination node may include the payment node and the examination check-in node; the pre-nodes of the medication dispensing node may include the doctor's consultation node and the payment node; the pre-nodes of the report acquisition node may include the corresponding examination node or blood collection node. The medical order node parsing module first matches the direct nodes corresponding to each currently valid medical order according to the medical order-node mapping relationship, and then reads the node dependency relationship of each direct node; when the pre-node in the node dependency relationship is not yet included in the matched nodes, the pre-node is added to the outpatient process node being processed.

[0063] The historical completion records are derived from medical visit log data and can be returned by the billing system, queuing system, examination and testing system, pharmacy system, and self-service terminal, respectively. Each historical completion record includes a patient visit identifier, outpatient process node identifier, task instance identifier, completion time, medical order version, and execution result. The medical order node parsing module compares the historical completion records with the matched outpatient process nodes. When the medical order version in the historical completion record matches the current medical order version, and the execution result of the corresponding outpatient process node is "completed," the outpatient process node is excluded from the nodes of pending task generation. When the medical order version corresponding to the historical completion record is earlier than the current medical order version, the medical order node parsing module compares the old version and the current version based on the changes in the medical order. Only when the completion result of the old version remains valid for the current version is the corresponding outpatient process node excluded.

[0064] In one implementation, a task instance is an executable object formed by an outpatient process node in response to the patient's visit identifier. Each task instance includes a task instance identifier, a patient's visit identifier, a source medical order identifier, a medical order version, an outpatient process node identifier, a preceding node identifier, and a task execution status. The task instance identifier can be formed based on the patient's visit identifier, the medical order identifier, the outpatient process node identifier, and the generation time. When the same outpatient process node is triggered by multiple currently valid medical orders, the medical order node parsing module matches the medical order identifier and the outpatient process node identifier, forming a task instance with nodes that are allowed to be executed together, and associating multiple source medical order identifiers with this task instance. For outpatient process nodes that are not allowed to be executed together, separate task instances are generated.

[0065] The task execution status includes pending execution, delegated, received, executing, completed, execution failed, pending migration, and invalid. When a task instance is generated, the medical order node parsing module initializes the task execution status based on node dependencies; task instances without incomplete prerequisite nodes are initialized as pending execution, while task instances with incomplete prerequisite nodes remain pending execution and are associated with the corresponding prerequisite node identifier. The task execution status is updated in subsequent steps S300 and S400 based on task issuance, terminal receipt of acknowledgments, and terminal execution results, and serves as the basis for classifying completed nodes, executing nodes, and pending execution nodes in step S500.

[0066] This step can be triggered by a patient's initial entry into the companion robot system or by a notification of a change in the medical order version issued by the medical order system. Upon initial triggering, the medical order node parsing module establishes a patient's visit task. When triggered by a change in the medical order version, the module reads existing task instances and currently valid medical orders, re-executes the medical order-node matching, and generates new, retained, or revoked outpatient process nodes. For patient visits where no currently valid medical order is found, the module generates a medical order data missing record and keeps the current patient's visit task in a pending confirmation state. For medical orders where no corresponding item exists in the medical order-node mapping relationship, the original fields of the medical order are retained, a mapping missing record is generated, and a corresponding task instance is not directly generated.

[0067] When conflicting historical completion records returned from multiple data sources occur, the medical order node parsing module compares the source, medical order version, and generation time of each historical completion record. If both completed and failed execution records exist for the same task instance, the module prioritizes reading the execution result that matches the current medical order version and has a later generation time. If a consistent result still cannot be formed, the task execution status remains "pending confirmation," and the conflicting historical completion records are associated with the task instance for subsequent re-querying. If the medical order version field is missing or multiple medical order versions are simultaneously in effect, the medical order node parsing module does not overwrite existing task instances but generates version conflict records and queries again based on the effective time returned by the medical order system.

[0068] In one specific implementation, after the companion robot reads the patient's medical code, the medical order node parsing module obtains an imaging examination order and a prescription order. The imaging examination order corresponds to a payment node, an examination appointment node, an examination check-in node, an imaging examination node, and a report retrieval node; the prescription order corresponds to a payment node and a medication pickup node. Historical completion records indicate that the patient has completed the payment node for this version of the medical order. The medical order node parsing module merges duplicate payment nodes and excludes them based on historical completion records, generating task instances for the examination appointment node, examination check-in node, imaging examination node, report retrieval node, and medication pickup node respectively. The imaging examination node is associated with the examination check-in node as a preceding node, and the medication pickup node is associated with the prescription order and the completed payment result.

[0069] This step ultimately generates a patient visit task, a set of required nodes, task instances, and task execution status. The set of required nodes includes multiple outpatient process nodes not excluded from historical completion records and their task instance identifiers. The patient visit task associates the patient visit identifier, the medical order version, and multiple task instances. The set of required nodes, node dependencies, task instances, and task execution status are sent to S200. S200 limits the scope of node status record acquisition according to the set of required nodes and generates a target node access sequence based on the node dependencies.

[0070] S200. Obtain the node status records of the set of nodes that must be visited, verify the validity of the status and generate a node status snapshot; sort the set of nodes that must be visited according to the node dependency relationship and the node status snapshot, and generate a target node access sequence.

[0071] This step is executed by the node status processing module and the node access sequence generation module. The node status processing module receives the set of mandatory nodes, task instances, task execution status, and node dependencies formed in S100, and obtains node status records from the queuing and calling system, examination appointment system, department status monitoring unit, and terminal capability management module according to the outpatient process node identifiers in the set of mandatory nodes. The node access sequence generation module receives the node status snapshot formed by the node status processing module and uses the node status snapshot, node dependencies, and node time windows as sorting inputs.

[0072] The node status record represents the operational status of an outpatient process node at a given time, including the current queue length, average processing time, current node occupancy, available node capacity, status collection time, and status validity period. The current queue length indicates the number of waiting tasks that have entered the outpatient process node; the average processing time can be generated based on the processing time of multiple task instances completed by the node during the current business period, or it can be directly provided by the node's business system; the current node occupancy indicates the number of tasks currently being served or reserved by the node; and the available node capacity indicates the number of tasks the node can still receive during the corresponding time period.

[0073] The status acquisition time represents the time when the node status record is generated or returned by the data source; the status validity period represents the time range within which the node status record can participate in the current round of access sequence sorting. Different outpatient process nodes can be configured with different status validity periods; blood collection nodes and payment nodes with frequent queue status changes can be configured with shorter status validity periods, while imaging examination nodes with fixed appointment times can be configured with longer status validity periods. In one embodiment, the status validity period is read by the node status processing module according to the node type; in another embodiment, the status validity period is returned by the node business system along with the node status record.

[0074] The node status processing module compares the current system time with the status acquisition time, and compares the time difference between the two with the status validity period. When the time difference does not exceed the status validity period, the corresponding node status record is marked as meeting the status validity condition. When the time difference exceeds the status validity period, the corresponding node status record is marked as invalid, and a new status acquisition request is sent to the data source of that node. The reacquired node status record continues to be verified in the same way, and after successful verification, it is written into the current round of node status snapshot.

[0075] The node status snapshot is a collection of multiple node status records used in the same round of target node access sequence generation process. In this embodiment, the node status snapshot technology is implemented by using the same status acquisition round for multiple outpatient process nodes in the set of mandatory nodes, and writing a snapshot identifier, patient visit identifier, medical order version, multiple node status records, and snapshot generation time into the snapshot. After generating the node status snapshot, the node status processing module associates the node status snapshot with the medical order version generated by S100; when the medical order version changes subsequently, S500 can identify the range of node statuses used in the original target node access sequence based on this association.

[0076] When node status records come from multiple data sources, the node status processing module aligns them according to the outpatient process node identifier and status collection time. When multiple status records exist for the same outpatient process node, the most recent valid record is read. If the current occupancy and available capacity of a node conflict within the same collection period, the node status processing module marks the node as having a status conflict and retrieves the node capacity and current service quantity from the node business system. Before the status conflict is resolved, the node does not participate in the priority ranking of the candidate access sequence in this round, but remains in the set of mandatory nodes.

[0077] The node access sequence generation module first sorts the set of mandatory nodes according to the node dependencies, forming multiple candidate access sequences; each candidate access sequence's subsequent nodes are arranged after its incomplete preceding nodes. For multiple outpatient process nodes without mutual dependencies, different arrangements of candidate access sequences can be formed. The node access sequence generation module further obtains the node time window; the node time window includes the outpatient process node's opening time, appointment start time, appointment end time, or report availability time. If a node in a candidate access sequence has an expected arrival time that does not fall within the corresponding node's time window, that candidate access sequence is excluded from the current candidate access sequence.

[0078] The node access sequence generation module also filters candidate access sequences based on resource occupancy constraints. These constraints are formed based on the current node occupancy and available node capacity. When the available capacity of a node within the expected arrival time period corresponding to a candidate access sequence is 0, the corresponding node is recorded as having a resource conflict, and the candidate access sequence is either shifted or excluded. The expected arrival time period can be formed based on the node information of adjacent outpatient process nodes and the current node's completion time. This step does not limit the specific path calculation method; it only requires that the preceding and following nodes within the same candidate access sequence have a corresponding expected arrival order.

[0079] For multiple candidate access sequences filtered through node time windows and resource occupancy constraints, the node access sequence generation module generates candidate waiting times for each outpatient process node based on the current queue length and average processing time. The candidate waiting time technical feature is implemented by calculating the corresponding relationship between the current queue length and average processing time according to the node's service capacity. The node access sequence generation module uses the candidate waiting times, current node occupancy, and available node capacity of multiple outpatient process nodes in each candidate access sequence as sorting criteria to rank the filtered candidate access sequences, and records the top-ranked candidate access sequence as the target node access sequence.

[0080] In one implementation, when multiple candidate access sequences have the same sorting result, the node access sequence generation module re-sorts them according to the end time of the node time window, placing the outpatient process nodes with earlier end times first. In another implementation, the arrival times between adjacent outpatient process nodes can be adjusted based on the movement speed records in the patient behavior data. The patient behavior data is only used as the sorting input for the candidate access sequences and does not change the node dependencies or node time window constraints.

[0081] When an outpatient process node in the mandatory node set fails to return a valid node status record, the node status processing module retains the task instance and generates a node status failure record. If no other valid candidate nodes exist, the corresponding task instance remains in a pending execution state, and the node is not sent to S300 as a pending execution node. If other outpatient process nodes satisfy the node dependency relationship exist, the node access sequence generation module can move the status failure node to the next node and generate the target node access sequence using the remaining valid nodes. The node status failure record serves as the trigger input for dynamic reordering in S500.

[0082] In one specific implementation, the set of mandatory nodes output by S100 includes a blood collection node, an ultrasound examination node, and a medication retrieval node. The time window for the ultrasound examination node is 10:00 to 10:30, and the current time is 9:20. The current queue length for the blood collection node is 4, the average processing time is 3 minutes, and the available node capacity is 2. The current queue length for the medication retrieval node is 12, the average processing time is 1 minute, and its preceding node has already been completed. The node access sequence generation module generates two candidate access sequences, "blood collection—ultrasound examination—medication retrieval" and "medication retrieval—blood collection—ultrasound examination," based on node dependencies. After sorting the sequences according to the ultrasound examination node's time window, current queue length, and available node capacity, a target node access sequence associated with the current node status snapshot is generated.

[0083] This step ultimately outputs a node status snapshot and a target node access sequence. The target node access sequence includes a sequence identifier, a medical order version, a node status snapshot identifier, multiple task instance identifiers arranged in execution order, and the sequence's effective status. The node status snapshot and the target node access sequence are sent to S300. S300, based on the target node access sequence, task execution status, and node pre-constraints, reads the task instances that are prioritized and meet the execution conditions, forming nodes to be executed.

[0084] S300: Determine the node to be executed based on the target node access sequence and task execution status, decompose the corresponding task instance into robot guidance task and terminal business sub-task; match the terminal capability record to determine the target terminal, generate task delegation record and issue task.

[0085] This step is executed by the subtask orchestration module, the terminal capability management module, and the task delegation processing module. The subtask orchestration module receives the target node access sequence formed in S200 and the task execution status formed in S100, and reads the currently preceding incomplete task instance according to the order of task instances in the target node access sequence. The subtask orchestration module further reads the node prerequisite constraints associated with the task instance; when the task execution status corresponding to all prerequisite nodes is completed, the outpatient process node corresponding to the task instance is recorded as a node to be executed.

[0086] The technical feature of the pending execution node is implemented by filtering task instances in the target node access sequence whose execution status is pending execution and whose corresponding node's prerequisite constraints have been met. When a task instance at the beginning of the target node access sequence has an incomplete prerequisite node, the subtask orchestration module continues to read subsequent task instances; if a subsequent task instance has no dependency on that prerequisite node, and the node time window and node state snapshot are still valid, it can be recorded as the current pending execution node. The resulting pending execution node remains associated with the target node access sequence and does not modify the arrangement of task instances already recorded in the target node access sequence.

[0087] The subtask orchestration module decomposes the task instance corresponding to the node to be executed into a robot guidance task and a terminal business subtask. The robot guidance task includes a task instance identifier, a patient visit identifier, starting node information, target node information, the sequence version of the target node access sequence, and the robot task execution status. The terminal business subtask includes a task instance identifier, a business type, an authentication method, a medical order version, and a task execution status. For payment nodes, the robot guidance task records the patient's current location and the target payment area, while the terminal business subtask records the payment business type, the patient authentication method, and the corresponding medical order version. For report acquisition nodes, the robot guidance task records the target report printing area, while the terminal business subtask records the report printing business type and the report identifier.

[0088] The terminal capability record is maintained by the terminal capability management module and includes terminal identifier, executable service type, authentication method, payment capability, printing capability, terminal operating status, and resource load data. The executable service type indicates the types of terminal service sub-tasks the terminal can receive; the authentication method indicates the authentication methods supported by the terminal, such as medical code, medical card, or patient identifier; the payment capability indicates the types of fee processing supported by the terminal; and the printing capability indicates whether the terminal has report or invoice printing status. The resource load data may include the number of tasks currently pending execution, the current execution status, and the status collection time.

[0089] The terminal capability management module matches the business type and authentication method of each terminal business subtask with multiple terminal capability records, forming a candidate terminal set for terminals that match both the business type and authentication method. For terminal business subtasks requiring payment or printing capabilities, candidate terminals are further filtered based on the corresponding fields. The terminal capability management module reads the terminal running status of the candidate terminals and excludes those with unavailable or invalid status records based on status validity criteria. For the retained candidate terminals, they are sorted according to resource load data, and the candidate terminals with fewer pending tasks and available running status are identified as target terminals.

[0090] In one implementation, when the resource load data of multiple candidate terminals are identical, the terminal capability management module obtains the current location of the companion diagnostic robot and the node information of the multiple candidate terminals, and re-sorts the multiple candidate terminals according to their corresponding positional relationships; the positional relationships only participate in the sorting after the business capabilities, authentication methods, and terminal operating status have been matched. In another implementation, the estimated completion time can be formed based on the average processing time of each candidate terminal and the number of tasks currently pending execution, and the candidate terminals can be sorted according to the estimated completion time.

[0091] The task delegation processing module issues the robot guidance task to the companion robot and sends a delegation request to the target terminal. The delegation request is bound to a task instance identifier, patient visit identifier, medical order version, terminal business sub-task, delegation validity period, and the sequence version of the target node access sequence. The task delegation processing module generates a task delegation record when sending the delegation request; the task delegation record includes a task instance identifier, target terminal identifier, delegation time, delegation validity period, medical order version, sequence version, and delegation status. After the delegation request is sent, the task execution status is updated from pending to delegated, and the delegation status is recorded as waiting to receive a receipt.

[0092] The task delegation processing module performs task idempotency verification based on the task instance identifier. When multiple delegation requests are generated for the same task instance due to communication retries or repeated triggering, the module queries existing task delegation records. If the target terminal identifier, medical order version, and sequence version in an existing task delegation record match the current delegation request, the current delegation request is associated with the existing task delegation record, and the delegation time or retry count is updated. No new execution tasks with the same task instance identifier are added. If an existing task delegation record has been revoked or has a different sequence version, a new task delegation record is generated according to the currently effective sequence version, while maintaining the association with the original task delegation record.

[0093] This step can also involve the node resource coordination module handling node capacity occupancy for the node to be executed. The node resource coordination module generates an estimated arrival time period based on the current location of the accompanying robot and the node information of the node to be executed; the node information includes the outpatient process node identifier, node location, and node capacity. The node resource coordination module queries existing node occupancy records based on the estimated arrival time period and subtracts the current node occupancy within the corresponding time period from the node capacity to form the available node capacity; when the available node capacity meets the node capacity constraint, a node occupancy record is generated.

[0094] The node occupancy record includes a task instance identifier, an outpatient process node identifier, an estimated arrival time, a resource occupancy lease period, and a node occupancy status. The resource occupancy lease period indicates the time interval during which the node occupancy record remains valid. When the accompanying robot arrives at the target node within the resource occupancy lease period, the node occupancy status is updated from "booked" to "arrived." If the accompanying robot does not arrive within the resource occupancy lease period, the node resource coordination module updates the corresponding node occupancy status to "expired" and reclaims the available node capacity corresponding to that occupancy record. For multi-capacity outpatient process nodes, occupancy is deducted according to node capacity; a single occupancy status is not set for the entire outpatient process node.

[0095] When the candidate terminal set is empty, the terminal capability management module generates a terminal capability mismatch record and keeps the terminal business sub-task in a pending execution state. When the target terminal becomes unavailable before the entrustment request is sent, the task entrustment processing module does not issue the entrustment request and returns to the terminal capability management module to re-select candidate terminals. When the companion diagnosis robot task execution status is unavailable, the sub-task orchestration module retains the terminal business sub-task and task instance identifier, and generates a robot task exception record. The robot task exception record and incomplete task instances are entered into S500 for dynamic rearrangement.

[0096] In one specific implementation, the node to be executed is the payment node; the subtask orchestration module decomposes the task instance into a robot guidance task to the payment area and a terminal business subtask for fee processing. The terminal capability management module reads the terminal capability records of three self-service terminals; the first terminal does not support the current authentication method, the second terminal supports the target business but its terminal operating status is unavailable, and the third terminal supports the target business, authentication method, and payment capability, and its resource load data is available. The terminal capability management module identifies the third terminal as the target terminal; the task delegation processing module issues a robot guidance task to the companion robot and sends a delegation request to the third terminal to bind the task instance identifier and the medical order version, forming a task delegation record.

[0097] This step ultimately outputs the robot guidance task, terminal service sub-task, target terminal, task delegation record, and optional node occupancy record. The task delegation record and its delegation status are sent to S400. The robot guidance task is executed by the companion robot and returns guidance feedback. The terminal service sub-task is received by the target terminal and returns a terminal receipt and terminal execution result. The node occupancy record enters S400 along with the task instance and is released or reclaimed when the task is completed, the task is migrated, or the resource occupancy lease expires.

[0098] S400: The receiving terminal receives the receipt and the terminal execution result, and updates the task execution status; if the target terminal does not return the terminal receipt or the terminal execution result is execution failure, the task instance identifier is maintained, the terminal capability record is re-matched, and a task migration record is generated.

[0099] This step is performed by the execution feedback processing module and the task migration module. The execution feedback processing module receives the task delegation record generated by S300, and simultaneously receives the guidance feedback returned by the companion robot, the terminal reception receipt returned by the target terminal, and the terminal execution result. The guidance feedback includes the task instance identifier, companion robot identifier, arrival node identifier, arrival time, and robot task execution status. The terminal reception receipt includes the task instance identifier, target terminal identifier, reception time, and reception status. The terminal execution result includes the task instance identifier, execution result status code, completion time, and output result identifier.

[0100] The execution feedback processing module first matches the terminal's received receipt with the task delegation record generated by S300 based on the task instance identifier. If the match is successful and the receiving status is "received," the delegation status of the task delegation record is updated to "received," and the task execution status of the corresponding task instance is updated from "delegated" to "received." When the target terminal returns to the "in execution" status after starting to execute the terminal service sub-task, the execution feedback processing module updates the task execution status to "in execution." When the target terminal returns the "completed" status and the corresponding output result identifier, the task execution status is updated to "completed," and the terminal execution result is associated with the task instance.

[0101] For payment nodes, the output result identifier corresponds to the fee processing record; for report acquisition nodes, the output result identifier corresponds to the report printing record; for check-in or sign-in nodes, the output result identifier corresponds to the check-in record or sign-in record. The execution feedback processing module does not directly update the terminal business sub-task to "completed" based on the accompanying robot reaching the target location; only when the task instance identifier of the terminal execution result matches the task delegation record, and the execution result status code indicates completion, will the corresponding task instance be updated to "completed".

[0102] The validity period of the task delegation record serves as the verification basis for the terminal receiving the receipt. If the current system time exceeds the validity period of the delegation and the target terminal does not return a receipt, the execution feedback processing module generates a delegation timeout record, updates the delegation status of the task delegation record to timeout, and updates the task execution status to pending migration. If the target terminal returns a rejection status within the validity period of the delegation, the execution feedback processing module generates a delegation rejection record, and similarly updates the task execution status to pending migration.

[0103] When the target terminal returns an execution failure result, the execution feedback processing module reads the execution result status code and associates it with the corresponding task instance. The execution result status code can indicate authentication failure, payment interface failure, abnormal printing status, terminal unavailability, or business processing timeout. The execution feedback processing module updates the original task delegation record to "revoked" and retains the original task delegation record and its execution result status code, without deleting the original delegation process. If the target terminal updates its terminal running status to "unavailable" during execution, the original task delegation record is revoked in the same manner.

[0104] The task migration module receives task instances with a pending migration status and retains the original task instance identifier. Maintaining the original task instance identifier means using the same task instance identifier to associate the patient's visit identifier, source medical order identifier, and outpatient process node identifier before and after the task migration, without regenerating a replacement task instance. The task migration module excludes the original target terminal from the original candidate terminal set and re-matches the terminal's business sub-tasks with the terminal's capability records. During re-matching, it continues to verify the executable business type, authentication method, payment capability, printing capability, terminal operating status, and resource load data.

[0105] The task migration module determines a replacement terminal based on the re-matching results and sends a new delegation request to the replacement terminal. The new delegation request continues to bind the original task instance identifier, the current medical order version, and the currently effective sequence version. The task migration module generates a task migration record; the task migration record includes the task instance identifier, the original executor, the target executor, the migration reason, the migration time, and the migration status. After the new target terminal returns a receipt, the migration status of the task migration record is updated to "received"; after the new target terminal completes the terminal business sub-task, the task migration record is updated to "completed," and the task execution status is also updated to "completed."

[0106] If no alternative terminal matching the terminal capability conditions is found after re-matching, the task migration module maintains the task execution state as pending migration and generates a terminal capability mismatch record. This terminal capability mismatch record, along with the task migration record, is sent to S500. S500 can either move the pending node to the next node based on the current node's terminal availability status or regenerate an adjusted node access sequence in the updated node status snapshot. If the terminal capability record changes subsequently, the task migration module can perform matching again.

[0107] For repeated terminal receipts and terminal execution results, the execution feedback processing module performs task idempotency verification based on the task instance identifier, target terminal identifier, and sequence version. Receipts that are completely consistent with existing execution results are associated with existing task delegation records, and the task execution status is not updated repeatedly. When the same task instance receives completion results from multiple different terminals, the execution feedback processing module queries the effectiveness status of the corresponding task delegation record, only accepts the completion results corresponding to the currently effective task delegation record, and writes the remaining results into the execution result conflict record.

[0108] When the target terminal returns a delayed receipt after a timeout, and the task migration module has already sent a new delegation request to the replacement terminal, the execution feedback processing module compares the delegation status of the original task delegation record and the new task delegation record. If the original task delegation record has been revoked, the delayed receipt is marked as invalid, and the task execution status is not restored to received. If the original terminal has already generated a non-repeatable business result before the delegation is revoked, the execution feedback processing module compares the business result with the execution status of the replacement terminal and temporarily updates the task instance to pending confirmation until the business system returns a unique and valid execution result.

[0109] The node resource coordination module updates the node occupancy record based on the task execution status generated by S400. When the task execution status is "completed," the node occupancy status is updated to "released," and the corresponding node's available capacity is restored. If a robot task anomaly occurs and the accompanying robot fails to reach the target node, the corresponding node occupancy record is revoked. When the resource occupancy lease expires, the node occupancy record is updated to "expired," and the node's available capacity is reclaimed. When a task migration only changes the target terminal and does not change the outpatient process nodes, the original node occupancy record can be maintained. When migrating to a different outpatient process node, the original node occupancy record is released, and a new node occupancy record is generated for the new node.

[0110] In one specific implementation, the target terminal is a report printing terminal. The target terminal has already returned a terminal receipt, but returned an execution result status code indicating a printing status error when executing the report printing task. The execution feedback processing module updates the task execution status to "pending migration" and cancels the original task delegation record. The task migration module retains the task instance identifier of the original report acquisition task, excludes the original target terminal from the candidate terminal set, and selects another terminal with printing capabilities and an available terminal running status as a replacement terminal. After the replacement terminal completes printing, both the task migration record and the task execution status are updated to "completed."

[0111] This step ultimately outputs the updated task execution status, terminal execution result, task migration record, delegation timeout record, delegation rejection record, or execution result conflict record. The task execution status is used by S500 to divide nodes into completed nodes, executing nodes, and pending nodes. The task migration record is directly used as the trigger input for S500, and the terminal execution result is inherited by S500 as the execution result of the completed node. When the task execution status is completed and there are no changes in the medical order version or node status failure, the system returns to S300 according to the target node access sequence and reads the next task instance that satisfies the node's preconditions.

[0112] When S500 detects changes in medical order versions, node status failures, or task migration records, it inherits the execution results of completed nodes, dynamically rearranges the nodes to be executed, and generates adjusted node access sequences and sequence version records.

[0113] This step is performed by the dynamic reordering module. The dynamic reordering module receives the target node access sequence and node state snapshot formed in S200, the task execution status and task migration record updated in S400, and also receives the medical order version change notification sent by the medical order system and the node state failure record generated by the node state processing module. When any of the medical order version change, node state failure, or task migration record occurs, the dynamic reordering module reads the currently effective target node access sequence and records it as the original sequence version.

[0114] The changes in the medical order version include the addition, modification, or revocation of currently valid medical orders. After receiving the notification of the medical order version change, the dynamic reordering module calls the medical order node parsing module to re-obtain the currently valid medical orders, the medical order-node mapping relationship, and the node dependency relationship according to the processing method of S100, forming the outpatient process node corresponding to the current medical order version. The node status failure includes the node status snapshot associated with the target node access sequence exceeding the status validity period, the node available capacity of the outpatient process node becoming 0, or the running status of the outpatient process node becoming unavailable. The task migration record indicates that the original target terminal can no longer execute the corresponding terminal business sub-task, and the execution subject of the task instance has changed.

[0115] The dynamic reordering module categorizes task instances in the original target node access sequence into completed nodes, running nodes, and pending nodes based on their execution status. Completed nodes correspond to completed task instances; running nodes correspond to received or currently executing task instances; and pending nodes correspond to tasks awaiting execution, delegated but not yet received, awaiting migration, or whose preceding nodes have not yet completed. The dynamic reordering module writes the task instance identifiers corresponding to each type of node into the current reordering record.

[0116] For completed nodes, the dynamic reordering module retains their task instance identifier, medical order version, and execution result, and does not re-add the completed node to the remaining node set. When a change in the medical order version causes the medical order corresponding to a previously completed node to be revoked, the dynamic reordering module still retains the original execution result and completion time, and simultaneously associates the task instance with the revoked medical order version for use in structured medical process records. When a change in the medical order version requires the same outpatient process node to be re-executed, the medical order node parsing module generates a new task instance based on the new source medical order identifier; the previously completed task instance is not directly restored to pending execution.

[0117] For nodes in execution, the dynamic reordering module processes them according to the execution status inheritance conditions. These conditions may include the current task instance's medical orders remaining valid in the new version of the medical orders, the executing entity still being available, the node's time window not having expired, and the current business allowing continued execution. When all the above conditions are met, the node in execution and its task delegation record are retained, and it is not added to the reordered set of remaining nodes. If a medical order is revoked, the node stops service, or the task delegation record becomes invalid, the dynamic reordering module revokes the corresponding task delegation record, updates the task execution status to invalid or pending execution, and releases the corresponding node's occupied record.

[0118] For nodes awaiting execution, the dynamic reordering module reads the set of outpatient process nodes corresponding to the current medical order version. If the original node awaiting execution still exists in the current medical order version, its task instance and task execution status are retained. If the medical order corresponding to the original node awaiting execution has been revoked, the task instance is updated to an invalid state, and its unused task delegation record is revoked. When a new outpatient process node is added to the current medical order version, the medical order node parsing module generates a new task instance and supplements the preceding nodes according to the node dependencies.

[0119] The dynamic reordering module forms a set of remaining nodes from the outpatient process nodes generated by the new medical order version, the retained pending execution nodes, and the nodes that need to be re-executed due to execution interruption. This set of remaining nodes includes task instance identifiers, outpatient process node identifiers, medical order versions, task execution status, and node dependencies. Completed nodes are not included in this set of remaining nodes, but their completion status can serve as the prerequisite for subsequent nodes in the set. Therefore, examination nodes that depend on completed payment nodes can continue to participate in the sorting process without regenerating payment tasks.

[0120] The dynamic reordering module sends a status update request to the node status processing module. The node status processing module then retrieves the node status records corresponding to the remaining node set according to the processing method of S200, verifies the validity of the status, and generates an updated node status snapshot. The dynamic reordering module generates multiple candidate access sequences based on the remaining node set, node dependencies, node time windows, and the updated node status snapshot. It then filters the candidate access sequences based on resource consumption constraints and sorts them according to the current queue length, average processing time, current node occupancy, and available node capacity to form an adjusted node access sequence.

[0121] The adjusted node access sequence includes an adjusted sequence identifier, an adjusted sequence version, the current medical order version, an updated node status snapshot identifier, multiple task instance identifiers arranged in execution order, and their effective status. The dynamic reordering module generates a sequence version record; this record includes the original sequence identifier, original sequence version, adjusted sequence identifier, adjusted sequence version, trigger event identifier, effective time, and original sequence failure status. Completed nodes corresponding to the original sequence version and nodes in execution that meet the execution status inheritance conditions retain their original execution results, while nodes to be executed corresponding to the original sequence version are updated to an failure status.

[0122] After receiving the sequence version record, the task delegation processing module queries the task delegation record corresponding to the original sequence version. If the delegation status is "awaiting receipt" and the corresponding task instance has already entered another position in the adjusted node access sequence, the original task delegation record is revoked. When the target terminal subsequently returns the receipt corresponding to the original sequence version, the execution feedback processing module marks the receipt as invalid based on the sequence version field. After the adjusted node access sequence takes effect, the task delegation processing module only issues new robot guidance tasks and terminal business sub-tasks based on the adjusted sequence version.

[0123] In one implementation, node status failure is triggered by the node status snapshot exceeding its validity period. The dynamic reordering module does not directly use the original node status snapshot for sorting; instead, it requests the node status processing module to re-acquire multiple node status records from the remaining node set. In another implementation, if the task migration record only changes the target terminal within the same outpatient process node, and the node's time window and node occupancy status remain valid, the dynamic reordering module can retain the outpatient process node's position in the target node access sequence, updating only the task delegation record and the execution subject. If the task migration causes the expected completion time to cross the node time window of the next node, then the nodes to be executed are dynamically reordered.

[0124] When the notification of a change in a medical order version and the terminal execution result arrive simultaneously, the dynamic reordering module processes them according to the event generation time and task execution status. If the completion time of the terminal execution result is earlier than the effective time of the medical order version, the corresponding task instance is assigned to the completed node. If the completion time of the terminal execution result is later than the effective time of the medical order version, and the original medical order has been revoked, the execution result is written to the execution result conflict record, and the task instance is updated to pending confirmation. Task instances pending confirmation are not directly added to the remaining node set until the medical order system and the terminal business system return a consistent status.

[0125] When a new medical order version change notification is received during the generation of the adjusted node access sequence, the dynamic reordering module compares the currently processed medical order version with the version in the new notification. If the new notification version is newer, the generation process of the currently ineffective adjusted node access sequence is stopped, the intermediate records that have already been formed are retained, and the remaining node set is regenerated according to the new medical order version. The adjusted node access sequence that has already taken effect is not overwritten, but is written into the new sequence version record as the original sequence version for the next round of dynamic reordering.

[0126] In one specific implementation, the patient has completed the payment node, the ultrasound examination task has been received by the target terminal, and the doctor has added a blood collection order. Upon receiving the order version change notification, the dynamic reordering module classifies the payment node as a completed node and retains the payment processing record; the ultrasound examination node meets the execution state inheritance conditions and remains in the execution state; the newly added blood collection order forms a blood collection reporting node and a blood collection node through the order-node mapping relationship, and supplements the corresponding node dependencies. The dynamic reordering module forms the blood collection reporting node, the blood collection node, and the pending medication collection nodes retained in the original sequence into a set of remaining nodes, obtains an updated snapshot of the node state, and generates an adjusted node access sequence and sequence version record.

[0127] In another specific implementation, while the patient is traveling to the report retrieval node, the original target report printing terminal experiences a printing status malfunction, and S400 generates a task migration record. The dynamic reordering module reads the original target node access sequence, retains the completed inspection nodes and their execution results, preserves the report retrieval task instance identifier, and regenerates the subsequent node order based on the node information of the alternative terminal and the updated resource load data. Report retrieval tasks that have not yet been executed in the original sequence version are updated to an invalid state, and the same task instance in the adjusted sequence version is associated with a new task delegation record.

[0128] This step ultimately outputs the adjusted node access sequence and sequence version record. The adjusted node access sequence returns to S300, where the subtask orchestration module determines new nodes to be executed based on the adjusted sequence version and the latest task execution status, and generates corresponding robot guidance tasks and terminal business subtasks. The sequence version record, task migration record, completed node execution results, and multiple task execution statuses can be written into the structured medical treatment process record. The structured medical treatment process record associates the doctor's order version, sequence version, task delegation record, task migration record, and terminal execution result in this medical treatment according to the patient's medical treatment identifier and medical treatment batch identifier, for subsequent status queries and medical treatment log data archiving.

[0129] Example 2: Figure 2 A structural block diagram of an outpatient companion robot system based on multimodal perception and intelligent decision-making according to an embodiment of the present invention is shown. Figure 2 As shown, the structure may include:

[0130] The medical order node parsing module 01 is used to obtain the patient's visit identifier, currently valid medical orders, medical order version, medical order-node mapping relationship, and node dependency relationship. Based on the medical order-node mapping relationship and the node dependency relationship, it generates a set of mandatory nodes, task instances, and task execution status. Specifically, the medical order node parsing module receives the patient's visit identifier submitted by the companion robot and obtains the corresponding currently valid medical orders and medical order version based on the patient's visit identifier. The currently valid medical orders include examination orders, laboratory orders, or prescription orders associated with the current visit and in effect. The medical order version is used to distinguish the set of medical orders before and after addition, modification, or cancellation. The medical order node parsing module matches the medical order type of the currently valid medical orders with the medical order-node mapping relationship to obtain the corresponding outpatient process node. Then, based on the node dependency relationship, it queries the predecessor nodes of each outpatient process node and adds the predecessor nodes not yet included in the matching results to the corresponding outpatient process node. The medical order node parsing module generates task instances based on the patient's visit identifier, medical order version, and outpatient process node identifier, and registers the task execution status of each task instance as pending execution, in execution, completed, failed execution, pending migration, or expired. When the same outpatient process node is triggered by multiple currently valid medical orders, medical orders that can be merged are associated with the same task instance, while medical orders that cannot be merged are formed into separate task instances. When a currently valid medical order lacks a corresponding medical order-node mapping relationship, the medical order node parsing module retains the currently valid medical order and its version, but does not generate a corresponding task instance. When there is a conflict in the medical order version, the currently effective medical order version is read according to its effective time, and the original task instance maintains its original task execution status. The medical order node parsing module provides the generated set of mandatory nodes, task instances, and task execution status to the node status processing module, the node access sequence generation module, and the subtask orchestration module, respectively. The set of mandatory nodes limits the scope of node status record acquisition, and the task instances and task execution status serve as inputs for subsequent task decomposition and status updates.

[0131] The node status processing module 02, connected to the medical order node parsing module, is used to obtain the node status records of the mandatory node set, verify the validity of the node status records, and generate a node status snapshot. Specifically, the node status processing module receives the mandatory node set output by the medical order node parsing module and obtains the corresponding node status records according to the outpatient process node identifiers in the mandatory node set. The node status records include the current queue length, average processing time, current node occupancy, available node capacity, status collection time, and status validity period. The node status processing module compares the current time with the status collection time and compares the time difference between the two with the status validity period. If the time difference does not exceed the status validity period, the corresponding node status record is registered as valid; if the time difference exceeds the status validity period, the corresponding node status record is registered as invalid, and the node status record of the outpatient process node is re-obtained. When multiple sources return node status records for the same outpatient process node, the node status processing module associates them according to the outpatient process node identifier and status collection time, and reads the most recent valid record. When there is a conflict between the current occupancy of a node and its available capacity, the corresponding node status record is registered as a status conflict and is not written into the current node status snapshot. The node status processing module encapsulates multiple node status records that meet the status validity conditions into a node status snapshot, and associates the patient's visit identifier, medical order version, required node set, and snapshot generation time into the node status snapshot. The node status snapshot is provided to the node access sequence generation module as the node status input when sorting the required node set, and is also provided to the dynamic reordering module as the input for regenerating and adjusting the node access sequence after a node status record becomes invalid.

[0132] The node access sequence generation module 03, connected to the medical order node parsing module and the node status processing module, is used to sort the set of mandatory nodes based on the node dependencies and the node status snapshots to generate a target node access sequence. Specifically, the node access sequence generation module receives the set of mandatory nodes and node dependencies from the medical order node parsing module, and receives node status snapshots from the node status processing module. Based on the node dependencies, the node access sequence generation module arranges outpatient process nodes with prerequisite relationships in the order of prerequisite nodes first and subsequent nodes last, and forms multiple candidate access sequences for outpatient process nodes without mutual dependencies. The node access sequence generation module reads the current queue length, average processing time, current node occupancy, and available node capacity corresponding to each outpatient process node in the candidate access sequence. When a node status record is invalid or the available node capacity is zero, the corresponding outpatient process node is registered as a node resource conflict, and the candidate access sequence containing the node resource conflict is moved to the next position or excluded from the current sorting range. When multiple candidate access sequences all meet the node dependency relationship, the node access sequence generation module sorts the candidate access sequences according to the current queue length, average processing time, current node occupancy, and available node capacity of each outpatient process node, generating a target node access sequence. The target node access sequence is associated with the medical order version, node status snapshot, multiple task instance identifiers arranged in access order, and sequence validity status. If a node status record is missing in a candidate access sequence, the node access sequence generation module retains the corresponding task instance but does not use it as the current node to be executed; the remaining task instances with valid node status records and meeting the node dependency relationship continue to participate in the sorting. The node access sequence generation module provides the target node access sequence to the subtask orchestration module and provides the association relationship between the target node access sequence and the node status snapshot to the dynamic reordering module.

[0133] The subtask orchestration module 04, connected to the medical order node parsing module and the node access sequence generation module, is used to determine the node to be executed based on the target node access sequence and the task execution status, and decompose the task instance corresponding to the node to be executed into robot guidance tasks and terminal business subtasks. Specifically, the subtask orchestration module receives the target node access sequence, multiple task instances and their corresponding task execution statuses, and reads incomplete task instances according to the order of task instances recorded in the target node access sequence. The subtask orchestration module queries the predecessor nodes of each incomplete task instance according to the node dependency relationship; when the task execution status corresponding to the predecessor node is completed, the outpatient process node corresponding to the incomplete task instance is registered as a node to be executed; when the predecessor node is not yet completed, the original task execution status of the task instance is retained, and the system continues to query subsequent task instances without incomplete predecessor nodes. The subtask orchestration module decomposes task instances based on the outpatient process node type corresponding to the node to be executed. Specifically, the robot-guided task is associated with a task instance identifier, patient visit identifier, target node information, and task execution status; the terminal business subtask is associated with a task instance identifier, business type, authentication method, medical order version, and task execution status. When the node to be executed does not contain terminal business, the subtask orchestration module generates a corresponding robot-guided task and keeps the terminal business subtask empty. When the node to be executed includes check-in, payment, authentication, or printing services, a robot-guided task and a terminal business subtask are generated respectively. The subtask orchestration module provides the terminal business subtask to the terminal capability management module and provides the robot-guided task and task instance identifier to the task delegation and execution feedback processing module. When the task execution status changes or the adjusted node access sequence takes effect, the subtask orchestration module rereads the currently effective target node access sequence or the adjusted node access sequence and determines a new node to be executed.

[0134] The terminal capability management module 05, connected to the subtask orchestration module, is used to match the terminal service subtasks with terminal capability records to determine the target terminal. Specifically, the terminal capability management module receives the terminal service subtasks output by the subtask orchestration module and reads multiple terminal capability records. These records include terminal identifier, executable service type, authentication method, payment capability, printing capability, terminal operating status, and resource load data. The terminal capability management module matches the service type and authentication method in the terminal service subtasks with the multiple terminal capability records. If the terminal service subtask includes a payment service, it continues to match the payment capability; if it includes a printing service, it continues to match the printing capability. The matching results form candidate terminals. The terminal capability management module excludes terminals whose operating status is unavailable or invalid from the candidate terminals, then sorts the remaining candidate terminals according to the resource load data, and registers the top-ranked candidate terminals as the target terminals. When multiple candidate terminals have the same resource load data, they are reordered according to the node information corresponding to the candidate terminals. If no candidate terminal matches the terminal capability record, the terminal service sub-task maintains its original task execution state, the terminal capability management module does not generate a target terminal, and provides the unmatched result to the task migration module and the dynamic reordering module. The terminal capability management module provides the target terminal's terminal identifier, the corresponding terminal capability record, and the terminal service sub-task to the task delegation and execution feedback processing module. When the terminal's running state changes during the target terminal's execution, the terminal capability record is updated, and the updated terminal running state is sent to the task delegation and execution feedback processing module and the task migration module.

[0135] The task delegation and execution feedback processing module 06, connected to the subtask orchestration module and the terminal capability management module, is used to issue the robot guidance task to the companion robot, issue the terminal business subtask to the target terminal, generate a task delegation record, and update the task execution status based on the terminal reception receipt and terminal execution result returned by the target terminal. Specifically, the task delegation and execution feedback processing module receives the robot guidance task and terminal business subtask output by the subtask orchestration module, and receives the target terminal output by the terminal capability management module. The task delegation and execution feedback processing module associates the robot guidance task and the terminal business subtask according to the task instance identifier, sends the robot guidance task to the companion robot, and sends a delegation request to the target terminal binding the task instance identifier, medical order version, and terminal business subtask. When the delegation request is sent, a task delegation record is generated; the task delegation record includes the task instance identifier, target terminal identifier, delegation time, delegation validity period, medical order version, and delegation status, and updates the corresponding task execution status from pending execution to delegated. The task delegation and execution feedback processing module receives a terminal receipt from the target terminal. It matches the terminal receipt with the task delegation record based on the task instance identifier and the target terminal identifier. If the match is successful and the receipt status is valid, the delegation status is updated to "received," and the task execution status is also updated to "received." When the target terminal returns the execution result, the task execution status is updated based on the task instance identifier and execution result status code in the execution result. If the execution result is "complete," the task execution status is updated to "completed," and the execution result is retained. If the execution result is "failed," the task execution status is updated to "pending migration." If the target terminal fails to return a terminal receipt within the delegation validity period, the task delegation record is updated to a timeout status, and the task execution status is updated to "pending migration." Duplicate delegation requests with the same task instance identifier are associated with existing task delegation records and do not generate duplicate task instances. If the original task delegation record has been revoked, late terminal receipts are registered as invalid. The task delegation and execution feedback processing module provides the task instance to be migrated, the original task delegation record, and the terminal execution result to the task migration module, and provides the updated task execution status to the dynamic reordering module and the subtask orchestration module.

[0136] The task migration module 07, connected to the task delegation and execution feedback processing module and the terminal capability management module, is used to maintain the task instance identifier, re-match the terminal capability record, and generate a task migration record when the target terminal does not return a terminal receipt or the terminal execution result is an execution failure. Specifically, the task migration module receives the task instance to be migrated, the original task delegation record, and the terminal execution result output by the task delegation and execution feedback processing module, and receives the terminal capability record maintained by the terminal capability management module. The task migration module excludes the original target terminal from the re-matching range, keeps the task instance identifier, medical order version, and terminal business sub-task unchanged, and then matches the business type, authentication method, payment capability, or printing capability of the terminal business sub-task with the remaining terminal capability records. Terminals with valid terminal running status in the matching results form a range of alternative terminals, and the target execution entity is determined based on resource load data. After determining the target execution entity, the task migration module updates the original task delegation record to a cancelled state and provides the terminal business subtask, retaining the original task instance identifier, to the task delegation and execution feedback processing module. The task delegation and execution feedback processing module then issues a new delegation request to the target execution entity. The task migration module generates a task migration record; this record associates the original execution entity, the target execution entity, the task instance identifier, the migration reason, and the migration status. When the new target execution entity returns a receipt to the terminal, the migration status is updated. When the new target execution entity returns a completed terminal execution result, both the migration status and the task execution status are updated to "completed." If no target execution entity exists after re-matching, the execution status of the task to be migrated is retained, and the task migration record is provided to the dynamic reordering module. The dynamic reordering module reorganizes the nodes to be executed based on the task migration record. The task migration module also provides the generated task migration record to the task delegation and execution feedback processing module for subsequent matching of terminal receipts and terminal execution results with the currently effective task delegation record.

[0137] The dynamic reordering module 08, connected to the medical order node parsing module, the node status processing module, the task delegation and execution feedback processing module, and the task migration module, is used to dynamically reorder the nodes to be executed when a change in the medical order version, an invalid node status record, or a task migration record is detected. This reordering process inherits the execution results of completed nodes and generates an adjusted node access sequence and sequence version record. Specifically, the dynamic reordering module receives the currently valid medical order and its version from the medical order node parsing module, the node status snapshot and the validity of the node status record from the node status processing module, the task execution status and terminal execution results from the task delegation and execution feedback processing module, and the task migration record from the task migration module. When a change in the medical order version, an invalid node status record, or a task migration record is detected, the dynamic reordering module reads the currently effective target node access sequence and divides the task instances within it into completed nodes, executing nodes, and nodes to be executed based on the task execution status. The dynamic reordering module retains the task instance identifier and terminal execution result of completed nodes, and does not re-add the completed nodes to the pending execution nodes. When the medical order version corresponding to the executing node remains valid and the task delegation record is still in effect, the corresponding task execution status is retained. When the task delegation record has expired, the corresponding task instance is updated to pending execution or expired. The dynamic reordering module retains the pending execution nodes that remain valid according to the current medical order version, excludes the pending execution nodes corresponding to revoked medical orders, and receives the task instances generated by the medical order node parsing module based on the new medical orders. The retained pending execution nodes and the new task instances form a new range of pending execution nodes. The dynamic reordering module calls the valid node state snapshot generated by the node state processing module, and sorts the new range of pending execution nodes according to the node dependencies and the node state snapshot, generating an adjusted node access sequence. At the same time, a sequence version record is generated, which is associated with the original target node access sequence, the adjusted node access sequence, the medical order version, the triggering condition, and the effective status. The dynamic reordering module updates the unexecuted and uninherited task instances in the original target node access sequence to an invalid state, provides the adjusted node access sequence to the subtask orchestration module, and provides the sequence version record to the task delegation and execution feedback processing module; the subtask orchestration module determines new nodes to be executed based on the adjusted node access sequence, and the task delegation and execution feedback processing module identifies the currently effective task delegation record based on the sequence version record.

Claims

1. A method for outpatient companion robots based on multimodal perception and intelligent decision-making, characterized in that, include: S100: Obtain the patient's visit identifier, currently valid medical orders, medical order version, medical order-node mapping relationship, and node dependency relationship; Based on the medical order-node mapping relationship and the node dependency relationship, a set of mandatory nodes, task instances, and task execution status are generated; S200. Obtain the node status records of the set of nodes that must be visited, verify the validity of the status and generate a node status snapshot; sort the set of nodes that must be visited according to the node dependency relationship and the node status snapshot, and generate a target node access sequence; S300: Determine the node to be executed based on the target node access sequence and task execution status, and decompose the corresponding task instance into robot guidance task and terminal business sub-task; The target terminal is determined by matching the terminal capability record, a task delegation record is generated, and the task is issued. S400: The receiving terminal receives the receipt and the terminal execution result, and updates the task execution status; If the target terminal does not return a terminal receipt or the terminal execution result is execution failure, retain the task instance identifier, re-match the terminal capability record and generate a task migration record; When S500 detects changes in medical order versions, node status failures, or task migration records, it inherits the execution results of completed nodes, dynamically rearranges the nodes to be executed, and generates adjusted node access sequences and sequence version records.

2. The method according to claim 1, characterized in that, The generation of the required node set, task instance, and task execution status includes: Based on the medical order-node mapping relationship, match the outpatient process node corresponding to the currently valid medical order; Based on the node dependencies, supplement outpatient process nodes with node prerequisite constraints; Obtain historical completion records and exclude completed nodes from the matched outpatient process nodes in the historical completion records; The task instance is generated for the excluded outpatient process nodes, and the patient visit identifier, the medical order version, the outpatient process node identifier, and the task execution status are associated with the task instance.

3. The method according to claim 1, characterized in that, The node status record includes the current queue length, average processing time, current node occupancy, available node capacity, status collection time, and status validity period. The validity of the status record of each node is determined based on the status acquisition time and the status validity period. Filter the node status records that meet the status validity conditions, generate the node status snapshot, and associate the node status snapshot with the medical order version.

4. The method according to claim 3, characterized in that, The generation of the target node access sequence includes: The set of mandatory nodes is sorted according to the node dependencies to generate multiple candidate access sequences; Obtain the node time window, and filter the candidate access sequence based on the node time window and resource usage constraints; Based on the current queue length, the average processing time, the current node occupancy, and the available node capacity, the filtered candidate access sequences are sorted to determine the target node access sequence, and the target node access sequence is associated with the node state snapshot.

5. The method according to claim 1, characterized in that, The terminal capability record includes executable business types, authentication methods, payment capabilities, printing capabilities, terminal operating status, and resource load data; The service type and authentication method of the terminal service sub-task are matched with the terminal capability record to generate a candidate terminal set; Candidate terminals whose operating states meet the validity conditions are selected from the candidate terminal set; The selected candidate terminals are sorted according to the resource load data to determine the target terminal.

6. The method according to claim 5, characterized in that, The task delegation record includes the task instance identifier, target terminal identifier, delegation time, delegation validity period, medical order version, and delegation status; The task sent to the target terminal includes a delegation request that binds the task instance identifier, the medical order version, and the delegation validity period; When a delegation request with the same task instance identifier is received, the delegation request is associated with an existing task delegation record, and the delegation status is updated.

7. The method according to claim 6, characterized in that, The process of re-matching terminal capability records and generating task migration records includes: If the target terminal fails to return a receipt within the time limit for receiving the assignment, returns a rejection status, the execution result of the terminal is an execution failure, or the terminal's running status is unavailable, the original task assignment record shall be revoked. Maintain the task instance identifier, re-match the terminal service sub-task with the terminal capability record, and determine the alternative terminal; The terminal service subtask is sent to the alternative terminal, and a task migration record is generated that associates the original execution subject, the target execution subject, the task instance identifier, the migration reason, and the migration status.

8. The method according to claim 1, characterized in that, The estimated arrival time is determined based on the robot's current location and the node information of the outpatient process nodes; The available capacity of a node is determined based on the estimated arrival time, node capacity, and existing node occupancy records. When the available capacity of a node meets the node capacity constraint, a node occupancy record is generated. The node occupancy record includes the task instance identifier, the outpatient process node identifier, the estimated arrival time, the resource occupancy lease term, and the node occupancy status. When the task execution status is completed, a robot task abnormality occurs, or the resource occupation lease term expires, the available node capacity corresponding to the node occupation record is released or reclaimed.

9. The method according to claim 1, characterized in that, The inheritance of completed node execution results and dynamic rearrangement of nodes to be executed includes: Based on the task execution status, the target node access sequence is divided into completed nodes, executing nodes, and pending nodes; Retain the completed nodes and their execution results, process the nodes in execution according to the execution status inheritance conditions, and revoke the task delegation records that are no longer applicable; The outpatient process nodes resulting from changes in the medical order version are combined with the retained pending execution nodes to form a set of remaining nodes; The adjusted node access sequence is generated based on the remaining node set and the updated node state snapshot; Generate a sequence version record that associates the original sequence version with the adjusted sequence version, and update the pending node corresponding to the original sequence version to an invalid state.

10. An outpatient companion robot system based on multimodal perception and intelligent decision-making, characterized in that, include: The system comprises a medical order node parsing module, a node status processing module, a node access sequence generation module, a subtask orchestration module, a terminal capability management module, a task delegation and execution feedback processing module, a task migration module, and a dynamic reordering module; the system is used to implement the method of any one of claims 1-9.

Images