# HealthGuard White Paper

**Version :** 0.1 (MVP/POC)
**Date :** 20/12/2025
**Auteur :** Sébastien (Seb)
**Statut :** Draft public – itératif

---

## 1. Résumé exécutif

Les documents médicaux circulent encore trop souvent via des canaux fragiles (mails, papier, clés USB, portails hétérogènes), ce qui crée un cocktail tristement classique : perte de documents, fuites potentielles, frictions administratives, redondances d'examens, et charge mentale pour les patients comme pour les soignants.

**HealthGuard** propose un wallet santé orienté MVP : une dApp permettant à un patient de téléverser, chiffrer, conserver et partager ses documents médicaux sous forme de NFT, avec un contrôle d'accès granulaire. Le patient reste le point de contrôle logique du partage, et l'application vise à réduire l'exposition des données en limitant au maximum ce qui transite et ce qui est stocké en clair.

> **Note importante :** HealthGuard ne prétend pas "remplacer" les SI hospitaliers. Le MVP vise un usage très concret : pré-admission, pré-consultation, partage patient → pro, et réduction des frictions.

---

## 2. Problème : la santé numérique version "papier + mail + stress"

### 2.1 Fragmentation et friction

- Portails patients multiples, incompatibilités, et identifiants perdus
- Documents éparpillés (papier, PDF, messageries)
- Redemandes fréquentes à l'arrivée (carte mutuelle, ID, examens, CR)

### 2.2 Confidentialité et traçabilité imparfaites

- Transfert par email ou pièces jointes : surface d'attaque énorme
- Partage non traçable finement (qui a vu quoi, quand, pourquoi)
- Difficile de limiter le partage à "uniquement tel document pendant 7 jours"

### 2.3 Coût humain

- Le patient devient "transporteur de données"
- Le soignant perd du temps à récupérer ce qui devrait être déjà là

---

## 3. Vision : remettre le patient au centre sans punir le soignant

HealthGuard vise un modèle simple :

- Le patient **conserve** ses documents dans un wallet
- Le document est **chiffré avant stockage** (zéro confiance côté stockage)
- Le partage est **volontaire et ciblé** : durée, catégorie, contexte
- Le professionnel accède avec une **expérience fluide** (MVP d'abord, intégrations SI ensuite)

---

## 4. Solution : documents médicaux "tokenisés" et chiffrés

### 4.1 NFT de document médical (preuve + index + contrôle d'accès)

Chaque document devient un **NFT ERC-721** qui transporte :

- Un identifiant unique
- Des métadonnées minimales (type, date, émetteur si besoin)
- Une référence chiffrée vers le contenu (CID IPFS chiffré)
- Des règles d'accès (via contrat d'accès / gestionnaire)

#### Pourquoi NFT ?

Parce que ça fournit un objet standard :

- **Indexable** : facile à retrouver et organiser
- **Traçable** : événements on-chain (création, partage, révocation)
- **Partageable** : via droits explicites et contrôle d'accès
- **Interopérable** : compatible avec l'écosystème blockchain

### 4.2 Stockage : off-chain, chiffré, et "chain = registre"

- Le contenu (PDF/image) est stocké **off-chain** sur **IPFS via Pinata**
- La blockchain conserve : **preuves, index, événements, règles d'accès**
- Aucune donnée médicale sensible n'est stockée en clair

---

## 5. Architecture MVP (vue d'ensemble)

### 5.1 Composants

| Composant | Technologie | Rôle |
|-----------|-------------|------|
| **Frontend** | Next.js 14 + React 18 + TypeScript | UI patient/pro, upload, consultation, partage |
| **Smart Contracts** | Solidity 0.8.26 + Hardhat 2.23.0 | Registry types, NFT documents, access manager, encryption keys |
| **Blockchain** | Ethereum Sepolia (testnet) | Layer 1 principal avec support multi-chain |
| **Account Abstraction** | ERC-4337 via Alchemy Account Kit | Gasless transactions, social login, passkeys |
| **Stockage chiffré** | IPFS via Pinata | Stockage décentralisé des fichiers chiffrés |
| **Cryptographie** | Web Crypto API, @noble/hashes, TweetNaCl | AES-256-GCM, X25519, HKDF-SHA256 |
| **Authentication** | Clerk + Passkeys | Social login et hardware wallets |

### 5.2 Smart Contracts déployés (11+)

#### Contrats principaux :

1. **CategoryKeyRegistryV1** (`0x2e66f21CFA564a045C3a02468493FF4235400Aa8`)
   - Stocke les clés de catégorie chiffrées (6 par utilisateur)
   - Chiffrement hiérarchique Level 2
   - Rotation de clés sans re-chiffrement des fichiers

2. **EncryptionKeyRegistryV2** (`0xbB13777d11006677A688A6EC7daa410440338241`)
   - Stocke les clés publiques X25519 des patients
   - Permet le partage asymétrique Pro → Patient

3. **ProEncryptionKeyRegistryV2** (`0x5a7f3B4b1c002AC2e87604077eA2aAF1672d3aC7`)
   - Stocke les clés publiques X25519 des professionnels
   - Structure similaire au registre patient

4. **MedicalDocumentNFTV1** (`0x827a691D589800Ca6f2bC521662710184ec1332d`)
   - NFT ERC-721 pour les documents médicaux
   - Métadonnées chiffrées (CID IPFS, clés wrappées, hash fichier)
   - Support du partage via enveloppes chiffrées

