FollowUpBot: LLM Robot for Postoperative Care
- FollowUpBot is an LLM-powered, edge-deployed robot that automates postoperative care through adaptive dialogues and autonomous navigation.
- It replaces manual bedside interviews by dynamically tailoring questions based on patient responses and local data processing.
- The system integrates SLAM-based mapping, local LLM inference, and NLI-based normalization to improve clinical documentation and efficiency.
FollowUpBot is an LLM-powered edge-deployed robot for postoperative care and monitoring that combines autonomous bedside navigation, adaptive follow-up conversation, and automatic structured report generation. It is designed for in-hospital postoperative follow-up, where bedside interviews and manual documentation remain clinically important but time-consuming and labor-intensive, and where existing web questionnaires, apps, or automated calls either rely on inflexible scripted interaction or raise privacy concerns because of cloud dependence (Chen et al., 21 Jul 2025).
1. Clinical role and motivation
Postoperative follow-up is used to monitor recovery and identify complications after surgery. In the workflow targeted by FollowUpBot, staff ordinarily visit patients at the bedside, ask follow-up questions, and document the answers. The paper presents this as a setting in which rising surgical volume and nursing shortages make manual follow-up costly and error-prone. FollowUpBot is therefore positioned as a system that preserves face-to-face bedside interaction while automating routing, questioning, and documentation (Chen et al., 21 Jul 2025).
A central design goal is adaptive rather than fixed follow-up. The robot is intended to ask questions based on patient profile and real-time responses, instead of running a rigid form or telephone script. A second goal is privacy-preserving deployment. The paper emphasizes that both dialogue and report generation are executed on edge devices, so patient interactions do not need to be sent to cloud APIs. This local deployment is presented as a way to reduce privacy leakage risk and avoid compliance and latency problems associated with cloud services (Chen et al., 21 Jul 2025).
2. System architecture and operational workflow
FollowUpBot is organized into three major modules: an Automatic Navigation Module, an Adaptive and Privacy-Preserving Follow-up Module, and an Automatic Report Generation Module. Its end-to-end workflow begins with ward mapping, proceeds through task retrieval and bedside navigation, and ends with structured report completion and local storage (Chen et al., 21 Jul 2025).
| Module | Function |
|---|---|
| Automatic Navigation Module | SLAM-based mapping, global route planning, local obstacle avoidance, bedside arrival |
| Adaptive and Privacy-Preserving Follow-up Module | Multimodal bedside conversation using local LLM inference |
| Automatic Report Generation Module | Field completion, extraction, normalization, and structured report assembly |
At startup, the robot performs SLAM-based 3D mapping of the ward and then remains in a standby state. When a new task arrives from the Operation Room Information System, it retrieves the patient ID, bed number, and surgery details. It then locates the bed in a semantic 3D map and computes a global path using A*-based search on a topological graph with costs adjusted by distance and environmental risk. Local motion is handled by a Model Predictive Controller together with a reinforcement learning policy for dynamic obstacle avoidance. As it approaches the bed, the robot slows down and confirms arrival using LiDAR before handing over to the interaction module (Chen et al., 21 Jul 2025).
The hardware stack includes an RGB camera, touchscreen, audio input/output, 2D LiDAR, RGB-D camera, wheel encoders, an IMU-assisted localization system, and dual edge devices for local inference and control. Ward mapping fuses LiDAR, RGB-D, and IMU data into a semantic 3D map that includes beds, walls, and restricted zones. The paper does not describe a biometric bedside identification stage; operationally, task assignment is tied to ORIS data and bed location rather than to an explicit face-recognition or wristband-verification step (Chen et al., 21 Jul 2025).
3. Dialogue management and report generation
The interaction design is multimodal. Patients can respond through speech, touch, or text; the robot presents dialogue on a screen and also produces speech output. The interface includes a patient information panel, a dialogue panel, and an input area. This multimodal design is motivated by the fact that postoperative patients may differ in physical and cognitive ability and therefore may not all use the same mode comfortably (Chen et al., 21 Jul 2025).
The follow-up module uses WiNGPT2-Llama-3-8B-Chat for dialogue, whisper-large-v3 for automatic speech recognition, and Llama-3.1-8B for report extraction. The conversation is field-oriented. The robot maintains a list of required postoperative fields, with examples including headache, dizziness, and nausea. Each field has a label, a type, and a description. The system selects the next unfilled field, asks a targeted question, interprets the patient response, extracts a value, marks the field complete, and moves on until all required fields are filled (Chen et al., 21 Jul 2025).
Report generation is likewise field-aware. For each required field, the extraction model is guided by the field description and by the report schema. The paper distinguishes single-choice fields, numerical fields, and text fields. For strict-format fields, a postprocessing step uses nli-deberta-v3-base to map a free-form extraction to a valid predefined option by selecting the option with the highest entailment score. In the formulation given in the paper briefing, this normalization step can be written as
where is the extracted answer and is the valid option set for the field. Once all required fields are completed, the structured postoperative report is assembled in the hospital’s format and saved locally (Chen et al., 21 Jul 2025).
4. Empirical evaluation
The paper reports both real-world feasibility and quantitative benchmark results. The robot was deployed in Guangdong Provincial People’s Hospital, where it successfully navigated inpatient wards and completed automatic follow-up with real patients. The main quantitative evaluation, however, is based on a synthetic dataset of 100 postoperative follow-up cases generated using GPT-4o. Each case contains a patient profile, a multi-turn dialogue with field-level annotations, and a structured report (Chen et al., 21 Jul 2025).
In simulated follow-up conversations, FollowUpBot is compared against a prompting-only WiNGPT2 baseline. The headline result is coverage: FollowUpBot achieves 100% coverage, whereas the baseline reaches 53.8%. The paper also reports that FollowUpBot outperformed the baseline on most of the six simulated patient-satisfaction dimensions measured on a 5-point Likert scale, although the exact per-dimension values are not provided in the text (Chen et al., 21 Jul 2025).
For report generation, the paper gives ablations over three settings: Description only, + NLI, and the Full system. The strongest results are obtained with the full pipeline. For single-choice fields, the full system reaches 0.9144 accuracy and 0.9912 BERTScore F1. For numerical fields, it reaches 0.9920 accuracy with 0.0300 mean absolute error. For text fields, it reaches 0.8513 BERTScore F1. The ablation pattern shows that NLI-based normalization contributes most of the gain for single-choice and numerical fields, while explicit field tracking produces additional gains, especially on text fields (Chen et al., 21 Jul 2025).
These results matter because they separate conversational adequacy from documentation adequacy. The system is not only assessed on whether it asks the right questions, but also on whether it can convert dialogue into structured outputs that match a hospital template. This makes the evaluation closer to an operational documentation task than to open-ended chatbot benchmarking (Chen et al., 21 Jul 2025).
5. Relation to adjacent follow-up research
FollowUpBot belongs to a broader research space in which follow-up is treated as a structured information-seeking or workflow-management problem rather than as unconstrained dialogue. In asynchronous patient-provider messaging, for example, “Follow-up Question Generation For Enhanced Patient-Provider Conversations” introduces FollowupQ, a multi-agent framework that processes patient messages and EHR data to generate personalized follow-up questions. That system is reported to reduce requisite provider follow-up communications by 34%, improve performance by 17% and 5% on real and synthetic data, and release a public dataset of asynchronous medical messages with linked EHR data and 2,300 expert-written follow-up questions (Gatto et al., 21 Mar 2025). FollowUpBot differs from that setting in embodiment and workflow: it operates at the bedside, after surgery, with local multimodal interaction and report generation rather than asynchronous portal clarification.
A second neighboring line of work concerns extraction of follow-up instructions from clinical text. “Extraction and Analysis of Clinically Important Follow-up Recommendations in a Large Radiology Dataset” identifies recommendation sentences in radiology reports and extracts reason, test, and time frame, achieving 0.92 F-score for recommendation sentence detection, 0.65 for reason, 0.73 for test, and 0.84 for time frame extraction (Lau et al., 2019). That work addresses follow-up as a text-mining and longitudinal audit problem over millions of reports, whereas FollowUpBot addresses follow-up as an embodied conversational workflow. The connection is methodological: both systems turn free clinical language into structured follow-up data.
A third adjacent problem is assistant turn-taking in follow-up conversation. “Device-Directed Speech Detection for Follow-up Conversations Using LLMs” shows that jointly modeling the previous query and ASR uncertainty yields 20–40% false-alarm reduction at 10% fixed false rejects for follow-up device-directed speech detection (Ognjen et al., 2024). This suggests that conversational follow-up systems can benefit from explicit modeling of previous-turn context and uncertainty, even when the main task is not command classification.
6. Limitations and significance
The paper’s main limitations are tied to evaluation scope. Although real-hospital feasibility is demonstrated, the principal quantitative results are based on a synthetic 100-case dataset rather than on a large real-patient trial. The paper does not report large-scale real-patient demographics, ward-scale operational statistics, navigation success rates, path efficiency, collision rates, ASR error rates, latency, or hardware-resource usage. Dialogue safety is only partially specified: the system includes structured field tracking and NLI-based normalization, but the paper does not define escalation rules for severe symptoms, clinician handoff logic, or emergency conversation policies (Chen et al., 21 Jul 2025).
These limits are important because they separate system feasibility from clinical deployment readiness. The reported results establish that the architecture can integrate navigation, adaptive follow-up, and structured report generation in one edge-deployed robot. They do not yet establish hospital-scale performance, long-term robustness, or safety policy sufficiency. The paper therefore positions FollowUpBot less as a finished clinical product than as a working systems prototype for privacy-preserving postoperative follow-up automation (Chen et al., 21 Jul 2025).
Its significance lies in that integration. The authors present FollowUpBot as the first postoperative follow-up robot integrating navigation, interaction, and report generation. More broadly, it marks a shift from fixed questionnaires and scripted automated calls toward embodied, field-aware, locally deployed follow-up systems. This suggests a research trajectory in which bedside conversational robots, structured clinical extraction, and workflow-aware follow-up question generation become increasingly connected components of clinical monitoring infrastructure (Chen et al., 21 Jul 2025).
