VitalShield

The Spark

Medical data is a mess. Doctors are currently forced to play "detective" across dozens of disjointed FHIR tables just to figure out if a patient is crashing. We built VitalShield because we believe clinical intelligence should look less like an Excel spreadsheet and more like a Bloomberg Terminal.

We wanted to move past the "Magic 8-Ball" phase of medical AI. Instead of asking a single model for a guess, we created a digital arena where multiple specialized agents debate each other to find the truth.

The Build

At its core, VitalShield is a high-performance Model Context Protocol (MCP) server built with Python and FastMCP. The server acts as a "Clinical Sanity Layer" that sits between the hospital’s messy FHIR database and the AI agents.

Before any analysis happens, our engine performs automated terminology mapping. We take raw, inconsistent EMR codes and normalize them using SNOMED-CT and LOINC standards. This ensures that whether a hospital labels a vital sign as "HR," "Heart Rate," or a specific pulse code, the system understands it as a single, consistent clinical concept.

The system then runs a custom Neurosymbolic Scorer. We calculate risk using temporal velocity vectors, tracking the rate of change in mean arterial pressure ($MAP$) relative to heart rate ($HR$) to calculate a shock index velocity:

$$ \vec{v}_{shock} = \frac{d}{dt} \left( \frac{HR}{MAP} \right) $$

The Privacy Firewall

VitalShield is built on a "Zero-Trust" data architecture. We believe that clinical data should never leave the hospital's secure environment. Our MCP server handles all the "heavy lifting" locally:

Redaction: We scrub all Patient Identifiers (Names, Birthdates, SSNs) before data is processed. Local Processing: The SNOMED mapping and scoring math happen entirely on the server. Redacted Analysis: The external LLM agents only see a clinical "redacted profile." They never see the original FHIR record or the patient's identity. Core Features Adversarial Agent Fleet: A group of 5 specialized agents—including a professional "Diagnostic Challenger"—that debate clinical findings to eliminate hallucinations. Bloomberg-Style Terminal: An ASCII-based real-time dashboard that renders trend vectors and acuity scores directly in the chat interface. Automated Triage: Provides an instantaneous 0-100 Acuity Score based on physiological stability. SHARP & FHIR Native: Full support for Prompt Opinion’s SHARP extension, allowing for seamless, context-aware patient context propagation.

The Hurdles

Building this was a crash course in "interoperability hell." We spent late nights wrestling with CORS headers and the SHARP extension spec to ensure Prompt Opinion could talk to our Railway-hosted backend without the browser panicking. Mapping raw FHIR R4 resources into a readable "Bloomberg-style" dashboard while maintaining strict PHI redaction required a complete ground-up rethink of the clinical data pipeline.

The Lesson

We learned that the "last mile" of healthcare isn't about better algorithms; it's about better trust. By forcing our agents into an adversarial consensus model, we eliminated the "hallucination" problem. If the agents can't agree on a diagnosis, the system tells the doctor "Low Consensus," which is a much safer answer than a confident lie.

We’ve built a bridge between the cold world of clinical databases and the messy reality of the Emergency Room.

Built With

• mcp
• python
• railway