Between 2020 and 2025, MultiMed Engineers participated in the BD4QoL project, which investigated how digital technologies and Artificial Intelligence could support the follow-up and quality of life of people treated for head and neck cancer. Among other activities, the project explored the unobtrusive collection and interpretation of behavioural data, the recognition of affective traits, risk assessment, clinical alerting and a conversational e-coach supporting patient self-management.

MultiMed Engineers contributed to the original conception of the project, to the modelling of behavioural and affective features, and to the assessment of its potential value through Health Technology Assessment.

Since the BD4QoL concept was originally formulated, however, the technological landscape has changed substantially. In particular, modern Large Language Models (LLMs) make it possible to revisit several functions that previously required combinations of conventional software, manually specified rules and dedicated Machine Learning models.

MultiMed Engineers has conducted an exploratory experiment aimed at reflecting on this evolution and at investigating the following exemplary question:

Which functions explored in BD4QoL could today be reimplemented—or extended—by treating an LLM as a general-purpose reasoning component instructed in natural language?

The objective was not to develop a new clinical product. It was to understand, through a working proof of concept, what changes when LLM-based reasoning is introduced into an architecture for digital self-empowerment and self-management.

From software functions to reasoning tasks

The working hypothesis behind the experiment—formulated by MultiMed Engineers—is to consider an LLM as a system capable of performing bounded reasoning tasks when provided with an appropriate problem description, relevant knowledge and constraints.

This, in turn, leads to a different implementation approach.

In conventional software development, a domain requirement must progressively be translated into algorithms, data structures, rules and programming-language instructions. This process starts close to the domain experts, that express the need that the system must solve, but end far from them, in a code-base written in a programming language that only experts can understand.

With an LLM, part of this translation can instead stop at a much higher level of abstraction: the required system behaviour is expressed in prompts, which are artefacts directly written in natural language, that can be understood by domain experts.

Consider, for example, the problem of classifying a collection of health-promotion resources.

In previous projects such as BD4QoL, but also City4Age and GATEKEEPER, resources intended for patients had to be manually collected, inspected and classified according to domains such as mobility, nutrition or sleep. In the MultiMed Engineers’ exploratory implementation, this task was insteaf assigned to a Content Agent through instructions such as:

“You are a medical oncologist and you have been asked to classify a certain number of health promotion resources, suitable for elderly patients who have been treated for cancer…”

The agent receives the resources and returns a structured classification comprising category, title and description.

The important change is not merely that an AI model performs the classification. It is that the specification of the task itself is expressed in language that a medical expert can directly read, question and modify.

Figure 1. Example from the experiment: a natural-language prompt specifies the task assigned to the Content Agent, while a structured output model defines the information that the software expects from the LLM.

“LLM-ising” a digital follow-up architecture

The proof of concept developed by MultiMed Engineers decomposes the overall problem into a set of specialised agents. They revisit functions previously investigated in BD4QoL, City4Age and GATEKEEPER, while also exploring new possibilities made practical by LLM technology:

• Content Agent – reads and classifies health-promotion resources so that they can subsequently be selected according to patient needs.
• Behaviour Agent – interprets patient-generated activity data, such as step-counter time series, extracting higher-level features including trends, intensity, variability and missing-data patterns.
• Affective Agent – analyses the conversation with the patient to obtain an assessment of emotional status.
• Anamnesis Agent – reconstructs health problems reported during conversations and produces a concise report that could be made available to a clinician at follow-up.
• Own Data Agent – turns personal activity data into short comments intended to stimulate patient reflection on his or her own behaviour.
• Information Agent – selects relevant material from a predefined collection of health-promotion resources and prepares an accompanying personalised message.
• Symptoms Agent – responds to symptom-related requests using a restricted, authoritative source of medical information rather than relying on unconstrained generation.
• Risk Agent – combines behavioural, affective and anamnesis information into a multidimensional assessment and assigns the situation to one of several possible actions, ranging from continued self-management to requesting more information or escalating the case towards healthcare professionals.

This is not simply a collection of independent prompts. The agents are connected through an elementary orchestration layer so that their outputs become inputs to subsequent reasoning steps.

Figure 2. Exploratory multi-agent architecture. Patient-generated device data and conversations are interpreted by specialised agents; the resulting higher-level information is integrated by the Risk Agent and can drive personalised information, symptom-management interactions or escalation towards healthcare professionals.

A small but complete experiment

The experiment has been implemented as a lightweight simulation of longitudinal follow-up, developed in a Jupyter Notebook, in Python:

• A simple software clock schedules periodic activities
• Device data are analysed; recent conversations are used to update anamnesis and affective status
• A Risk Agent periodically reassesses the available information
• Health-promotion resources and personal-data feedback are delivered at scheduled times
• Direct patient requests are processed as they occur.

For example, in one illustrative run, the simulated patient first reports dizziness and subsequently adds persistent fatigue and concern about cancer recurrence. The system progressively incorporates this information into its representation of the patient’s status. It can provide symptom-related information, update the anamnesis, reconsider the risk assessment and select subsequent actions (Figure 3).

