I-ETL: Federated Health Data Integration

• I-ETL is an interoperability-aware health data pipeline that integrates diverse clinical datasets using standardized data and metadata models.
• Its ETL process systematically extracts, transforms, and loads data with built-in semantic mappings and explicit interoperability metrics.
• The framework supports decentralized analytics in privacy-constrained environments, enabling federated analysis across hospitals.

Searching arXiv for the cited I-ETL paper and closely related ETL/interoperability work to ground the article. arXiv search query: all:"I-ETL interoperability-aware health metadata pipeline federated analyses" I-ETL denotes “an interoperability-aware health (meta) data pipeline to enable federated analyses”, a framework designed for integrating highly heterogeneous healthcare datasets of hospitals in interoperable databases (Barret et al., 26 Sep 2025). It was proposed for settings in which clinicians need to analyze phenotypic, clinical, imaging, genomic, and related data across institutions while preserving decentralized data governance. Its central proposal is twofold: two general and extensible conceptual models for modeling both data and metadata, and an Extract-Transform-Load pipeline ensuring and assessing interoperability from the start. Within that formulation, interoperability is treated as a first-class property of the pipeline rather than a post hoc validation step, with explicit support for federated learning and distributed analytics in privacy-constrained clinical environments (Barret et al., 26 Sep 2025).

1. Clinical setting and design objective

I-ETL is situated in a healthcare context where clinicians and researchers want to better understand complex diseases, such as cancer or rare diseases, by producing and exchanging data across centers (Barret et al., 26 Sep 2025). The motivating constraint is that strict data protection regulations prohibit centralizing sensitive health data, so decentralized architectures and Federated Learning algorithms are preferred because data remains within the institutions in which it was collected (Barret et al., 26 Sep 2025). The corresponding obstacle is that hospitals and research centers often work individually with different representations and raw data, and therefore do not have means to normalize their data, and even less to do so across centers (Barret et al., 26 Sep 2025).

The framework addresses three linked problems. First, it seeks to provide a practical, extensible Common Data Model and metadata scheme capable of representing diverse medical data types. Second, it automates harmonization through an ETL process that includes both syntactic and semantic alignment. Third, it assesses and ensures interoperability at every stage using systematic metrics, rather than treating interoperability as an external audit after loading (Barret et al., 26 Sep 2025).

This design goal places I-ETL within a broader movement in ETL research toward pipelines that encode domain-specific constraints. In other domains, Obidos implements a hybrid ETL approach with incremental and selective integration for scientific data sharing (Kathiravelu et al., 2018), Dataverse provides an open-source ETL pipeline for LLMs (Park et al., 2024), and FlowETL proposes an autonomous example-driven ETL architecture that infers transformation plans from paired samples (Profio et al., 30 Jul 2025). I-ETL differs in emphasizing healthcare interoperability, federated analysis readiness, and explicit metric-driven assessment from feature definition through loading (Barret et al., 26 Sep 2025).

2. Metadata model

One of the two central conceptual models in I-ETL is a metadata model intended to maximize semantic interoperability by describing each feature in a structured way (Barret et al., 26 Sep 2025). The core entity is FeatureMetadata, whose fields are specified as follows:

• Name: feature name, such as calc_age
• Ontology: ontology reference used for semantic alignment, such as SNOMED-CT
• Code: unique code from the chosen ontology describing the feature concept
• Kind: feature category, such as phenotypic, clinical, genomic, or imaging
• DataType: expected type, including string, category, integer, numeric, boolean, date, and datetime
• Unit: measurement unit for numeric features
• Categories: mapping from categorical values to ontology resources
• Visibility: sensitivity flag, with values public, anonymized, or private (Barret et al., 26 Sep 2025)

The paper gives the feature “sex” as an example, with ontology SNOMED-CT, code 734000001, kind phenotypic, datatype category, mapped category values for Female and Male, and visibility public (Barret et al., 26 Sep 2025). The metadata model therefore supports both schema-level description and semantic anchoring, including value-level mappings for categorical variables. In practical terms, this allows a feature to carry not only a column name and type but also its ontology binding, unit semantics, and privacy handling requirements.

A plausible implication is that the metadata model is intended to reduce ambiguity before data transformation begins. In the I-ETL workflow, experts define the features to consider and specify their metadata prior to ETL execution, so metadata curation is structurally upstream of loading rather than embedded informally inside transformation scripts (Barret et al., 26 Sep 2025).

