Le succès du FSE dépendra des services de l’EDS

L’écosystème des données de santé sera la clé de voûte du dossier de santé électronique. Toutes les questions restent sur la table.

Le décret réglementant la partie “documentaire» du Dossier de Santé Electronique (FSE) 2.0, le ministère de la Santé, la Direction de la Transformation Numérique et les Régions travaillent à la définition de l’Ecosystème de Données de Santé (EDS). Il y a de nombreux aspects auxquels il faut répondre et que j’essaierai de rapporter dans une série d’articles, dont celui-ci est le premier.

Une première observation concerne la méthode choisie qui, j’imagine, était également déterminée par le timing du PNRR. Nous avons défini les données qui composent les fichiers CDA injectés dans les PDF avant de définir les services que nous souhaitons créer avec EDS. Il aurait été préférable de faire l’inverse et de déterminer quelles données seraient nécessaires pour développer des tableaux de bord ou des fonctions dans l’EDS. Souhaitant utiliser un lexique juridique, définissez d’abord le “traitements» à partir duquel dériver les données. Cette démarche aurait également, à mon avis, facilité le dialogue avec le Garant qui est en cours et sur lequel je reviendrai ultérieurement.

Sur le plan architectural, la discussion avec les Régions est toujours en cours mais on peut dire que l’EDS sera très probablement “fédéré», c’est-à-dire composé de différents EDS régionaux. Le choix, en termes d’interopérabilité, s’est porté sur FHIR que de nombreuses régions envisagent également d’utiliser pour la persistance des données en créant des référentiels FHIR, un choix plutôt risqué et incorrect. Vous trouverez ici différents articles dans lesquels j’explique les raisons de cet avis.

Cependant, restant sur l’interopérabilité, le choix de FHIR que je partage pose la question de savoir comment fédérer les différents serveurs dans lesquels les informations patients (ressources dans le concept FHIR) seront disponibles. Au niveau du document, nous disposons de la technologie ebXML et de la présence de registres qui résolvent le problème. Que faut-il utiliser en cas de FHIR ? HL7 suggère trois chemins possibles :

Dans un environnement où les informations pertinentes peuvent être distribuées sur plusieurs serveurs, les systèmes clients auront besoin d’un mécanisme pour déterminer où se trouvent les données.
Il existe trois mécanismes principaux de détection :

• Configuration manuelle : les systèmes sont configurés manuellement pour pointer vers d’autres serveurs (pertinents) avec des indications sur les types de données résidant sur quel serveur, l’adresse du serveur, les informations d’authentification nécessaires, soit codées dans le logiciel, soit gérées via la configuration du système.
• Transversal : les systèmes clients doivent lancer des requêtes à partir d’un serveur unique qui gère les ressources « primaires » (par exemple, les rencontres, les rapports de diagnostic, les épisodes, etc. D’autres informations pertinentes, telles que les diagnostics, les observations, les conditions, les procédures, etc. sont récupérées par parcourir les références contenues dans les ressources primaires
• Registre : les systèmes clients découvrent l’ensemble « actuel » de serveurs pertinents en interrogeant un emplacement central pour les points de terminaison du serveur contenant des données pertinentes.

La première hypothèse n’est pas utilisable, la seconde est complexe étant donné le nombre élevé de ressources pouvant être associées à chaque patient, la troisième est plus réalisable mais pas triviale à mettre en œuvre également en raison des grands effectifs impliqués.

Pour en revenir à l’aspect vie privée, se pose le problème de la gestion du droit au black-out qui s’exprime aujourd’hui au niveau du document. Il est possible d’envisager de conserver ce paramètre puisque davantage de ressources FHIR seront extraites de chaque document, à condition toutefois de maintenir le lien document – ressources FHIR.

Reste alors une question centrale : quels services EDS devra-t-elle proposer ? Vous limiter aux données uniquement ou inclure des traitements ou des fonctions ? En d’autres termes, la « logique » fera-t-elle partie de l’EDS ou dépendra-t-elle des systèmes qui l’invoquent ? La réponse est complexe et j’essaierai de vous l’expliquer dans le prochain article.

1 – Continuer