Private Set Intersection Protocols in Healthcare AI Data Pipelines

Two hospitals can suspect they treat the same patients and still be legally barred from checking. Private Set Intersection solves that exact problem: it lets two institutions find out which patient records overlap without either one showing the other its underlying data. That capability is turning into a real piece of infrastructure in healthcare AI, and this piece walks through why, starting with what the math actually promises and ending with where the research is headed. I've spent enough time around hospital data-sharing agreements to know that "just anonymize it" is not an answer anyone's legal team accepts, so this is about the thing that actually gets built instead.

Deep learning models for clinical prediction need large, varied patient datasets to work well, but that data sits locked inside institutional silos, kept there by law and by policy written before most of the AI techniques now trying to get around it even existed. ONC's 2024 data brief found that only 43% of U.S. hospitals routinely engage in all four interoperability domains, which means most still can't move, find, send, and pull in patient data the way a working national health system should. Every workaround carries its own cost, too: IBM's 2025 Cost of a Data Breach Report put the average healthcare breach at $7.42 million and 279 days to contain. Sit with that second number for a second. Nine months of a breach sitting open before anyone fully contains it, and that's the average, not the bad case.

Institutions want to work together on trial recruitment, rare disease research, joint model training. Patient overlap across nearby facilities is common; nobody in this field finds that surprising when a patient sees a specialist across town and shows up in two systems at once. Joint computation over that overlap, though, is either flatly prohibited or takes so much coordination that the project dies in committee before anyone writes a line of code. PSI was built to close that gap.

What private set intersection actually does — and what it doesn't reveal

Strip away the cryptography and PSI answers one question: do our two datasets overlap, and if so, where? Two parties compute the intersection, and neither learns anything about the other's records outside it. Records that don't match stay invisible to both sides, withheld by the math itself rather than merely anonymized or hidden behind a policy that someone could, in theory, choose to ignore.

That's a different guarantee than de-identification or tokenization gives you. Those reduce identifiability, sure, but they still leak set membership patterns. An attacker with enough context can sometimes figure out who's in a dataset without seeing a single name attached to it. PSI's guarantee doesn't depend on the attacker being ignorant or under-resourced, and the protocol never produces the non-matching data in usable form on either end. That's the part people miss when they first hear the pitch: this isn't better anonymization, it's a different category of promise entirely.

One variant worth knowing by name is PSI-Cardinality, or PSI-CA, which reveals only the count of matching records, not the records themselves. Small difference on paper, big one in practice. Before two hospitals sign a data-sharing agreement, someone can ask how much overlap they actually have, get back a number and nothing else, and kill the project early if the overlap's too thin to bother with.

The field traces back to a formal introduction at FNP 2004, built initially on Diffie-Hellman key exchange, and has since branched into a wide family of constructions tuned for different dataset sizes, trust levels, and network conditions. PSI answers one precise question, do we share patients, without training a model, moving records, or leaving behind a merged dataset sitting somewhere waiting to be queried by someone who shouldn't have access to it.

The protocol families healthcare engineers actually choose from

Most efficient two-party PSI implementations lean on Oblivious Pseudorandom Functions, or OPRFs, which the IETF standardized through RFC 9497. That standardization matters more than it sounds: a stable spec means vendors and hospitals can build implementations that actually talk to each other instead of everyone rolling out an incompatible flavor. VOLE-PSI, which uses vector oblivious linear evaluation to build a batched OPRF, sits near the top for raw speed right now, and that starts to matter once dataset sizes climb into the hundreds of thousands or millions and throughput becomes the actual bottleneck rather than a theoretical concern.

Clinical data rarely shows up in balanced pairs, though. One side often holds a small set, trial eligibility criteria, say, while the other holds an EHR repository with millions of entries. Unbalanced PSI protocols exist for exactly this mismatch. A 2025 NDSS paper on recurrent PSI for unbalanced databases uses leveled fully homomorphic encryption so institutions don't have to rerun the whole protocol every time they want to recheck overlap, with communication scaling to the smaller set's size instead of the larger one. That's a real gain when the small set is 500 eligibility criteria and the large set is a hospital system's entire patient roster.

