lunes, 28 de enero de 2019

Liberando a la Sanidad.

Ya comenté cómo podríamos hacer para impulsar el software libre  en las escuelas, y para eso elaboré un escenario que es el que podría darse en caso de comenzar a implantar software libre en las escuelas. Ahora vengo a hacer lo mismo pero con la Sanidad. No es casualidad que haya empezado por la Educación y la Escuela para impulsar el software libre en todas las instituciones de los países . He decidido liberar a la Educación y la Sanidad ya que suelen ser las grandes afectadas por los recortes, violando así el Estado del Bienestar y la población.


Como siempre, voy a explicar en qué entorno estamos y cuales el escenario del que vamos a partir. Lo primero es que todo esto lo voy a hacer desde un Debian 9 para la recepción del Centro Sanitario/Hospital y un Debian 8 para un médico concreto. Ojo, que ninguno de los Debian utilizados tienen interfaz gráfica, es a pelo, todo desde la línea de comandos. Puede parecer que va a ser más complicado, pero ya veréis como al final, va a ser más fácil para todo el mundo independientemente de sus conocimientos en informática. Vamos a hacer el más difícil todavía.


Tendremos, como he mencionado, 2 usuarios; uno el de recepción que estará implantado en el ordenador de la recepción. Otro usuario será el de uno de los médicos y que estará en el ordenador del despacho de ese médico. En la captura anterior están todos en el mismo por no sacar una captura, porque es un ejemplo y por si nos puede servir de backup (tenemos que tener siempre en mente la seguridad). Pero yo he utilizado 2 equipos distintos como he comentado, el que dice SID será el de recepción, y el que pone BACKUP es el del Médico1.



Tenemos una base de datos dentro de la recepción en el que tenemos a todos los que van a pasar consulta. Yo esto lo he hecho pensando en un Centro Sanitario de la Seguridad Social y no en un Hospital; pero igualmente nos sirve para cualquier caso modificando determinados aspectos.



Ahora nos toca ir al software en sí. Ya hemos desarrollado un poco lo que son los sistemas, no tenía mucha complicación, es crear los usuarios con sus grupos correspondientes y poco más, lo más complicado es instalar los sistemas en sí, y eso no es que sea muy difícil, aunque depende de la instalación que se vaya a seguir.



El funcionamiento del software sanITas (salud en latín y con ese IT en mayúsculas a conciencia) es tan simple como que espera recibir como parámetros posicionales las opciones -d y -o, que nos servirán para indicar la base de datos que queremos exportar como backup y el archivo output respectivamente.  Si no introduces nada, entonces se hace una llamada a un programa en C++ que básicamente, contiene la función usage().


La ejecución es tan simple como esto; no tiene más.



Y vemos como nos crea la backup de la base de datos que teníamos. Podríamos dejarlo aquí, pero no, vamos a darle más vueltas, vamos a apretar un poco más las tuercas.


Me encanta programar tareas en el crontab para así quitarme yo trabajo, pues aquí vamos a hacer lo mismo para la gente de recepción, vamos a reducir su trabajo y vamos a pasar la ejecución de este script a un crontab para que lo ejecute todos los días a las 23:45 de la noche y tener así una copia de seguridad de cada día para que en caso de pérdida no se pierdan muchos datos.


Pero aún podemos apretar un poco más las tuercas, aún podemos sacar más zumo. Estaría bastante bien dejar unos logs para que, en caso de fallo, saber el qué ha pasado y cualquier recepcionista pueda acceder y comprobarlo. Sobre si pasar los logs a Apache y verlos así en web, eso ya dependerá, yo soy muy escéptico sobre ese tema, aunque es cierto que así lo podrían ver todos los trabajadores del centro sanitario...y los no trabajadores; hay que tener eso en cuenta.

Lo que sí vamos a mover a nuestro Apache será el dump de la base de datos; ojo, que al igual con los logs, podría acceder cualquiera, por eso, en caso de hacerlo, podríamos hacerlo de forma local sin tirar de DNS, que nos facilitaría la vida a nosotros...pero también a los atacantes. Pero lo que deberíais preguntar es...¿por qué lo pasamos a Apache?


Aquí entra en juego el Médico (con el usuario médico1 porque es el médico de la planta 1). Cada mañana a las 09:00 de la mañana se descargará el archivo de backup de la base de datos que tenemos en el otro servidor (SID que representaba al de recepción). Esto es importante porque cuando empecemos con esta implementación de Sanidad Libre, tendremos que hacerlo después de las 09:00 de la mañana para que se genere el archivo y la mañana siguiente el médico pueda descargar el archivo.

