Sujet 4.3 — Interopérabilité et normes de données

Dans la santé et l'action sociale, l'interopérabilité n'est pas une gentillesse technique mais une exigence de sécurité clinique et d'équité : lorsque les systèmes ne peuvent pas partager la bonne donnée, sous la bonne forme, avec un sens non ambigu, au point de soin, les gens sont blessés et l'iniquité est amplifiée.

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

Les soins d'une personne se passent rarement en un seul endroit. Un seul épisode peut toucher un cabinet de médecine générale, un service d'ambulance, un service d'urgence, un service hospitalier, une infirmière communautaire, une pharmacie, une équipe d'action sociale, et un aidant à domicile. Chacun d'eux détient une partie du dossier. Si ces parties ne peuvent pas être rassemblées en toute sécurité et rapidement, les cliniciens prennent des décisions avec des informations manquantes : une allergie non vue, une médication doublement prescrite, un test inutilement répété, un signalement de protection invisible à l'équipe qui en a besoin.

L'interopérabilité est ce qui transforme un ensemble de systèmes déconnectés en quelque chose qui se comporte, du point de vue du patient, comme un service connecté. C'est la plomberie sous les soins intégrés. Quand elle fonctionne, un clinicien dans une organisation peut voir ce qu'une autre a enregistré, et peut faire confiance que cela signifie ce qu'il pense que cela signifie. Quand elle échoue, l'échec est souvent silencieux jusqu'à ce que quelqu'un soit blessé.

C'est aussi une question d'équité. Les personnes ayant les besoins les plus complexes — adultes âgés fragiles, ceux ayant de multiples affections de longue durée, personnes se déplaçant entre services — sont exactement les personnes dont les données sont les plus fragmentées. Une mauvaise interopérabilité nuit donc le plus aux plus vulnérables. Et c'est une question de confiance publique : les gens supposent raisonnablement que le NHS partage déjà leurs informations sensément, et sont consternés d'apprendre à quel point ce n'est souvent pas le cas.

Enfin, l'interopérabilité protège l'argent public. Les systèmes propriétaires qui ne peuvent pas échanger de données enferment les organisations dans des contrats coûteux et difficiles à remplacer et forcent des intégrations point-à-point coûteuses. Construire selon des normes ouvertes est comment vous gardez les options ouvertes, gardez les fournisseurs honnêtes, et évitez de payer de manière répétée pour résoudre le même problème.

Concepts fondamentaux#

L'interopérabilité est la capacité de différents systèmes à échanger de l'information et à l'utiliser. Il est utile de séparer deux couches. L'interopérabilité syntaxique ou technique signifie que deux systèmes peuvent échanger un message et chacun peut analyser sa structure — l'enveloppe arrive et peut être ouverte. L'interopérabilité sémantique signifie que le système récepteur comprend ce que le contenu signifie de la même façon que l'expéditeur — qu'un code pour « allergie à la pénicilline » est interprété de manière identique des deux côtés. L'interopérabilité technique sans l'interopérabilité sémantique est dangereuse : les données circulent, mais le sens est perdu ou déformé.

Les données de santé sont échangées en utilisant des normes. Health Level 7 (HL7) est la famille de normes la plus utilisée en santé. Sa plus ancienne messagerie HL7 version 2 (v2), utilisant du texte délimité par barres verticales et accents circonflexes, sous-tend toujours une vaste quantité de messagerie hospitalière et le fera pendant des années. Sa norme moderne, HL7 Fast Healthcare Interoperability Resources (FHIR), modélise l'information clinique comme des « ressources » échangées via des interfaces de programmation d'application (API) de style web, ce qui rend le travail beaucoup plus facile pour les développeurs modernes.

Les normes pour le message ne suffisent pas ; vous avez aussi besoin de vocabulaires standard pour le contenu. SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) est la terminologie clinique mandatée à travers les soins du NHS pour enregistrer les diagnostics, symptômes, procédures et plus. Le NHS Dictionary of medicines and devices (dm+d) est le vocabulaire standard pour les médicaments et dispositifs médicaux, et sous-tend la prescription électronique. La Classification internationale des maladies, 10e et 11e révisions (CIM-10 et CIM-11), maintenue par l'Organisation mondiale de la santé, est utilisée pour la classification, les statistiques et le remboursement plutôt que l'enregistrement clinique quotidien. openEHR est une spécification ouverte pour structurer le dossier de santé lui-même à travers des « archétypes » partagés et cliniquement gouvernés, et est utilisé par certaines organisations pour garder les modèles de données cliniques indépendants de tout fournisseur unique.