Circuit-based PSI and exclusive PSI protocols like Labelled PSI solve different problems, and it's easy to blur them together if you're new to the space. Circuit-based approaches compute arbitrary functions over the intersection, aggregate statistics, say, while exclusive PSI just spits out membership and nothing more. Multi-Party PSI stretches the two-party case to three or more institutions, which sounds like the natural next step for hospital consortia until you notice communication overhead climbs with each added participant, sometimes steeply enough to make a five-hospital consortium impractical with today's constructions.

And then there's the actual mess of clinical data: OCR errors, spelling variants, a "Jon" here and a "John" there, dates entered as MM/DD in one system and DD/MM in another. Fuzzy PSI handles this with a closeness function instead of demanding an exact match, and both EUROCRYPT 2024 and ASIACRYPT 2025 introduced more efficient constructions here. Underneath all these variants sit the same building blocks: oblivious transfer extension, oblivious key-value stores, cuckoo hashing for bin assignment, homomorphic encryption for polynomial membership tests. Which variant a team picks also comes down to the threat model. Most deployed protocols assume semi-honest, or honest-but-curious, adversaries; malicious-secure variants exist but cost more compute, and the right call depends on how much institutions actually trust each other. In healthcare consortia, that trust varies more than anyone likes to admit out loud.

Where PSI plugs into real healthcare AI workflows

Privacy-Preserving Record Linkage, or PPRL, is the most mature application here, and it's already running in production, not just in a lab somewhere. MainSEL, short for Mainzelliste Secure EpiLinker, is a working MPC-based PPRL system with no trusted third party, and its benchmarks tell a story on their own: 3.9 seconds per record lookup against a 10,000-record database on a low-latency LAN, but 48 seconds on a high-latency WAN. Network conditions, not just cryptographic overhead, drive real-world latency here, and the performance section further down comes back to exactly this.

A common setup pairs locality-sensitive hashing with PSI. Fields get locally hashed with LSH before matching, which allows fuzzy linkage while keeping the privacy guarantees tunable through the LSH parameters. This matters for vertical federated learning, too, where institutions hold different feature sets about the same overlapping patients: one hospital has imaging, another has lab results, for shared patients. PSI finds the common sample space before any training starts. Gradient exchange in vertical FL doesn't even make sense as a computation without entity alignment first; you can't average gradients over records that don't correspond to the same patients. So the pipeline runs PSI for alignment first, then handles privacy-preserving gradient aggregation through secure aggregation or differential privacy.

Clinical trial cohort identification fits unbalanced PSI naturally, since eligibility criteria form a small set intersected against sprawling EHR repositories across multiple health systems. For multi-institution feasibility studies, PSI-CA lets everyone count overlap before committing to full linkage or a governance agreement, sidestepping regulatory exposure for a study that might not even be statistically viable once the numbers come back. Genomic applications, paternity testing, genetic compatibility checks, personalized medicine: these all involve set operations over identifiers sensitive enough that exact-match PSI is close to the ideal tool for the job.

How PSI fits into federated learning architectures across hospital networks

Federated learning splits into two main flavors, and PSI plays a different part in each. In horizontal FL, where institutions share the same features but different patient populations, PSI runs before training to check dataset coverage and de-duplicate overlapping patients, preventing double-counting without ever exposing a patient list to anyone. In vertical FL, where institutions hold different features about overlapping patients, PSI sits at the alignment step, which a 2025 PETS paper spells out explicitly for production-grade vertical FL systems.

Major frameworks have already built this in. FATE, PySyft, and NVIDIA FLARE all include built-in or pluggable PSI modules for alignment, and NIH, NHS, and Genomics England have deployed federated learning using NVFlare, PySyft, and Flower. The federated learning market reached $0.1 billion in 2025 and is projected to hit $1.6 billion by 2035, growing at a 27.3% compound annual rate. PSI's role scales right alongside it, since you can't really do vertical FL at scale without solving alignment first.

