Written by Clinical Decision Support · Agentic AI · Workflow Automation
A five-step agentic pipeline that takes patient lab data, searches NIH PubMed in real time, and delivers a source-cited, confidence-scored clinical brief to the clinician’s inbox — in under 60 seconds
Open research contribution · built on n8n, SerpApi, GPT-4o, Nutrient DWS, and Foxit eSign · confidence gate validated on live executions · by Uday Shankar Bhowal · Lead Analyst, Cigna Evernorth · MS Healthcare Informatics · GitHub · ORCID 0009-0008-3908-5730 · September 2026
Clinical Decision Support is a multi-billion dollar global problem. Clinicians spend over two hours per complex patient case searching literature and writing structured briefs. Most AI tools either hallucinate clinical recommendations — which is dangerous — or cost $50,000 per year in enterprise licensing. There is no open, inspectable, evidence-grounded CDS pipeline that any clinic can run without enterprise software. ClinicalBrief AI is that pipeline.
This post walks through how it works: the architecture, the confidence gate, the RAG knowledge base, and why chaining three APIs together — rather than bolting them on separately — is what makes the design hold up under real clinical data.
Watch the dots: six stages, one feedback arc. The orange dashed return is the audit trail that informs future confidence scoring.
What Clinical Decision Support (CDS) actually means
And why the existing tools fail the clinics that need them most.
Clinical Decision Support refers to any health IT system that helps clinicians make evidence-based decisions at the point of care. Tools like UpToDate and DynaMed charge $500 or more per clinician per year. Epic’s CDS module runs into six figures. For a small clinic or rural health system, this is simply not accessible.
The secondary problem is hallucination. When AI tools generate clinical recommendations from training data, they can produce plausible-sounding but factually incorrect guidance — a hallucinated drug dosage or contraindication can harm patients. The solution is not a better model; it is grounding the model in real retrieved evidence before generation. That is what Retrieval-Augmented Generation (RAG) does, and it is the architectural foundation of ClinicalBrief AI.
How ClinicalBrief AI works
Five steps, under 60 seconds, end to end.
1. Patient intake via Google Sheet
A patient or pharmacy staff fills in lab values — HbA1c, LDL, BMI, blood pressure, medications, diagnoses. No app. No login. The Google Sheets Trigger polls every 60 seconds for new rows and fires the pipeline automatically.
2. SerpApi queries NIH PubMed in real time
Before the AI generates anything, SerpApi searches Google Scholar using the patient’s diagnoses as the query. Three current peer-reviewed publications are retrieved and injected into the agent prompt. This is the key differentiator: the agent works from 2024 and 2025 evidence, not frozen training data.
3. GPT-4o agent reasons over patient data, PubMed evidence, and RAG guidelines
The agent runs at temperature 0.1 — near-deterministic. It receives the patient’s lab data, the live PubMed results, and passages retrieved from a RAG knowledge base of six clinical guidelines. It produces a structured JSON brief: summary, primary diagnosis, risk level, numbered recommendations with evidence citations, drug interactions, and a confidence score.
4. Confidence gate decides routing
A deterministic IF node — not the model — evaluates the combined confidence score. Above 80%: the brief goes to Foxit eSign. Below 80%, or when extreme clinical values are present (HbA1c above 10%, LDL above 190 mg/dL, BMI above 40, systolic BP above 160), the case routes to human review. The agent cannot override this gate.
5. Foxit eSign delivers the signed brief
The clinician receives an HTML email with the full brief and a Foxit eSign signing request. The clinician must sign. The agent cannot sign on their behalf. That boundary — between what the agent does and what the human must authorize — is the core responsible AI design principle of this project.
The confidence scoring formula
Two independent signals, averaged, with a clinical threshold override.
The formula: confidence_score = (agent_score + extraction_confidence) / 2. The agent score is GPT-4o’s self-assessment of how well the retrieved evidence supports each recommendation (0–1). The extraction confidence is the average field-level score across the lab values — penalised when data is vague (“unknown supplement”, “possible metabolic issue”) or when clinical values exceed safety thresholds. The combined threshold is 0.80.
| Condition | Score applied | Routing |
|---|---|---|
| Normal lab values, clear diagnosis | 0.88 – 0.96 | ✅ Auto-sign via Foxit eSign |
| Vague medications or diagnosis | 0.40 – 0.42 on affected fields | ⚠️ Human review |
| HbA1c >10%, LDL >190, BMI >40, BP >160 | 0.60 – 0.62 on flagged fields | ⚠️ Human review + clinical flags |
| Agent JSON malformed or missing fields | Hard error — no score | ⚠️ Human review |
The RAG knowledge base
Six clinical guidelines, embedded and retrievable — grounding every recommendation in named, citable source text.
1. Seed the knowledge base
Six open-access clinical protocol documents load into n8n’s in-memory vector store using OpenAI’s text-embedding-3-small at 1,536 dimensions, stored under the key clinical_protocol_kb. Sources: ADA 2024, ACC/AHA 2023, JNC 8, WHO Metabolic Syndrome, NKF KDIGO 2023, USPSTF 2024.
2. Retrieve on each run
The agent calls retrieve_clinical_protocols autonomously — typically 3 to 4 tool calls per execution. The query is the patient’s diagnosis and lab context. Top-3 matching passages are returned by cosine similarity.
3. Inject alongside PubMed evidence
Retrieved protocol passages and the SerpApi PubMed results merge into the agent prompt before generation. When the agent cites “ADA 2024” in a recommendation, that text came from the embedded document — not a training-data recollection.
Why chained — not bolted on
The three external APIs are not independent integrations. They are a chain: each one’s output is the required input for the next. Nutrient DWS structures the lab data. SerpApi retrieves the evidence the agent reasons over. Foxit eSign certifies the output the agent produced. Remove any one and the pipeline breaks — not degrades, breaks. That dependency is the design, not a side effect.
What the clinician receives
What makes it different
Five design decisions that separate this from a prompt-wrapped chatbot.
Live evidence, not training data
SerpApi retrieves current PubMed publications before every brief. The agent works from papers published this year, not from a training snapshot that may be two years old. Clinical guidelines change. The evidence layer keeps up.
RAG-grounded, not hallucinated
Every recommendation traces to a retrieved protocol document or a live PubMed link. The output parser enforces the schema — if the agent returns free text or skips a required field, the parser catches it and the brief does not proceed.
Deterministic safety gate
The confidence gate is an IF node. It is not probabilistic, not model-driven, not overridable. A brief below the threshold does not reach Foxit eSign regardless of what the model would prefer. Extreme clinical values force a review path even when numeric confidence is high.
Fully inspectable in n8n
Every node in the pipeline is visible and clickable. A clinician, a regulator, or a developer can open any execution and trace any recommendation back to the exact PubMed paper and RAG passage it came from. No black box. No hidden inference.
Human signs — agent cannot
Foxit eSign is not decorative. The agent generates the brief. The clinician must sign it before it is sealed. That boundary is the point — responsible CDS means the human authorizes the output, not the model.
Honest caveats
| Component | Current state | Production path |
|---|---|---|
| Nutrient DWS | Simulated — reads from Google Sheet columns | Real PDF upload → Nutrient Data Extraction API |
| Foxit eSign | Sandbox endpoint returns 404 — pipeline continues | Correct production endpoint from Foxit developer portal |
| RAG store | In-memory — resets on n8n restart | Supabase pgvector — persistent, no reseed needed |
| Patient data | Demo data — not real patient records | Real integration requires HIPAA-compliant data handling |
Try it or build on it
The full pipeline is open. Both n8n workflow JSONs are exported with credentials scrubbed and placeholder variables documented. The RAG knowledge base seeds from public domain clinical guidelines. The confidence gate threshold, the clinical flag thresholds, and the SerpApi query construction are all adjustable in plain JavaScript code nodes — no build step, no config file.
GitHub: github.com/udaytx009/clinicalbrief-ai
n8n main workflow: sBl3HSAqigFBB2t1 · Seed KB: SStYwG7ydw4gwliW
Notes
- ClinicalBrief AI is an open research contribution voluntarily published under LearnHive Labs by Uday Shankar Bhowal. It is not affiliated with Cigna Evernorth or any employer.
- This is not a medical device and does not constitute medical advice. It is a proof-of-concept CDS automation pipeline intended for research and demonstration purposes.
- Clinical guidelines referenced: ADA Standards of Medical Care 2024, ACC/AHA Cardiovascular Risk Guidelines 2023, JNC 8 Hypertension Guidelines, WHO Metabolic Syndrome Criteria, NKF KDIGO CKD Guidelines 2023, USPSTF Preventive Care Recommendations 2024. All are open-access or public domain.
- SerpApi results in the pipeline are real-time Google Scholar queries — the specific papers returned vary by execution date.
- Confidence scoring validated on live n8n executions (execution IDs 56–113) during development. Not validated on clinical populations.
LearnHive Community
Ready to connect with fellow learners?
Share ideas, ask questions, and grow together — join the LearnHive Community today.
Join the LearnHive Community →