🔥 Comment créer un guide d'implémentation FHIR

Le problème d'interopérabilité

Imaginez que vous êtes un médecin qui reçoit un nouveau patient ayant consulté plusieurs hôpitaux, subi divers examens et prenant actuellement plusieurs médicaments. Mais en ce moment, toutes ces informations critiques sont éparpillées dans différents systèmes qui ne communiquent pas efficacement entre eux. C'est le problème d'interopérabilité des soins de santé.

Les systèmes informatiques de santé sont profondément fragmentés. Chaque hôpital, clinique, laboratoire et compagnie d'assurance stocke les données des patients différemment — en utilisant des bases de données personnalisées, des formats propriétaires et des API incompatibles. Lorsque les patients passent d'un prestataire à l'autre, leur historique médical ne les suit pas de façon transparente. Vos résultats de laboratoire se trouvent dans un système, les ordonnances dans un autre, et l'imagerie dans un troisième. Les médecins perdent du temps à chercher des informations ou, pire encore, prennent des décisions avec des données incomplètes.

Chaque nouvelle connexion entre les systèmes nécessite un développement personnalisé. Le dossier patient de l'hôpital « A » ne ressemble en rien à celui de la clinique « B ». Les API sont incohérentes. Les formats de données varient considérablement, et des informations critiques se perdent dans la traduction. Allergies, médicaments et antécédents médicaux — tout est éparpillé dans des systèmes incompatibles qui ne peuvent pas échanger de messages cohérents.

Les organisations de santé se retrouvent prisonnières de systèmes propriétaires. Changer de fournisseur signifie reconstruire toutes les intégrations à partir de zéro — une entreprise coûteuse et risquée que peu peuvent se permettre.

FHIR : Le langage universel de la santé

FHIR (Fast Healthcare Interoperability Resources) révolutionne la façon dont les systèmes de santé communiquent. Pensez-y comme à un vocabulaire universel que chaque système de santé peut comprendre. Au lieu de construire des ponts personnalisés entre chaque paire de systèmes, chaque organisation se connecte à un serveur FHIR en utilisant le même langage normalisé.

Patient, Observation, Medication, Condition — toutes les données de santé de toutes les cliniques utilisent les mêmes structures de ressources. Un dossier Patient de l'hôpital « A » est identique à celui de la clinique « B ». Plus besoin d'analyseurs syntaxiques personnalisés ni de couches de transformation des données.

Sous le capot, FHIR est une API RESTful, de sorte que chaque serveur FHIR prend en charge les mêmes opérations :

GET /Patient/001 – récupérer les données du patient
GET /Observation?patient=001&code=blood-pressure – rechercher des observations
POST /Patient – créer un nouveau dossier patient

Pourtant, la flexibilité de FHIR crée de nouveaux problèmes. La ressource Patient de base comporte plus de 50 champs optionnels. Lesquels votre clinique pédiatrique devrait-elle exiger? Votre centre de cardiologie? Votre système d'assurance?

Différentes équipes interprètent la spécification FHIR à leur façon : l'une stocke le poids du patient en kilogrammes, une autre en livres. Un laboratoire code les analyses avec LOINC, un autre invente des codes locaux. Les paramètres de recherche varient entre les implémentations.

Votre hôpital a probablement besoin de flux de travail spécifiques que le FHIR de base n'aborde pas. Comment faites-vous respecter vos règles de qualité des données? Quelles opérations de recherche personnalisées votre équipe clinique et vos systèmes d'intégration nécessitent-ils?

Les fournisseurs choisissent souvent des sous-ensembles de FHIR : le système « A » prend en charge la recherche de patients par nom; le système « B » ne le fait pas. Votre intégration se brise lorsque vous changez de fournisseur, même si les deux prétendent être « conformes à FHIR ». Sans contraintes, les systèmes « conformes à FHIR » échouent toujours à partager des données significatives. Vous obtenez une interopérabilité structurelle (même format JSON) mais perdez l'interopérabilité sémantique (sens partagé).

C'est pourquoi la prochaine étape — un guide d'implémentation (IG) sur mesure — oblige tout le monde à suivre le même manuel et transforme la promesse de FHIR en réalité quotidienne.

Guide d'implémentation : Votre manuel de règles FHIR

Un guide d'implémentation FHIR transforme la spécification FHIR en un contrat sans ambiguïté adapté à votre organisation.

