Sujet 9.2 — Santé numérique mondiale et internationale

En une phrase : Les principes de ce livre voyagent à travers les frontières, mais les systèmes, lois, et contrats sociaux dans lesquels ils atterrissent ne le font pas — donc votre travail est d'apprendre délibérément d'autres systèmes de santé, d'adopter les standards mondiaux partagés, et d'adapter tout le reste au contexte plutôt que de le copier.

Pourquoi c'est important dans la santé et l'action sociale#

La santé numérique n'est pas une invention britannique, et le Royaume-Uni n'en est pas le centre de gravité. Le travail le plus difficile et le plus instructif du domaine se passe en Estonie, en Inde, au Rwanda, au Brésil, et au Kenya autant qu'à Londres ou Leeds. Si vous dirigez la livraison numérique dans le NHS, un système de soins intégrés, ou un organisme déconcentré et regardez seulement vers l'intérieur, vous résoudrez à nouveau des problèmes que d'autres ont résolus il y a une décennie, et vous manquerez les standards, outils, et histoires édifiantes qui vous auraient sauvé des années.

Cela compte pour des raisons qui vont au-delà de l'efficacité. La santé est un bien commun mondial : les pathogènes, la preuve, les directives cliniques, et — de plus en plus — le logiciel qui exécute les systèmes de soins se déplacent tous à travers les frontières. Les mêmes préoccupations de sécurité clinique, équité, et confiance publique qui définissent comment vous travaillez chez vous réapparaissent, amplifiées, quand les données et la technologie traversent les juridictions. Un outil de surveillance à distance qui est sûr dans une ville anglaise bien connectée peut être dangereux quand déployé là où la connectivité échoue ; un modèle de consentement qui est légal sous le régime d'un pays peut être illégal sous celui d'un autre ; un algorithme entraîné sur une population peut discrètement nuire à une différente.

Il y a aussi un devoir d'humilité. Le Royaume-Uni apprend de la santé mondiale et y contribue, et le flux va dans les deux sens. Les pays à revenu faible et intermédiaire (LMIC) ont pionné les soins mobile-en-premier, les plateformes de travailleurs de santé communautaires, et l'infrastructure nationale open-source que les systèmes plus riches étudient maintenant. Traiter la santé numérique internationale comme de la charité, ou comme un menu de modèles à soulever et déposer en Angleterre, est la route la plus rapide vers l'échec. La traiter comme une discipline d'apprentissage réciproque et prudent est comment vous rendez la revendication de ce livre de « principes internationalement transférables » honnête plutôt que creuse.

Concepts fondamentaux#

Santé mondiale et santé numérique. La santé mondiale est l'étude et la pratique d'améliorer la santé et d'atteindre l'équité en santé pour toutes les personnes mondialement. La santé numérique est l'usage des technologies de l'information et de la communication — dossiers, applications, appareils, analytique, et intelligence artificielle — pour livrer et améliorer les soins. L'intersection est le sujet de ce sujet : comment les outils numériques et façons de travailler se déplacent, ou échouent à se déplacer, entre systèmes de santé qui diffèrent en richesse, loi, infrastructure, et culture.

La stratégie mondiale de l'OMS et les biens publics numériques. L'Organisation mondiale de la santé (OMS) a publié une Global Strategy on Digital Health qui encadre la santé numérique comme un facilitateur de la couverture sanitaire universelle (UHC), le but que tout le monde puisse utiliser les services dont il a besoin sans difficulté financière. Une idée centrale est le bien public numérique : logiciel open-source, données ouvertes, normes ouvertes, et contenu ouvert — parfois appelés « biens mondiaux » — que tout pays peut adopter et adapter plutôt que d'acheter des systèmes propriétaires qu'il ne peut pas posséder ou se permettre. Les outils approuvés par l'OMS tels que DHIS2 (une plateforme d'information de santé utilisée dans plus de soixante-dix pays) et OpenMRS (un dossier médical open-source) sont des exemples canoniques.

