Hace un mes que se implantó en el centro de Atención Primaria donde trabajo el programa de gestión de historias clínicas AP-Madrid. Desde entonces han sido varias las incidencias que hemos sufrido, algunas de ellas sumamente relevantes para la seguridad del paciente. Considero que debe revisarse seriamente este programa y las fórmulas para su implantación.
Soy consciente de que han sido muchos los profesionales que se han quejado del funcionamiento de este programa desde que se implantó por primera vez en los centros piloto hace 4 años y posteriormente en el resto hasta conseguir una cobertura superior al 70%. Incluso existe un foro en el que se manifiestan continuamente los defectos y las quejas sobre el mismo. También es verdad que no se pueden despreciar las propiedades y particularidades que son positivas. No obstante me permito hacer algunas consideraciones con la esperanza de que puedan servir para mejorarlo y sobre todo para que se puedan evitar los riesgos que creo conlleva para los pacientes por sus defectos y actuales limitaciones.
No trato de analizar en profundidad todos los aspectos del programa. Me limito a comentar incidencias graves o aquellos aspectos del mismo que pueden afectar a la seguridad del paciente.
Uno de los sucesos más relevante y grave es la pérdida de información referente a pacientes durante el proceso de implantación. Al trasladar (migrar) los datos del programa previo al actual se pierden datos. He podido constatar esta pérdida de información por tener el caso de pacientes a quienes e impreso la información previa para enviarla a especialistas o para hacer informes (la que existía en OMI-AP) y tras la implantación de AP-Madrid esta información no aparece. Este hecho además pudo ser confirmado por los técnicos que estuvieron en el centro durante el proceso de implantación.
Ante esto no es de extrañar que en más de una ocasión se tenga la sensación de que “faltan” datos en la historia a tenor de lo que nos comenta el paciente, aunque no tengamos forma de demostrar que sea así. Sin embargo, al confirmar que ocurre con casos puntuales surge la terrible duda sobre lo que “puede no estar y no lo sabemos”. Solo en casos muy concretos nos acordamos muy bien de todo lo realizado a un paciente aunque no conste escrito. Esta situación puede crear una gran incertidumbre y riesgos, especialmente si el paciente dice que toma una medicación que no nos aparece, o si volvemos a realizar una prescripción de algo que ya no toma pero que nos figura como su medicación activa, aunque realmente ya no lo sea.
No puede ser que esta falta de migración y pérdida de datos sea la primera vez que ocurre. ¿Cuánto pasa?. ¿En qué porcentaje?. Alguien debe conocer estas respuestas. Se debería informar en el momento de la implantación, antes de la migración de un programa a otro, que esta pérdida de datos puede ocurrir y qué hacer si se detecta. De la cantidad de información perdida dependerá la validez y fiabilidad de la información que permanece.
Otro problema grave relacionado fundamentalmente con la prescripción es el que se produce con la fusión automática de historias, lo que ocurre cuando un paciente ha estado en otro centro que ya tenía AP-Madrid. Habitualmente se realiza la fusión de historias de forma voluntaria (lo puede realizar cualquiera con acceso a las historias clínicas, de cualquier centro donde se atienda al paciente y que tenga AP-Madrid, y lo haga con criterio o no) y otras veces ocurre sin que sepamos como se ha producido la fusión. Hay casos en que el paciente se trasladó a nuestro centro hace años y durante este tiempo se le han creado sus correspondientes episodios y prescripciones relacionadas con ellos. Como en el otro centro nadie cerró sus prescripciones crónicas, al fusionarse las historias aparecen todas (las actuales y las antiguas), en ocasiones duplicadas, con el consiguiente desconcierto que crea y el riesgo de prescribir algo que incluso pudo dejar de tomar porque no era eficaz o con consecuencias peores si se retiró porque causaba efectos secundarios. Nadie ha ideado una formula sencilla (como el cambio de color) para que lo que procede de historias previas no se pueda confundir con episodios y tratamientos realmente activos.
A esto añado otro riesgo más. Según se nos informó en las jornadas de implantación “nunca se cuelga”, o casi nunca, pero, ¡qué mala suerte!, en la primera semana ya tuvimos un día completo en el que era imposible disponer de la información porque no funcionaba internet. En este día tuve una reclamación (contra el Sistema) por error de medicación. El paciente acudió a por los antihipertensivos que tomaba. Sabía el producto que tomaba (a medias) y me aseguró que de una dosis determinada. Cuando pude comprobar si estaba bien lo que le había recetado (y porque se me ocurrió tener esa precaución) el paciente tomaba un fármaco con dosis doble de la que yo le había recetado y le faltaba otro principio activo. Actualmente todo el mundo confía en que “todo está en el ordenador” y es difícil que sepan exactamente lo que toman en composición y dosis. Por suerte se lo pude cambiar antes de que se redujera bruscamente el tratamiento de su hipertensión.
Por último un comentario sobre el tiempo que consume el programa. Es un programa que, aunque haya sido testado en centros piloto, no parece pensado y diseñado, como debería ser, por los usuarios del mismo, es decir los profesionales que lo manejamos día a día para atender a nuestros pacientes. Obliga a pasar por diferentes ventanas, demasiadas, para llegar por ejemplo a crear un episodio o realizar una prescripción, en vez de que algunas de esas ventanas fueran opcionales. Como ejemplo si quiero depurar un tratamiento crónico, como he comentado antes por estar duplicado, no puedo hacerlo en una misma pantalla con todo lo que sobra, he de hacerlo uno a uno con cada medicamento y confirmar hasta 3 veces que quiero retirar cada medicación. Un sistema de información que obligue a que se esté más pendiente de la aplicación que de los problemas de los pacientes es un mal sistema de información y si consume el tiempo que debo dedicar a los pacientes, y ya no hay mucho, se convierte en un problema muy grave. Un sistema de información es eficiente cuando facilita la utilización racional de los recursos con disminución del tiempo dedicado a las labores burocráticas, incluido el propio registro, y aumenta el tiempo dedicado al paciente. Puede ser que haya sido pensado para tener 30 pacientes en consulta al día, pero no, como es mi caso, para atender muchos días a más de 50. Simplemente resulta imposible.
Antes de poner en marcha un sistema de información han de valorarse varios aspectos. En primer lugar si es factible y pertinente, es decir, la posibilidad fundamentalmente económica de disponer del mismo. En este caso así ha sido considerado a pesar de la crisis económica. Ha de ser fiable y válido, tanto en la carga de la información como en la transmisión y la explotación de los datos. En este caso pueden surgirnos muchas dudas sobre dicha fiabilidad y validez. La capacidad para adaptarse a la realidad asistencial y los diferentes modelos organizativos debe estar previamente contrastada, y supongo que así se ha realizado, aunque con nuestra carga asistencial parece que no se había contado. Debe tener la capacidad de ser monitorizado, evaluado y de incorporar las modificaciones que se estimen necesarias en el transcurso de su desarrollo. Debe admitir la conversión de los sistemas de información previos, sean informáticos o no. Y fundamentalmente deben orientarse al servicio y mejora de la organización verificando previamente la aceptabilidad de los profesionales que son quienes los van a utilizar, por lo que conviene que se tengan muy en cuenta sus opiniones y se logren consensos orientados hacia la mejora continua del programa.
Joaquín Morera Montes
Médico de Familia
Nota:
He realizado estos comentarios esperando que pueda servir para algo mi experiencia en sistemas de información y registro. He tenido la suerte de haber participado en el diseño de la Historia Clínica de la Comunidad de Madrid (vigente desde 1989 hasta las implantación de aplicaciones informáticas), de haber formado parte del grupo de trabajo que elaboró el diseño de OMI para Stacs (el anterior programa informático hasta la implantación de AP-Madrid) y de haber sido docente durante muchos años en sistemas de información para el Diplomado de Dirección y Gestión de Equipos de Atención Primaria organizados por el Centro Universitario de Salud Pública y para diversos Diplomados de Sanidad y Másters de Gestión organizados por la Agencia Laín Entralgo.
Tras el proceso de implantación envié un informe analizando las limitaciones y los defectos que existían a mi modesto entender en el programa ofertando posibles soluciones. La única respuesta que he recibido hasta la fecha es que se ha enviado a la Unidad correspondiente para su conocimiento.
Escrito por juanbravoa 
ATensión Primaria 