Bell Eapen MD, PhD.

Bringing Digital health & Gen AI research to life!

When GenAI Ideas translate to practice with DHTI

If you’ve ever worked in healthcare, you know the feeling: you have a brilliant idea—something that would save time, reduce frustration, or make patient care smoother—and then… nothing happens. Not because the idea is bad, but because turning it into real software feels like trying to build a spaceship out of sticky notes.

That’s the gap vibe coding is trying to close. And with tools like DHTI, that gap is finally starting to shrink, and it resembles more of a conversation like below!

npx dhti-cli copilot --model gpt-5.3-codex --skill elixir-generator --prompt "Generate an elixir glycemic_advisor that summarizes diabetic patients' latest lab results and medications"

npx dhti-cli copilot --model gpt-5.3-codex --skill start-dhti --prompt "Start the glycemic_advisor elixir and display in CDS-Hooks sandbox"

Let’s walk through what vibe coding is, why it matters, and how DHTI makes it surprisingly doable—even if you’ve never written a line of code in your life.

So… what exactly is vibe coding?

Think of vibe coding as building software the same way you’d brainstorm with a colleague over coffee. You don’t start with code. You start with the vibe of what you want.

Instead of saying:

“I need a function that queries a FHIR endpoint and transforms the JSON.”

You say:

“I want a little helper that pulls a patient’s meds and tells me if anything looks risky.”

And the system starts shaping that idea into something real.

Vibe coding is:

  • Talking to the computer like you’d talk to a person
  • Iterating as you go
  • Letting the AI handle the technical scaffolding
  • Staying focused on the idea, not the syntax

It’s not magic. It’s just finally letting people who understand healthcare shape the tools they need—without having to become software engineers first.

Why healthcare needs this more than anyone

Healthcare is full of smart, creative people. But it’s also full of complexity: clinical workflows, privacy rules, specialized language, and data standards that feel like they were designed by a committee of cryptographers.

Even when clinicians know exactly what they want, translating that into something a developer can build is… hard. And developers, for their part, often spend more time deciphering clinical nuance than writing code.

Vibe coding cuts out the translation layer.
It lets clinicians express ideas in their own words.
It lets AI turn those ideas into working prototypes.
And it lets developers focus on polishing and deploying—not guessing.

But vibe coding alone isn’t enough. Healthcare needs structure. It needs guardrails. It needs standards.

That’s where DHTI comes in.

Meet DHTI: the “let’s actually build this” engine

DHTI is an open‑source reference architecture built specifically for healthcare GenAI applications. If vibe coding is the conversation, DHTI is the workshop where the ideas get shaped into something sturdy.

DHTI gives you a ready‑made foundation for building GenAI healthcare tools. It understands healthcare standards, provides synthetic data, supports agentic workflows, and helps you turn natural‑language ideas into real, testable applications.

In plain English:
DHTI makes vibe‑coded ideas actually work in healthcare environments.

Here’s how.

DHTI speaks healthcare, so you don’t have to

Most AI tools can generate code, but they don’t understand the rules of healthcare. They don’t know what FHIR is supposed to look like. They don’t know how CDS‑Hooks cards plug into clinical workflows. They don’t know what’s safe, what’s allowed, or what’s interoperable.

DHTI does.

So when someone says:

“Can you build something that checks whether a patient with diabetes is overdue for an A1c?”

DHTI can assemble the pieces:

  • A FHIR query
  • A little reasoning chain
  • A card that could show up in the EHR
  • A test environment to try it out

All without the user needing to know any of those words.

It lets non‑technical users build real workflows

Healthcare tasks aren’t simple. They involve multiple steps, multiple data sources, and multiple decisions. DHTI is built for that.

A clinician might say:

“I want something that looks at a patient’s skin images, compares them to previous ones, and drafts a note.”

DHTI can turn that into:

  • A workflow that loads images
  • A reasoning step that describes changes
  • A draft note
  • A preview card