Au lieu de plus de 50 champs Patient optionnels, votre IG précise exactement lesquels sont obligatoires. Les cliniques pédiatriques exigent la date de naissance et les coordonnées du tuteur, tandis que les centres de cardiologie imposent le poids et l'historique de la pression artérielle.

Votre IG définit que le poids doit être enregistré en kilogrammes, que les dates suivent le format ISO et que les observations de pression artérielle utilisent des codes LOINC spécifiques. Pas de place pour les suppositions ou les interprétations incohérentes.

Au moyen de ValueSets et de CodeSystems, votre IG limite le groupe sanguin aux valeurs valides (A+, B-, O+), les codes de laboratoire aux termes LOINC approuvés et les codes de diagnostic à votre sous-ensemble ICD-10 organisationnel.

Les extensions vous permettent de saisir la « citoyenneté », la « race » ou le « niveau de couverture d'assurance » sans rompre la compatibilité FHIR. Les données restent structurées et consultables tout en répondant aux besoins métier uniques.

Votre IG liste les paramètres de recherche que chaque serveur doit prendre en charge. Comme chaque fournisseur implémente le même ensemble de requêtes, vous pouvez remplacer les systèmes en toute confiance.

Les serveurs FHIR peuvent valider les données entrantes par rapport aux profils de votre IG, en rejetant les enregistrements incomplets ou mal formés avant qu'ils n'entrent dans votre système.

Le résultat : « conforme à FHIR selon notre IG » signifie que les systèmes fonctionnent vraiment ensemble, et pas seulement qu'ils partagent la même structure JSON.

Alors que FHIR fournit les fondations, les guides d'implémentation vous permettent de définir exactement comment votre organisation utilise FHIR. Pensez à FHIR comme à l'anglais, et à votre IG comme au guide de style de votre entreprise — même langue, mais avec des règles spécifiques à votre contexte.

Avec plusieurs services, équipes et fournisseurs travaillant avec un seul serveur FHIR, vous avez besoin qu'ils parlent un seul dialecte : quels champs sont obligatoires, quelles valeurs sont autorisées, quelles API doivent être prises en charge. Cela signifie qu'une application hospitalière et un système d'assurance peuvent tous deux travailler avec les mêmes données Patient sans coordination. Les recherches telles que GET /Observation?patient=123&code=loinc|1234-5 se comportent de la même façon sur tous les serveurs conformes, rendant l'intégration prévisible.

Terminology : Parler le même langage

Un ValueSet et un CodeSystem sont des ressources FHIR qui représentent vos vocabulaires contrôlés. Ils définissent quels codes sont autorisés dans les champs codés et assurent une terminologie cohérente dans l'ensemble de votre système.

Pourquoi est-ce important? Un champ « groupe sanguin » a besoin de valeurs spécifiques comme A+, B-, O+, et non de texte aléatoire comme « sang rouge » ou « type fantastique ». Différents domaines de la santé utilisent différents systèmes de codification — LOINC pour les résultats de laboratoire, SNOMED CT pour les termes cliniques, ICD-10-CM pour les diagnostics.

La ressource CodeSystem définit les codes réels et leurs significations, comme la création d'un dictionnaire propre à votre domaine. La valeur d'affichage peut être traduite en plusieurs langues, préservant le sens voulu quelle que soit la langue utilisée.

À son tour, la ressource ValueSet sélectionne quels codes provenant d'un ou plusieurs CodeSystems sont autorisés dans des contextes spécifiques — imaginez un ValueSet « Groupe sanguin » qui ne retient que huit codes (A+, A‑, B+, B‑, AB+, AB‑, O+, O‑) du catalogue SNOMED beaucoup plus vaste. Différents ValueSets qui extraient leurs codes liés à un contexte spécifique peuvent être basés sur le même CodeSystem, mais servir différents flux de travail.

Les avantages comprennent l'application de codes valides uniquement dans les champs codés, la prévention des erreurs de saisie de données grâce à la validation, et l'activation de l'interopérabilité sémantique où les systèmes comprennent le sens, et pas seulement la structure. Au lieu d'accepter n'importe quelle valeur de chaîne dans les champs codés, votre système valide par rapport à des vocabulaires prédéfinis, garantissant que les données cliniques utilisent une terminologie normalisée que d'autres systèmes peuvent interpréter correctement. Cette approche contrôlée transforme le chaos du texte libre en données structurées et significatives qui soutiennent la prise de décision clinique, la conformité réglementaire et l'analytique des données et l'apprentissage automatique.

