DEV Community: Ileana Mazilu

MDR Evidence Gap Agent: finding unsupported claims with Sanity Context

Ileana Mazilu — Mon, 21 Sep 2026 06:45:55 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

I'm a medical writer, and I built this project to explore how the clinical evidence requirements of the EU MDR can be modeled as structured content. In a clinical evaluation report, every claim needs supporting clinical evidence, and it is easy to lose track of which claims are still unsupported and which MDR requirements they touch. I have not worked on MDR submissions professionally: this is a learning project built from the public text of the regulation, and I built it with the help of an AI assistant.

The result is MDR Evidence Gap Agent: an agent that answers audit questions over a small dossier stored in Sanity, for example "Which claims have no supporting evidence, and which MDR requirements do they affect?"

Everything is synthetic. The device (VascuSeal, a fictional Class III vascular closure device), its claims and its studies are invented. The requirement entries are my own short paraphrases of the regulation, not the official text. This is a demo, not regulatory advice.

Why structure matters

A keyword search finds pages that mention things. It cannot find what is missing. In this project the gap is a claim with no linked evidence, which only exists as an empty reference list. The agent finds it by following references with GROQ, not by matching words.

Demo

Live app: https://mdr-evidence-gap-agent.vercel.app

Ask the agent: type a question or click an example. You can see every tool call and every GROQ query the agent wrote on its own.
Dossier: all claims, evidence and requirements read from Sanity through the same Context endpoint. Claims with no evidence are flagged, and each has a button that asks the agent about that gap.
Coverage: a requirement by claim matrix that shows which requirements are at risk.
About: how the content is structured, and the limits of the demo.

Note: the live demo runs on free quotas and on a Sanity trial that ends around October 19. It may become unavailable after that, depending on what the free plan includes. The sample run below shows what the agent returns.

Sample run. The agent called initial_context, then wrote its own queries. One of them:

*[_type == "claim"]{
  _id, title, text,
  "requirements": requirements[]->{ _id, title, annex, text },
  "evidence": evidence[]->{ _id, title, studyType, summary },
  "evidenceCount": count(evidence)
}

Its answer: two claims have no linked evidence.

Five-year seal durability affects Article 61(1) (clinical evidence for conformity) and Annex XIV Part B (PMCF).
Real-world PMCF confirmation affects Annex XIV Part B (PMCF) and Article 86 (PSUR).

These are the two gaps I planted in the dataset. The agent found both without being told where to look.

Code

This is the core agent loop. It connects to the Sanity Context MCP endpoint, hands the endpoint's tools to Gemini and loops until the model answers. The deployed app wraps the same loop in a streaming API route with a rate limit and retries when the model is busy, and keeps all keys on the server.

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { GoogleGenAI } from "@google/genai";

const { CONTEXT_URL, CONTEXT_TOKEN, GEMINI_API_KEY } = process.env;
const question = process.argv.slice(2).join(" ") ||
  "Which claims in the VascuSeal dossier have no supporting evidence, and which MDR requirements do they affect?";

const SYSTEM = [
  "You are the MDR Evidence Gap Agent.",
  "You audit a SYNTHETIC Class III device dossier (VascuSeal) stored in Sanity as three linked document types: requirement, claim and evidence.",
  "Call initial_context first, then use groq_query to follow references between claims, requirements and evidence.",
  "Only report what the linked documents show. Never declare a claim compliant. Requirement texts are paraphrased summaries, not the official MDR text.",
  "Answer concisely in English and list each gap with the affected requirements.",
].join(" ");

const mcp = new Client({ name: "mdr-evidence-gap-agent", version: "1.0.0" });
await mcp.connect(
  new StreamableHTTPClientTransport(new URL(CONTEXT_URL), {
    requestInit: { headers: { Authorization: `Bearer ${CONTEXT_TOKEN}` } },
  })
);

const { tools } = await mcp.listTools();
const functionDeclarations = tools.map((t) => {
  const schema = { ...(t.inputSchema || { type: "object", properties: {} }) };
  delete schema.$schema;
  return { name: t.name, description: t.description || "", parametersJsonSchema: schema };
});