Deux idées supplémentaires sont fondamentales. Le numéro NHS est l'identifiant patient commun qui permet aux dossiers concernant la même personne d'être liés de manière fiable à travers les organisations ; sans identifiant partagé, la correspondance est une supposition. Et Integrating the Healthcare Enterprise (IHE) publie des « profils » qui spécifient exactement comment combiner les normes existantes pour résoudre des problèmes concrets tels que le partage de documents, afin que différents fournisseurs les implémentent de la même façon.

Sous-tendant tout cela se trouve un choix stratégique. Construire selon des normes ouvertes avec des API publiées et réutilisables garde un marché compétitif et vos données portables. S'appuyer sur des interfaces propriétaires crée une dépendance envers un fournisseur, où changer de fournisseur devient si coûteux que vous ne pouvez effectivement pas. Rien de tout cela ne livre de la valeur, cependant, sans qualité des données : des données précises, complètes, opportunes, et codées de manière cohérente sont la précondition de l'interopérabilité, pas une réflexion après coup.

Bonnes pratiques#

1. Distinguez l'interopérabilité sémantique de la technique, et concevez pour les deux. Il est facile de célébrer qu'un message circule maintenant entre deux systèmes et de manquer que le clinicien récepteur ne peut pas s'appuyer en toute sécurité sur son sens. Demandez toujours : l'autre côté interprète-t-il ces codes, unités, et négations exactement comme nous ? Investissez dans des terminologies partagées (SNOMED CT, dm+d) et des ensembles de valeurs, pas seulement des formats de message, car une allergie correctement transmise mais mal comprise est plus dangereuse qu'aucun message du tout.

2. Construisez selon des normes ouvertes et réutilisez les plateformes plutôt que de réinventer. Adoptez le principe largement approuvé : construisez selon des normes ouvertes, et réutilisez les plateformes et services nationaux existants avant de construire les vôtres. Dans le NHS, cela signifie préférer les API HL7 FHIR, utiliser le numéro NHS comme identifiant, et se connecter aux services nationaux tels que le Spine, GP Connect, et les dossiers de soins partagés plutôt que créer des liens point-à-point sur mesure. La réutilisation réduit le coût, répartit le fardeau de maintenance, et signifie que vos données peuvent voyager.

3. Rendez le numéro NHS non négociable dans chaque dossier et message. La liaison fiable de dossiers dépend d'un identifiant commun digne de confiance. Assurez-vous que le numéro NHS est capturé, vérifié contre le service démographique national, et porté sur chaque dossier et interface pertinent. Là où il est manquant ou non vérifié, traitez cela comme un défaut de qualité de données à résoudre, car la correspondance sur nom et date de naissance seule produit à la fois des correspondances erronées dangereuses et des liens manqués.

4. Traitez la qualité des données comme un livrable de premier ordre. L'interopérabilité exporte vos problèmes de qualité de données vers tout le monde en aval. Profilez vos données, mesurez la complétude et la cohérence du codage, et mettez en place une intendance afin que les erreurs soient trouvées et corrigées à la source. La dérive de codage, le texte libre là où des données structurées sont nécessaires, et des unités incohérentes corrompront discrètement chaque analyse et vue clinique en aval, donc financez ce travail explicitement plutôt que de supposer qu'il se produit tout seul.

5. Préférez les architectures API-first et faiblement couplées aux intégrations serrées. Concevez afin que les capacités soient exposées via des API bien documentées et versionnées que d'autres peuvent consommer sans négociation sur mesure. C'est plus lent au début qu'un lien direct de base de données, mais c'est ce qui vous permet de remplacer un composant sans reconstruire tout autour. Cela s'aligne aussi avec comment les services nationaux et fournisseurs modernes s'attendent maintenant à intégrer, et cela soutient les approches de livraison au Sujet 3.5 — Cycles de vie de livraison.

6. Utilisez des profils publiés et des tests de conformité, pas des interprétations locales. Les normes sont flexibles, et deux équipes peuvent implémenter « la même » ressource FHIR de manière incompatible. Adoptez les guides d'implémentation nationaux et profils IHE qui fixent les détails, et exigez que les fournisseurs démontrent la conformité contre eux avant la mise en production. Les tests de conformité transforment « nous supportons FHIR » — une affirmation qui signifie très peu en soi — en fait vérifiable et contractuel.

