Meetup Tech.Rocks

Comment héberger et faire communiquer nos logiciels médicaux entre eux ?

Meetup Tech.Rocks · 6 avril 2023 · 48 min · en français

Résumé

Replay du meetup virtuel Tech.Rocks du 6 avril 2023 : « Comment héberger et faire communiquer nos logiciels médicaux entre eux ? ». Les intervenants répondent aux grandes questions liées à la sécurisation des données de santé et partagent leurs conseils concrets et retours d'expérience : - Hébergement de données de santé (HDS) : état des lieux et bonnes pratiques pour se lancer. - Comment faire communiquer entre eux les différents logiciels médicaux ?

Summary

Replay of the Tech.Rocks virtual meetup of 6 April 2023: “How do we host our medical software and get it to communicate?” The speakers address key questions about securing health data and share practical advice and experience: - Certified health data hosting (HDS): the current landscape and best practices for getting started. - How to get different medical software systems to communicate with each other?

Thèmes : Cloud, infra & ops

Transcript complet

Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.

Bonjour à tous, donc oui effectivement avec Stan Quaken qui est CTO de Kiro, on va vous co-animer ce meet-up. On va parler de la santé, des enjeux de la santé. Vous savez tous que c'est un système qui est en pleine transformation, qui est un système qui est assez malade. On parle beaucoup des hôpitaux, etc. On sait que les US arrivent en force aussi derrière et on sait qu'il y a beaucoup, beaucoup... d'initiatives et d'applications qui sont lancées en France autour de ce sujet passionnant. On a beaucoup de valeur à créer en France autour de tout ça, donc c'est vraiment super. Toute cette énergie-là, ça fait beaucoup de temps de cerveau, etc. Et en fait, on va parler de deux sujets aujourd'hui pour améliorer Tout ce qui se passe en ce moment, l'hébergement de santé avec Stan, un autre Stan qui est de Padok, qui va nous expliquer comment gérer l'hébergement de données de santé. Mais on va commencer par Julie, qui est Head of Product chez Resilience et qui était avant ingénieure chez Lifone, qui va nous expliquer comment interconnecter tous les logiciels de santé entre eux, enfin tous, on va en parler de certains, et on va parler d'un cas concret autour de l'intégration de la télésurveillance dans les hôpitaux.

Et elle va nous expliquer pourquoi c'est compliqué et quelles solutions peuvent être mises en place. Voilà, Julie, je te laisse la parole. Ah oui, juste, n'hésitez pas à poser vos questions dans l'onglet Q&A pendant, et on sera votre porte-parole pendant cette session-là. Merci Jean-Marc. Je vais partager quelques slides. Et pour débuter, nickel. Alors, ce sujet-là, il est assez vaste et assez complexe. Effectivement, je vais parler de mon expérience chez Resilience et mon expérience passée aussi. Tout au long de mon parcours, je me suis vraiment spécialisée dans l'interop. Et j'ai créé, il y a quatre ans, le Meetup Fire. On parlera un peu de Fire dans cette présentation-là. Si vous avez des questions au long de la présentation, n'hésitez pas à les poser sur le chat, dans l'onglet Q&A. On prendra cinq minutes à la fin de la présentation pour y répondre. Donc, je vais présenter Resilience rapidement et vous expliquer pourquoi et quel choix on a fait autour de l'interop chez Resilience, pourquoi on a externalisé cette partie-là. Et puis, à la fin, je vous donnerai quelques billes pour aller plus loin par vous-même sur les sujets de l'interop.

Rapidement, Résilience, qui on est et qu'est-ce qu'on fait avec nos solutions? On a développé une solution qui est dédiée au suivi à distance et à l'accompagnement des patients et des patientes atteintes de cancer. Et notre solution, elle se divise en deux briques. Une brique dédiée aux soignants, qui leur permet de faire de la télésurveillance auprès des patients via des questionnaires et des alertes. Et une brique pour les patients, qui est en fait une application mobile qui va leur permettre de façon personnalisée d'avoir du contenu adapté tout au long de leur parcours. On a des vidéos, des podcasts, des programmes personnels. de soins. Et du coup, chez Resilience, on a un vrai enjeu à bien connaître le patient, à bien connaître son profil et ses caractéristiques cliniques pour mieux personnaliser l'expérience et cibler du contenu qui sera vraiment adapté au patient. Le premier point à savoir, c'est qu'en fait, nos solutions, elles fonctionnent sans interrompre. Et c'est le premier conseil que je donnerais à tout le monde pour assurer un déploiement rapide de sa solution dans la santé.

C'est de permettre d'avoir une solution qui fonctionne en standalone et qui permet des premiers usages sans interrompre. Bien sûr, dans les faits, sur le terrain, on a rapidement dû développer des connecteurs avec certains établissements, notamment pour sécuriser tout ce process de soins et sécuriser l'identité du patient. Côté technique, rapidement, on a... Ça, c'est pas bon. Excusez-moi. Je recommence là. On est un dispositif médical de classe 2A. Donc, on a une certification DM qui nous permet de déployer notre dispositif. On a bien sûr la collecte de données sécurisées chez des hébergeurs HDS, mais je laisserai Stan parler du sujet HDS par la suite. Et le sujet du jour, on a déployé deux flux de données avec nos établissements. On en a six live aujourd'hui, qui sont la capture d'identité patient et le retour des documents médicaux. On a fait le choix de passer par un prestataire technique externe pour déployer ces connecteurs.

Et justement, aujourd'hui, je vais vous parler de ce choix-là et pourquoi on l'a fait. Très rapidement, une petite démo de la partie Interop de résilience. En fait, je vous montre ici l'interface soignant. Et lorsque je vais pouvoir ajouter un patient au sein de mon télésuivi, il va tout simplement y avoir une barre de recherche ici. Alors, ça paraît simple, mais derrière, en fait, on va aller rechercher le patient au sein de l'établissement. Je me permets de t'interrompre. Je ne sais pas si tout le monde voit bien sur les écrans. Oui, merci. Oui, très bien comme ça. C'est mieux? Alors, c'est très zoomé, mais du coup, j'espère que ça marchera. Oui, ça c'est bien. Et donc, via une barre de recherche, je vais pouvoir aller rechercher un patient, soit par nom, soit par identifiant. Par exemple, ici, un patient qui s'appellerait Lothier Manon. Et donc, quand je vais sélectionner ce patient, ça va pré-remplir les champs d'identité du patient au sein du logiciel Résilience. Je vais avoir sa date de naissance.

