Architecture

Architecture

DHTI is a modular reference architecture for GenAI in healthcare. It wires together:

• OpenMRS O3 (EMR and container for conchs)
• LangServe (runtime for elixirs)
• Ollama (optional self‑hosted LLMs)
• Redis (vector store for RAG)
• LangFuse (LLM observability)
• HAPI FHIR with CQL (FHIR repository and CQL execution)
• Neo4j (graph utilities)
• MCP FHIR tool server (agent tools)

All components are orchestrated via a generated docker-compose.yml managed by the DHTI CLI.

System Diagram

You can reference the diagram from the main repo:

Related standards and tools: FHIR, CDS-Hooks, LangServe, OpenMRS O3.

Data and Control Flow

1. Conchs (OpenMRS O3 ESMs or CDS Hook clients) collect user input and clinical context.
2. Requests are sent over CDS-Hooks/FHIR to elixirs (LangServe apps) and other services.
3. Elixirs can call LLMs (Ollama or external), vector store (Redis), FHIR (HAPI), and tools (MCP) as needed.
4. Results are rendered back in the conch UI and/or posted to FHIR resources.

Modularity principles

• Contracts over implementation: FHIR for data, CDS-Hooks for UI/backend handshake.
• Dependency injection: Models and hyperparameters injected at runtime via bootstrap.
• Decoupling: Conchs and elixirs are installable, swappable units.
• Observability: Centralized traces and events in LangFuse.

Production considerations

• Secrets management via .env and upstream secrets providers.
• Separate per-environment compose overlays.
• Model governance and prompt safety checks.
• Auditing and PHI handling in logs.

See Elixirs and Conchs to extend the system.