7. Inscrivez les exigences d'interopérabilité et de normes ouvertes dans les achats et contrats. Le moment le moins cher pour éviter la dépendance est avant de signer. Exigez des API ouvertes et documentées, le droit d'extraire vos propres données sous une forme standard, l'adhérence à des normes nommées, et aucune charge pour les intégrations standard. Travaillez avec vos collègues commerciaux (voir Sujet 6.3 — Achats et commercial) afin que cela devienne des critères d'évaluation obligatoires, pas des aspirations négociées plus tard.

8. Gouvernez l'interopérabilité avec la sécurité clinique et la gouvernance de l'information dans la pièce. Chaque nouveau flux de données change le risque clinique et le traitement de l'information confidentielle. Amenez les responsables de sécurité clinique et de gouvernance de l'information dans les décisions de conception dès le début, pas comme une validation finale, afin que les dossiers partagés soient à la fois sûrs et légaux. Cela se connecte directement au Sujet 1.6 — Sécurité clinique et gestion des risques et au Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité.

Questions à discuter avec votre équipe#

1. Où dans nos parcours de soins les données manquantes ou mal comprises créent-elles le plus grand risque clinique aujourd'hui ? L'investissement en interopérabilité devrait suivre le préjudice et la valeur, pas la mode architecturale. Cartographiez les parcours que vos patients les plus complexes empruntent réellement et trouvez les transmissions où l'information est perdue, retardée, ou arrive sans sens fiable. Demandez aux cliniciens où ils travaillent habituellement à l'aveugle — les transferts, les lacunes en dehors des heures ouvrables, la frontière entre santé et action sociale. Distinguez les endroits où les données ne circulent pas du tout des endroits où elles circulent mais ne peuvent pas être fiables, car ceux-ci nécessitent des correctifs différents. Considérez quelles populations sont le plus affectées, car la fragmentation a tendance à tomber le plus durement sur les personnes ayant les besoins les plus complexes. La réponse vous dit où commencer, et vous donne un dossier de sécurité clinique qui pèsera plus lourd que tout argument technique.

2. À quel point sommes-nous exposés à la dépendance fournisseur, et que nous en coûterait-il réellement de changer nos systèmes cliniques principaux ? De nombreuses organisations découvrent le véritable prix d'un système fermé seulement lorsqu'elles essaient de le quitter. Passez en revue, concrètement, ce qu'il faudrait pour extraire vos données sous une forme utilisable et standard et vous déplacer vers un autre fournisseur. Examinez vos contrats pour qui possède les données, quelles interfaces standard existent, et si vous êtes facturé pour des intégrations qui devraient être routinières. Identifiez les interfaces et formats de données propriétaires qui devraient être démêlés. Pesez cela contre l'ouverture des alternatives et plateformes nationales que vous pourriez réutiliser à la place. Ce n'est pas à propos de changer constamment de fournisseurs ; c'est comprendre votre levier et réduire le risque que la feuille de route d'un seul fournisseur devienne votre seule option.

3. Nos données sont-elles assez bonnes pour être partagées en sécurité, et comment le saurions-nous ? Partager de mauvaises données ne fait pas que vous embarrasser — cela propage des erreurs dans les décisions d'autres cliniciens. Demandez si vous mesurez réellement la complétude, l'exactitude, l'opportunité, et la cohérence du codage des données que vous avez l'intention d'exposer. Discutez de qui possède la qualité des données dans votre organisation et s'ils ont le temps et le mandat de corriger les problèmes à la source. Considérez quelle proportion de dossiers porte un numéro NHS vérifié et combien d'informations cliniquement importantes se trouvent encore en texte libre plutôt que dans des champs codés. Pensez à comment vous détecteriez une erreur de codage systématique avant qu'elle n'atteigne un dossier de soins partagé. Si vous ne pouvez pas répondre à ces questions avec des preuves, traitez cela comme une conclusion en soi, et financez le travail de qualité des données avant d'élargir le tuyau.

