Verifiable privacy for digital health twins

The challenge

A digital health twin is a dynamic, virtual copy of a person. It is continuously updated with real-time personal health data from wearables and lab results. It may also store other sensitive medical data, such as a person’s medical imaging records or their genome. These data are a huge and valuable asset. Over a lifetime they grow into an invaluable treasure of data for the person, but also for science. To realise their value, these data need to be stored, permitted to interact with algorithms for analysis and eventually shared. The person the data are about controls this process, in principle. But consider an unencrypted record on a laptop or in the cloud, wearable data scattered across different providers, a loose folder of lab data. All of these can be lost or copied unknowingly, read by an unauthorised agent, or kept by a vendor even after a deletion request. The risk of abuse is huge.

The Open Science Foundation is looking for new ideas and solutions to the privacy challenges that arise when personal medical data are aggregated into a human digital twin. This challenge should be approached as a property of the whole lifecycle of one person’s data. Where are the data stored, and under which key? What program or agent, if any, computes on them? What do models and statistics learn from them? And what do the twin’s answers give away when they are shared? Leakage and unauthorised aggregation by others is a further challenge, often overlooked and critical: each time data are shared, the personal health data store leaks a little, and over a lifetime these leaks can threaten an individual’s privacy.

Today no satisfactory approach exists for the individual to verify the integrity (nothing has been altered or lost) and the confidentiality (every read or copy was authorised and is on record) of their personal health data store, whether it sits locally, in the cloud or in multiple decentralised locations. A person can neither see how much has leaked nor assess how much any leak matters.

What makes a digital twin really private? What can a twin reveal over time, across storage, computation, aggregation and sharing? And how can that lifetime leakage be measured, bounded or checked?

What we fund

This call funds verifiable privacy for health data that belongs to one person specifically. We do not focus on large cohorts of data of a hospital or a study, but personal health data. Any data type feeding a digital twin and any personal agent acting for that person are in scope. Your contribution to the call must allow verification by the person the data are about. We welcome contributions to at least one of these four lines:

01 Storage

Ways for a person to check, without trusting whoever holds the data, where every copy lives and under which key, and that a deleted copy can no longer be read, including vendor and derived copies.

Example methods

Envelope encryption with keys held in hardware (TPM, secure element, FIDO2); threshold key backup (Shamir); key transparency and witnessed logs of copies and deletions; crypto-shredding of wrapped keys, with receipts; deletion tests via vendor APIs and data-subject requests; post-quantum key wrapping (ML-KEM).

02 Computation

Checks the person's device can run: attestation of the remote host and its model before data leave, confinement of each agent to its declared tools, and an access log shown complete, not just tamper-evident.

Example methods

Remote attestation of CPU and GPU enclaves (TDX, SEV-SNP, confidential GPUs) against reproducible builds and the loaded model's hash; information-flow control and capability confinement of agents; an attested reference monitor at every access, writing a hash-linked log; zero-knowledge (zkML, zkVM) or sampled proofs of inference and policy checks, bound to the attested model, checked on the person's device.

03 Aggregation

A privacy bound for each person who contributes to a model or statistic, stated before they join and updated as training runs, tested by attacks aimed at their record, plus removal on withdrawal the person can verify.

Example methods

Per-person and user-level differential-privacy accounting (privacy filters and odometers, Rényi DP); secure aggregation with distributed DP and verifiable noise; membership, extraction and reconstruction audits per person (LiRA, one-run auditing); exact unlearning by sharded retraining, checked against a dishonest operator.

04 Sharing

A measure, kept by the person, of what a twin's answers and exports reveal about them, free text included (paraphrases, derived figures), relative to what each recipient already knows, added up over every release.

Example methods

Quantitative information flow (Bayes vulnerability, g-leakage, pointwise maximal leakage); claim extraction from free text and derived figures; Pufferfish privacy with composition; privacy odometers and continual-release accounting; attribute-inference audits with LLM adversaries; zero-knowledge selective disclosure.

Not funded on its own: encryption or secure computation presented as a privacy guarantee, new foundation models, infrastructure without a research question.

Open proofs with Theoria

You can use AI to develop your proposal. We use it too, to help assess the research behind it.