RISK ASSESSEMENT
Dizziness reported with high activity intensity and data gaps; no current red flags, but insufficient data to gauge risk accurately.
EXPLANATION
Dizziness is reported without immediate red flags (no chest pain, confusion, focal weakness, fainting). However, high intensity/variability in activity and pronounced missing data limit interpretation. Dizziness can stem from dehydration, anemia, medications, or infection in cancer survivors. Seek more details (onset/duration, triggers, associated symptoms, vitals, medications, recent treatments) to better assess and plan follow-up; advise safety precautions until clarified.
**RECOMMENDED ACTION**: ask_the_patient_more_information_on_health_status

Figure 3. Exemplary reasoning results from the Risk Agent, including recommendation of next steps.

The example is exploratory and its clinical outputs have not been validated for patient use. However, it still demonstrates the technical possibility of constructing a continuous reasoning cycle in which heterogeneous information—device measurements, conversational information, emotional signals and previously reported health problems—can be progressively transformed into higher-level representations and used to select subsequent actions.

This also illustrates an important architectural finding from the experiment: LLMs do not need to replace conventional programming in toto.

Deterministic software could effectively remain responsible for aspects such as timing, event management, agent invocation, data exchange and orchestration, while LLMs are best introduced where the problem requires interpretation of information, application of domain knowledge or reasoning over heterogeneous evidence.

The best architecture is therefore hybrid: conventional code is used where precision and predictable execution are essential; LLMs are used where flexibility and semantic reasoning provide an advantage.

Prompts as a new interface between engineers and domain experts

As previously mentioned, an most interesting consequence concerns the development process itself.

A traditional software component can ultimately be reviewed in detail only by somebody able to understand its programming language, libraries, data structures and implementation architecture. A medical oncologist or psychologist can discuss its requirements and inspect its outputs, but usually cannot directly inspect the implementation that connects one to the other.

An LLM prompt is radically different.

Even when embedded in a more complex agent architecture, its core instructions remain natural-language statements about the task to be performed. They can therefore be read directly by clinicians and other domain experts.

A medical oncologist can challenge whether a Risk Agent has been asked to consider the right evidence. A psychologist can revise the conceptualisation used by an Affective Agent. A clinician can discuss whether an escalation rule corresponds to the intended follow-up process.

Prompt engineering can therefore become not only an implementation technique but also a co-design interface between software engineers and healthcare professionals.

This ability of the domain expert to inspect and discuss a substantial part of what appear to be the system’s “executable specification” represents a material change in the relationship between domain knowledge and software implementation (Figure 4).

Figure 4. Two ways of translating domain knowledge into executable behaviour. Conventional development progressively translates requirements into detailed program logic. In an LLM-based component, a larger part of the executable specification remains expressed in natural language and can therefore be reviewed directly with domain experts.

What the experiment does not solve

The experiment also helped to make several research questions more explicit.

One concerns the objective function. A system intended to support long-term patient empowerment needs measurable objectives against which its behaviour can be assessed. Established Patient-Reported Outcome and Experience Measures (PROMs and PREMs) provide validated measurement instruments, but were generally designed as questionnaires rather than as continuous conversational interactions. How they should be combined with LLM-based interaction remains an open issue.

A second question concerns the scope of the conversation. A general-purpose LLM can respond to a virtually unlimited set of user requests, but this is not necessarily desirable in healthcare. An operational system may need a carefully defined set of intents and controlled knowledge repositories—for example, authoritative cancer symptom-management information—to constrain what the system is allowed to address.

A third issue is architectural: when is one sufficiently capable agent preferable to a network of specialised agents? Which tasks should remain conventional code? Which require explicit agent orchestration? The prototype provides a convenient environment in which these alternatives can be tested.

Finally, there is the question of the appropriate human role. The Health Technology Assessment work conducted by MultiMed Engineers in BD4QoL indicated that the amount of healthcare-professional time required by a digital follow-up intervention is an important driver of its economic sustainability. The objective is therefore neither unrestricted automation nor continuous professional supervision of every interaction, but the identification of those points at which human intervention creates the greatest clinical value.

From an exploratory prototype to a research and business-development direction

The experiment suggests that several ideas developed by MultiMed Engineers over ten years of work on City4Age, GATEKEEPER and BD4QoL can now be reconsidered from a substantially different technological perspective.

The underlying objectives remain familiar: interpreting patient-generated data, supporting reflection and health promotion, identifying emerging needs, providing appropriate information and connecting patients with healthcare professionals when necessary.

What changes is the implementation space.

LLMs make it possible to express some of these functions as high-level reasoning problems rather than implementing every semantic step through dedicated software components. At the same time, they introduce new requirements for validation, reproducibility, guardrailing, controlled knowledge access and clinical governance.

For MultiMed Engineers, exploring this combination of LLM-based reasoning, digital phenotyping, patient self-management and clinically governed follow-up represents an important research and business-development direction for the coming five years.

The next step is to determine, experimentally and together with domain experts, which parts of knowledge-intensive digital-health systems should remain programs, which can become prompts, and how the two can be combined into solutions that are technically reliable, clinically meaningful and economically sustainable.