It’s not just generating text—it’s building a mini‑application.

It makes experimentation safe and fast

One of the biggest barriers in healthcare innovation is simply being able to try things. Real patient data is locked down (as it should be). EHR systems are hard to access. And IT teams are stretched thin.

DHTI solves this by including:

  • Synthetic data that looks realistic but contains no PHI
  • A ready‑to‑use FHIR server
  • Prebuilt agent templates
  • A local environment you can spin up quickly

This means you can test ideas without waiting for approvals, access, or integration.

You can play.
You can explore.
You can see what works.

And that’s where the best ideas come from.

It smooths the path from prototype to production

Prototyping is fun. Deploying is not.

Healthcare IT teams have to think about:

  • Security
  • Compliance
  • Standards
  • Maintenance
  • Integration
  • Auditing

DHTI is built with these realities in mind. Because everything is structured, modular, and standards‑aligned from the start, IT teams don’t have to rebuild the prototype from scratch. They can refine it, secure it, and deploy it.

This is the difference between “cool demo” and “something translatable to practice.”

The Copilot SDK: your agent, packed right into the app

One of the most exciting pieces of this ecosystem is the Copilot SDK, making the AI agent directly available in DHTI—no external tools, no switching windows, no juggling platforms.

You can:

  • Build the agent
  • Test it
  • Tweak it

All in one place.

For vibe coding, this is huge. It means the conversation that creates the tool can happen inside the tool itself. Clinicians can test ideas in the same interface where they’ll eventually use them. Developers can refine behavior without rebuilding infrastructure.

It’s a tight, elegant loop.

Why this moment matters

Healthcare has always been full of ideas. What it hasn’t had is a way to turn those ideas into working software without months of meetings, requirements documents, and integration headaches.

Vibe coding changes the front end of innovation.
DHTI changes the back end.

Together, they make it possible for:

  • Clinicians to prototype ideas
  • Researchers to test hypotheses
  • Developers to build faster
  • IT teams to deploy safely
  • Organizations to innovate sustainably

It’s not just a new tool.
It’s a new way of building.

Last but not least, thank you, Hanson Professional Services, for supporting this project! Version 1 will debut at the Medical Informatics Europe Conference 2026 in Genoa, Italy, taking place May 26–28, 2026. Read more about DHTI and try it today! It is free and open-source. See the repository link below. Please comment/share if you find this useful!

Hanson - DHTI

DHTI: a reference architecture and agent harness for Gen AI in healthcare!
https://github.com/dermatologist/dhti
0 forks.
20 stars.
13 open issues.

Recent commits:

Published by Bell Eapen on | Permalink

How DHTI Makes MCP Practical for Healthcare Through “Docktor” (Part IV)

The previous post of this series explained why LLMs need tools, why the agentic pattern matters, and how standards like MCP and A2A make tool‑calling safe and interoperable. But standards alone don’t guarantee usability—especially in healthcare, where clinicians and researchers need systems that “just work.” This is where DHTI steps in, transforming the complexity of MCP into something deployable, maintainable, and clinician‑friendly.

A key part of this transformation is DHTI’s integration with MCPX, a production‑ready gateway for managing MCP servers at scale. MCPX is powerful, but on its own it still requires engineering expertise. DHTI removes that barrier by packaging MCPX inside its own container environment and extending it with a new feature called docktor, which makes installing healthcare algorithms as simple as running a single command.

Let’s unpack how this works.

Image credit: sOER Frank, CC BY 2.0 https://creativecommons.org/licenses/by/2.0, via Wikimedia Commons

What MCPX Is and Why It Matters

MCPX is an open‑source, production‑grade gateway created by Lunar.dev to orchestrate and manage multiple MCP servers. It provides a unified gateway for an entire MCP ecosystem, giving teams centralized control over which tools are exposed to which agents, how they are configured, and how they perform. MCPX acts as an aggregator, meaning it can connect to many MCP servers and present them as a single, coherent interface to an LLM or agent.

