From Chaos to Orchestration: The Architecture Behind NeuroLab

Problem: Why Healthcare AI Needs AI Orchestration in NeuroLab

Most healthcare products hit the same wall. They start with one successful AI use case, then grow into multiple disconnected integrations. Teams add model calls where needed, but architecture is an afterthought. The result is not innovation. The result is drift. In a system like NeuroLab, drift creates immediate risks:

• Patient and doctor applications diverge in behavior.
• Identity and access become inconsistent across user roles.
• Async flows (reminders, notifications, bot inputs) become hard to govern.
• AI outputs cannot be reliably traced back to source context.
• Scaling one user-facing surface accidentally destabilizes another.

This is especially critical in care workflows. A patient logs symptoms through one interface. A doctor reviews trends in another. Admins manage reference data and access rights in a third. If these channels are not orchestrated by design, each "quick feature" introduces hidden coupling and long-term operational debt.

The core challenge is not model quality alone. The challenge is system coordination under clinical constraints.

Solution: NeuroLab AI Orchestration Architecture

To avoid that trap, NeuroLab uses a modular orchestration-first backend with separated channel applications.

1. Channel separation with a shared platform core

NeuroLab runs multiple frontends with independent lifecycles:

• Patient app (React + Vite)
• Doctor app (Next.js)
• Admin app (Next.js)

All of them connect to a shared Laravel backend, but each channel has dedicated API namespaces and flows. This means each app can evolve and scale without forcing synchronized releases across all interfaces.

2. Domain-driven modular backend

Backend structure is split into explicit domains and modules (via nwidart/laravel-modules), including:

• Core (business entities and reusable services)
• PatientApp
• DoctorApp
• AdministratorApp
• BotApp

This is a critical orchestration decision: core clinical logic is centralized in reusable services, while channel-specific APIs stay in app-facing modules.

3. Segmented APIs and auth boundaries

APIs are versioned by channel-style prefixes such as:

• /api/patient-app/...
• /api/doctor-app/...
• /api/administrator-app/...
• /api/bot-app/...

Authentication is separated by role-specific Sanctum guards (patient, doctor, administrator) and distinct auth cookies. Middleware maps cookie tokens to bearer auth per channel. This prevents cross-channel leakage and keeps security context explicit.

4. Event-driven and async orchestration layer

NeuroLab already uses asynchronous orchestration patterns for operational workflows:

• Cron-protected endpoints using X-Cron-Token
• Event dispatching for reminders
• Queue-based listeners with retries/backoff
• Redis/MySQL-backed runtime infrastructure in Docker

This architecture is essential in healthcare operations because not every flow should be synchronous with user actions.

5. AI service integration as a composable module

In BotApp, AI is integrated as a service layer, not embedded randomly in controllers. IBM calls are abstracted behind IBMService, with model configuration from environment (chatmodel, transcriptionmodel, timeout). This enables controlled upgrades and safer provider changes.

Real Example: AI Orchestration in NeuroLab Across Patient, Doctor, and Bot Channels

The most practical example is how migraine logs can be created from multiple channels while staying in one canonical data model.

I built the architecture so we could scale both the client app and the doctor app quickly and independently, while still adding new ingestion channels without redesigning the system.

Here is the flow already implemented in NeuroLab:

1. A patient sends text or voice in Telegram.
2. BotApp receives webhook events at /api/bot-app/telegram/webhook.
3. TelegramMigraineParserService builds context from Core reference datasets: * symptoms * triggers * pain locations * medications
4. IBMService parses free text (and transcribes audio when needed) into structured migraine fields.
5. Parser output is normalized and validated (including fallback logic when key fields like pain intensity are missing).
6. The bot flow creates a canonical migraine log through shared MigraineLogService.
7. The record is stored with source metadata (source = telegrambot, externalmessage_id) for traceability.
8. The same canonical data is available to patient and doctor channels through their own APIs.

This is orchestration in practice:

• Multiple inputs (manual app entry, bot text, bot audio) converge into one domain model.
• AI output is not trusted blindly; it is normalized and constrained by domain rules.
• Missing critical values trigger guided fallback interaction instead of silent failure.
• Provenance is preserved, so downstream users know where data came from.

The same principle is visible in reminder workflows:

• Cron endpoint triggers reminder dispatch.
• Events are emitted per patient.
• Queue listeners process sends asynchronously with retries and failure logging.

So NeuroLab does not treat AI as an isolated feature. It treats AI as one participant in a governed, multi-channel orchestration pipeline.

Result: Measurable Impact of AI Orchestration in NeuroLab Healthcare AI

NeuroLab now runs as one orchestrated platform across 3 web applications (Patient, Doctor, Admin), 1 bot channel (Telegram), and 34 active backend modules organized into 5 domains. API traffic is segmented through 21 domain route modules and protected by 3 dedicated auth guards.

This architecture produced measurable outcomes:

• Up to 75% less duplicated integration logic: instead of implementing the same workflow in 4 channels, core logic is implemented once and reused.
• 100% source attribution for bot-ingested migraine logs using source and externalmessageid, improving auditability of AI-assisted records.
• 2 AI input modalities (text + voice) normalized into one canonical migraine log model, reducing data-format fragmentation.
• Queue reliability controls in production (tries=3, backoff=60s) for reminder delivery, lowering failure risk during spikes.
• Independent scaling and release cycles for client and doctor surfaces, without forcing synchronized frontend deployments.

In short, NeuroLab moved from potential feature chaos to architectural control.

Andrei Tereshin, AI Systems Architect

CTA

If you’re building healthcare AI and need production-grade AI orchestration from day one, see how we design systems like NeuroLab at EGO-Digital.