PREVIS Diabetes Intelligence Tool

Built by clinicians, for clinicians.


Inspiration

We didn't build PREVIS Diabetes from a pitch deck. We built it from memory.

Raphaëlle spent several years as a registered dietician at Diab-eCare in Lyon, France — a national reference center for Type 1 diabetes, working directly under Professor Thivolet's endocrinology team. Her daily work involved preparing nutrition and insulin management reviews for patients on hybrid closed-loop systems. She watched endocrinologists walk into consultations with weeks of dense CGM data and less than fifteen minutes to make sense of it. Critical patterns — sport-induced nocturnal hypoglycemia, fat-delay meal spikes, unawareness flags — were documented somewhere in the data. But finding them, every time, for every patient, under that kind of time pressure, was genuinely hard.

Jordan comes from the other side of the same problem. As a registered nurse in the US with a background in cardiology and diabetes care, she saw how much clinical judgment gets compressed into the time available. Not because clinicians aren't skilled. Because the data is too dense and the workflow too fragmented.

We are both now colleagues at IQVIA. When we started talking about what we each wished we'd had — as a dietician, as a nurse — the same answer kept coming up: something that does the pattern recognition before the appointment, so the clinical time can go where it matters.

That's PREVIS Diabetes.


What It Does

PREVIS Diabetes is an MCP (Model Context Protocol) server that sits between patient device data and the endocrinologist's workflow. It takes raw CGM readings, pump logs, and nutrition records — normalized to a FHIR-compliant schema — and turns them into clinically structured outputs in seconds.

It is built specifically for Type 1 diabetes patients on hybrid closed-loop insulin delivery systems: Omnipod 5, MiniMed 780G, Tandem t:slim X2 with Control-IQ, CamAPS FX, and Diabeloop.

The Six Tools

1. Patient Risk Dashboard — get_patient_risk_summary

Ranks all patients by glycemic risk before the clinic day starts. Each patient is scored against clinical thresholds — Time in Range, Time Below Range, Time Very Low, HbA1c — and assigned a risk category. The endocrinologist sees immediately who needs attention today.

2. Glycemic Summary — get_glycemic_summary

Produces a full structured breakdown of a patient's CGM metrics for the review period, with automated clinical flags wherever international thresholds are exceeded. Includes adjusted targets for high-risk patients — those over 65 or with documented hypoglycemia unawareness — who require more conservative parameters.

3. Nutrition–Insulin Pattern Analysis — get_nutrition_insulin_pattern

Cross-references meal logs with CGM and bolus data to identify which food types and eating behaviors are driving glycemic events. A pattern is only surfaced when it recurs three or more times — isolated events are never flagged. High-risk meal categories include mixed dishes, high-fat meals with fat-delay two-phase patterns, starchy carbohydrates with variable glycemic index, and alcohol-food combinations with nocturnal hypo risk.

4. Hypoglycemia Risk Detection — flag_hypoglycemia_risk

Identifies and prioritizes hypoglycemia risk triggers: sport-induced nocturnal hypos, suspected unawareness patterns, post-prandial late drops, and basal timing mismatches. Designed to surface the multi-factor picture that is easy to miss in a five-minute chart review.

5. Pre-Consultation Briefing — generate_consultation_briefing

Assembles a six-section pre-consultation brief — glycemic summary, hypo risk analysis, nutrition–insulin patterns, clinical flags, trend comparison against previous visit, and recommended consultation focus areas. Ready in seconds before the patient walks in.

Built-in data quality gate: if sensor wear is below 70% for the review period, the tool refuses to generate a briefing and flags the data as unreliable. This is a hard block, not a warning.

6. Post-Consultation SOAP Note — draft_post_consultation_note + export_post_consultation_note

After the consultation, the clinician selects the topics discussed, then enters their objective findings and clinical plan — verbatim. The tool structures the SOAP note. Nothing is paraphrased. Nothing is generated without direct clinician input. The note can be exported to HTML for print or FHIR-compatible records. The clinician remains in control, always.


How It Works in a Consultation

A typical workflow in PREVIS Diabetes follows the full clinical loop:

  1. The endocrinologist opens the day with the patient dashboard — all patients ranked by risk, full metrics visible.
  2. A patient flags as high priority. The clinician drills in: hypoglycemia risk and nutrition patterns run in parallel, returning a multi-factor clinical picture in seconds.
  3. Thirty seconds before the patient walks in, the pre-consultation briefing is ready.
  4. After the consultation, the SOAP note workflow launches. The clinician confirms topics, enters findings and plan, and exports the structured note.