Je vais aussi avoir, par exemple, ses identifiants de contact, son email, qui est assez important pour pouvoir le contacter dans le cadre du télésuivi. On voit ici qu'on pourrait aller encore plus loin, et c'est l'échantillon qu'on adresse actuellement chez Resilience, c'est de pouvoir récupérer, par exemple, sa pathologie. Quel est l'organe touché par ce patient-là au sein de l'établissement? C'est des chantiers qu'on lance et qui sont assez complexes à mener, mais on a attaqué cette partie-là. Si je reviens du coup sur la suite de notre démarche, donc on a décidé de ne pas développer ces connecteurs par nous-mêmes et de passer par l'iPhone pour le faire. Et en quelques mots, pour vous expliquer pourquoi on a fait ce choix-là, je vais essayer de vous... Faire toucher du doigt la complexité du système hospitalier et notamment son architecture. On a très rapidement des gros modules. On a le module de gestion administrative. des patients qui va être le maître des identités des patients au sein de l'établissement.

Et ensuite, des modules dédiés aux soins. Donc, le plus gros, c'est le dossier patient informatisé qui va recueillir toute l'info, mais aussi des modules dédiés. Donc, on va avoir les urgences, la radiologie, la pharmacie, la gestion des plateaux repas. Plein de solutions qui seront dédiées à des usages très précis. Et il faut savoir qu'au sein d'un établissement hospitalier, c'est assez fréquent d'avoir plusieurs centaines de logiciels qui vont discuter entre eux. Et donc, pour mettre en place tous ces flux, l'établissement utilise... Un logiciel dédié, qui s'appelle le AI, qui va être dédié au filtrage, au routage de ces flux au sein de l'établissement. Donc, un exemple tout bête, un patient arrive à l'admission d'un établissement, je vais créer ce patient-là au sein de l'admission, en vérifiant toutes ses informations d'identité, Et de façon automatique, au moment où le secrétariat d'admission va cliquer sur la création de ce patient-là, en temps réel, je vais avoir un petit message qui va être envoyé, par exemple,

au logiciel, à tous les logiciels de soins de l'établissement, par exemple, au logiciel de radiologie, qui va créer ce patient-là au sein de sa base. Ce qui fait que le patient, dix minutes après, quand il va aller faire sa radio avec un logiciel dédié, il sera créé dans la base, on aura son dossier, son identité et on pourra lui faire sa radiologie. Si vous êtes éditeur et que vous vous intéressez au sujet, normalement, du coup, vous devriez vous intégrer avec le AI et vous aussi envoyer ou recevoir des messages hospitaliers au sein de l'établissement. Un message de manière assez concrète, c'est un fichier texte. Alors, peut-être qu'on va creuser un peu ce slide-là qui n'est pas très digeste. Qu'est-ce que c'est? Je voulais vraiment vous montrer à quoi ça ressemble ici. En fait, c'est assez simple. C'est des segments de texte qui vont être mis à jour. Et ici, par exemple, c'est un message de préadmission d'un patient au sein d'un établissement.

Donc, on a Nathalie Desmaux. Qui va arriver, donc on sait que c'est son identifiant, parce que ça va être le segment patient identifier ici, qui va arriver au sein de l'établissement, et c'est le message qui va être envoyé à toutes les autres briques des logiciels. Très bien. Je ne sais pas si c'est le bon moment, mais on parle beaucoup de Fire depuis le début. C'est un sujet qui a ses clés dans l'interop. Ce que c'est, expliquer un peu, ou un petit démo. Oui, je vais en parler juste après. En fait, FIRE, c'est ça. FIRE, en fait, ça a vocation à remplacer tous ces standards-là, parce qu'aujourd'hui, il y a énormément de standards différents. Là, je vous en ai montré un, mais en fait, dans les faits, il y en a plein. Vous entendrez peut-être parler d'H-Prime, qui est un standard franco-français. Mais voilà, il y en a plein qui sont dédiés. Fire, il a vocation à simplifier et à remplacer ces standards-là pour créer des API standards au sein de la santé.

Donc ça, c'est dans les faits, le petit schéma que je vous ai montré. Voilà, je suis désolée, Jean-Marc, mais en effet, ça ressemble plutôt à ça. Ça peut être même beaucoup plus complexe. Là, c'est un schéma des flux hospitaliers. À la PHP. On n'a pas trop envie de s'y frotter. Non, on n'a pas envie de trop s'y frotter. Et c'est justement pour ça que chez Resilience, on est passé par un prestataire qui, du coup, répond et permet de passer outre toutes ces difficultés. Les projets sont longs, coûteux, les solutions sont fréquemment renouvelées. On a plein d'usages et de versions différentes. Par exemple, Resilience souhaite récupérer les événements des chimiothérapies. Selon les établissements, dans le champ label de l'événement, il y en a qui vont mettre le nom du protocole et il y en a qui vont mettre le numéro du cycle. Et donc, en fait, on va avoir des cas d'usage qui sont vraiment toujours différents. Le modèle est assez complexe, je vous l'ai montré. Il va falloir reconstruire un état du patient à propos de plein de messages différents.

Et il y a plein d'exceptions, des formats de téléphone qui ne vont pas être pareils. Pareil côté technique. Oui? C'est juste une question dans le chat général. Fire, c'est donc un concurrent de HomeHub. C'est Johan Kachurin qui pose la question. Ah, alors non, ce n'est pas un concurrent. Fire, j'ai des slides sur Fire, mais Fire, c'est un cas d'usage différent de OMOP. OMOP, c'est un standard qui est dédié à la recherche clinique. Donc, il va vraiment être dédié à la construction de gros... repository de data et de recherche précise sur un patient. FHIR, c'est plutôt un standard qui est dédié aux applications, aux applications de santé, aux API de santé. On a par exemple Apple Health Kit qui va aller se brancher sur les serveurs FHIR des établissements aux États-Unis. Donc, il y a vraiment deux cases d'usage différents, un pour la recherche et un pour l'applicatif et les API en santé. Et les deux sont mappés et il existe des ponts entre les deux standards.

