---
title: 'FollowUpBot: LLM Robot for Postoperative Care'
url: https://www.emergentmind.com/topics/followupbot
type: topic
---

# FollowUpBot: LLM Robot for Postoperative Care

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 [2507.15502].

## 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 [2507.15502].

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 [2507.15502].

## 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 [2507.15502].

| 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 [2507.15502].

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 [2507.15502].

## 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 [2507.15502].

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 [2507.15502].

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
\[
\hat{y} = \arg\max_{o \in \mathcal{O}} \operatorname{EntailmentScore}(a, o),
\]
where \(a\) is the extracted answer and \(\mathcal{O}\) 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 [2507.15502].

## 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 [2507.15502].

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 [2507.15502].

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 [2507.15502].

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 [2507.15502].

## 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 [2503.17509]. 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 [1905.05877]. 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 Large Language Models” 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 [2411.00023]. 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 [2507.15502].

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 [2507.15502].

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 [2507.15502].

Source: https://www.emergentmind.com/topics/followupbot