Patient Consent and Erasure in an EU Health Data Exchange
An EU health-data exchange connecting 6 hospitals and 2.3 million patients uses Hyperledger Fabric. Consent is recorded on-chain as a token containing patient_id_hash, scope, expiry, and granting hospital. Clinical documents stay in hospital object stores; their SHA-256 hashes are on-chain. A patient requests erasure under GDPR, including consent history. One hospital wants the full national patient ID on-chain for audit; another proposes a zero-knowledge proof that a consent token exists without revealing the patient. The consortium's legal counsel warns that hashed IDs may still be personal data and that immutable ledgers conflict with erasure. A vendor offers a 'right-to-be-forgotten' chaincode that deletes keys from world state but not blocks. The exchange has 90 days to answer the regulator and 12 pending erasure requests.
1. Assess the vendor's 'delete keys from world state' chaincode as a GDPR erasure solution.
Read the worked answer
Reject it as a complete erasure solution. Deleting current state does not delete historic blocks, and the chaincode may leave indexes, private data, or hashes. If patient_id_hash is derived from a national ID and the mapping exists in a hospital, it remains pseudonymous personal data. Erasure requires that the data no longer be available, not just hidden from current-state queries.
Crypto-shredding can help if the on-chain value is encrypted and the key is destroyed, but the on-chain ciphertext/hash may still be personal data if it can be linked. The consortium needs a data protection impact assessment and legal sign-off, not a chaincode feature.
2. Propose a privacy-preserving design for consent, audit, and erasure.
Read the worked answer
Design data minimization:
- Do not put the national patient ID or a deterministic hash of it on-chain. Use a random subject pseudonym per consent, with the mapping held in a permissioned off-chain registry controlled by the hospital/DPO.
- Store consent scope, expiry, granting organization, and status on-chain; store the consent document and patient identifiers off-chain.
- For clinical documents, store a salted hash only if needed; keep the salt off-chain and delete it on erasure (crypto-shredding). Better: anchor a batch Merkle root, not individual document hashes, to reduce linkability.
- Use zero-knowledge proofs for 'valid consent exists' and 'scope matches' so verifiers do not need patient identity. Revocation is a new on-chain event; deletion is off-chain plus key destruction.
- Keep audit metadata non-personal (txid, timestamp, organization).
3. What governance controls should the consortium put in place for data-subject erasure requests?
Read the worked answer
Governance:
- A data protection officer per hospital and a consortium DPO with authority to suspend processing.
- A documented erasure workflow: identity verification, legal basis, scope, legal-hold check, off-chain deletion, key destruction, on-chain revocation event, and response within GDPR deadlines.
- A register of on-chain personal data and a DPIA; minimize new fields via change control.
- Contracts: joint controller/processor roles, data-sharing agreements, breach notification, and audit rights.
- Technical controls: role-based access, private data collections, HSM-backed keys, and monitoring for unauthorized queries.
For the 12 pending requests, triage by legal hold and respond with a consistent method; do not promise block deletion.