Normes internationales d'interopérabilité et de terminologie. Les frontières ne sont pas franchies en déplaçant des systèmes entiers mais en partageant un langage commun. Trois normes font la plupart du travail : HL7 Fast Healthcare Interoperability Resources (FHIR) pour échanger des données cliniques structurées ; SNOMED CT, la terminologie clinique internationale gouvernée par SNOMED International ; et l'ICD-11 de l'OMS, la onzième révision de la Classification internationale des maladies, utilisée pour le codage de mortalité, morbidité, et remboursement mondialement. Ce sont le vocabulaire partagé qui laisse un dossier anglais, un dossier estonien, et un retour statistique de l'OMS signifier la même chose. (Voir Sujet 4.3 — Interopérabilité et normes de données.)

mHealth et le saut technologique. Le mHealth — santé mobile — est la livraison de services et information de santé via les téléphones mobiles. Dans de nombreux LMIC, les soins mobile-en-premier ne sont pas un déclassement mais le canal primaire, et cela illustre le saut technologique : sauter une génération d'infrastructure (ici, la connectivité filaire fixe et l'informatique hospitalière lourde en papier) pour passer directement à une technologie plus récente. La leçon pour les systèmes plus riches n'est pas que les téléphones sont bon marché, mais que la contrainte engendre des conceptions — hors-ligne-en-premier, faible bande passante, repli SMS — qui sont plus résilientes que de nombreuses alternatives « avancées ».

Souveraineté des données et flux de données transfrontaliers. La souveraineté des données est le principe que les données sont gouvernées par les lois de la juridiction dans laquelle elles sont collectées ou stockées. Les données de santé sont parmi les catégories les plus étroitement contrôlées, et les régimes légaux divergent nettement : le UK et EU General Data Protection Regulation (GDPR) repose sur des bases légales et des droits de sujet de données ; le US Health Insurance Portability and Accountability Act (HIPAA) protège un ensemble plus étroit d'« entités couvertes » ; l'Artificial Intelligence Act de l'UE et l'EU Medical Device Regulation (Regulation (EU) 2017/745) imposent des contrôles échelonnés par risque sur le logiciel en tant que dispositif médical. Un outil conforme sous un régime peut être illégal sous un autre, et les flux de données transfrontaliers exigent un mécanisme de transfert légal explicite, pas une hypothèse.

Apprendre à travers les systèmes de santé. Les pays exécutent des expériences naturelles que vous ne pouvez pas exécuter chez vous. L'Estonie a construit une couche d'échange de données pour tout le gouvernement et des dossiers numériques quasi universels ; l'Inde a construit un ensemble de composants « stack » numériques ouverts pour l'identité, les paiements, et la santé sur lesquels les acteurs privés et publics construisent ; le Rwanda a échelonné le sang livré par drone et les plateformes de santé communautaire. Chacun est une source de leçons transférables et de spécificités non transférables — et distinguer les deux est la compétence centrale que ce sujet enseigne.

Bonnes pratiques#

1. Adoptez les standards mondiaux avant d'en inventer des locaux. Revenez par défaut à HL7 FHIR, SNOMED CT, et ICD-11 pour l'échange, la terminologie, et la classification, car ce sont le langage partagé qui rend possible toute future comparaison internationale, collaboration, ou changement de fournisseur. Chaque système de code local sur mesure que vous créez est un mur que vous devrez plus tard démolir. Là où un profil national existe — les profils UK Core FHIR, par exemple — utilisez-le, et contribuez en retour plutôt que de forker discrètement.

2. Préférez les biens publics numériques et normes ouvertes au verrouillage propriétaire. Quand vous achetez ou construisez, pondérez fortement les options open-source, ouvertement spécifiées, et gouvernées indépendamment, car elles préservent votre capacité à posséder, auditer, et sortir. Les biens publics numériques tels que DHIS2 et OpenMRS sont prouvés à l'échelle nationale et libres de rente de licence ; même là où vous choisissez un produit commercial, insistez sur les normes ouvertes et la portabilité des données afin de ne jamais être otage. (Voir Sujet 9.0 — Collaborer avec des organisations partenaires sur concevoir contre le verrouillage fournisseur.)

