A service instruction control and page linkage method and system for a medical robot

Abstract

The application provides a medical robot service instruction control and page linkage method and system, and belongs to the technical field of robots and human-computer interaction. The system comprises a service result receiving unit, a service instruction coding unit, a robot action issuing unit, a page display issuing unit, a field verification unit, a page mapping unit and a parameterized direct unit on the front-end page side. The service instruction coding unit encodes the service result output by the medical robot service process into a service instruction with predefined field semantics. The front-end page side performs parameterized page jumping according to the patient identification field, the record type field and the sub-item field in the service instruction. The application improves the cross-end service state consistency and the on-site task stability of the medical robot.

Description

Technical Field

[0001] This invention belongs to the fields of robotics and human-computer interaction, and in particular relates to a method and system for business instruction control and page linkage of a medical robot. Background Technology

[0002] In hospital environments, medical robots not only need to perform physical tasks such as delivery, guidance, and alarms, but also need to synchronize information and operate in conjunction with page systems such as nurse stations, doctor workstations, and ward terminals. Traditionally, robot control and page display are often independent: when the robot performs actions such as navigation, opening wards, and arrival, the front-end page cannot reflect the execution status in real time; buttons, forms, and confirmation operations on the page cannot directly constrain or advance the robot's process.

[0003] The first category of existing technologies adopts a general page linkage display method. For example, the published patent "A display method, system and electronic device based on page linkage" (CN112711460A) mainly revolves around the linkage display, master-slave association and parallel display of multiple pages to organize page content.

[0004] The basic process of this type of technology typically includes: receiving page linkage trigger operations; determining the relationship between the main page and the secondary pages; updating the display content of one or more pages according to the linkage relationship; and presenting the linked page on the terminal device.

[0005] This type of solution has addressed the display of relationships between pages, but its focus remains on the general page presentation layer. It typically does not involve the robot's action phase when performing tasks, nor does it emphasize the shared interpretation of business fields such as patient information, record type, sub-items, and task status in relation to the page's interaction.

[0006] The second type of existing technology involves triggering page navigation via voice commands. For example, the published patent "A Page Navigation Method and Terminal Device" (CN109063082A) mainly focuses on voice command recognition, keyword extraction, and navigation to the corresponding page.

[0007] The basic process of this type of technology typically includes: receiving user voice; recognizing page keywords in the voice content; matching the target page based on the keywords; and redirecting to and displaying the target page.

[0008] This type of solution can solve the problem of how to open a page after a user says a page name, but its page redirection is usually based on the page name or keywords. It does not solve how the robot task results can simultaneously drive the action end and the page end, nor does it solve the problem of parameterized direct access to patients, record types, sub-items, etc. required for medical data pages.

[0009] The third category of existing technologies involves controlling web page navigation based on data content. For example, US10083242B2, "System and method for data-driven webpage navigation control," relates to controlling page navigation based on data or form content.

[0010] The basic idea behind this type of technology is to read or receive page-related data; determine the page navigation target based on the data content; and control page navigation or execute page flow.

[0011] This type of approach demonstrates that data can drive page navigation, but it is primarily applicable to general web pages and form navigation. It does not handle robot actions, medical business objects, clinical data types, and page states within the same set of business instruction field semantics.

[0012] The fourth category of existing technologies consists of RPA process execution systems based on page state understanding and large model-driven approaches, such as "RPA Process Execution System and Method Based on Page State Understanding and Large Model-Driven Approach" (CN117196546B). This type of solution focuses on automatically understanding page states and driving RPA to automatically execute page operations.

[0013] The similarity between this type of solution and the present invention is that both involve processes and page states, but the difference is that: RPA solutions are usually understood and operated by automated programs, while the present invention generates business instructions with unified field semantics from the medical robot business process, so that the robot action end and the page display end can be executed collaboratively according to the same business result.

[0014] In summary, the path closest to existing technology can be summarized as follows: The system receives user operations, voice commands, or business data. The target page is determined based on preset rules. Send page redirection or page linkage instructions to the front end. The front-end displays the page according to the page type. Some solutions can be further linked based on data or page status.

[0015] While this technical approach can achieve page redirection or page linkage, it typically does not integrate the robot control end, page display end, and medical business objects into the same set of business instruction field semantics, nor does it design an event confirmation and fallback mechanism for typical robot event loss.

[0016] Figure 1This illustrates a typical process that most closely resembles existing technologies. In this process, the trigger source can be user operation, voice command, or business data, and the main goal of the system is to identify and open the target page. The page side typically displays content according to page name or linkage relationship, and the robot action end, patient object, clinical record type, and event fallback mechanism do not form a unified processing link.

[0017] Figure 1 In this context, page navigation instructions primarily flow within the page presentation layer. When robot navigation, patient-level indicator display, and navigation completion events need to be integrated into the same task, the existing path requires the addition of multiple temporary adaptation relationships, which can easily lead to issues such as inconsistent field definitions, inconsistent cross-platform interpretations, and process stalls after event loss. Summary of the Invention

[0018] Therefore, the technical problem to be solved by the present invention is to provide a method and system for business instruction control and page linkage of a medical robot, which solves the problems of disconnect between robot execution state and page display, and lack of consistent constraints between page operation and business stage, resulting in repeated triggering, state misalignment or abnormal progress.

[0019] In a first aspect, the present invention provides a business instruction control and page linkage system for a medical robot, comprising: The business result receiving unit is used to receive the business results output from the medical robot business process. A business instruction encoding unit, connected to the business result receiving unit, is used to encode the business result into a business instruction. The fields in the business instruction have predefined semantics. The fields include at least an instruction category field for distinguishing between page display instructions and robot action instructions, and a page or action type field for representing the target page or target action. A robot motion sending unit, connected to the business instruction encoding unit, is used to send robot motion instructions to the robot control terminal according to the instruction category field; The page display distribution unit is connected to the business instruction encoding unit and is used to distribute the page display instruction to the front-end page according to the instruction category field. The front-end page includes: The field validation unit is used to parse the page display instructions and validate key fields. A page mapping unit is used to determine the target page based on the page or action type field. The parameterized direct access unit is used to perform parameterized page redirection based on the business parameters carried in the business instruction.