Ça répond à ta question, Johan, j'espère. Vas-y, continue. Voilà. Et donc, juste pour finir sur l'iPhone, ils nous proposent une API unifiée Fire et ils vont avoir une seule API pour... Plusieurs centaines d'établissements en France. Et donc, nous, ça nous permet vraiment d'avoir un seul accès pour la connexion directe à tous ces flux. Du coup, je vous montre une petite démo sur Fire. Oui, avec plaisir. Tout à l'heure, vous avez vu la barre de recherche sur notre outil Resilience que je vous avais montré ici. En fait, cette recherche-là derrière, c'est tout simplement un appel. Donc, si j'avais tapé maintenant ici, c'est un appel à un endpoint fire qui va être appelé au niveau de l'IFUN. Je vais vous montrer sur Postman à quoi ça ressemble. Est-ce que c'est assez gros?

On voit à peu près? Moi, je pense que c'est assez gros. Ça va? Dites les autres sur le chat si ça ne va pas. J'ai déjà zoomé. Après, on ne voit plus rien si je zoome plus. Donc, je vais faire un appel, en fait, sur un endpoint unique. Par exemple, ici, sur ma ressource patient. Donc, dans Fire, on parle de ressources. C'est tous les objets, comme les briques de Lego, un peu, qui vont structurer tout le parcours de soins. Et donc, je vais pouvoir faire une recherche sur des noms, sur des identifiants. Donc ici, par exemple, je vais faire ma recherche sur le champ Manon et je vais avoir mon résultat qui est aussi sous la forme d'une ressource et qui va contenir ma ressource passant ici. Donc, on va l'ouvrir. En grand pour voir ce qu'il y a. J'ai dans mon objet patient ici, Peut-être que je peux agrandir encore plus. Ça va, je pense. Je vais avoir des identifiants. Je vais avoir, bien sûr, les champs noms. Et on voit que cette structuration, en fait, elle est vraiment structurée d'une certaine manière.

Et l'idée de FIRE, c'est que tous les API dans le monde proposent leur structuration et leur objet de données sous le même format. Alors, bien sûr, il n'y aura pas toujours les mêmes champs. On va spécifier certains champs selon des cas d'usage. Mais le format global sera le même. Et ça va permettre vraiment d'avoir des déploiements d'applications qui sont beaucoup plus rapides. Donc voilà, ici par exemple, j'ai le numéro de téléphone de mon patient et je sais qu'il sera toujours structuré de la même façon, contrairement au message de Julie. ancien qui n'était pas toujours... Voilà. On a quelques questions. Je peux t'interrompre? Oui, bien sûr, bien sûr. Il y a des questions qui commencent à popper un peu. Il y a Stan Cocken qui dit, du coup, le fait de passer par un prestataire à l'IPN pour gérer votre interop, est-ce que les hôpitaux sont frileux à ne pas juste envoyer leurs données à vous, mais à un prestataire, passer par quelqu'un pour gérer les données? Alors, ça arrive, on a eu quelques freins avec les gros CH notamment, mais aujourd'hui, L'IFUN a quand même déployé sa solution dans plus de 500 établissements.

Donc, on a, je vais reprendre mes slides, on a du coup, on a beaucoup plus de oui que de non. Voilà, déjà. Et de deux, s'il n'y a pas l'IFUN, il y aura quand même la possibilité d'avoir des API, des API FIRE qui seront standardisées. Par exemple, au prochain meet-up FIRE, le 27 avril, on va présenter l'API du Chut Toulouse qui est en train d'être développée au format FIRE. Donc, l'idée, la vision globale, c'est que chaque établissement ait son API toute prête et qu'on puisse s'y pluguer. En tout cas, nous, on a décidé de passer par ce standard-là. Et après, si ce n'est pas l'IFUN, ça peut être d'autres API qui sont développées soit par le DPI lui-même, soit par l'EAI. Innovacom, par exemple, commence à développer certaines API en FIRE. Et donc, voilà. Mais on a beaucoup plus de oui que de non, et ça se passe quand même assez bien, parce que l'IFUN dispose de toutes les sécurités et les réglementations actuelles. Et deux questions rapidement. Est-ce que l'IFUN conserve les données ou pas?

Oui, ils conservent les données, mais par contre, via toute leur réglementation RGPD, l'usage est dédié à Resilience et ils n'ont aucun droit de le diffuser à d'autres éditeurs. C'est vraiment un prestataire et le contrat est entre Resilience et l'IFUN. Donc, ils ont un engagement de confidentialité sur ce point-là. Ok, on a... On a deux questions, mais je propose d'avancer un petit peu sur Tesla. Je ne sais pas s'il en reste beaucoup, mais il nous reste 10 minutes. Non, c'est quasiment la fin. On pose la question à la fin, peut-être. Pour revenir sur Fire, parce que je suis passée vite, il faut savoir que c'est un standard qui existe depuis 2005, qui est maintenant dans sa version 5. C'est une version qui est normative, donc ça veut dire qu'on a des engagements de non-régression sur les modèles. Et on a énormément d'éditeurs majeurs internationaux qui sont impliqués, qui financent même. La Google Foundation, par exemple, finance énormément Fire. On a Amazon, on a Apple qui est derrière, Microsoft.

Donc, il y a vraiment maintenant une confiance énorme dans ce standard-là. Et c'est pour ça que c'est important de le connaître si vous bossez dans la santé, et surtout dans la tech, dans la santé. C'est indispensable. L'autre piste aussi que je voulais mettre en avant aujourd'hui, c'est que c'est intéressant d'utiliser comme une boîte à outils. À minima pour s'inspirer des hommages de la modélisation. Et donc, très rapidement, je voulais vous montrer la doc. Donc, par exemple, ça, c'est... On n'aura pas le temps, Julie, de voir toute la doc. Ah, pardon. OK. Non, non, mais tu m'as dit qu'il reste 10 minutes. J'ai fini mes slides. Voyons, pendant 10 minutes, toute la doc, fire. Non, je ne vais pas vous montrer la doc, mais justement sa structure pour vous montrer qu'elle est accessible à tous et qu'il ne faut pas avoir peur de rentrer dedans. Si on rentre dans la ressource patient, par exemple, on va avoir des définitions. C'est ça qui est super intéressant, c'est qu'en fait, Ce n'est pas juste de l'aspect technique, c'est aussi une explication de comment on utilise les objets dans son contexte. Et ça permet d'uniformiser tous les usages dans le monde.