This full loop — dashboard, deep-dive, briefing, note — is what we mean by "clinical AI." Not a chatbot. A structured workflow that respects clinical time and clinical judgment.


How We Built It

MCP Server: Jordan built the backend MCP server from scratch, deployed on Railway. The server exposes six tools via the Model Context Protocol, making them callable by any MCP-compatible AI interface. The server handles patient data normalization to a FHIR-compliant schema, clinical threshold logic, and data quality gating.

Clinical Logic: Raphaëlle led the product specification — translating clinical knowledge from years at Diab-eCare into tool-level rules. Every threshold, every flag condition, every safety guardrail was designed against international consensus targets (Time in Range consensus, ADA guidelines) and validated against real clinical practice.

Platform: PREVIS Diabetes runs on the Prompt Opinion platform, where it is published as an MCP-powered agent available in the marketplace.

Tech Stack: Model Context Protocol (MCP), Railway (server hosting), FHIR schema normalization, HTML export for SOAP notes.


Challenges We Ran Into

The hardest challenge wasn't technical. It was the boundary between useful and dangerous.

Clinical AI that surfaces patterns is genuinely valuable. Clinical AI that generates clinical decisions is dangerous. Designing the exact line between those two — and holding it under every edge case — took more iteration than any other part of the build.

The data quality gate on the briefing tool is a good example. It would have been easy to generate a briefing with a caveat label for low-quality data. We chose a hard block instead, because a briefing that can't be trusted should not exist. That design decision meant rebuilding the logic several times to handle partial data correctly without failing silently.

A second challenge was the SOAP note. Every AI writing assistant wants to generate. We designed a tool that structures without generating: the clinician's words go in, structured and unchanged. Preserving verbatim clinical language inside an AI-assisted workflow required explicit architecture, not just a prompt.

On the team side: this is our first hackathon. Raphaëlle manages the product, Jordan builds the tool. Coordinating clinical specification with technical development without an IT background, under a submission deadline, with a live clinical demo in between — that was its own challenge.


Accomplishments We're Proud Of

We pitched it to real endocrinologists. Before submitting, we demoed PREVIS Diabetes to the endocrinology team at Diab-eCare in Lyon — the clinical environment where the idea originated. The feedback was direct and specific: the tool is immediately useful for remote patient monitoring, and the patient dashboard has an unexpected secondary value. By ranking and grouping patients with similar glycemic profiles, it enables clinicians to build targeted care pathways and therapeutic education workshops tailored to those patient clusters — something that had never been systematically possible before in their workflow.

The safety guardrail works in a demo. Sophie Martin has 29% sensor wear. When a clinician asks for her briefing, the tool refuses — hard block, no bypass. We demoed that refusal deliberately, in front of clinicians, because we believe clinical safety is not a feature you enable. It's the baseline.

Six tools, one coherent clinical workflow. Each tool is independently useful. Together, they map to a real consultation cycle: preparation before, support during, documentation after. That end-to-end coherence — built in weeks, by two people, across two continents — is something we're genuinely proud of.


What We Learned

We learned that clinical knowledge is not the same as clinical logic. Raphaëlle knew from experience which meal types cause glycemic problems for T1D patients. Turning that into a tool that flags exactly those patterns — and never flags the wrong ones — required translating clinical intuition into explicit, testable rules. That translation is hard, important work.

We also learned that AI in healthcare has to earn its place at each step. Every design choice had to answer the question: does this serve the clinician, or does it substitute for them? The answer shaped every tool we built.

And we learned that a product manager with clinical experience and a nurse-turned-developer make a surprisingly effective team. The shared clinical background meant we never had to explain why a safety constraint mattered. We already both knew.


What's Next

The immediate next step is EHR integration. PREVIS Diabetes currently runs on synthetic demo data with a FHIR-compliant schema ready for live connection. Connecting to real EHR systems would move the tool from clinical validation into clinical deployment.

We are also actively planning integration with GlookoXT — the leading CGM data aggregation platform used by diabetes care centers across Europe and the US. GlookoXT integration would give PREVIS Diabetes access to real, structured, multi-device CGM data at the population level, unlocking the full potential of the patient grouping and care pathway features that the Diab-eCare team identified in their feedback.

On the product side, we want to build out the dietician-facing module more fully: a dedicated carbohydrate analysis workflow, directly linked to insulin adjustment recommendations — bringing Raphaëlle's original clinical work into the tool itself.

The longer-term vision is a clinical AI layer that sits across the full diabetes care team: endocrinologist, dietician, diabetes nurse — each with the right structured view of their patients, prepared before the appointment, documented after, and connected across visits.

Built With

Share this project:

Updates