back
11 comments
I don't quite understand their example - they reproduce a study done with de-identified genomic data. For each patient, the data required for the analysis are the number of mutations in the tumour, the type of tumour and how long they lived for. The genomic data cannot be related back to an individual. I guess it is just a toy example rather than an actual use case.

It seems that their model would work best when sharing rich data like medical records or perhaps imaging. But it isn't clear to me that the more sophisticated analyses required for such datasets can be done with their system.

It also occurs to me that analyses done with these privacy preserving methods will not be reproducible, since the data is just not available. They don't mention reproducibility once. On the other hand, you can download the data used in the study of tumor mutational burden and run the analysis yourself [1].

Perhaps they aren't big on reproducibility. They don't make their code available actually...

[1] https://www.nature.com/articles/s41467-021-25972-y#data-avai...

Isn't it more the case that privacy preservation allows from more sharing of data since it produces anonymised data that actually can be shared?

The fact that they don't share any data is down to these particular researchers, not a consequence of their methods as the entire baseline for the field of medicine is that sharing raw data is a gross ethical violation.

It would be helpful to see the code and to know whether their protocol uses a unique feature of the Latice-based primitives it depends on, or if their protocol could be implemented with current block ciphers.

I work on a variety of health data problems that would benefit from a practical FHE implementation with standards backing. This Federated Analysis (FA) piece is new to me, but mainly because I deal with it from the infrastructure side and not the research side. Google has a good blog post on it: https://ai.googleblog.com/2020/05/federated-analytics-collab...

Biomedical research could be an ideal application for FHE, it's true.

Medical researchers are already used to registering their trials and how they're going to analyse their data before the trial starts. They're also used to needing to get approval from oversight bodies before they start working. The data will be subject to human error, but not part of an adversarial cat-and-mouse game. Their means of analysis aren't 'secret sauce' that would have to be kept secret. And even if homomorphic encryption is 10,000x slower than normal encryption, it's still fast compared to a medical trial.

Nice application of HME. The runtime is pretty long especially if there are faults (which is not talked about). Also it is a big assumption that each institution will have equal sized data. That is never the case in practice, so inevitably there will be a hot spot.

The other hurdles they mentioned:

  * data prep and transfer
  * harmonization of the data model
are still hurdles for many institutions. The second one in particular although standards like FHIR and OMOP are increasing traction. Other data modalities like imaging would be more difficult.
Looking at the Kaplan-Meier estimator, aren't the sites just sharing, for each timepoint, the number at risk and the number of events? Perhaps reviewers asked for this, but it seems fairly irrelevant.

It would be nice to see just the kernel of their claimed advance.

Isn‘t the point of Homomorphic Encryption to do it in the cloud? What’s the point of using it in a federated setting?
The point is to prevent data leaking. Since medical data is quite sensitive, giving someone the data--even another researcher--requires a great deal of trust. Homomorphic encryption makes it easier.

I have a friend who works with individual-level Census data that is similarly sensitive. Getting cleared to use the data required a lengthy training and vetting period, and when she wants to actually access it to do an analysis she has to go to a secure room at another university. She's not allowed to bring any of her own electronics in, only pen and paper. The analysis script and anything derived from the data (analysis script output) is cleared by a Census Bureau employee before it leaves the room, to make sure it's not leaking any personal information.

There are some really goofy laws about moving medical data around. My lab is involved in a couple of large projects that involve researchers at other hospitals, and we're not allowed by law to send the data from these grants directly to our partners. Instead, we push things up to a google bucket, and then the other hospitals pull down from that bucket. I have no idea why that's the way things are done, but it's true for more than one of our grants, so there's obviously some sort of systemic thing going on with it.
As far as my understanding goes, federation already solves the problem of data leaking, doesn't it? I mean, that's what you are describing, the data does not leave it's source, you (the algorithm) have to move to the data not the other way around.

That's exactly as I understand federation: the (original) data never leaves the home organization. But because everyone uses the same data model + algorithms (and those are choosen to enable combination of the output from each federated processing site) the results can be combined into a single outcome.

So, if data leaking is already solved for by keeping the data locally, why would I employ HE? Unless maybe the participants should not be able to look into the algorithms itself?

No, federation alone doesn't solve the problem. This is addressed in the third paragraph of the paper; the TLDR is that federated processing might still leak personal information:

> The adoption of FA in the medical sector, despite its potential, has been slower than expected. This is in large part due to the unresolved privacy issues of FA, related to the sharing of model updates or partial data aggregates in cleartext. Indeed, despite patient-level data not being transferred between the institutions engaging in FA, it has been shown that the model updates (or partial aggregates) themselves can, under certain circumstances, leak sensitive personal information about the underlying individuals, thus leading to re-identification, membership inference, and feature reconstruction. Our work focuses on overcoming this key limitation of existing FA approaches.