Et après, j'ai cette fameuse structure de données qui peut être ultra utile dans la tech pour construire vos API parce que vous n'allez pas réinventer la roue et vous baser sur de l'existant. Et donc, je mouvement le patient, mais il y a en fait beaucoup, beaucoup de cas d'usage qui existent déjà. Donc sur la bio, les médicaments, je ne vais pas rentrer dans les détails, mais vous avez énormément de choses qui existent. Chacun va aller voir un peu. Il y a deux questions. Oui, c'est fini. Non, mais j'ai mon résumé et pour aller plus loin. Tu pourrais redire cette slide-là juste à la fin. On va prendre les deux questions rapidement. Je pense qu'il y en a une sur la légitime, sur tout ce qui est sécurité de données, accès, qui a le droit de voir quoi, etc. La question d'Adrien Garnier, c'est« Bonjour, vous parlez d'API et notamment d'envoi de données à l'étranger. Comment vous assurez-vous que les données de santé françaises ne soient pas envoyées en dehors du territoire? Alors, nous, Résilience, on est hébergé sur des hébergeurs HDS qui sont en France, avec notamment OVH qui est utilisé en France.

Donc ça, c'est un engagement de notre part et de la part des hébergeurs. Voilà, je pense que ça répond à la question. De toute façon, après, il y aura une presse dédiée. En fait, on a… Voilà, c'est ça. On a… Oui, exactement. On pourra poser la question à ce moment-là. On complétera le données, mais on a un engagement de nos hébergeurs qui s'engagent à avoir les données hébergées en France. Après, une autre question, j'ai du mal à voir le sens, peut-être que Johan pourra peut-être préciser. Johan Katchurin, c'est donc Resilience est une application sur le store d'Olyphon? Non, alors, est-ce qu'il y a un store Leafun? C'est une bonne question. On fait partie de l'écosystème des applications Leafun. Voilà, mais il y a le store, je ne sais pas. Le store, il est dédié plutôt aux applications, il me semble, médecins. Mais je ne connais pas bien cette partie-là. Ok. Je ne préfère pas dire de bêtises. Oui. Quelle est votre expérience sur les différences entre Fire V3, V4 et V5?

De Benoît. Ouh là là! Oui, alors il y a plein de différences. Il a vraiment évolué pas mal le standard. Je ne vais pas rentrer dans le détail. La plupart du temps, en fait, c'est des nouveaux champs ou des nouvelles ressources qui sont créées. Et par contre, toutes les différences sont dispo sur la spec fire. En fait, quand je suis sur patient ici, je vais pouvoir aller voir R4 diff, par exemple. Je vais aller voir les modifs entre R5 et R4. Et je vais avoir le mapping entre les deux pour pouvoir passer. Donc, par exemple, ici, entre R4 et R5, ils ont changé la cardinalité sur le champ langage. Donc, ça va être des petits détails la plupart du temps. Voilà, il arrive aussi que dans une nouvelle version, il y a des nouvelles ressources qui sont à publier. Très bien, super. Est-ce qu'il y a d'autres questions avant qu'on passe à la dernière slide où tu peux faire ta conclusion justement? Non, ça a l'air d'aller. Je te laisse conclure sur la partie interop. Super. Pour résumer, les quatre conseils que je donnerais à tout le monde qui se lance dans l'interop en santé, c'est le premier, c'est vraiment que ce ne soit pas bloquant pour le déploiement de votre produit, pour avoir vraiment un déploiement rapide au début, parce que

quoi qu'il arrive, vous allez avoir... plusieurs mois d'intégration sur cette partie-là. Ne pas réinventer la roue sur l'interop et de se concentrer sur ce que vous faites, votre produit, et pas commencer à développer des choses spécifiques. Ne pas sous-estimer la complexité de l'interop. On peut penser qu'une fois, c'est facile, mais une fois qu'on le déploie à grande échelle, c'est vraiment très complexe à maintenir. Et puis, ne pas oublier Fire. Pour structurer toutes vos API en santé, comme l'a fait Nabla aussi, qui viendra présenter au prochain meet-up. C'est vraiment une boîte à outils qui est super utile pour construire sa tech dans la santé et intégrer l'interopérabilité un peu by design dès le début. Voilà. Et pour aller plus loin, je vais rester disponible après ce meet-up sur les tables de Rimo pour discuter avec vous si vous le souhaitez. On va vous partager le lien du prochain meet-up. Il y a un Slack aussi qui est disponible pour vraiment venir rencontrer spécifiquement des experts sur FIRE.

Il y a un événement dédié à FIRE en juin à Amsterdam qui est super bien pour les débutants, pour monter en compétence rapidement sur le sujet. Et sur le site des Dev Days, il y a toutes les vidéos des anciens événements avec plusieurs centaines de vidéos d'intro, des ateliers, des tutoriels qui permettent de monter en compétence assez rapidement. Il y a une association en France qui s'appelle... Interop Santé, avec plein de ressources sur l'interopérabilité en France, notamment un guide qui s'appelle l'Atlas du SIH, qui a plus de 200 pages, qui explique vraiment les flux hospitaliers et comment s'intégrer au sein d'un établissement. Et le site de référence d'HL7, qui contient des Getting Started dédiés aux techs, aux business, qui sont vraiment assez bien expliqués. Et enfin, un chat international sur FIRE qui permet d'échanger avec tous les grands experts mondiaux sur le sujet. Ils sont ultra réactifs, ils sont tout le temps connectés dessus. Et vous allez un peu toucher du doigt la communauté grâce à ça, sur ce chat-là, qui est totalement ouvert et gratuit à tous.