3. Apprenez d'autres systèmes comme une discipline, avec des propriétaires nommés et une traduction honnête. Traitez l'apprentissage international comme un véritable travail : assignez quelqu'un pour étudier un système comparateur, comprendre pourquoi il fonctionne là — ses lois, financement, identité numérique, et confiance sociale — et séparez le principe transférable du spécifique local. Une visite d'étude qui revient avec « nous devrions copier l'Estonie » a échoué ; une qui revient avec « voici le problème d'identité et de consentement que l'Estonie a résolu, et voici comment nos contraintes diffèrent » a réussi.

4. Ne soulevez et déposez jamais un modèle national. Le succès de l'Estonie repose sur une petite population, une identité numérique nationale obligatoire, et un règlement de haute confiance construit sur deux décennies ; le stack de santé de l'Inde repose sur une architecture publique-privée particulière et un système d'identité à l'échelle du milliard de personnes. Extraire un composant et le déposer en Angleterre ignore l'échafaudage qui le rend sûr. Adoptez le motif et reconstruisez l'implémentation pour votre contexte légal, démographique, et de confiance.

5. Cartographiez le régime légal avant que toute donnée ne traverse une frontière. Établissez, par écrit, la base légale, le mécanisme de transfert, et les relations de contrôleur avant que les données de santé ne quittent une juridiction — ne supposez pas qu'un flux légal au Royaume-Uni est légal en aval. Là où vous opérez à travers GDPR, HIPAA, l'EU AI Act, et l'EU Medical Device Regulation, traitez le régime applicable le plus strict comme votre plancher, et enregistrez comment la souveraineté des données est respectée pour chaque population dont vous détenez les données.

6. Concevez pour les conditions réalistes les plus rudes, pas la démo. Empruntez la discipline LMIC de hors-ligne-en-premier, faible bande passante, et dégradation gracieuse, car elle produit des services qui survivent à l'échec de connectivité, l'ancien appareil, et la zone rurale sans signal chez vous aussi. Un outil qui ne fonctionne que sur fibre rapide dans une clinique n'est pas résilient ; l'équité et la sécurité clinique s'améliorent toutes deux quand vous supposez que le réseau échouera.

7. Ancrez tout dans l'équité et la couverture universelle, et vérifiez qui est exclu. Demandez, pour chaque déploiement, s'il réduit ou élargit l'écart — à travers les pays et à l'intérieur de votre propre population — car un service numérique qui sert les connectés et confiants tout en laissant d'autres derrière est un pas loin de la couverture universelle, pas vers elle. Mesurez l'adoption par groupe, pas seulement en agrégat. (Ceci se connecte au Sujet 1.9 — Inclusion numérique et accessibilité.)

8. Gouvernez l'IA et les technologies émergentes selon la barre internationale applicable la plus élevée. Les algorithmes entraînés dans une population peuvent nuire à une autre, et le terrain réglementaire bouge vite sous l'EU AI Act et cadres comparables. Documentez la provenance des données d'entraînement, validez sur votre propre population, et alignez la gouvernance au régime le plus strict que vous touchez plutôt que le plus permissif. (Voir Sujet 8.4 — Gouvernance de l'IA et des technologies émergentes.)

Questions à discuter avec votre équipe#

1. Quand nous admirons le système de santé numérique d'un autre pays, pouvons-nous articuler exactement quelles parties sont transférables à notre contexte et lesquelles dépendent de conditions que nous ne partageons pas ? Cette question garde contre l'erreur la plus courante et la plus coûteuse dans l'apprentissage international : confondre une implémentation spécifique avec un principe général. L'échange de données quasi sans friction de l'Estonie dépend d'une identité numérique nationale obligatoire et d'un règlement social de haute confiance ; le stack de santé de l'Inde dépend d'une architecture publique-privée particulière et d'un système d'identité à l'échelle de la population ; les deux ont pris de nombreuses années et des conditions politiques spécifiques. Votre équipe devrait pouvoir nommer le problème sous-jacent que chaque système a résolu — identité sécurisée, échange de données consenti, atteindre les populations éloignées — puis décrire honnêtement comment votre régime légal, financement, démographie, et confiance publique diffèrent. La discussion devrait faire surgir quel échafaudage un modèle emprunté aurait besoin pour être sûr ici, et si cet échafaudage est réaliste. Une réponse mature sépare le motif digne d'être adopté de l'implémentation qui ne peut pas voyager, et traite « nous devrions juste les copier » comme un drapeau rouge plutôt qu'un plan. Elle demande aussi la question réciproque : que fait notre système que d'autres pourraient apprendre, ce qui aiguise l'humilité que tout l'exercice exige.

