Skip to content
Bennyhinn.
← All work
Blockchain2025

DPDP-Compliant Redactable Blockchain Healthcare System

Blockchains are designed to be unchangeable. Data-protection law requires that personal data can be corrected and erased. This system resolves that contradiction.

Stack

  • Flask 3
  • Python 3.11
  • React 18
  • TypeScript
  • MongoDB 7
  • Ethereum (Ganache)
  • Web3.py
  • AES-256-GCM
  • Chameleon Hashing
  • JWT / bcrypt
  • Docker Compose
DPDP Health DPO Command Center dashboard showing a 100 out of 100 DPDP compliance score, counts for total patients, health records, active consents, blockchain anchors, audit events, and registered users, plus a rights-requests panel for corrections, erasures, and redacted records.

Problem

India's Digital Personal Data Protection Act (2023) grants individuals the right to correct and erase their personal data. Traditional blockchains guarantee the opposite: once written, records cannot change. A healthcare system that anchors records on-chain for integrity therefore appears fundamentally incompatible with DPDP compliance.

The core question: can you keep verifiable, tamper-evident records and still honour a legal right to erasure?

Approach

The system uses a Chameleon Hash Function to enable authorized redaction. A chameleon hash lets a holder of a secret trapdoor find a controlled hash collision — meaning an authorized party can rewrite specific data while the chain's hash links remain valid. Unauthorized modification remains computationally infeasible.

This is paired with a dual integrity model: a hash-chained audit trail plus blockchain anchoring on Ethereum (Ganache), so every correction and erasure leaves a verifiable proof.

Integrity model
hash-chained audit log  →  SHA-256 links
on-chain anchor         →  Ganache (Ethereum) via Web3.py
authorized redaction    →  Chameleon Hash trapdoor

Architecture

A React + TypeScript frontend talks to a Flask API behind a gateway layer that enforces rate limiting, JWT validation, and role-based access control. Nine backend services separate concerns: auth, patients, consent, doctors, audit, encryption, blockchain, chameleon hash, and compliance.

Personally identifiable data is encrypted field-level with AES-256 (Fernet) before it reaches MongoDB. Doctor access to records is consent-gated — role permissions alone are not enough; an active, purpose-limited patient consent must exist.

Implementation

The API exposes DPDP-mapped endpoints: consent grant/withdraw, record correction, record erasure, integrity verification, audit timeline, and a live compliance score. Corrections and erasures run through the chameleon hash workflow so the on-chain anchor stays consistent.

The build includes 80+ automated tests covering auth, encryption, blockchain, consent, audit, and the chameleon hash integration, plus Swagger/OpenAPI documentation. Design documentation lives in the repository's spec folder.

DPDP Act mapping

Each feature maps to a specific DPDP obligation: consent management (Sec 5-6), right to access (Sec 11), right to correction and erasure (Sec 12), security safeguards (Sec 8(4)), and breach-notification support via a severity-tagged audit trail (Sec 8(6)). The compliance service surfaces a real-time score so the mapping is observable, not just claimed.

Interface

DPDP Health Identity Governance and User Intelligence screen with user role counts, a role distribution chart, platform activity metrics for records, consents, anchors, corrections, and erasures, and an identity risk assessment section.
DPDP Health user profile page showing identity details and a security status panel listing JWT (HS256) authentication, AES-256 encryption, India data residency, and MFA status.
DPDP Healthcare Platform sign-in screen labelled secure, consent-driven health data management, with a note that the platform is DPDP Act compliant with data residency in India.

Limitations

  • Blockchain runs on Ganache (local Ethereum) — a development chain, not a production network.
  • Chameleon Hash redaction is implemented as a working demonstration of the mechanism, intended for evaluation rather than clinical deployment.
  • Demo data and seed accounts ship with the repo for evaluation and are not real records.

Future work

  • Migrate the anchor from Ganache to a permissioned production chain.
  • Formal threat modelling of the trapdoor key custody.
  • Independent security review of the redaction workflow.