Deployment on the ground tells a messier story, though. Only 5.2% of federated learning research has reached real-world use, meaning most PSI-FL integrations sit stuck in academic papers or narrow pilots that never made it past a single hospital system. Clinical workflows have tight latency budgets, EHR schemas differ wildly from one institution to the next, and the shared patient identifiers that would make all of this simpler just don't exist, which is the exact absence PSI is meant to work around in the first place. PSI also doesn't fix federated learning's other weak points. Gradient inversion attacks, model poisoning, aggregator compromise: these need separate defenses layered on top, since PSI only handles alignment and stops there.

Performance and security tradeoffs engineers face when deploying PSI at clinical scale

The numbers ground this better than generalities do. A PSI-CA protocol over two sets of one million elements each takes 41 seconds at 80-bit security and 339 seconds at 256-bit security on moderate hardware running in parallel. That's roughly an eightfold jump in runtime for a much higher security margin, and it shows a tradeoff engineers hit directly: raising the security level doesn't add to the runtime, it multiplies it.

The choice between semi-honest and malicious security models isn't academic hair-splitting, either. In the malicious model, a participant could enumerate every possible element in a finite, structured universe, patient ID ranges, say, and stuff them all into their own set, effectively learning which elements the other party holds through the intersection result. That's a realistic attack in healthcare, where ID spaces are often finite and predictable enough to enumerate. FHE-based unbalanced PSI carries its own specific risk, too: a malicious sender can trick the receiver into accepting a non-intersecting item as a match, something 2025 research calls a deception attack. The proposed fix uses Merkle trees for authenticated PSI, catching the deception before it spreads downstream into whatever model gets trained next.

Network conditions, more than algorithm choice, often dominate real-world latency. The MainSEL numbers make this concrete: 3.9 seconds on LAN versus 48 seconds on WAN, roughly a twelvefold gap, and no amount of protocol tuning closes it if the network itself is the bottleneck. OKVS and cuckoo hashing optimizations do cut communication volume meaningfully compared to naive polynomial approaches, and that matters a lot for hospital systems connected over WAN instead of sitting in the same data center rack.

Recurrent PSI, the 2025 NDSS work mentioned above, exists for a plain reason: hospital datasets don't sit still. They change constantly, and rerunning a full PSI protocol from scratch every time two institutions want to check overlap wastes real compute and real time. Leveled FHE lets that recomputation happen incrementally instead of from zero. Underneath all of this sits a plain, unglamorous fact, too: PSI's guarantees are only as strong as the cleanup work feeding it. EHR systems use different identifier formats, different date conventions, different coding standards, and if that normalization step is sloppy, PSI will happily report zero overlap between two datasets that actually share thousands of patients. Garbage in, confident garbage out.

How HIPAA's evolving requirements create both the mandate and the cover for PSI adoption

HHS OCR's late 2024 proposed rule to modify the HIPAA Security Rule pushes several safeguards that used to be merely "addressable" into mandatory territory: MFA at every ePHI access point, and required encryption both at rest and in transit across every environment. PSI fits this shift almost too neatly. Raw PHI never crosses institutional boundaries in a PSI protocol, so the approach directly backs the access-control and encryption posture these rules now demand. It's a genuine match between what the rule asks for and what the protocol already does, which doesn't happen often when law and cryptography cross paths.

The regulatory landscape institutions operate in cuts both ways, too. Regulators have made clear that information blocking prohibitions don't override privacy protections, so organizations face exposure on two fronts at once: under HIPAA, under 42 CFR Part 2, and under information blocking rules, for both over-restricting data and over-disclosing it. That's a narrow needle to thread. PSI-CA handles the over-disclosure side specifically. In a feasibility study, revealing only a patient count instead of a matched record list means no PHI changes hands at all, yet the institution still meets its obligation to check whether a data-sharing arrangement is even worth pursuing.

There's a quieter upside, too. Every additional PHI copy made for an ETL pipeline, a data warehouse, a cross-institutional transfer, expands what needs auditing and what's exposed if something breaks. PSI cuts down how many of those copies need to exist at all, shrinking audit scope and breach surface together, which is a rare case where privacy engineering and operational simplicity actually point the same direction instead of fighting each other. This isn't a purely domestic story, either. GDPR's data minimization principle and purpose limitation requirements line up closely with PSI's output-only model, and that lines up more as cross-border clinical research between EU and U.S. institutions runs into dual regulatory exposure that a protocol built around minimal disclosure happens to fit well.

