Cet article fait partie d'une série sur les sessions de Health Samurai lors du HL7 FHIR DevDays 2025. Dans cet article, « FHIR Schema : résultats de la première année — évolution de l'écosystème et expérience développeur », Evgenii Mukha, ingénieur logiciel chez Health Samurai, partage les leçons tirées d'une année d'exploitation d'un nouveau moteur de validation FHIR en production.
Ce que vous apprendrez :
- Pourquoi les validateurs FHIR existants divergent sur les mêmes données et ce que cela signifie pour l'interopérabilité.
- Ce qu'est FHIR Schema et en quoi il diffère des StructureDefinitions brutes.
- Comment l'algorithme de validation sans instantané permet les vérifications multi-profils et les ajustements à l'exécution.
- Ce que l'équipe a appris de l'utilisation en conditions réelles et vers quoi FHIR Schema se dirige.
Le problème : une validation incohérente
La présentation s'ouvre sur un cas limite simple mais révélateur : une ressource Patient contenant une extension primitive avec des valeurs nulles qui devrait enfreindre une contrainte FHIRPath el-1. Différents serveurs publics le traitent de manières complètement différentes, allant de la suppression silencieuse de la valeur à son acceptation ou au signalement d'erreurs sans rapport. Cela illustre le fait que la validation, qui devrait être une pierre angulaire de l'interopérabilité, se comporte de façon imprévisible selon les implémentations.
Le problème fondamental n'est pas uniquement des bogues, mais une spécification de validation insuffisamment définie, dont les détails clés concernant le découpage, la terminologie et les cas limites sont éparpillés dans des conversations sur Zulip et des tickets dans JIRA plutôt que dans un document clair orienté vers les implémenteurs. Les auteurs de moteurs manquent d'une orientation précise comparable à ce qui existe pour FHIRPath, ce qui rend difficile l'atteinte d'une compatibilité complète.
L'approche FHIR Schema
FHIR Schema est présenté comme un moyen de fournir aux implémenteurs une représentation partagée et indépendante du langage des contraintes de validation, ainsi qu'un algorithme de validation précis. Il est dérivé des StructureDefinitions plutôt que de les remplacer, et se compose de trois parties principales : un transpileur qui convertit les StructureDefinitions en fichiers de schéma, un format de schéma JSON/YAML représentant les contraintes sous forme d'arbre, et un algorithme de validation accompagné d'une suite de tests.
L'objectif est que les moteurs de validation dans différentes piles technologiques réutilisent la même représentation de schéma au lieu d'inventer leurs propres modèles internes. Cela devrait rendre le comportement plus prévisible et réduire les divergences entre les serveurs.
Schéma en arbre et validation sans instantané
Là où les StructureDefinitions listent les éléments sous forme de tableau plat, FHIR Schema les organise en un arbre explicite qui reflète les données FHIR réelles. Les éléments définissent les clés possibles, les tableaux sont des entités de première classe, les liaisons terminologiques et les éléments polymorphes sont modélisés directement, et les champs obligatoires ou exclus sont représentés sans avoir à deviner à partir des cardinalités. Le découpage est exprimé sous forme de correspondances qui déterminent si un élément appartient à une tranche, selon des critères tels que les liaisons, les motifs ou la validité des profils.
L'algorithme de validation construit un ensemble de schémas pertinents (ressource de base, profils et ancêtres), vérifie les invariants de premier niveau, puis parcourt l'arbre de ressources en appliquant les vérifications au niveau des nœuds et les règles de découpage. Comme il fonctionne sans instantanés préconstruits, il prend en charge les modifications des contraintes à l'exécution, la validation simultanée par rapport à plusieurs profils, et la découverte de profils en testant quels schémas correspondent aux données existantes.
Apprentissages en production et feuille de route
Après une année d'utilisation en production dans Aidbox, plusieurs leçons ont émergé : la transpilation doit être sans état et reproductible ; les groupes de découpage doivent avoir une portée unique lorsque plusieurs profils sont appliqués ; et un modèle de signalement des erreurs plus clair est nécessaire pour que les outils et les suites de tests puissent comparer les résultats de manière fiable. Ces points montrent que standardiser le format et l'algorithme n'est qu'une partie du travail — la sémantique des erreurs compte également.
Pour la suite, l'équipe prévoit d'ouvrir sa suite de tests, de publier des implémentations de référence en JavaScript et en Clojure, et de publier une spécification versionnée sous une forme plus « proche de FHIR », accompagnée d'un groupe de travail axé sur les implémenteurs de validateurs. L'objectif est de passer d'un seul moteur avec des tests internes à un écosystème plus large de moteurs compatibles et de cas de test partagés.
Pourquoi cela importe pour les équipes FHIR
Pour les organisations qui construisent ou intègrent des serveurs FHIR et des validateurs, FHIR Schema offre une voie plus claire vers une validation cohérente. Les auteurs de moteurs disposent d'un format et d'un algorithme implémentables au lieu d'avoir à reproduire le comportement par rétro-ingénierie d'une seule implémentation de référence. Les équipes ont de meilleures chances d'obtenir des résultats réussite/échec cohérents entre les serveurs et peuvent accéder à des scénarios avancés tels que la validation multi-profils et l'ajustement des contraintes à l'exécution. Cela rend les systèmes fondés sur FHIR plus faciles à déboguer et plus prévisibles dans les scénarios d'interopérabilité réels.
Ressources
Visionnez la présentation complète d'Evgenii au FHIR DevDays 2025 et la liste de lecture complète de Health Samurai : Visionner la vidéo complète Liste de lecture complète sur YouTube
Connectez-vous avec Evgenii sur LinkedIn ou via le fil Zulip de FHIR Schema.
Explorez ces ressources FHIR Schema : Ébauche de spécification Terrain de jeu Exportation du paquet transpilé Impl. de référence (CLJ) Impl. de référence (JS)
Voir aussi : Type Schema : construire des SDK FHIR.
