GeneGuardian Data governance & consent
Case study · Data governance · CSIRO Digital OneHealth
Genomic data outlives the moment someone signs a form. With broad consent, participants cannot see or change how their data is used afterwards. GeneGuardian is a dynamic consent and data governance platform built at CSIRO. I co-led its design and deployment with a colleague, led the cross-functional team that built it, and owned the data side. It is live at geneguardian.online and running at a pilot hospital, at one site for now.
For the specialist Dynamic consent on HL7 FHIR, with self-sovereign identity and verifiable credentials. Blockchain-anchored consent records and decentralised storage (IPFS, FileCoin, StorJ) were developed, researched and written up in the paper; post-quantum cryptography is part of the reference design. Development and test environments were deployed with Terraform on AWS.
The problem
Our review estimated that more than 60 million people would have their genome sequenced in healthcare by 2025. Consent tooling has not kept pace: a signed form cannot record a participant changing their mind, and a genome cannot be re-issued if it leaks. Trust has to be built into the infrastructure, not added as a policy document.
Three consent models, and where each one breaks
The reference design: who holds, issues and verifies consent
The design
My co-lead and I wrote the paper together and designed the architecture together. I focused on the data side: where the data is stored, FHIR, cloud versus on-premises, and whether to centralise or decentralise, including the choice between IPFS and the alternatives. I led the 10+ cross-functional team (IT, medical informatics, bioinformatics) under Scrum and supervised the students.
Step 01
Consent is a live setting the participant owns, not a document the institution files. Every other decision follows from the review’s principle that the individual’s right to self-determination sits at the centre.
Step 02
Cloud, on-premises or hybrid: each trades control against cost and scalability, and sovereignty concerns differ for each. I owned this decision area and set out the options in the review.
Step 03
A consent platform that cannot exchange data with clinical systems stays a demo. HL7 FHIR gives consent records and participant data a standard shape that hospitals and researchers already understand.
Step 04
I recommended it, developed it and researched it, and it is written up in the paper: every grant, change or withdrawal becomes an entry nobody can quietly rewrite. It was also the hardest recommendation to land, because it was the least familiar to the non-technical people who had to approve it (see below). The review notes that blockchain tools are often hard to use and hard to make interoperable, so the interface has to hide them.
Step 05
I developed and compared IPFS, FileCoin and StorJ against centralised options. They improve resilience but depend on the underlying networks and their economics, and the trade-offs are documented in the review. Development and test environments ran on AWS, deployed with Terraform, like most CSIRO projects.
Step 06
Genomic data stays sensitive for a lifetime, so the reference design includes post-quantum cryptography. It belongs to the reference design and is not part of the deployed pilot. The review is explicit that post-quantum methods are still hard to scale to large datasets.
Two things took more effort than any component. First, explaining to non-technical stakeholders why the best solution was one they instinctively distrusted: blockchain was unfamiliar to them, and unfamiliar sounds risky. Second, keeping a large group of collaborators (clinicians, informatics, IT, students) at the same level of understanding, so that decisions were made on shared ground rather than on whoever spoke last. Neither problem shows up in the architecture diagram, and both decided what shipped.
Evidence and limits
The first-author GigaScience paper (DOI 10.1093/gigascience/giae021) surveys storage, encryption, consent models and privacy-preserving techniques. It is the research foundation for the platform, not a user study of it.
GeneGuardian runs at a pilot hospital, at a single site so far. Participant numbers and outcomes are confidential to the hospital, so this page states none. Wider adoption would change that.
The blockchain and decentralised storage layers were developed, researched and written up, and post-quantum cryptography is design-only. The pilot runs a simpler configuration, so the figure above shows the reference design, not the exact production system.
K-anonymity is vulnerable to background-knowledge attacks, differential privacy reduces data utility, federated learning has coordination and backdoor risks, and synthetic genomes do not guarantee privacy. Choosing a stack means choosing which trade-off to live with.
The platform was designed for HIPAA, GDPR and GA4GH alignment. Alignment in design is not a formal certification or a legal opinion for a specific deployment.
Sources
Start with a diagnostic of your consent, storage and access model, then build the smallest secure path to production.