4. Lorsqu'un fournisseur dit « nous supportons FHIR », comment vérifierions-nous réellement cela avant la mise en production ? Une étiquette de norme est une affirmation marketing jusqu'à ce qu'elle soit testée contre un guide d'implémentation spécifique. Discutez de si votre organisation a une quelconque capacité de test de conformité propre, ou si vous prenez simplement les fournisseurs au mot. Deux systèmes peuvent chacun être « conformes FHIR » et pourtant être incapables d'échanger un message utilisable, car la norme est délibérément flexible et le sens vit dans les profils et ensembles de valeurs qui le fixent. Demandez quels guides d'implémentation nationaux et profils IHE s'appliquent à l'interface en question, et qui de votre côté est compétent pour les lire. Considérez si la conformité est inscrite dans le contrat comme condition de connexion, ou découverte douloureusement pendant l'intégration. Une réponse honnête nomme le profil spécifique contre lequel vous testeriez, la personne ou fonction qui exécuterait le test, et le point du calendrier où un fournisseur défaillant est refusé plutôt que laissé passer.

5. Qui possède les normes, la terminologie, et la conformité à travers notre organisation, et ont-ils le mandat de dire non ? L'interopérabilité se dégrade sans intendance : les ensembles de valeurs dérivent, les guides locaux divergent, et chaque nouveau projet invente discrètement sa propre interprétation. Demandez s'il existe une fonction nommée responsable des normes, des sous-ensembles SNOMED CT et dm+d, et de la conformité, ou si cette connaissance se trouve dans la tête de quelques individus. Considérez la tension entre la cohérence centrale et la vitesse de livraison locale — les équipes sous pression construiront la chose la plus rapide à moins qu'une fonction de normes n'ait une véritable autorité pour exiger la réutilisation. Discutez de comment la maintenance de terminologie est financée, étant donné qu'elle est peu glamour, continue, et bénéficie à tous plutôt qu'à un seul projet. Regardez comment vous gardez les implémentations alignées à mesure que FHIR, SNOMED CT, et les guides nationaux évoluent, plutôt que de geler à la version que vous avez d'abord adoptée. Une réponse honnête identifie le propriétaire responsable, son financement, et un exemple récent où il a soit appliqué une norme soit échoué à le faire.

6. Les personnes dont nous connectons les dossiers sont-elles informées et satisfaites de comment leurs données circulent ? L'interopérabilité n'est pas seulement une question technique et clinique mais une question de confiance publique et de base légale. Les gens supposent raisonnablement que le NHS partage déjà leurs informations sensément, et sont consternés à la fois quand ce n'est pas le cas et quand cela l'est de manières qu'ils n'attendaient pas. Discutez de si les patients comprennent quelles organisations peuvent voir leur dossier partagé, comment un National Data Opt-Out ou un modèle de consentement local est respecté à travers le flux, et comment l'accès est enregistré et auditable. Considérez la dimension d'équité : les personnes dont les données sont les plus fragmentées — celles ayant des besoins complexes — sont aussi celles les moins capables de naviguer les désinscriptions et avis d'information. Amenez la gouvernance de l'information et, où pertinent, les patients ou leurs représentants dans la conception plutôt que de traiter le consentement comme une case cochée à la fin. Une réponse honnête peut décrire la base légale pour chaque flux, comment une personne découvrirait qui a vu son dossier, et comment ses choix sont respectés de bout en bout.

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

Un integrated care system dans le nord de l'Angleterre entreprend de donner aux cliniciens une vue unique des médications partagées à travers la médecine générale, l'hôpital, et la pharmacie communautaire, après qu'une revue d'incident grave ait constaté qu'un patient avait été prescrit deux médicaments en interaction par des équipes qui ne pouvaient pas voir les dossiers l'une de l'autre.

La tentation est d'acheter un « tableau de bord de médicaments » d'un fournisseur et de le câbler directement dans la base de données de chaque système. Le responsable d'interopérabilité résiste à cela. À la place, le programme adopte une approche de construction selon des normes ouvertes. Chaque système source expose les données de médication comme des ressources HL7 FHIR ; chaque médicament est codé en utilisant le dm+d afin que « le même médicament » signifie la même chose partout ; et chaque dossier est indexé sur un numéro NHS vérifié afin que les bonnes médications s'attachent à la bonne personne. Les données de médecine générale sont extraites via GP Connect plutôt qu'un flux sur mesure, réutilisant une capacité nationale au lieu d'en inventer une locale.

Le profilage précoce des données prouve immédiatement sa valeur. Le système d'un cabinet a enregistré certains médicaments en texte libre plutôt que comme entrées dm+d codées, ce qui signifie qu'ils auraient été invisibles à toute vérification d'interaction automatisée. Cela est corrigé à la source avant la mise en production. L'équipe trouve aussi un groupe de dossiers avec des numéros NHS non vérifiés et les achemine via le service démographique national pour correspondance.

