Politique de signature

Cette page décrit comment la plateforme EIZOR, éditée par la SAS ESIT, fait signer les documents du médecin requis, comment elle les scellera, et ce qu'elle conserve pour en apporter la preuve. Elle s'adresse aux professionnels qui utilisent la plateforme comme à ceux qui reçoivent ces documents : pharmacien, radiologue, infirmier, fournisseur de pansements.

Deux documents sont concernés :

• le compte rendu de téléexpertise, établi à partir de l'avis du médecin requis ;
• les ordonnances jointes à cet avis (médicaments, produits locaux, imagerie, soins infirmiers). L'interface propose chacune dans un PDF distinct, un destinataire par PDF.

La demande du requérant, les photographies et les messages du dossier ne sont pas signés. Le compte rendu reprend une partie de la demande (question posée, contexte clinique) : cette copie suit le sort du compte rendu. Aucune photographie n'y figure.

Les conditions de services l'incorporent par référence : article 24 pour le professionnel requérant, article 22 pour le médecin requis.

EIZOR retient le palier 2 du référentiel « Force probante des documents de santé » de l'Agence du numérique en santé (ANS), celui que ce référentiel fixe pour l'ordonnance comme pour le compte rendu. Il associe deux éléments :

• la signature électronique simple du médecin requis : authentifié sur la plateforme, il valide lui-même son avis, et le document porte son nom, son numéro RPPS et, s'il l'a déposé, son paraphe manuscrit ;
• le cachet serveur de la SAS ESIT, certificat de cachet de personne morale que l'exploitant prévoit d'obtenir de l'IGC Santé, qui scellera chaque PDF une fois installé et activé.

Le premier élément fonctionne aujourd'hui. Le second, pas encore : le certificat de production n'est pas installé. Tant qu'il ne l'est pas, le palier 2 n'est pas atteint et les documents sortent sans sceau (section 6).

Une fois en place, le cachet attestera que le document est sorti de la plateforme et n'a pas été modifié depuis. Il ne dira rien de l'identité du médecin, qui repose sur le procédé décrit à la section 4.

Aucun certificat personnel n'est délivré au médecin. Sa signature est une signature électronique au sens de l'article 1367 du code civil, sans la présomption de fiabilité prévue au second alinéa de cet article : sa valeur se démontre par le dossier de preuve décrit à la section 7, que les conditions de services reconnaissent entre les parties. Aucun autre niveau n'est revendiqué.

1. Le médecin requis se connecte (section 4). Seul un compte de médecin requis validé par l'exploitant et rattaché à la file des médecins peut prendre en charge un dossier et le signer (art. L.4161-1 du code de la santé publique).
2. Il ouvre le dossier. L'interface le lui attribue à l'ouverture, ou au plus tard à l'envoi de l'avis. Une fois le dossier attribué, lui seul peut le signer. Le dossier ne revient à la file que s'il le rend lui-même ou si l'exploitant le libère (dossier bloqué, compte du médecin désactivé avec remise à la file, compte supprimé).
3. Il rédige son avis dans le formulaire : diagnostic, compte rendu (30 caractères au moins, hors espaces de début et de fin), suivi et, s'il y a lieu, ordonnances.
4. S'il joint au moins une ordonnance, il coche la case « Je confirme disposer d'éléments suffisants et assumer la responsabilité de cette prescription. » Sans elle, le serveur refuse l'envoi. L'heure de cette confirmation est enregistrée avec l'avis, puis inscrite au journal d'audit.
5. Il clique sur « Signer et envoyer l'expertise ». Ce clic vaut validation : l'avis et ses ordonnances sont enregistrés en une seule opération, le dossier passe à l'état répondu, puis l'événement est inscrit au journal d'audit. Un email est envoyé au requérant : il donne le nom du médecin et un lien vers le dossier sur la plateforme, sans aucune donnée patient.
6. Juste après la validation, la plateforme produit le compte rendu et chaque ordonnance en PDF à partir de l'avis enregistré, y place le cartouche du médecin et archive ces fichiers. Une fois le cachet activé, elle les scellera à ce moment-là (sections 5 et 6).

