RESULTATS DE L'ENQUETE "GRILLE BCD" Novembre 2010 Mars 2011

Transcription

1 RESULTATS DE L'ENQUETE "GRILLE BCD" Novembre 2010 Mars /01/2012 Grille BCD

2 TABLE DES MATIERES 1. METHODOLOGIE Origine Idée initiale La "Communauté Grille BCD" Structure Axe - Groupe + Génération + Fiches (sémantiques, descriptives courtes complètes) Autres outils de mesure du degré d'informatisation Pourquoi un scorage et quelle est l'utilité des moyennes? Qui va scorer? Comment procéder (quelle démarche est recommandée)? Comment donner un score à une fonctionnalité? Pourquoi pas les aspects processus? Pourquoi certaines fonctionnalités dans un axe plutôt que dans un autre? Outil pensé dès le départ comme évolutif Initiative qui vient du secteur pour le secteur avec des gens opérationnels dans le secteur Conclusions ressortant de l'enquête quant à la pertinence de l'outil DEROULEMENT DE L ENQUETE Objectifs du SPF Fonctionnement du helpdesk et résultats Les feedback individuels ECHANTILLON /POPULATION Taille type région : pertinence Analyse de l échantillon Méthode d'analyse statistique choisie : petite population + référence ANALYSE DES RESULTATS Corrélations Conclusion d ensemble ANALYSE DES RESULTATS PAR AXE GROUPE Génération AXE 1 : données cliniques AXE 2 : Données administratives du patient AXE 3 : Logistique hospitalière AXE 4 : SUPPORT DE L'ORGANISATION AXE 5 : méthodologie et gouvernance AXE 6 : sécurité du patient et tracabilité AXE 7 : sécurité des opérations SUBSET DE 50 QUESTIONS objectif de trouver ce subset Rappel Que représente ce subset? = là où porte l'effort majeur Comment trouver les items? Condition limite CONCLUSIONS Validité de l'outil validation des réponses Mesures possibles pour le SPF Santé publique Comment continuer? Rôle de la "Communauté Grille BCD" ANNEXE 1 : Résultats de l'enquête Grille BCD 10/ / ANNEXE 2 : Présentation de l'enquête "Grille BCD" (9/11/2010) ANNEXE 3 : Discours de Mr Decoster (9/11/2010) ANNEXE 4 : HIMSS - US EMR Adoption Model SM ANNEXE 5 : CORRELATION ENTRE AXES GROUPES ITEMS ANNEXE 6 : SUBSET de "50 QUESTIONS" ANNEXE 7 : Remarques de certains hôpitaux et réponses ANNEXE 8 : GUIDE D'ENTRETIEN "BEST PRACTICES" Notes