2. Avant que toute donnée de santé ne traverse une frontière — y compris vers une région cloud, un fournisseur, ou un partenaire de recherche dans un autre pays — connaissons-nous la base légale, le mécanisme de transfert, et quel régime la gouverne ? Les flux de données transfrontaliers sont là où les bonnes intentions rencontrent le droit dur, et l'échec est habituellement silencieux : les données se déplacent via une région cloud ou un bureau de support d'un fournisseur outre-mer sans que personne n'établisse un mécanisme de transfert légal. Votre équipe devrait distinguer clairement entre le monde UK et EU GDPR de bases légales et droits de sujet de données, le modèle US HIPAA qui protège un ensemble plus étroit d'entités couvertes, et les contrôles émergents de l'EU AI Act et Medical Device Regulation pour le logiciel clinique. La discussion doit couvrir la souveraineté des données concrètement : pour chaque population dont vous détenez les données, quelle loi nationale la gouverne, et le respectez-vous ? Elle devrait aussi confronter les pièges pratiques — un produit SaaS « mondial » avec du personnel de support sur un autre continent, un fournisseur IA dont le modèle est réentraîné sur vos données, une collaboration de recherche qui suppose une réciprocité que la loi n'accorde pas. Une réponse forte traite le régime applicable le plus strict comme le plancher, enregistre le mécanisme de transfert par écrit avant que les données ne bougent, et peut nommer qui est responsable quand un régulateur demande.

3. Concevons-nous pour la connectivité, les appareils, et la littératie de tous ceux que nous servons, ou seulement pour l'utilisateur confiant et connecté de la démo ? Une grande partie de la technologie de santé la plus résiliente du monde a été construite sous contrainte — alimentation intermittente, faible bande passante, téléphones partagés ou de base, langues multiples — et cette discipline produit des services qui servent aussi les exclus à l'intérieur d'un système riche. Votre équipe devrait examiner si ses conceptions supposent une connectivité rapide, des appareils modernes, et une haute littératie numérique, et ce qui arrive à un patient quand ces hypothèses échouent. Les enjeux d'équité sont directs : un service qui ne fonctionne que pour les bien connectés élargit l'écart qu'il était censé fermer, à la fois entre pays et à l'intérieur de votre propre population, s'éloignant de la couverture universelle plutôt que s'en rapprochant. La conversation devrait regarder le comportement hors-ligne-en-premier, la dégradation gracieuse, le repli SMS ou vocal, l'accessibilité de langue et de niveau de lecture, et si l'adoption est mesurée par groupe plutôt que seulement en agrégat. Elle devrait aussi demander si vous empruntez des motifs de conception LMIC prouvés ou les ignorez par un sens qu'ils ne sont « pas pour nous ». Une bonne réponse peut pointer vers des choix de conception spécifiques qui protègent l'utilisateur le plus difficile à atteindre et vers des métriques qui révéleraient l'exclusion tôt.