Très bien. Maintenant, vous savez tout sur Interop et Fire, quasiment, enfin en tout cas, tout pour se lancer dans ce monde-là. On voit que c'est une grosse communauté qui est déjà bien active et il y a plein de choses autour de ça. Merci Julie beaucoup pour la présentation. Maintenant, on va parler des petits sujets dont tu as parlé pendant ta présentation. C'est l'hébergement des données de santé. On sait que c'est quelque chose de très sensible et on sait qu'en France, on fait attention à ça. On met parfois du temps à mettre en place les choses, mais quand on le fait, on le fait bien. Normalement, j'ai invité Stan Girard à venir sur scène. Merci Stan. Bonjour Stan. Un deuxième Stan. Bonjour. Voilà, je te laisse la parole. Tu vas nous parler hébergement de données santé. Et puis j'interagirai comme d'habitude à poser des questions, à être votre porte-parole pour ceux qui m'aident des questions. Dans l'onglet Q&A. Et de toute façon, on peut se parler en live à la fin sur les tables dédiées, comme disait Julie. À toi, Stanislas. Merci beaucoup Jean-Marc pour l'introduction. De toute façon, rapidement, je travaille chez Padok en tant qu'engineering manager et j'ai aidé à construire l'offre HDS et à faire certifier Padok.

Et du coup, aujourd'hui, je vais vous aider à essayer de comprendre comment héberger des données de santé. Vous êtes peut-être dans ce cas-là où vous avez besoin d'héberger des données de santé ou vous êtes dans le milieu de la santé. et vous poser la question de qu'est-ce que HDS ? Donc la première raison de pourquoi est-ce qu'on veut protéger la donnée de santé, c'est tout simplement, c'est la loi. Du coup, la certification HDS est là pour être en conformité légale. Il y a un deuxième point, et j'en reviendrai juste un petit peu après. La norme HDS permet de mettre en place une couche de sécurité et de protéger la donnée. Ce n'est pas juste quelque chose où il faut être conforme, c'est également quelque chose qui peut vous aider à mettre en place, et c'est ce que je reviens dans le troisième point, mais toute une couche de sécurité, d'opérabilité, de vraiment venir sécuriser, mettre en place des bonnes pratiques sur la donnée. Du coup, il faut voir ça plutôt comme un guide de bonne pratique pour protéger les données.

Et également auprès de vos clients, ça peut être vu comme un gage de qualité. Dans certains cas, vous allez voir, vous n'avez pas le choix. Mais le fait de travailler avec des opérateurs qui sont certifiés HDS vous permet de plus facilement gagner du business. Du coup, si vous avez des questions tout au long de la présentation, n'hésitez vraiment pas. J'essaie de faire ça le plus interactif possible. Je vais rentrer un peu dans le détail de qu'est-ce que c'est que la norme HDS et on va commencer par la base. La norme HDS est une surcouche de la norme 27001. La norme 27001 est une norme système de sécurité, système d'information, sécurité du système d'information. Du coup, pour être certifié HDS, il faut être également certifié 27 000. Du coup, là, j'ai mis un petit lien vers un article que j'ai écrit. Je me servirai tout du long de la présentation. C'est un article sur le bug de Padog.

Il y a le QR code juste ici. N'hésitez pas parce que je vais m'en servir un peu pour... Il y a des images, mais dans l'article, il y a un peu de texte qui rentre dans le détail. C'est un excellent article et on le trouve très facilement. C'est un des premiers articles pop quand tu cherches c'est quoi le HDS. Je vous conseille à tous d'aller jeter un oeil. Mais du coup, si jamais vous avez des questions, n'hésitez vraiment pas à aller regarder dessus, il y a le QR code. Sinon, tu as fait comprendre HDS, lien de Padok, normalement dans les 5 premiers résultats, j'espère que je suis dedans. Mais du coup, voilà. Donc, HDS, c'est une surcouche. Et du coup, en fait, qu'est-ce qui se passe? C'est que la norme 27001 et HDS, il y a des législations qu'on doit suivre. Et du coup, elles imposent des requirements. Donc, ces requirements-là, c'est des requirements qui sont techniques, tout comme des requirements qui sont légaux. c'est-à-dire avoir un process pour les utilisateurs quand ils demandent le retrait d'ordonnées. Et du coup, ça demande à avoir plein de process en interne qui existent.

Du coup, voilà. La grande question que beaucoup de gens se posent, et je m'en souviens beaucoup, les QR codes, du coup, les... Il y a un QR code qui va sur le site de l'État. Donc, e-santé.gouv. Et si vous regardez la question 2, il y a le détail de qui est concerné. Mais du coup, si on revient à la présentation, Aujourd'hui, vous êtes concerné si vous êtes dans les activités de diagnostic de soins ou de suivi social et médico-social, sauf si vous êtes une association sportive qui a des sportifs handicapés chez vous. Vous vous hébergez de la donnée de santé, mais malgré tout, ce n'est pas à des fins de diagnostic, de soins, etc. Mais vous êtes techniquement obligé d'avoir la certification HDS à partir du moment où vous utilisez la donnée de santé qui, à un moment, sera utilisée à des fins de prévention, de diagnostic, de soins ou de suivi. Social ou médico-social.

Du coup, c'est très large. Et du coup, par exemple, j'ai rencontré des entreprises qui m'avaient creusé. Si je fais de la recherche pour créer des algorithmes et que plus tard, mes algorithmes seront peut-être utilisés pour la santé, est-ce que j'ai besoin d'être certifié? Dans ce cas-là, c'est des sujets où c'est un peu compliqué parce que la donnée n'est pas aujourd'hui utilisée pour faire du diagnostic, mais le modèle de data sera utilisé lui pour... Mais dans tous les cas... Ça, il faut demander l'avis à quelqu'un qui... dans le réglementaire qui permet de trancher un petit peu. C'est juste sujet là parce que c'est un sujet très délicat et selon ce qu'on veut faire, il faut demander conseil à des gens qui ont ce métier. Voilà, exactement. Du coup, en général, il faut aller regarder le petit lien que vous a envoyé. Donc avec ce document-là, on creuse, on regarde les législations en détail. On demande conseil à d'autres dans la communauté Tech.Rocks, on peut aussi demander des conseils. Il y en a beaucoup qui ont déjà lu ce document-là et qui le maîtrisent plus ou moins.