3. Common conceptual data model

The second conceptual model is the data Common Data Model (CDM), designed to standardize storage, access, and semantics of healthcare data after ETL (Barret et al., 26 Sep 2025). The model is described as broad and extensible for federated analysis, and its principal entities are Feature, Record, Patient, Hospital, and OntologyResource.

The Feature entity captures metadata and is specialized as PhenotypicFeature, ClinicalFeature, GenomicFeature, and related domain-specific subclasses (Barret et al., 26 Sep 2025). The Record entity represents the actual data value for a patient-feature-dataset triplet and includes an identifier, a value of any type, and dataset provenance. Record is likewise specialized as PhenotypicRecord, ClinicalRecord, GenomicRecord, ImagingRecord, MedicineRecord, and DiagnosisRecord, with specialized attributes such as file paths for images or VCFs (Barret et al., 26 Sep 2025). Patient contains only anonymized identifiers and no personally identifiable information, while Hospital provides institutional identity. OntologyResource serves as the semantic anchor for features or category values by storing a system, a code, and a human-readable label (Barret et al., 26 Sep 2025).

The core relationships are explicitly constrained. Each Record is instantiated by exactly one Feature, associated with exactly one Patient, and registered by exactly one Hospital (Barret et al., 26 Sep 2025). Each Feature may optionally be linked to one OntologyResource. The model is also extensible: new data types can be added by extending the Feature and Record entities (Barret et al., 26 Sep 2025).

This architecture is presented as a response to the heterogeneity of hospital data. The same framework is expected to represent phenotypic, clinical, imaging, and genomic information in a unified structure, while keeping the semantic reference layer explicit. The paper characterizes the models as general and extensible, and reports that experiments on open-source datasets showed that I-ETL succeeds in representing various health datasets in a unified way thanks to these two conceptual models (Barret et al., 26 Sep 2025).

4. ETL workflow and implementation

The I-ETL pipeline is organized as a sequence of stages in which interoperability assessment is integrated into the workflow itself (Barret et al., 26 Sep 2025). The described process is:

1. Selection
2. Feature definition
3. Metadata specification
4. ETL execution
5. Interoperability reporting (Barret et al., 26 Sep 2025)

During the Extract stage, the system reads datasets $D_1, \ldots, D_n$ and their metadata $M$, without normalization at that point (Barret et al., 26 Sep 2025). The Transform stage performs several concrete operations. Patients receive unique anonymized identifiers in the format <HospitalName>:<counter>. For each selected feature, the system generates a Feature object and associates it with an OntologyResource when available. For each patient-feature data point, it creates a Record (Barret et al., 26 Sep 2025).

Transformation is datatype-aware. The reported table-driven logic applies:

• String: trim and normalize
• Category: map to OntologyResource
• Date/Datetime: standardized ISO casting and format
• Boolean: cast accordingly
• Numeric: respect unit normalization and cast types (Barret et al., 26 Sep 2025)

Security handling is part of transformation. For fields marked anonymized, sensitive details such as the day of month are omitted as needed (Barret et al., 26 Sep 2025). In the Load stage, all instantiated Hospital, Patient, Feature, and Record objects are inserted into the target database; the implementation uses MongoDB, with indices for efficient querying (Barret et al., 26 Sep 2025).

The reported implementation is also operationalized for reproducibility. The framework supports automated, reproducible deployments, for example via Docker, and the code and data are described as open-source and available for verification and extension (Barret et al., 26 Sep 2025). This suggests that I-ETL is intended not merely as a conceptual reference model but as a deployable integration stack for federated clinical data preparation.

5. Interoperability assessment as a first-class property

A defining feature of I-ETL is that interoperability is not only enforced but also measured. The framework assesses interoperability at three levels: self-interoperability, intra-institution, and inter-institution (Barret et al., 26 Sep 2025). The last of these is explicitly described as crucial for federation.

The paper organizes metrics into data, metadata, and ETL categories, each scored in the interval $[0,1]$. The metric set is summarized below.