4. Quand nous construisons ou achetons, choisissons-nous des biens publics numériques et normes ouvertes que nous pouvons posséder, auditer, et quitter — ou acceptons-nous discrètement le verrouillage propriétaire parce que c'est commode aujourd'hui ? Le choix entre une plateforme ouverte et gouvernée indépendamment et une propriétaire polie est là où la souveraineté à long terme d'un système est gagnée ou perdue, et la pression va presque toujours vers l'option fermée car elle démo mieux et demande moins de vous maintenant. Votre équipe devrait pouvoir dire pourquoi elle a pondéré les options open-source, ouvertement spécifiées, et portables dans une décision récente spécifique — ou admettre honnêtement qu'elle ne l'a pas fait. Les biens publics numériques tels que DHIS2 et OpenMRS sont prouvés à l'échelle nationale et libres de rente de licence, mais ils exigent une capacité interne et un engagement de maintenance qu'un contrat commercial semble retirer ; ce compromis est réel et devrait être argumenté, pas supposé résolu. La discussion doit aussi couvrir la sortie concrètement : si ce fournisseur doublait son prix ou quittait le marché en trois ans, pourriez-vous déplacer vos données et votre service, et avez-vous testé cette revendication plutôt que de faire confiance à une clause de contrat ? Une réponse mature traite la portabilité des données et une sortie documentée comme non négociables même quand le produit choisi est commercial, et peut nommer ce que l'organisation devrait construire ou financer pour rendre l'option ouverte viable.

5. Traitons-nous les partenaires à faible revenu comme des sources de conception prouvée et de véritables collaborateurs, ou comme des destinataires de notre charité — et pouvons-nous dire clairement ce que nous contribuons en retour ? La santé numérique internationale porte une asymétrie de pouvoir persistante, et l'encadrement de charité — où un système riche « aide » un LMIC en donnant de la technologie — est à la fois condescendant et une route fiable vers l'échec, car il ignore que les soins mobile-en-premier, les plateformes de travailleurs de santé communautaires, et l'infrastructure nationale ouverte ont souvent été pionnés exactement dans ces systèmes. Votre équipe devrait examiner un partenariat réel ou proposé et demander qui possède le résultat, qui le maintient, et si le flux d'apprentissage va véritablement dans les deux sens. Les tensions sont concrètes : une plateforme donnée qui devient une dépendance non financée, une « collaboration » qui extrait des données ou une validation d'une population partenaire sans bénéfice réciproque, une visite d'étude qui prend des leçons mais n'offre rien en retour. Elle devrait aussi confronter l'humilité réciproque que le sujet exige — que fait votre propre système que d'autres pourraient apprendre, et le partagez-vous aussi ouvertement que vous attendez qu'ils le partagent avec vous ? Une réponse honnête peut pointer vers des arrangements de copropriété, des contributions en retour aux noyaux ouverts partagés, et un partenariat qui aurait toujours du sens si la direction du financement était inversée.

6. Pour tout algorithme ou modèle IA que nous déployons, pouvons-nous montrer qu'il a été validé sur la population qu'il servira réellement, et gouverné selon le régime le plus strict que nous touchons plutôt que le plus permissif ? Un modèle entraîné et validé sur une population peut discrètement nuire à une différente, et la santé numérique internationale multiplie ce risque car les outils, données d'entraînement, et fournisseurs traversent les frontières plus vite que la preuve de leur sécurité. Votre équipe devrait pouvoir distinguer la provenance d'un modèle — d'où viennent ses données d'entraînement, contre quelle population il a été validé — de la population qu'on lui demande maintenant de servir, et traiter tout écart comme une préoccupation de sécurité clinique en direct plutôt qu'un détail de paperasse. Le terrain réglementaire bouge vite et inégalement : l'EU AI Act impose des contrôles échelonnés par risque sur le logiciel clinique à haut risque, l'EU Medical Device Regulation traite de nombreux algorithmes comme logiciel en tant que dispositif médical, et la loi britannique est plus légère par endroits, ce qui crée une tentation de gouverner selon le régime le plus permissif que vous pouvez défendre. La discussion devrait faire surgir qui est responsable de la revalidation, comment les mises à jour de modèle et le réentraînement du fournisseur sont contrôlés, et si l'organisation documente la provenance des données d'entraînement du tout. Une réponse forte revalide sur la population locale avant le déploiement, aligne la gouvernance à la barre internationale applicable la plus élevée pour garder les options ouvertes, et peut expliquer ce choix à un régulateur sans embarras.

En pratique : un exemple de santé et d'action sociale#