Exactement. Et du coup, maintenant, Si vous dites, je suis concerné ou je ne suis pas concerné, on va partir du fait que vous êtes concerné là-dedans. Du coup, c'est quoi la certification HDS? Quand on parle de certification HDS, vous entendez souvent parler, ou peut-être pas, des niveaux de la certification. Donc, il y a six niveaux. Là, c'est les niveaux qui sont présentés sur le site du gouvernement. Et du coup, il y a deux parties. La partie prestations et bergers en infrastructure physique, donc ça c'est celle qui... Dont les cloud providers sont en général responsables. Par exemple, AWS, OVA, HCO, Scaleway, Google, GCP, Azure sont certifiés niveau 1 et 2. Parce que c'est tout ce qui touche à l'infrastructure, l'accès à l'infrastructure. Et les niveaux 3, 4, 5 et 6, c'est des infogérants. C'est ceux qui font les prestations, la cybersécurité, l'audit, la vérification des backups. Et donc, cela, ça touche plus une couche métier, logiciel.

Donc, c'est des entités comme Padok, Clarinet, Corail et autres qui sont certifiées sur ces niveaux-là. Du coup, un petit schéma ici pour vous expliquer. Niveau 1 et 2, ce n'est pas une suite, c'est pour être certifié HDS, il faut avoir des prestataires ou être soi-même certifié sur l'intégrité des niveaux. Par exemple, demain, vous utilisez AWS. AWS est certifié niveau 1, 2. 3, 4, 5 et 6. Mais 5, ils ne fournissent pas le service. Donc, vous êtes obligé de passer par quelqu'un qui va vous certifier le niveau 5. Ça peut être vous. Ça peut être également quelqu'un d'externe. Du coup, petit lien avec QR Code encore, parce que ça marche bien, pour savoir qui est certifié. Je vous parlais de la WS juste avant. Du coup, si vous allez sur le lien, vous allez encore sur le site du gouvernement. Et là, on peut voir qu'il y a un site qui recense tous les hébergeurs certifiés. Que ce soit niveau 1, 2, 3, 4, 5, 6, vous pouvez voir si vous avez besoin de main de travail avec une entreprise, vous pouvez vérifier.

Quels sont les niveaux sur lesquels elle est certifiée. Si on prend Amazon, ce sont des cas qui sont très intéressants à Amazon, et les cloud providers en général. Les cloud providers sont certifiés sur, en général, tous les sujets 1, 2, 3, 4, 5, 6, tous les niveaux HDS. Par contre, Ils sont cependant certifiés sur ces niveaux-là, mais ils ne font pas de service sur certains niveaux. Amazon, par exemple, en fonction de ses outils, est certifié 1, 2, 3, 4 et 6. Mais ne fournit pas le service numéro 5, qui est là l'infogérance, qui est le fait d'avoir quelqu'un qui va venir réparer l'applicatif si jamais ça tombe. Donc en interne, ils ont eux les procédures, ils ont fait certifier leurs procédures en interne et leurs équipes parce qu'ils ont des services en interne où ils ont de l'infogérance. Ils ne proposent pas. Ce service-là. Donc, ça veut dire que demain, si vous allez sur Amazon, il faut faire attention et regarder l'offre de service d'Amazon pour vérifier

ou sur le prestataire sur lequel vous allez, qu'il est bien certifié et qu'il vous propose bien tous les niveaux de certification. Ou sinon compléter par exemple là si on regarde ok je suis sur Amazon on va prendre par exemple Happy SemSar je ne connais pas, ils sont certifiés 3, 4, 5 c'est à dire que potentiellement Vous pouvez faire appel à cette entreprise-là, si ça a encore une sorte de service, pour vous certifier. Nous, chez Padok, par exemple, on est certifié 3, 4, 5, 6. Pourquoi pas 1 et 2? Parce que si on regarde à nouveau ce petit schéma, alors je vais vous présenter cet onglet-là, 1 et 2, en fait, on se base sur Amazon. 3, 4, 6, Amazon l'a également, et fournir ce service-là, mais nous on en complément. Et 5, donc là l'infogérance, c'est-à-dire qu'on va venir intervenir, nous on est certifié là-dessus également. Et du coup là on va permettre à quelqu'un comme une entreprise, un groupe pharmaceutique, ou de l'AFN ou des résidences, d'être certifiés s'ils hébergent de la donnée de santé sur l'intégralité des niveaux.

Voilà, du coup, c'est un conseil que je vous donne. Faites attention quand vous avez un hébergeur, vous allez sur le cloud, de vérifier que malgré le fait qu'il soit certifié sur l'intégralité des niveaux, et je parle d'OVH par exemple, qui est potentiellement certifié, sur l'intégralité des niveaux, mais qui ne propose pas des services sur le niveau 5. Du coup, vous ne dites pas, OK, AWS, OVH, son certificat HDS, c'est-à-dire que je peux y aller sans problème. Non. C'est un point d'attente. Ce serait quoi le meilleur moyen de se l'assurer quand on n'est pas encore à l'aise là-dessus? Comment on peut être sûr qu'on va dans la bonne direction? Tout simplement, en fait, il faut demander au site, enfin au vendeur, OK, le service, la prestation, Vous nous vendez la certification sur quel niveau? 1, 2, 3, 4, 5? Juste demandez à ce que vous couvrez l'intégralité des 6 niveaux de la norme HDS. Et le mettre à l'écrit ou autre, comme ça vous vous déchargez de cette responsabilité, de cette...

Si vous n'êtes pas... Vous ne connaissez pas très bien ça, juste demandez-moi, demandez à votre interlocuteur quels sont les niveaux sur lesquels vous nous certifiez aujourd'hui. Voilà. Et du coup, important, c'est aujourd'hui comment vous certifiez HDS. Donc, s'il n'y a pas de questions sur la partie les niveaux, je vais vous expliquer rapidement comment certifier HDS. Parce que dans votre cas, ça peut être intéressant. A savoir, je vous ai expliqué la norme HDS, c'est 27 000 avec une surcouche HDS, c'est du législatif. En général, ça prend un à deux ans et par-dessus, il y a un audit par un organisme externe qui est fait. Chez Padok, nous, on a été audité par BSI. Donc, il y a un grand cabinet d'audit. Et je crois qu'au CLAS aussi, vous avez été audité pour la norme 13485. C'est ça. Par BSC Group. Du coup, en général, ça prend un à deux ans parce qu'il faut passer la norme 27001. C'est-à-dire qu'il faut écrire beaucoup de standards, il faut mettre en place beaucoup de procédures.

