Research Consortium Federated Cohort Query

In science and research, the most useful questions often span several institutions. A consortium studying indoor air, for example, may enroll homes through different universities and institutes, each holding its own participant records under its own approvals. This concept illustrates a single query run in SemanticFed that answers one consortium question across every partner site, with the design keeping participant-level rows at the site that collected them.

Pooling that data the usual way means each site exporting records to a shared location, followed by agreements, de-identification and checks that nothing re-identifying slipped through. Even an aggregate table carries risk, because a cell that counts only a handful of homes can point to a specific household. The design treats both concerns as part of the run itself rather than as a manual step afterward.

The illustrated run detail sits in the Query Console, with a breadcrumb naming the sample consortium and a succeeded badge on the run. The question asks for homes with overnight nitrogen dioxide above a guideline level, grouped by cooking type, and resolves against a versioned consortium exposure model. Summary cards count the sites queried, participant rows exported, which reads zero in the sample, cells suppressed and columns masked. A Per-site execution panel shows each partner's Postgres database, the count by stratum pushed down to it and the number of homes it covered. The Pooled result table then lists each cooking type by site with a pooled total. Where a site's count falls below the threshold the cell reads as suppressed, and in those rows the pooled total is withheld as well, so the design keeps a hidden count from being worked back out of the totals.

A Governance panel lists the four columns masked by policy, namely home address, participant name, date of birth and zip code, and a minimum cell size of ten set as policy. Suppression is designed as a rule in SemanticFed's row and column policy model rather than a manual review. The panel also names the data use agreement behind the run and the CosmicIntersection grant it came through, with the grant's scopes and expiry, along with the researcher who requested the run and a count of approved policies that are active. The design intent is that CosmicIntersection holds the grant and SemanticFed enforces it at query time, so a data steward can see who asked, under which agreement and until when access runs. Save to CosmicIntersection and View audit log actions sit at the foot of the panel, the first designed to hand the pooled result back to CosmicIntersection.