Impossible de procéder à une documentation électronique «correcte» sans des systèmes logiciels qui le facilitent ou du moins le permettent. Mais que signifie ici «correcte»? Qui détermine ce qui est correct ou incorrect? Comme souvent le cas, la réponse est: cela dépend!
Un revirement de tendance semble progressivement s’installer: de plus en plus de médecins indépendants ont déjà recours à la documentation électronique ou prévoient d’y passer dans un avenir proche [1]. La tendance est positive, même si elle ne s’effectue pas à une vitesse vertigineuse.
Les raisons à cette adoption retardée de la documentation clinique informatisée sont d’une part les problèmes «courants» inhérents au système informatique (protection et sécurité des données, dépendance, coûts, etc.) [2]. D’autre part, la complexité augmentant pratiquement chaque année et les besoins d’échange de données émis en parallèle freinent énormément le processus [3]. A cela s’ajoute le fait que les collègues proches de la retraite ont tendance à attendre plutôt qu’à introduire un système susceptible de ne pas être acceptable pour un successeur potentiel.
Faire le bon choix, c’est-à-dire passer à la documentation électronique, ne représente qu’un seul côté de la médaille. Y procéder de manière correcte constitue toutefois le «revers de la médaille».
Il incombe à chacun de faire le premier pas, que ce soit rapidement ou en toute tranquillité, en sollicitant l’aide de collègues qui se trouvent déjà depuis plus longtemps «sur cette voie» (par ex. avec les cours «Going paperless» de l’Institut pour l’informatique au cabinet médical (IPI) [4]), s’en remettre à une entreprise ou un consultant, ou simplement se lancer et voir soi-même jusqu’où on peut arriver.
Ce faisant, il faut garder à l’esprit que le bien est l’ennemi du mieux! Il vaut la peine de jeter un œil chez le confrère ou la consœur et d’adopter une approche «biblique»: «Tout vérifier et garder le positif»!
Survient alors le risque de rester sur place à un moment donné, de s’habituer à un système loin d’être optimal et de le considérer comme le summum. C’est la raison pour laquelle il n’est pas surprenant que les sondages ne fassent état que d’un bénéfice modeste. Par exemple, l’augmentation de l’efficacité grâce au gain de temps compte souvent parmi les objectifs ciblés. Toutefois, les chiffres publiés sont plutôt décevants, comme le constate Scott Hensley dans sa publication «Electronic Medical Records, Built For Efficiency, Often Backfire» [5] (fig. 1).
Figure 1: Temps libre grâce à l’assistance par ordinateur.
«Doing the things right»
Le présent article ne se concentre pas sur le changement en soi, mais sur la deuxième partie de la phrase introductive: «Doing the things right».
Cela dépend de ce que l’on cherche à atteindre avec la documentation électronique. Le National Learning Consortium NLC des Etats-Unis (HealthIT.gov) recense près de 50 objectifs, regroupés selon la perspective de l’instance impliquée (système, fournisseur, utilisateur, coûts, échanges de données, patient, etc.) [6]. Pour l’exercice médical pratique, les objectifs attendus de la documentation électronique sont toutefois un peu plus simples:
– Lisibilité (l’assistant au cabinet médical peut la lire);
– Redondance (le dossier médical est consultable partout dans le cabinet médical);
– Augmentation de l’efficacité (par ex. ordonnance permanente en un clic);
– Netteté /ordre /gain de place;
– Récupération des données ou d’extraits de données:
• au sein du cabinet médical;
• en dehors du cabinet médical (par ex. lettres de transfert, dossier du patient);
– Etre prêt pour le CDS (Clinical Decision Support). Voici quelques exemples à ce sujet:
• Le score AGLA [7], le calculateur Arriba [8] ou le score Frax [9] requièrent de nombreuses données déjà présentes dans le système mais qui, actuellement, doivent généralement être encore une fois saisies;
• Représentation graphique de rapports [10]: valeur de laboratoire <–> médicament (par ex. cholestérol par rapport à la prescription de statines), valeur de pression artérielle <–> médicament;
• Prise en considération des taux de potassium, créatinine ou transaminases en cas de nouvelle prescription de médicaments critiques dans ce cas de figure;
• Proposition relative aux contrôles biologiques périodiques en cas de prescription correspondante de surveillance;
– Export des données à des fins de recherche comme par exemple pour le projet FIRE [11].
Cette liste n’est pas exhaustive. En principe, tout le monde s’accorde sur le fait que les systèmes doivent être «construits» de manière à ce qu’en cas de besoin, toutes les options soient possibles. A l’heure actuelle, nul ne doit se débattre avec le CDS ou la recherche si cela n’est pas souhaité. Toutefois, si le besoin venait à se présenter plus tard, il serait très dommage que certaines options soient inaccessibles en raison d’une saisie incorrecte des données.
C’est pourquoi la suite de l’article présente quelques indications concernant les principes de base de la documentation. Ces propositions constituent des points de discussion: du côté de l’IPI, nous sommes ouverts aux critiques, d’autant plus que nous travaillons en arrière-plan de manière intensive à la «Big Picture», c’est-à-dire le dossier électronique du patient (DEP). Les entreprises de logiciels nous ont communiqué à plusieurs reprises qu’elles préféraient mettre en œuvre des suggestions concrètes après avoir trouvé un consensus plutôt que des souhaits individuels. Nous ne parviendrons jamais à tout concilier. C’est la raison pour laquelle la rubrique «must» sera toujours accompagnée d’une section «nice to have».
Les points essentiels d’un dossier électronique du patient
Consultation
Une consultation donne naturellement lieu à des données administratives qui doivent également être saisies. Le passage ci-dessous se concentre toutefois sur la documentation clinique.
RFE: Reason for Encounter (motif de consultation)
Il convient de consacrer un champ séparé au motif de consultation, sous forme de texte libre et/ou idéalement codé selon la CISP [12]. Le motif de consultation doit être strictement séparé des symptômes subjectifs, mais peut cependant être complètement identique, par exemple pression du partenaire, confirmation d’une incapacité de travail, etc.
Schéma SOAP(E)
Bien que le schéma SOAP(E) provienne du temps des documents papier, il perdure dans de nombreuses solutions de DEP, constitue le standard WONCA [13] malgré des critiques notoires [14] et reste considéré comme éprouvé dans les ouvrages didactiques de médecine générale [15].
S = Subjectif: Données subjectives du patient, si possible en ses propres termes «j’ai soudain ressenti un pincement» (zone de texte libre).
O = Objectif: Résultats cliniques sous forme de texte libre ou avec masque de saisie et génération de texte en arrière-plan (fiche d’état électronique). Les paramètres vitaux (pression artérielle, pouls, poids, indice de masse corporelle, température, etc.) font également partie des résultats objectifs mais doivent impérativement être saisis séparément dans les champs de données prévus à cet effet. Si la pression artérielle est simplement consignée dans le texte de la rubrique «Objectif», la possibilité d’une analyse ultérieure disparaît (par ex. diagramme de l’évolution).
Sur ce point, les systèmes se distinguent parfois de manière considérable: si le champ destiné à la saisie des valeurs de pression artérielle se trouve plusieurs clics plus bas, il est alors mal ou pas du tout utilisé.
A = Assessment (évaluation): Quelle est mon «hypothèse de travail»? Zone de texte libre prévue pour un bref résumé par mots-clés.
P = Procédure: Quelle est la première chose à faire? Zone de texte libre pour consigner les prochaines étapes (examens diagnostiques complémentaires, transfert à un confrère, traitement).
E = Etiquette ou problème de cette consultation: Idéalement sous forme codée, sachant que la CISP s’est avérée être la meilleure classification pour les médecins de famille, par exemple toux, douleur dorsale, éruption cutanée, etc. Les consultations en raison d’un seul problème sont plutôt rares au cabinet de médecine de famille. Généralement, deux, trois voire même cinq problèmes sont traités lors d’une consultation. En ce qui concerne la mise en œuvre et l’exécution d’une liste de problèmes, les systèmes présentent des différences. Il existe en principe deux types d’étiquetage.
Première variante: Chaque problème a son (propre) schéma SOAP. Cela signifie que le problème 1 (toux) présente les champs «subjectif», «objectif», «assessment» et «procédure».
Deuxième variante: Chaque consultation fait l’objet d’une seule entrée SOAP, celle-ci comprenant toutefois plusieurs étiquettes.
Personnellement, je ne me suis jamais converti à la première variante, car les patients concluent rarement un problème avant de passer méthodiquement au suivant. Cela nécessiterait de manipuler plusieurs fenêtres en parallèle. Par conséquent, les médicaments et valeurs de laboratoire doivent également être attribués aux problèmes respectifs pour une structuration propre et ordonnée. Plusieurs collègues travaillent toutefois avec ce type de documentation et semblent très bien s’en sortir.
Médication
Les médicaments doivent exclusivement être repris des banques de données. Les entrées manuscrites sont certes lisibles mais inutilisables notamment pour le contrôle des interactions et la vérification des effets indésirables.
La vue d’ensemble, les avertissements en cas de mauvaise tolérance préalable, la liste des médicaments pour le patient ainsi qu’une «impression d’ordonnance en un clic» sont évidemment requis.
Diagnostics continus
Dans l’idéal, les diagnostics continus sont consignés de manière structurée selon la CIM-10. Le problème du patient (par ex. intertrigo) porte l’étiquette de la consultation actuelle. En «arrière-plan», il est essentiel que le diagnostic continu «diabète» soit également présenté. Bien sûr que je connais mes patients diabétiques, du moins c’est ce que je crois! Mais justement en cas de remplacement au sein d’un cabinet médical de groupe, il est très utile que ces diagnostics continus soient visibles. Dans ce cas, la saisie selon la CIM-10 est pertinente en raison de l’échange structuré de données. Si un jour un rapport de sortie est automatiquement «lu», les diagnostics doivent pouvoir être comparés. Si le diagnostic «diabètes» est déjà consigné, aucune modification n’a lieu; dans le cas contraire, ce diagnostic continu est ajouté. Cela relève encore de l’utopie, mais illustre le fait que le type de saisie devrait rendre une telle option possible.
Facteurs de risque
La plupart des facteurs de risque sont déjà consignés et pourraient être repris de manière plus ou moins automatique par exemple dans le calculateur Arriba (mon préféré!). Le statut de fumeur est saisi, pondéré et surtout actualisé de mille manières différentes. La question se pose alors de savoir s’il conviendrait par exemple d’adopter la SNOMED CT (Systematized Nomenclature of Human and Veterinary Medicine – Clinical Terms). Etant donné que le statut de fumeur influence considérablement le calcul de risque, il est très surprenant qu’il n’existe ici aucune méthode «de pointe».
Informations complémentaires
En ce qui concerne les antécédents familiaux et personnels, les données opératoires et l’anamnèse systémique, les systèmes divergent fortement. Cela est principalement une question d’aperçu et d’exhaustivité des informations. La mise en page, soit la présentation, est très individuelle. La reprise automatique en cas de transfert du patient devrait être possible si besoin.
Perspectives
Les différentes solutions logicielles ont subi divers développements et se trouvent par conséquent à des stades de développement différents. Malheureusement, il existe encore d’importants fournisseurs qui suivent les conseils de quelques collègues isolés sans que ces derniers ne soient impliqués dans la recherche de consensus avec leurs confrères.
Comme cela a déjà souvent été communiqué, ou du moins tenté: nous avons besoin d’un consensus largement appuyé, que nous devons intégrer. C’est précisément l’idée de l’Institut pour l’informatique au cabinet médical (IPI). Comme nous l’avons mentionné, nous travaillons à la «Big Picture» du dossier électronique du patient. Dans le cadre de ce projet, tous les sousprocessus de la documentation électronique au cabinet médical seront dans la mesure du possible listés, décrits et classés selon les priorités. Au cours des prochains mois débutera la première procédure de consultation. Il est prévu de convoquer le plus rapidement possible une «table ronde» avec les partenaires industriels (Société suisse des entreprises spécialisées en informatique médicale – VSFM [16]) dans l’espoir de voir prochainement la réalisation progressive de nos souhaits regroupés. Il est ainsi clair que la «troupe IPI» ne sera en attendant pas mise au chômage.
Correspondance
Dr. med. Heinz Bhend Facharzt Allgemeine Innere Medizin Informatiker (Exec. Master of ICT) Fachlicher Leiter Insitut für Praxisinformatik CH-4663 Aarburg h.bhend[at] praxisinformatik.ch
Références
1 eHEalth-Barometer 2016 à http://www.infosocietydays.ch/images/content/dokumente/barometer/163101_Prsentation_Swiss_eHealth_Barometer_ehealth_Forum_2016.pdf
2 Djalili S: Wer eHealth sucht..; SAEZ 2015;96(43):1575–1578 ...
3 Factsheet GDK, Ziele und Stand eHealth Juli 2015
4 www.praxisinformatik.ch à projekte à going paperless
5 Electronic Medical Records, Built For Efficiency, Often Backfire; online unter http://www.npr.org/sections/health-shots/2014/11/ 07/361148976/electronic-medical-records-built-for-efficiency- often-backfire
6 The National Learning Consortium (NLC) Guidelines Goals and Objectives for Electronic Health Record (EHR) Implementation; online unter: https://www.healthit.gov/providers-professionals/implementation-resources/goals-and-objectives-electronic-health-record-ehr