Et après, par-dessus, il faut mettre en place une réglementation HDS. Si vous voulez plus de détails là-dessus, j'ai mis le lien. Donc, en gros, QR Code, c'est un talk que j'ai fait avec le club ISO 27001 de Lyon sur comment Padok a fait pour être certifié HDS. Donc, il y a toutes les bonnes pratiques, plein de tips qui vous expliquent comment est-ce que Padok a fait pour être certifié en six mois, quelles ont été les difficultés qu'on a rencontrées. Qu'est-ce qu'on a dû faire? À qui on a fait appel? Oui, Jean-Marc? Non, juste quand je regarde la question de Stan, de Stan Cocon, pardon, ça ressemble un peu à ma question, mais peut-être un petit complément. C'est pourtant AWS sur le site du gouvernement, 10 qui sont certifiés, c'est dur de voir si ça nous couvre ou non. On doit lire le contrat à chaque fois pour chacun? C'est tout vrai, c'est comment on peut se faire aider là-dessus. Là, on est néophyte, on vote HDS, on voit que c'est plus le bazar qu'on pensait. C'est quoi le meilleur moyen d'être sûr?

Demandez, demandez et écrivez ça contractuellement. Dans le contrat, c'est écrit certifié HDS niveau 1, 2, 3, 4, 5, 6. Et si la personne derrière, elle vous ment, si jamais vous vous faites attaquer derrière ou autre, vous faites appel à quelqu'un de la communauté qui connaît un peu tout ça. Si vous m'envoyez un petit message sur Tech.Rocks, sur le Slack, c'est avec plaisir que j'irai regarder, je regarderai l'offre et je vous dirai. Du coup, vraiment, n'hésitez pas à demander à l'écrire dans le contrat, en fait. Partir du principe que les gens ne sont pas forcément malhonnêtes et qu'ils vous diront la vérité, mais dans le cas où ils le sont, Ça vous permettra de vous protéger un petit peu. Ça, ça nous permet de nous sensibiliser là-dessus déjà, de savoir qu'on ne sait pas et qu'il va falloir être vigilant. Exactement. Du coup, voilà. En général, la difficulté, ça prend longtemps à être certifié HDS parce qu'il y a beaucoup de processus à mettre en place, de process à mettre en place, de standards. Il faut créer des choses, plein de trucs en interne.

La facilité qu'on a eue, nous, avec Padok, c'est qu'on fait partie du groupe Théodo, qui est déjà existant depuis 10 ans, qui avait beaucoup de process déjà existants, et du coup, on s'est beaucoup basé là-dessus. Et c'est une des raisons pourquoi est-ce qu'on a mis que 6 mois, parce que nous, on a lancé l'objectif d'être certifié. On a mis que 6 mois. Après, on a investi, ça nous a coûté entre 100 et 200 000 euros, parce que c'est difficile à chiffrer. Et c'est aussi quelque chose qui est récurrent tous les ans, parce qu'on doit se faire... On a des audits de surveillance tous les ans. Voilà. Du coup, c'est quelque chose à prendre en compte, mais j'y réponds vraiment en détail si vous voulez, comment faire, si jamais c'est quelque chose qui vous intéresse là-dedans, à savoir, c'est que ça coûte du temps et de l'argent. Voilà. Et donc, c'est qu'il y a aussi des ressources à investir et à maintenir parce que ce n'est pas juste un one-shot, c'est quelque chose qu'il faut continuer et la norme HDS, même si elle n'évolue pas régulièrement, elle évolue cette année, donc il va y avoir des petits changements. Donc HDS, comment être conforme? Là, moi, je vous présente rapidement, si vous faites appel à un prestataire, qu'en général,

Si vous n'êtes pas certifié HDS, vous ne partez pas sur ce point-là, vous pouvez avoir un prestataire externe qui vous certifie en conformité HDS. Et du coup, là, nous, chez PADOC, ce qu'on a fait, on a créé un framework qui s'appelle Yamas. Donc, pour les Grecs, chez vous, ça veut dire« stenter» en grec. Enfin les grecs dans l'audience, et du coup en fait c'est une liste de 60 critères, donc on a pris la norme, on a défini des critères, et du coup il y a des grandes parties dans la norme HDS qui sont la donnée, la sécurité, le chiffrement, auditabilité. J'y reviendrai juste après pour vous présenter un peu. Là, c'est un exemple d'infrastructure HDS sur AWS. Donc, c'est un peu technique, mais c'est juste pour vous montrer que, déjà, premier point, cette infrastructure, elle est certifiée HDS, mais la donnée n'est pas stockée en France. Elle est stockée en Irlande. Elle utilise les services managés d'AWS, donc les Lambda. Les bases de données, les dynamos. Il y a deux comptes AWS, donc un compte avec des data scientists qui se connectent et un autre compte avec des patients.

Donc, on a une ségrégation malgré tout des utilisations. Il y a une partie qui est plutôt applicative, qui est liée à la récupération de la donnée santé. Et si on regarde ici, là, on a les data scientists qui viennent accéder à la donnée qui a été générée par les patients. Et du coup, pour répondre tout à l'heure, la donnée n'est pas forcément en France avec HDS, avec la norme HDS actuelle, l'évolution qui vient potentiellement chambouler un peu les choses, mais qui va imposer plus ou moins un cadre en Europe. Là, cette infrastructure-là, elle est HDS et elle est en Europe. Voilà, elle en est en. Du coup, ne vous dites pas qu'en général, on ne sait pas trop pourquoi il faut être stocké la donnée en France. On entend souvent parler de souveraineté numérique. Mais la norme HDS n'impose pas d'être stockée en France pour... Elle certifie HDS. Du coup, voilà. Vous pouvez partir sur Amazon, sur Amazon, GCP, Azure, OVH.

