Invite-only testers
Cardiac specialists, cardiology trainees and junior doctors interested in reviewing triage behaviour, retrieval grounding and answer quality.
AI / RAG portfolio · invite-only clinician testing
Cardiac Aftercare
A safety-first cardiac recovery companion built around governed RAG, deterministic triage and constrained on-device LLMs.
Designed for UK/NHS-style post-discharge recovery questions. Currently open only to invited cardiac specialists and junior doctors evaluating the prototype — not for patients or public distribution.
What Cardiac Aftercare is
Cardiac Aftercare helps adults recovering after a cardiac event or procedure ask free-text recovery questions and receive plain-English answers grounded only in approved NHS / BHF / NICE-derived sources.
Before any answer is composed, every message passes a safety-first triage engine. Red-flag results stop generation and return vetted escalation wording. The system never tells a patient they are “safe,” and it does not diagnose, prescribe or interpret ECGs.
- Heart attack / MI recovery
- PCI / coronary stent aftercare
- CABG and cardiac surgery recovery
- Heart failure pathway support
- Valve disease / TAVI recovery
- Pacemaker, ICD, CRT and ILR pathways
- LVAD escalation-only scope
- Cardiac rehab and secondary prevention
Who can test it now
Distribution is intentionally narrow while clinical safety and governance work continues.
Not available to
Patients, carers, the general public, or any App Store / open distribution channel until Clinical Safety Officer sign-off and regulatory readiness.
RAG & LLM development phases
This page is written as an AI / modelling portfolio piece. The build order was deliberate: govern the knowledge, lock safety rules, then add constrained generation — not “train a chatbot on PDFs.”
Knowledge pipeline
Source register, ingestion, cleaning, clinical metadata, chunking, indexing and retrieval testing across a curated NHS/BHF/NICE-first corpus.
Safety layer first
Red / amber / yellow / green / blue triage rules, medication and safeguarding overlays, escalation wording and local audit before any generative path.
Governed RAG assistant
Question handling, BM25 retrieval over approved chunks only, prompt construction from retrieved evidence, answer validation and source traceability.
Evaluation & clinician review
Retrieval and red-flag evaluations, clarification-depth evidence packages, CARE-RAG review portals and clinician assessment workflows.
On-device redesign
Moved from networked server RAG to a privacy-first on-device pack: no patient free text leaves the phone; template fallback if the local LLM fails.
Constrained LLM roles
llama.cpp + Qwen2.5-1.5B-Instruct (Q4_K_M), temperature 0 / seed 0, used only for escalate-only safety classification, clinical interpretation and grounded composition.
Runtime answer pipeline
Every patient-style message follows the same fail-closed path. Generation is optional; escalation and templates are not.
01 profileBuild pathway-aware patient context (recovery day, procedure, device status).
02 triageLayer 0 deterministic rules → Layer 1 semantic similarity → Layer 2 on-device LLM classifier (escalate-only).
03 overridesMedication safety and safeguarding rules can only raise severity, never suppress a deterministic hit.
04 stop gateRed / stop-answer paths return vetted escalation wording and skip retrieval entirely.
05 dialogueBounded clarification turns resolve uncertainty before retrieval; exhausted budget triggers a safety net.
06 retrieveBM25 over the approved on-device knowledge pack (pathway-aware, top-k), with sufficiency checks.
07 composeOn-device LLM writes from approved snippets only; fixed headings and reading-age constraints.
08 validateStructural / safety validator; any failure falls back to a byte-identical template answer.
Modelling choices that matter for hiring conversations
The modelling story is about constraint, evaluation and clinical governance — not unconstrained chat.
Retrieval, not fine-tuning
The corpus is a governed retrieval pack. Patient answers cite approved chunks; the assistant is not trained to invent cardiac advice.
Escalate-only LLM safety
Layer 2 returns a triage category only. It never writes patient-facing text and cannot downgrade a deterministic red flag.
Deterministic decoding
Composer and interpreter run greedy decoding (temp 0, seed 0) with timeouts, JSON repair, closed taxonomies and template fallback.
Fail-closed gating
Pathway / topic tags and approval gates block unapproved content. Incomplete profiles block personalised green-path answers.
Evidence packages
Phased clarification-depth evaluation, CARE-RAG governance portals and clinician research tooling support review before any patient release.
Privacy posture
Current architecture is on-device: no networked LLM for patient answers, no server-side patient free-text store, local audit only.
Technical stack snapshot
| Client | Flutter (iOS + Android) with shared Dart triage / RAG services |
|---|---|
| On-device LLM | llama.cpp · Qwen2.5-1.5B-Instruct Q4_K_M · MethodChannel bridge |
| Retrieval | BM25 over approved knowledge pack (~966 chunks from clinician-gated sources) |
| Triage | 51+ deterministic rules + semantic escalate layer + constrained LLM classifier |
| Corpus governance | 191 registered sources → approved / withheld split → pathway-tagged chunks |
| Reference / parity | Python triage engine, pytest suites, CARE-RAG review + governance portals |
| Earlier server path | FastAPI + PostgreSQL / pgvector prototype retained as historical architecture context |
How invite-only testing works
- A cardiac specialist or junior doctor requests access and confirms they understand this is not for live patients.
- Invited testers exercise triage, clarification, retrieval grounding and answer quality on synthetic / non-patient scenarios.
- Feedback feeds clinician review workflows and CARE-RAG governance packages.
- Patient or public release remains blocked until Clinical Safety Officer sign-off and regulatory readiness.
Related internal review surface (unlisted): CARE-RAG governance review portal.
Frequently Asked Questions
Is Cardiac Aftercare available to patients?
No. The app is not available for patient or public distribution. Access is limited to invited cardiac specialists and junior doctors evaluating the prototype.
What AI techniques does Cardiac Aftercare use?
It combines deterministic clinical triage rules, BM25 retrieval over a clinician-governed knowledge pack, escalate-only semantic similarity, and constrained on-device LLM roles for safety classification, clinical interpretation and grounded answer composition.
Does the app diagnose or prescribe?
No. It does not diagnose, prescribe, change medication, interpret ECGs or images, or replace emergency care or clinician judgement.
Who can request access?
Cardiac specialists, cardiology trainees and junior doctors interested in testing the governed RAG and on-device LLM prototype may request invite-only access.
Is this affiliated with the NHS?
No. Cardiac Aftercare is an independent development prototype. It is not affiliated with, endorsed by, or approved by the NHS, NICE, BHF or any hospital trust.
Why show this on a public website if it is invite-only?
The public page documents the AI / RAG / modelling approach for portfolio and collaboration purposes. The product binary and patient distribution remain closed.
Important notes
Cardiac Aftercare is an independent development prototype by Random Mini Apps. It is not affiliated with, endorsed by, or approved by the NHS, NICE, the British Heart Foundation, MHRA, Apple, Google, or any hospital trust.
Content grounded in publicly available guidance remains subject to licence, clinical review and local trust variation. Do not use this prototype for real patient advice. In an emergency, call 999.
Request clinician testing access
If you are a cardiac specialist or junior doctor interested in evaluating the RAG / triage / on-device LLM prototype, get in touch. Patient and public distribution remain closed.