In building Qu we understood the need to handle clinical tasks that range from the straightforward to the highly complex. These tasks can be broadly categorized into two types: System 1 reasoning, involving intuitive and straightforward processes such as understanding a user's intent, and System 2 reasoning which requires more sophisticated cognitive processing, like considering potential competing hypotheses while taking a clinical history. Our system must seamlessly handle both forms of reasoning in order to fulfill its goals.
Qu’s cognitive architecture is structured through the orchestration of multiple "agents” - LLM-based systems tailored to perform specific tasks or subtasks. These agents are designed to handle specialized operations and can leverage external databases or tools to fulfill their objectives. The orchestration is managed by a system - the “Qu Orchestrator” - that handles the control flow, maintains the conversation state, and facilitates the exchange of information between agents. This dynamic coordination allows for optimal task execution and allows the system to flexibly switch between System 1 and System 2 reasoning depending on the task at hand.
The Qu Orchestrator is a key component of the Qu Platform and is responsible for the following activities during a Consultation.
At the beginning of a consultation, Qu identifies the user’s Intent, or reason for the visit, and tracks any changes in intent to adjust the consultation as needed. Qu supports several Intents: Health problem, where the patient reports a new health issue and seeks guidance; Health Q&A, when the patient has a general health question without a specific complaint; Qu support, for questions about Qu’s capabilities; and Accept topic, where the user agrees to discuss a topic initiated by Qu. Requests outside these intents, such as financial advice, are marked as Invalid intent and are not supported.
Qu maintains the conversation state in each consultation to ensure appropriate responses. For instance, after discussing symptom-matching conditions, Qu will guide the conversation toward further investigations or treatments. This state acts as Qu’s short-term memory, complementing the longer-term memory in its Personal Health Record.
Qu selects the most suitable agent based on intent, pending tasks, and context from its Personal Health Record. This modular approach—routing queries to specialist agents rather than a single general-purpose LLM—optimizes each agent for specific tasks and allows independent evaluation. Depending on the agent, multiple LLM steps may be required, especially for complex reasoning. Selected agents can also retrieve relevant personal data from Qu’s Personal Health Record and clinical guidelines as needed.
Qu maintains a list of tasks that determines its agenda. At every turn of the consultation, the Qu orchestrator checks for uncompleted tasks and the agent necessary to complete it. This allows Qu to steer the consultation and allows the user to discuss unrelated topics before returning to the task at hand.
The Qu orchestrator implements a set of clinical guard rails. Qu is able to detect situations that are potentially emergencies such as risk of stroke.
Qu will determine when a consultation is concluded by seeking confirmation from the patient. Once a consultation is completed, it is automatically summarized by Qu, and the summary is offered to the patient and stored in the patient’s health record. Qu Knowledge baseAlongside the Orchestrator, which provides the reasoning capabilities of Qu, our system is highly dependent on its robust sources of clinical knowledge.
Taking inspiration from the process presented by Chen et al, we built a corpus of Clinical Practice Guidelines (CPGs). Clinical practice guidelines are rigorously researched frameworks designed to guide healthcare practitioners and patients in making evidence-based decisions. They have been sourced and curated from an extensive range of datasets, numbering in tens of thousands. They’ll be further fine tuned, curated and amended with time, and according to the specific needs of each community of clinicians and patients.
We have developed an automated process, using an LLM, to automatically search conditions through the corpus of CPGs and to summarize the relevant information in the KB. We explicitly model relevant clinical knowledge, into the Qu Knowledge Base (KB) by prioritizing the content. For each of these conditions we use an automated method to develop the content of our KB, categorizing it into Symptoms, Risk Factors, Investigations and Treatments.
This process is partly executed, monitored and audited by accredited doctors in the UK for quality assurance. The KB is used to guide Qu’s agents. It is also used as the ground truth to assist with our clinical testing and validation.