Un organisme déconcentré anglais fictif, le « National Remote Monitoring Service », est demandé d'acheter une plateforme pour la surveillance à domicile de conditions de longue durée, avec une option de collaborer sur un noyau open-source partagé avec les ministères de la santé de deux pays partenaires — l'un un voisin UE à revenu élevé, l'un un LMIC échelonnant des travailleurs de santé communautaires.

La tentation est d'acheter une plateforme commerciale polie et de traiter l'angle international comme une courtoisie diplomatique. L'équipe résiste. Elle commence par les standards : toute plateforme doit échanger des données comme HL7 FHIR, coder les observations en SNOMED CT, et classifier les conditions en ICD-11, afin que les données signifient la même chose à travers les trois pays et que le service ne soit pas verrouillé à un fournisseur. Elle présélectionne un noyau de bien public numérique (un stack dérivé d'OpenMRS) aux côtés de deux options commerciales, notant chacune sur la portabilité des données et la sortie aussi fortement que sur les fonctionnalités.

Sur la loi, l'équipe cartographie les régimes avant qu'un octet ne bouge. Les données pour les patients anglais restent sous UK GDPR dans une région cloud britannique ; la collaboration du partenaire UE fonctionne sous EU GDPR avec un mécanisme de transfert documenté ; aucune donnée personnelle ne circule vers ou depuis le partenaire LMIC du tout — seulement des indicateurs agrégés désidentifiés et le code open-source lui-même, qui est un bien public numérique et ne porte aucun risque de souveraineté. L'algorithme de surveillance est traité comme logiciel en tant que dispositif médical et validé contre la population anglaise séparément, car un modèle ajusté ailleurs ne peut pas être supposé sûr ici ; sa gouvernance est alignée aux attentes à haut risque de l'EU AI Act même là où la loi britannique est plus légère, pour garder les options ouvertes.

La conception emprunte au partenaire LMIC plutôt que de lui faire la leçon. La plateforme de travailleur de santé communautaire là-bas est hors-ligne-en-premier avec repli SMS, et le service anglais adopte le même motif — ce qui s'avère compter pour les zones rurales sans signal et les patients plus âgés à domicile. Dix-huit mois plus tard, le noyau open-source partagé est maintenu conjointement, chaque pays exécute son propre déploiement légal, et aucun partenaire n'a copié le modèle d'un autre entièrement. L'équipe anglaise peut montrer à un régulateur exactement quelles données siègent sous quelle loi, et le ministère LMIC a une plateforme copossédée plutôt qu'une dépendance donnée.

Angles sectoriels#

Startup#

