Kmehr version 2

Introduction
Le projet Kmehr a été développé dans le cadre d'une étude commandée par l'interhospitalière IRIS au CHU de Charleroi en 2001. Cette étude visait à proposer une implémentation concrète de l'avis n°4 de la commission télématique.

La norme Kmehr a été présentée officiellement le 5 décembre 2002, au symposium télématique organisé par le SPF Santé Publique. Il s'agissait d'une proposition de norme dont de nombreux volets restaient et restent encore à définir.

Néanmoins, sur le terrain de nombreux acteurs se sont appropriés ce format et ont commencé à l'utiliser dans le cadre de projets pilotes, voire de projets en production.

L'étude initiale s'était limitée à proposer un format mais n'avait pas inclu les aspects logistiques que nécessitent une telle norme pour sa maintenance.

Le feed-back renvoyé par les projets pilotes a permis d'identifier les adaptations requises à la norme Kmehr et l'infrastructure de support nécessaire pour sa maintenance sur le long terme.

Malheureusement, l'analyse technique poussée nous amène à la conviction qu'une rupture est nécessaire dans la spécification kmehr. La version 2 de kmehr proposée dans le présent document ne sera pas compatible avec la version 1.

Ceci a pour conséquence que la transition devra être organisée soigneusement au niveau fédéral. Il est fondamental que l'infrastructure technique et organisationnelle nécessaire soit mise en place de manière professionnelle avant le déploiement de la version 2 sur le terrain.

Spécifications

Nous nous concentrerons ici sur les aspects techniques de l'évolution de la norme kmehr nécessaires à la rendre plus facilement maintenable. Certaines adaptations sont proposées pour tenir compte de l'évolution des techniques et tirer parti des enseignements des projets pilotes. Un des éléments clés est la gestion dynamique des tables de référence.

L'accès à la documentation technique complète se fait depuis la page d'introduction à Kmehr 2.

Nous résumerons ici les grandes lignes d'évolution proposées :

• Expression de la spécification via les XSchema
  Les contraintes fonctionnelles de Kmehr 1 ont été exprimées par l'association d'une XSchema avec une XSL-T de validation. Celle-ci permettait d'exprimer des conditions particulières difficilement intégrables dans la XSchema et présentait un volet didactique. Une meilleure connaissance de cette technologie et l'apparition de nouveaux outils nous permettent de reconsidérer ce choix et de réintégrer toute la spécification dans le XSchema. Les Xschema sont éclatés en de nombreux fichiers afin d'en faciliter la lisibilité et la maintenance.
• Au niveau des basic datatypes
  • Alignement du type boolean de kmehr sur la spécification du 28 octobre 2004 des datatypes du W3C.
  • Alignement du type date de kmehr sur la spécification du 28 octobre 2004 des datatypes du W3C.
  • Alignement du type time de kmehr sur la spécification du 28 octobre 2004 des datatypes du W3C.
  • Proposition de nouvel élément 'datetime' dans kmehr afin de mieux pouvoir imposer l'encodage de tout ou partie d'un moment.
  • Proposition de nouvel élément 'duration' dans kmehr afin d'éviter l'écueil d'une combinaison quantité/unité variable.
  • Alignement du type decimal de kmehr sur la spécification du 28 octobre 2004 des datatypes du W3C.
  • Proposition des nouveaux éléments 'unsigned' et positivenonzerounsigned afin d'augmenter les possibilités de contraintes au sein de kmehr
  • Alignement du type language de kmehr sur la spécification du 28 octobre 2004 des datatypes du W3C.
  • Alignement du type string de kmehr sur la spécification du 28 octobre 2004 des datatypes du W3C.
  • Imposition d'un attribut de langue non vide au niveau de l'élément text de kmehr.
  • Intégration de l'élément text-with-layout qui était déjà intégré dans les web services de la version 1 et qui permet de véhiculer une mise en page dans un bloc de texte.

• Au niveau des key elements
  • L'élément cd est fondamentalement revu pour permettre une gestion efficace et automatisable des tables de référence. Ce changement rend la version 2 incompatible avec la version 1. L'élément cd fera désormais référence à un espace de noms sous-tendu par un XSchema. Les éléments faisant référence à un code officiel kmehr ne pourront plus véhiculer ni le libellé, ni la langue. L'identification des versions de code est normalisée pour permettre sa gestion automatisée. Un bénéfice secondaire de cette modification est un aspect moins verbeux des éléments cd.
  • L'élément id est également revu en ce sens pour augmenter les capacités de contrainte sur l'identification des éléments clés d'un message kmehr. Un bénéfice secondaire de cette modification est un aspect moins verbeux des éléments id.
  • Ajout d'un attribut show à l'élément lnk afin d'automatiser ou non l'affichage des pièces jointes à un document. Ceci est important pour la diffusion de l'imagerie.

• Au niveau des tables de référence
  • Chaque table de référence est désormais associée à un espace de noms où les contraintes sur les valeurs sont soit exprimées par énumération, soit sous contrainte lexical.
  • Une architecture est proposée pour la gestion des versions de tables de référence. Les valeurs des tables de référence seront gérées uniquement en base de données relationnelle. Un système 'expert' génèrera automatiquement les Xschema correspondant de même que les XSL de visualisation et la documentation. Le modèle de données est proposé.
  • L'architecture dynamique présentée ci-avant permet de fusionner les XSL de validation et de présentation et de rendre celle-ci totalement dynamique. L'aspect multilingue est également intégré.

• Au niveau des contraintes logiques
  • Kmehr a développé très peu de contraintes logiques (comme par exemple l'obligation d'avoir une personne physique comme auteur d'une transaction). Ces contraintes sont à l'origine de la XSL de validation qui pose des soucis de maintenance. La technologie Shematron est proposée pour implémenter les contraintes logiques actuelles et futures de kmehr au sein même des XSchema, faisant ainsi l'économie de la XSL de validation.
  • Au niveau de la spécialisation des transactions et des items
  • Kmehr a été conçu d'une manière très générique laissant souvent à l'émetteur et au récepteur des données la responsabilité d'établir des conventions d'usage. Ainsi l'auteur d'une transaction de prescription est supposé être le prescripteur tandis que celui d'un résultat est le prestataire valideur du résultat. Kmehr est très ouvert et autorise par exemple l'usage d'une date comme contenu d'un diagnostic. D'aucun voudrait spécialiser les transactions et les items pour lever toute ambiguïté. Le concept d'archétype est introduit dans la version 2 pour permettre d'avancer dans cette direction. Nous appelons à la plus grande prudence en la matière car l'équipe de maintenance de la norme pourrait bien vite être débordée par l'abondance de documentation suscitée par cette approche. Si on souhaite typer et contraindre chaque attribut, chaque item, chaque document médical, il serait bon d'envisager l'adoption d'une norme internationale comme HL7. Kmehr devrait rester fidèle à sa philosophie : supporter à court terme l'échange des données cliniques essentielles.

• Au niveau des types complexes
  • L'ensemble de la spécification kmehr a été réécrite pour incorporer les éléments précédents. On la retrouve dans la documentation technique sous c:\kmehrdebug\kmehr2\2006\2.0\XSD\ComplexDataTypes

  Plan d'action

  Une proposition détaillée pour la mise en œuvre de Kmehr 2 a été remise au SPF en septembre 2006.

  Le développement de l'infrastructure technique est à l'étude sous la coordination du Dr Bangels.