Rendre visibles les données cliniques complexes avant qu'elles ne deviennent un modèle
La mesure de la tension artérielle semble simple jusqu'à ce qu'Ian McNicoll demande ce qu'elle doit signifier dans un dossier médical. Quelles unités doit-elle prendre en charge ? Quelle était la position du patient ? Quel contexte doit accompagner ce chiffre ? Pour Ian, informaticien clinique et ancien médecin généraliste écossais, ces questions se situent à la frontière de la médecine et du logiciel.
En tant que fondateur et directeur général de freshEHR Clinical Informatics, membre du conseil d'administration et ancien co-président d'openEHR International, Ian aide à transformer les connaissances cliniques en modèles de données réutilisables. Bien avant que ces modèles n'atteignent un système technique, lui et la communauté openEHR au sens large utilisent Xmind pour rendre leur structure visible.
Une seule mesure peut contenir tout un arbre de décisions
Lorsqu'Ian explique la modélisation des données cliniques, il commence souvent par quelque chose de familier : le poids corporel. Son enregistrement peut sembler ne nécessiter qu'un seul chiffre. C'est alors que les questions commencent. Le modèle doit-il accepter les kilogrammes et les mesures impériales ? L'enfant a-t-il été pesé avec ses vêtements ? La mesure nécessite-t-elle un commentaire ? Comment le même concept fonctionnera-t-il dans différentes langues ?
La tension artérielle apporte ses propres ramifications : valeurs systolique et diastolique, posture du patient, circonstances de la mesure et contexte clinique global. Chaque réponse peut révéler une autre décision qui doit être représentée clairement.
Ian décrit les données et les idées médicales comme arborescentes et fractales. Leur signification dépend non seulement des points de données individuels, mais aussi de la manière dont ces points sont liés les uns aux autres. Pour les personnes qui élaborent des modèles cliniques partagés, le défi ne consiste pas simplement à collecter des informations. Il s'agit de trouver une structure que les cliniciens peuvent comprendre, remettre en question et affiner avant que quoi que soit ne soit figé dans un logiciel.
Un Schéma jette un pont entre le tableur et le système
Les Schémas d'Ian occupent une place spécifique dans le processus de modélisation. Ils se situent entre les exigences fournies par les cliniciens et les modèles formels que les systèmes logiciels utiliseront finalement.
Des exigences cliniques à une structure visible
Le travail commence souvent par un tableur fourni par un groupe de cliniciens. Un ophtalmologue, par exemple, peut lister toutes les informations à collecter sur le glaucome. Les lignes capturent les exigences, mais elles ne révèlent pas nécessairement la forme clinique sous-jacente.
Ian reconstruit ce contenu dans Xmind. Une structure mixte — un organigramme en haut et un arbre logique plus bas — lui permet de passer de l'organisation générale d'un ensemble de données à ses ramifications cliniques plus détaillées. Il peut ainsi relier les points de données demandés aux modèles openEHR existants et identifier les besoins potentiels de nouveaux développements.
Chaque choix visuel a une signification pratique :
Les marqueurs indiquent quels points de données sont prêts et lesquels nécessitent encore de l'attention.
Les frontières regroupent les listes de codes associées.
Les notes conservent les explications de la source originale.
Le mode Outliner présente la même structure sous forme linéaire lorsque celle-ci est plus facile à réviser.
Ensemble, ces détails aident Ian à transformer un tableur plat en une structure qui reflète la manière dont les cliniciens comprennent les données.
D'un Schéma de travail à un modèle de données formel
Le Schéma n'est pas le modèle clinique final. C'est l'espace préparatoire où la communauté interprète un tableur, organise ses relations et décide de la place de chaque élément dans un tableau clinique plus large.
Une fois la structure claire, des outils openEHR dédiés sont utilisés pour créer des archétypes et des modèles formels exploitables par les systèmes logiciels. Ces modèles peuvent ensuite être révisés, traduits, versionnés et ajoutés à une bibliothèque partagée.
Xmind ne remplace pas l'expertise clinique ni la modélisation technique. Il offre aux deux parties un espace commun pour s'accorder sur la signification du modèle avant qu'elle ne soit traduite en code.
Une structure unique devient le langage d'une communauté
Ian a intégré Xmind pour la première fois dans son flux de travail il y a au moins dix ans, après que la communauté a testé un autre outil de carte mentale. La possibilité de combiner différentes structures correspondait parfaitement à l'évolution de ses modèles. Sans aucune obligation formelle, Xmind est progressivement devenu ce qu'Ian appelle le « standard de fait » de la communauté pour cette phase initiale de la chaîne d'outils.
La communauté openEHR est internationale et collaborative. Cliniciens et modélisateurs partagent des fichiers .xmind sur leur forum de discussion, révisent les modèles, les traduisent et renvoient le travail finalisé dans une bibliothèque commune. Les membres expérimentés recommandent souvent Xmind aux nouveaux venus, mais l'outil s'impose par l'utilité de sa structure, et non par contrainte de participation.
Ce langage visuel partagé permet à des personnes d'horizons divers de se rencontrer à mi-chemin. Un clinicien n'a pas besoin de maîtriser un langage de modélisation technique pour vérifier si les branches reflètent la pratique réelle. Un modélisateur peut suivre comment chaque champ demandé s'intègre dans le tableau clinique global.
Les modèles formels issus de ce processus élargi soutiennent des projets de santé dans plusieurs pays, notamment le Universal Care Plan à Londres et des initiatives openEHR en Allemagne, en Slovénie et en Irlande. Le déploiement à grande échelle intervient plus tard. La première étape consiste toujours, pour un groupe de personnes, à s'assurer qu'elles parlent bien de la même chose.
Le modèle commence par une question visible par tous
Pour Ian, une carte mentale est d'autant plus utile que les réponses ne semblent pas encore définitives. Elle maintient les hypothèses cliniques visibles tant qu'elles peuvent être contestées, réorganisées et améliorées. Au moment où un modèle atteint une base de données, l'essentiel de sa signification a déjà été décidé.
Le système finalisé peut contenir une tension artérielle, un poids corporel ou les volontés d'un patient. Derrière chaque champ se cache un arbre de choix que quelqu'un a dû expliciter. Le travail d'Ian commence par donner à ces choix une forme que cliniciens et technologues peuvent visualiser ensemble.