[0020] Furthermore, the fields in the business instruction are organized semantically in the following manner: The instruction category field works in conjunction with the page or action type field to jointly determine the page display instruction or robot action instruction and its specific type; The business instructions also form a hierarchical business parameter structure through patient identification field, record type field and sub-item field, which is used to directly locate the page to the target patient, target record type and target sub-item.

[0021] Furthermore, the robot action instructions and the page display instructions are formed separately in the same business process based on the same business result, and the robot action instructions and the page display instructions share common fields in the business instructions, so that the robot's action execution and the page display task description come from the same business judgment.

[0022] Furthermore, the parameterized direct access unit directly locates the front-end page to the target patient, target record type, or target sub-item based on at least one of the patient identifier field, record type field, and sub-item field.

[0023] Furthermore, when the parameterized direct access unit locates the target sub-item based on the sub-item field, if the sub-item field does not completely match the sub-item name in the target page, it matches the target sub-item according to the following priority rules: First priority: exact match; Second priority: When the sub-item field is a numeric sequence number, match the sub-item with the corresponding sequence number in the ward round data group; Third priority: When the sub-item field is a name, calculate the string similarity with each sub-item name. When there is a sub-item with a similarity exceeding a preset threshold, select the sub-item with the highest similarity. Fourth priority: If none of the above matches are successful, the first sub-item under this record type will be displayed by default; String similarity is calculated using edit distance or Jaccard similarity.

[0024] Furthermore, the field verification unit performs integrity and legality checks on the message object, patient identifier, and record type of the strongly verified page. If the verification fails, the page will not be redirected.

[0025] Furthermore, the front-end page also includes: The event listening unit is used to receive navigation completion or position result events reported by the robot control terminal; The fallback push unit is used to trigger the page to enter a preset stable state if the event is not received within a predetermined time using a fallback timer.

[0026] Furthermore, the event listening unit and the fallback push unit together form an event-prioritized, timed fallback page push mechanism, and the fallback timer in the fallback push unit is cleared when the event arrives or the page is unloaded, and the event listening unit is removed when the page is unloaded.

[0027] Furthermore, the predetermined time in the backup propulsion unit T timeout Calculated dynamically according to the following formula:

[0028] in: T base The base timeout period; D current This represents the remaining distance between the robot's current position and the target position. D total This is the total path length for this navigation task; R success The historical success rate of the same type of task; α This is the distance factor coefficient, used to adjust the strength of the influence of the remaining distance ratio on the timeout time. β This is the success rate factor coefficient, used to adjust the decay strength of historical success rate over timeout.

[0029] In a second aspect, the present invention also provides a method for business instruction control and page linkage of a medical robot, used to implement the system described in any one of the first aspects, comprising: Receive business results output from the medical robot's business process; The business results are encoded into business instructions, and the fields in the business instructions have predefined semantics. The fields include at least an instruction category field for distinguishing between page display instructions and robot action instructions, and a page or action type field for representing the target page or target action. Based on the instruction category field, robot action instructions are sent to the robot control terminal, and page display instructions are sent to the front-end page terminal; The front-end page parses the page display instruction, performs page mapping based on the page or action type field, and executes parameterized page redirection based on the business parameters carried in the business instruction.

[0030] Beneficial effects: (1) The present invention defines clear semantics for fields such as cmd, type, task, patientId, recordType, subtype, status, and id in business instructions. Therefore, the backend, robot end and frontend page end can interpret business results around the same set of fields.

[0031] With standardized field meanings, robot actions and page displays no longer rely on temporary conventions for each scenario, thereby reducing situations where actions have been executed but the page is not synchronized, or the page has been redirected but the task object is inconsistent. Ultimately, this improves the consistency of cross-platform business status.

[0032] (2) Business instructions can carry patient identifiers, record types, and sub-items, and the page can directly display the target patient's target data, rather than just entering the entry page. Therefore, after medical staff make a viewing request through voice or robot interaction, the page can directly drop to the target content.

[0033] This reduces the need for secondary selection steps and lowers the probability of selecting the wrong patient or data item in a busy field environment. Ultimately, this improves clinical review efficiency and the availability of robotic services.

[0034] (3) By performing validations on the strongly validated page through the front end, such as message objects, patient identifiers, and record types, messages with missing or invalid parameters will not be executed blindly. Errors can be detected and logged before the page redirects, instead of turning into an empty page, a default page, or an incorrect patient page.

[0035] This verification goes beyond simply ensuring message delivery; it ensures the message can be securely interpreted, thereby improving the reliability of the medical page display.

[0036] (4) Since both the robot's action commands and the page display commands are determined from the same business process, the current task displayed on the page, the actions performed by the robot, and the voice response content can remain consistent. For example, the page displays the task page when navigation begins, the page displays the target metric when querying metrics, and the page displays the corresponding alert page when an alarm is triggered.

[0037] This allows medical staff to understand in a timely manner what tasks the robot is currently performing through the webpage, reducing on-site communication costs.

[0038] (5) In typical task pages, the present invention simultaneously employs robot event listening and fallback timers. Under normal circumstances, the page is driven by real robot events; under abnormal circumstances, the page will not remain indefinitely due to event loss.

[0039] This mechanism balances realism and continuity. When events are normal, it ensures the page state matches the robot's actual execution result; when events are abnormal, it uses a fallback mechanism to ensure the process continues uninterrupted. Ultimately, this improves the stability of the robot's on-site tasks.

[0040] (6) This invention does not design a separate set of messages for each page, but rather abstracts reusable field semantics. Therefore, when adding new pages in the future, basic fields such as cmd, type, task, and status can be reused, and business parameters such as patient, record type, and sub-item can be added as needed.