Ce qu'elle n'est pas encore HDS. Ils le seront bientôt, je pense. En tout cas, selon notre auditeur, ils le seront bientôt. Du coup, voilà. Vous pouvez partir sur ces quelques providers-là. Regardez, si vous partez sur Amazon, ils n'ont pas toutes les régions qui sont en HDS. Ils ont été certifiés sur un certain nombre de régions. Je connais bien Amazon, mais également sur Azure. Et si vous tapez, oui. Il nous reste trois minutes. Je ne sais pas s'il y a beaucoup de choses, mais il y a une question. Je t'interromps rapidement dessus. C'est un client, c'est Benoît qui demande. Un client nous a demandé d'être ISO 27001. Nous sommes en HDS et donc notre hébergeur est 27001. Mais évidemment, pas nous directement. Est-ce que ça a du sens de s'imposer ces contraintes? En fait, si vous êtes certifié HDS par votre ingénieur, c'est-à-dire qu'il met en place les bonnes pratiques qui sont liées à HDS, mais également 27001. Vous n'avez pas forcément un PRA ou un PCR en place, mais il s'assure que l'infrastructure qui a été déployée sur le cloud, ou chez vous ou chez eux, respecte les critères 27001 et HDS.

Vous n'avez pas forcément besoin d'être certifié 27 000. Pas pour ça en tout cas. Ils ont peut-être besoin pour d'autres choses qu'il faut croiser, mais peut-être pas pour ça. Exactement. Et une deuxième question rapidement. Pardon, tu avais fini ou tu veux compléter? J'avais presque fini, il restait… Non, mais la question, après, oui. Ah, la question, oui. La question, c'était… Enfin, pour moi, il y a des… Dans une deuxième, pardon, c'était Adrien Garnier qui demande, étant donné que vous utilisez des services tiers pour la fourniture des infrastructures, comment arrivez-vous à auditer vos fournisseurs, exemple AWS? Je ne les ai pas. Je fais confiance à des entreprises qui ont été certifiées. Du coup, je retourne sur le site ici et je vais regarder AWS, Amazon, ils sont certifiés en 2, 3, 4, 5, 6. Si je vais regarder Google Cloud, Google, Comment il s'appelle déjà? LSC, la plateforme, ils sont 1, 2, 3, 4, 5, 6. Workspace également, 1, 2, 3, 4, 5, 6.

Du coup, voilà, je me base sur le site de la santé du gouvernement qui me donne cette information. Vas-y, tu peux continuer. Il n'y a plus trop d'autres questions pour l'instant. Et du coup, si jamais vous avez des questions, si jamais vous voulez quelque chose, je vous ai mis un QR code ici, ou encore un. Donc, c'est le framework Yamas qu'on a mis en place chez Paloc. Pour quand on vient chez un client, pour auditer l'infrastructure et s'assurer qu'il y ait tout qui soit présent pour que nous, on puisse certifier la conformité du client. Du coup, c'est quelque chose qu'on a ingénieré chez Padok. Les liens, là, malheureusement, ne marchent pas parce que c'est des liens vers le motion interne. Mais au moins, vous avez une liste qui vous permet de savoir si vous êtes plus ou moins loin. vis-à-vis des critères de PADOC. C'est-à-dire à savoir, c'est, ou d'un critère qui pourrait être potentiellement d'un infogéreur autre que BADOC, à savoir ce que, comme j'ai répondu tout à l'heure, Il y a certains critères que nous, on a en interne, parce qu'on est certifié 27 000 ans, et qui ne sont pas présentés là-dedans.

Donc ça, c'est que les choses qui sont nécessaires. Que vous allez devoir faire, mettre en place, si jamais vous avez besoin d'être infogéré. Ça ne veut pas dire que si vous faites ça, vous serez certifié HDS si vous choisissez de passer la certification. C'est les critères qu'un infogéreur demande pour vous... Certifie en conformité par rapport à ses critères à lui et son interprétation. Du coup, voilà. Ça peut vous aider à identifier des chantiers sur lesquels vous n'êtes pas forcément en adéquation aujourd'hui, que vous avez sûrement quelque chose à travailler. Du coup, le lien de QR code, il est ici. Je vous invite à scanner si vous avez envie. C'est un peu l'interprétation de Padok, de la norme HDS qu'on a eue et qui nous permet d'auditer nos clients. Top. Est-ce que c'était ta dernière slide? Oui. Trop bien. Merci beaucoup, Stan. Julie, si tu peux remonter rapidement sur scène, il y avait une dernière question, on peut en parler après, mais tant qu'à faire, tant qu'on est là.

Il y avait une dernière question sur les meetups FIRE, savoir si c'était en webinar ou en présentiel. Oui, je partage tous les liens. Il y a eu certains meetups en présentiel. Et je vais aussi vous partager la chaîne YouTube avec certaines meetups qu'on a pu capter en vidéo. Et vous pouvez regarder les vidéos. Voilà. Très bien, merci beaucoup. A priori, il n'y a pas d'autres questions, mais de toute façon, vous pouvez continuer à chatter, à parler sur... sur les tables. Juste pour, si vous avez un petit mot de fin, en fait ce qu'on a retenu c'est l'interop, il ne faut pas forcément y aller tout seul, c'est peut-être plus clair pour vous, mais c'est un vrai investissement, est-ce qu'on achète ou est-ce qu'on construit. Le HDS c'est un peu pareil, donc maintenant vous êtes tous sensibilisés à ça, vous connaissez un peu Fire, etc. On peut faire plein de jeux de mots chouettes avec Fire, donc ça c'est super aussi. N'oubliez pas les Fire Days, on va parler de Julie. On a un channel Slack aussi qui est dédié à tout ce qui est santé sur Tech.Rocks, dont la plupart d'entre vous y sont peut-être déjà, c'est tech-in-else.

On vous remettra ça si Amélie ou quelqu'un peut le mettre dans le chat, c'est peut-être pas mal. Et voilà, donc ce meet-up sera dispo en replay. Je ne sais pas dans combien de temps, peut-être que vous pouvez le mettre dans le chat aussi, avec Rox, je n'ai pas les dates, mais il sera disponible en replay de toute façon. Vous avez accès à toutes les docs. Je pense qu'on a fini. Est-ce que l'un des présentateurs, Stan, tu veux rajouter quelque chose? Les deux Stan ou Julie, pour finir, est-ce que vous avez oublié quelque chose que vous voulez rajouter avant qu'on se quitte? Moi, c'est juste, n'hésitez pas à utiliser la norme HDF pour vous aider à construire des belles choses et pas comme un frein à l'innovation. Très bien. Merci à tout le monde. Merci Julie, Stan. Et on se retrouve sur les tables thématisées sur l'application RIMO pour ceux qui veulent continuer la discussion. Merci. Très bonne journée et à bientôt.