5. **HGPatientNFTV1** (`0xfDE21a27E7243764f62F9e4C955ef11aAbA657a8`)
   - NFT ERC-721 représentant l'identité patient
   - Vérification d'identité on-chain

6. **HGProNFTV1** (`0x8E3a34C55aa371303f7fBeC57609f7b1eE0d7296`)
   - NFT ERC-721 représentant l'identité professionnelle
   - Stocke le numéro RPPS et la spécialisation

7. **HealthDataAccessManagerV4** (`0x94379F15C4c912DB5FB45b15f3Aafd00CE572a88`)
   - Gère les accès temporaires via QR codes
   - Niveaux d'accès : Read (1), Write (2)
   - Durée configurable : 5 min à 24h+
   - Mode accès d'urgence

8. **DocumentTypeRegistry** (`0x07D66f3872cdA04187320A200919Cd5fFddC7e7a`)
   - Métadonnées pour les 6 catégories de documents

9. **PatientDataV1** (`0xFA9956f506E5478556fd26460D0F2Bd1cc6380E5`)
   - Stockage des données de profil patient

### 5.3 Catégories de documents (6 types)

| ID | Type | Description |
|----|------|-------------|
| 0 | Prescription | Ordonnances médicales |
| 1 | Examination Report | Comptes-rendus de consultation |
| 2 | Biology Results | Résultats biologiques |
| 3 | Imaging | Imagerie médicale (radio, scanner, IRM) |
| 4 | Certificate | Certificats médicaux |
| 5 | Other | Autres documents |

### 5.4 Flux "Upload patient"

```mermaid
sequenceDiagram
    Patient->>Frontend: Sélectionne document
    Frontend->>Crypto: Génère clé document (AES-256)
    Crypto->>Crypto: Chiffre fichier (AES-GCM)
    Frontend->>IPFS: Upload fichier chiffré
    IPFS-->>Frontend: Retourne CID
    Frontend->>Crypto: Chiffre CID + wrapping clé
    Frontend->>Smart Contract: Mint NFT document
    Smart Contract-->>Frontend: TokenID + événement
```

**Étapes détaillées :**

1. Patient sélectionne un document (mobile/desktop)
2. Génération d'une clé de document aléatoire (AES-256)
3. Chiffrement du fichier côté client (AES-256-GCM)
4. Upload du contenu chiffré vers IPFS (Pinata)
5. Récupération du CID (Content Identifier)
6. Chiffrement du CID avec la clé de catégorie
7. Wrapping de la clé de document avec la clé de catégorie
8. Mint du NFT avec métadonnées chiffrées
9. Stockage du hash SHA-256 pour intégrité

### 5.5 Flux "Consultation pro"

```mermaid
sequenceDiagram
    Pro->>Patient: Présente QR code
    Patient->>Frontend: Scanne QR code
    Patient->>Smart Contract: Accorde accès temporaire
    Pro->>Smart Contract: Vérifie accès
    Smart Contract-->>Pro: Retourne clé chiffrée
    Pro->>Crypto: Déchiffre avec X25519 privée
    Pro->>IPFS: Télécharge fichier chiffré
    Pro->>Crypto: Déchiffre fichier
    Pro->>Frontend: Affiche document
```

**Étapes détaillées :**