Explorons un exemple pratique : la gestion des fuseaux horaires dans les applications de santé en ligne. Lorsque votre application dessert des patients dans différentes régions, la planification précise des rendez-vous nécessite une prise en compte des fuseaux horaires. La ressource CodeSystem de FHIR offre une façon structurée de définir et de gérer ces valeurs de fuseaux horaires.

{
  "url": "http://my-organization.io/pacakage-1/CodeSystem/timezone-codes",
  "status": "active",
  "content": "complete",
  "resourceType": "CodeSystem",
  "concept": [
    { "code": "America/Los_Angeles", "display": "Pacific Time (US & Canada)" },
    { "code": "Europe/Andorra", "display": "Central European Time (Andorra)" },
    { "code": "Australia/Melbourne", "display": "Australian Eastern Time (Melbourne)" }
  ]
}

Pour appliquer les règles de validation en utilisant notre CodeSystem, nous créons un ValueSet qui le référence — les profils se lient toujours aux ValueSets plutôt que directement aux CodeSystems. L'URL canonique sert d'identifiant unique permettant à notre profil de référencer ce ValueSet, tandis que l'attribut compose agit comme un langage spécifique au domaine définissant des règles pour inclure des codes provenant des CodeSystems. Dans notre cas simple, nous incluons tous les codes de notre CodeSystem de fuseaux horaires.

{
  "url": "http://my-organization.io/pacakage-1/ValueSet/timezone-codes",
  "status": "active",
  "resourceType": "ValueSet",
  "compose": {
    "include": [{ "system": "http://my-organization.io/pacakage-1/CodeSystem/timezone-codes" }]
  }
}

Résultat : le serveur rejette maintenant tout code de fuseau horaire en dehors de cette liste, gardant les horaires précis partout dans le monde.

Extensions : Ajout de vos champs personnalisés

Les extensions = ressources FHIR + vos champs personnalisés pour les ressources existantes. Elles vous permettent d'ajouter des données qui n'existent pas dans les ressources FHIR standard sans dériver de la norme.

Pourquoi s'en donner la peine? La ressource Patient de base ne comporte pas la « citoyenneté », la « race » ou le « niveau de couverture d'assurance », mais nos exigences métier et médicales dépendent de cette information. Rappelons que FHIR est une colonne vertébrale — complète, mais pas une ontologie médicale exhaustive.

Principaux avantages

Ajoutez des champs propres à votre domaine tout en restant 100 % conforme à FHIR.
Maintenez l'interopérabilité tout en capturant vos exigences uniques.
Stockez des données personnalisées dans un format structuré et consultable — jamais enfouies dans du texte libre.

Au lieu de modifier les ressources FHIR de base ou d'utiliser des champs de texte non structurés, votre système capture des données supplémentaires précises dans un format normalisé et consultable. Cette approche structurée garantit que les données personnalisées restent interrogeables et échangeables tout en préservant la promesse d'interopérabilité de FHIR.

Le ValueSet est lié à l'extension

Avec notre ValueSet défini, nous pouvons maintenant le lier à notre extension de fuseau horaire. La référence de liaison pointe vers l'URL canonique de notre ValueSet, tandis que la force de liaison est définie sur « required » pour assurer une validation stricte. Cela signifie que le serveur FHIR rejettera toutes les ressources utilisant des codes de fuseau horaire qui ne figurent pas dans notre ValueSet.

{
  "url": "http://my-organization.io/package-1/time-zone",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Extension",
  "abstract": false,
  "name": "TimeZone",
  "status": "active",
  "kind": "complex-type",
  "type": "Extension",
  "derivation": "constraint",
  "resourceType": "StructureDefinition",
  "context": [{ "expression": "Patient", "type": "element" }],
  "differential": {
    "element": [
      {
        "path": "Extension.url",
        "id": "Extension.url",
        "fixedUri": "http://my-organization.io/package-1/time-zone"
      },
      {
        "id": "Extension.value[x]",
        "path": "Extension.value[x]",
        "type": [{ "code": "code" }],
        "min": 1,
        "binding": {
          "strength": "required",
          "valueSet": "http://my-organization.io/pacakage-1/ValueSet/timezone-codes"
        }
      }
    ]
  }
}