Le responsable de sécurité clinique et le responsable de gouvernance de l'information font partie du groupe de conception tout du long. Ensemble, ils définissent exactement quelles données sont partagées, avec qui, sous quelle base légale, et comment l'accès d'un clinicien est enregistré — les préoccupations du Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité. Les fournisseurs doivent réussir les tests de conformité contre le guide d'implémentation FHIR national avant de se connecter. Douze mois plus tard, la vue de médication connectée est en direct, une interaction qui aurait auparavant été manquée a déjà été attrapée, et — parce que tout a été construit selon des interfaces ouvertes — un second cas d'usage, l'information d'allergie partagée, réutilise la majeure partie de la même plomberie à une fraction du coût original.

Angles sectoriels#

Startup#

Une startup de santé numérique vit ou meurt selon la facilité avec laquelle elle se branche sur les systèmes existants, donc traitez l'interopérabilité comme une fonctionnalité centrale, pas une corvée de conformité. Construire des API FHIR et utiliser SNOMED CT et dm+d dès le départ vous rend bien plus facile à acheter et intégrer, et signale la maturité aux acheteurs prudents du NHS. Résistez à l'envie d'inventer votre propre modèle de données quand une norme existe ; votre différenciation devrait être votre produit, pas un format propriétaire qui devient une responsabilité. Bien gérer le numéro NHS et la gouvernance de l'information tôt est ce qui vous permet de passer du pilote à l'achat. Concevez afin qu'un client puisse, en principe, extraire ses données et partir — paradoxalement, cette ouverture est ce qui gagne la confiance qui les garde.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, ou une clinique monosite — porte les mêmes obligations de partager les données en sécurité que le plus grand trust, mais avec une fraction de la capacité technique. Ici, l'interopérabilité est principalement une discipline d'achat et de configuration plutôt qu'une discipline d'ingénierie : choisissez des systèmes qui parlent déjà FHIR, connectez-vous aux services nationaux tels que GP Connect et le Spine, et codez avec SNOMED CT et dm+d dès la sortie de la boîte, afin que vous héritiez des normes au lieu de les construire. Faites de la capture vérifiée du numéro NHS une partie de la pratique quotidienne, car sans équipe d'intégration pour réconcilier les incompatibilités plus tard, bien obtenir l'identifiant au point d'enregistrement est votre garantie la moins chère. Appuyez-vous sur les programmes de dossiers de soins partagés et l'infrastructure partagée de votre integrated care system plutôt que de commander des liens sur mesure que vous ne pouvez pas maintenir. Lorsque vous signez ou renouvelez un contrat de système, insistez sur les droits d'extraction de données et les interfaces ouvertes en termes clairs, car une petite organisation ressent la dépendance fournisseur le plus vivement et a le moins de levier pour l'échapper après coup.

Entreprise#

Un grand prestataire ou fournisseur porte typiquement des décennies d'héritage : interfaces HL7 v2, systèmes de dossiers électroniques multiples, et moteurs d'intégration maintenant tout ensemble. La stratégie réaliste n'est pas d'arracher tout mais de placer une couche API-first et basée sur des normes devant le parc, migrant les flux vers FHIR de manière incrémentale tout en gardant v2 fonctionnel là où c'est nécessaire. Gardez-vous fermement contre la dépendance à chaque renouvellement, et insistez sur les tests de conformité afin que « conforme aux normes » soit vérifié plutôt qu'affirmé. Établissez une fonction interne de normes et de conformité afin que les projets individuels n'inventent pas chacun leur propre interprétation. Cela est étroitement lié à comment vous gérez les plateformes opérationnelles centrales au Sujet 5.4 — Planification des ressources d'entreprise (ERP), où la même discipline de réutilisation et d'interface ouverte s'applique.

Gouvernement#

Les organismes nationaux et régionaux fixent les règles du marché, donc leurs choix sur les normes se répercutent à travers chaque organisation. La chose la plus précieuse que le gouvernement puisse faire est de mandater des normes ouvertes, publier des guides d'implémentation clairs et exigences de conformité, et fournir des plateformes nationales réutilisables — le Spine, GP Connect, les cadres de dossiers de soins partagés, le service de numéro NHS — afin que les organisations locales construisent une fois et réutilisent. La cohérence compte plus que la perfection : une norme suffisamment bonne fermement appliquée bat une norme théoriquement supérieure que tout le monde implémente différemment. Le gouvernement doit aussi financer le travail peu glamour de maintenance de terminologie et d'amélioration de la qualité des données, car ce sont des biens publics qu'aucune organisation seule ne financera seule. Ce rôle d'intendance se connecte au Sujet 9.1 — Travailler avec les gouvernements locaux et nationaux et à comment les partenaires collaborent au Sujet 9.0 — Collaborer avec les organisations partenaires.