1. Le pro génère un QR code (ou demande l'accès)
2. Patient scanne et valide la demande
3. Smart contract enregistre l'accès (durée, niveau)
4. Chiffrement de la clé de document pour le pro (X25519)
5. Pro déchiffre la clé via son wallet/X25519 privée
6. Pro récupère le CID, télécharge le contenu chiffré
7. Pro déchiffre localement avec la clé de document
8. Traçabilité : événement on-chain + journal applicatif

---

## 6. Modèle cryptographique (MVP pragmatique, sécurité sérieuse)

### 6.1 Principes

- **Chiffrement symétrique** des contenus (performant)
- **Chiffrement asymétrique** des clés de document (partage ciblé)
- **Architecture zéro-knowledge** : aucune clé stockée en clair
- **Une clé = un usage** (éviter les mélanges dangereux)
- **Minimiser le on-chain en clair** (métadonnées minimales)

Ces principes s'alignent avec les recommandations ANSSI de sélection d'algorithmes et de mécanismes cryptographiques.

### 6.2 Architecture hiérarchique à 3 niveaux

#### **Level 1 : Master Key (Jamais stockée)**

```
Dérivation : Signature wallet "HEALTHGUARD_MASTER_KEY_V1"
           → HKDF-SHA256
           → Clé AES-256 Master Key (32 bytes)

Objectif   : Chiffrer les Category Keys
Durée      : Session uniquement (re-générée à chaque login)
Stockage   : JAMAIS (recalculée à la demande)
```

**Propriétés :**
- Déterministe : même wallet = même master key
- Éphémère : existe uniquement en mémoire
- Zéro-knowledge : impossible à extraire de la blockchain

#### **Level 2 : Category Keys (Chiffrées on-chain)**

```
Génération : 6 clés aléatoires AES-256-GCM (une par type de document)
Chiffrement: Chiffrées avec Master Key avant stockage
Stockage   : CategoryKeyRegistryV1 (smart contract)
Format     : { ciphertext (base64), iv (base64), version }

Objectif   : Chiffrer/déchiffrer les Document Keys
Rotation   : Possible sans re-chiffrer les fichiers
```

**Avantages :**
- **Isolation par catégorie** : compromission d'une clé ≠ tous les documents
- **Rotation facile** : nouvelle clé de catégorie sans toucher aux fichiers
- **Granularité du partage** : partage par type de document

#### **Level 3 : Document Keys (Unique par fichier)**

```
Génération : Clé aléatoire AES-256 (32 bytes) par document
Wrapping   : Chiffrée avec Category Key avant stockage
Stockage   : Métadonnées NFT + IPFS
Format     : { wrappedKey (base64), iv (base64) }

Objectif   : Chiffrer le fichier médical réel
Extraction : Requiert Master Key → Category Key → Document Key
```

**Propriétés :**
- **Unique** : chaque fichier a sa propre clé
- **Isolé** : compromission d'un document ≠ autres documents
- **Partage sécurisé** : clé wrappée avec X25519 pour les pros

### 6.3 Chiffrement des contenus

**Algorithme :** AES-256-GCM (NIST SP 800-38D)

```javascript
// Pseudo-code simplifié
const documentKey = generateRandomKey(32); // 256 bits
const iv = generateRandomIV(12); // 96 bits (GCM standard)
const encryptedFile = AES_GCM_encrypt(file, documentKey, iv);
const authTag = encryptedFile.authTag; // Authentification intégrée
```

**Caractéristiques :**
- **Mode GCM** : chiffrement authentifié (AEAD)
- **IV aléatoire** : généré pour chaque opération
- **Tag d'authentification** : détecte les modifications
- **Performance** : hardware-accelerated (AES-NI)

### 6.4 Chiffrement de la référence de stockage (CID)

Le CID IPFS est également chiffré avant inscription on-chain :

```javascript
const encryptedCID = AES_GCM_encrypt(ipfsCID, categoryKey, iv);
contract.storeEncryptedCID(encryptedCID, iv);
```

**Raison :** Éviter de révéler un identifiant exploitable de stockage.

### 6.5 Partage de clé (X25519 Curve25519)

**Algorithme :** X25519 + XSalsa20-Poly1305 (TweetNaCl)

#### Génération de paires de clés :

```
Dérivation : Signature wallet "HEALTHGUARD_X25519_KEYPAIR_V1"
           → HKDF-SHA256 → Seed 32 bytes
           → nacl.box.keyPair.fromSecretKey()

Clé publique  : Stockée on-chain (EncryptionKeyRegistryV2)
Clé privée    : JAMAIS stockée (re-dérivée à chaque session)
```

#### Protocole de partage Pro → Patient :

```mermaid
sequenceDiagram
    Pro->>Smart Contract: Récupère clé publique X25519 du patient
    Pro->>Crypto: Dérive sa clé privée X25519
    Pro->>Crypto: Chiffre clé de document (nacl.box)
    Pro->>Smart Contract: Stocke enveloppe chiffrée
    Patient->>Smart Contract: Récupère enveloppe
    Patient->>Crypto: Dérive sa clé privée X25519
    Patient->>Crypto: Déchiffre enveloppe (nacl.box.open)
    Patient->>IPFS: Télécharge + déchiffre fichier
```

**Propriétés cryptographiques :**
- **Perfect Forward Secrecy** : compromission future ≠ déchiffrement passé
- **Authenticated Encryption** : Poly1305 MAC intégré
- **Nonce aléatoire** : évite les attaques par rejeu
- **ECDH** : échange de clés Diffie-Hellman sur Curve25519

### 6.6 Intégrité et audit

- **Hash SHA-256** : calculé avant chiffrement, stocké on-chain
- **Événements blockchain** : création, partage, révocation (immuables)
- **Vérification d'intégrité** : comparaison du hash après déchiffrement

---

## 7. Contrôle d'accès

### 7.1 Objectif MVP

Permettre :

- **Accès par patient** : propriétaire des NFT documents
- **Accès par professionnel** : via QR code ou demande
- **Accès par catégorie** : partage sélectif (ex : uniquement imagerie)
- **Accès temporaire** : durée limitée configurable
- **Révocation** : instantanée ou automatique à expiration

### 7.2 Mécanisme de QR Code

**Flux :**

1. Patient génère un QR code depuis l'app
2. QR code contient : adresse du pro, durée, niveau d'accès, catégories
3. Patient scanne le QR code du professionnel
4. Transaction on-chain : `grantAccess(proAddress, duration, level, categories)`
5. Professionnel vérifie son accès : `verifyAccess(patientAddress)`
6. Récupération des clés chiffrées si accès valide

**Niveaux d'accès :**
- **Read (1)** : consultation uniquement
- **Write (2)** : création de documents pour le patient

**Durées configurables :**
- 5 minutes (consultation rapide)
- 1 heure (consultation standard)
- 24 heures (accès d'urgence)
- Custom (configurable)

### 7.3 Mode accès d'urgence

En cas d'urgence médicale :

- **Accès automatique 24h** : lecture seule
- **Traçabilité renforcée** : événement "emergency access" on-chain
- **Notification patient** : alerte post-accès
- **Révocation possible** : patient peut révoquer même en urgence

### 7.4 Traçabilité

**Événements on-chain :**
- `DocumentCreated(tokenId, owner, category, timestamp)`
- `AccessGranted(patient, professional, duration, level, timestamp)`
- `AccessRevoked(patient, professional, timestamp)`
- `KeyRotated(owner, category, timestamp)`

**Journal applicatif :**
- Emails de notification (accès accordé/révoqué)
- Logs d'audit (qui a consulté quoi, quand)
- Historique de partage (interface patient)

---

## 8. Identité et onboarding (orientation MVP)

### 8.1 Patients

**Onboarding simplifié via Account Abstraction :**

- **Email** : création de wallet via email (Alchemy Account Kit)
- **Google** : social login sans clé privée à gérer
- **Passkeys** : authentification biométrique (Face ID, Touch ID)
- **Hardware wallets** : support optionnel pour utilisateurs avancés

**Expérience utilisateur :**
- Aucun ETH requis (gasless transactions via paymaster)
- Pas de gestion de seed phrase (abstraction)
- Récupération de compte via email/social

### 8.2 Professionnels

**MVP pragmatique :**

- **Connexion initiale** : compte applicatif + wallet
- **Vérification d'identité** : numéro RPPS (Répertoire Partagé des Professionnels de Santé)
- **NFT professionnel** : mint après vérification
- **Métadonnées** : spécialisation, établissement (optionnel)

**Roadmap :**
- Migration vers DID (Decentralized Identifier)
- Intégration carte CPS (Carte de Professionnel de Santé)
- Vérification automatique RPPS via API

### 8.3 Flux QR code pro

**Génération QR :**

```javascript
const qrData = {
  proAddress: "0x...",
  timestamp: Date.now(),
  signature: signWithWallet(proAddress + timestamp)
};
const qrCode = generateQR(JSON.stringify(qrData));
```

**Scan patient :**

1. Patient scanne le QR du professionnel
2. Vérification de la signature
3. Affichage : identité du pro (RPPS, nom, spé)
4. Patient sélectionne : durée, catégories, niveau d'accès
5. Validation → transaction on-chain

---

## 9. Sécurité applicative (Next.js / Frontend)

Le MVP applique des contrôles standards Next.js :

### 9.1 Protection des routes

- **Middleware** : vérification de l'authentification
- **Route guards** : redirection si non connecté
- **Role-based access** : patient vs professionnel

### 9.2 Validation des données

- **Validation côté client** : types TypeScript stricts
- **Validation fichiers** : taille max, types MIME
- **Sanitization** : nettoyage des inputs utilisateur

### 9.3 Protection CSRF / CORS

- **CSRF tokens** : pour les actions sensibles
- **CORS stricte** : whitelist des origines autorisées
- **SameSite cookies** : protection contre CSRF

### 9.4 En-têtes de sécurité

```javascript
// next.config.js
headers: {
  'Content-Security-Policy': "default-src 'self'; ...",
  'X-Frame-Options': 'DENY',
  'X-Content-Type-Options': 'nosniff',
  'Strict-Transport-Security': 'max-age=31536000',
  'Permissions-Policy': 'geolocation=(), microphone=()'
}
```

### 9.5 Secrets et variables d'environnement

- **Aucun secret en clair** : variables d'environnement uniquement
- **.env exclusion** : gitignore strict
- **Rotation** : changement régulier des API keys

### 9.6 Mitigation des attaques

| Attaque | Mitigation |
|---------|------------|
| XSS | CSP stricte + sanitization + React auto-escaping |
| CSRF | SameSite cookies + tokens |
| Injection SQL | N/A (pas de DB SQL, blockchain only) |
| Path traversal | Validation stricte des paths IPFS |
| ReDOS | Timeout sur regex complexes |
| DoS upload | Limite taille fichier (10 MB) + rate limiting |

---

## 10. Conformité et posture réglementaire (RGPD / hébergement santé)

### 10.1 Approche MVP réaliste

**Principes appliqués :**

✅ **Minimisation des données**
- Seules métadonnées minimales on-chain
- Aucune donnée médicale en clair sur la blockchain
- Pseudonymisation (adresses Ethereum)

✅ **Chiffrement systématique**
- AES-256-GCM avant upload IPFS
- Clés chiffrées avant stockage on-chain
- Architecture zéro-knowledge

✅ **Journalisation des accès**
- Événements blockchain immuables
- Journal applicatif des consultations
- Historique de partage visible par le patient

✅ **Gestion des durées**
- Expiration automatique des accès temporaires
- Révocation manuelle possible
- Purge des clés (fonction `emergencyClearKeys()`)

✅ **Séparation des rôles**
- Patient (data controller)
- Professionnel (data processor)
- Admin technique (infrastructure only, no data access)

### 10.2 Droits RGPD implémentés

| Droit | Implémentation |
|-------|----------------|
| **Accès** | Patient voit tous ses documents + historique de partage |
| **Rectification** | Re-upload possible (nouveau NFT, ancien révoqué) |
| **Effacement** | `emergencyClearKeys()` + burn NFT (optionnel) |
| **Portabilité** | Export de tous les documents (format standard) |
| **Limitation** | Partage granulaire (catégories, durée) |
| **Opposition** | Révocation d'accès instantanée |
| **Consentement** | Explicite via transaction on-chain |

### 10.3 Points à cadrer avant industrialisation

⚠️ **Le whitepaper n'est pas un tampon magique "RGPD compliant".**
C'est un **engagement d'architecture + roadmap de conformité**.

**Avant production :**

1. **Qualification des rôles**
   - Responsable de traitement vs sous-traitant (selon cas d'usage)
   - Contractualisation avec établissements de santé
   - DPA (Data Processing Agreement) si nécessaire

2. **Exigences d'hébergement**
   - HDS (Hébergement de Données de Santé) si périmètre l'impose
   - Certification ISO 27001 / HDS pour IPFS / infrastructure
   - SOC 2 Type II pour providers (Alchemy, Pinata)

3. **DPIA (Data Protection Impact Assessment)**
   - Analyse des risques pour les droits et libertés
   - Mesures de mitigation
   - Validation par DPO (Data Protection Officer)

4. **Registre de traitements**
   - Documentation complète des flux de données
   - Base légale (consentement, contrat, intérêt légitime)
   - Durées de conservation

5. **Procédures d'incident**
   - Notification CNIL sous 72h (si breach)
   - Notification patients concernés
   - Plan de réponse aux incidents

6. **Purge et rétention**
   - Politique de conservation (ex : 10 ans pour dossiers médicaux)
   - Suppression automatique après expiration
   - Logs d'audit (combien de temps ?)

---

## 11. Cas d'usage MVP

### 11.1 Pré-admission / bureau des entrées

**Problème actuel :**
- Patient arrive sans documents
- Retour à domicile pour récupérer pièces
- Photocopies, saisie manuelle

**Avec HealthGuard :**

1. Patient upload en amont : ID, mutuelle, ordonnance, CR
2. Génère un QR code "Admission"
3. Bureau des entrées scanne le QR
4. Accès temporaire (1h) aux documents administratifs
5. Récupération directe des infos
6. Révocation automatique après traitement

**Bénéfices :**
- ⏱️ Réduction temps d'attente (30 min → 5 min)
- 📄 Zéro photocopie
- 🔒 Traçabilité complète

### 11.2 Consultation spécialiste

**Problème actuel :**
- Email d'examens entre généraliste et spécialiste
- Clé USB oubliée
- Re-prescription d'examens déjà faits

**Avec HealthGuard :**

1. Patient partage "Imagerie + CR" pendant 14 jours
2. Spécialiste consulte avant RDV
3. Gain de temps en consultation
4. Révocation automatique après 14 jours

**Bénéfices :**
- 🩺 Meilleure préparation de la consultation
- 💰 Évite examens redondants (€€€)
- ⏱️ Consultation plus efficace

### 11.3 Suivi chroniques / parcours coordonné

**Problème actuel :**
- Informations médicales fragmentées
- Coordination difficile entre professionnels
- Patient "messager" entre soignants

**Avec HealthGuard :**

1. Patient diabétique partage :
   - **Biologie** → Infirmier (accès permanent)
   - **Imagerie** → Cardiologue (accès temporaire)
   - **Ordonnances** → Pharmacien (accès permanent)
2. Chaque pro accède uniquement à ce qui le concerne
3. Historique visible par le patient

**Bénéfices :**
- 🤝 Coordination améliorée
- 🎯 Partage ciblé et sécurisé
- 📊 Vision globale pour le patient

### 11.4 Urgences

**Problème actuel :**
- Patient inconscient sans dossier médical
- Allergies, traitements en cours inconnus
- Perte de temps vitale

**Avec HealthGuard (roadmap) :**

1. Patient configure "Accès d'urgence"
2. En cas d'urgence, médecin scanne bracelet/carte
3. Accès automatique 24h (lecture seule)
4. Consultation : allergies, traitements, groupe sanguin
5. Traçabilité : notification patient post-urgence

**Bénéfices :**
- ⚕️ Accès vital en urgence
- 🔒 Traçabilité même en urgence
- 📱 Notification a posteriori

---

## 12. Roadmap (proposée)

### Phase 0 – POC (0–4 semaines) ✅ **COMPLÉTÉ**

**Objectifs :**
- Upload chiffré + stockage IPFS + mint NFT document
- Listing documents côté patient
- Partage simple (accord/refus) + consultation pro
- Smart contracts déployés sur Sepolia

**Livrables :**
- ✅ 11+ smart contracts déployés
- ✅ Frontend Next.js fonctionnel
- ✅ Chiffrement hiérarchique 3 niveaux
- ✅ Partage X25519 Pro → Patient
- ✅ QR code pour accès temporaire

### Phase 1 – MVP bêta (1–3 mois) 🚧 **EN COURS**

**Objectifs :**
- Accès temporaire avec gestion fine (durées, catégories)
- UX mobile optimisée (PWA)
- Parcours professionnel simplifié
- Journalisation + exports

**Tâches :**
- [ ] PWA (Progressive Web App) pour mobile
- [ ] Interface pro dédiée (dashboard)
- [ ] Export PDF de l'historique de partage
- [ ] Notifications push (accès accordé/révoqué)
- [ ] Support multi-langues (EN/FR)
- [ ] Tests utilisateurs (alpha testers)

### Phase 2 – Intégrations (3–9 mois) 📅 **PLANIFIÉ**

**Objectifs :**
- Connecteurs logiciels métiers (DPI/SIH)
- Modèle DID professionnel
- Signature/attestation de documents
- Interopérabilité DMP (Dossier Médical Partagé)

**Tâches :**
- [ ] Connecteur HL7 FHIR (standard interop santé)
- [ ] DID (Decentralized Identifier) pour pros
- [ ] Signature électronique des documents (EIP-712)
- [ ] API REST pour intégrations tierces
- [ ] SDK JavaScript pour établissements
- [ ] Contextual launch (SMART on FHIR)

### Phase 3 – Version "scale" (9–18 mois) 🔮 **VISION**

**Objectifs :**
- Gouvernance multi-établissements
- Conformité renforcée (HDS, ISO 27001)
- Audits de sécurité externes
- Passage en production (mainnet)

**Tâches :**
- [ ] Certification HDS (Hébergement Données de Santé)
- [ ] Audit de sécurité smart contracts (Certik/Trail of Bits)
- [ ] DPIA complète + validation CNIL
- [ ] Migration Ethereum mainnet (ou L2 production)
- [ ] Multi-tenancy (établissements multiples)
- [ ] DAO (gouvernance décentralisée - optionnel)

---

## 13. Risques et limites (parce que la réalité existe)

### 13.1 Risques techniques

| Risque | Impact | Probabilité | Mitigation |
|--------|--------|-------------|------------|
| **UX Web3** : friction wallet, clés | Élevé | Élevé | Account Abstraction, social login, gasless |
| **IPFS disponibilité** : pinning défaillant | Élevé | Moyen | Redondance multi-providers, backup S3 chiffré |
| **Smart contract bug** : exploit | Critique | Faible | Audits externes, tests unitaires (100% coverage) |
| **Perte de wallet** : clés irrécupérables | Élevé | Moyen | Récupération sociale, multi-sig, backup seeds |
| **Performance** : lenteur blockchain | Moyen | Faible | L2 (Arbitrum), batch transactions, caching |

### 13.2 Risques utilisateurs

| Risque | Impact | Mitigation |
|--------|--------|------------|
| **Erreur de partage** : patient partage trop large | Élevé | UI claire, confirmation, révocation facile |
| **Métadonnées fuitent** : même minimales | Moyen | Anonymisation max, chiffrement CID |
| **Clé compromise** : vol de clé privée | Critique | Hardware wallets, 2FA, rotation de clés |
| **Mauvaise catégorisation** : document mal classé | Faible | Suggestions auto, validation ML (roadmap) |

### 13.3 Risques réglementaires

| Risque | Impact | Mitigation |
|--------|--------|------------|
| **Non-conformité RGPD** : sanction CNIL | Critique | DPIA, DPO, documentation complète |
| **HDS requis** : coût/complexité | Élevé | Plan de certification, choix hébergeur certifié |
| **Responsabilité juridique** : qui est responsable ? | Élevé | Contrats clairs, CGU/CGV, assurance RC Pro |
| **Changement régulation** : nouvelles lois | Moyen | Veille juridique, architecture modulaire |

### 13.4 Limites assumées du MVP

⚠️ **Ce que HealthGuard NE fait PAS (encore) :**

- ❌ Remplacer les DPI (Dossiers Patients Informatisés) hospitaliers
- ❌ Prescription électronique certifiée (e-prescription)
- ❌ Téléconsultation intégrée
- ❌ IA de diagnostic médical
- ❌ Gestion de pharmacie / stock médicaments
- ❌ Prise de RDV en ligne
- ❌ Messagerie sécurisée pro-patient (roadmap)

**Focus MVP :** Stockage sécurisé + partage ciblé de documents existants.

---

## 14. Architecture technique détaillée

### 14.1 Stack complète

```
┌─────────────────────────────────────────────────────────┐
│                    FRONTEND (Next.js)                   │
│  ┌─────────────┐  ┌──────────────┐  ┌───────────────┐  │
│  │   Patient   │  │ Professional │  │  Admin (dev)  │  │
│  │  Interface  │  │  Interface   │  │   Interface   │  │
│  └─────────────┘  └──────────────┘  └───────────────┘  │
│         │                 │                  │          │
│         └─────────────────┴──────────────────┘          │
│                         │                               │
│         ┌───────────────▼───────────────┐               │
│         │   Account Abstraction (AA)   │               │
│         │    Alchemy Account Kit       │               │
│         └───────────────┬───────────────┘               │
└─────────────────────────┼───────────────────────────────┘
                          │
         ┌────────────────▼────────────────┐
         │   BLOCKCHAIN (Ethereum Sepolia) │
         │  ┌────────────────────────────┐ │
         │  │  11+ Smart Contracts      │ │
         │  │  - NFT Documents          │ │
         │  │  - Encryption Registries  │ │
         │  │  - Access Manager         │ │
         │  │  - Identity (Patient/Pro) │ │
         │  └────────────────────────────┘ │
         └────────────────┬────────────────┘
                          │
         ┌────────────────▼────────────────┐
         │   STORAGE (IPFS via Pinata)     │
         │  ┌────────────────────────────┐ │
         │  │  Encrypted Medical Files  │ │
         │  │  - PDFs                   │ │
         │  │  - Images (JPEG, PNG)     │ │
         │  │  - DICOM (roadmap)        │ │
         │  └────────────────────────────┘ │
         └─────────────────────────────────┘
```

### 14.2 Flux de données complet

```mermaid
graph TD
    A[Patient Upload] -->|1. Select File| B[Frontend]
    B -->|2. Generate Keys| C[Crypto Layer]
    C -->|3. Encrypt File| D[AES-256-GCM]
    D -->|4. Upload| E[IPFS Pinata]
    E -->|5. Return CID| B
    B -->|6. Encrypt CID + Wrap Key| C
    C -->|7. Mint NFT| F[Smart Contract]
    F -->|8. Store Metadata| G[Blockchain]
    G -->|9. Emit Event| H[Event Log]

    I[Pro Request] -->|10. Scan QR| B
    B -->|11. Grant Access| F
    F -->|12. Encrypt Key X25519| C
    C -->|13. Store Envelope| G

    J[Pro Consultation] -->|14. Verify Access| F
    F -->|15. Return Envelope| B
    B -->|16. Decrypt X25519| C
    C -->|17. Fetch CID| E
    E -->|18. Download File| B
    B -->|19. Decrypt AES| C
    C -->|20. Display| J
```

### 14.3 Répartition on-chain / off-chain

| Donnée | On-Chain | Off-Chain | Chiffrement |
|--------|----------|-----------|-------------|
| **Fichier médical** (PDF/image) | ❌ | ✅ IPFS | ✅ AES-256-GCM |
| **CID IPFS** | ✅ (chiffré) | ❌ | ✅ Chiffré |
| **Clé de document** | ✅ (wrappée) | ❌ | ✅ Wrappée avec catégorie |
| **Clé de catégorie** | ✅ (chiffrée) | ❌ | ✅ Chiffrée avec Master |
| **Master Key** | ❌ | ❌ | N/A (dérivée) |
| **X25519 Public Key** | ✅ | ❌ | ❌ (publique) |
| **X25519 Private Key** | ❌ | ❌ | N/A (dérivée) |
| **Hash SHA-256** | ✅ | ❌ | ❌ |
| **Métadonnées NFT** | ✅ | ❌ | ✅ Minimales |
| **Événements d'accès** | ✅ | ❌ | ❌ |
| **Identité patient** | ✅ (NFT) | ❌ | ❌ |
| **RPPS pro** | ✅ (NFT) | ❌ | ❌ |

**Principe :** Maximiser off-chain chiffré, minimiser on-chain en clair.

### 14.4 Performance et coûts

#### Gas costs estimés (Sepolia testnet) :

| Opération | Gas | Coût ETH (≈) | Coût USD (≈) |
|-----------|-----|--------------|--------------|
| Mint NFT patient | ~150k | 0.003 ETH | $0 (gasless) |
| Upload document | ~200k | 0.004 ETH | $0 (gasless) |
| Grant access | ~80k | 0.0016 ETH | $0 (gasless) |
| Revoke access | ~50k | 0.001 ETH | $0 (gasless) |
| Rotate category key | ~100k | 0.002 ETH | $0 (gasless) |

**Note :** Avec Account Abstraction (paymaster), les utilisateurs ne paient rien.

#### Stockage IPFS (Pinata) :

| Plan | Stockage | Coût/mois | Documents (≈) |
|------|----------|-----------|---------------|
| Free | 1 GB | $0 | ~1000 PDFs (1 MB chacun) |
| Pro | 100 GB | $20 | ~100,000 PDFs |
| Enterprise | Illimité | Custom | Illimité |

**Optimisations :**
- Compression avant chiffrement (zlib)
- Déduplication (hash identique = même CID)
- Garbage collection (documents révoqués)

---

## 15. Comparaison avec solutions existantes

### 15.1 HealthGuard vs DMP (Dossier Médical Partagé)

| Critère | DMP | HealthGuard |
|---------|-----|-------------|
| **Contrôle** | Centralisé (Assurance Maladie) | Décentralisé (Patient) |
| **Accès** | Via CPS (Carte Pro Santé) | QR code + blockchain |
| **Stockage** | Serveurs centralisés | IPFS décentralisé |
| **Chiffrement** | Transport (HTTPS) | End-to-end (AES-256) |
| **Révocation** | Difficile | Instantanée |
| **Traçabilité** | Logs centralisés | Blockchain immuable |
| **Interopérabilité** | Standards français | Blockchain (global) |
| **Adoption** | Faible (~10% France) | MVP (early adopters) |

**Complémentarité :** HealthGuard peut être un "wallet d'appoint" pour documents personnels, pré-admission, urgences, voyages à l'étranger.

### 15.2 HealthGuard vs Google Health / Apple Health

| Critère | Google/Apple Health | HealthGuard |
|---------|---------------------|-------------|
| **Modèle** | Centralisé (cloud) | Décentralisé (blockchain) |
| **Propriété** | Google/Apple | Patient (NFT) |
| **Chiffrement** | Cloud (clés Google/Apple) | Client-side (clés patient) |
| **Partage** | Via compte Google/Apple | Blockchain (direct) |
| **Audit** | Opaque | Transparent (events on-chain) |
| **Données** | Fitness + santé légère | Documents médicaux lourds |
| **Professionnels** | Non | Oui (QR code, RPPS) |

**Différence clé :** HealthGuard vise les **documents médicaux professionnels** (ordonnances, CR, imagerie), pas le fitness.

### 15.3 HealthGuard vs Blockchain santé (Medicalchain, MedRec, etc.)

| Critère | Medicalchain/MedRec | HealthGuard |
|---------|---------------------|-------------|
| **Blockchain** | Ethereum / Hyperledger | Ethereum Sepolia (+ multi-chain) |
| **Account Abstraction** | ❌ | ✅ ERC-4337 |
| **UX** | Complexe (clés privées) | Simplifiée (email, social) |
| **Gasless** | ❌ | ✅ Paymaster |
| **Chiffrement** | Variable | Hiérarchique 3 niveaux |
| **Adoption** | Pilots limités | MVP (France) |
| **Open Source** | Partiel | Roadmap (open-source) |

**Avantage :** Account Abstraction = **UX grand public** (pas de wallet friction).

---

## 16. Support multi-chain (roadmap)

### 16.1 Chaînes supportées (testnet MVP)

Le projet est **multi-chain ready** :

- ✅ **Ethereum Sepolia** (principal)
- ✅ Arbitrum Sepolia
- ✅ Base Sepolia
- ✅ Polygon Amoy
- ✅ Optimism Sepolia (roadmap)
- ✅ Scroll Sepolia (roadmap)

### 16.2 Stratégie multi-chain

**Pourquoi multi-chain ?**

- **Coûts** : L2 moins cher (Arbitrum, Base)
- **Performance** : Throughput élevé (Polygon)
- **Écosystème** : Partenariats spécifiques
- **Résilience** : Pas de dépendance à une seule chaîne

**Architecture :**

```
Patient Wallet (AA)
    │
    ├─ Documents Ethereum (NFT)
    ├─ Documents Arbitrum (NFT)
    └─ Documents Polygon (NFT)
        │
        └─ Unified View (Frontend aggregation)
```

**Interopérabilité :**
- Même adresse sur toutes les chaînes (EVM)
- Clés de chiffrement chain-agnostic
- Frontend unifié (vue multi-chain)

### 16.3 Migration L1 → L2 (roadmap)

**Objectifs :**
- Réduire coûts gas (100x moins cher)
- Améliorer performance (10x plus rapide)
- Maturité L2 (Arbitrum, Base)

**Stratégie :**
- Phase 1 : Dual deployment (L1 + L2)
- Phase 2 : Migration progressive (nouveaux docs sur L2)
- Phase 3 : L2 principal, L1 legacy

---

## 17. Gouvernance et modèle économique (vision)

### 17.1 Modèle économique envisagé

**MVP :** Gratuit (financement innovation / R&D)

**Post-MVP :**

| Acteur | Tarification | Justification |
|--------|--------------|---------------|
| **Patients** | Gratuit (freemium) | Accès de base gratuit, premium pour stockage illimité |
| **Professionnels** | Abonnement (€5–20/mois) | Outils pro, intégration DPI, support prioritaire |
| **Établissements** | Licence (€500–5000/mois) | Multi-utilisateurs, API, conformité renforcée |
| **Assurances** | Partenariats | Réduction coûts via meilleure coordination |

**Revenus potentiels :**
- Abonnements professionnels
- Licences établissements
- API usage (pay-per-call)
- Services premium (signature électronique, téléconsultation)

### 17.2 Gouvernance (roadmap DAO)

**Vision décentralisée :**

- **HealthGuard DAO** : gouvernance communautaire
- **Token de gouvernance** : HG (roadmap)
- **Votes** : évolution protocole, partenariats, treasury

**Participants :**
- Patients (utilisateurs)
- Professionnels (early adopters)
- Développeurs (contributeurs)
- Établissements (partenaires)

**Décisions :**
- Nouvelles fonctionnalités
- Tarification
- Allocation budget R&D
- Partenariats stratégiques

---

## 18. Conclusion

HealthGuard est une tentative très **pragmatique** de résoudre un problème très **humain** : arrêter de perdre du temps et de la sécurité sur des documents médicaux, tout en respectant une contrainte centrale : **la confidentialité**.

### Ce que HealthGuard apporte :

✅ **Contrôle patient** : propriété réelle de ses données (NFT)
✅ **Sécurité cryptographique** : chiffrement end-to-end, zéro-knowledge
✅ **Partage ciblé** : granulaire (catégorie, durée, niveau)
✅ **Traçabilité** : blockchain immuable, audit complet
✅ **UX simplifiée** : Account Abstraction, gasless, social login
✅ **Interopérabilité** : multi-chain, standards ouverts (FHIR roadmap)

### Ce que HealthGuard ne prétend PAS être :

❌ Un remplacement des DPI hospitaliers
❌ Une solution magique "RGPD compliant" sans effort
❌ Un projet fini (c'est un MVP itératif)
❌ Une plateforme de téléconsultation (hors scope)

### L'objectif du MVP :

Livrer une **première brique utile, testable, et extensible**, qui remet le patient en contrôle et facilite la vie des professionnels.

**HealthGuard n'est pas une révolution.**
C'est une **évolution pragmatique** vers une santé numérique plus respectueuse, plus sécurisée, et plus humaine.

---

## Annexes

### A. Glossaire

- **AA (Account Abstraction)** : ERC-4337, permet wallets sans gestion de clés
- **AES-GCM** : Chiffrement symétrique authentifié (NIST)
- **CID** : Content Identifier (IPFS)
- **DID** : Decentralized Identifier
- **DMP** : Dossier Médical Partagé (France)
- **ERC-721** : Standard NFT Ethereum
- **HKDF** : HMAC-based Key Derivation Function (RFC 5869)
- **IPFS** : InterPlanetary File System (stockage décentralisé)
- **RPPS** : Répertoire Partagé des Professionnels de Santé
- **X25519** : Algorithme Diffie-Hellman sur Curve25519

### B. Références

- [ANSSI - Guide de sélection d'algorithmes cryptographiques](https://www.ssi.gouv.fr/)
- [ERC-4337: Account Abstraction](https://eips.ethereum.org/EIPS/eip-4337)
- [NIST SP 800-38D: AES-GCM](https://csrc.nist.gov/publications/detail/sp/800-38d/final)
- [RFC 5869: HKDF](https://datatracker.ietf.org/doc/html/rfc5869)
- [RGPD - Texte officiel](https://www.cnil.fr/fr/reglement-europeen-protection-donnees)
- [HL7 FHIR](https://www.hl7.org/fhir/)
- [HDS - Hébergement Données de Santé](https://esante.gouv.fr/produits-services/hds)

### C. Contact

**Projet** : HealthGuard (HGP-AA)
**Version** : v2.0.0-alpha.3
**Repository** : (à publier)
**Contact** : [À compléter]
**Discord** : (roadmap)
**Twitter** : (roadmap)

---

**Dernière mise à jour :** 20/12/2025
**Prochaine révision :** Phase 1 MVP bêta (Q1 2026)

---

*Ce document est un work-in-progress. Les retours et contributions sont les bienvenus.*

*HealthGuard - Pour une santé numérique vraiment au service du patient.*