Metric	Scope	Description
A1	Data	Ratio of selected features
A2	Data	Ratio of datasets not requiring external extraction tools
M1	Metadata	Features having both ontology name and code
M2	Metadata	Features with non-empty dataType
M3	Metadata	Features with visibility set
M4	Metadata	Categorical features with category mapping
M5	Metadata	Numeric features with a unit specified
E1	ETL	OntologyResource objects with non-empty labels
E2	ETL	Proportion of Record values for which transformation to interoperability succeeded
E3	ETL	Numeric values matched to Feature units
E4	ETL	Categorical values declared in Feature categories
E5–E7	ETL	Referential integrity for Hospital, Patient, and Feature references

These metrics provide what the paper describes as practical, actionable feedback for improving interoperability (Barret et al., 26 Sep 2025). The immediate significance is methodological: interoperability becomes an observable property of the pipeline state, rather than a general aspiration. A plausible implication is that the framework encourages iterative remediation of metadata gaps, unit omissions, ontology coverage problems, and referential inconsistencies before federated analysis begins.

The paper also frames the approach as FAIR-aware by design, especially with respect to interoperability (Barret et al., 26 Sep 2025). In that sense, assessment is not a separate governance layer but an integrated component of the data engineering workflow.

6. Experimental evaluation and demonstrated use

The reported experimental scenario concerns patients with end-stage kidney disease (ESKD) who contracted COVID-19, using open-source, real-life data from 111 patients (Barret et al., 26 Sep 2025). The case study is divided across two simulated hospitals. Hospital 1 manages genomic data, specifically a panel of 2,382 most informative genes. Hospital 2 manages phenotypic, clinical, imaging, and diagnosis data (Barret et al., 26 Sep 2025).

Metadata were curated with ontology mappings sought via SNOMED-CT, LOINC, and HGNC, with categorical values and units specified where possible (Barret et al., 26 Sep 2025). The datasets were then processed through I-ETL, including anonymization, semantic mapping, and loading into two MongoDB databases, one per hospital, each using the CDM (Barret et al., 26 Sep 2025).

The reported interoperability assessment showed full interoperability—that is, a score of 1.0—for several metrics, including cases where almost all OntologyResources in genomic data carried labels, referential integrity was ensured, and transformation procedures for data and categorical mappings succeeded (Barret et al., 26 Sep 2025). Lower scores were observed for features missing units, described as common in medical datasets where units are implicit or missing, and for features for which ontology mappings could not be assigned, including niche genomic markers (Barret et al., 26 Sep 2025). The paper also notes that all categorical features in Hospital 2 were mapped to ontology categories, and that only one feature in Hospital 2 required anonymization for privacy (Barret et al., 26 Sep 2025).

The practical conclusion drawn is that the processed databases are ready for federated analyses, with features and data semantically aligned for automated distributed learning and analytics (Barret et al., 26 Sep 2025). The metric reports are further intended to help data stewards improve metadata and data quality in future runs.

7. Position within ETL research and scope of the term

Within the ETL literature, I-ETL belongs to a line of work that adapts ETL to domain-specific constraints rather than treating extraction, transformation, and loading as domain-neutral mechanics. Obidos addresses scientific data integration through a hybrid of eager and lazy ETL, with incremental loading, virtual proxies, replicasets, and human-in-the-loop selective integration (Kathiravelu et al., 2018). Dataverse targets LLM development with a unified open-source ETL pipeline, a block-based interface, a processor registry, and Spark-based scaling (Park et al., 2024). FlowETL pursues autonomous pipeline construction through a Planning Engine, Data Task Nodes, and LLM-based schema matching and transformation logic generation (Profio et al., 30 Jul 2025).

I-ETL is narrower in domain but more explicit in its treatment of interoperability. Its distinguishing claims are the use of two general and extensible conceptual models, the integration of interoperability assessment from the start, and the orientation toward federated healthcare analyses under privacy constraints (Barret et al., 26 Sep 2025). The framework is also presented as not tied to a single data type or domain, in contrast to more rigid healthcare models, because it supports phenotypic, clinical, imaging, genomics, and extensible specializations of both Feature and Record (Barret et al., 26 Sep 2025).

This suggests that I-ETL should be understood less as a generic automation framework and more as an interoperability-centric reference architecture for decentralized biomedical data integration. Its contribution lies in combining metadata formalization, a healthcare CDM, datatype-aware transformation, privacy-aware loading, and explicit interoperability metrics into a single operational pipeline (Barret et al., 26 Sep 2025).