Checking for conflicts when neither side can show their data

David Uzan · 17 August 2026

A hospital is about to prescribe a new set of medications. A pharmaceutical company maintains a database of known drug interactions. Between them sits a question that genuinely matters: is anything in this patient's regimen dangerous in combination with what's being added?

The hospital won't send out the patient's medication list. That's PII, and in most jurisdictions sharing it with a third-party checker is somewhere between risky and prohibited. The pharma company won't hand over its full interaction database either; that's years of proprietary research. So the check happens partially, or late, or through a workaround that someone in compliance would not enjoy reading about.

This shape of problem is everywhere once you start looking. My private list, your private list, and a public set of rules that says which combinations matter. Allergens and ingredients. Regulatory clauses and business activities. Bill of materials and proposed component substitutions. The rules are common knowledge. The lists are not.

What Rule-Based Cross-Match does

Rule-Based Cross-Match is a JuLenny function built for exactly this pattern: "does my X interact with your Y under public rules R?"

It starts with the rule list, which is the one piece that's genuinely public. A simple CSV, each row pairing one item with another: aspirin with warfarin, metformin with contrast dye, and so on. The rule list says "if one side has the left item and the other side has the right item, that's a match." It reveals nothing about who has what.

Then each party marks which items it holds and encrypts that private list. Encryption happens locally, on each party's own machine, with the JuLenny client. Neither list is ever uploaded in readable form.

The platform walks the rule list and checks every pair against the two encrypted indicators. Every check runs on encrypted data. JuLenny never sees either list; it sees only ciphertext, and the joint decryption key is split between the parties, so nothing is readable without both of them approving.

What you get back

Two variants, for two different needs.

The count variant returns a single number. "3 interactions found." That's the quick go/no-go: is there a problem at all, and how big.

The itemized variant tells you exactly which rules fired. "Row 1 (aspirin + warfarin): match." That's what you want when the answer drives action: substitute this medication, remove that ingredient, rework that clause.

In both cases, everything that did not trigger a rule stays hidden. The hospital learns about the dangerous combinations, not about the pharma company's research beyond the shared rules. The pharma company never sees the patient's medication list at all.

Beyond the pharmacy

The same function, unchanged, covers a surprising range of checks:

A restaurant's recipe against a customer's dietary restrictions, using a public allergen table. The customer doesn't expose their full medical profile; the restaurant doesn't expose its recipe. The answer is "2 violations" or "all clear."

A company's planned activities against applicable regulatory clauses. "4 compliance issues found," without the company exposing its full plan.

A manufacturer's bill of materials against a supplier's proposed substitutions, using a compatibility table. "1 incompatible swap," caught before it ships.

Open role requirements against a candidate pool, through a role-fit matrix. Matches surface; everything else stays private on both sides.

Why it took until now

The answer to "why can't we just check?" was always that checking required seeing. Some intermediary, somewhere, had to hold both lists in the clear, and that intermediary became the problem: a breach target, a compliance liability, a party to be audited and trusted.

On JuLenny there is no such intermediary. The computation happens, the answer comes out, and at no point does any party, including us, hold both lists in readable form. Zero trust by protocol, not policy.

If your organization has a check it should be running but can't, because the data on one side or the other can't move, that's exactly the conversation we want to have. Get in touch.