Search results also highlight several key capabilities:

  • MCPX dynamically manages multiple MCP servers through simple configuration changes, enabling zero‑code integration with MCP‑compatible services.
  • It centralizes tool discovery, access control, call prioritization, and usage tracking, making it suitable for production‑grade agentic systems.
  • It is designed for environments where the number of tools and servers grows rapidly, providing visibility and governance across all interactions.

In short, MCPX solves the “tool sprawl” problem: instead of wiring dozens of MCP servers manually, you point everything to MCPX and let it orchestrate the rest.

But MCPX is still a developer‑oriented platform. It assumes familiarity with Node.js, configuration files, environment variables, and container orchestration. That’s where DHTI changes the game.

How DHTI Makes MCPX Easy

DHTI embeds MCPX directly into its Docker‑based architecture. Instead of requiring users to install MCPX manually, configure it, and manage its lifecycle, DHTI:

  • Deploys MCPX automatically inside its container environment
  • Configures MCPX to work with DHTI’s FHIR, CDS‑Hooks, and agentic components
  • Exposes MCPX to agents without requiring any user‑side setup
  • Handles the installation of algorithms/calculators packaged as an MCP server with a single command.

For healthcare teams, this is transformative. MCPX becomes invisible infrastructure: powerful, flexible, and standards‑compliant, but never something clinicians need to touch.

Docker‑in‑Docker: Deploying Healthcare Algorithms as Tools

Healthcare algorithms and calculators increasingly ship as Docker containers. This is already common in research environments and many FHIR‑related tools. Docker packaging ensures reproducibility, version control, and portability across systems.

DHTI extends this model by enabling Docker‑in‑Docker deployments inside MCPX. In practice, this means:

  1. A research team packages an algorithm—say, a stroke‑risk calculator or EEG classifier—into a Docker container.
  2. They follow a simple standard:
    • The container must accept a patient ID as input
    • It must be able to access a FHIR server for structured data
    • It must be able to read from a local folder for unstructured data (EEG, radiology images, PDFs, etc.)
  3. DHTI installs this container inside MCPX, where it becomes an MCP tool.
  4. Agents can now call the tool using MCP, passing only the patient ID.

This architecture ensures that algorithms remain isolated, reproducible, and easy to update—just replace the container with a new version.

Why Standards Matter for Healthcare Algorithms

Healthcare algorithms are not arbitrary scripts. They must follow predictable patterns so they can be safely integrated into clinical workflows. The most common requirements include:

  • FHIR server access for structured data such as vitals, labs, medications, and encounters.
    • Many FHIR servers—including Microsoft’s open‑source implementation—run as Docker containers, making them easy to integrate into DHTI’s environment.
  • Local folder access for unstructured data such as EEG files, radiology images, or waveform data.
  • Patient‑ID‑based invocation, which keeps the interface simple and consistent across tools.

By standardizing these expectations, DHTI ensures that any algorithm packaged by a research team can be installed and used by clinicians without custom engineering.

Introducing “Docktor”: One‑Command Installation for Clinicians

The most exciting part of this new architecture is docktor, a DHTI feature that lets clinicians install algorithms with a single command.

Instead of:

  • cloning GitHub repositories
  • configuring environment variables
  • wiring MCP servers manually
  • setting up Docker networks
  • mapping volumes
  • writing MCP configuration files

…a doctor simply runs:

dhti-cli docktor install <algorithm-name>

Behind the scenes, DHTI:

  1. Pulls the Docker image
  2. Deploys it inside MCPX using Docker‑in‑Docker
  3. Registers it as an MCP tool
  4. Grants it access to FHIR and local data folders
  5. Makes it available to agents immediately

The installed algorithm becomes a first‑class MCP tool, callable by any agent in the system.

This is the democratization of GenAI in action: clinicians gain the ability to extend their AI stack without needing a DevOps team.

Seamless Data Access and Agent Output