Modes d'échec courants#

• Confondre connexion technique et compréhension sémantique. Déclarer victoire quand un message circule, sans confirmer que les deux côtés interprètent ses codes, unités, et négations de manière identique. Le résultat est des données qui semblent intégrées mais sont discrètement mal lues.
• Partager de mauvaises données plus vite. Élargir le tuyau avant de corriger la qualité des données, de sorte que les erreurs de codage, le texte libre, et les numéros NHS manquants se propagent dans les décisions d'autres cliniciens et chaque analyse en aval.
• « Nous supportons FHIR » comme affirmation vide. Accepter une étiquette de norme sans test de conformité contre un guide d'implémentation spécifique, de sorte que deux systèmes « conformes » ne peuvent toujours pas se parler.
• Intégrations point-à-point sur mesure. Construire des liens directs entre chaque paire de systèmes, produisant une toile fragile qui devient exponentiellement plus difficile et coûteuse à maintenir à mesure qu'elle grandit.
• Dépendance par défaut. Signer des contrats avec des interfaces propriétaires et aucun droit d'extraction de données, découvrant seulement le coût du piège quand vous essayez de changer de fournisseur.
• Traiter la gouvernance comme une porte finale. Amener la sécurité clinique et la gouvernance de l'information seulement pour valider, de sorte que les problèmes émergent tard et coûteusement, ou sont laissés passer sous pression de livraison.
• Normes sans intendance. Adopter des terminologies et profils mais ne financer personne pour maintenir les ensembles de valeurs, surveiller la conformité, ou garder les implémentations alignées à mesure que les normes évoluent.

Modèle de maturité#

Liste de contrôle#

• Chaque dossier et interface pertinent porte un numéro NHS vérifié, avec un processus pour résoudre ceux manquants ou non correspondants.
• Les nouvelles interfaces utilisent HL7 FHIR et des guides d'implémentation nationaux nommés, avec HL7 v2 retenu seulement là où la migration n'est pas encore justifiée.
• Le contenu clinique est codé en utilisant SNOMED CT, et les médicaments en utilisant dm+d, contre des ensembles de valeurs convenus.
• La qualité des données pour tout ce que vous avez l'intention de partager est profilée, mesurée, possédée, et améliorée à la source avant que le tuyau ne soit élargi.
• Les fournisseurs doivent réussir les tests de conformité contre un profil spécifique avant de se connecter — « supporte FHIR » n'est jamais accepté seul.
• Les plateformes nationales (Spine, GP Connect, dossiers de soins partagés) sont réutilisées avant qu'aucune intégration sur mesure ne soit construite.
• Les contrats mandatent des API ouvertes et documentées, des droits d'extraction de données sous une forme standard, et aucune charge pour les intégrations standard.
• Les responsables de sécurité clinique et de gouvernance de l'information sont dans le groupe de conception dès le début, pas seulement à la validation.
• L'architecture est API-first et faiblement couplée, afin qu'un composant puisse être remplacé sans reconstruire tout autour.
• Une fonction nommée possède les normes, la conformité, et la maintenance de terminologie à travers l'organisation.

Sources clés#

• NHS England — interoperability standards, the Spine, GP Connect, and shared care record programmes.
• HL7 International — the FHIR standard and HL7 v2 specifications.
• SNOMED International — SNOMED CT terminology and implementation guidance.
• NHS Business Services Authority — the Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — interoperability profiles.
• openEHR International — open specifications for structuring the health record.
• World Health Organization — the International Classification of Diseases (ICD-10 and ICD-11).

Références#

1. Interoperability — Wikipédia — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — Wikipédia — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — Wikipédia — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — Wikipédia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — Wikipédia — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — Wikipédia — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — Wikipédia — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — Wikipédia — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — Wikipédia — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — Wikipédia — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — Wikipédia — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — Wikipédia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — Wikipédia — https://en.wikipedia.org/wiki/API
14. Data quality — Wikipédia — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases