¿Cuántas veces les ha pasado? Se acercan a una ventanilla, hacen una petición razonable y a la que tienen derecho y les contestan que no pueden atenderla. La razón: “El programa no me deja”. O bien el software no les permite escribir en ese campo de la base de datos o bien lo que no les permite es borrar
|
etiquetas: derechos , software , sentencia
No es ni la primera ni la última vez que ocurre esto.
Además ha hecho algo que parece una tontada, pero que es relevante.
En lugar de ir por la vía de la denuncia en la AEPD se ha tirado directamente al juzgado. No se si decir que ha hecho lo más apropiado en este caso pero seguramente ha acertado de pleno.
Bien por Francisco, hasta los cojones de informaticos inútiles !!!
No es ni la primera ni la última vez que ocurre esto.
Además ha hecho algo que parece una tontada, pero que es relevante.
En lugar de ir por la vía de la denuncia en la AEPD se ha tirado directamente al juzgado. No se si decir que ha hecho lo más apropiado en este caso pero seguramente ha acertado de pleno.
Con buena voluntad podría haberse solucionado mucho antes. El software puede que no permita esa modificación, pero seguro que a la BD puede accederse por otros métodos.
www.joseantoniocobena.com/
Sería un alarde de transparencia que ofreciera explicaciones. No se si es mucho pedir
Saludos
Estás detrás de una mesa, sentadito y metiendo datos en un programita con su GUI, tú no tienes ni idea de software, bases de datos, programación, servidores ni nada, solo sabes meter datos en un campito de texto y pulsar el botón guardar. Y sabes que ese programa no permite cambiarlo una vez que se ha guardado un valor por más de 24hs. Es lo que le dices al cliente.
El sistema informático de Salud de la Junta no funciona
www.libertaddigital.com/sociedad/el-sistema-informatico-de-salud-de-la
El sistema informático Diraya roba de 45 a 75 minutos cada día a los pacientes
www.20minutos.es/noticia/376963/0/diraya/medicos/sas/
Cosas del capitalismo
Es mejor no denunciar mediante AEPD si se puede evitar, porque rara vez solucionan algo.
De todos modos, tan difícil es acceder a la base de datos y cambiar el dato desde ahí?
Ahora en serio, todo software que usen administraciones públicas debería estar licenciado como software libre y ofrecer y repositorio público, así como un sistema de seguimiento de errores
En general aceptamos en término "informático" pero informático no es nada. Es como si a todo lo que tenga que ver con la aplicación de la justicia(jueces, abogados, procuradores ...) los llamáramos justicieros.
Puede ser cierto, ¿pero de que informático? El programador, el analista, el de sistemas, el administrador de la base de datos... ¿Quién? o es el propio cliente que de informático no tiene nada y no sabe que no hacen magia(lo mismo que los "informáticos" no tendrán ni idea de como funciona el negocio del cliente) y tiene que pedir y comprobar que el programa hace todo lo que se necesita.
No sabes de lo que hablas. Este no es el caso de un programador inútil, que es más difícil hacer un control de no-cambiar-pasadas-24-horas que no hacerlo.
Tienes el mismo mal que quien negó la rectificación de datos a Francisco. Piensas que lo que haga el programa es lo determinante. Y no, lo determinante son las especificaciones que haya pedido quien encargó el programa.
Mientras sigamos así, en españa seguirá valiendo al excusa de "fallo informático" para justificar cualquier desmán, incluso abusos.
No sé si lo entiendes.
PD: Me gustaría leer las críticas vertidas si la reconversión de ley 11/2007 se hubiese encargado por completo a Indra o al Corte Inglés.
Esto es actuar de mala fe. Justo lo que se espera de una administración que representa a los ciudadanos, vamos.
- Tengo '); DROP TABLE *
- Espere que lo introduzco.
xkcd.com/327/
Nuestro queridisimo Bobby Tables
Porque en la sentencia dice algo así como "sin hacer expresa imposición de las costas a ninguna de las partes".
Porque si esto es como parece, pues seguimos igual de indefensos, si para hacer valer tus derechos -además de perder un montón de horas- tienes que pagar abogado, procurador y demás, pues han vuelto a ganar. Como siempre.
Por norma general no es así, cuando hay un problema en una aplicación informática de cualquier tipo, el funcionario o laboral que la gestiona abre una incidencia y el servicio informático pertinente la soluciona. Eso incluye desde modificación de especificaciones, cambios en el código, puesta en producción y formación si es necesario, hasta modificaciones directas en las BD directamente.
Esas rectificaciones forman parte natural del ciclo de vida de las aplicaciones y se suelen solucionar en unos días y hasta en pocas horas si son críticas.
El problema este, por lo que veo no está en el software, si no más bien en el gestor que no abre la incidencia
#1 Que manía la gente de siempre matar al mensajero. El culpable, si es que hay uno en concreto, es al, o son los, que han diseñado la aplicación, o quizás más bien, a los que han probado la herramienta, aunque en mi opinión es una carencia total de comprensión de las necesidades de los clientes finales.
Así que seguramente el problema sea de la pericia de algún gestor que no sabía lo que quería pero lo quería para ayer y a cuatro duros.
Pues se me toma cada dos horas una de éstas:
DELETE ALL
y una de éstas:
COMMIT
Da igual que llames, te dicen que no es posible.
Pues si, en la administración, un analista funcional hace de técnico, padre, madre, amante, psicólogo clínico, publicista y confesor del equipo que va a gestionar la app.
Encima de estar malpagados, ¿váis a tocar los huevos echándonos la culpa siempre de todos los fallos que pasan sin saber de dónde vienen?
NOTA: Me alegro porque la reclamación de este señor tuviera éxito porque es impresentable que no se puedan cambiar datos erróneos de un historial médico pasadas 24 horas, que en juego está la salud de la gente
Pero habría que ver qué gol le han metido a la administración con el software gracias a que algún politicucho se haya llevado su correspondiente sobre/comisión.
Una respuesta adecuada (balanceando el problema técnico que pueda suponer esta petición, con el derecho del ciudadano a la rectificación) hubiera sido responder algo así como:
"Disculpamos las molestias por el error cometido en el almacenamiento de su historia.
Actualmente, la forma en que nuestro sistema informático (DIRAYA) está diseñado, no contempla en primera instancia modificaciones a la historia una vez transcurridas 24h, por lo que no podemos atender de forma inmediata su petición.
No obstante, se ha abierto la incidencia correspondiente para que se corrija este error puntual, petición que gestionará el departamento XXX (datos de contacto abajo, nº de referencia de la incidencia YYY).
Hasta que la modificación en la base de datos sea efectiva, le adjuntamos un certificado firmado por nuestra unidad que refleja ese dato de su historia tal y como quedará (Nº de registro de salida ZZZ). Este certificado debería tener validez legal ante cualquier organismo que requiera la información relativa a su historia médica.
Atentamente."
Probablemente el ciudadano no habría recurrido la respuesta, ni habría habido juicio, y la administración podría ahora tomarse el tiempo que necesite para realizar la actualización del registro en la base de datos, sea cual fuere la manera más adecuada de resolver el problema técnico.
Que supongo que es lo que hará ahora.
Y otro tema es que a lo mejor no queda nadie capaz de saber dónde/cómo hay que meter mano. Es muy posible que el programa se subcontratase a una empresa, y por tanto los que lo hicieron saben cómo va, mientras que los usuarios lógicamente no. Para resolver esto, o mirarán de que alguno de sus informáticos "deduzca" por dónde hay que meter mano a esto, o se lo encargarán a la empresa original, que les cobrará un pico.
Y lo que puede ser peor, hay un plazo para recoger un paquete, si vas el último día y no te lo pueden dar porque no les va internet, lo devuelven igualmente y ya te toca a ti reclamar después (esto último me lo dijeron desde el teléfono de correos).
Por curiosidad, las fechas del proceso, según la sentencia:
Fecha de alta en centro de salud que motiva la reclamación: 19/9/2011
Desestimación de la rectificación pedida: 17/11/2011
Recurso de alzada: 5/1/2012
Presentación de demanda: 4/10/2012
Celebración de la vista: 19/6/2013
Sentencia: 27/6/2013
Casi dos años. ¿Y cuánto dinero, y quebraderos de cabeza?
PS.: No soy abogado, obviamente, pero sí sé que la 30/92 noticias.juridicas.com/base_datos/Admin/l30-1992.html es una ley que todo el mundo debería conocer, y reclamar su cumplimiento a las administraciones.
Perdona que interrumpa tu fanboyismo barato con datos reales.
Y también me gustaría saber cómo lo van a solucionar ¿le van a pagar un pastón a Indra para que modifique la aplicación y permita modificar los datos pasadas 24 horas?(supongo que no habrá otra opción, dudo mucho que nuestros políticos hayan solicitado el código de la aplicación para que sea modificada por los informáticos de la Junta y la documentación del diseño de la BD para acceder a modificar lo que sea necesario sin pasar por la aplicación, luego tocará pagar a Indra sí o sí) ¿alguien se va a hacer responsable de ese gasto extra por la mala especificación de la aplicación?
No tiene pérdida como lo presentan >_<
me sorprende que nadie lo haya nombrado hasta ahora...
Así que la culpa a otros.
Si el sistema está bien montado no va a permitir que cualquiera altere esos datos, eso antes que nada, por una cuestión de permisos. Además, tampoco me extrañaría que la base de datos esté montada en algún sitio externo, donde la administran, no puedo presuponer que nivel de centralización existe respecto a esos datos.
Eso sí, aunque quizás esa función no debería estar disponible para alguien que atiende una ventanilla con las consultas y servicios habituales, obviamente si debería haber alguien con esa capacidad o existir algún mecanismo para que alguien haga algo.
Y en ese sentido, supongo que es un tema de ignorancia, a ellos simplemente les dieron el software, y nadie sabe realmente como funciona. Nisiqueira me extrañaría que realmente alguien si tuviera a su disposición esa función, pero que no tengan idea de como se usa, o que si tuviera la posibilidad de contactar con algún sitio para su modificación, pero que tampoco sepa siquiera que existe ese protocolo.
No meto la mano en el fuego por nadie, simplemente no hablemos por hablar.
- Vale, ponga el 00000014Z
En Aragon (mi caso) hay muchas opciones del programa que no se pueden eliminar, una vez realizados, imprimidos, o pasados 24 horas. Asi lo pidio el cliente (los medicos que estan al cargo de las gerencias.) y si por culpa de una denuncia sin pies ni cabeza, tienen que cambiar de software, esque es pa'cagarse !!!
Eso no es así, los contratos de los servicos y entes informáticos de la administración con las empresas de desarrollo como Indra o Infoservicios contemplan en su pliego de contratación los tipos de modificaciones de los desarrollos y esto es una modificación menor que no tiene apenas coste
Ejemplo de actividad en una HC (historia clinica) que puede borrarse sin problema:
- Las bajas: Pueden borrarse, y volverse a crear con la fecha que el medico desee. Si es erronea, se elimina, y se crea con la fecha correcta.
Una Prescripcion: Se crea y se elimina al antojo del medico, sin importar fechas.
Ejemplo de actividad que NUNCA DEBERIA PODER BORRARSE (y que actualmente no se puede)
(Imaginaos la situacion en una violación, la persona va al medico de urgencias, el cual el medico realiza unos un primer escaner al paciente, realizando anotaciones en el aplicativo, y rellenando unos protocolos de seguimiento para este tipo de casos.) Al cabo de unas semanas, cuando el juzgado requiere los informes medicos para presentarlos como pruebas, aparece que alguien los ha borrado y "uis" de eso no hay registro ni copia...
Por eso hay muchos registros en una app del SALUd que no s epueden eliminar, son ANTIMANAZAS.
En mi opinión puede haber datos que no se deban borrar alegremente, pero debería haber unos pocos responsables que pudieran modificarlos, aunque fuera únicamente bajo petición justificada por escrito. Quizás, incluso, se podría mantener la información borrada en el historial del usuario, al menos durante un tiempo, pero inactiva para que sólo sea accesible en caso de extrema necesidad (por ejemplo si la pide un juez). Vamos, que soluciones puede haber muchas, pero la de no dejar que se modifiquen los datos bajo ninguna circunstancia no me parece la mejor.
#66 En el proceso de especificación y toma de requisitos, por supuesto que hay informáticos del equipo que va a llevar a cabo el proyecto... Pero su labor no es decirle al cliente "Esto que pides no tiene ni pies ni cabeza", sino, simplemente, si es viable técnicamente llevarlo a cabo o no.
#71 Los datos sensibles normalmente se borran de forma lógica, o sea, se habilita un indicador que dice si el registro está vigente o no...
No creo que la solución permanente fuese modificar ese dato, imagino que lo suyo sería modificar el código o la estructura de las tablas implicadas o los triggers que tengan enganchados las mismas. Pero vamos, te puedo garantizar que tiene el aspecto de ser una gilipollez a nivel técnico. Otra cosa es las implicaciones que tenga a nivel de negocio el poder tocar ese registro después de las 24 horas, pero eso lo tenían que haber tenido en cuenta en el diseño funcional.
y lo que tú llamas "roles" que supongo será la gestión de perfiles, no veo que problema pueda haber, por norma general, la mayoría de frameworks con los que se trabaja en la administración tiene librerías estandarizadas para cosas como esa. Cuando se crea una nueva app, lo que se suele hacer es partir de un ejemplo básico que ya lleva todas las librerías necesarias, menús y pantallas estandarizadas e incluso las llamadas a la bd y su estructura a través del gestor que usen, como hibernate. En fin, que supongo que la gestión de perfiles de usuarios la puede hacer un usuario con privilegios de administrador en un par de clicks de alguna pantalla que lleve la app.
En particular en esos de la administracion en los que que el software te obliga a meter el NIF para pasar a la pantalla siguiente aunque estes en fase de borrador o preliminar. Pero seguro que una vez sepamos cual es el cargo encargado de hacer esta tarea, tambien bastantes empresarios privados estaran interesados en incluirlo en su contrato.
#77 Sí, me refiero a los perfiles. Si no recuerdo mal, un rol es un tipo de usuario (usuario, administrador,...), y a cada tipo de usuario (o a cada usuario concreto) supuestamente le corresponde un perfil distinto, así que no son lo mismo pero están relacionados (ahora estoy con Symfony y la gestión de perfiles, permisos o seguridad como quieras llamarlo se realiza definiendo roles de ahí que es lo primero que me ha venido a la cabeza, aunque en Symfony lo llaman "gestión de la seguridad").
El que el framework permita (y facilite) la gestión de roles no quita para que tengas que definir un nuevo rol, configurar sus permisos y crear los formularios necesarios para modificar los datos o modificar los formularios ya existentes. No creo que los usuarios del SAS tengan acceso al código (tampoco al framework), por lo que eso tendrían que hacerlo los responsables de la aplicación (posiblemente Indra y quizás alguna otra más) y dependiendo de la cantidad de datos en los que no hayan tenido en cuenta que debería ser posible su modificación y la cantidad de formularios a crear/modificar, la cosa se puede complicar.
#75 Yo creo que sí es función de los informáticos que tomaron parte en el diseño de las especificaciones del sistema aconsejar al cliente en temas en los que se suponen que son expertos, por ejemplo, dar consejos sobre usabilidad o accesibilidad, recomendar formas de hacer las cosas (que en un sistema informático no tienen por qué hacerse exactamente de la misma forma que se haría en un sistema de archivo tradicional basado en papel) o decirle al cliente que un dato que es introducido por una persona es susceptible de ser erróneo y que, por tanto, debería poder modificarse de alguna forma. Otra cosa es que el cliente, aún sabiéndolo, diga que nada, que eso se hace de tal forma, entonces no hay nada que hacer, el cliente manda.
Si, en otros sitios les llaman gestión de stakeholders. Solo una puntualización, Indra solo hace lo que el responsable informático de la administración le permita a través de la pertinente aplicación de gestión de contratos y cuando devuelve la solución sofware modificada, tiene que actualizar todos los repositorios, modificar y subir la nueva documentación y entregar el código fuente modificado. En na buena gestión administrativa de la informática, las cárnicas implicadas no toan nada que no se les permita u obligue por su responsable laboral público o funcionario y es a el al que rinde cuentas con el respaldo de una jerarquía de penalizaciones económicas.