En pocas semanas, mi centro adaptará el programa AP-Madrid para la gestión de las historias clínicas y demás tareas. Durante meses, se han comentado en diferentes foros las ventajas e inconvenientes de este programa. Leer los comentarios de Joaquín Morera, compañero de residencia y médico de familia comprometido desde hace muchos años, es una manera positiva de aportar soluciones para la mejora de dicha herramienta. Esperemos que los responsables sean sensibles a estas sugerencias.
AP-Madrid. Un programa que puede comprometer la seguridad
del paciente
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.
Ya sé que no es un consuelo, pero esto pasa en todas las CCAA: con Diraya en Andalucía, con Abucasis en Valencia, con Medora en Castilla y León. Todavía recuerdo el desastre de migración del SIAP-Win al OMI en Teruel hace unos años. Lo que iba a ser una operación de una semana, con formación incluida, se convirtió en casi mes y medio, con cuelgues, pérdidas de datos y enfado de los pacientes. De los profesionales, mejor ni hablo. Ahí se han enterrado muchos recursos, para no estar mejor que hace 20 años, cuando con programas caseros en FoxBase tenías todo lo que necesitabas y encima ahorrabas al sistema montones de dinero, cosa que nunca agradeció.
ResponderEliminarRecomiendo se lea también en el blog de Rafa Bravo, Primum non nocere, el artículo "AP-Madrid o historia de un despropósito", de Pablo Astorga, también interesante y donde aporto un comentario.
ResponderEliminarSaludos.
No sé para qué los responsables de estos programas, sus diseñadores y programadores acuden a congresos la Sociedad de Informática de la Salud, realizan masters y cursos de ergonomía pagados por las distintas consejerías, si después las decenas de historias electrónicas que hay pecan de los mismos problemas. Y casi ninguna de las que he conocido se diseña con la participación relevante de sus usuarios. Se ve que tienen miedo de que les pidan herramientas útiles.
ResponderEliminarUna vez mas pecais de ilusos:
ResponderEliminarNo hace falta ser Rappel para saber que detras de toda esta aparente pasotismo oficial y estos problemas simples de diseño de software , existen contratos multimillonarios de asistencia informatica.
Parece que recuerda a lo que se dice de algunas empresas de antivirus, la receta es muy antigua se crea un problema y se necesita a alguien "casualmente" para resolverlo.
Tras año y medio de tenerlo instalado en mi centro de salud, en dos palabras: aberrante y desesperante.
ResponderEliminarParece que esto es un problema más general de lo que parece, y se debería clamar por la "informática basada en la evidencia y en la seguridad":
ResponderEliminarhttp://www.biomedcentral.com/content/pdf/1472-6947-11-27.pdf
Un saludo