Más de 100.000 sanitarios en hospitales públicos españoles usan cada día el programa Selene para gestionar a miles de pacientes. Muchos se quejan de continuos fallos en el sistema que suponen una "pérdida de tiempo brutal". Es el sistema de gestión de pacientes que usan 67 de los 468 hospitales públicos en España. Se trata del software comercial con mayor implantación en los hospitales de nuestro país por número de centros, número de usuarios y años de funcionamiento (dos décadas) y, a la vez, es uno de los que más quejas acumulan.
|
etiquetas: españa , hospitales públicos , selene , software de gestión de pacientes 
Resumen: mala gestión. No saben crear requisitos de un proyecto ni validarlos. Además, quieren pagar cacahuetes para proyectos que dada su complejidad necesitas a gente superior a la media.
1. Escalabilidad: la lentitud se vuelve algo normal en un sistema con uso intensivo de datos. Actualmente hay muchas soluciones a esto, pero que no existían antes. Eso sí, en algunas situaciones habrá que aumentar el dinero para el mantenimiento de una infraestructura que pueda soportarlo.
2. "Seniority": tanto el sector público como el privado dedicado a licitaciones carece de supervisores con años de experiencia. Tanto para gestionar el proyecto desde la parte privada como el comprobar si los requisitos se han cumplido desde la parte pública. Pero claro, la experiencia se paga y no creo que el gobierno compita con sueldos de >60k por programador.
3. Evolución del sistema. Un sistema siempre tiene que ir evolucionando. A veces, esto supone cambios muy profundos pero necesarios que dejarían un agujero en el presupuesto y no se quieren hacer cargo. Se tiene que asumir esto en el ciclo de vida de un software y no pensar que es un objeto creado y con un mantenimiento fijo a posteriori.
4. Licitaciones poco técnicas en cuanto a requisitos. Eso hace que los programadores no vean / no quieran hacerse cargo de errores que pudieran generarse. Por ejemplo, no es lo mismo tener una cantidad de usuarios menos a 2.000 que tener que gestionar 1.000.000, cosa que puede generar un retardo importante en el programa. También afecta directamente a requisitos que se podrían introducir en la licitación como "dado un sistema de 1.000.000 de usuarios como máximo, esperamos que X acción suponga menos de 2s de tiempo".
... y paro porque me canso
Estas aplicaciones tienen un elevado grado de complejidad que aumenta aún más por, insisto, una ausencia de criterio unificado en la forma de trabajar y la propia evolución del producto para adaptarse a décadas de evolutivos y nuevas necesidades. Y, al final, como se termina simplificando: todas son la misma mierda. Pero se está exigiendo que algo cuyo core se diseñó hace 30 años esté preparado para el presente sin apenas coste, en un sector cuya evolución tecnológica es constante. Imagina tratar de hacer un coche con las necesidades actuales usando un motor y una mecánica de hace 60 años. ¿Y por qué no hacer un coche nuevo? Porque no es rentable. En mi opinión, tras meditar sobre el asunto con otros colegas, la solución pasa por diseñar un modelo de datos público que cubra las necesidades de la atención sanitaria y levantar las aplicaciones públicas y/o privadas sobre ese modelo de datos. Esto también tiene inconvenientes pero, en mi opinión, mejoraría evolución de estas aplicaciones porque se tendería a la estandarización de circuitos de trabajo.
A ver: si tu vendiste un producto y lo cobraste, cualquier trabajo extra que tengas que hacer es una pérdida de dinero. Un gasto que no reporta beneficios porque ya cobraste antes y no te van a pagar extra por solucionar los problemas.
La solución "obvia", sería cobrar un mantenimiento mensual. Así tienes la ventaja de que estás ingresando dinero constantemente haya o no haya problemas y al cliente le solucionas lo que necesite. Pero... ahí surge otra buena estrategia de negocios: cobrar todos los meses pero no dar nada a cambio, o dar lo menos posible. Si el problema se soluciona reiniciando, ¿para qué gastar dinero en corregirlo definitivamente? A demás, si lo corriges y ya no falla puede que el cliente ya no quiera pagar el mantenimiento mensual.
Aquí la clave está clara: Se trata del software comercial con mayor implantación en los hospitales de nuestro país, o sea, que gastar dinero en mejorar el software no les conseguirá beneficios extra. Y una inversión sin beneficio es un mal negocio.
(*) Todo esto oído a un consultor de SAP que se alquilaba a 300 euros/hora.
Lo que antes una persona tardaba entre 3-5 minutos por cada material, yo tardo 1 minuto para todos (15000 como máximo cada vez).
Sólo es ponerse y practicar.
Edit: en serio, lo q paso es q vi tu cita y no lo había dicho yo. Y si está en el artículo... Yo esq comento sin leer. Llámame raro.
1.- Los problemas de la salud pública en materia informática son varios, la financiación, la calidad del puesto, pasando por la formación del usuario.
1.1-hay unos 3 o 4 informáticos por área, y piensa que cada área son tropocientos ordenadores, llegando al caso de tener que ayudarse entre informáticos de otras áreas por falta de personal.
1.2.- La cantidad y calidad de la formación del usuario son casi nulos, teniendo que estudiarse los programas (y muy básicamente) en las oposiciones.
1.3- La calidad del puesto de trabajo, primando el precio a la competitividad del instrumento.
2.- La seguridad. Si no recuerdas mal, solo el año pasado sufrieron 2 o 3 ataques masivos, dando el resultado de gente no pudiendo trabajar electrónicamente durante días.
3.- La calidad del código es cuanto menos dudosa, así como que tienen que hacer reestructuraciones y actualizaciones cada muy poco tiempo. Puede ser que se olviden de acotar entradas, delito de seguridad mayúsculo.
Todo esto lo sé de primera mano, desde trabajadores del puesto hasta técnicos. Es una vergüenza lo de la informática en los servicios públicos, reclamando interinos que los hagan fijos por antigüedad, y el sistema los necesita, así como más técnicos.
La mayoría de los programadores son unos flipados que no reconocen sus errores y culpan a cualquiera de ellos en vez de aceptarlos, aprender de ellos y dejar de joder la vida a quien tiene que soportar sus cagadas. También hay gente muy buena, los menos.
Como todo buen meneante
"Es un programa muy poco intuitivo. La distribución de los botones en la pantalla no tiene lógica. Si quieres saber el historial de medicación de un paciente, tienes que imprimirlo primero para verlo completo, en el ordenador no podíamos. Pierdes mucho tiempo y gastas papel""
"Se nota que no está pensado por médicos o enfermeros. Está creado por informáticos sin tener en cuenta las cosas que necesitamos los sanitarios. No es intuitivo y va lento, pero no sabemos si es por los ordenadores o qué. Cuando se cae, estamos media hora o más sin poder trabajar. Por suerte, ocurre poco, una vez cada mes o dos. También sueles tardar en encontrar los informes, se pueden guardar hasta en tres sitios diferentes"
"Nosotros no tenemos todo unificado. Usamos un sistema para medicación de pacientes ingresados, otro para los que damos de alta, otro para acceder a hospitales de la Comunidad de Madrid... Cada día uso siete programas distintos, cada uno con su usuario y contraseña. Pero Selene es el más importante y, de largo, el peor. ¿Ves normal tener que borrar información del historial clínico porque hay limitación de caracteres? ¿O que el programa se cierre de repente y pierdas tu trabajo? ¿O que tengas que estar entrando todo el rato para saber cuándo están listas las analíticas que has pedido? No hay alertas que te avisen, ni un triste icono. Los compañeros de analíticas nos tienen que acabar llamando por teléfono cuando hay algo urgente"
Ninguna se está refiriendo a tecnologías, arquitecturas o paradigmas de programacion usados, se refieren a la definicion de flujo de trabajo y eso meu, eso no lo hace el programador, al que le cae la bronca cuando el que se está escaqueando es el funcional
HCIS, ya más moderno, se me escapa. La implementación en el Gregorio fue larga y cara de Cojones, eso sí.
No necesita lo mismo un hospital de referencia, con miles de pacientes, que un ambulatorio de una ciudad turística.
De igual forma no hay 17 programas de bibliotecas. Hay tres, 3-4 empresas a lo sumo que comercializan esos programas en España. Lo que haces cada comunidad es comprar el programa, dimensionado al número de licencias que necesitan. Y la empresa les da el soporte según lo que pagan y lo que necesitan. Y si necesitan customizaciones particulares cada cual se paga la suyas.
Por ejemplo muchas de las bibliotecas cabeceras de provicia utilitzan Absys, que es el programa original cuando todavia dependían del ministerio. Después de la transferencia algunas como Catalunya migraron a milenium, porque era lo que tenian en sus biblioteas universitarias y sus gestores querian aprovechar esa experienza.
Los dos sistemas dan un servicio lo suficientemente bueno para mantener los dos en sus respectivos ambitos.
Yo considero que la competencia ayuda a que esos programas crezcan y se desarrollen. Por ejemplo hay una empresa de Albacete que se ha especializado en proporcionar un pack básico económico en la nube de servicios de administración electrónico para ayuntamientos. Los ayuntamientos se subscriben y tienen todos los servicios interoperables en pocos días.
Que esto lo debería haber hecho el estado, o los diputaciones de forma centralizada...se intentó y algunos ayuntamientos lo usaron. Pero era tan obtuso que solo unos pocos lo consíguelo. Luego vino la empresa privada y se llevo el mochuelo... y esto es bueno.
Programas sanitarios que han costado MILLONES son incapaces de arreglar un bug sencillo. Ridículo.
Estuve en una conferencia en la Fosdwm de un burócrata europeo y casi no sale vivo de allí.
1. El modelo de proyecto: unos gestores públicos gastan dinero de otros (los ciudadanos) para que un tercero (el contratista) desarrolle un producto/servicio para unos cuartos (los profesionales del hospital).
2. El modelo de contratación: el contratista consigue el proyecto con una propuesta a la baja. Ya reducirá costes de alguna manera.
3. El modelo de empresa: el contratista tiene desarrolladores malpagados que son tratados como carne al peso para compensar los enormes costes de los consultores/analistas con solera.
4. El modelo de trabajo: la mayoría de consultores/analistas hacen un trabajo terrible definiendo los requisitos y, por otro lado, interfieren en decisiones técnicas que les vienen grandes (porque la tecnología les pasó de largo hace ya mucho tiempo). Las indefiniciones acaban siendo resueltas por los desarrolladores, muchas veces ad-hoc y, por otro lado, se ven obligados a usar herramientas o tecnologías impuestas que no sirven o no son las más adecuadas.
5. La metodología de análisis: ¿quién define el producto, el cliente o los usuarios? ¿Quiénes son los interlocutores expertos que más valor aportan? ¿Quiénes producen tanto ruido que deben ser apartados? ¿Se les puede apartar, o su "autoridad" lo impide? ¿A quiénes les importa que la solución desarrollada sea la que se necesita?
6. Las tecnologías: ¿cómo de actualizados están los responsables técnicos del proyecto sobre la mejor manera de abordarlos? ¿Son conscientes de que la única posibilidad es tomar un enfoque holístico que reduzca al mínimo la complejidad?
Visto lo visto, lo raro es que alguna vez un proyecto de estas características termine llegando a algún sitio que no sea el cubo de la basura.
Errores de usabilidad pueden deberse a falta de definición o cambios constante de la misma. A que no se ha contratado perfil de UX o el que hay es un vende humos. A que el tipo de front es un sudas que mete los componentes según se le abra el cursor en el IDE. O que lo ha acabado haciendo alguien de back hasta las pelotas de esperar a que el tech leader de front acabe de hacer átomos, moléculas y otras formas moñas de llamar a los widgets.
Lo de que te puedas encontrar informes en tres sitios diferentes puede deberse a los programadores amigos del copy&paste o a una falta total de organización y que el mismo informe lo han hecho tres personas en tres sitios diferentes cada uno a su manera.
Lo de integrar claves únicas, tokens cifrados o firmados para hacer sistemas acceso centralizados me parece utópico. Si la mitad de los programadores no tiene claro lo que es el character encoding como para reunir a dos que trabajan en plataformas distintas para que se pongan de acuerdo en algoritmos, modos, padding, expiraciónes, revocaciones,... de "marcianitos" serializados en base-64. Y si, hay librerías de oauth fáciles de integrar, pero al final uno va a meter oauth 1 cuando se había decidido oauth 2 o cualquier otra cagada a solucionar sin tener acceso a las trazas (y esto tan típico de tener que resolver cagadas a ciegas si que es fallo de gestión).
Lo de la limitación de caracteres podría ser un fallo de definición al poner límites no realistas. Lo de hacer el sistema de notificación suena a típica fase 2 que llegará con el esperado Godot. Pero no creo que nadie tenga que definir: "Oye, es un requisito que el programa no se cuelgue aleatoriamente". Que cuando van los obreros a casa a arreglar un gotera no les tienes que decir "no me quemes la casa para acabar con la humedad" como parece que hay que decirle a algunos programadores inconscientes y medio autistas.
A título profesional ver las notas de un médico para saber las actualizaciones de tratamiento es un puto infierno porque ni peter sabe dónde se escriben y te las encuentras en mil sitios que debes mirar por si acaso (tampoco te notifican novedades de pruebas o si ha salido la analítica por ejemplo, lo tienes que refrescar por si acaso).
Por la via del sofwar libre, se podriia enseñar a los colegios como se evoluciona y creo sofware util para la sociedad.
#16 Pues ese seriia otro motivo para hacerlo sofware libre, hacerlo investigable, para ver si saca datos delicados.
Antes en los ordenadores habia unos pocos datos y poco peligrosos, peor ahora esta todo y la capacidad de gestionarlos y el interes en sacarlos partido es muchisiimo mayor que hace unas decadas.
#56 Pues la toma de requisiitos podriia ser una profesion en si misma. Hay gente muy curiosa que interesa aprender de temas nuevos que no tienen que ver nada con su campo.
Tambien los profesionales de toda la vida, tampoco saben hasta que punto la informatica puede solucionarles tareas.
#71 Curiosamente ninguno de los dos suele ser informatico
El presentacion de Ingenieria romana,( isaac moreno Gallo) se estaba quejando todo el rato que los historiadores no sabiian interpretar cosas iingenieriiles de la antiiguedad, porque no tenian formaciion tecnica.
Un GC, se quejaba de que no habiia forma de buscar matriculas por parte de la matricula,porque la gente muchas veces solo se acordaba de parte.
He trabajado en ambos lados, haciendo pliegos de contratación para la administración pública (para un organismo autónomo) y dirigiendo equipos de desarrollo en contratos públicos. A lo contrario que lo deja entrever la carencia de argumentos de tus dos comentarios, yo sí sé perfectamente de lo que hablo.
De nada.
En vez de ir de chulo, podrías iluminarnos. Has elegido la prepotencia, eso lo dice todo.
A buen entendedor, pocas palabras bastan.
Hace unos años cambié a televisión, el mismo soft que se usa para hacer Fornite, unreal, se usó para hacer los fondos de Mandalorian y otras muchas más, producción virtual lo llaman, me llamó una productora y acepté para cambiar de aires, gran error, nunca pasé tanta vergüenza, en la primera reunión con los clientes el CEO de la empresa que me había contratado, se inventaba términos, fallos garrafales, diciendo unas tonterías tremendas, prometiendo cosas que no podía cumplir porque habría que multiplicar le presupuesto por 100, y lo peor, en el otro "bando", el del cliente, había un tipo que trabajó conmigo en videojuegos y sabía que aquello era penoso, cuando terminó me quedé con él para salvar los muebles y me dice., ahh no te preocupes estas chorradas siempre son igual, los ceo no tienen ni idea, ni siquiera los lameculos que llevan como director de estrategia logística de contenido interactivo orientado a tigres blancos, cargos bonitos, para decir ayudante, pero siempre llevan a uno que sepa algo, porque ellos son conscientes que no tienen ni idea, sueltan chorradas y ya.,
El proyecto fue un desastre, lo dejé en menos de un año., eso sí, la productora de las más importantes, con contratos millonarios con Amazon y netflix, pero con un CEO que no distingue una cámara de una alpargata..