Inspiration: The Post-Discharge Blind Spot
When patients leave the hospital, they enter a monitoring blind spot. Standard remote monitoring systems rely on threshold alarms that only beep when a single vital sign crosses a catastrophic red line.
But physiological decline is rarely sudden. It is a "compound deterioration", a slow and dangerous trend where, for example, a heart rate creeps up by 15% while oxygen saturation slowly drifts down over four days. By the time a standard alarm rings, the patient is already in crisis. I was inspired to build an autonomous system that doesn't just look at data points, but analyzes the timeline.
What it does
My project is built on a two-part architecture: The PostWatch MCP Server (The Brain) and a BYO Agent inside Prompt Opinion (The Orchestrator).
1. The PostWatch MCP Server (Core Build): I built a standalone Model Context Protocol server that acts as a clinical reasoning engine. It exposes three secure tools:
get_clinical_context: Pulls discharge diagnoses and active conditions.
get_vitals_trend: Extracts a dense array of the last 3–7 days of vital signs (HR, RR, SpO2).
assess_deterioration_risk: Runs cross-signal temporal reasoning to detect subclinical deterioration.
2. The BYO Agent (Prompt Opinion Integration): I configured a "Bring Your Own" Agent inside the Prompt Opinion ecosystem to act as our triage coordinator. It connects directly to our MCP server. When asked to evaluate a patient, the BYO Agent autonomously triggers our tools, retrieves the data, and outputs a strict, Markdown-formatted A2A (Agent-to-Agent) clinical summary, risk score, and recommendation.
How we built it
The heavy lifting was engineering the custom MCP Server using Node.js, Express, and TypeScript.
**The SHARP Integration:** I integrated deeply with Prompt Opinion’s enterprise architecture by utilizing their FHIR Context Extension (SHARP headers). My server intercepts x-po-fhir-server and x-po-fhir-token headers, allowing our tools to securely query the FHIR database without exposing credentials or requiring manual patient lookups.
**Streamable HTTP:** To ensure enterprise-grade stability behind Azure reverse proxies, I bypassed standard Server-Sent Events (SSE) and implemented the native StreamableHTTPServerTransport from the MCP SDK, instantiating secure, per-request tool sessions.
**Data Dieting:** I built custom mappers inside our tools to flatten raw, bloated FHIR JSON (Observations, Conditions, Encounters) into dense arrays. This prevents LLM context timeouts and allows our BYO agent to process data near-instantly.
Challenges we ran into
The "Final Boss" of Enterprise Networking: I initially attempted to use SSE for our MCP transport, but clashed with Azure App Service proxies and Nginx buffering, resulting in persistent stream is not readable errors. I had to reverse-engineer the platform's expected handshake and successfully pivoted our entire architecture to Streamable HTTP with zero hours to spare.
Context Bloat & Markdown Bleed: Early iterations of our BYO Agent struggled to format the clinical output, often hallucinating markdown tags across the response and timing out due to massive FHIR JSON payloads. I solved this by strictly flattening the data at the MCP server level and engineering a highly constrained system prompt.
Accomplishments that we're proud of
The Green Badge: Earning the "PromptOpinion FHIR Context Supported" badge on our server, proving I successfully worked out the platform's native security layer.
The BYO Agent A/B Test: Successfully demonstrating our core thesis. We fed our agent a stable CABG patient (Adam) and it recommended standard care. I fed it a critical CABG patient (Christina) whose vitals were slowly drifting but hadn't crossed traditional threshold limits. My MCP server caught the compound deterioration and the BYO agent flagged a Critical Escalation.
What we learned
The deep mechanics of the Model Context Protocol (MCP) and how different transport layers interact with enterprise proxies.
How to orchestrate a BYO Agent to securely navigate complex HL7 FHIR resources.
The massive difference between building a conversational chatbot and building a strict, data-driven Agent-to-Agent (A2A) analytical pipeline.
What's next for PostWatch
Direct EHR Write-Backs: Upgrading the MCP server to write FHIR Flag or Communication resources directly back into the patient's medical record when critical risk is detected.
Automated Cron Triggers & Real-time monitoring: Partnering with a scheduling system to run the BYO PostWatch assessment on every high-risk discharged patient automatically at 8:00 AM every morning or in real-time with integration of an IoT wearable with sensors that would send vitals data in real-time.
Built With
- express.js
- generative-ai
- node.js
- prompt-opinion
- typescript
Log in or sign up for Devpost to join the conversation.