Once installed, these tools behave like native components of the agentic workflow. An agent can call a tool with:

patient_id: “12345”

The tool retrieves the necessary data from the FHIR server or local folders, runs the algorithm, and returns structured output to the agent. The agent can then:

  • summarize results
  • generate recommendations
  • integrate findings into a CDS‑Hooks card
  • write notes back into the EMR (if permitted)

The entire workflow becomes smooth, modular, and maintainable.

Why This Matters for Healthcare

Healthcare AI has long been held back by deployment friction. Researchers build algorithms, but clinicians struggle to use them. EMR vendors offer APIs, but integrating new tools requires engineering resources most hospitals don’t have.

DHTI + MCPX + docktor changes that equation:

  • Researchers package algorithms as Docker containers
  • DHTI installs them with one command
  • MCPX orchestrates them as standardized MCP tools
  • Agents call them using patient IDs
  • Clinicians get actionable results inside their workflows

This is the missing layer that turns agentic AI from a prototype into a practical clinical platform.

What’s Next

In the next post, I’ll walk through practical examples of docktor in action—how a clinician might install a stroke‑risk calculator, a dermatology classifier, or a genomics pipeline, and how agents use these tools to deliver meaningful clinical insights.

Try the following command today!

npx dhti-cli docktor –help

DHTI: a reference architecture and agent harness for Gen AI in healthcare!
https://github.com/dermatologist/dhti
0 forks.
20 stars.
13 open issues.

Recent commits:

Published by Bell Eapen on | Permalink

Bringing Generative AI Into the EHR: Why DHTI Matter (Part I)

Large Language Models (LLMs) are transforming how we think about clinical decision support, documentation, and patient engagement. Yet despite their impressive capabilities, LLMs have a fundamental limitation that becomes especially important in healthcare: LLMs are stateless. They do not remember prior interactions unless that information is explicitly included in the prompt. For clinical use, this means that patient‑specific data must be added to every prompt if we want the model to generate relevant, safe, and context‑aware output.

This is where the real challenge begins.

Image credit: Grzegorz W. Tężycki, CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons

Why Patient Context Matters for Generative AI in Healthcare

Healthcare workflows depend on rich, longitudinal patient data—medications, allergies, labs, imaging, diagnoses, and more. To generate clinically meaningful output, an LLM must be given this context. Without it, the model is essentially guessing.

But adding patient data to prompts is not as simple as it sounds. Extracting structured, reliable data from Electronic Medical Records (EMRs) is notoriously difficult. EMRs were not originally designed with AI integration in mind. Data may be siloed, inconsistently structured, or locked behind proprietary interfaces. Even when APIs exist, authentication, authorization, and data‑mapping complexities can slow down innovation.

FHIR: The Standard That Makes Interoperability Possible

Fortunately, the healthcare ecosystem has rallied around a modern interoperability standard: HL7® FHIR® (Fast Healthcare Interoperability Resources). FHIR provides a consistent, web‑friendly way to represent clinical data, making it easier for external applications—including AI systems—to retrieve patient information.

Most major EMRs now expose FHIR APIs that allow authorized systems to query patient‑specific data such as demographics, medications, conditions, and lab results. This shift has been transformative. Instead of custom integrations for each EMR vendor, developers can rely on a shared standard.

FHIR also underpins many modern interoperability frameworks, including SMART on FHIR and CDS‑Hooks. These standards are now widely adopted across the industry, with CDS‑Hooks explicitly designed to connect EMRs to external decision‑support services using FHIR data.

Displaying AI Output Inside the EMR: The Role of CDS‑Hooks

Retrieving data is only half the problem. Once an AI model generates insights, the output must be displayed inside the clinician’s workflow—not in a separate window, not in a separate app, and not in a place where it will be ignored.

This is where CDS‑Hooks comes in.

