Privacy & Security
Multi-layered security architecture protecting patient data through advanced anonymization, blockchain verification, and patient-controlled access.
Multi-Layered Security Architecture
Layer 1: Double Anonymization
Two-stage anonymization process removes all PII and generalizes data at multiple levels.
Layer 2: K-Anonymity
Ensures minimum 5 records per demographic group, preventing re-identification.
Layer 3: Patient Control
Patients control all data sharing through opt-in/opt-out and researcher approvals.
Layer 4: Hedera Blockchain
Immutable consent records and data provenance hashes on Hedera Consensus Service.
Layer 5: Encrypted Storage
All data stored in encrypted FHIR format with secure database access controls.
Layer 6: Access Control
API key authentication, rate limiting, and role-based access controls.
Before vs. After Anonymization
| Before (Raw) | After (Anonymized) |
|---|---|
| ❌ Name: "John Doe" | ✅ Anonymous ID: "PID-001" |
| ❌ ID: "P-12345" | ✅ Removed |
| ❌ Address: "123 Main St" | ✅ Country Only: "Uganda" |
| ❌ Phone: "+256-123-4567" | ✅ Removed |
| ❌ DOB: "1990-01-15" | ✅ Age Range: "35-39" |
| ✅ Medical Data | ✅ Medical Data: Preserved |
| ✅ Demographics | ✅ Demographics: Preserved |
K-Anonymity Protection
What is K-Anonymity?
K-anonymity is a privacy model that ensures each record in a dataset cannot be distinguished from at least K-1 other records. MediPact enforces K=5, meaning each record must be part of a group with at least 5 records sharing the same demographic characteristics.
Minimum 5 Records
Each demographic group must contain at least 5 records to prevent re-identification.
Grouping Criteria
Groups are formed by: Country, Age Range, Gender, Occupation
Record Suppression
Records with fewer than 5 matches are suppressed from the dataset.
Privacy Guarantee
Even with external knowledge, an attacker cannot identify individuals with confidence.
Privacy Guarantees
No PII on Blockchain
Only anonymous IDs and hashes are stored on Hedera. No personally identifiable information is ever written to the blockchain.
No Original Patient IDs
ConsentManager stores only anonymous IDs. The mapping between original patient IDs and anonymous IDs is stored securely in the backend database, never on-chain.
Double Anonymization
Stage 1 (Storage): 5-year age ranges, exact dates, region/district preserved for research queries.Stage 2 (Chain): 10-year age ranges, month/year dates, region/district removed for maximum blockchain privacy. Both hashes stored with provenance proof for verifiable transformation.
Provenance Tracking
Both storage and chain hashes are stored together on Hedera with a provenance proof, allowing anyone to verify that the chain hash was derived from the storage hash. This provides complete audit trail and transformation verification.
K-Anonymity Enforced
Privacy protection through demographic grouping ensures each record is indistinguishable from at least 4 others in the same group.
Consent Validation
Database-level and smart contract-level enforcement ensures only consented data is accessible. Researchers cannot query or purchase data without valid consent records.
Double Anonymization Process
Two-Stage Protection
MediPact implements double anonymization with provenance tracking for maximum privacy protection:
- Stage 1 (Storage): Optimized for research queries - 5-year age ranges, exact dates
- Stage 2 (Chain): Maximum privacy for blockchain - 10-year age ranges, month/year dates
- Provenance Tracking: Both hashes stored on Hedera with transformation proof
End-to-End Encryption
Field-Level Encryption
MediPact uses AES-256-GCM encryption for sensitive patient and medical data fields. Each field is encrypted individually, allowing granular access control.
- Algorithm: AES-256-GCM (Galois/Counter Mode)
- Key Derivation: Hospital-specific and patient-specific keys
- Encrypted Fields: UPI, contact info, national ID, addresses, DOB, patient names, medical notes
- Zero-Knowledge: Platform cannot decrypt patient data
Zero-Knowledge Architecture
The platform operates on a zero-knowledge model where encrypted data is returned to the platform, but only hospitals and patients can decrypt their own data.
Hospital Access
Only the hospital that collected the data can decrypt it using their hospital-specific key.
Patient Access
Patients can decrypt their own data using their patient-specific key derived from their UPI.
Re-Encryption for Temporary Access
When a hospital requests temporary access to a patient's data from another hospital, the data is re-encrypted with the requesting hospital's key upon patient approval. This enables secure telemedicine while maintaining zero-knowledge architecture.
Security Measures
Password & API Key Security
- Bcrypt Hashing: All passwords and API keys hashed with bcrypt (12 rounds for passwords, 10 for API keys)
- Timing Attack Protection: Secure comparison functions prevent timing-based attacks
- Backward Compatibility: Legacy SHA-256 hashes supported during migration
Rate Limiting
- General API: 100 requests per 15 minutes per IP
- Authentication: 5 attempts per 15 minutes per IP
- API Key: 1000 requests per hour per key
- Query: 50 queries per hour per researcher
- Purchase: 10 purchases per hour per researcher
Access Control
- Role-based access control (Patient, Hospital, Researcher, Admin)
- API endpoints protected by role verification
- Consent validation at database and smart contract levels
- Patient preferences filter all queries
- Platform access restrictions for zero-knowledge compliance
Audit Trail
- All consent records stored immutably on Hedera HCS
- Data proof hashes verifiable on HashScan
- Revenue distribution transactions publicly auditable
- Data access history tracked for patients
- Temporary access requests logged with timestamps
Compliance
MediPact's privacy and anonymization techniques are designed to comply with healthcare data protection regulations including GDPR, HIPAA (where applicable), and other regional data protection laws. The K-anonymity model and PII removal ensure that datasets cannot be used to re-identify individuals.