Outils, registres et plateformes de test FHIR

• Quoi : la boîte à outils d'un implémenteur FHIR se compose d'un langage de rédaction (FSH) avec son compilateur (SUSHI), d'un outil de construction (l'IG Publisher), de registres de paquets, d'un validateur, de serveurs de terminologie, de bibliothèques et de plateformes de test^[1][2][3][4].

• Comment : un guide est publié sous la forme d'un seul paquet NPM contenant des ressources de conformité, et les outils récupèrent ces paquets via l'API de paquets^[5][3].

• Qui le produit : le noyau (IG Publisher, validateur, FSH) provient de HL7 et de la communauté FHIR, avec des bibliothèques open source comme HAPI FHIR à côté de produits de fournisseurs comme ceux de Firely et d'AEGIS^{[6][4][7][8][9]}.

• Pas pour la production : ni le validateur en ligne de commande ni le site web du validateur ne conviennent à la production, et tx.fhir.org n'a pas de SLA et enregistre, pour chaque code validé, aussi l'adresse IP^[4].

• Belgique : BE Core 2.2.0 est rédigé en FSH et a été construit avec IG Publisher v2.3.2 et le serveur de terminologie dte-tx de la Plate-forme eHealth^[10][11].

• Principale incertitude : quel serveur de terminologie belge est destiné à la production ; le résumé de l'enquête qualifie son statut de « peu clair », et les guides n'utilisent pas tous le même serveur^[12][13][14].

HL7 FHIR is een standaard, maar wie hem toepast, werkt met een gedeelde set tools. Een implementatiegids (IG) bundelt profielen, extensies en waardelijsten; een FHIR-pakket groepeert zulke conformiteitsresources (zoals StructureDefinitions en ValueSets) als NPM-pakket, en elke gids wordt als één zo'n pakket gepubliceerd^[5]. De tools op deze pagina dekken de hele levensloop van zo'n gids: schrijven, bouwen, verdelen, valideren en testen.

De keten begint bij het schrijven. FHIR Shorthand (FSH) is een tekstuele taal die gidsauteurs hun bedoeling directer laat uitdrukken, met minder aandacht voor de onderliggende FHIR-mechanica^[15]. SUSHI is de referentie-implementatie: een compiler op de opdrachtregel die FSH omzet^[1]. De IG Publisher van HL7 zet een reeks invoerbestanden om in een standaard FHIR-gids, maar biedt zelf geen auteursomgeving^[2]; de bron wordt met andere tools gemaakt, zoals SUSHI, Simplifier of gewone tekst-, JSON- en XML-editors^[6]. FSH en SUSHI zijn in de IG Publisher en in Simplifier.net geïntegreerd, zodat een FSH-bron rechtstreeks tot een volledige gids kan worden verwerkt^[15]. Gewoonlijk staat de hoofdbron van een gids in een publieke GitHub-repository^[6].

Daarna volgen verdelen en valideren. Volgens de FHIR-specificatie staan alle pakketten op het register packages.fhir.org, dat vooral door tools via de pakket-API wordt gebruikt; packages2.fhir.org is een tweede register^[3]. De FHIR Validator is een zelfstandige Java-tool die vanaf de opdrachtregel controleert of een resource conform is aan de basisspecificatie, aan toepasselijke gidsen en profielen, en aan terminologieregels^[4]. Voor codes uit SNOMED CT, LOINC, RxNorm of ICD-10 vraagt de validator standaard de terminologieserver tx.fhir.org; enkel de te valideren concepten worden doorgestuurd^[4]. Een terminologieserver is een dienst die codes opzoekt, valideert en waardelijsten uitklapt (zie Serveur national de terminologie (FHIR)).

Voor de API-specificaties waarop veel van deze tools testen, zie SMART App Launch (SMART on FHIR) en FHIR Bulk Data Access ($export).

Le tableau énumère les outils dans l'ordre du cycle de vie d'un guide ; il ne les classe pas. Ce qu'un fournisseur dit de son propre produit figure comme information fournisseur.

Rédiger et construire

Le FSH est largement utilisé : en mars 2024, le FSH Finder recensait plus de 600 projets de développement de guides utilisant le FSH^[15]. La release 3.0.0 est mixte : la majeure partie du langage est normative, quelques fonctionnalités plus récentes sont en trial use^[15]. SUSHI est mis à jour en continu ; la version 3.21.0 a apporté de petites améliorations et des corrections de bogues, dont des améliorations de performance^[32]. L'IG Publisher lui-même se limite à la construction : il laisse la rédaction de la source à d'autres outils^[6].

Distribuer et trouver

