Unified Healthcare Data Platform with LLMOps Integration

doctolib · Healthcare · 2025 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Healthcare data platform for AI/LLMOps

Doctolib's centralized data platform was slowing development and lacked the vector, model-serving, governance, and LLMOps components needed for healthcare AI and ML workloads.

Constraints:

The data team grew to over 100 people.
The monolithic repo had 30-40 minute CI pipelines and one daily release cycle.
Shared Airflow IAM roles created healthcare data security risks.
The Redshift warehouse gave all users administrative rights.
The existing platform lacked vector databases, model registry, feature store, and production model monitoring.

Architecture

Doctolib proposed a modular Unified Healthcare Data Platform with dedicated LLMOps tooling, vector database, lakehouse storage, model serving, inference engine, monitoring, model-as-a-service catalog, and a GenAI assistant for natural-language data exploration. The design separates ownership and governance boundaries that were previously collapsed into one repo, account, warehouse, and Airflow instance.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  healthcare_lakehouse["Healthcare lakehouse"] --> vector_database["Vector database"]
  healthcare_lakehouse --> ml_training_platform["ML training platform"]
  ml_training_platform --> llmops_tooling["LLMOps tooling"]
  llmops_tooling --> inference_platform["Inference platform"]
  healthcare_lakehouse --> inference_platform
  inference_platform --> model_serving["Model serving"]
  model_serving --> model_inference_engine["Model inference engine"]
  inference_platform --> model_monitoring["Model monitoring"]
  inference_platform --> model_as_a_service_catalog["Model as a Service catalog"]
  vector_database --> genai_assistant["GenAI assistant"]
  model_as_a_service_catalog --> genai_assistant

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Healthcare lakehouse`	Combines data lake storage with data warehouse governance.	`Vector database`, `ML training platform`, `Inference platform`
`Vector database`	Stores and searches high-dimensional embeddings for AI applications.	`Healthcare lakehouse`, `GenAI assistant`
`ML training platform`	Supports model training and LLMOps workflows.	`Healthcare lakehouse`, `LLMOps tooling`
`LLMOps tooling`	Supports fine-tuning, deployment, monitoring, versioning, prompt optimization, and cost management.	`ML training platform`, `Inference platform`
`Inference platform`	Serves models and manages real-time prediction endpoints.	`Healthcare lakehouse`, `LLMOps tooling`, `Model serving`, `Model monitoring`, `Model as a Service catalog`
`Model serving`	Deploys models with scaling, versioning, and API endpoint management.	`Inference platform`, `Model inference engine`
`Model inference engine`	Optimizes execution across GPUs, CPUs, and accelerators.	`Model serving`
`Model monitoring`	Tracks accuracy, drift, resource use, and anomalies.	`Inference platform`
`Model as a Service catalog`	Exposes pre-trained models as APIs or reusable services.	`Inference platform`, `GenAI assistant`
`GenAI assistant`	Supports natural-language data exploration.	`Vector database`, `Model as a Service catalog`

Data flow

Healthcare data moves into a governed lakehouse and ML storage layer. Vector data is indexed for semantic/RAG workloads. ML training uses LLMOps tooling for fine-tuning, prompt optimization, versioning, monitoring, and cost management. Served models run through an inference platform with model serving, inference engine, model monitoring, and API catalog capabilities.

3 supporting quotes

“The new platform architecture includes explicit components for LLMOps”summary, stated

“As part of their ML Storage layer, Doctolib plans to implement a vector database”summary, stated

“The Inference Platform includes several components essential for production LLM deployment:”summary, stated

Why this architecture

Doctolib's old platform worked for BI but not for secure healthcare AI: ML workloads need vector search, model lifecycle infrastructure, isolated permissions, and production monitoring.

“Their existing platform, while effective for business intelligence and analytics, was not designed to handle the requirements of training and deploying machine learning models”summary, stated

“Perhaps most critically, the architecture lacked the foundation for supporting ML workloads: no vector databases for embeddings, no model registry, no feature store”summary, stated

Models used: LLMs · model serving infrastructure · vector database

Scale

Doctolib's data team grew to over 100 members over 4-5 years.
“Over the past 4-5 years, Doctolib's data team grew from a small startup team to over a hundred members.”summary, stated
CI pipelines took 30-40 minutes.
“The centralized Git repository with a single daily release cycle led to CI pipelines taking 30-40 minutes”summary, stated

Alternatives considered (roads not taken)

Continue with the monolithic centralized data platform

Rejected because: It created slow CI, shared permissions, inflexible orchestration, and missing ML/LLMOps foundations.

“limitations of their centralized approach—including complex CI pipelines, shared permissions, and inflexible orchestration”summary, stated

Use the same Airflow IAM role for all workflows

Rejected because: Shared IAM roles were unacceptable for sensitive healthcare data.

“all DAGs sharing the same IAM role created security vulnerabilities unacceptable for healthcare data.”summary, stated

Patterns

`rag-retrieval` (semantic healthcare data)

The planned vector database supports similarity search and RAG-like AI applications.

“efficient similarity searches for AI applications.”summary, stated

`prompt-versioning` (LLMOps lifecycle)

Prompt optimization and model versioning are first-class planned LLMOps tooling capabilities.

“tools for model fine-tuning, deployment, monitoring, versioning, prompt optimization, and cost management.”summary, stated

`observability-tracing` (model monitoring)

The inference platform includes production model monitoring for accuracy, drift, and resource usage.

“Model Monitoring: Tracks production model performance, monitoring accuracy, drift, and resource usage with anomaly alerting”summary, stated

`privacy-preserving-processing` (healthcare governance)

The architecture addresses fine-grained access controls for sensitive healthcare data.

“The monolithic Redshift warehouse meant all users had administrative rights, making it impossible to enforce fine-grained access controls needed for sensitive healthcare data used in AI training.”summary, stated

Tradeoffs

Publish a target architecture before full implementation.

Chose Aspirational blueprint over Only documenting completed production systems.

Rationale: The article is transparent about current limitations but its claims should be treated as planned rather than proven.

“This case study is notable because it represents an aspirational architecture rather than a completed implementation”summary, stated

Separate ML/LLMOps components from the monolith.

Chose Dedicated vector, serving, monitoring, and LLMOps layers over Extending Redshift/Airflow monolith for AI.

Rationale: Healthcare AI requires stronger governance, modularity, and model lifecycle support.

“designing a modular architecture that incorporates dedicated LLMOps tooling, vector databases, model serving infrastructure”summary, stated

Gotchas (what bit them)

BI-era data platforms can block ML/LLMOps.

Root cause: They lack vector databases, model registries, feature stores, model serving, and monitoring.

Resolution: Add dedicated ML storage, LLMOps tooling, and inference platform layers.

“no vector databases for embeddings, no model registry, no feature store, and no infrastructure for deploying and monitoring models in production.”summary, stated

Monolithic data repos slow teams as organizations grow.

Root cause: A single repo and daily release cycle created long CI pipelines.

Resolution: Move to modular ownership boundaries.

“single daily release cycle led to CI pipelines taking 30-40 minutes, slowing development velocity.”summary, stated

Evaluation

This is an architecture blueprint, so evaluation is by identified limitations and planned capabilities rather than measured production outcomes.

Metrics: Data team growth to over 100 members. · 30-40 minute CI pipelines. · Single daily release cycle.

“While primarily an architectural blueprint rather than a post-implementation case study, the plan demonstrates how healthcare organizations can structure their platforms to operationalize LLMs in production with proper governance, security, and team ownership boundaries.”summary, stated

Outcomes

Doctolib defined a modular healthcare data platform architecture for AI and LLMOps.
The plan introduces vector databases, model serving, monitoring, and LLMOps tooling.
The case is not yet evidence of completed production implementation.

The platform responds to a data organization of over 100 people and CI pipelines taking 30-40 minutes.

“the plan demonstrates how healthcare organizations can structure their platforms to operationalize LLMs in production”summary, stated