Theoria uses AI and internet research to investigate your main research question, the only field taken from your application. Its open proofs record sources, prompts, responses and tool activity: an evidence trail you and reviewers can inspect to check the reasoning, identify gaps and challenge findings.

We run and pay for the official investigation. Its report and evidence stay private to you and authorised reviewers and staff. You can respond before the final funding decision, by the deadline supplied with the report. The report is advisory; it cannot reject your application on its own. People decide on funding.

AI use and reviewer responsibilities · Privacy notice · Theoria preprint (opens in a new tab)

Optional practice

Try it on your question

Optionally investigate your question on Standard Proofs with your own API key. Inspect prompts, responses and sources. Practice does not affect selection. It does not automatically transfer your application or return results to the foundation. This separate service’s terms and API-key authorisation apply.

Try Theoria

Selection and dates

An independent panel of three to five experts decides, informed by eligibility checks, an artefact re-run, a claim check and fellow-applicant review. Names and direct identifiers are removed for peer review. Everyone receives written feedback. A lottery with published rules and draws decides among equally qualified applications.

Criteria: novelty, a deciding experiment, openness, relevance to health twins

Decisions are planned for 15 January 2027. Projects start on 1 February 2027.

Call rules

Eligibility and funding

Who can apply: Researchers worldwide, independent or at universities, research institutes and non-profits. Apply individually or as a small team with one accountable lead. One proposal per lead; one application per person per call; no double funding. The Swiss Code of Conduct for Scientific Integrity or equivalent applies.
The grant: Up to CHF 20'000 per application for 6, 9 or 12 months, covering personnel, compute and data access. Instalments follow code re-runs. Initial total cap: CHF 200'000; co-funders welcome.
Open science conditions: Code must be public from the first commit, with a working demo; papers and data openly licensed. See Open source requirement below. Patient data require the applicable legal basis, permissions, ethics approvals and appropriate safeguards. Prefer synthetic data: twin-llm.

Open source requirement

Open from the first commit: Funded research outputs stay open from the first commit so anyone can read and re-run them.
Licences: Eligibility requires these licences: code, OSI-approved (e.g. Apache-2.0, MIT, GPL-3.0, AGPL-3.0 or EUPL-1.2); papers and project reports, CC BY 4.0 or CC BY-SA 4.0; data and benchmarks, CC0 1.0 or CC BY 4.0. Released fine-tuned or audit models include weights, code and training-data information under the OSI Open Source AI Definition. Every file needs an SPDX licence tag.
Not accepted, and ownership: No non-commercial, field-of-use, responsible-AI or source-available terms, or closed components needed to check a claim. You retain your rights and must obtain necessary institutional or third-party release permissions. Anyone may use, study, change and share funded work, including commercially. Before work begins, the grant agreement must identify funded results covered by royalty-free patent licensing and necessary background rights.
In the open: Link an existing open-source artefact. Funded work uses a public repository; we re-run its code before each instalment. Publish preprints by journal submission and papers openly without embargo on publication. The final project report is public.
Re-runnable and lasting: One documented command rebuilds the main results on public or synthetic data, with pinned dependencies and no paid licence. Released binaries and enclave images build reproducibly. Archive every release with a DOI (e.g. Zenodo) and Software Heritage.
Exceptions: Do not publish personal research data. Models trained on them require a documented assessment of privacy risks, applicable legal basis and third-party rights before release; a technical privacy guarantee alone is insufficient. Agree any delay of exploit details with the foundation in a coordinated-disclosure plan.

AI use and reviewer responsibilities

AI is welcome: LLMs and other AI tools are welcome in your application and research, including literature search, code, analysis and writing. Disclose tools and purposes. The named lead remains responsible for every claim; AI-made code, text and data follow the same open-source rules. The Call Terms govern reviewer use of other applicants’ material.
Theoria services: The foundation runs and pays for the official Theoria investigation using OpenAI models through its own account. Optional practice on Standard Proofs requires your own OpenAI API key. The privacy notice explains provider data handling.
AI-assisted peer review: Reviewers may use foundation-approved Anthropic API tools for background research, technical checks and language editing. They write substantive evaluations themselves and verify AI output. Tools must not score or rank applications or recommend funding. Feedback discloses substantive use; applicants may respond to material AI-assisted findings before the final decision. Never enter application or review material into unapproved AI services.