CDS‑Hooks is a standard that allows EMRs to call external decision‑support services at specific points in the clinical workflow. When a clinician opens a chart, writes an order, or reviews a medication list, the EMR can trigger a “hook” that sends key context—including the patient ID—to a backend service. That backend can then use FHIR APIs to retrieve the necessary patient data, run AI models, and return actionable “cards” that appear directly inside the EMR interface.

This pattern is powerful because:

  • It keeps clinicians in their workflow
  • It ensures AI output is tied to real‑time patient context
  • It avoids sending large amounts of PHI directly from the EMR to the AI model

In short, CDS‑Hooks is the bridge between EMRs and modern AI‑powered decision support.

DHTI: A Reference Architecture for GenAI in Healthcare

As interest in generative AI grows, developers and researchers need a framework that brings all these pieces together—LLMs, FHIR, CDS‑Hooks, EMR integration, and modular AI components. DHTI (Distributed Health Technology Interface) is one such open‑source project.

DHTI embraces the standards that matter:

  • FHIR for structured data exchange
  • CDS‑Hooks for embedding AI output in the EMR
  • LangServe for hosting modular GenAI applications
  • Ollama for local LLM hosting
  • OpenMRS as an open‑source EMR environment

The project’s documentation highlights how CDS‑Hooks is used to send patient context (including patient ID) and how backend services retrieve additional data using FHIR before generating AI‑driven insights. DHTI’s architecture is intentionally modular, allowing developers to prototype new GenAI “elixirs” (backend services) and UI “conches” (frontend components) that plug directly into an EMR environment.

You can explore the project here:

DHTI: a reference architecture and agent harness for Gen AI in healthcare!
https://github.com/dermatologist/dhti
0 forks.
20 stars.
13 open issues.

Recent commits:

Why This Matters for the Future of Clinical AI

Healthcare AI must be:

  • Context‑aware
  • Integrated into clinical workflows
  • Standards‑based
  • Secure and privacy‑preserving
  • Interoperable across EMRs

LLMs alone cannot meet these requirements. But LLMs combined with FHIR, CDS‑Hooks, and frameworks like DHTI can.

This is how we move from isolated AI demos to real, production‑ready clinical tools. Try DHTI and Help Democratize GenAI in Healthcare

Published by Bell Eapen on | Permalink

Vibe Coding FHIR to OMOP

TL;DR: A clinician‑researcher can download vocabularies, point at a folder of FHIR Bulk Export files, and be querying in OMOP CDM in an afternoon. This function, generated by vibe coding using these prompts, would help you do just that!

🎵 What is Vibe Coding?

Vibe coding is an AI‑assisted development approach popularized by Andrej Karpathy. Instead of hand‑coding every function, you describe your intent in natural language to a large language model (LLM), and the AI generates boilerplate, scaffolding, or even full implementations.

Core elements:

  • Natural language prompts: You focus on what you want, not how to implement it.
  • AI‑driven code generation: The LLM translates your description into actual code.
  • Iteration through conversation: You refine the output by prompting adjustments, much like pair programming.
  • Conceptual focus: This frees mental bandwidth for architecture, data flows, and domain logic, rather than syntax minutiae.

Done well, vibe coding is not “letting the AI code everything blindly.” It’s a collaborative, high‑level design process where you still review, edit, and integrate the code yourself.

But let us discuss the problem first!

🗂 What is OMOP CDM?

The Observational Medical Outcomes Partnership Common Data Model (OMOP CDM) is the de‑facto standard for representing health data in a way that’s consistent, query‑friendly, and research‑ready. Stewarded by OHDSI, OMOP CDM structures clinical data into a fixed set of standardized tables—patients, conditions, drug exposures, measurements, procedures—each with precisely defined fields and standard vocabulary concept IDs.

The payoff:

  • You can write a single analysis and run it across multiple sites—without rewriting SQL for each local schema.
  • Data from disparate EHR systems, claims databases, and registries can be harmonized and compared.
  • The model supports rich vocabularies like SNOMED, RxNorm, and LOINC through standardized concept IDs.

