Dans le monde effréné de l’élaboration des normes de santé numérique, l’International Health Terminology Standards Development Organisation (IHTSDO) et le Health Level Seven (HL7) sont en première ligne. Ces organisations, aux côtés de nombreuses autres, qu’elles soient régionales ou spécialisées, travaillent d’arrache-pied à la création et à la révision de guides d’implémentation (IG). L’objectif : atteindre une spécification parfaite dès la première version. Une ambition louable, mais souvent irréaliste, car un guide qui n’évolue pas est rarement un guide utilisé.
Pour parvenir à une spécification idéale, deux mécanismes organisationnels sont cruciaux : une documentation claire des changements et la possibilité pour les utilisateurs de soumettre des retours et des suggestions d’amélioration. Mais comment savoir précisément ce qui a été modifié ?
Au sein de l’IHTSDO, l’accent est mis sur la production d’une liste conviviale des modifications apportées à chaque nouvelle version. Ces notes, disponibles dans une section dédiée (« Notes roses ») sur la page d’index de chaque IG, ne se focalisent pas sur les corrections mineures comme les fautes de frappe, mais résument les évolutions significatives, par exemple en indiquant « exemples ajoutés ». L’intégralité des versions historiques est également accessible via un lien « Répertoire des versions publiées », généralement placé en évidence sur la page principale de l’IG, permettant de retrouver ces notes de version pour chaque itération.
Pour une analyse encore plus poussée des évolutions, les utilisateurs peuvent consulter les problèmes résolus sur les plateformes de suivi de projet. Dans le cas de l’IHTSDO, cela signifie examiner les « issues » closes sur GitHub, tandis que HL7 utilise Jira. Ces informations, bien que techniques, offrent une transparence complète sur les discussions et les corrections apportées.
Pour ceux qui s’intéressent aux modifications plus techniques des ressources de conformité, une section « Rapport QA » est disponible. Elle contient une « Comparaison des versions précédentes », offrant un aperçu détaillé et généré par ordinateur des différences entre les différentes itérations d’un guide.
L’importance des retours utilisateurs est capitale : « Les normes vivent de commentaires ; c’est vraiment l’aliment qui rend les normes utiles. » C’est pourquoi les organisations encouragent vivement les utilisateurs à soumettre leurs observations. La période de commentaires publics est particulièrement privilégiée, car c’est à ce moment que les équipes prévoient de traiter activement les retours afin de résoudre les points soulevés. Qu’il s’agisse d’une faute de frappe, d’un bug, d’une formulation peu claire, d’un désaccord avec un pair, ou d’une suggestion d’amélioration des fonctionnalités, tous les commentaires sont bienvenus. Il est même possible de soumettre des suggestions une fois la période de commentaires publics terminée, pendant la phase d’essai ou même lorsque l’IG atteint son statut définitif.
Pour soumettre un commentaire sur un guide d’implémentation donné, deux méthodes sont proposées. La première consiste à ouvrir un « issue » sur GitHub. La seconde, accessible via un lien « Proposer un changement », est un formulaire web ouvert à tous, membres ou non de l’organisation.
En conclusion, à mesure qu’une spécification gagne en maturité et s’approche du statut normatif (Texte Final), les modifications deviennent moins fréquentes. Idéalement, un texte définitif ne devrait pas intégrer de changements susceptibles de rompre la compatibilité avec les versions antérieures. Cependant, le statut d’une spécification ne devrait jamais dissuader les utilisateurs de partager leurs commentaires, quel que soit le moment.