Le registre et le téléchargement de paquets depuis celui-ci sont gratuits ; le dépôt de paquets dans le registre peut aussi être gratuit, mais est quelque peu laborieux, et des options plus simples comme Simplifier.net demandent un abonnement^[20]. À côté des registres de paquets existe le registre FHIR registry.fhir.org, où les concepteurs conservent les artefacts de conformité de leur profilage afin que d'autres puissent les trouver et les télécharger^[20]. Sur fhir.org figure en outre une liste de guides de la communauté FHIR, avec un renvoi vers le registre complet^[21].

Valider et terminologie

Le validateur est open source et est fourni par le projet FHIR en collaboration avec HL7, Smile CDR et le projet HAPI FHIR^[4]. Il est disponible sous forme de fichier jar prêt à l'emploi sur GitHub et comme service web sur validator.fhir.org ; Inferno sur HealthIT.gov en est un reconditionnement public^[4]. La bibliothèque sous-jacente org.hl7.fhir.core contient aussi trois modules expérimentaux pour FHIR R6 qui ne conviennent pas encore à la production^[17].

La restriction relative à la production est explicite. Ni le validateur en ligne de commande ni le site web du validateur ne conviennent à un usage en production^[4]. En production, un serveur de terminologie propre est nécessaire, car tx.fhir.org n'a pas de SLA et n'est pas pris en charge pour un usage en production^[4]. Le tx-registry international dit la même chose de tous les serveurs de l'écosystème d'outils FHIR : ils servent à la conception et à la publication, pas à des systèmes opérationnels^[33]. S'y ajoute un point de confidentialité : pour chaque code validé, tx.fhir.org enregistre aussi l'adresse IP de l'expéditeur, dans un journal tournant de quelques heures^[4].

Le logiciel derrière tx.fhir.org, FHIRsmith, est une boîte à outils serveur open source de la communauté FHIR sous BSD-3^[23]. Ontoserver est développé par l'Australian e-Health Research Centre du CSIRO^[25]. Snowstorm fournit notamment l'API serveur derrière le SNOMED International Browser^[27], et son API FHIR implémente le module de terminologie de FHIR R4^[28]. Pour en savoir plus sur Snowstorm en Snowstorm Lite (terminologieservers van SNOMED International) et sur les serveurs belges, voir leurs pages respectives.

Bibliothèques et serveurs

HAPI FHIR est une API Java pour clients et serveurs FHIR^[7], open source sous l'Apache Software License 2.0^[7]. Firely se présente comme fournisseur de logiciels et de services FHIR « from the initiators of FHIR » (affirmation du fournisseur)^[34]. Selon sa propre documentation, le Firely .NET SDK est un SDK pour travailler avec FHIR sur la plateforme .NET^[18] et Firely Server est le serveur FHIR de l'entreprise, autrefois appelé « Vonk »^[19].

Tester

Inferno Core est la bibliothèque centrale de l'Inferno Framework pour écrire, exécuter et diffuser des tests de conformité exécutables pour FHIR^[29]. Les kits de test sont étendus en permanence : en novembre 2026, la version 1.0.0 d'un kit de test de certification ONC pour la Coverage Requirements Discovery API s'est ajoutée sur Inferno sur HealthIT.gov^[30]. Touchstone d'AEGIS est, selon le fournisseur, un service d'infrastructure et de test pour l'échange d'informations de santé^[9], construit dès le départ sur la ressource FHIR TestScript^[9].

En Europe, l'Interoperability Test Bed de la Commission européenne a construit, pour les tests de conformité de Vitalink, une preuve de concept qui encapsule une instance du validateur FHIR afin d'exécuter des validations complexes pour des cas de test paramétrables^[31]. Cette preuve de concept a été menée à bien en décembre 2023 ; un passage en production n'a pas été confirmé^[31]. Selon la Commission, la même preuve de concept est aussi utilisée dans un harnais de test pour FHIR et les WHO SMART Guidelines, et non pour la spécification HL7 SMART App Launch^[31].

Sites de référence et communauté

fhir.org est le site de la HL7 FHIR Foundation, qui se présente comme « the home for FHIR Implementers »^[22]. Pour les questions sur FHIR Shorthand, SUSHI renvoie au FHIR Community Chat sur chat.fhir.org^[1]. Le chapitre R5 sur le soutien à l'implémentation indique que l'essentiel du travail de soutien a quitté la spécification pour le Confluence de HL7 et la communauté, et que peu de travail supplémentaire y est prévu^[35].

