Horizontal Federated Learning (HFL), often called sample-partitioned or homogeneous federated learning, is a collaborative training paradigm where n clients hold data matrices that align vertically in feature schema but diverge horizontally in sample IDs. This is the most common topology in healthcare, where two hospitals record the same clinical measurements (e.g., blood pressure, lab values) for entirely different patient cohorts. The mathematical objective is to aggregate local model updates without exposing raw patient records, effectively increasing the virtual training set size while preserving federated data locality.
Glossary
Horizontal Federated Learning

What is Horizontal Federated Learning?
Horizontal Federated Learning (HFL) is a decentralized machine learning topology where participating datasets share an identical feature space but contain different, non-overlapping sample populations.
The primary technical challenge in HFL is managing federated non-IID data distributions, where local client datasets exhibit statistical skew despite sharing a common feature space. To mitigate federated model divergence, aggregation algorithms like Federated Averaging (FedAvg) compute a weighted mean of local stochastic gradient descent updates. This architecture is foundational to cross-silo federated learning networks, enabling multi-institutional diagnostic models that generalize across diverse patient populations without violating HIPAA or GDPR constraints.
Key Characteristics of Horizontal Federated Learning
Horizontal Federated Learning (HFL) is defined by a specific data partitioning schema where features are aligned but samples are distributed. The following characteristics distinguish it from other topologies and define its architectural requirements.
Shared Feature Space
The fundamental prerequisite for HFL is feature alignment across all participating nodes. Every hospital must collect the same clinical variables—such as blood pressure, heart rate, and lab values—using compatible schemas. This is typically enforced through a Federated Common Data Model (CDM) like OMOP.
- Requirement: Identical feature schemas across all clients
- Example: Three hospitals all recording
HbA1c,LDL, andBMIfor diabetic patients - Contrast: Vertical FL shares samples but different features; HFL shares features but different samples
Disjoint Sample Populations
In HFL, each client holds a mutually exclusive set of data subjects. Hospital A's patients do not overlap with Hospital B's patients. This is the natural state of medical data—patients typically receive care at a single institution.
- Key Insight: No entity resolution or record linkage is required between sites
- Benefit: Simplifies privacy compliance since patient identities are not matched across institutions
- Scale: Sample sizes can range from thousands (cross-silo) to millions (cross-device)
Federated Averaging (FedAvg) Compatibility
HFL is the native topology for the Federated Averaging algorithm, the most widely deployed aggregation strategy. Because local models share identical architectures and feature spaces, their weight matrices are directly element-wise averageable.
- Process: Each client trains locally on its own samples, then uploads model weights to the aggregation server
- Formula: Global weights = weighted average of local weights, proportional to local dataset size
- Advantage: Mathematically straightforward convergence guarantees under IID assumptions
Non-IID Data Distribution Challenge
Despite aligned features, HFL suffers from statistical heterogeneity when local data distributions diverge. Hospital A may treat predominantly geriatric patients while Hospital B serves a pediatric population, creating label distribution skew and concept drift.
- Label Skew: Disease prevalence differs dramatically across sites
- Feature Skew: Same lab test may have different normal ranges across demographics
- Mitigation: Requires proximal regularization terms like FedProx or personalized FL layers to prevent model divergence
Sample-Size Weighted Aggregation
HFL aggregation typically weights each client's contribution by its local dataset cardinality. A hospital with 100,000 records exerts more influence on the global model than one with 5,000 records.
- Rationale: Larger datasets produce lower-variance gradient estimates
- Risk: Can bias the global model toward the data distribution of the largest institution
- Alternative: Equal weighting or inverse-variance weighting can be used to balance influence across heterogeneous sites
Cross-Institutional Generalization
The primary clinical motivation for HFL is building models that generalize across diverse patient populations without centralizing protected health information. A model trained on geographically distributed data learns robust features rather than site-specific artifacts.
- Outcome: Reduced overfitting to any single hospital's demographic biases
- Validation: Requires federated model evaluation where each site tests the global model on its local holdout set
- Regulatory Alignment: Satisfies GDPR data minimization and HIPAA minimum necessary standards
Frequently Asked Questions
Clear answers to common questions about the architecture, security, and implementation of horizontal federated learning in healthcare networks.
Horizontal federated learning (HFL) is a decentralized machine learning paradigm where participating institutions share the same feature space but hold data on different patient populations. In a typical healthcare HFL round, each hospital downloads a global model, trains it locally on its own patient records, and sends only the encrypted model updates—never the raw data—to a central aggregation server. The server applies a federated aggregation algorithm like Federated Averaging (FedAvg) to combine these updates into an improved global model. This architecture is also known as sample-based federated learning because the data partitioning occurs across rows (samples) rather than columns (features). HFL is the most common topology for cross-institutional medical imaging collaborations, where every hospital captures the same MRI sequences and lab values but for different patients.
Horizontal vs. Vertical Federated Learning
Structural comparison of the two primary federated learning paradigms based on how data is partitioned across participating nodes.
| Feature | Horizontal Federated Learning | Vertical Federated Learning | Federated Transfer Learning |
|---|---|---|---|
Data Partitioning Axis | By samples (rows) | By features (columns) | By both samples and features |
Feature Space Overlap | Identical feature space | Different feature space | Minimal or no overlap |
Sample Space Overlap | Different sample space | Identical sample space | Minimal or no overlap |
Entity Alignment Required | |||
Typical Use Case | Multiple hospitals with same lab tests for different patients | Hospital and insurer with different attributes for same patients | Cross-domain collaboration with no common data dimensions |
Common Aggregation Algorithm | Federated Averaging (FedAvg) | Split Neural Network with encrypted entity alignment | Domain adaptation with co-regularization |
Privacy Mechanism | Differential privacy on gradients | Entity resolution with private set intersection | Instance-based transfer with domain-invariant features |
Communication Overhead | Moderate | High (intermediate activations) | Moderate to high |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Healthcare Use Cases for Horizontal Federated Learning
Horizontal federated learning enables hospitals to collaboratively train robust diagnostic models on identical feature sets without exposing patient records, unlocking multi-institutional research while maintaining strict privacy compliance.
Multi-Hospital Diagnostic Imaging
Radiology departments across institutions share the same imaging modalities—CT scans, MRI, and X-rays—but serve different patient populations. Horizontal FL allows them to jointly train a tumor detection model without centralizing sensitive scans.
- Each hospital trains locally on its own PACS data using identical feature extraction pipelines
- Only encrypted gradient updates are transmitted to the aggregation server
- The global model learns from diverse patient demographics, improving generalization
- Proven effective for breast cancer screening and lung nodule classification across geographically dispersed sites
Cross-Institutional ICU Mortality Prediction
Intensive care units collect the same structured vital signs, lab values, and ventilator parameters for different patient cohorts. Horizontal FL enables collaborative training of early warning systems across hospital networks.
- Features include heart rate, blood pressure, SpO2, and serum lactate—standardized across all ICUs
- Models trained on aggregated data from multiple hospitals detect rare deterioration patterns invisible to single-site datasets
- Federated training preserves the privacy of protected health information under HIPAA
- Demonstrated superior AUROC compared to single-hospital baselines in sepsis prediction
Multi-Site EHR-Based Readmission Risk Stratification
Hospitals using the same electronic health record system with standardized ontologies can collaboratively predict 30-day readmission risk without sharing patient-level discharge summaries.
- Features include diagnosis codes, medication lists, and prior admission history—identical schema across sites
- Horizontal FL aggregates learnings from diverse socioeconomic populations
- Each hospital benefits from patterns observed at peer institutions while maintaining data locality
- Enables proactive discharge planning and targeted follow-up interventions
Collaborative Pathology Slide Analysis
Digital pathology departments capture whole-slide images at standardized resolutions and stain protocols. Horizontal FL allows multiple labs to jointly train cancer grading models on gigapixel images.
- Identical feature extraction pipelines process H&E-stained slides across institutions
- Federated training captures morphological variability across patient populations
- Addresses the rare disease problem—no single hospital has sufficient cases of uncommon malignancies
- Compliant with GDPR and HIPAA requirements for cross-border research collaborations
Wearable Cardiac Arrhythmia Detection
Cardiology clinics monitor patients using FDA-cleared wearables that record identical ECG lead configurations. Horizontal FL trains arrhythmia classifiers across clinic populations without uploading raw waveforms.
- Features are standardized: RR intervals, QRS duration, and ST-segment measurements
- On-device training preserves continuous monitoring data privacy
- The global model benefits from diverse arrhythmia presentations across age groups and comorbidities
- Enables personalized alert thresholds while maintaining a robust base model
Federated Pharmacovigilance Signal Detection
Pharmacovigilance centers monitor the same adverse event reporting forms with standardized MedDRA coding. Horizontal FL enables collaborative drug safety signal detection across national databases.
- Features include drug names, reaction terms, and patient demographics—identical coding systems
- Federated aggregation detects rare adverse events that individual centers lack statistical power to identify
- Maintains regulatory compliance with data residency requirements across jurisdictions
- Accelerates post-market surveillance without requiring centralized data warehouses

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us