Une fois enregistré, l'avis ne se modifie plus. La plateforme n'offre aucune fonction pour corriger ou supprimer le diagnostic, le compte rendu ou une ordonnance ; seul l'indicateur déclaratif « facturé à l'Assurance Maladie », propre au médecin, peut encore changer.

Ces PDF sont l'original. Chacun est chiffré puis conservé chez l'hébergeur, avec son empreinte SHA-256 et l'heure de l'archivage. Chaque téléchargement sert ce même fichier, sans le refaire : un changement ultérieur du paraphe, du nom ou des coordonnées du médecin ne modifie pas un document déjà émis, et un original archivé n'est jamais remplacé. Si l'archivage échoue juste après la validation, l'avis reste validé ; le document est alors produit et archivé lors d'un téléchargement suivant. Pour un avis validé avant la mise en place de cet archivage (octobre 2026), l'original est le premier exemplaire archivé lors d'un téléchargement, avec le paraphe et les coordonnées du compte à ce moment-là.

Une exception : quand l'identité d'un patient a été effacée à sa demande, la plateforme ne sert plus l'original, qui la contient. Le document est produit à chaque téléchargement, sans cette identité, et n'est pas archivé ; l'original reste conservé chez l'hébergeur.

Limites actuelles : l'aperçu du PDF final n'est pas présenté au médecin avant la validation (il relit son avis dans le formulaire de saisie), et aucune case distincte ne recueille son consentement à signer.

L'identité du signataire repose sur deux contrôles, de fiabilité différente, faits à des moments différents.

• À l'inscription, une déclaration puis une vérification manuelle. Le médecin déclare son numéro RPPS. La plateforme contrôle son format (11 chiffres, clé de contrôle) et refuse un numéro déjà présent, à l'identique, sur un autre compte ; elle ne vérifie pas son existence auprès de l'Annuaire santé. Le compte ne peut rien signer tant qu'un administrateur de la plateforme ne l'a pas validé. Depuis la console d'administration, la validation exige une note de vérification d'au moins 10 caractères et peut s'appuyer sur une liste de contrôle facultative (Annuaire santé consulté, pièce d'identité vue, attestation d'assurance de responsabilité civile professionnelle vue). La date, l'auteur, la note et la liste sont conservés avec le compte, et la validation est journalisée. L'adresse email est confirmée par un lien avant la première connexion par mot de passe.
• À chaque connexion, une authentification. Mot de passe, haché avec Argon2id, puis, quand la double authentification est activée, un code à 6 chiffres de l'application d'authentification. Ce code change toutes les 30 secondes et reste accepté environ 90 secondes, pour tolérer un décalage d'horloge. La plateforme garde la période du dernier code accepté à la connexion et refuse ensuite les codes de cette période ou d'une période antérieure. Des codes de secours existent ; chacun est marqué comme utilisé dès qu'il est accepté. La session repose sur un jeton d'accès de 15 minutes par défaut, et le compte est relu en base à chaque requête authentifiée par cette session : un compte désactivé perd l'accès à la requête suivante.

La double authentification est exigée par défaut pour les comptes requérant, requis et administrateur, et l'utilisateur ne peut pas la désactiver tant qu'elle est exigée pour son rôle. Un compte qui ne l'a pas encore activée dispose d'un délai de grâce de 7 jours après sa création (valeur par défaut) ; passé ce délai, toute action métier est bloquée, signature comprise, jusqu'à son activation. Pendant ce délai, un médecin requis déjà validé peut signer avec son seul mot de passe.

La connexion par Pro Santé Connect (carte e-CPS) n'est pas ouverte. L'identité professionnelle du médecin repose donc sur la seule vérification faite à l'inscription.

Ce qui suit décrit le scellement tel qu'il est programmé. Il ne s'appliquera qu'une fois le certificat de production installé et le scellement activé (section 6).