Les guides belges (Guides d'implémentation FHIR belges) suivent la même chaîne. Le fichier ig.ini de BE Core fait utiliser par l'IG Publisher la ressource ImplementationGuide générée par SUSHI : le guide de base belge est rédigé en FSH et construit avec l'IG Publisher^[10]. Le rapport QA de BE Core 2.2.0 a été généré le 19 août 2026, sur FHIR 4.0.1^[11], avec la version v2.3.2 de l'IG Publisher^[11]. Le serveur de terminologie utilisé pour ce build était celui de la Plate-forme eHealth (dte-tx.ehealth.fgov.be/r4), et non tx.fhir.org^[11]. HL7 Belgium travaillait déjà en 2021 à des procédures pour publier lui-même officiellement, avec l'IG Publisher, des guides pour des spécifications communautaires^[36].

Simplifier joue aussi un rôle : HL7 Belgium publie de préférence ses profils sous forme de guide d'implémentation, avec les ressources également sur Simplifier.net^[37]. Dans la phase de groupe de travail, les artefacts de conception sont publiés provisoirement, comme projet dans un registre public tel que Simplifier et/ou comme guide sur GitHub^[38].

Les guides belges n'utilisent pas tous le même serveur de terminologie lors de leur build. Le guide core-clinical v1.3.0 utilisait dte-tx comme serveur principal, avec le module belge de SNOMED CT comme version du système^[13], tout comme le guide public-health v1.0.4^[39]. Le guide medication v1.1.1 utilisait tx.fhir.org comme serveur principal^[14]. Dans le rapport de build du guide PSS v1.1.0, l'Ontoserver du SPF a été trouvé comme serveur faisant autorité pour SNOMED CT^[40]. dte-tx tourne sur FHIRsmith, le même logiciel que tx.fhir.org^[23], et la réponse à la racine du serveur porte le message « FHIR Development Server »^[41]. Par ailleurs, le SPF Santé publique documente un serveur national de terminologie basé sur Ontoserver, avec son propre endpoint FHIR^[42], et mentionne le Terminology Portal DTS, un serveur Snowstorm adapté par la Plate-forme eHealth et exécuté dans un conteneur^[43].

Un résumé publié dans le registre de paquets à partir de la State of FHIR Survey 2026 qualifie de « peu clair » le statut du serveur national de terminologie^[12] et indique que la Belgique penche fortement vers les logiciels FHIR open source plutôt que vers des outils propriétaires^[12]. Ce résumé repose sur un seul contributeur anonyme à l'enquête de Firely et HL7 International^[12].

Les outils eux-mêmes sont en usage et sont mis à jour en continu ; l'état par composant :

Un hôpital ou un fournisseur de DPI utilise ces outils surtout pour contrôler des messages par rapport aux profils belges : le validateur contrôle une ressource par rapport à la spécification de base, aux guides et aux règles de terminologie^[4], et récupère les paquets nécessaires dans le registre^[3]. Pour la production, la limite est nette : le validateur public et le site web du validateur ne s'y prêtent pas^[4], tx.fhir.org n'a pas de SLA^[4], et qui fait valider des codes laisse brièvement sa propre adresse IP chez tx.fhir.org^[4]. Il est possible d'intégrer la validation dans son propre logiciel avec la bibliothèque org.hl7.fhir.core^[17].

Recommandation : n'utilisez le validateur public et tx.fhir.org que pour la conception et le test, pas dans des connexions opérationnelles ; demandez à un fournisseur quel validateur et quel serveur de terminologie son produit utilise en production, et suivez le choix belge entre dte-tx et l'Ontoserver du SPF sur Serveur national de terminologie (FHIR).

• Statut du serveur national de terminologie : le résumé de l'enquête le qualifie de « peu clair »^[12], mais repose sur un seul contributeur anonyme^[12]. Les guides belges ont utilisé lors de leur build dte-tx, tx.fhir.org ou l'Ontoserver du SPF^[13][14][40], et le registre des contradictions note qu'il n'existe pas d'endpoint de production documenté sans ambiguïté (voir Serveur national de terminologie (FHIR)).

• dte-tx comme serveur de développement : BE Core a été construit avec dte-tx^[11], alors que ce serveur se nomme « FHIR Development Server »^[41] et que le tx-registry destine tous les serveurs de l'écosystème d'outils uniquement à la conception et à la publication^[33].

• Échantillon belge : les données de build (version de l'IG Publisher, serveur de terminologie) n'ont été entièrement vérifiées que pour BE Core 2.2.0^[11].

• Information fournisseur : les descriptions de Simplifier.net, des produits Firely et de Touchstone proviennent des fournisseurs eux-mêmes^{[8][18][19][9]}.

• Licences : pour l'IG Publisher, Inferno, Ontoserver et les produits Firely, la licence ne figure pas dans les sources vérifiées de cette page.