const ai = new GoogleGenAI({ apiKey: GEMINI_API_KEY });
const contents = [{ role: "user", parts: [{ text: question }] }];

for (let step = 0; step < 10; step++) {
  const res = await ai.models.generateContent({
    model: "gemini-3.1-flash-lite",
    contents,
    config: { systemInstruction: SYSTEM, tools: [{ functionDeclarations }] },
  });
  const calls = res.functionCalls || [];
  if (calls.length === 0) { console.log(res.text); break; }

  contents.push(res.candidates[0].content);
  const responses = [];
  for (const call of calls) {
    const r = await mcp.callTool({ name: call.name, arguments: call.args || {} });
    const out = (r.content || []).map((c) => c.text || "").join("\n").slice(0, 20000);
    responses.push({ functionResponse: { name: call.name, response: { result: out } } });
  }
  contents.push({ role: "user", parts: responses });
}
await mcp.close();

How I Used Sanity

Schema: three document types defined in TypeScript in Sanity Studio: requirement (title, annex, text), evidence (title, study type, summary) and claim (title, text, and two arrays of references: requirements and evidence). The links between them are what make the agent's questions answerable.
Content: 6 requirement summaries, 4 pieces of synthetic evidence and 5 synthetic claims in the production dataset. Two claims deliberately have an empty evidence array.
Studio: deployed at https://mdr-evidence-gap.sanity.studio/ (requires a Sanity login), so the Context endpoint can read the deployed schema.
Sanity Context: an MCP endpoint created in the Context app, with a dataset source, a GROQ filter (_type in ["requirement", "claim", "evidence"]) that limits what the agent can read, and custom instructions. The app connects with a read-only Context Viewer token kept on the server.
What the agent does with the content: it calls initial_context to learn the schema, then runs groq_query to resolve references (->, count(), references()), and reports each claim with no evidence together with the requirements it is tied to. The Dossier and Coverage pages read the same content through the same endpoint.

Sanity Project Details

Project ID: 0hmb0qqg
Dataset: production
Studio: https://mdr-evidence-gap.sanity.studio/ (requires a Sanity login)
MCP endpoint name: mdr-evidence-gap-agent

Limitations

I built a small Knowledge Base from the text of four MDR provisions (Article 61, Annex XIV, Article 86, Annex I), but the agent does not read it yet: the endpoint behind this demo serves the dataset only.
The dataset is small (15 documents) and fully synthetic.
Requirement texts are short paraphrases, simplified, and were checked against public copies of the regulation with the help of an AI assistant. They are not legal text.
The agent reports what the linked documents show. It does not judge compliance.
The demo uses a free model quota, so questions are limited to 10 per visitor per hour, and the model may occasionally be busy. If you see an error, try again.

I built two AI agents at recent hackathons — now selling the codebases

Ileana Mazilu — Sat, 29 Aug 2026 21:37:48 +0000

Over the past month I've been deep in hackathon mode, building AI agents for healthcare/pharma use cases. Two of them turned out solid enough that I think someone else could build on them:

RxTrack Agent (ADK version) — a prescription-tracking agent built with Google's Agent Development Kit + Gemini + Firestore. GCP deployment verified, README included, built for the "All Things Agentic" hackathon.

RxTrack Agent (AWS version) — the same concept, rebuilt with AWS Strands SDK + Bedrock + Firestore, for "Agents for Humans."

Both are functional, tested, complete codebases. I don't have the bandwidth to develop them further right now, so I'm selling the source code outright — $149 each, no exclusivity, full ownership transfers to the buyer.

Links: RxTrack ADK: https://iancuileana.gumroad.com/l/agtwi

RxTrack AWS:https://iancuileana.gumroad.com/l/sqwkl

Happy to answer questions about the build, the frameworks, or the hackathon experience in the comments.

title: The Three-Headed Bug That Almost Sank My Compliance App published: true tags: devchallenge, bugsmash

Ileana Mazilu — Mon, 27 Jul 2026 13:23:14 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Setup

