# FeverMate Clinical Copilot
## Inspiration
In many primary-care settings, the problem is not a complete absence of clinical information. The problem is that useful information is scattered across previous consultations, laboratory results, medication lists and handwritten or electronic notes.
Clinicians must reconstruct that story quickly, sometimes with unreliable connectivity, limited referral capacity and hardware that cannot run large cloud-dependent systems.
As a doctor, I wanted to explore a practical question:
> Can a compact language model run completely offline, inside an electronic health record, and help a clinician recognise important changes in a patient's condition?
That question became **FeverMate Clinical Copilot**: an offline, EHR-native clinical reasoning assistant designed for primary-care environments.
## What it does
FeverMate reads a structured patient record and produces a concise, clinician-facing assessment containing:
- The current clinical picture
- Prioritised problems and differential diagnoses
- Evidence linked to the patient’s documented findings
- Immediate management and investigation priorities
- Medication and comorbidity considerations
- Missing information and uncertainty
- Safety and disposition considerations
The interface also highlights longitudinal changes. For example, it can compare a patient's current potassium and creatinine with previous results instead of treating each measurement in isolation.
FeverMate supports qualified clinicians. It does not autonomously diagnose, prescribe, refer patients or write decisions back into the EHR.
## How we built it
We began by testing several compact language models against the competition’s deployment constraints. The selected foundation model was:
**Qwen2.5-1.5B-Instruct**
It provided the best practical balance between reasoning ability, memory usage, speed, licensing and `llama.cpp` compatibility.
We then built a frozen 66-case private clinical-reasoning benchmark covering areas such as:
- Clinical synthesis
- Differential diagnosis
- Investigation strategy
- Emergency management
- Maternal and child health
- Medication safety
- Missing-information handling
- Longitudinal reasoning
- Numerical value sensitivity
The benchmark was kept separate from the training data.
The initial model was good at listing investigations but unreliable at deciding what should happen next. It also failed all seven matched value-sensitivity pairs, sometimes responding to the presence of a result rather than correctly interpreting its numerical value.
Those failures directly shaped our training strategy.
We created a supervised fine-tuning corpus covering primary-care reasoning, emergency prioritisation, investigations, medication interactions, reassessment and clinical communication. It included matched examples where small changes in values required different clinical responses.
The final training run used:
- 1,000 supervised training examples
- 100 separate development examples
- LoRA fine-tuning
- Completion-only loss
- Group-preserving splits for matched examples
- A Qwen-specific chat template
The trained LoRA adapter was merged safely into the FP16 base model, converted to GGUF and quantised to **Q4_K_M**.
The final model is approximately **986 MB**.
```text
EHR record
↓
FeverMate prompt and chart renderer
↓
Fine-tuned Qwen2.5 1.5B
↓
Q4_K_M GGUF running through llama.cpp
↓
Evidence-linked clinical assessment
The demonstration interface connects an EHR-style patient record to llama-server. The browser displays the patient’s longitudinal history while the model performs inference inside a constrained Linux virtual machine.
No cloud inference API, retrieval service or internet connection is required after downloading the model.
Deployment results
The final model completed the official participant-mode profiler on CPU:
| Metric | Result |
|---|---|
| Model parameters | 1,543,714,304 |
| Parameter metadata match | true |
| Quantised model size | 986,047,968 bytes |
| Generation speed | 13.96 tokens/second |
| First-token latency | 16.40 seconds |
| Peak memory | 1,572.50 MB |
| Steady-state memory | 1,371.28 MB |
| ARC Easy, 50 samples | 0.72 acc_norm |
| Thermal throttling | false |
The same GGUF was also downloaded anonymously and launched successfully inside a separate CPU-only Linux virtual machine.
ARC Easy measures general reasoning performance; it is not presented as evidence of clinical safety or clinical accuracy.
Challenges we faced
Teaching a small model to interpret values
The most important failure was numerical insensitivity. The base model sometimes called normal measurements abnormal, underestimated dangerous results or gave similar recommendations when only a critical value had changed.
We learned that ordinary question-and-answer examples were insufficient. The training data needed matched cases in which the clinical context remained similar while one meaningful value changed.
Balancing useful treatment advice with safety
A clinical assistant that merely says “refer according to local protocol” is safe-sounding but often unhelpful. However, giving doses without checking eligibility, contraindications, monitoring and local capability can also be unsafe.
We therefore trained the model to identify indicated treatment classes and provide appropriate guidance while preserving uncertainty and capability-aware escalation.
Running within limited memory
Larger models offered potential reasoning advantages but used substantially more memory and generated more slowly. Quantisation was essential.
Q4_K_M gave us a deployable model with substantial headroom under the 8 GB competition limit.
Building a reproducible pipeline
Training happened on a Kaggle GPU, while conversion, quantisation and final validation used llama.cpp. Maintaining model lineage across the base model, LoRA adapter, merged checkpoint and GGUF required manifests and SHA-256 verification at every important stage.
What we learned
We learned that a high aggregate benchmark score can hide clinically important failures. Hard-failure rates, emergency-case performance and matched perturbation pairs were more informative than one average score.
We also learned that fine-tuning a compact model is particularly effective at improving:
- Response structure
- Evidence-linked explanations
- Clinical prioritisation style
- Missing-information disclosure
- Clinician-facing communication
However, structured output is not the same as clinical safety. Small models can remain inconsistent even when their answers look polished.
This is why FeverMate is designed as a copilot rather than an autonomous decision-maker.
Accomplishments we are proud of
- Built an end-to-end clinical fine-tuning pipeline
- Created a private, contamination-protected clinical benchmark
- Trained and merged a custom LoRA adapter
- Converted and quantised the model into a 986 MB GGUF
- Passed the official profiler with
params_match=true - Ran the model on a constrained CPU-only Linux environment
- Published the model through a public, credential-free download
- Integrated real local inference into an EHR-style interface
- Preserved a fully offline runtime after model download
What is next
The next stage is not simply adding more examples. We want to improve the quality and diversity of matched numerical cases, increase coverage across primary-care presentations and test the model with independent clinical reviewers.
Future work includes:
- Better numerical and temporal reasoning
- More low-risk cases to reduce inappropriate escalation
- Expanded maternal, paediatric and chronic-disease coverage
- Structured medication eligibility and monitoring checks
- Faster response generation on low-end CPUs
- Controlled EHR integrations with audit trails
- Prospective usability studies with clinicians
FeverMate demonstrates that useful clinical reasoning support does not always require a massive cloud model. A compact, carefully evaluated model can run privately and offline, bringing practical AI assistance closer to frontline primary care.
Log in or sign up for Devpost to join the conversation.