3 1. METHODOLOGIE 1.1 Origine 3 initiateurs actifs dans le secteur : - Pierre Bouchat Licencié et Maître en Informatique (FUNDP Namur). 25 années de carrière (1 année en tant qu'analyste-programmeur, 13 années en tant que chef de projets, 9 années en tant que IT Manager Directeur Informatique) Secteurs d activité : société de développement de logiciel (1 an) secteur des assurances (société d assistance) (10 ans) multinationale du secteur industriel (4 ans) secteur hospitalier : CHU Godinne Cliniques Universitaires UCL Saint-Luc (10 ans). - Luc Ceyssens Expertise de plus de deux ans dans un groupe social belge comme CIO, Expertise de 7 ans à la tête d un département informatique dans un hôpital général à Liège Expertise confirmée dans la gestion de département informatique et la gestion de projets. Expertise en gestion de base de données, en méthodes d analyse, en développement et en télécommunications. Compétences confirmées en gestion de la sécurité des systèmes d informations (ISO 27001, 27002, 27799). Compétences en systèmes experts et intelligence artificielle. Lien vers linkedin : - Georges de Wasseige Première partie de carrière consacrée aux milieux sociopolitiques. Evolution vers les métiers de l'informatique : développeur, analyste, chef de projet dans des sociétés de logiciels et au sein d'entreprises. Depuis vingt ans, diverses fonctions de chef de projet et de directeur informatique dans le monde hospitalier. Récemment, Directeur Organisation et Projets au sein d'un hôpital de grande taille. Actuellement consultant indépendant. Formateur certifié PRINCE2 (méthode de gestion de projet) Compétences confirmées en gestion de la sécurité des systèmes d informations (ISO 27001, 27002,

4 1.2 Idée initiale Au printemps 2008, le salon fit appel à conférenciers pour un ensemble de sessions de présentations non commerciales concernant l informatique en milieu hospitalier. Chacun des trois "initiateurs" de la démarche BDC avait trouvé un intérêt à participer à ce type d événement. Mais quel sujet choisir? Lors d une réunion inter-hospitalière et d échanges informels entre ces trois personnes, il s est avéré qu elles pouvaient efficacement partager leur expérience sur un sujet qui devait intéresser les directions d un hôpital : un outil pour discuter stratégie informatique avec les directions générales au sujet des données cliniques du patient. La grille BCD était née. Le sujet était trouvé et la conférence eut lieu en octobre de la même année. Le titre de la conférence était : "Quels outils informatiques mettre, en milieu hospitalier, à disposition de tous les soignants pour améliorer la prise en charge des patients? 1 " Mi-2009, un des initiateurs fut amené à participer à un groupe de travail inter-hospitalier au SPF Santé Publique, sur le thème des indicateurs hospitalier non cliniques (volet informatique). Lors de ces travaux, le travail initial fut présenté au groupe. L intérêt ayant été marqué pour le travail réalisé, il fut demandé 2 choses : - étendre le périmètre au-delà de l informatisation des données cliniques du patient. Les buts étaient 1 d'intégrer la totalité des matières prises en compte par une informatique hospitalière; 2 d ajouter des préoccupations transversales comme la sécurité, la formation, la méthodologie et d autres notions transversales du métier de l informaticien; - mettre au point une méthode de scorage. Les buts poursuivis étaient 1 de pouvoir avoir une vue d ensemble de la situation de l informatique hospitalière en Belgique; 2 de pouvoir mesurer une progression en fonction d actions menées. Ces demandes furent donc prises en charge et réalisées comme évolution du projet initial. Le déroulement de la pré-enquête et de l'enquête est décrit au chapitre 2. En novembre 2010, une enquête officielle fut lancée sur base des travaux réalisés sur l année écoulée. Les réponses furent rendues sur base volontaire uniquement. Malgré cela, 49 hôpitaux ont répondu sur les 106 ayant reçu le questionnaire. Les résultats individuels ont été collectés fin juin Le présent document en synthétise les résultats globaux. 2

5 1.3 La "Communauté Grille BCD" Depuis début 2009, une communauté de personnes, fortement impliquées dans l informatisation des hôpitaux émanant de plus d une quinzaine d institutions hospitalières de Belgique s est réunie autour des initiateurs de l'initiative de mise en place d une grille d évaluation de l avancement et de la performance des systèmes d information au sein des hôpitaux. Ces personnes sont membres de cette "communauté" à titre personnel. Comment prendre conscience, organiser et prioriser les développements pour éviter les dispersions, les dépenses caduques, les projets sans fin, les réalisations boiteuses en production, les allégations des fournisseurs des plus belles solutions (sic!)? Comment arriver à satisfaire les clients (nous aurions pu écrire acteurs) des systèmes d information dans la prise en charge efficace des patients? Le but de cette "communauté" - que nous nommerons par la suite "Communauté Grille BCD "- est de mettre à disposition des directions générales, des directions médicales et des directions informatiques des institutions hospitalières un outil permettant : - dans un premier temps l évaluation de l état des systèmes d information de leur institution propre ; - dans un deuxième temps de définir, grâce à cet outil, un plan stratégique de développement des systèmes d information de l institution ; - dans un troisième temps, de mesurer la progression de la réalisation de ce plan stratégique au cours du temps par des évaluations régulières des pistes de développement arrêtées conjointement par les trois instances de l institution. Cet outil doit aussi permettre d adapter facilement le plan stratégique informatique de l institution sans perdre le bénéfice apporté par les trois premières étapes décrites cidessus. La "Communauté Grille BCD" se réunit très régulièrement autour des initiateurs pour se définir des axes de développement et se fixer des objectifs autour de ce développement. Une roadmap de développement de l outil est avalisée et acceptée par la "Communauté Grille BCD". La "Communauté Grille BCD" produit ses articles en mode open source. Elle est intervenue sur la découpe en axes, en groupes et en fonctionnalités de la grille d évaluation, en respectant la dimension des générations (Le concept de "génération" est expliqué au point 1.4 ci-dessous). Elle se positionne sur le classement de ces fonctionnalités. La "Communauté Grille BCD" s organise en groupes de travail pour prendre en charge la rédaction et la validation des fiches liées aux fonctionnalités croisées avec le classement par génération et les fiches sémantiques. Chaque groupe de travail est pilotée par un rédacteur autour de contributeurs. Les fiches rédigées sont ensuite envoyées à toute la "Communauté Grille BCD" pour une lecture qualitative supplémentaire. Ces fiches sont enfin examinées au cours de réunion plénière. Les fiches sont rédigées selon un format uniformisé. 3

6 La "Communauté Grille BCD" s est aussi interdit d intervenir à propos de la description de la manière dont une fonctionnalité donnée doit être satisfaite. La volonté de la "Communauté Grille BCD" est d exprimer la définition de la fonctionnalité (de quoi il s'agit) en laissant toute liberté à l institution hospitalière de choisir comment celle-ci va apporter une solution, et par quelle démarche aboutir à la réalisation de celle-ci pour autant que la méthode choisie respecte certaines notions exprimées dans les fiches sémantiques et certaines règles communes à toutes les fonctionnalités (exemple : le numéro d identification du patient doit être unique au sein d une institution hospitalière). La "Communauté Grille BCD" est ouverte à toute personne désirant faire partie de cette initiative pourvu qu elle fasse état d une connaissance établie du milieu hospitalier. 1.4 Structure Axe - Groupe + Génération + Fiches (sémantiques, descriptives courtes complètes) Dans l idée initiale, discuter stratégie d informatisation voulait dire avoir aussi une perspective de progression dans les matières. Chaque fonctionnalité fut donc déclinée en quatre générations : - génération 1 : le papier. C est la génération du minimum pour prendre en charge la fonctionnalité - génération 2 : une application répond à la fonctionnalité. C est la génération du premier outil informatique (best of breed) - génération 3 : un outil existe pour intégrer les fonctionnalités qui se tiennent. C est la génération de l intégration.(best of suite) - génération 4 : de l aide à la décision ou de l expertise est présente sur la fonctionnalité. C est la génération des systèmes experts. Les initiateurs se sont délibérément limités à quatre générations afin de rester dans les domaines où des concrétisations apparaissent clairement. Il leur sembla prématuré d aller plus loin au risque de rater l objectif de communication avec les directions générales. Deux des demandes du SPF Santé Publique étaient d étendre le périmètre au-delà des fonctionnalités "cliniques" et d ajouter des thèmes transversaux liés à la sécurité du patient et aux méthodes de travail. Cela aurait eu pour effet d'allonger considérablement la liste de fonctionnalités à définir. Une demande complémentaire était de pouvoir fournir quelques indicateurs clés (+/- 10). On trouvera la réponse à cette demande au chapitre 6. Spontanément, il fut décidé de regrouper les sujets dans une structure pyramidale. Le premier niveau de la pyramide est occupé par les items et leurs fiches. Au niveau juste au-dessus, les groupes permettent de se concentrer sur un sujet en particulier au travers de ses différentes facettes (exemple : anamnèse infirmière). Au niveau supérieur, sept axes permettent de rassembler les groupes. 4

7 Au départ, la méthode de regroupement est relativement arbitraire. L enquête révélera plus tard que - ce choix est pertinent - d autres choix auraient pu être tout aussi valables. Les sept axes sont répartis en quatre axes fonctionnels et trois axes transversaux. Au niveau des axes fonctionnels, le critère de regroupement a été choisi en s éloignant de plus en plus des données touchant directement le patient. Donc, on obtient dans l ordre : - données cliniques - données administratives (où l agenda fut placé par la nature des fonctions des personnes qui traitent ces informations : secrétaires ou aides infirmières administratives pour la plupart) - logistique hospitalière (DRH, Finance, Achats, Facturation, ) - Données propres à l organisation et à sa gestion (Datawarehouse, Site Web, outils de collaboration, ). Les trois axes transversaux sont : - méthodologie et gouvernance : pour se concentrer sur les "hommes "et leur façon de faire - sécurité et traçabilité : la sécurité autour du patient - sécurité des opérations : la sécurité globale informatique et des bâtiments. Au départ, les fiches faisaient l objet d un texte explicatif continu. De façon à être plus compréhensibles, ces fiches furent repensées et complétées en utilisant la structure Boscar³ Cette structure a été proposée par les initiateurs à la communauté. Boscar³ est un acronyme pour une structuration efficace et une rapidité dans la rédaction des fiches. La structure en est la suivante : - Background : permet de décrire la situation de départ. - Objectives : permet de définir le «quoi». - Scope: permet de décrire le périmètre de la fonctionnalité, mais aussi ce qui n y est pas intégré. - Constraints : définit les contraintes liées au contexte propre de la fonctionnalité. - Assumptions, transformé en Dépendances : permet de décrire les dépendances entre les fonctionnalités. Une notion de préséance peut ici être invoquée. - Ressources : permet d identifier le type de ressources et leur dimensionnement pour la réalisation de la fonctionnalité. - References : identifie les références externes utilisées lors de la rédaction de la fiche sur la fonctionnalité décrite. - Risks : identifie les risques inhérents à la fonctionnalité décrite. 5

8 Figure 1 : Modèle de fiche BCD Gn où n est le numéro de génération nn = numéro de la fiche Au modèle Boscar³, il fut également décidé d ajouter un paragraphe pour une courte explication. Pour certains items, cette courte explication suffisait amplement. Par la suite, le besoin s est fait sentir de définir un certain vocabulaire et certains concepts généraux. Des fiches sémantiques furent donc créées pour répondre à ce besoin. Figure 2 : Nombre de fiches selon les versions Axes Groupes Générations Items Fiches explicatives Fiches sémantiques Longue Courte 90 6

9 Figure 3 : Evolution des versions de la Grille BCD Version # fiches Nombre d'items par génération G1 G2 G3 G4 Total items % fiches rédigées 1.5 1ère version livrée ,93% 1.6 version utilisée pour ,65% premiers tests 2.0.h version finale ,23% 2.1 version après enquête % Enfin, un ensemble de graphiques de synthèse permettent de donner une vue synoptique simple et rapide des scores établis. 1.5 Autres outils de mesure du degré d'informatisation - HIMSS Il existe d'autres démarches visant à "mesurer" le degré d'informatisation des institutions de soins. La plus ancienne est HIMSS 2, fondée en HIMSS propose une grille à sept niveaux (voir Annexe 1). Malgré des tentatives d'"européanisation ", la grille HIMSS conserve une manière d'aborder la question de l'informatisation en milieu hospitalier très marquée par ses origines américaines, spécialement dans l'ordre dans lequel les différentes pièces du puzzle, les différentes composantes de la solution informatique globale sont mises en place. En outre, la grille HIMSS se limite aux données qui sont censées se retrouver dans le DPI (Dossier Patient Informatisé ou Electronic Health Record). Ceci implique que d'autres aspects liés au patient mais qui ne sont pas des données cliniques ne sont pas pris en compte. Tout le volet de la sécurité du patient (Patient Safety), qui implique de capturer, organiser et consolider des données venant, par exemple, des autoclaves de la stérilisation, de la chaîne de production de la nourriture ou des actions d'entretien et de nettoyage, n'est pas pris en compte. HIMMS ne méconnaît assurément pas le "Patient Safety" mais cela n'est pas intégré dans la vision globale de l'informatisation représentée par sa grille à sept niveaux. Si HIMSS publie une grande quantité d'études, d'analyses et de "livres blancs", la distinction n'est pas toujours simple à opérer entre ce qui émane d'acteurs issus du monde hospitalier et ce qui est produit par des fournisseurs de solutions destinées à ce même monde hospitalier. - Enquête Deloitte Depuis plusieurs années, la Commission européenne finance de vastes enquêtes sur l'usage des technologies de l'information dans les hôpitaux. Cette enquête a été confiée en aux bureaux d'étude Deloitte et Ipsos. 7

10 La démarche méthodologique a consisté à poser des questions par téléphone aux CIO et aux Directeurs médicaux. Certaines questions peuvent légitimement soulever des objections : par exemple, l'enquête comporte des questions (11 à 13) à propos de l'utilisation éventuelle de connexions "wireless " au sein de l'institution et à quel(s) public(s) celles-ci sont, le cas échéant, proposées. Ceci sous-entend que l'hôpital qui aura pris la décision de NE PAS installer de "wifi "pour ne pas exposer sans raison impérieuse ses patients, c'est-à-dire des personnes potentiellement immuno-déprimées, à des ondes électromagnétiques se verra automatiquement considéré comme ayant un degré d'informatisation moindre. Dans le même ordre d'idées, la question est posée de savoir si le PACS de l'institution appartient ou pas à un réseau régional ou national (question 21). La question est biaisée par des présupposés organisationnels. Si un hôpital dispose de son propre PACS et est capable d'envoyer dans de bonnes conditions de confidentialité, de sécurité et de vitesse des images cliniques, peu importe comment cela est réalisé : au travers d'un "PACS régional" ou au travers d'un hub de santé. Certaines questions semblent aussi marquées par les modes technologiques du moment comme la télémédecine; la caractéristique de ces modes technologiques est de prétendre rendre obsolètes tout ce qui est en place et de réaliser des économies fulgurantes dans le domaine concerné. Ces modes technologiques qui ne sont pas propres au secteur des soins de santé sont à considérer avec prudence. L'apport technologique est incontestable mais entre les annonces marketing, hélas parfois relayées sans nuances par la presse et malheureusement parfois adoptées sans distance par certaines autorités politiques, et un réel apport "sur le terrain" doublé d'une appropriation par les acteurs de terrain, il y a une marge. L'avantage majeur de ce type d'études est d'opérer un benchmarking entre les pays 3. L'étude a ainsi permis de mettre en évidence un certain nombre de questions de base à éclaircir avant toute tentative de benchmarking, préalable à la mise en place d'une politique européenne de soutien à l'e-santé. Ces questions, souvent triviales, sont : qu'est-ce qu'une institution de soins du point de vue de l'enquête? (En Belgique, la question est pertinente pour les bassins de soins, le groupe Iris à Bruxelles ou les hôpitaux publics anversois). - Agence Wallonne des Télécommunications Très récemment, l'agence Wallonne des Télécommunications a réalisé une enquête sur l'utilisation des TIC dans le secteur hospitalier wallon 4. Les aspects d'infrastructures sont plus largement traités que dans la présente enquête qui se centre sur les besoins internes et sur la stratégie de mise en place des fonctionnalités informatiques. Les conclusions de l'awt en matière de Dossier Patient Informatisé (en d'autres mots de dossier patient multi-métiers) et de partage des données rejoignent les observations de la présente étude. 8

11 1.6 Pourquoi un scorage et quelle est l'utilité des moyennes? La demande du SPF Santé Publique à ce niveau était de pouvoir mesurer une évolution. Il fallait donc répondre à 2 besoins : - établir un état des lieux global du paysage informatique hospitalier belge à un moment donné; - mesurer une progression du niveau d informatisation au fil du temps pour identifier la portée des actions politiques menées. Le modèle de calcul a donc été basé sur un scorage de 0 à 6 (expliqué ci-après) et en utilisant des moyennes : - pour que le modèle puisse évoluer tout en gardant une comparabilité avec le passé; - pour que des items non scorés pour des raisons justifiées ne perturbent pas les calculs. 1.7 Qui va scorer? Comment procéder (quelle démarche est recommandée)? Pour arriver à établir un scorage correct de la grille, il est fortement recommandé de ne pas se contenter de recueillir l'avis du seul responsable informatique de l hôpital. Idéalement, chaque personne représentative d un métier de l institution doit pouvoir donner son avis lors de l établissement du score. Le temps estimé pour une première démarche est d une journée de travail coordonnée par le responsable informatique. 1.8 Comment donner un score à une fonctionnalité? Tout d abord, il est essentiel de spécifier que la fonctionnalité observée sera scorée dans le sens suivant : il s agit de la mise à disposition et de l utilisation continue de la dite fonctionnalité. Il faut exclure les tentatives avortées et autres utilisations temporaires motivées par des périodes d activité bien précises ou sous surveillance. L idée majeure est de mesurer l état réel de l informatisation et non son état espéré. 9

12 Les valeurs de scorage sont les suivantes : Figure 4 : Valeurs de scorage et signification Score Signification Explication 0 Pas demandé 0 : signifie que la demande n existe pas en ce qui concerne la fonctionnalité, personne n y a pensé ou n est sensible à ce sujet. 1 Demande existe 1 : la demande existe et a fait l objet d une formalisation. 2 Envisagé/ A l'étude/ Planifié 2 : l hôpital travaille à réaliser la fonctionnalité. Il existe un groupe d analyse, des personnes sont responsabilisées. 3 En place dans une unité/service pilote 4 En place dans moins de la moitié des unités/services 5 En place dans plus de la moitié des unités/services 6 En place dans toutes les unités/services (> 90%) (*) 3 : un pilote est en cours. Des premières réalisations sont opérationnelles à petite échelle. 4 : la fonctionnalité est en place dans moins de la moitié des services concernés ou moins de la moitié du périmètre initialement prévu. 5 : la fonctionnalité est en place dans plus de la moitié des services concernés ou plus de la moitié du périmètre initialement prévu. 6 : la fonctionnalité est en place dans la totalité (*) des services concernés ou la totalité du périmètre initialement prévu. * On a considéré que plus de 90% des services équivaut à 100% car il y a des villages gaulois d irréductibles résistants à l informatisation; ceux-ci ne doivent pas empêcher de scorer 6 : une opportunité finira par se présenter pour résoudre le problème et atteindre les 100% effectifs. Il reste évidemment la possibilité, pour l hôpital qui n est pas concerné par la fonctionnalité, de retirer toute valeur de score de façon à neutraliser la fonctionnalité. La valeur Non Applicable est donc possible Comme cela peut transparaître dans le paragraphe ci-dessus, les scores 4, 5 et 6 peuvent trouver des variantes en fonction de la portée initialement prévue pour la fonctionnalité. Exemple : Un outil de gestion complète du Capital Humain peut être déployé à 60% de ses capacités -> score 5. Exemple : une prescription de médicaments peut être déployée dans 30% des unités de soins d hospitalisation mais il n est pas prévu que l outil soit déployé en Hôpital de jour -> score 4. Dans une version ultérieure de l'outil Grille BCD, la notion ci-dessus sera explicitée plus clairement (chaque fiche contiendra la définition du "comment scorer "). Disponibilité ou utilisation effective L'enquête "ehealth Benchmarking III", financée par la Commission européenne, a notamment investigué sur la distinction entre la disponibilité de certaines applications et leur usage effectif par le personnel soignant. La démarche méthodologique pour mettre ces différences en évidence a consisté à poser des questions différentes aux CIO 10

13 (disponibilité) et aux Directeurs médicaux (utilisation) 5. La question est pertinente et mérite que l'on y accorde de l'attention. L'outil "Grille BCD" a opté pour une autre approche; l'objectif premier de l'outil n'était pas de fournir des renseignements aux pouvoirs publics mais bien de permettre à une institution de soins d'établir avec précision l'état de son informatisation, de recenser l'ensemble des demandes, de définir les priorités pour les trois à cinq années à venir et enfin de suivre la réalisation des objectifs ainsi fixés. La collecte par une autorité publique de ces informations ne devient donc pas une charge supplémentaire pour l'hôpital. Au contraire, l'autorité publique met à disposition des institutions de soins un outil de gestion et, en retour, par simple communication des plans stratégiques sous une forme structurée, codifiée, l'autorité publique dispose d'une vue globale et évolutive des outils informatiques en place. En outre, la technique de scorage de la "Grille BCD", parce qu'elle pose la question de l'existence d'une demande et du fait que la réponse à cette demande est envisagée (score = 2), permet d'appréhender le plan stratégique de l'hôpital. L'enquête effectuée pour la Commission européenne pose la question supplémentaire des priorités d'investissement dans les trois ans à venir, en permettant un choix entre neuf "applications". Cette démarche se rapproche de celle d'himss et ne donne qu'une vue très approximative du déploiement des applications. L'aspect de "montée en puissance" d'une application est également important à mesurer. Le volet infirmier du Dossier Patient Informatisé (DPI) exige du temps et des efforts : de 4 à 6 semaines par unités d'hospitalisation est une durée habituelle. La mise en place du Parcours du médicament (prescription par le médecin délivrance par la pharmacie distribution par le personnel infirmier) exige par unité d'hospitalisation sensiblement le même temps. Ce genre de projet se compte en années et pas en semaines. Mesurer le degré de déploiement d'une application est un aspect important d'où l'utilisation des scores 4, 5 et Pourquoi pas les aspects processus? Suivre un système d information au travers des processus ou au travers des fonctionnalités aboutit au même périmètre d informatisation. Lorsque tous les processus sont couverts, toutes les fonctionnalités sont remplies (et réciproquement). L approche processus est un autre angle de vue sur une même matière : le périmètre des fonctionnalités à remplir. De plus, les axes transversaux (traçabilité, sécurité, méthodologie) ne sont pas concernés par cette approche processus mais doivent l encadrer. Il existe deux stratégies majeures dans le monde de l informatique hospitalière : - le "tout fait maison " - l acquisition de produits du marché 11

14 Une "approche processus" est plus spontanée en développement "maison" qu en recherche de produits commerciaux. Certains hôpitaux ont clairement optés pour cette "approche processus" dans leur stratégie d'informatisation. Par analogie avec le monde de la mode, nous parlons de "haute couture" et de "prêt-àporter". Lorsqu une institution est dans la logique du développement "maison", il est plus intuitif (pour des raisons d efficacité pure) d automatiser des processus. Exemple : une gestion multi-métiers de stocks (meilleure transversalité et intégration). Nous assistons à une mutation progressive vers l acquisition de produits du marché poussés par les fournisseurs qui voient de plus en plus d opportunités à développer des solutions cliniques. Ces mêmes fournisseurs voient de plus en plus l intérêt de l intégration et de la transversalité de leurs produits. Des fournisseurs ont proposé des solutions spécifiques. D autres proposent des solutions globales et intégrées. Dans les scores élevés, on trouve aussi bien des hôpitaux ayant adopté une démarche de développement "maison" que des hôpitaux ayant opté pour une politique d'acquisition de produits logiciels. Prendre position pour l une ou l autre stratégie impliquerait une ingérence dans le choix des méthodes, ce que nous avons choisi d'éviter pour adopter une vision qui nous semblait plus adaptée au terrain. En conclusion, l approche processus fera l objet d une prochaine version de l enquête si nécessaire Pourquoi certaines fonctionnalités dans un axe plutôt que dans un autre? Discussion sans fin! Le choix initial a fait l objet de longues discussions entre les initiateurs de la démarche. La conclusion : il n y a pas de vérité. Le choix des axes et groupes, tel qu il se présente actuellement, représente un consensus entre les initiateurs et a été validé par la "Communauté Grille BCD". Le modèle, grâce à l utilisation des moyennes, peut être revu et réorganisé sans perdre la comparabilité avec le passé Cette discussion fut reprise par les hôpitaux participant à l enquête, mais il n y pas eu de remise en question fondamentale de la répartition entre axes. Par exemple, le groupe "agenda" aurait pu faire partie de l axe des données cliniques. D un autre côté, le caractère "non soignant" des personnes utilisant ce type d application est encore largement répandu. Ce qu il faut retenir, c est que mettre ce groupe dans l un ou l autre des deux axes est peu important au vu de la cohérence du groupe en tant que tel. Où qu il fut placé, cela n aurait rien changé aux conclusions. Pour l'hôpital, l'important est de ne rien oublier et de tout maîtriser (quelque soit la structure des axes). 12

15 1.11 Outil pensé dès le départ comme évolutif Les initiateurs de cette démarche, en accord avec la "Communauté Grille BCD", ont décidé d emblée de penser cette grille comme devant être évolutive dans le temps sans perdre les informations des précédentes utilisations de la grille par les acteurs du monde hospitalier. Le nombre d axes, de groupes par axe, de fonctionnalités par groupe peuvent évoluer dans le temps, le nombre de générations peut aussi augmenter; fondamentalement, les résultats présentés peuvent toujours se comparer d une utilisation à l autre de la grille et de son outil de scorage. L utilisation de moyenne et d écart-type dans l outil de scorage le permet aisément, même si mathématiquement, l ajout d une fonctionnalité peut avoir un impact sur le scorage moyen d un groupe. Chaque fonctionnalité est cotée individuellement et l impact sur la moyenne de cotation d un axe est souvent minime. La représentation en bâtonnets qui est présentée sur les rapports globaux et individuels, permet aisément cette comparaison visuelle. La grille évolue de la même manière pour l ensemble du secteur. Nous avons pu constater cela au travers des générations successives produites (V1.5; V1.6; V1.6.1; V2.0; V2.1, ) où le nombre de fonctionnalités a significativement augmenté en passant de 230 à plus de 440, sans compter les quatre générations impliquées dans la grille Initiative qui vient du secteur pour le secteur avec des gens opérationnels dans le secteur Les premiers paragraphes de ce document mentionnent le fait que la "Communauté Grille BCD" est composée par des professionnels du secteur ayant une expérience importante et y exercent actuellement leurs talents. Comme indiqué plus haut, cette "Communauté Grille BCD" est constituée de médecins, infirmiers et informaticiens qui se sont engagés à titre personnel. Cette initiative de la grille BCD prend sa source parmi des acteurs du milieu hospitalier et a finalement servi de base pour la constitution d un outil de scorage sous le patronage du SPF Santé Publique. Nous y retrouvons des personnes qui proviennent de tous types d institutions hospitalières des trois régions du pays. L ensemble des vécus des membres de la "Communauté Grille BCD" rassemble une somme importante de réalités, de visions, de stratégies différentes et pourtant très complémentaires dans les préoccupations de développement de l informatisation au sein de chacune des institutions hospitalières. La "Communauté Grille BCD" est, par principe, ouverte à tout acteur du secteur hospitalier désireux de participer à la réalisation de cette démarche visant à livrer à la fois un outil en mode "open source" d aide à la décision stratégique au sein de l hôpital et un outil de benchmarking du secteur hospitalier. 13

16 Les initiateurs profitent de ce rapport pour remercier chacune des personnes partie prenante de notre "Communauté Grille BCD" pour leur participation active à notre démarche commune dans un esprit "open source" de partage des meilleures pratiques en matière d informatisation des institutions hospitalières Conclusions ressortant de l'enquête quant à la pertinence de l'outil La grille a été testée : - auprès d'hôpitaux tests - enquête auprès de 49 institutions avec un helpdesk qui a fonctionné pendant 4 mois et demi - entretiens "Best practices" Pendant toutes ces démarches, nous avons pu constater les mêmes points : - des remarques et questions ont été formulées sur la ventilation entre axes : ce point a été discuté ci-dessus. Il ne subsiste pas d'objection à la ventilation proposée par l'outil - de nombreux intervenants ont reconnu la très grande utilité de l'outil Grille BCD comme démarche en interne pour élaborer / valider le plan stratégique et comme outil de communication interne. Ce point était unanime lors des entretiens "Best practices" - la complétude de l'outil est reconnue même s'il faut encore rédiger des fiches explicatives pour éviter toute équivoque - de multiples propositions positives et enthousiastes pour améliorer l'outil ont été émises. 14

17 2. DEROULEMENT DE L ENQUETE 2.1 Objectifs du SPF La logique du SPF Santé publique était de mener une enquête "beta" en visant à se doter d'un outil pour supporter le secteur. Après que le principe d utilisation de la grille BCD (élaborée par des acteurs du secteur hospitalier, complétée par une méthodologie de scorage et une grille adéquate) eut été accepté par le SPF Santé public, la démarche liée à la grille fut testée auprès de quelques institutions hospitalières. Ces tests se sont déroulés sur un minimum d'une demi-journée en présence d au moins deux initiateurs. Cinq institutions ont participé à ces tests; une très grande majorité était située en Flandre pour équilibrer la provenance plutôt francophones des initiateurs et des membres de la "Communauté Grille BCD". Ces tests ont fortement contribué à faire évoluer la grille. L'évolution de l'outil a été détaillée dans un tableau ci-dessus (Figure 2). Au vu des résultats très positifs de cette première série de test (destinés à évaluer la manière dont la grille BCD était perçue et acceptée) et au vu du retour positif que son utilisation pourrait générer, le SPF et les initiateurs se sont accordés sur un plan réaliste de tests à proposer à l ensemble du secteur. Une présentation de l'outil "Grille BCD" a eu lieu au CNEH en date du 24 août Cette présentation a été suivie d'une large discussion très ouverte. Le principe d'une enquête "beta" auprès de l'ensemble du secteur a été acquis, notamment lors de la réunion du Bureau du CNEH en sa séance du 14/10/2010. Ce test grandeur nature n avait pas de caractère obligatoire, cependant, chacune des 106 institutions hospitalières de Belgique a été invitée à y participer. Pour lancer cette enquête, deux séances d information, l une en Néerlandais et l autre en Français ont été organisées, le 9 novembre 2010, dans les locaux du SPF Santé Publique. Ces séances d'information étaient destinées aux représentants des institutions de soins intéressés à participer à l'enquête. Plus d'une centaine de personnes, équitablement réparties entre les deux sessions y ont participé. A cette occasion, Mr Decoster Directeur Général de la DG 1 - a clairement précisé la démarche du SPF Santé publique : "Afin de pouvoir mieux appréhender la situation actuelle du secteur, il a été décidé de proposer une méthode devant permettre une analyse détaillée de la situation de chaque hôpital. Pour ce faire, et grâce à l important input d experts émanant du terrain, nous avons donc décidé de soutenir la création d une grille d évaluation spécifique." La durée du test a été fixée du 15 décembre au 28 Février 2011, période qu'il fut ultérieurement décidé de prolonger jusqu'au 28 mars Un helpdesk par a été mis en place par les initiateurs durant cette période. 49 institutions hospitalières sur 106 ont répondu favorablement à cette initiative. Soit un échantillon de 46,22 % de réponses positives par rapport à la population totale finie. 15

18 Une page dédicacée à l'enquête "Grille BCD" ouverte sur le site web du SPF Santé publique permettait de poser les questions. 2.2 Fonctionnement du helpdesk et résultats Au travers de l'outil de helpdesk mis en place sur le site du SPF Santé Publique, 54 questions ont été posées. La réponse a été essentiellement donnée par courrier électronique; quelques contacts téléphoniques ont été nécessaires pour mieux cerner la demande ou apporter une réponse plus nuancée. Il faut savoir que certaines questions comportaient en fait une série de sous-questions. Au total, c'est près d'une centaine de questions qui ont été posées. Bien évidemment il y avait certains recoupements entre les questions : - sept questions/remarques portaient sur des erreurs ou des absences de traduction - cinq questions sur l'utilisation élémentaire du tableur - vingt-sept questions portaient sur les calculs effectués dans la grille dont une quinzaine signalait un bug corrigé en cours d'enquête - dix questions ont signalé un bug qui empêchait de scorer pour certains items. Ce bug a été corrigé en cours d'enquête - vingt-neuf questions portaient sur la compréhension de l'un ou l'autre item; les réponses à ces vingt-neuf questions deviendront dans la version 2.1 autant de fiches explicatives - dix-huit questions ont nécessité un simple éclaircissement qui se traduira dans des adaptations aux fiches existantes; on trouve par exemple, une question sur le calcul du nombre de services à prendre en compte pour mesurer le déploiement. Il y a eu quelques questions portant sur la philosophie générale de la Grille BCD. Des questions du même genre ont été adressées directement à l'adresse électronique de contact. Les questions posées sur ce sujet et les réponses apportées ont été reprises en annexe 7. Ces questions sont les plus critiques sur la démarche du SPF Santé Publique et sur l'outil en lui-même. La critique principale porte sur le temps nécessaire à compléter la grille. Une critique plus philosophique pose la question de savoir s'il est possible d'élaborer un outil tel que la Grille BCD; la démarche de HIMSS, de l'enquête Deloitte et la récente initiative française sont autant de réponses positives à cette interrogation. L'exigence d'univocité revient à de multiples reprises. Cette exigence a été entendue puisque la prochaine version (2.1) comprendra une septantaine de nouvelles fiches (Cf. Figure 3). S'il ne faut retenir qu'une conclusion du gros travail de helpdesk qui a été effectué c'est qu'il est possible de mettre au point un outil objectif de mesure du degré d'informatisation d'une institution de soins. La Grille BCD à cet égard est un très bon premier pas, malgré des maladies de jeunesse incontestables; il faut poursuivre dans la définition des items pour arriver à supprimer toute équivoque dans les questions. 16

19 2.3 Les feedback individuels Chaque hôpital ayant participé à l'enquête a reçu en retour en juin son scorage mis en perspective par rapport au scorage moyen de l'échantillon pour chaque axe, groupe et item. Une comparaison en graphique pour les 7 axes et les groupes de chaque axe permettait de visualiser le scorage de l'hôpital par rapport à la moyenne. Les hôpitaux ont également reçu sept graphiques (un par axe) qui classaient les hôpitaux selon le score obtenu. Les graphiques envoyés aux institutions ayant participé à l'enquête sont repris dans l'annexe. Il faut noter que les réponses à l'enquête ont été renvoyées par les institutions au SPF Santé Publique qui les a anonymisées avant de les transmettre aux initiateurs pour dépouillement. De la même manière, les résultats comparatifs inter-hospitaliers sont totalement anonymes : chaque hôpital est identifié par un numéro. Chaque hôpital ne connaissait que son numéro. 17

20 3. ECHANTILLON / POPULATION 3.1 Taille type région : pertinence Une des premières questions qu il est légitime de se poser est de savoir si l échantillon est représentatif par rapport à la taille connue de la population. Les prochains paragraphes vont discuter de la pertinence de ces échantillons et des éventuels autres questions qu'il est aussi légitime de se poser par rapport au nombre de lits, par rapport au type des hôpitaux ou par rapport à la région. Les études ont été faites sur un échantillon de 49 hôpitaux sur une population totale de 106. Deux hôpitaux ont rendu leur résultat en dehors des délais et ont été inclus dans les études détaillées et non sur l étude de la validité de l échantillonnage. Deux hôpitaux de la population considérée possèdent plus de deux mille lits, ces deux hôpitaux ne sont pas représentatifs de la population totale ; les initiateurs ont donc décidé de les exclure de la population cible. Leurs réponses devront faire l objet d une analyse spécifique. (Ceci ne fera que renforcer les conclusions ci-dessous). Dans un premier temps, nous examinons la distribution des hôpitaux en fonction de leur nombre de lits. Nous les avons classés par ordre croissant du nombre de lits. La première courbe est obtenue sur l ensemble de la population choisie. La deuxième courbe représente la distribution des hôpitaux ayant répondu à l enquête en fonction des mêmes critères soient un classement ordonné par nombre de lit Série1 600 Série Nous pouvons en déduire que la distribution de l échantillon est particulièrement homogène par rapport à la distribution de la population. Ceci forme à n en pas douter un premier indice permettant de déduire une bonne répartition de l échantillon. Plusieurs questions nous ont alors traversé l esprit. Si nous ventilions l échantillon par région, par statut ou par type, quels types de conclusions pouvions-nous en tirer en comparant les trois distributions obtenues à chaque fois? Existe-t-il des disparités régionales entre les établissements hospitaliers du point de vue de l'état d'avancement de leur informatisation? La même question se pose-t-elle si on les envisage sous l'angle du type d'établissement ou du statut? 18