Quels services pour l’écosystème des données de santé ?

Cet article poursuit l’examen des aspects à gérer pour créer de la valeur pour les professionnels de santé et les citoyens.

Dans l’article précédent, que vous pouvez retrouver ici, j’ai illustré pourquoi les services détermineront ou non le succès du FSE 2.0. En conclusion, j’ai posé une question clé, à savoir quels services l’EDS doit offrir, s’il doit se limiter aux données uniquement ou inclure des traitements ou des fonctions sur celles-ci.

Essayons d’approfondir cet aspect qui a diverses implications. Mais il faut d’abord réfléchir à la manière dont l’EDS sera utilisé : il s’agira d’un backend qui sera appelé par les systèmes cliniques que les professionnels de santé utilisent déjà, principalement le dossier médical électronique, ou il comportera son propre front-end. qui devra être utilisé par les utilisateurs ou même les deux ? La réponse la plus correcte est la troisième, car il n’est pas raisonnable de penser que les professionnels, au cours de leur pratique clinique, devraient utiliser un système supplémentaire à ceux qu’ils utilisent déjà (et qui sont nombreux).

La situation est différente pour les citoyens. Dans leur cas, il est plus probable que le FSE soit le frontal avec lequel ils utiliseront les services mis à disposition, même si, même dans ce cas, ils pourraient utiliser une application régionale intégrée à l’EDS.

Dans le premier cas (données uniquement), la logique et l’intelligence pour traiter et représenter les données relèveraient de la responsabilité des systèmes “de consommation», dans le second (données plus fonctions) serait supporté par l’EDS. Les systèmes cliniques pourraient ainsi profiter d’une série de fonctions déjà développées, qui peuvent être rappelées et affichées facilement, par exemple dans des fenêtres.

La mise en place de services avancés sur l’EDS permettrait d’augmenter sa valeur, en fournissant non seulement des données mais aussi des informations et finalement des connaissances aux utilisateurs, de manière uniforme, sans différences entre un système et un autre.

Mais quels sont les services qui pourraient être créés dans ce second sens, avec ou sans intelligence artificielle ? Essayons d’en énumérer quelques-uns :

• Des visualiseurs avancés, capables d’agréger et de corréler des données et des informations selon des critères cliniques, par exemple par étendue temporelle et/ou par pathologie. C’est un type de fonction vraiment nécessaire pour représenter de manière synthétique et efficace les nombreuses données, notamment celles des patients chroniques et des personnes âgées,
• Des tableaux de bord spécialisés par maladie ou par fonction, comme le rapprochement diabète ou pharmacothérapie,
• Aide à la décision clinique (DSS) basée sur l’Evidence Based Medicine pour orienter et suggérer le diagnostic et le traitement des pathologies,
• Accès aux lignes directrices, protocoles et preuves scientifiques d’une manière contextuelle et pertinente pour le patient.

Les fonctions peuvent également être hybrides, c’est-à-dire composées de plusieurs services, dans une vue intégrée, comme par exemple le Diagnostic Specific Overview d’EBMEDS, un CDSS produit par Duodecim et distribué en Italie exclusivement par Alkimiya.

Certifier et centraliser les services sur EDS permet de réduire le temps et les coûts de développement nécessaires par rapport au choix de les dupliquer sur plusieurs systèmes, sans parler de la charge de certification MDR pour les services qui en relèvent (comme par exemple dans l’exemple présenté – MDR classe IIA).

Mais quels services peut-on concrètement créer une fois l’EDS alimenté avec les données extraites des documents CDA ? Pour répondre à cette question, nous devons examiner en détail les données fournies par les spécifications publiées.

C’est ce que nous ferons dans le prochain article.

2 – Continuer