What a PSI-enabled healthcare AI pipeline looks like end to end

Walk through it in order and the pieces click together. Phase one is feasibility: run PSI-CA across the institutions to count patient overlap, no PHI disclosed at any point, so the governance decision gets made on statistical grounds before anyone signs anything. Phase two is entity alignment, using full PSI, or fuzzy PSI where record quality is inconsistent, to find the shared patient sample space, with each institution learning only which of its own records matched and nothing about the other side's full dataset.

Phase three moves into feature exchange or model training itself: vertical FL gradient exchange or secure aggregation running over the now-aligned sample, with PSI output feeding directly into whichever framework's alignment module is in use, FATE, NVIDIA FLARE, PySyft. Phase four is deployment: the trained model runs on local data at inference time, and PSI drops out of the picture unless the model gets retrained on a new cohort down the line. The whole point of building privacy-first infrastructure this way is that no institution's raw data should ever land in a shared computational environment at any phase, and PSI is the connective tissue that makes that promise hold across the four phases.

A few failure modes need design attention up front, because they don't announce themselves loudly. Identifier normalization failures upstream of PSI silently invalidate matches without throwing any error, so a hospital could think it has zero overlap with a partner when the real problem is a mismatched date format sitting three steps back in the pipeline. Semi-honest-only security assumptions break down fast when institutional incentives aren't actually aligned, so threat model choice has to reflect the real trust relationship between parties, not an idealized one drawn up during contract negotiations. PSI output itself, meanwhile, can leak membership information back to the querying party. In small cohorts, the intersection size alone can be re-identifying, since knowing "12 patients matched" out of a tiny population narrows things down fast for anyone paying attention. PSI-CA combined with noise added to the count, differential privacy layered on the cardinality result, is the standard fix here.

Where PSI research is moving and what it means for clinical deployment timelines

IETF's standardization of OPRF through RFC 9497 is a real maturity signal, not a bureaucratic footnote to skim past. Once a stable spec exists, interoperability across vendors and institutions stops being a research problem and turns into an engineering one, and that changes how fast this technology actually spreads through hospital IT departments. Fuzzy PSI is probably the frontier most relevant to real clinical data quality, since the EUROCRYPT 2024 and ASIACRYPT 2025 constructions, while still heavier computationally than exact-match PSI, are closing that gap steadily year over year. That matters a lot for EHR linkage, where name and date-of-birth variants are the norm rather than some rare edge case.

Recurrent and incremental PSI address something the performance section already flagged: hospital datasets change constantly, and protocols that spread setup cost across repeated intersections are simply more workable in production than one-shot schemes built for a single comparison. Malicious-secure PSI and authenticated PSI, the Merkle tree constructions from 2025 mentioned earlier, are moving from theory papers toward things engineering teams can actually deploy on real infrastructure. That matters as institutions move from pilots into production, where trust assumptions get harder to hold together the more parties join in.

That 5.2% real-world deployment rate for federated learning deserves a second look, because it tells you where the actual bottleneck sits. The cryptography mostly works; what's missing is the unglamorous integration work: schema normalization across mismatched EHR systems, governance frameworks institutions can actually agree to sign, and consensus on which threat model reflects reality instead of whatever's convenient to assume. The near-term path still looks workable, though. PSI-CA for feasibility studies is deployable today with tooling that already exists, while full vertical FL pipelines with PSI alignment need more integration work but have live reference deployments at NIH and NHS to learn from instead of starting from a blank page.

PSI makes it possible to ask who do we share before ever asking what do we share. That turns the governance conversation away from blanket data-sharing agreements negotiated once and applied broadly, toward precise, cryptographically enforced queries asked one at a time, each one scoped to exactly what's needed and nothing more. It's a smaller ask on paper than a sweeping data-sharing pact. But it may end up mattering more, since it's the difference between institutions that never collaborate because the legal risk feels unbounded, and institutions that collaborate often because the risk finally has a shape they can measure before they sign anything.