Profils : Adapter FHIR à vos besoins

Les profils = ressources FHIR + vos restrictions sur celles-ci. Ils permettent aux ressources abstraites de fonctionner selon vos besoins spécifiques. FHIR fournit un ensemble de ressources avec un schéma spécifique, et la plupart des champs de la ressource sont optionnels par défaut.

Pourquoi créer un profil? Une clinique cardiologique a besoin de données sur les patients différentes de celles d'une clinique pédiatrique. Chaque spécialité médicale a des directives cliniques et des exigences de rapport uniques qui définissent quelles données doivent être recueillies et comment. Les exigences légales varient également selon le pays et la spécialité.

Au lieu d'accepter toute ressource Patient répondant à la spécification FHIR de base, un profil dirige votre système pour n'accepter que les enregistrements satisfaisant à vos exigences cliniques ou métier spécifiques et garantit que votre pipeline de données recueille des informations qui améliorent la qualité et l'exhaustivité des données. Cette approche ciblée réduit les erreurs d'intégration et assure la cohérence des données dans votre écosystème de santé.

Examinons un profil Patient qui applique la qualité des données et la prise en compte des fuseaux horaires dans notre application de santé. Ce profil illustre comment combiner les capacités de base de FHIR avec des extensions personnalisées pour répondre à des besoins métier spécifiques.

Le profil exige trois éléments clés :

Le nom du patient (obligatoire pour une identification appropriée)
Le sexe (obligatoire pour un contexte clinique précis)
Notre extension Timezone (obligatoire pour la planification des rendez-vous)

En rendant ces champs obligatoires et en incorporant notre extension de fuseau horaire, nous assurons une collecte de données cohérente dans l'ensemble de notre système.

{
  "url": "http://my-organization.io/package-1/my-patient",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Patient",
  "name": "MyPatient",
  "status": "active",
  "kind": "resource",
  "type": "Patient",
  "abstract": false,
  "derivation": "constraint",
  "resourceType": "StructureDefinition",
  "differential": {
    "element": [
      {
        "id": "Patient.name",
        "path": "Patient.name",
        "min": 1
      },
      {
        "id": "Patient.gender",
        "path": "Patient.gender",
        "min": 1
      },
      {
        "id": "Patient.extension",
        "path": "Patient.extension",
        "min": 1,
        "slicing": {
          "rules": "open",
          "discriminator": [{ "path": "url", "type": "value" }]
        }
      },
      {
        "min": 1,
        "max": "1",
        "sliceName": "TimeZone",
        "path": "Patient.extension",
        "id": "Patient.extension:TimeZone",
        "type": [
          {
            "profile": [ "http://my-organization.io/package-1/time-zone" ],
            "code": "Extension"
          }
        ]
      }
    ]
  }
}

Remarque : Quelle que soit la spécialisation de vos profils — que vous héritiez de plusieurs profils ou ajoutiez des règles de validation strictes — toute ressource qui passe votre validation de profil reste une ressource FHIR valide à la base. Les autres systèmes FHIR peuvent toujours travailler avec vos ressources, même s'ils ne comprennent pas vos règles de profil spécifiques. C'est ce qui rend FHIR véritablement puissant — vous obtenez à la fois normalisation et flexibilité.

Exemple minimal de patient valide selon la version finale de notre profil :

{
  "meta": { "profile": ["http://my-organization.io/package-1/my-patient"] },
  "extension": [
    {
      "url": "http://my-organization.io/package-1/time-zone",
      "valueCode": "America/Los_Angeles"
    }
  ],
  "name": [{ "given": ["John"], "family": "Doe"}],
  "gender": "male",
  "resourceType": "Patient"
}

SearchParameter : Trouver ce dont vous avez besoin

SearchParameter = ressources FHIR + vos capacités de recherche personnalisées. Ils vous permettent d'inventer de nouvelles façons de rechercher et de filtrer des ressources au-delà des paramètres de recherche FHIR standard.

Pourquoi étendre la recherche? Les paramètres de recherche FHIR standard comme « name » ou « birthdate » sont utiles, mais les flux de travail réels exigent des requêtes plus riches — trouver des patients par champs personnalisés (extensions), localiser tous les résultats de laboratoire au-dessus d'un seuil, ou effectuer des recherches dans plusieurs ressources en une seule requête.