I'm not a traditional developer. I spent 20 years as a pharmacy technician and medical writer before I taught myself to build software using AI-assisted, no-code tools. Earlier this year, I built MedAd Compliance AI—a tool powered by Google's Gemini API that reviews medical device documentation against EU MDR and ICH-GCP regulatory standards. I didn't write the code by hand; I built it through natural-language prompts in Lovable, describing what I needed in plain English and iterating until the app behaved. That doesn't mean the debugging disappeared—it just looked different than a typical engineer's day. Three bugs, back to back, almost took the whole project down before it ever reached a user.

You can see the live tool here: https://ileana-mazilu.lovable.app/medad-ai

Bug #1: The AI That Lied With Confidence

The review engine would sometimes generate compliance feedback that sounded completely authoritative—citing specific clauses or requirements—but the details didn't actually match real EU MDR or ICH-GCP language. It wasn't obviously wrong. It was confidently, fluently wrong, which is far more dangerous in a regulatory tool than an answer that's obviously broken.

As someone with 20 years of hands-on regulatory experience, I could catch this because I knew the real standards well enough to spot the mismatch. A user without that background wouldn't have known to question it.

What I did: I rewrote the underlying instructions given to the AI, adding explicit constraints forcing it to only reference verifiable regulatory language and to flag uncertainty instead of inventing specifics when it wasn't sure. I tested it repeatedly against documents where I already knew the correct compliance answer, comparing the AI's output against my own expert review until the confident-but-wrong pattern stopped showing up.

Bug #2: The PDF That Refused to Change

Every time I generated a new compliance report for a different document, the exported PDF looked suspiciously similar to the last one—even when the underlying analysis should have been completely different. I only caught it because I ran two clearly different test documents back to back and compared the outputs side by side; they were nearly identical, which should have been impossible.

What I did: I traced it back to the report template pulling from a cached or default data set instead of the fresh analysis each time. I had to rebuild the export step so it explicitly pulled the current session's results instead of falling back to old data, then re-tested with several different documents in a row to confirm each report was actually unique.

Bug #3: The Rewrite Feature That Broke Itself

The tool's rewriting function—meant to suggest corrected, compliant language for flawed document sections—would sometimes cut off mid-sentence or return incomplete text, especially on longer passages. It wasn't a crash; it was worse, because it looked finished when it wasn't, and a user could easily miss that the suggested rewrite was truncated.

What I did: I identified that longer inputs were hitting an output limit that silently cut the response short instead of erroring out. I adjusted how the tool handled longer passages, breaking them into smaller chunks the AI could process fully instead of trying to force one long response, then verified the fix by testing with the longest, most complex document sections I could find.

What I Learned

Building with AI tools doesn't mean the debugging disappears—it just changes shape. Instead of stepping through stack traces, I was stepping through prompts, outputs, and edge cases, trying to figure out not just what broke, but why an AI model would confidently produce something wrong. That's a different kind of debugging discipline, and it took my regulatory background—not a computer science background—to actually catch two of these three bugs in the first place.

What I'm proud of: none of these bugs were hypothetical. They stood between real users and a tool meant to help people navigate genuinely high-stakes regulatory work. Fixing them wasn't just a technical win—it was the difference between a tool I could stand behind and one I couldn't.

🔗 Try the tool: https://ileana-mazilu.lovable.app/medad-ai

How I Built an AI Tool for Medical Device Regulatory Compliance

Ileana Mazilu — Mon, 20 Jul 2026 12:03:55 +0000

After 20+ years in pharmacy and 3 years as a Senior Clinical Evaluation Medical Writer, I kept seeing the same problem: small and mid-sized medical device companies often lack large in-house regulatory teams, yet face the same compliance scrutiny as major manufacturers when preparing Clinical Evaluation Reports (CER), Post-Market Clinical Follow-up (PMCF), and Periodic Safety Update Reports (PSUR).

Manual review is slow, expensive, and error-prone — even small gaps can delay approval or trigger regulatory findings.

So I built MedAd Compliance AI, combining my real-world EU MDR and ICH-GCP expertise with AI-powered document review. Unlike generic AI writing tools, it's grounded in actual clinical evaluation practice — flagging compliance gaps before submission, not after rejection.

You can try it here: https://ileana-mazilu.lovable.app

Would love feedback from anyone in medtech, regulatory affairs, or healthtech!