🧠 About the Project

💡 Inspiration

Sepsis is not a rare edge case — it is the default failure mode of modern hospital systems.

Despite decades of guidelines like the Surviving Sepsis Campaign and regulatory enforcement through Centers for Medicare & Medicaid Services SEP-1 measures, outcomes remain highly dependent on execution speed. Every hour of delay in antibiotics increases mortality by 4–7%.

What stood out wasn’t a lack of knowledge — clinicians already know what to do.

The problem is operational:

• Signals appear early but are buried in notes
• Decisions require synthesizing fragmented data
• Documentation determines reimbursement, not just care
• Existing systems (like the Epic Sepsis Model) miss the majority of cases

This led to a simple question:

What if an AI system didn’t just detect sepsis — but actually **ran the protocol, end-to-end, like a clinical co-pilot?

That question became SepsisGuard.

---

🏗️ How We Built It

SepsisGuard is not a chatbot — it is a multi-agent clinical execution system built around real healthcare standards.

Core design principles

1. FHIR-native from day one Every decision is grounded in structured clinical data using FHIR R4 — not scraped UI or mock schemas.

2. Agents with clear clinical roles Instead of one monolithic LLM, we decomposed the workflow into five specialized agents:

• Sentinel → detection
• Adjudicator → diagnosis reasoning
• Orchestrator → protocol execution
• Pharmacist → treatment planning
• Documentation → compliance-grade note writing

1. Tool-driven reasoning (MCP) Using Model Context Protocol, each agent operates through strict tool interfaces:

• No hallucinated data
• Every claim backed by a FHIR resource
• Deterministic + auditable execution

1. Real healthcare interoperability

• SMART on FHIR scopes for access control
• A2A agent card for discoverability
• SHARP context headers for session binding

1. Execution, not suggestion The system doesn’t say “consider antibiotics” — it:

• Checks timing windows
• Scores SEP-1 compliance
• Creates tasks
• Notifies care teams
• Drafts documentation

---

⚙️ What We Learned

1. Clinical reasoning ≠ classification

Detecting sepsis is not a binary ML problem.

It requires:

• Time-series reasoning (labs, vitals trends)
• Free-text interpretation (nursing notes, radiology impressions)
• Contextual judgment (is hypotension transient or persistent?)

LLMs are uniquely suited for this — but only when grounded in tools.

---

2. Documentation is as important as treatment

In SEP-1, what is written determines:

• Compliance scores
• Hospital reimbursement
• Legal defensibility

We learned that generating a CMS-abstractor-grade note is just as complex as diagnosing the condition.

---

3. Safety must be enforced at the system level

Prompt engineering is not enough.

We enforced hard guarantees:

• No medication without clinician sign-off
• No fabricated data
• Immediate halt on missing information

This turned the system from a “demo AI” into something closer to clinical infrastructure.

---

4. Multi-agent > single model

Breaking the system into agents:

• Reduced reasoning complexity
• Improved traceability
• Made debugging and testing feasible

It mirrors how real hospitals operate — specialized roles coordinating around a patient.

---

🚧 Challenges We Faced

1. Translating SEP-1 into code

SEP-1 is written for human abstractors, not machines.

We had to encode:

• Time windows (3-hour, 6-hour bundles)
• Edge cases (e.g., fluid type exclusions)
• Dozens of failure modes

This became sep1_definition.py — effectively a machine-readable compliance engine.

---

2. Free-text signal extraction

The most critical signals appear in:

• Nursing notes
• Microbiology reports
• Radiology impressions

Parsing these reliably required careful LLM prompting + strict grounding to avoid hallucinations.

---

3. Orchestration complexity

Coordinating:

• 5 agents
• 7 tools
• Multiple decision branches

…while maintaining:

• Determinism
• Auditability
• Clinical safety

…was significantly harder than building any single component.

---

4. Balancing autonomy vs control

Too much autonomy → unsafe Too much restriction → useless

We solved this by:

• Allowing reasoning autonomy
• Enforcing action constraints

---

🚀 What This Means

SepsisGuard demonstrates a shift:

From AI as a decision support tool → to AI as an execution layer for clinical protocols

This model can extend beyond sepsis to:

• Stroke pathways
• Cardiac emergencies
• Oncology treatment protocols
• Revenue cycle automation

---

🧩 Final Thought

Hospitals don’t fail because they lack knowledge.

They fail because execution breaks under complexity.

SepsisGuard is an attempt to fix that — not by replacing clinicians, but by ensuring that nothing critical is missed, delayed, or undocumented.

Built With

• claude
• llm
• python
• python-package-index