Différentes équipes ont besoin de différentes façons de trouver des données : le personnel clinique par symptômes et diagnostics, la facturation par assurance et codes de procédure. Au lieu de construire une logique de requête complexe côté client ou de maintenir des points de terminaison de recherche personnalisés, vos définitions SearchParameter rendent les requêtes avancées disponibles via les API FHIR standard. Cette approche normalisée garantit que tous les systèmes peuvent effectuer les mêmes recherches de façon cohérente.

Exemple : Réutilisons notre extension de fuseau horaire pour identifier les patients dans des fuseaux horaires spécifiques. Si une ressource Patient inclut une extension précisant son fuseau horaire, un SearchParameter peut utiliser FHIRPath pour filtrer les patients en fonction de la valeur de cette extension. Cela permet des recherches telles que GET /Patient?timezone=America/Los_Angeles pour récupérer les patients dans le fuseau horaire du Pacifique.

{
  "url": "http://my-organization.io/package-1/SearchParameter/Patient-timeZone",
  "id": "Patient-timeZone",
  "base": ["Patient"],
  "description": "Search patient by their time zone",
  "expression": "Patient.extension.where(url='http://my-organization.io/package-1/time-zone').value",
  "name": "timezone",
  "status": "active",
  "type": "token",
  "code": "timezone",
  "resourceType": "SearchParameter"
}