If raw EHR data is a jumble of puzzle pieces, OMOP CDM is the finished picture on the box—complete with a shared key so everyone knows exactly where each piece fits.

🔗 Why is it hard to map FHIR to OMOP?

At first glance, FHIR (Fast Healthcare Interoperability Resources) and OMOP both sound like they’re aiming for the same thing: standardization. But FHIR focuses on data exchange—it’s an API‑friendly format designed for real‑time transactions, mobile apps, and message passing between systems. OMOP, in contrast, is optimized for longitudinal analytics and cohort‑level studies.

Mapping challenges include:

  • Structural mismatch
    FHIR resources are often nested, verbose JSON objects with variable optional fields. OMOP tables are flat, relational, and denormalized for fast query performance. Flattening nested hierarchies without losing nuance is non‑trivial.
  • Semantic alignment
    FHIR can store local codes or references; OMOP demands standardized vocabulary concepts. This means you can’t just copy values—you must map each source code to a standard concept ID, often using crosswalk tables from OHDSI’s Athena vocabulary service.
  • Event granularity
    In FHIR, the same clinical fact might appear in multiple resources with different contexts. In OMOP, each fact needs to live in exactly one table with precise timestamps and provenance.
  • Volume and variety
    FHIR Bulk Export can generate millions of NDJSON lines across dozens of resource types. Efficiently parsing, reconciling, and loading that into OMOP while preserving relationships is an engineering workout.

🐍 Meet PyOMOP

PyOMOP is a lightweight, Python‑based toolkit for working with OMOP CDM v5.4 or v6 databases.

Key capabilities include:

  • Creating and initializing OMOP databases (SQLite for quick tests, Postgres/MySQL for production).
  • Loading vocabularies from Athena CSVs.
  • Running standard OHDSI QueryLibrary queries or your own SQL.
  • Converting results to DataFrames for downstream analysis or machine learning.
  • FHIR → OMOP import utilities for bulk‑loading FHIR data into CDM tables.

PyOMOP’s design goal is to get researchers and developers productive quickly without the steep ramp‑up of setting up full OHDSI stacks from scratch.

🛠 Building FHIR→OMOP in PyOMOP with Vibe Coding

When I set out to add robust FHIR Bulk Export to OMOP CDM loading in PyOMOP, I knew the mapping complexity would be the biggest hurdle. I also knew that much of the tedious parsing, table loading, and vocabulary reconciliation could be scaffolded quickly using an AI coding partner.

Leveraging vibe coding for scaffolding

Using natural‑language prompts, I asked the AI to:

  • Generate Python functions to parse NDJSON files into DataFrames.
  • Build class methods that map FHIR resource fields to OMOP column names.
  • Handle async bulk inserts into Postgres using SQLAlchemy.

I treated the AI’s output like a first draft. I kept the domain‑specific logic in my own hands. I fed failure examples back into the AI prompt, asking for exception handling and logging improvements. This conversational loop closed the gap quickly. Once the mapping functions were stable, I embedded them behind a simple command:

pyomop --create --vocab ~/Downloads/omop-vocab/ --input ~/Downloads/fhir/

Now, a single command could create an OMOP DB, load vocabularies, import FHIR data, and reconcile mappings.

With the FHIR→OMOP feature now baked into PyOMOP, a clinician‑researcher can download vocabularies, point at a folder of FHIR Bulk Export files, and be querying in OMOP CDM in an afternoon—no endless SQL migrations required.

Python package for managing OHDSI clinical data models. Includes support for LLM based plain text queries, MCP server and FHIR import.
https://github.com/dermatologist/pyomop
11 forks.
67 stars.
24 open issues.

Recent commits:

Published by Bell Eapen on | Permalink

Loading MIMIC dataset onto a FHIR server in two easy steps
WordPress › Error

There has been a critical error on this website.

Learn more about troubleshooting WordPress.