[0041] This reduces the cost of integrating new services and makes it easier to maintain the same set of linkage rules across multiple platforms. Attached Figure Description

[0042] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0043] Figure 1 This is a typical flowchart of existing technology; Figure 2 This is a diagram showing the connection relationships between the system components of Embodiment 1 of the present invention; Figure 3 This is a processing relationship diagram of parameterized direct access to the indicator data page in Embodiment 1 of the present invention; Figure 4 This illustrates the processing relationship between task page event confirmation and fallback implementation in Embodiment 1 of the present invention. Figure 5 This is a flowchart of the method in Embodiment 2 of the present invention. Detailed Implementation

[0044] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. The principles and features of the present invention are described below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other. The embodiments given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0045] When medical robots perform tasks such as consultations, ward rounds, deliveries, and indicator display, the backend intelligent workflow must not only control the robot's actions but also ensure that the frontend page synchronously displays the current task, patient, page content, and execution status. Current practices, which rely on separate message formats for each page and task, are prone to issues such as inconsistent field definitions, lost patient parameters, asynchronous page navigation and robot actions, and prolonged page dwell times after navigation events are lost.

[0046] 1. Currently, medical robots have the following characteristics: 1.1 Medical robot tasks are not one-way actions. Robot tasks in hospital settings are typically not just a simple robot movement or page jump. Taking ICU reception and delivery scenarios as an example, a complete task often includes multiple stages such as: speech recognition, business intent judgment, patient or bed confirmation, robot navigation, front-end task page display, navigation completion event feedback, next page switching, result broadcasting, task completion or reloading, etc.

[0047] Therefore, there is a strong requirement for business consistency between robot actions and page states: 1.1.1 When the robot starts navigating, the page should display the current task, instead of remaining on the homepage.

[0048] 1.1.2 When doctors query patient indicators, the page should directly display the corresponding ward round, test or examination data for that patient, instead of opening a page that requires further selection.

[0049] 1.1.3 After the robot reaches the target location, the page should enter the next task state instead of continuing to display the old task.

[0050] 1.1.4 If the navigation completion event is lost, the page should not be stuck indefinitely and should be able to enter a preset stable state.

[0051] These requirements dictate that the interactive pages of medical robots cannot rely solely on ordinary page routing, but require an application-layer instruction mechanism that can express business objects, page types, task statuses, and execution events.

[0052] 1.2 Limitations of Traditional Page Redirect Messages In typical business systems, page redirection usually only requires passing a target page address or a simple page type field. However, page redirection in medical robot systems often involves more constraints: 1.2.1 The page needs to know who the current patient is.

[0053] 1.2.2 The page needs to know whether to display ward rounds, inspections, or examinations.

[0054] 1.2.3 The page needs to know whether to further locate a specific sub-item.

[0055] 1.2.4 The page needs to know whether the current task is in a reminder, in progress, completed, or abnormal state.

[0056] 1.2.5 The page status needs to be coordinated with the robot navigation, warehouse, access control, recharging and other action statuses.

[0057] If each page has a custom message structure, single-point functionality can be achieved in the short term, but problems such as inconsistent field names, missing parameters that cannot be detected, separation of page and robot actions, repeated redirects, and status lag will occur after the system is expanded.

[0058] 1.3 Parameterization Requirements for Typical Medical Pages Taking the display of clinical indicators as an example, the actual instructions from medical staff are often: to check the blood routine of a patient in a specific bed, to display the vital signs of a patient during ward rounds, or to review a CT scan. These requests naturally contain multiple business elements: 1.3.1 Patients or beds.

[0059] 1.3.2. Major data categories, such as ward rounds, inspections, and examinations.

[0060] 1.3.3 Data sub-items, such as vital signs, blood routine, CT scan.

[0061] 1.3.4 Current task description, used for page prompts and voice responses.

[0062] If the system only sends "Open indicator page," medical staff still need to select the patient and data items again, failing to demonstrate the value of the robot's automated guidance. By uniformly writing these elements into the business instruction field, the front end can directly open the target patient's target data page, achieving parameterized direct access.

[0063] 1.4 Impact of Event Loss on On-Site Tasks Robot-based interactive pages present a challenge compared to regular web pages: page progression often relies on physical events transmitted back from the robot's endpoint, such as navigation completion, location results, and warehouse operation completion. These events may not be captured by the page due to network fluctuations, native plugin callback errors, or the timing of page transitions.

[0064] If a page relies solely on event confirmation, it will remain in the current task state if the event is lost. Conversely, if the page redirects directly without waiting for the event, it may advance prematurely before the robot arrives. Therefore, a "event-first, timed fallback" mechanism is needed: advance immediately upon the normal arrival of the event; if the event has not arrived, enter a stable page state after a preset time to ensure uninterrupted workflow.

[0065] 2. Analysis of existing medical robot solutions 2.1 Because the semantics of the fields are not consistent, cross-platform interpretation is prone to inconsistencies. Existing page redirection solutions typically only consider the target page, while robot systems require both the action-side and the page-side to jointly understand the same business outcome. If fields are defined separately for each business page, robot action, and backend process, issues may arise where a field represents the page type on the page-side and the action type on the robot-side, or the same patient field may have inconsistent names in different scenarios.

[0066] Inconsistent field semantics lead to backend processes requiring different adaptation logic for each page, and the frontend struggles to determine if a message contains complete parameters. The end result is that while the robot's actions may have been executed, the patient, task, or status displayed on the page may not match the actual process.

[0067] 2.2 Because it only jumps to the correct page without carrying the business object, the page may be correctly navigated to, but the content may be inaccurate. In a healthcare setting, simply "opening the indicator page" is insufficient; it's also necessary to know which patient, which record type, and which sub-item to open. Existing page redirection solutions, if only the target page type is passed, only allow the front-end to navigate to the entry page or display content based on local default values.

[0068] When medical staff want to view a patient's blood test results, if the command does not include fields such as patientId, recordType, and subtype, the page may redirect successfully, but manual selection is still required. It may even display a default patient or default indicators. This reduces the value of the automated robot and increases the risk of misreading or missing information on-site.

[0069] 2.3 Because robot actions and page displays are distributed separately, task status is prone to becoming disconnected. When the robot performs actions such as navigation, opening doors, and returning to its charging dock, the page needs to display the corresponding task status. If the action commands and page commands are not based on the same business result encoding, but are sent independently by different modules, situations may arise where the robot has already navigated but the page remains on the homepage, or the page displays "Navigating" but the robot has not received the action commands.

[0070] This disconnect might only be a user experience issue in a regular web-based system, but in a hospital setting, it can affect medical staff's judgment of the robot's current status and even disrupt the continuity of delivery, reception, and alarm handling processes.

[0071] 2.4 Because of the lack of parameter validation, error messages are easily executed silently. If existing page redirection solutions lack message format validation and key field validation, the front end may continue to redirect even for messages with missing patient identifiers, invalid record types, or incorrect sub-item encoding. This will cause errors to manifest at the page level as empty data, default data, or no response after redirection, making troubleshooting difficult.

[0072] For medical data pages, missing or invalid parameters are not ordinary anomalies, but may lead to incorrect display of objects. Therefore, it is necessary to perform necessary integrity and legality checks before page interaction.

[0073] 2.5 Because it relies solely on robot events, the page may freeze for an extended period if an event is lost. In scenarios such as navigation completion, if the front-end only waits for native robot events without a fallback mechanism, the page will remain stuck on the current task page if the event is lost. On-site personnel will see that the robot may have completed its movement, but the page will not proceed to the next step.

[0074] Conversely, if the page jumps directly without waiting for the event, the robot may not have completed its action before the page advances prematurely. Therefore, the lack of a solution that combines event confirmation with fallback timing creates a conflict between stability and realism.

[0075] 2.6 Because a reusable field organization is not formed, subsequent business expansion costs are high. The medical robot business will continue to add new pages and tasks, such as ward rounds, consultations, alarms, deliveries, and metric displays. If a new message format is defined for each new page, subsequent expansions will continuously increase the costs of field translation and compatibility.

[0076] As the number of pages increases, the lack of reusable field organization can lead to protocol fragmentation, affecting system maintenance and multi-terminal collaboration.

[0077] Based on the above analysis, the basic solution proposed in this invention is as follows: A set of instruction field semantics for medical robot business is defined at the application layer, encoding the process output results into business instructions containing fields such as instruction category, page or action type, task description, patient identifier, record type, sub-item, status, and message identifier; the backend issues robot action instructions and page display instructions according to the field semantics; after receiving the instructions, the frontend performs field validation, page mapping, and parameterized redirection; in typical event scenarios such as navigation completion and task completion, event listening and timed fallback mechanisms are simultaneously set up to ensure the page can stably advance with the robot's execution status.

[0078] The business instructions referred to in this invention are not limited to a specific transmission method. Messages can be transmitted via MQTT, WebSocket, HTTP push, or other communication methods. The transmission channel solves the problem of "how the message arrives," while this invention solves the problem of "how each terminal interprets and executes the message based on the same business semantics after it arrives."

[0079] For example, display_page is not just a plain string; it indicates that the message is used for page display. indicator_data is not just a page name; it indicates that the target page needs to display specific clinical data based on the patient, record type, and sub-item parameters. task_page not only opens the task page but also carries the current task description and status. Fields such as id and timestamp can be used to identify messages and record the execution process.

[0080] Therefore, this invention emphasizes the semantics of application layer business instruction fields and their collaborative use in robot control and page display.

[0081] The relevant terms in this invention are explained as follows: Medical robots: refer to service robots or their supporting terminals used in scenarios such as hospital reception, ward round guidance, item delivery, drug delivery, indicator display, and early warning reminders.

[0082] Business instructions: refer to application layer messages generated by backend processes or intelligent agents to drive robot actions and / or frontend page displays.

[0083] Field semantics: refers to the fixed business meaning of each field in a business instruction. For example, cmd indicates the instruction category, type indicates the page or action type, task indicates the task description, and patientId indicates the patient object.

[0084] Page linkage: This refers to the front-end page switching to the corresponding page according to the business instructions when the robot's business process is progressing, and displaying the target content with business parameters.

[0085] Parameterized access: This means that the page does not just redirect to the entry page, but directly locates the target patient and target data item through parameters such as patient, record type, and sub-item.

[0086] Record type: refers to the major categories of clinical data presented, preferably including ward round data, laboratory data, and examination data.

[0087] Sub-items: These refer to further display items under the record type, such as vital signs, intake and output, circulation and perfusion in ward round data, or dynamic items such as blood routine and CT scans in laboratory and examination data.

[0088] Backup timing: refers to a mechanism whereby the front end or business process executes a stable state advancement or repeated reminders after a predetermined time when the target event does not arrive as expected.

[0089] The fallback timer: This refers to a timer instance started in the fallback push unit, used to trigger a callback after a preset timeout. It is a fundamental tool for the fallback push unit to achieve stable progress or recurring reminders. This timer is cleared when a robot event occurs or the page is unloaded.

[0090] Same-origin business result-driven: This means that the output of the same business process is encoded into the same set of field semantics, and then used to drive the robot's actions and the page's display, avoiding the two terminals interpreting the business status separately.

[0091] Message identifier: refers to the id or similar field in the business instruction, used to identify a message, which facilitates logging, troubleshooting, or correlation analysis in certain scenarios.

[0092] Strongly validated pages: These are pages that perform integrity and legality checks on key parameters before redirecting to the next page or displaying data, such as indicator data display pages.

[0093] Robotic Process Automation (RPA): This approach uses automated programs to identify page states and simulate manual page operations, which differs from the method described in this invention, where business instructions actively drive robot actions and page interactions.

[0094] Android native plugins: These are capability modules that run in the native layer of the Android terminal and can provide front-end pages with capabilities such as navigation, location events, and device control.

[0095] RobotLocationEvent: refers to the location or navigation result event reported by the robot or Android native plugin to the front-end page. Example 1

[0096] This embodiment first provides a business instruction control and page linkage system for a medical robot, such as... Figure 2 As shown, the business result receiving unit 101 receives the business results output by the intelligent process, rule process, or manually triggered process, and passes the business results to the business instruction encoding unit 102. The business instruction encoding unit 102 generates robot action instructions and page display instructions according to the unified field semantics: the robot action instructions are sent to the robot control terminal via the robot action issuing unit 103, and the page display instructions are sent to the front-end page via the page display issuing unit 104.

[0097] After receiving the page display instruction, the front-end page processes it sequentially through the field validation unit 105, the page mapping unit 106, and the parameterized direct access unit 107 to determine whether to perform a page jump, which page to jump to, and whether to include parameters such as patient, record type, and sub-items. The robot control terminal can report events to the event listening unit 108 upon completion of navigation, location confirmation, or task completion; if the event does not arrive within the predetermined time, the fallback push unit 109 pushes the page into a preset stable state. The log and status recording unit 110 records business instruction generation, field validation, page jump, event triggering, and fallback push information.

[0098] The business result receiving unit 101 is used to receive business results output by intelligent processes, rule processes, or manually triggered processes.

[0099] The business instruction encoding unit 102 is used to convert business results into business instructions with field semantics.

[0100] The robot action sending unit 103 is used to send action commands such as navigation, stop navigation, open the compartment, close the compartment, and charge to the robot control terminal.

[0101] Page display distribution unit 104 is used to send display instructions for the homepage, task page, consultation page, early warning page, indicator data page, etc. to the front-end page.

[0102] Field validation unit 105 is used to validate whether the message is the expected object, whether the instruction category is correct, and whether the key parameters exist and are valid.

[0103] Page mapping unit 106 is used to map a target page based on a page or action type field.

[0104] The parameterized direct access unit 107 is used to locate the target patient and target data item based on fields such as patient identifier, record type, and sub-item.

[0105] The event listening unit 108 is used to receive events such as navigation completion and position results reported by the robot's native plugin or control terminal.

[0106] The fallback push unit 109 is used to advance the page state via a timer when the event does not arrive in time.

[0107] The log and status recording unit 110 is used to record message identifiers, task parameters, page jumps, and fallback information for exceptions.

[0108] The business instructions in this invention preferably adopt the following field semantics: The above fields are not required for every business instruction; instead, only the necessary fields should be selected based on the page or action type. For pages with strong validation, such as metric data pages, patientId and recordType are required fields, while subtype is an optional field.

[0109] The business instruction encoding unit preferably performs the following steps: 3.1 Read the business objective output by the process and determine whether the objective belongs to robot action, page display or a combination of actions.

[0110] 3.2 If the target is a robot action, set cmd to the action category such as navigation, stop navigation, open the compartment, close the compartment, or charge, and write id, timestamp, session_id, target location or action parameters.

[0111] 3.3 If the target is a page display, set cmd to display_page and write the target page type through the type field.

[0112] 3.4 If the page needs to display task descriptions, then write them into the task field.

[0113] 3.5. If the page needs to display patient-related data, then write the patientId field.

[0114] 3.6 If the page needs to display clinical records, write them into the recordType field.

[0115] 3.7 If the page requires further direct access to sub-items, then write the subtype field.

[0116] 3.8. If the page involves task status or warning status, write the status or hasWarning field.

[0117] 3.9 Generate message identifiers and timestamps to form deliverable business instructions.

[0118] In a preferred embodiment, the backend page display tool receives parameters such as page, task, patientId, recordType, and subtype. When page is indicator_data, the instruction encoding unit writes the patient identifier, record type, and sub-item into the same page display instruction, enabling the frontend to directly jump to the target patient's target data page.

[0119] This embodiment does not require each business instruction to be sent to both the robot and the webpage simultaneously. Instead, within the same business process, robot action instructions and webpage display instructions are generated separately based on the business results. Both share the same set of field semantics and task context.

[0120] For example, when the robot begins navigation, the system can send an action command to the robot containing cmd=navigate, the target location, and a session identifier, while simultaneously sending a page display command to the webpage containing cmd=display_page, type=task_page, and task=navigate to the target location. In this way, the robot's action and the page display task description originate from the same business decision, avoiding a disconnect between the terminal and the user's state.

[0121] For example, when a doctor queries a patient's indicators via voice, the system can first obtain the patient's information based on the bed, and then encode the patient's identifier, record type, and sub-items into an indicator_data page display command. The webpage can then directly open the target data based on this, while the chatbot can simultaneously announce, "Showing you a specific indicator for a specific bed."

[0122] As an optional implementation, after receiving the business instruction, the front-end page performs the following steps: 4.1. Parse the received message object.

[0123] 4.2 Determine if cmd is a page display command; if not, delegate to other processing logic or ignore it.

[0124] 4.3 Read the type field and match the page type.

[0125] 4.4 For general pages, perform page redirection according to the page mapping table.

[0126] 4.5 For the task page, read fields such as task, status, and hasWarning to form the parameters for displaying the task page.

[0127] 4.6 For the indicator data page, first verify whether the message is an object, then verify whether the patientId exists, and then verify whether the recordType is within the allowed range.

[0128] 4.7 Encode parameters such as subtype that may contain Chinese characters or special characters.

[0129] 4.8 Construct the target page URL and execute the page redirection.

[0130] 4.9 After the page loads, validate the necessary parameters again and call the corresponding data interface according to the recordType.

[0131] 4.10 After the data is returned, set the target sub-item according to the subtype; if no sub-item is specified, the first sub-item will be displayed according to the default rules.

[0132] Through the above processing, the system does not blindly execute page redirection, but constrains the key fields before and after the redirection.

[0133] In one optional implementation, after the doctor says "Check the blood routine of a patient in bed X" or "Show the vital signs of a patient in bed X" during ward rounds, the background process first identifies the bed and the type of indicator, and then retrieves the patient's identifier. Subsequently, the following business instruction is generated: { "cmd":"display_page", "type":"indicator_data", "patientId":"Patient ID", "recordType":2, "subtype":"complete blood count", "task":"View this patient's blood routine data", "id":"Message Identifier", "timestamp":1760000000 } After receiving the instruction, the front end performs the following processing: 5.1 Confirm that cmd is display_page.

[0134] 5.2 Confirm that the type is indicator_data.

[0135] 5.3 Check that patientId is not empty.

[0136] 5.4. Verify that the recordType is one of 1, 2, or 3.

[0137] 5.5. URL-encode the subtype.

[0138] 5.6. Redirect to the indicator data page, and include patientId, recordType, and subtype.

[0139] 5.7 When the indicator data page is loaded, select the ward round, inspection, or examination data interface according to the recordType.

[0140] 5.8 If recordType is ward round data, then integrate the data returned by the backend with the fixed group template, and convert subtype to numeric group number.

[0141] 5.9 If recordType is validation or inspection, then subtype will be used as the dynamic item name for matching.

[0142] 5.10 After matching is completed, display the target patient, target record type, and target sub-item data.

[0143] The technical effect of this embodiment is that the page no longer only opens the indicator entry, but directly leads to the specific patient and specific indicator sub-item, reducing the need for secondary operations by medical staff.

[0144] Figure 3 This illustrates the processing relationship for parameterized direct access to indicator data pages. The business process first determines the patient and indicator type, then the business instruction encoding unit writes the patient identifier, record type, and sub-items into the same page display instruction. The front-end page constructs the target page address after validating the fields and selects the corresponding data interface based on the record type when the page loads.

[0145] Figure 3 In this system, patient identifiers, record types, and sub-items are no longer scattered across different page states, but are transmitted within the same business instruction. The front-end field validation unit 105 can detect issues such as missing key parameters or invalid types before redirection, while the parameterized direct access unit 107 directly locates the target data item when the parameters are valid.

[0146] When parameterized access units locate a target sub-item based on a sub-item field, if the sub-item field does not exactly match the sub-item name on the target page, the target sub-item will be matched according to the following priority rules: First priority: exact match; Second priority: When the sub-item field is a numeric sequence number, match the sub-item with the corresponding sequence number in the ward round data group; Third priority: When the sub-item field is a name, calculate the string similarity with each sub-item name. When there is a sub-item with a similarity exceeding a preset threshold, select the sub-item with the highest similarity. Fourth priority: If none of the above matches are successful, the first sub-item under this record type will be displayed by default; String similarity is calculated using edit distance or Jaccard similarity.

[0147] This method can upgrade parameterized access from precise matching to intelligent adaptation, significantly improving the robustness, user experience, and on-site adaptability of medical robot page integration.

[0148] In another preferred embodiment, the task delivery page needs to wait for the robot navigation to arrive before proceeding to the next page. After the page loads the task parameters, the following steps are performed: 6.1 Read task information, next page, and status parameters.

[0149] 6.2. Invoke the robot's navigation capabilities to begin navigation.

[0150] 6.3 Register robotLocationEvent and other robot location event listeners.

[0151] 6.4 When the robot reports the location result through the native plugin and the status indicates that navigation is successful, the page will redirect to the next page.

[0152] 6.5 After page redirection, clean up pending callbacks and fallback timers.

[0153] 6.6 If a navigation success event is not received within the scheduled time, a fallback timer will trigger page progression.

[0154] 6.7 Remove robot event listeners and clear timers when the page is unloaded to prevent old page events from affecting the new page.

[0155] In this embodiment, the Android native plugin encapsulates the location operation result into an event object. This event object contains the event type, status, message, and additional data, and is sent to the front-end page via a global event callback. The front-end page prioritizes events while also implementing a timed fallback mechanism. This ensures that page interaction respects the robot's actual state while preventing page stagnation due to event loss.

[0156] Figure 4 The process relationship between task page event confirmation and fallback propulsion is illustrated. After the task page initiates navigation, it simultaneously registers robot position events and starts a fallback timer; when the event arrives normally, the event drives the page to advance; when the event does not arrive, the fallback propulsion unit 109 propels the page into a stable state after a predetermined time.

[0157] Figure 4 In this system, the event listening unit 108 and the fallback execution unit 109 are not mutually exclusive, but rather together form an "event-first, timed fallback" page advancement mechanism. When an event arrives, the actual robot's execution result is used first; if the event has not arrived, the system can still complete the page state closing after a predetermined time.

[0158] The scheduled time in the backup propulsion unit T timeout Calculated dynamically according to the following formula:

[0159] in: T base The baseline timeout time can be preset according to the task type. For example, the default timeout time is 30 seconds for navigation tasks. D current The remaining distance between the robot's current position and the target position, in meters, can be obtained in real time through the robot's positioning interface. D total The total path length for this navigation task, in meters, is calculated by the path planning module at the start of navigation. R success The historical success rate of the same type of task, ranging from 0 to 1, can be obtained from historical log statistics. α, β: Configurable coefficients used to adjust the influence strength of the distance factor and success rate factor. Default values ​​are α=0.5 and β=0.2. By employing the predetermined time algorithm in the aforementioned fallback propulsion unit, the following was achieved: Remaining distance adaptive: When the robot is far from the target, D current When the distance is large, the timeout period is automatically extended to avoid premature timeout due to excessively long paths; when the distance is short, the timeout period is appropriately shortened to improve page response efficiency.

[0160] Success rate feedback adjustment: If the historical execution success rate of similar tasks is... R success A higher success rate indicates a stable and reliable system, and the timeout period will automatically decrease to reduce unnecessary waiting. If the success rate is low, the timeout period will automatically increase to allow more time for handling abnormal situations and reduce the probability of page lag caused by occasional failures.

[0161] Exponential smoothing: The use of an exponential factor makes the impact of success rate on timeout smooth and continuous, avoiding drastic jumps in timeout caused by slight fluctuations in success rate, and ensuring stable and predictable system behavior.

[0162] Integration of on-site and statistical information: The formula integrates the real-time status of the current navigation (distance ratio) and long-term statistical characteristics (historical success rate), so that the timeout judgment respects the actual situation of the current task and is guided by historical experience, which is more scientific than fixed timeout or simple linear adjustment.

[0163] Parameters are configurable: The α and β coefficients can be optimized by the administrator according to different departments, robot models or task types to balance fault tolerance and response speed, and enhance the system's adaptability to diverse medical scenarios.

[0164] This dynamic timeout calculation formula upgrades the fallback mechanism from a static preset to an adaptive, learnable, and smoothly adjustable intelligent mechanism, significantly improving the stability, reliability, and environmental adaptability of the medical robot's page linkage.

[0165] In some reception processes, the system can also use timer commands to implement repeated reminders and final closing. Ideally, the backend reply text should include timer commands such as _startTimer, _timeout, _final, and _cancelTimer to indicate starting a reminder, repeating a reminder, reaching the limit, and canceling the reminder.

[0166] The timer processing unit preferably performs the following steps: 7.1 Identify the timer task identifier from the message.

[0167] 7.2 Determine whether the current message is a timeout reminder or a final timeout.

[0168] 7.3 If it is a timeout reminder, generate a continuation reminder instruction containing the reminder text, the interval time, and the maximum number of reminders.

[0169] 7.4 If the final number of attempts is reached, the process will proceed to cancellation, manual processing, calling the nurse station, or other stable states.

[0170] 7.5. If the business process is completed, generate a timer cancellation instruction to avoid further reminders.

[0171] This implementation can be used in conjunction with page linkage to ensure that scenarios such as long waiting times, information input, and medical staff confirmation are not interrupted due to a single unresponsive reminder.

[0172] To reduce page flickering or state resets caused by duplicate messages, the page linkage unit can also compare the current path with the target path. If the user is already on the target page, the duplicate redirection will be skipped. For the message chain, the front end can also set a watchdog to detect the validity of the connection object, the connection status, and the situation where no protocol packets are received for a long time. When the connection object is found to be invalid, disconnected and not in the recovery process, or no protocol packets are received for a predetermined time, the connection will be forcibly rebuilt.

[0173] The above mechanism is not the only essential feature of this invention, but it can be used as an enhancement to improve the stability of page linkage.

[0174] This invention has the following characteristics: 8.1 Encode the output of medical robot business processes into application-layer business instructions with unified field semantics, instead of just sending ordinary page redirection commands.

[0175] 8.2. Use cmd and type to express the instruction category and page or action type respectively, so that the page display instructions, robot action instructions and task status have interpretable boundaries.

[0176] 8.3. Include business parameters such as patientId, recordType, and subtype in the page display instructions to enable direct access to patient-level, record-type-level, and sub-item-level pages.

[0177] 8.4 For pages with strong validation, such as those displaying indicator data, perform integrity and validity checks on key fields before and after redirection.

[0178] 8.5 The robot action end and the page display end are issued based on the same business result, forming a co-source linkage between robot execution and page display.

[0179] 8.6 In scenarios such as navigation completion and task completion, adopt a page progression method that prioritizes event listening and supplements with timed backup.

[0180] 8.7. By using page redirection for deduplication, event listener cleanup, timer cancellation, and message logging, the impact of duplicate messages, old events, and event loss on the page state can be reduced.

[0181] The present invention can be replaced by the following alternatives: This invention does not limit business instructions to be transmitted via Message Queuing Telemetry Transport Protocol (MQTT). Business instructions can be transmitted via WebSocket, HTTP long polling, server push, message queue, Bluetooth, LAN socket, or other communication methods. As long as the message carries uniform field semantics and can be interpreted by the robot and the web page according to the agreement, the purpose of this invention can be achieved.

[0182] In this invention, the field names such as cmd, type, task, patientId, recordType, subtype, status, and id can be replaced with other names. For example, cmd can be replaced with command, type can be replaced with pageType or actionType, patientId can be replaced with patientCode, and recordType can be replaced with dataCategory. As long as the fields carry the same or equivalent business semantics, they are considered equivalent substitutions.

[0183] Page mapping can be implemented using a front-end enumeration table, a back-end returned route address, a configuration center, database configuration, a dynamic routing table, or a local mapping function. Regardless of the mapping method used, as long as the page determines the target page based on the business instruction field and executes the redirection, the purpose of this invention can be achieved.

[0184] Patient identifiers can be patient primary keys, hospital numbers, bed numbers, visit numbers, or other business identifiers that can uniquely identify a patient. Record types can be represented by numbers, strings, enumerations, or objects. Sub-items can be represented by fixed group numbers, examination item names, test item codes, or subject identifiers returned by the backend.

[0185] Field validation can be performed on the front end, before back end deployment, or jointly by the gateway, middleware, and page container. Validation rules can be implemented using code checks, JSON schemas, type definitions, configuration rules, or protocol description files.

[0186] Typical event fallback mechanisms can be implemented using front-end timers, back-end timeout tasks, robot-side event resending, heartbeat confirmation, status polling, or manual confirmation buttons. The timing can also be dynamically adjusted based on the task type. As long as the page can be pushed into a preset stable state before the event arrives in time, the purpose of this invention can be achieved.

[0187] This invention can be applied to reception robots, delivery robots, bedside robots, as well as tablet terminals, mobile nursing terminals, nurse station screens, or other terminals that are linked to robot operations. Example 2

[0188] This embodiment provides a method for controlling business instructions and linking pages using a medical robot in the system of Embodiment 1, for implementing the system described in Embodiment 1. This method converts the robot's business process output into business instructions, and sets fields with agreed-upon semantics in the business instructions, enabling the robot and the front-end page to execute actions and display content according to the same business result.

[0189] Figure 5 The method flow of the present invention is shown. S101 to S105 belong to the business result encoding and cross-terminal distribution process, S106 to S109 belong to the front-end page parsing, verification and parameterized direct access process, and S110 to S112 belong to the event confirmation, fallback and execution recording process.

[0190] S101 receives the output results of the medical robot business process.

[0191] S102, determine the target terminal and target action corresponding to the business result, and determine whether it is robot action, page display or combined linkage.

[0192] S103, Generate business instruction fields based on business results, including at least an instruction category field and a page or action type field.

[0193] S104, write the task description, patient identifier, record type, sub-item, status flag, message identifier and timestamp according to business needs.

[0194] S105 sends robot action commands to the robot and page display commands to the front-end page.

[0195] S106, the front-end page parses business instructions and determines whether to proceed to the page display process based on the instruction type.

[0196] S107, the front-end page maps pages based on the page type field.

[0197] S108 performs integrity and validity checks on key fields of the page with strong validation.

[0198] S109, execute parameterized direct access to the page based on business parameters.

[0199] S110, for pages that require waiting for robot results, register robot event listeners and set fallback timers.

[0200] S111: If the robot event arrives normally, the event-driven page will proceed; if the event does not arrive in time, a timer will trigger a fallback page.

[0201] S112 records message processing, page redirection, event triggering, and fallback execution information to complete this round of linkage.

[0202] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A business instruction control and page linkage system for a medical robot, characterized in that, include: The business result receiving unit (101) is used to receive the business results output by the medical robot business process; A business instruction encoding unit (102) is connected to the business result receiving unit (101) and is used to encode the business result into a business instruction. The fields in the business instruction have predefined semantics. The fields include at least an instruction category field for distinguishing between page display instructions and robot action instructions, and a page or action type field for representing the target page or target action. The robot action issuing unit (103) is connected to the business instruction encoding unit (102) and is used to issue robot action instructions to the robot control terminal according to the instruction category field; The page display distribution unit (104) is connected to the business instruction encoding unit (102) and is used to distribute the page display instruction to the front-end page according to the instruction category field; The front-end page includes: The field validation unit (105) is used to parse the page display instructions and validate key fields; Page mapping unit (106) is used to determine the target page based on the page or action type field; The parameterized direct access unit (107) is used to perform parameterized page redirection according to the business parameters carried in the business instruction.

2. The system as described in claim 1, characterized in that, The fields in the business instruction are organized semantically in the following manner: The instruction category field works in conjunction with the page or action type field to jointly determine the page display instruction or robot action instruction and its specific type; The business instructions also form a hierarchical business parameter structure through patient identification field, record type field and sub-item field, which is used to directly locate the page to the target patient, target record type and target sub-item.

3. The system as described in claim 1, characterized in that, The robot action instructions and the page display instructions are formed separately in the same business process based on the same business result, and the robot action instructions and the page display instructions share common fields in the business instructions, so that the robot's action and the page display task description come from the same business judgment.

4. The system as described in claim 2, characterized in that, The parameterized direct access unit (107) directly locates the front-end page to the target patient, target record type, or target sub-item based on at least one of the patient identification field, record type field, and sub-item field.

5. The system as described in claim 4, characterized in that, When the parameterized direct access unit (107) locates the target sub-item based on the sub-item field, if the sub-item field does not completely match the sub-item name in the target page, the target sub-item is matched according to the following priority rules: First priority: exact match; Second priority: When the sub-item field is a numeric sequence number, match the sub-item with the corresponding sequence number in the ward round data group; Third priority: When the sub-item field is a name, calculate the string similarity with each sub-item name. When there is a sub-item with a similarity exceeding a preset threshold, select the sub-item with the highest similarity. Fourth priority: If none of the above matches are successful, the first sub-item under this record type will be displayed by default; String similarity is calculated using edit distance or Jaccard similarity.

6. The system as described in claim 1, characterized in that, The field verification unit (105) performs integrity and legality checks on the message object, patient identifier and record type of the strong verification page. If the verification fails, the page will not be redirected.

7. The system as described in claim 1, characterized in that, The front-end page also includes: The event listening unit (108) is used to receive navigation completion or position result events reported by the robot control terminal; The fallback push unit (109) is used to trigger the page to enter a preset stable state when the event is not received within a predetermined time by the fallback timer.

8. The system as described in claim 7, characterized in that, The event listening unit (108) and the fallback push unit (109) together form an event-prioritized, timed fallback page push mechanism. The fallback timer in the fallback push unit (109) is cleared when the event arrives or the page is unloaded, and the event listening unit (108) is removed when the page is unloaded.

9. The system as described in claim 7, characterized in that, The predetermined time in the bottom-line propulsion unit (109) T timeout Calculated dynamically according to the following formula: ； in: T base The base timeout period; D current This represents the remaining distance between the robot's current position and the target position. D total This is the total path length for this navigation task; R success The historical success rate of the same type of task; α This is the distance factor coefficient, used to adjust the strength of the influence of the remaining distance ratio on the timeout time. β This is the success rate factor coefficient, used to adjust the decay strength of historical success rate over timeout.

10. A method for business instruction control and page linkage of a medical robot, used to implement the system described in any one of claims 1 to 9, characterized in that, include: Receive business results output from the medical robot's business process; The business results are encoded into business instructions, and the fields in the business instructions have predefined semantics. The fields include at least an instruction category field for distinguishing between page display instructions and robot action instructions, and a page or action type field for representing the target page or target action. Based on the instruction category field, robot action instructions are sent to the robot control terminal, and page display instructions are sent to the front-end page terminal; The front-end page parses the page display instruction, performs page mapping based on the page or action type field, and executes parameterized page redirection based on the business parameters carried in the business instruction.

Images