Comment fonctionne FHIRPath (tour d'horizon rapide)

Navigation par point – Patient.address.city parcourt l'arborescence JSON comme une notation objet.
Filtre where() – extension.where(url='…') ne conserve que les éléments correspondants.
Cast ofType() – value.ofType(Quantity) restreint les champs polymorphes (qui contiennent plus d'un type de données).
Chaînage – Vous pouvez enchaîner ces éléments pour atteindre n'importe quelle valeur imbriquée.

Comme chaque serveur comprend FHIRPath, la même expression produit des résultats identiques chez tous les fournisseurs.

Votre IG peut exiger la prise en charge de paramètres de recherche spécifiques. Cela garantit que toutes les implémentations fournissent les capacités de recherche dont votre organisation a besoin.

Opérations : Logique métier du domaine

Les opérations = API FHIR normalisée + vos points de terminaison personnalisés propres au domaine.

Elles vous permettent de définir des méthodes API complexes au-delà des simples opérations CRUD sur les ressources.

Pourquoi définir des opérations? Les flux de travail de santé ont parfois besoin de calculer des interactions médicamenteuses, de générer des rapports cliniques ou de traiter des vérifications d'admissibilité complexes. Les opérations REST FHIR standard (GET, POST, PUT, DELETE) fonctionnent très bien pour la gestion de base des ressources, mais elles n'exécutent pas de logique métier sophistiquée.

OperationDefinition décrit l'interface de votre opération personnalisée — paramètres d'entrée, format de sortie et documentation du comportement.

Exemple : Opération personnalisée Patient/$schedule-teleconsultation-window

Dans les environnements de soins distribués, en particulier avec la télémédecine, la planification doit tenir compte des fuseaux horaires du patient et du prestataire. Une opération FHIR personnalisée peut automatiser la coordination des plages horaires adaptées aux consultations virtuelles.

Cette opération prend en charge des paramètres d'entrée optionnels pour personnaliser la logique de planification :

practitioner (Reference) Avec qui le patient souhaite prendre rendez-vous. Une référence à une ressource Practitioner ou PractitionerRole. Leur disponibilité est utilisée pour calculer les plages possibles.
daysAhead (integer, défaut : 7) Jusqu'où dans le futur regarder. Limite la recherche aux N prochains jours. Utile pour éviter un calcul inutile.
slotDuration (Duration, défaut : 30 minutes) Durée minimale du rendez-vous. Filtre les plages plus courtes — par exemple, une consultation doit durer au moins 30 minutes.

Ces paramètres aident le client (p. ex., une application patient ou un outil de coordination des soins) à adapter le résultat aux contraintes réelles telles que les horaires des prestataires, les besoins des patients ou les politiques du système.

{
  "resourceType": "OperationDefinition",
  "id": "schedule-teleconsultation-window",
  "url": "http://my-organization.io/package-1/OperationDefinition/schedule-teleconsultation-window",
  "name": "ScheduleTeleconsultationWindow",
  "status": "active",
  "kind": "operation",
  "code": "schedule-teleconsultation-window",
  "resource": ["Patient"],
  "system": false,
  "type": true,
  "instance": true,
  "parameter": [
    {
      "name": "practitioner",
      "use": "in",
      "type": "Reference",
      "min": 1,
      "max": "1",
      "documentation": "Practitioner to check availability for"
    },
    {
      "name": "daysAhead",
      "use": "in",
      "min": 0,
      "max": "0",
      "type": "integer",
      "documentation": "Number of days into the future to check"
    },
    {
      "name": "slotDuration",
      "use": "in",
      "min": 0,
      "max": "1",
      "type": "Duration",
      "documentation": "Minimum desired duration for appointment slot"
    },
    {
      "name": "availableSlot",
      "use": "out",
      "min": 1,
      "max": "100",
      "type": "BackboneElement",
      "part": [
        { "name": "start", "use": "out", "type": "dateTime", "min": 1, "max": "1" },
        { "name": "end",   "use": "out", "type": "dateTime", "min": 1, "max": "1" }
      ]
    }
  ]
}

Remarque : Définir un OperationDefinition dans votre IG documente l'interface et les exigences de l'opération, mais n'implémente pas automatiquement la fonctionnalité — votre serveur FHIR doit fournir l'implémentation réelle.

Prendre en charge toutes les opérations de tous les guides d'implémentation existants serait impratique et gourmand en ressources. À la place, les serveurs FHIR implémentent généralement les opérations couramment utilisées provenant des IG publics largement adoptés et offrent la possibilité d'étendre l'API FHIR avec vos propres opérations. Par exemple, Aidbox offre un modèle flexible de passerelle API grâce à sa fonctionnalité « App », vous permettant d'implémenter des opérations personnalisées via des fonctions lambda ou des microservices dédiés qui s'intègrent parfaitement au serveur FHIR.

Distribution et packaging

Les guides d'implémentation FHIR peuvent être distribués sous forme de paquets NPM, ce qui les rend faciles à versionner, à partager et à intégrer dans différents systèmes. Cette approche tire parti de l'écosystème NPM familier que les développeurs utilisent déjà pour les dépendances JavaScript et TypeScript.

Notre fichier package.json minimal pour un FHIR IG pourrait ressembler à ceci :

{
    "name": "my.organization.fhir",
    "version": "0.0.1",
    "description": "My Organization IG FHIR Package",
    "author": "My Organization",
    "dependencies": {
        "hl7.fhir.r4.core": "4.0.1"
    }
}

Cette structure de paquet prend en charge la gestion des versions sémantiques de votre IG, la gestion des dépendances pour les spécifications FHIR de base et les autres IG, la distribution facile via les registres NPM, l'identification claire de la compatibilité avec la version FHIR, et l'intégration automatisée des outils.

Pour packager le guide d'implémentation, accédez à votre répertoire IG et exécutez : npm pack

Cela créera un fichier .tgz comme : my-organization-fhir-ig-package-1.0.0.tgz. Vous pouvez également créer une archive tarball manuellement.

L'exemple de guide d'implémentation de cet article est disponible à : https://storage.googleapis.com/my-implementation-guide/my.organization.fhir-0.0.1.tgz

Créez votre instance Aidbox et essayez le guide d'implémentation sur http://aidbox.app.

Pour charger l'IG, suivez la documentation.

Exemples d'IG dans le monde réel

Les IG FHIR ne sont pas seulement théoriques — ils sont fondamentaux pour les efforts d'interopérabilité dans le monde réel. Voici quelques guides largement adoptés :

US Core : Définit l'ensemble de données minimal et les contraintes pour l'échange de données cliniques aux États-Unis. De nombreuses API nationales et DSE sont construits sur cette base.
International Patient Summary (IPS) : Permet l'échange transfrontalier de résumés de patients. Utilisé dans l'UE et à l'échelle internationale.
mCODE (Minimal Common Oncology Data Elements) : Adapte FHIR à l'oncologie, permettant des données structurées et analysables sur le cancer pour les essais cliniques, les soins et la recherche.

Ces exemples montrent comment les IG répondent à des domaines et des cas d'utilisation spécifiques, établissant une norme pour l'interopérabilité et la qualité des données. En les examinant, vous pouvez aligner vos propres IG sur les meilleures pratiques de la communauté.

Voir aussi : Développement agentique d'IG FHIR.