Esto también lo haremos por comandos, y para que el médico no tenga que ejecutar nada ni aprender informática, lo pasaremos al script que podéis ver en la captura anterior que se llama import_sql.sh. Pero como se va a tener que ejecutar a las 09:00 de la mañana (cuando llegue el médico a la oficina por ejemplo), no podemos arriesgarnos a que al médico se le olvide ejecutar el script, por lo que la solución es clara ¡¡DE NUEVO AL CRONTAB PARA PROGRAMAR ESTA TAREA!!


Y las 09:01 el médico, con una sencilla consulta, ya podrá ver las consultas que tiene...pero ¡espera! no queremos que el médico tenga que aprender nada extra, vamos a facilitarle el trabajo aún un poco más y vamos a apretarnos las tuercas...vamos a pasarlo a un script esto.


Creamos el script consulta.sh, por lo que solamente tendría que ejecutarlo con ./consulta.sh. Pero vamos a facilitarle el trabajo aún un poco más, supongamos que no sabe ejecutar scripts (algo que no tiene por qué saber), vamos a ponérselo aún más fácil. La ejecución del script la pasamos,mediante un export, a una variable d el sistema.


La tarea queda en algo tan sencillo como ejecutar $consultas, que es la variable que contiene ya la ejecución del script de las consultas. Como veis salen 2 registros, eso es porque en el script hemos indicado, mendiante un "where clause" que muestre al médico de la planta 1, solamente las consultas de su planta.

Pero ¿qué mejora esto?

En primer lugar, ya sabéis que para mí el poder del scripting es mucho mayor que el poder de realizar tareas a manopla. Si encima lo metemos en un crontab para así realizar tareas periódicas con la seguridad de que no se nos va a pasar, mejor que mejor.

De esta forma, pasamos al siguiente planteamiento. Imaginemos que cada médico, para obtener la información en el ordenador del paciente, se tira 3 minutos porque tiene que dar muchos clicks y esperar a que la aplicación (normalmente en Java) haga todo lo que tiene que hacer. 3 minutos que no parecen nada, pero que sumada al tiempo de la consulta, pongamos 7 minutos, hacen 10 minutos por paciente.

Pongamos que cada día, cada médico tenga 40 pacientes por planta (muchas veces vemos plantas en las que solamente hay una persona atendiendo). Eso hacen 400 minutos que son 6 horas y media o un poco más.

Pues bien, con esto, conforme llegue el médico, solamente tendría que ejecutar las variables que tenga como ejecución de los programas y así reducir 3 minutos, ya que estas ejecuciones en sistemas sin interfaz gráfica es instantáneo, por lo que las consultas pasan de 10, a 7 minutos, lo que haría un total de 280 minutos, un poco más de la mitad de los minutos que antes, pero es que esto son algo más de 4 horas y media, es decir, nos hemos quitado, de golpe, 2 horas de trabajo por médico; lo que haría que los médicos tuviesen menos horas de trabajo y así pudiesen estar más descansados para cada consulta y no tan saturados como están.

Pero ojo, que esto que propongo no es una solución ni mucho menos, esto es una ayuda; solamente mediante el reclamo popular de la gente por una sanidad universal y gratuita y pidiendo que se destinen más recursos para la sanidad, podremos solucionar esta situación. Si en lugar de un médico por planta, hay 2, el trabajo se reduce a la mitas y así sucesivamente, por lo que tendríamos gente que vaya con más frecuencia pero por casos menos graves y no por casos graves (hay gente que, a menos que estén muy graves, no van al médico para no pagar una sanidad privada por un resfriado), lo que hace que, a lo mejor tendríamos menos pacientes, pero con casos más graves y difíciles de diagnosticar. Es por eso que es mejor tener más casos y más sencillos; pero por supuesto, con los fondos y recursos suficientes para la sanidad y no recortando lo que da salud a los habitantes de un país.

Finalmente podréis decir que la base de datos o la backup de la base de datos no están cifradas y que estaríamos incumpliendo la protección de datos; y es cierto, pero para eso ya hay soluciones que yo mismo he dado, la herramienta que desarrollé llamada Bárcenas es un ejemplo de cómo podíamos cifrar, con un script, cualquier archivo.

Esto es una prueba más de cómo apostar por el software libre no es una tarea tan complicada como se pinta y que las instituciones de nuestros países pueden hacerlo de forma muy sencilla,solamente hay que querer.

Por último, decir que todos los scripts sobre este proyecto os los dejaré (posiblemente mañana)para que si los queréis tener o incluso mejorarlos, os sintáis libres de hacerlo para así ayudar a la comunidad y a que nuestros países se democraticen.

¿Hackeamos el Mundo? 

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...