Logo ANAP
Ce site requiert l'activation de javascript pour être utilisé, merci de l'activer.
S'abonner

Avis d'experts

Comprendre l'intérêt de gérer l’interopérabilité comme un projet fonctionnel

 48 vues

Cet avis d'expert a été rédigé par Sylvie COIFFARD, Directrice de l'organisation et du système d’information, experte numérique en santé de l’ANAP. Il explique comment et pourquoi aborder l'intéropérabilité comme un projet fonctionnel plutôt que technique.

Interopérer deux systèmes d’informations de santé ou plus, c’est leur faire échanger des informations dans des contextes précis d’utilisation qui doivent être décrits scrupuleusement pour éviter toute erreur d’interprétation ou de perte de sens.

Très souvent dans les projets de mise en place d’interfaces entre deux ou plusieurs systèmes, les seuls sujets abordés au moment des prérequis concernent l’EAI et les normes de communication, « la langue » que vont utiliser les systèmes pour se parler, etc.

Cela ne dit pas ce que les systèmes vont devoir s’échanger en fonction des situations, dans quel ordre, pour quel usage…

Limiter les projets d’interopérabilité aux aspects sémantiques et techniques c’est laisser de côté tous les aspects organisationnels, pourtant source de nombreuses difficultés.

Comment aborder l’interopérabilité par les aspects fonctionnels ?

L’analyse fonctionnelle des organisations doit conduire à décrire les « parcours » de l’information par contexte : quels acteurs la créent, dans quel système, qui la transforme, qui en a besoin et pour quel usage ? L’ensemble devant constituer les règles de gestion qui serviront de cahier des charges aux éditeurs concernés par ces interfaces.

On pourra par exemple procéder au travers d’« un patient traceur » inter-structures comme le proposent les certifications HAS au sein des établissements de santé.

Ces aspects organisationnels peuvent être spécifiés via une cartographie des processus internes autour des systèmes et des utilisateurs concernés. Ces descriptifs doivent permettre de décrire dans tous les cas de figure, du plus simple au plus complexe, comment l’information est partagée sans redondance ni cloisonnement. On pourra procéder de la même manière pour les interfaces avec des systèmes externes à la structure pour permettre une communication optimale.

Quelle forme cela peut-il prendre ?

On peut décrire dans une matrice les règles de fonctionnement par type d’événement en détaillant le processus associé, qui génère l’événement, qui peut le transformer, qui fait quoi dans quoi, etc. ? On peut prendre l’exemple des différentes possibilités de création d’un patient à son arrivée dans un établissement : pour une hospitalisation programmée en séjour ou en ambulatoire, en urgence, en externe … Il devait entrer tel jour mais son entrée a été reportée, il devait venir en hôpital de jour mais il faut le garder en hospitalisation complète, etc…

La démarche d’urbanisation donne cohérence au SI par l’analyse des processus

Le nombre d’interfaces à créer puis à maintenir est de plus en plus important, de par le nombre croissant de logiciels présents dans un établissement de santé et du fait que l’on cherche souvent à tous les faire interopérer. La réflexion sur l’urbanisation du SI englobe la maîtrise de la construction et de l’exploitation des interfaces. Organiser l’interopérabilité, c’est se baser sur les concepts classiques d’urbanisation des SI où l’approche par les processus métiers est indispensable.

Du côté de la méthode, quelques suggestions…

  • Décrire de manière très précise les différents processus de production impactés par l’interface et les règles de gestion associées. Etablir la liste des données structurées à gérer suite à l’analyse des processus. Ce travail de description des scenarii est à faire avec les utilisateurs métier présents dans les processus ;

  • Ecrire le cahier de recette découlant des différents scénarii ;

  • Mettre en place des bases de tests pour jouer le cahier de recette et l’adapter ;

  • Expliquer très en amont à l’éditeur que l’on va lui fournir des spécifications fonctionnelles et qu’il va potentiellement devoir adapter ou paramétrer son interface ;

  • Piloter et prendre le lead sur la coordination des éditeurs concernés par l’interface en particulier dans la phase de recette ;

  • Organiser la mise en production et prévoir les éventuelles actions préalables comme par exemple des phases de dédoublonnages et/ou rapprochement de données si les systèmes concernés fonctionnent déjà de manière autonome ;

  • Prévoir des modes dégradés de fonctionnement en cas d’arrêt de l’un des systèmes mais aussi les modalités de reprises ;

  • Se doter d’outils permettant de superviser l’exploitation des interfaces.

Quelques recommandations à partir de mon expérience…

  • Ne considérez pas que, parce que deux éditeurs disent qu’ils sont déjà interfacés, il n’y a rien à faire : il est très rare que deux établissements aient exactement les mêmes processus de travail…

  • N’acceptez jamais la mise en place d’interfaces bidirectionnelles sans système maître unique : cela vous obligerait forcément à devoir gérer plus tard des cas non prévus et donc de grosses difficultés organisationnelles…

  • Ne croyez pas sur parole un éditeur qui vous dit que son interface est standard et que tout va bien se passer…

  • D’une manière générale restez ferme vis-à-vis des éditeurs et gérez simplement le sujet en mode projet !

Cette réponse vous paraît-elle utile ?

Commentaires ( 1 )

DOLY Anne (HAD CLINIDOM)
posté le 25/10/2017

Bonjour,
Un exemple où l'analyse fonctionnelle peut donner un résultat différent qu'une seule analyse technique : bien que les mêmes flux de données soient mis en jeu, « récupérer un résultat de bactério en vue de la prescription d’antibiotiques pour un patient en réanimation » est différent de « récupérer un résultat de créatinine pour un patient ambulatoire sous chimiothérapie par voie orale »...
Merci Sylvie d'attirer notre attention sur ce sujet !

Pour ajouter un commentaire vous devez vous identifier

Inscription

Vous êtes actuellement sur la page consacrée à Comprendre l'intérêt de gérer l’interopérabilité comme un projet fonctionnel (Avis d'experts).

Vous êtes perdu ?

Haut de page