Une startup de santé numérique atteint souvent les marchés internationaux avant d'être prête pour la complexité légale qu'ils portent. L'avantage est réel — les standards mondiaux signifient qu'un produit FHIR-natif et codé SNOMED peut, en principe, vendre partout — mais chaque nouveau pays apporte un régime différent (GDPR, HIPAA, l'EU AI Act, règles nationales de dispositif médical) et une attente de souveraineté des données différente. Construisez au régime le plus strict que vous prévoyez plausiblement d'entrer, gardez les données personnelles dans la région par conception, et traitez la compatibilité de bien public numérique comme un avantage de marché plutôt qu'une menace. Les fondateurs qui font un saut technologique vers les marchés LMIC devraient s'associer véritablement et localiser honnêtement, car un outil parachuté sans propriété locale survit rarement au contact de l'infrastructure réelle.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une clinique monosite, ou un petit fournisseur de santé technologique passé le stade startup — porte les mêmes devoirs transfrontaliers et de standards qu'un organisme national mais avec une fraction de la capacité pour les satisfaire. Il a rarement du personnel informatique ou de gouvernance de l'information dédié, pourtant il peut toujours utiliser un produit hébergé sur cloud dont les données siègent dans une autre juridiction, ou un outil de diagnostic construit sur un modèle validé ailleurs. La protection pratique est de s'appuyer sur les standards et la discipline de régime-le-plus-strict-comme-plancher plutôt que d'essayer de raisonner chaque cas à partir de zéro : demandez aux fournisseurs de montrer le support FHIR et SNOMED CT, la résidence de données dans la région, et une base légale documentée avant de signer, et traitez la portabilité des données comme une question de survie car vous ne pouvez pas vous permettre d'être verrouillé dans un fournisseur qui échoue. Emprunter des motifs hors-ligne-en-premier et faible bande passante prouvés est souvent une meilleure adéquation ici que de poursuivre le produit d'entreprise poli, car la résilience compte plus que les fonctionnalités quand il n'y a personne à appeler quand le réseau tombe. Là où un profil national ou un bien public numérique existe déjà, adoptez-le plutôt que de commander quoi que ce soit sur mesure que vous ne pourriez jamais maintenir.

Entreprise#

Un grand organisme NHS, système de soins intégrés, ou fournisseur multinational a l'échelle pour façonner les standards plutôt que simplement les suivre, et l'obligation de le faire de manière responsable. Le risque d'entreprise est un achat mondial qui centralise discrètement les données à travers les juridictions, créant des problèmes de souveraineté et de verrouillage qui font surface des années plus tard sur le bureau d'un régulateur. Mandatez les normes ouvertes et la portabilité des données dans chaque contrat, insistez sur une résidence de données claire dans la région, et utilisez votre poids d'achat pour renforcer l'écosystème de bien public numérique plutôt que de l'affamer. Quand vous apprenez d'autres systèmes, ressourcez l'apprentissage correctement — des visites d'étude avec des propriétaires nommés et des écrits honnêtes — plutôt que de collecter des anecdotes.

Gouvernement#

Un organisme national ou supranational fixe les règles dans lesquelles tout le monde travaille, donc ses choix sur les standards, la souveraineté, et l'ouverture résonnent pour une décennie. Les gouvernements devraient mandater les standards internationaux (FHIR, SNOMED CT, ICD-11), investir dans et contribuer aux biens publics numériques comme une question de résilience et de valeur, et légiférer des régimes clairs et fonctionnels pour les données transfrontalières et l'IA plutôt que de les laisser à la négociation cas par cas. Ils détiennent aussi le rôle diplomatique : s'aligner avec la WHO Global Strategy on Digital Health, soutenir les systèmes LMIC comme partenaires plutôt que destinataires, et faire avancer la couverture sanitaire universelle comme but partagé. La responsabilité est publique et internationale, donc les décisions doivent être transparentes et défendables, pas simplement expédientes. (Voir Sujet 9.1 — Travailler avec les gouvernements locaux et nationaux.)

Modes d'échec courants#

• Soulever et déposer. Copier le modèle d'un autre pays sans son échafaudage légal, d'identité, et de confiance. Correctif : adoptez le motif, reconstruisez l'implémentation pour votre contexte.
• Inventer des standards locaux. Construire des systèmes de code sur mesure au lieu d'utiliser FHIR, SNOMED CT, et ICD-11. Correctif : adoptez les standards mondiaux d'abord et utilisez les profils nationaux là où ils existent.
• Fuite silencieuse de données transfrontalières. Les données se déplacent via des régions cloud ou bureaux de support outre-mer sans mécanisme de transfert. Correctif : cartographiez le régime et enregistrez la base légale avant que toute donnée ne bouge.
• Verrouillage propriétaire déguisé en commodité. Acheter une plateforme fermée que vous ne pouvez pas posséder, auditer, ou quitter. Correctif : pondérez les biens publics numériques et mandatez la portabilité des données.
• Encadrement de charité du travail LMIC. Traiter les partenaires à faible revenu comme destinataires plutôt que sources de conception prouvée. Correctif : associez-vous réciproquement et adoptez leurs motifs résilients hors-ligne-en-premier.
• Supposer qu'un algorithme voyage. Déployer un modèle validé sur une autre population. Correctif : revalidez sur votre propre population et gouvernez selon le régime applicable le plus strict.
• Concevoir seulement pour la démo. Supposer une connectivité rapide, des appareils modernes, et une haute littératie. Correctif : concevez hors-ligne-en-premier avec dégradation gracieuse et mesurez l'adoption par groupe.

Modèle de maturité#

Liste de contrôle#

• L'échange, la terminologie, et la classification utilisent HL7 FHIR, SNOMED CT, et ICD-11, avec des profils nationaux là où ils existent.
• Les options de bien public numérique et de standard ouvert ont été fortement pondérées dans les décisions de construire-ou-acheter.
• Chaque produit et contrat fournisseur garantit la portabilité des données et une sortie documentée.
• La base légale, la résidence des données, et le mécanisme de transfert sont enregistrés avant que toute donnée de santé ne traverse une frontière.
• Les régimes applicables (UK/EU GDPR, HIPAA, EU AI Act, EU Medical Device Regulation) sont identifiés, avec le plus strict traité comme le plancher.
• Tout modèle IA est validé sur votre propre population et gouverné selon la barre internationale applicable la plus élevée.
• L'apprentissage international a un propriétaire nommé qui sépare les principes transférables des spécificités non transférables.
• Aucun modèle national n'a été copié entièrement sans reconstruire son implémentation pour le contexte local.
• Les services se dégradent avec grâce — hors-ligne-en-premier, faible bande passante, canaux de repli — pour les conditions réalistes les plus rudes.
• L'adoption et les résultats sont mesurés par groupe pour détecter l'exclusion, au service de la couverture universelle et l'équité.

Sources clés#

• World Health Organization — Global Strategy on Digital Health 2020–2025 (who.int).
• World Health Organization — Classification of digital health interventions and ICD-11 (who.int).
• Digital Public Goods Alliance — DPG Standard and registry (digitalpublicgoods.net).
• HL7 International — FHIR specification (hl7.org/fhir); SNOMED International — SNOMED CT (snomed.org).
• Estonia — e-Estonia and X-Road / Nordic Institute for Interoperability Solutions (e-estonia.com; niis.org).
• Ministry of Health & Family Welfare / National Health Authority (India) — Ayushman Bharat Digital Mission (abdm.gov.in).
• European Commission — Regulation (EU) 2017/745 on medical devices; Regulation (EU) 2024/1689 (Artificial Intelligence Act).
• Information Commissioner's Office — international transfers guidance under UK GDPR (ico.org.uk).
• The Lancet & Financial Times Commission — Governing health futures 2030 (thelancet.com).

Références#

1. Global health — Wikipédia — https://en.wikipedia.org/wiki/Global_health
2. Digital health — Wikipédia — https://en.wikipedia.org/wiki/Digital_health
3. World Health Organization — Wikipédia — https://en.wikipedia.org/wiki/World_Health_Organization
4. Digital public goods — Wikipédia — https://en.wikipedia.org/wiki/Digital_public_goods
5. Universal health care — Wikipédia — https://en.wikipedia.org/wiki/Universal_health_care
6. Fast Healthcare Interoperability Resources (FHIR) — Wikipédia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. SNOMED CT — Wikipédia — https://en.wikipedia.org/wiki/SNOMED_CT
8. ICD-11 — Wikipédia — https://en.wikipedia.org/wiki/ICD-11
9. mHealth — Wikipédia — https://en.wikipedia.org/wiki/MHealth
10. Leapfrogging — Wikipédia — https://en.wikipedia.org/wiki/Leapfrogging
11. Data sovereignty — Wikipédia — https://en.wikipedia.org/wiki/Data_sovereignty
12. Artificial Intelligence Act — Wikipédia — https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
13. Regulation (EU) 2017/745 (EU Medical Device Regulation) — Wikipédia — https://en.wikipedia.org/wiki/Regulation_(EU)_2017/745
14. Health Insurance Portability and Accountability Act (HIPAA) — Wikipédia — https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
15. General Data Protection Regulation — Wikipédia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
16. Global Strategy on Digital Health 2020–2025 — World Health Organization — https://www.who.int/publications/i/item/9789240020924
17. The DPG Standard — Digital Public Goods Alliance — https://www.digitalpublicgoods.net/standard
18. Ayushman Bharat Digital Mission — National Health Authority, Government of India — https://abdm.gov.in/