• Format : signature CMS détachée insérée dans le PDF, avec le sous-filtre /ETSI.CAdES.detached du format PAdES.
• Empreinte et signature : empreinte SHA-256 calculée sur tout le fichier hors de l'emplacement réservé au sceau, signée en RSA par la clé du certificat de cachet. Les certificats contenus dans le fichier du cachet (le sien et, s'ils y figurent, ceux de l'autorité émettrice) sont joints au sceau.
• Scellant : le sceau désigne la SAS ESIT, avec le lieu « Clichy, France » et le contact « contact@eizor.fr ».
• Heure : celle de l'horloge du serveur au moment du scellement, portée dans l'attribut signing-time. Aucun jeton d'horodatage RFC 3161 n'est apposé.
• Niveau : le sceau ne revendique pas le niveau PAdES Baseline B. Il ne porte pas l'attribut signing-certificate-v2 que ce niveau exige, et il contient l'attribut signing-time que ce profil écarte.
• Certificat : un seul certificat, commun à toute la plateforme quel que soit l'établissement, fourni à l'application par une variable d'environnement chez l'hébergeur.

En production, hors environnement déclaré à données fictives, la plateforme refuse de démarrer avec un cachet simulé. Hors cachet simulé, elle refuse aussi de démarrer avec un certificat auto-signé, et elle refuse dans tous les cas un certificat expiré. Ces contrôles ont lieu au démarrage : un certificat qui expire ensuite n'est détecté qu'au redémarrage suivant. La plateforme ne vérifie pas d'elle-même l'autorité émettrice ni le nom du titulaire.

Si le scellement d'un document échoue, ce document est servi sans sceau et sans mention de scellement.

Le paraphe manuscrit n'a aucune valeur cryptographique. Le médecin le dépose depuis son espace (image de 2 Mo au plus) ; il est ré-encodé en PNG, ce qui retire ses métadonnées, ramené à 600 × 200 pixels au plus, puis chiffré en AES-256-GCM avant d'être stocké. Quand le médecin le remplace, l'ancienne image cesse d'être utilisée et la plateforme lance son effacement du stockage. En dehors des documents où il est apposé, seul le médecin peut l'afficher.

Le contenu de l'avis et des ordonnances est chiffré en base (AES-256-GCM). La plateforme est hébergée chez Clever Cloud SAS, hébergeur certifié « Hébergeur de données de santé » (certificat n° FR094504).

Le certificat de cachet de production n'est pas installé et le scellement n'est pas activé. Aucun document n'est scellé. Sur la plateforme :

• les comptes rendus et les ordonnances sont produits sans sceau ;
• l'ordonnance ne porte ni bandeau ni filigrane : la mention « ORDONNANCE NON OPPOSABLE », imprimée jusqu'au 2 novembre 2026, a été retirée ;
• l'ordonnance porte en tête le nom du médecin, son RPPS et son adresse email ; en bas, « Fait à distance, le [date] », son paraphe s'il l'a déposé, son nom, son RPPS, puis « Signé électroniquement le [date] via la plateforme EIZOR » ;
• le compte rendu porte en tête le nom du médecin, son RPPS, son adresse email et « Avis rendu le [date] », ainsi que son paraphe s'il l'a déposé. Il n'a ni bandeau ni filigrane.

Ces dates sont celles de la validation de l'avis, lues sur l'horloge du serveur.

Une fois le certificat installé et le scellement activé par l'exploitant, chaque compte rendu et chaque ordonnance seront scellés au moment de leur production, sauf échec du scellement (section 5). La mention du sceau sur le document dépend d'un réglage séparé, que l'exploitant active après avoir vérifié les premiers sceaux. La plateforme de production refuse de démarrer si ce réglage est posé sans scellement actif ou avec un cachet simulé. Tant qu'il n'est pas activé, aucune mention de scellement n'est imprimée, même sur un PDF scellé. Une fois activé, le compte rendu comme l'ordonnance porteront : « Document scellé par le cachet serveur de la SAS ESIT (PAdES). Toute modification postérieure invalide le sceau. » La section 9 précise ce que couvre ce sceau.

Sur un environnement de démonstration, les ordonnances portent « ORDONNANCE DE DÉMONSTRATION. NON OPPOSABLE. DONNÉES FICTIVES », un filigrane « DÉMONSTRATION » et « Signature électronique simulée (démonstration) » ; les comptes rendus portent un filigrane « DÉMONSTRATION ». Un tel environnement peut sceller ses documents avec un cachet simulé, sans aucune valeur probante.

