Les personnages sont à leur poste, nous avons une carte des communications à l’endroit. Tu vois, la bataille pourrait commencer… si seulement ils avaient des outils pour collaborer à une action commune.
En réalité, tous ces gens travaillent depuis des siècles en s’envoyant des comptes rendus par la poste. C’est une habitude ancienne, et d’ailleurs bien peu d’entre eux utilisent le courrier électronique. L’une des raisons les plus profondes c’est que, si tu te souviens bien, le DMP ne sert à rien s’il ne donne pas à tout moment une idée claire de l’état de la bataille et de la stratégie. Tu imagines que ça pourrait marcher si on te donne seulement la liste des comptes rendus de ce qu’ont fait les autres ?
Tu as raison… c’est d’autant plus dur que tu commences juste à lire. Et qu’en plus les Docteurs écrivent tous très mal. Mais s’ils écrivent si mal c’est qu’ils ont très peu de temps, et ils ne peuvent donc pas non plus lire des tas de documents.
Comment ferais-tu toi, si tu voulais avoir une idée claire de ton plan de bataille ? Tu voudrais quelque chose qui ressemble à une carte, avec tes armées qui bougent en laissant des traces. Comme ça tu comprendrais en un clin d’œil tout ce qui s’est passé, et tu pourrais préparer la prochaine action.
Oui, les militaires doivent avoir quelque chose comme ça. C’est bien dommage qu’ils soient les seuls, et ce serait bien d’arriver à faire quelque chose qui ressemble à ça avec le DMP. Il faudrait un serveur adapté à faire partager à toute l’équipe la stratégie de santé en cours pour un patient.
Tu as raison, c’est plus compliqué que de s’envoyer des comptes rendus, mais d’un autre côté les technologies informatiques ont fait beaucoup de progrès… enfin au moins en dehors de la médecine. Je t’avais promis des histoires de télécommandes ; et bien je vais te raconter ce qui s’est passé à ce sujet ces dix dernières années.
Au début, tout le monde s’est intéressé à partager des objets : un objet c’est un truc complexe qui fonctionne sur un serveur ; mais pour le piloter, il faut bien le connaître. C’est comme si ta télécommande de télé ressemblait à ce qui est à l’intérieur de la télé, avec des centaines de boutons, et pour te servir de la télécommande, tu devrais comprendre comment fonctionne l’intérieur de ta télé. Les informaticiens parlent de « couplage fort » et ils n’aiment pas ça parce que c’est difficile à mettre en place et encore plus difficile à faire évoluer. En fait, toi tu n’aimerais pas non plus devoir te passer de télé tant que tu ne sais pas comment le modèle précis que tu veux utiliser fonctionne de l’intérieur : tu préfères des télécommandes très simples.
Alors, les informaticiens se sont intéressés aux services : un service, c’est un truc aussi compliqué qu’on veut de l’intérieur, mais très facile à utiliser de l’extérieur : tu lui donne des informations, il te renvoie un résultat. C’est comme des petites télécommandes avec très peu de boutons. Le problème, comme qu’on se retrouve avec des tas de télécommandes, et que ça ressemble vite à beaucoup de maisons où pour regarder la télé il faut utiliser la télécommande du boîtier câble ou satellite, puis celle de la télé, voire celle du lecteur DVD, et parfois de l’amplificateur de la chaîne HIFI. Bref, on n’a pas à savoir comment ça marche de l’intérieur, mais on se perd dans les télécommandes, et surtout on ne sait jamais dans quel ordre les utiliser pour faire quelque chose d’utile.
Alors les informaticiens ont créé très récemment l’architecture orienté services : ça fonctionne avec des services, mais à l’intérieur du système on a prévu à l’avance le type de démarches que veulent faire les gens (on appelle ça un processus métier), et on les a connectés dans le bon ordre. C’est un peu comme si on te proposait des « plateaux à télécommande » qui – pour une fonction donnée, par exemple regarder un DVD avec sortie du son sur la chaîne HIFI te permettait de poser tes télécommandes dessus, puis de rabattre un cache qui laisse uniquement apparent les boutons utiles, dans l’ordre où il faut les utiliser.
Tu vois que les solutions techniques existent. Tu as raison, la question c’est : pourquoi est-ce qu’on ne s’en sert pas ?
D’abord parce que dans le domaine médical les gens aiment bien faire autrement qu’ailleurs. Par exemple à l’hôpital, on a commencé à mettre en place des services assez disparates, avec une norme qui s’appelle HL7v2, et comme les gens se sont rendu compte qu’ils n’arrivaient pas à les enchaîner correctement, ils ont commencé à travailler à les coupler ensemble autour de processus métier avec des recommandations appelées IHE. On n’est pas très loin de l’architecture orientée services, en un peu moins construit.
Mais en ce moment, arrive des Etats-Unis un énorme machin appelé HL7v3 qui est une caricature de la démarche objet (dont, si tu te souviens, personne ne voulait après l’avoir essayé) et qui bouscule tout alors que personne ne saura probablement jamais s’en servir. Sans compter la vieille norme européenne d’échange de bouts de dossiers patients qui annonce qu’elle va enfin sortir alors que plus personne ne l’attend.
Mais le pire, c’est que, comme tu l’as bien compris, tout ça ce ne sont que des jouets d’informaticiens tant qu’on n’a pas défini les fameux processus métiers : le "à quoi ça sert, à qui, et pour quoi faire". Et pour la première ligne, l’endroit où se jouent les vrais enjeux de la santé des gens, et bien à part la Ligne de vie, qui bénéficie depuis de nombreuses années du travail patient de nombreux médecins de terrain européens, il n’y a personne qui s’intéresse seulement à les définir, ces processus métiers. Ce ne sont donc que des jeux stériles d’informaticiens, d’autant plus à l’aise dans cet exercice qu’ils le pratique depuis longtemps dans les hôpitaux.
Tu as raison… nous ne sommes pas sorti de l’auberge si nous ne finissons pas rapidement notre architecture de services de Lignes de vie. Allez, je te laisse jouer avec les télécommandes, et je m’y remets.