Le dossier de preuve d'une signature se reconstitue à partir des éléments suivants, tous enregistrés par la plateforme :

• l'avis et ses ordonnances (contenu chiffré), avec l'identifiant du médecin signataire et la date et l'heure de validation ;
• l'heure de la confirmation de prescription directe, quand une ordonnance est jointe ;
• pour un compte validé depuis la console d'administration, la date, l'auteur et la note de la validation, et la liste de contrôle quand l'administrateur l'a remplie ;
• la date et la version des conditions acceptées à l'inscription, ou à l'activation d'un compte invité. Une nouvelle acceptation après un changement de version n'est pas encore enregistrée ;
• le journal d'audit, décrit ci-dessous ;
• les traces d'envoi des emails de notification, tant qu'elles sont conservées (section 8).

Le journal d'audit enregistre la validation de l'avis, la confirmation de prescription, le dépôt et le retrait du paraphe, l'activation et la désactivation de la double authentification, les connexions et leur seconde étape, chaque téléchargement d'un compte rendu ou d'une ordonnance, chaque ouverture du coffre d'identité du patient pour produire un document, et la validation du compte du médecin par l'exploitant.

Chaque entrée porte la date et l'heure et, quand la personne est déjà connectée, l'identifiant de son compte. Les entrées liées à une requête portent aussi l'adresse IP et le navigateur ; celles qu'écrit un traitement interne (confirmation de prescription, ouverture du coffre d'identité) n'en portent pas. Les entrées de connexion ne portent pas l'identifiant du compte. L'entrée de validation d'un avis porte le compte du médecin et l'heure, sans l'identifiant de l'avis, qui se retrouve par ce compte et cette heure.

Les entrées liées à une requête sont écrites après l'action, sans la bloquer : si l'écriture échoue, l'action reste acquise et l'entrée manque. Quand une action tracée échoue ou est refusée pendant son traitement (dossier inaccessible, par exemple), l'échec est inscrit lui aussi ; un refus prononcé avant ce traitement (session absente, double authentification manquante) ne l'est pas. Aucune entrée ne reprend le contenu de l'avis ou des ordonnances : pour la confirmation de prescription, le journal garde le seul type des ordonnances émises.

Le journal est chaîné. Chaque entrée porte une empreinte SHA-256 calculée sur son contenu (auteur, action, ressource, adresse IP, navigateur, contexte, horodatage) et sur l'empreinte de l'entrée précédente. Modifier ou supprimer une entrée au milieu du journal rompt la chaîne, sauf à recalculer toutes les empreintes suivantes : l'empreinte n'est pas scellée par une clé, et la suppression des dernières entrées ne se voit pas. Les administrateurs disposent d'un contrôle de la chaîne, qui s'exécute par tranches (10 000 entrées par défaut). Le journal n'a pas de lien technique vers les comptes : la suppression d'un compte laisse ses entrées intactes et la chaîne vérifiable.

Conservation. La plateforme n'offre aucune fonction pour effacer un avis ou une ordonnance et ne programme aucune purge du dossier. La politique de conservation d'EIZOR, document au statut de projet à valider par le délégué à la protection des données, fixe la durée du dossier à 20 ans à compter du dernier avis rendu ; l'archivage intermédiaire et la suppression à l'échéance restent à mettre en place. Le compte rendu et les ordonnances sont archivés en PDF, chiffrés, au moment de la validation de l'avis (section 3). Les avis survivent au compte de leur auteur : la plateforme refuse de supprimer le compte d'un médecin qui a rendu un avis. Les données sont hébergées en France chez Clever Cloud SAS.

Accès. Dans la plateforme, les PDF ne sont servis qu'aux comptes qui ont accès au dossier : le requérant auteur de la demande, le médecin coordonnateur, qui lit les dossiers de son établissement, et le médecin requis signataire. Les comptes administrateurs de la plateforme n'ont accès, dans l'application, ni au contenu de l'avis et des ordonnances, ni à l'identité du patient, ni aux PDF. Le journal d'audit ne se consulte que depuis la console d'administration, réservée à ces comptes, et chaque consultation par cette console passe elle-même par le journal, avec le même mécanisme non bloquant. Un accès direct à la base de données, par l'exploitant ou par l'hébergeur, ne laisse pas de trace dans ce journal.

Un professionnel concerné peut demander à contact@eizor.fr un extrait des éléments non cliniques de son dossier de preuve : entrées du journal, validation de son compte, conditions acceptées, horodatages. Les comptes administrateurs n'ayant pas accès au contenu de l'avis ni des ordonnances, l'extrait ne le contient pas ; le professionnel qui a accès au dossier retélécharge lui-même les documents.

• Journal d'audit de la plateforme (accès aux dossiers, signature, téléchargements, connexions) : 240 mois, soit 20 ans, alignés sur la durée retenue pour le dossier. Il est purgé d'un seul tenant, sans tri par type d'action, car une purge sélective romprait la chaîne.
• Journaux techniques et de connexion de l'hébergeur : conservés par l'hébergeur selon sa propre politique. La politique de conservation d'EIZOR vise 12 mois ; EIZOR ne les archive pas, et la durée appliquée par l'hébergeur n'a pas encore été confirmée par écrit.

Au-delà de 240 mois, une purge glissante programmée chaque jour supprime les entrées les plus anciennes. Avant de supprimer, la plateforme enregistre une ancre (numéro et empreinte du dernier maillon supprimé) pour que la chaîne restante reste vérifiable ; quand elle supprime des entrées, la purge est journalisée juste après. Par défaut, les entrées purgées ne sont pas archivées.

Les traces d'envoi des emails de notification sont gardées 365 jours au plus, puis purgées automatiquement ; elles disparaissent plus tôt si le compte destinataire est supprimé.

La durée de 240 mois reste à confirmer par le délégué à la protection des données, dont la désignation est en cours.

Document non scellé (la situation actuelle). Aucune vérification cryptographique n'est possible. Le professionnel qui a accès au dossier peut télécharger de nouveau le document : il reçoit l'original archivé, qu'il peut comparer à l'exemplaire qu'il détient (section 3, qui décrit aussi le cas d'un patient effacé). Le destinataire d'une ordonnance peut joindre le prescripteur, dont le RPPS et l'adresse email figurent sur le document. L'exploitant peut confirmer sur demande, à contact@eizor.fr, qu'un avis a été validé sur la plateforme pour un numéro de dossier donné, par quel médecin et à quelle date. Il n'a pas accès au contenu des documents, mais l'empreinte SHA-256 de chaque original archivé est enregistrée : il peut indiquer si un exemplaire qu'on lui présente a la même empreinte que l'original.

Document scellé (une fois le certificat installé). Il s'ouvrira dans un lecteur qui affiche les signatures, Adobe Acrobat Reader par exemple, dont le panneau des signatures indique qui a scellé le document et s'il a été modifié depuis. Changer un seul octet de la partie scellée rend le sceau invalide. Une modification ajoutée par-dessus le fichier (annotation, nouvelle révision enregistrée) laisse le sceau valide pour la version qu'il couvre : le lecteur signale alors une modification postérieure au scellement et permet d'afficher la version scellée, seule couverte par le sceau. Un lecteur qui ne reconnaît pas l'autorité émettrice du certificat signale une identité non vérifiée, même si le fichier est intact.

Le document sera scellé une seule fois, quand il est produit puis archivé (section 3). Chaque téléchargement servira ensuite ce même fichier scellé, identique octet pour octet. Seul le document d'un patient effacé sera produit et scellé à chaque téléchargement.

Cette politique décrit le procédé en vigueur. Elle sera mise à jour à l'installation du certificat de cachet et à chaque changement du procédé.

Éditeur : SAS ESIT, 13 rue du Bac d'Asnières, 92110 Clichy. Contact : contact@eizor.fr. Les mesures de sécurité de la plateforme sont détaillées dans la politique de sécurité.