E.2 Instalación Del Sistema De Monitoreo Web De Signos Vitales 168 E.2.1 Instalación De Noisette 168

INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA EN INGENIERÍA Y TECNOLOGÍAS AVANZADAS

UPIITA

Trabajo Terminal

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales

Que para obtener el título de “Ingeniero en Telemática” Presenta

Mario Alberto García Torrea

Asesores

Ing. Francisco Antonio Polanco Montelongo

M. en C. Noé Sierra Romero

Dr. en F. Fernando Martínez Piñón

México D. F. a 29 de mayo del 2008 INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA EN INGENIERÍA Y TECNOLOGÍAS AVANZADAS

UPIITA

Trabajo Terminal

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales

Que para obtener el título de “Ingeniero en Telemática” Presenta

Mario Alberto García Torrea

Asesores

Ing. Francisco Antonio M. en C. Noé Sierra Dr. en F. Fernando Polanco Montelongo Romero Martínez Piñón

Presidente del Jurado Profesor Titular

M. en C. Miguel Félix Mata M. en C. Susana Araceli Sánchez Rivera Nájera Agradecimientos

A mi familia Por enseñarme a creer y ayudarme a crecer; porque siempre han estado ahí cuando los he necesitado; por enseñarme que las mejores cosas de la vida no son más que aquellas que hacemos con el corazón, en las que podemos soñar y alcanzar, y por las que debemos de luchar. Gracias papá por tu sabiduría y por todos los consejos que me has brindado. Gracias mamá por procurarnos sencillez y por enseñarnos a amar. Gracias hermano porque – aunque siempre buscas la forma de molestarme – estás ahí creyendo en mí.

A mis amigos Porque han creido en mí y me han apoyado con su compañía, su alegría y consejos. Gracias por ayudarme a crecer y a creer que todo es posible si realmente queremos que así lo sea; y sobre todo si creemos en nosotros mismos. Gracias por su confianza, honestidad y por depositar también en mí una parte de sus vidas.

A mis profesores Porque siempre procuraron crear personas capaces, por obligarnos a crecer no sólo en lo académico sino como personas. Gracias por sus consejos y experiencias. Gracias por creer en que es posible un mejor futuro y hacernos parte de él.

Al Instituto Politécnico Nacional Porque a pesar de las limitantes, sigue procurando formar jóvenes con nuevas ideas y más sueños. Porque nos ha dado las herramientas técnicas y las experiencias de su gente para formarnos y hacernos crecer.

A México Porque aún creo en su gente y eso genera esperanzas en que se puede lograr un mejor país si su gente, dentro de un marco responsable y honesto, comprende que somos una nación y no un cúmulo de individualidades.

A Dios Por permitirme conocer grandes personas y concederme tiempo para disfrutarlos; por darnos salud, alegría, esperanza y confianza en nosotros mismos para aprender del pasado, crear un nuevo presente y confiar en un mejor futuro. Lista de Contenidos

Capítulo 1 Introducción 1.1 Antecedentes 1 1.2 Planteamiento del problema 1 1.2.1 Solución propuesta 1 1.3 Objetivos 2 1.3.1 Objetivo General 2 1.3.2 Objetivos Específicos 2 1.4 Justificación 3 1.5 Beneficios Esperados 4 1.6 Alcances y Límites 4 1.7 Organización de la Tesis 4

Capítulo 2 Marco Teórico 2.1 Introducción 7 2.2 Estado del arte 9 2.2.1 Antecedentes 9 2.2.2 Monitoreo de signos vitales 11 Variables biológicas consideradas 11 2.2.3 Comunicación entre procesos 12 Interfaces de Programación de Aplicaciones 14 CORBA XML-RPC Sockets DCOP DBUS Daemons: Procesos ejecutándose en segundo plano 16 2.2.4 Sistemas distribuidos y modelo Cliente-Servidor 17 2.2.5 Sistemas de Tiempo Real 18 Tolerancia a Fallos 18 Técnicas de tolerancia a fallos 19 2.2.6 Aplicaciones Web 20 2.2.7 Tecnologías de Internet 21 Javascript 21 XML 21 XSLT 22

I Ajax 23 Nuevas Tendencias 24 2.2.8 Frameworks para el desarrollo de aplicaciones Web 25 Frameworks para desarrollo de aplicaciones Web orientadas al modelo MVC 26 Ruby on Rails Apache Struts Spring Framework Grails Cake PHP Frameworks del lado del cliente 30 Prototype.js MooTools jQuery HL7 30 Conformación del expediente médico 2.3 Resumen 31

Capítulo 3 Análisis y Diseño de la Aplicación 3.1 Introducción 33 3.2 Arquitectura de la Aplicación 36 3.2.1 Escenarios 36 3.2.2 Actores 37 Administrador 37 Staff 37 Cliente Web 37 Sistema de Adquisición 38 3.3 Consideraciones del diseño 38 3.4 Casos de uso Generales 39 3.4.1 Nivel Cero 39 3.4.2 VSM Server 40 Autenticar 40 Administrar personas 41 Ver monitores 43 Ver detalle de monitor 45 Administrar monitores 46 Recibir información 48 3.4.3 Monitor de Signos Vitales 49 Nivel Cero 49 Transmitir 49 3.5 Diagramas de Secuencia 51

II Autenticación de usuarios 51 Visualización de monitores 52 Recepción de información 53 Administración de monitores 53 Secuencia registro Secuencia emparejamiento Secuencia establecer frecuencia Streaming 55 Procesar alerta 55 3.6 Diagrama de Clases 56 Clases persistentes 56 Diagrama General 57 Paquete Communications 58 Paquete WebApp 58 3.7 Diagramas de Actividades 59 Transmisión 59 Recepción de Información 60 Procesamiento de Información 60 Almacenamiento de Información 61 3.8 Diagramas de Paquetes 62 Diagrama general de paquetes 62 3.9 Diagramas de Despliegue 63 3.10 Diseño de la base de datos 64 3.11 Puntos clave del diseño 66 3.11.1 Caracterización de la información a transmitir 66 Formación del mensaje 66 Encabezado del mensaje 66 Mensaje de control 66 Mensaje de información simple 67 Información del sensor 68 Mensaje de alerta 69 3.11.2 Diseño de las interfaces gráficas 71 Inicio de sesión 71 Registro 72 Búsqueda 73 Central de enfermeras 74 Monitor global 75 Monitor extendido 76 Otros elementos de la interfaz 76 Región de alarmas Mapa de navegación 77

III 3.12 Resumen 78

Capítulo 4 Desarrollo 4.1 Introducción 79 4.2 Amande 80 4.2.1 Transmisión de información de los monitores de signos vitales al módulo Amande 80 4.2.2 Châtaigne: API de propósito específico para el Sistema de Monitoreo Web de Signos Vitales 81 Estructura de la información de los sensores 81 Estructura de los módulos del servidor 82 Conversión de estructura binaria a representación en texto 82 Uso del API 83 Procesamiento de los paquetes 84 Libpqxx: Librería de conexión a base de datos PostgreSQL Almacenamiento de alarmas 84 4.2.3 Simulador 85 4.2.4 Consideraciones de desempeño 86 4.2.5 Transmisión de información a clientes Web 87 Streaming 88 Conexión persistente FastCGI 91 Formato 92 JAULA: API para manejo de objetos JSON en C++ Manejo de la información en el cliente 94 4.2.6 Posibles mejoras 96 4.3 Noix: Sistema Web 98 4.3.1 Pistache 98 Aplicaciones en Grails 99 Seguridad: Control de Accesos Internacionalización (i18N) 4.3.2 Noisette 108 Manejo de elementos de la Interfaz Gráfica 108 Estilo Visual Obtención y procesamiento de información del servidor Amande 110 Dibujado en el objeto Canvas 110 4.3.3 Mapa de sitio 112

Capítulo 5 Conclusiones y Trabajos Futuros

Apéndice A Modelos de Caso de uso

IV A.1 Administración de pacientes 117 A.1.1 Secuencias de Administración de Pacientes 123 A.2 Administración de médicos 126 A.3 Administración de enfermeras 132

Apéndice B Diccionario de Datos

Apéndice C Análisis de las alternativas para el desarrollo Web C.1 Streaming de datos y dibujado dinámico de gráficas 143 C.1.1 Streaming: Manejo de flujos de información 143 El objeto XMLHttpRequest 143 C.1.2 Prueba de streaming de datos 144 Límites de Javascript 147 C.1.3 Dibujado dinámico de gráficas en el navegador 148

Apéndice D Protocolos del Sistema D.1 Notas sobre la implementación 153 D.1.1 Sobre el manejo de memoria y cadenas 153 D.1.2 Sobre la compilación en Linux 153 D.1.3 Sobre la compilación en Windows 153 D.2 Protocolo de transmisión de información al Servidor Amande 154 D.2.1 Contenedores 155 D.2.2 Protocolo del Ventilador 156 Paquete de Información 156 Paquete de Alarma del Ventilador 158 Uso de las rutinas para formación de paquetes 158 D.2.3 Notas sobre los demás protocolos 160 D.3 Protocolo de transmisión a clientes Web 160 D.3.1 Formato del paquete JSON 161 Paquete de información 161

Apéndice E Instalación del Sistema E.1 Establecimiento del entorno de producción 163 E.1.1 Instalación de Linux en el servidor 163 E.1.2 Configuración de las aplicaciones necesarias 163 Sistema Gestor de Bases de Datos PostgreSQL 164 Servidor lighttpd 164 Entorno de ejecución de Java 166 Instalación del servidor de aplicaciones Jetty 167 E.2 Instalación del Sistema de Monitoreo Web de Signos Vitales 168 E.2.1 Instalación de Noisette 168

V E.2.2 Instalación de Pistache 168 E.2.3 Instalación de Amande 168

Apéndice F Escenarios y casos de prueba Personajes 171 Marco Domínguez. Médico Elisa López. Enfermera Pedro Gómez. Paciente Pablo Mendoza. Paciente Escenarios 173 Antecedentes Primer escenario: Pablo Mendoza llega al hospital, pues siente una pequeña molestia en el pecho. Segundo escenario: A Pablo Mendoza le es necesario realizar una operación en uno de sus pulmones. Tercer escenario: Llega Pedro Gómez tras sufrir un accidente en automóvil Cuarto escenario: Marco quiere visualizar el monitor de Pedro y Pablo desde su computadora de escritorio. Quinto escenario: Pablo es dado de alta. Sexto escenario: El monitor de Pedro arroja una alarma. Elisa lo atiende y su estado regresa a normal.

VI Índice de Tablas Tabla 2.1: Variables biológicas consideradas 12 Tabla 2.2: Soporte de IPC en distintas implementaciones 13 Tabla 2.3: Lista de Frameworks para desarrollo de Aplicaciones Web 25 Tabla 3.1: Especificación de Requerimientos del Sistema 35 Tabla 3.2: Caso de uso Autenticación 40 Tabla 3.3: Caso de uso Administrar personas 41 Tabla 3.4: Tipos de mensaje 66 Tabla 3.5: Dispositivos de adquisición 67 Tabla 3.6: Caracterización de los dispositivos 68 Tabla 3.7: Tipos de mensajes de datos del ventilador 69 Tabla 3.8: Tipos de alarmas arrojadas por el ventilador 70 Tabla A.1: Caso de uso Administración de pacientes 117 Tabla A.2: Caso de uso Registrar paciente 119 Tabla A.3: Caso de uso Modificar información de paciente 120 Tabla A.4: Caso de uso Eliminar Paciente 121 Tabla A.5: Caso de uso Buscar paciente 122 Tabla A.6: Caso de uso Administración de médicos 126 Tabla A.7: Caso de uso Registrar médico 128 Tabla A.8: Caso de uso Modificar información de médico 129 Tabla A.9: Caso de uso Eliminar médico 130 Tabla A.10: Caso de uso Asignar paciente 131 Tabla A.11: Caso de uso Administración de enfermeras 132 Tabla A.12: Caso de uso Registrar enfermera 133 Tabla A.13: Caso de uso Modificar información de enfermera 134 Tabla A.14: Caso de uso Eliminar enfermera 135 Tabla C.1: Referencia del objeto XMLHttpRequest 144 Tabla C.2: Soporte del objeto Canvas 150 Tabla C.3: Soporte de CanvasRenderingContext2D 152

VII Índice de figuras Figura 1.1: Diagrama esquemático de la solución propuesta 2 Figura 2.1: Consideraciones tecnológicas para el desarrollo del sistema 9 Figura 2.2: Flujo de un programa que utiliza sockets como cliente y servidor 15 Figura 2.3: Modelos de aplicaciones web 24 Figura 3.1: Diagrama del nivel cero de casos de uso del servidor de monitores 39 Figura 3.2: Diagrama de casos de uso de Administrar personas 42 Figura 3.3: Diagrama de casos de uso de Ver monitores 44 Figura 3.4: Diagrama de casos de uso Ver detalle de monitor 45 Figura 3.5: Diagrama de casos de uso de Administración de monitores 47 Figura 3.6: Diagrama del nivel cero de casos de uso del monitor de signos vitales 49 Figura 3.7: Diagrama de casos de uso de Transmisión 50 Figura 3.8: Secuencia Autenticación Administrador 51 Figura 3.9: Secuencia Autenticación Staff 51 Figura 3.10: Secuencia Ver monitor global 52 Figura 3.11: Secuencia Ver detalle de monitor 52 Figura 3.12: Secuencia Recibir información 53 Figura 3.13: Secuencia Registro de monitor 53 Figura 3.14: Secuencia Emparejamiento de monitor 54 Figura 3.15: Secuencia Establecer Frecuencia de Monitor 54 Figura 3.16: Secuencia de Streaming 55 Figura 3.17: Secuencia Procesar Alerta 55 Figura 3.18: Diagrama de Clases Persistentes 56 Figura 3.19: Diagrama general de clases 57 Figura 3.20: Diagrama de clases del paquete Communications 58 Figura 3.21: Diagrama de clases del paquete WebApp 58 Figura 3.22: Actividades de Transmisión de información 59 Figura 3.23: Actividades de Recepción de Información 60 Figura 3.24: Actividades de Procesamiento de Información 60 Figura 3.25: Actividades para Almacenamiento de Información 61 Figura 3.26: Diagrama de paquetes 62 Figura 3.27: Diagramas de despliegue 63 Figura 3.28: Diagrama Entidad-Relación 64 Figura 3.29: Modelo Relacional 65 Figura 3.30: Formación del mensaje 67 Figura 3.31: Formulario de autenticación 71 Figura 3.32: Formulario de registro genérico 72 Figura 3.33: Formulario de búsqueda 73 Figura 3.34: Distribución general de los elementos de la interfaz gráfica de la aplicación 74

VIII Figura 3.35: Monitor global y detalle de monitor reducido 75 Figura 3.36: Distribución de elementos del monitor extendido 76 Figura 3.37: Visualización de alarmas 77 Figura 3.38: Mapa de navegación de la aplicación 77 Figura 4.1: Diagrama General del Sistema de Monitoreo Web de Signos Vitales 79 Figura 4.2: Diagrama de bloques de Amande: Servidor de monitoreo 81 Figura 4.3: Diagrama de bloques del simulador 85 Figura 4.4: Modelo de transmisión en Internet 89 Figura 4.5: Esquemas de manejo del objeto XMLHttpRequest 96 Figura 4.6: Diagrama de bloques de Noix: Sistema Web 98 Figura 4.7: Diagrama de bloques de Noisette 108 Figura 4.8: Mapa de Sitio 113 Figura A.1: Diagrama de casos de uso de Administración de pacientes 118 Figura A.2: Secuencia de Administración de pacientes 123 Figura A.3: Secuencia Agregar paciente 124 Figura A.4: Secuencia Modificar paciente 124 Figura A.5: Secuencia Buscar paciente 124 Figura A.6: Baja de pacientes 125 Figura A.7: Diagrama de casos de uso de Administración de médicos 127 Figura C.1: Captura de pantalla del test de bubblemark.com 149

IX Resumen Abstract: This project aims to develop an Information System which ob tains information from Vital Signs Monitors, stores it in a database and dis plays its graphs and numeric data in Web browsers. This Information System also handles information about physicians, nurses, patients in addition to the relationships among them and the patient's medical record.

En las unidades de cuidados intensivos se da soporte a los sistemas orgánicos de los pacientes que se encuentran críticamente enfermos, requiriendo supervisión y monitoreo intensivo, es aquí donde se encuentra uno de los principales puntos de atención dentro del área telemédica.

En el presente trabajo se desarrolla un sistema que recopila la información obtenida por los monitores de signos vitales correspondientes a los pacientes de terapia intensiva dentro de un hospital; dicha información se visualiza por el staff médico tanto en la central de enfermeras como mediante el acceso al sistema mediante una página web utilizando un navegador, haciendo uso de la red interna del hospital.

Palabras clave: monitoreo web, monitoreo de signos vitales, ajax, programación en red, signos vitales, telemedicina, sistemas de información hospitalarios.

X Capítulo 1 Introducción

“Cualquier tecnología suficientemente avanzada, es indistinguible de la magia”. Arthur Charles Clarke

1.1 Antecedentes La telemedicina puede ser definida como el uso de las tecnologías de telecomunicaciones para proveer información y servicios médicos [PER95]. También busca la convergencia de información médica para propósitos de diagnóstico y tratamiento de pacientes utilizando computadoras, enlaces de telecomunicaciones, audio, video y equipo de imágenes especializado. La telemedicina consiste tanto en consultas interactivas en tiempo real como el procesamiento de información del paciente para su posterior diagnóstico (asíncrono) [HUS00].

1.2 Planteamiento del problema Un paciente en el área de terapia intensiva tiene asignado un monitor de signos vitales el cual es constantemente revisado por una enfermera. Sin embargo, es difícil que el staff médico (médicos y enfermeras) puedan dedicarse todo el tiempo a un sólo paciente, más específicamente a estar vigilando un sólo monitor, por lo cual las enfermeras verifican el estado de varios monitores en la sala o salas de terapia intensiva.

1.2.1 Solución propuesta Mediante un monitor de signos vitales se recopila en tiempo real información de las señales biológicas de un paciente in situ. Actualmente ésta información es almacenada en cada monitor y se pretende transmitirla a un servidor que recopile datos de múltiples monitores y puede ser accedida re- motamente por el staff médico utilizando un navegador Web independientemente de la plataforma con la que cuenten; así pues se busca hacer que la información llegue al staff y no se necesite que ellos se encuentren vigilando cada uno de los monitores de forma presencial. Éste servidor no sólo permiti- rá visualizar los monitores, si no también manejar el almacenamiento de información y mostrar las

1 alarmas generadas en los monitores, al personal indicado. La figura 1.1 muestra un bosquejo del diagrama general del sistema.

Figura 1.1: Diagrama esquemático de la solución propuesta

1.3 Objetivos

1.3.1 Objetivo General Desarrollar un sistema en tiempo real que permita el acceso remoto a la información obtenida por monitores de signos vitales.

1.3.2 Objetivos Específicos ● Obtener información de cada uno de los monitores. ○ Definir el modelo de comunicaciones que asegure el correcto funcionamiento del sistema.

2 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ● Dirigir la información a los módulos correspondientes. ● Almacenar la información recibida en el disco duro. ○ Establecer el modelo de almacenamiento que cause una menor carga al sistema. ● Desplegar la información en un monitor general. ● Manejar las alarmas. ○ Desplegar las alarmas en el monitor general. ○ Almacenar las alarmas. ● Publicar la información en un servidor web para el acceso remoto. ● Generar el expediente médico del paciente.

1.4 Justificación La telemedicina ofrece un área bastante amplia de aplicación de la telemática pues ésta ofrece soluciones que aprovechan la sinergia existente entre las telecomunicaciones y la informática, ya que se necesita no sólo el conocimiento de un área u otra, si no de ambas para poder optimizar el uso de recursos – al ser estos limitados – y emplear y mejorar técnicas que aseguren los requisitos de estabili- dad y seguridad de dichos sistemas. Si bien en un principio los costos de investigación e implementación de sistemas de telemedicina pudieran ser elevados, ofrecer servicios remotos puede presentar una reducción en costos al no tener necesidad de encontrarse directamente el paciente con el médico; reduciendo así la cantidad de consultas físicas. Además una de las principales aplicaciones se presenta al ofrecer servicios en lugares donde tener instalaciones médicas pueda ser costoso y la solución de teleconsultas pueda ser altamen- te conveniente. En México existen pocas empresas que se dedican al desarrollo e implementación de estos sistemas, pues se ha visto que soluciones como la propuesta, ha sido apenas objeto de investigación y pruebas en otras universidades o centros de investigación, pues el reto de realizar un sistema médico, radica no sólo en el uso de las herramientas idóneas para su implementación si no también implica investigación y desarrollo de nuevas tecnologías y responsabilidad al desarrollar aplicaciones del área médica. Éste proyecto está enfocado principalmente al monitoreo en tiempo real de ciertas variables y aunque se busca definirlo para información de cualquier tipo, el trabajo se enfocará a variables médi- cas. El principal reto es ofrecer una baja latencia además de caracterizar el sistema de forma genérica y especializarlo en aplicaciones telemédicas fijas buscando que, a futuro, puedan implementarse aplicaciones telemédicas móviles utilizando el modelo propuesto. Así pues, uno de los alcances de este proyecto es proporcionar técnicas o modelos que permitan la implementación de streaming de datos, ofrecer nuevas perspectivas en cuanto a su uso para monitoreo de cualquier proceso mediante herramientas Web.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3 1.5 Beneficios Esperados ● Desarrollar un sistema que permita un mejor acceso a la información de los monitores de signos vitales por el staff médico. ● Mejorar la administración de expedientes médicos al almacenarlos en formato digital. ● Establecer los criterios necesarios para el desarrollo de aplicaciones de monitoreo remoto, para permitir utilizar esta investigación en desarrollos futuros.

1.6 Alcances y Límites La meta principal de cualquier sistema de monitoreo es clara. El sistema debe ayudar al usuario – un médico, enfermera o técnico – a hacer su trabajo más efectivo, interesante y menos extenuante1. Aunque lo establecido en este proyecto es principalmente una aplicación de distintas tecnologí- as, se busca definir los puntos que son necesarios considerar al implementar este tipo de sistemas y varios similares, pues aunque aquí se consideran señales cuya latencia debe ser baja, pueden usarse los criterios establecidos en éste desarrollo en monitoreo de señales cuyas características no impliquen que deba ser tan rápido su procesamiento. El sistema se desarrollará considerando 20 monitores de signos vitales. El formato del expediente médico se apegará a los requerimientos o definiciones delos estánda- res establecidos por el HL7.

1.7 Organización de la Tesis En el capítulo 1 se han establecido los conceptos, objetivos e ideas que definen el contexto del trabajo desarrollado en esta tesis; es decir, el planteamiento del problema y la solución propuesta. El capítulo 2 busca ampliar algunos conceptos definidos en el capítulo 1 exponiendo el estado del arte de los sistemas de monitoreo médicos, telemedicina y las tecnologías existentes que permiten el desarrollo de aplicaciones web. Ya que cae fuera del alcance de esta tesis el establecer todo el desarrollo teórico, técnicas, procedimientos y tecnologías; el marco teórico solo contiene la información suficiente para introducir al lector a los puntos definidos y determinar la forma en la que buscamos utilizar dichas tecnologías. Así pues, se invita al lector a investigar más sobre las tecnologías existentes y las tendencias tec- nológicas que circundan el desarrollo de sistemas como el propuesto y lo exhortamos a consultar la bibliografía en la cual nos hemos apoyado.

1 Steven R. Deller, et al. Utilization of a Small Computer for Real Time Continuous Patient Monitoring. ACM

4 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales En el capítulo 3 se muestra el análisis y diseño del sistema propuesto. El capítulo 4 presenta el desarrollo del proyecto en base a su implementación y el manejo de las tecnologías definidas en el capítulo 2. El capítulo 5 muestra las pruebas y los resultados obtenidos en éstas. Finalmente, el capítulo 6 contiene las conclusiones obtenidas en base a las pruebas y experiencias en el desarrollo del proyecto.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 5

Capítulo 2 Marco Teórico

“El esfuerzo de utilizar las máquinas para emular el pensamiento humano siempre me ha parecido bastante estúpido. Preferiría usarlas para emular algo mejor” Edsger Dijkstra

2.1 Introducción Debido a la arquitectura del sistema y su interacción con dos tipos de clientes – uno encargado de proveer la información correspondiente y los otros capaces de visualizar la información obtenida de los primeros – se propone dividir el sistema en dos subsistemas: Administrativo y de Monitoreo. El subsistema administrativo será el encargado de permitir al usuario el registro de nuevos elementos en el sistema, es decir registrar médicos, pacientes y enfermeras, y permitir las operaciones de actualización de información, eliminación y consulta. El subsistema de monitoreo consistirá de las aplicaciones necesarias para la transmisión de información desde los monitores de signos vitales a un servidor central, al procesamiento de la información recibida y su almacenamiento y distribución a los clientes Web.

En base a lo establecido anteriormente, se logran identificar en el sistema ciertas problemáticas en las que debemos de interesarnos y que establecen la base de la investigación necesaria para el desarrollo del sistema: Transmisión Tanto los monitores como el servidor de monitores e incluso los clientes Web, conllevan distintos enfoques de transmisión de información además, se ha establecido que dicha transmisión se establecerá de forma inalámbrica; por lo tanto, habiendo establecido que la tecnología de transmisión será utilizando IEEE 802.11, los puntos de interés se centran en la interconexión de procesos o aplicaciones. Así pues nos enfocaremos en la comunicación entre procesos, Inter-Process Communications (IPC) y el mantenimiento de procesos ejecutándose como servicios (daemons).

7 Acceso y mantenimiento de la información El servidor de monitoreo además de recopilar información de los monitores de signos vitales, debe de permitir almacenar y visualizar dicha información y relacionarla a los pacientes correspondientes. Además, al llevarse también un determinado control sobre los médicos y enfermeras, sus pacientes asignados y el acceso a la información de los pacientes que les correspondan (control de accesos), es necesario hacer uso de herramientas que nos permitan manejar esa información, mantener los registros y modificar y visualizar la información. Al ser sistemas que permiten el acceso desde la red o en una determinada posibilidad desde Internet, así mismo se considera de gran importancia el uso de herramientas que nos brinden esas capacidades por lo tanto, se necesita realizar una investiga- ción sobre los frameworks para el desarrollo de aplicaciones Web.

Acceso Web Además de ofrecer las características de recopilación y administración de la in- formación, la visualización de la misma es también importante. La visualización de la información necesita presentar un entorno sencillo y familiar al usuario; así pues, para poder presentar la información lo más similar posible a su visualización en un monitor in situ, es necesario considerar las técnicas que nos permitan obtener y procesar flujos de datos (streaming) y visualizarlos. Es por ello que se establece la necesidad de investigar sobre los objetos o herramientas que nos permitan realizar dichas actividades en entornos Web es decir, crear Aplicaciones Ricas de Internet.

Es debido a lo anterior que en este capítulo se establecerán los conceptos necesarios para el se- guimiento de esta tesis. Los primeros puntos se enfocarán al monitoreo de signos vitales, se definirán los puntos que se deben de considerar en este tipo de monitoreo y se listarán y definirán los tipos de señales biológicas a las que haremos referencia en el trabajo; posteriormente, se mostrará una perspec- tiva general de los modelos, técnicas y tecnologías existentes para el desarrollo del sistema. En la figura 2.1 se muestran las consideraciones de tecnologías necesarias para llevar a cabo el proyecto.

8 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Figura 2.1: Consideraciones tecnológicas para el desarrollo del sistema

En los capítulos siguientes se desarrollará el análisis y diseño del sistema, posteriormente se des- cribirá la implementación y se listarán las pruebas del sistema y los resultados obtenidos. Si bien el orden lógico del proyecto de investigación – a mi parecer – debe contemplar primero el análisis y el di- seño del sistema y posteriormente establecer las tecnologías necesarias para su desarrollo, aquí supone- mos que es necesario antes establecer las tecnologías y hacer uso de éstas para definir el diseño.

2.2 Estado del arte

2.2.1 Antecedentes La telemedicina puede ser definida como el uso de las tecnologías de telecomunicaciones para proveer información y servicios médicos [PER95]. También busca la convergencia de información médica para propósitos de diagnóstico y tratamiento de pacientes utilizando computadoras, enlaces de telecomunicaciones, audio, video y equipo de imágenes especializado. La telemedicina consiste tanto en consultas interactivas en tiempo real como el procesamiento de información del paciente para su posterior diagnóstico (asíncrono) [HUS00]; también se utiliza para educación médica conti-

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 9 nua. Se considera que la telemedicina es una aplicación importante de las Tecnologías de Informa- ción y Comunicaciones (TIC's) y forma parte también del concepto e-salud [wEME07]. Si bien la telemedicina no debe ser considerada como un nuevo campo, está demostrando un gran potencial con el surgimiento de nuevas tecnologías de la información. Una de las primeras implementaciones de televisión interactiva para consultas médicas fue en Nebraska a finales de los 50, utilizando enlaces de microondas para consultas de telepsiquiatría entre hospitales mentales estatales y el Instituto de Psiquiatría de Nebraska [PER95]. La Universidad de Kon Kuk en Corea del Sur, desarrolló en 1997 un sistema de monitoreo remoto de pacientes por Internet, considerando tanto el servicio de localización de pacientes como el servicio de monitor de signos vitales para un conjunto de 8 monitores médicos utilizando la red de área local [LEE97]. En el 2001, la Universidad de Londres desarrolló un sistema de monitoreo médi- co móvil basado en web, el cual busca ofrecer servicios de almacenamiento y acceso remoto a la infor- mación obtenida por diversos dispositivos asignados a pacientes dentro de un hospital, además de que al mantener la información histórica del paciente de forma anónima, ésta pueda utilizarse en educa- ción remota para estudiantes de medicina [POL01]. Se ha propuesto también un modelo de referencia en telemedicina para una futura normaliza- ción, ésto debido a que al presentarse los desastres del Tsunami en el 2004, la portabilidad de los equipos de telemedicina provistos por distintos países presentó varios problemas debido a sus distintas interfaces. Así pues es necesario tener estandarizadas las interfaces entre los equipos de telemedicina y los sistemas de telecomunicaciones [KOM05]. El avance de las tecnologías de telecomunicaciones móviles presenta continuamente incremen- tos en las tasas de transferencia de datos con la implementación de nuevas generaciones de telefonía móvil. Al ofrecerse dichas tasas de datos, el desarrollo de sistemas de monitoreo de señales biológicas supondrá otros esquemas en su diseño. Permitiendo sistemas más flexibles y que hospitales y centros de salud puedan ofrecer servicios de telemedicina. La implementación de dichos sistemas se ha llevado a cabo por el Colegio de Medicina en la Universidad Dong-A en Busan,Corea del Sur [JUN05]. Se ha desarrollado anteriormente un Trabajo Terminal en la unidad denominado “Sistema Ac- tivo y monitoreo del censado de signos vitales” [JES04] que también implementa un sistema de monitoreo de signos vitales, sin embargo ellos han construido su sistema de adquisición y transmisión utilizando el microcontrolador MC68HC912B32 y un módulo transceptor TR916SCP. Mientras que su sistema es una aplicación que recopila información y la muestra en una misma máquina, la aplicación propuesta en este trabajo es una aplicación servidor que recopilará la información proveniente de los monitores médicos y proveerá de medios para acceder a ella mediante una página web en “tiempo real blando” (soft real-time). También se han desarrollado varios trabajos en el área de telemedicina como trabajos o proyectos de tesis de maestría en el Centro de Investigación en Computación del Instituto Politécnico Na- cional (CIC – IPN). En uno se considera el manejo y acceso a los expedientes clínicos dentro de un Sistema de Información Hospitalario, Hospital Information System, (HIS) utilizando un asistente personal digital, Personal Digital Assistant (PDA) [ROD05]. En otro proyecto, se diseña el sistema de comunicaciones y manejo de datos para una unidad de cuidados coronarios [GAL04]. Aunque el pro-

10 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales yecto que se propone en esta tesis tiene una extensión mayor, ambos trabajos pueden ser de gran ayuda durante el desarrollo de este proyecto. En el mercado existen dispositivos que permiten la visualización – en una central de enfermeras – de los monitores de signos vitales que se encuentren conectados a él, principalmente desarrollados por la empresa Mennen Medical correspondiendo al modelo Enguard View.

2.2.2 Monitoreo de signos vitales Históricamente, las tasas de respiración y pulso han sido los primeros signos vitales debido a que su determinación no recae en cualquier instrumento que un reloj. La temperatura corporal, presión sanguínea y saturación de oxígeno requieren instrumentos que, estrictamente hablando, deben ser considerados pruebas de diagnóstico más que signos vitales. La adición de los tres anteriores a las tasas de pulso y respiratorias se ha debido a que los instrumentos utilizados – termómetro, esfigmomanómetro y monitor de oxígeno dactilar – son poco costosos, reutilizables y no invasivos. Es más, la información derivada de los cinco refleja el funcionamiento fisiológico crucial [TIE97]. El monitoreo de signos vitales se realiza in situ por un dispositivo denominado monitor médico o monitor de signos vitales el cual adquiere las señales necesarias y realiza el procesamiento apropiado para determinar los signos vitales del paciente.

Variables biológicas consideradas Los signos vitales considerados en el desarrollo del proyecto se definen en la tabla a continuación [wDIS07].

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 11 Variable Descripción Electrocardiograma Es el registro de la actividad eléctrica producida por el corazón, mediante la medición y amplificación de los pequeños potenciales generados por este durante el ciclo cardíaco. Oximetría de pulso Término relativo al método utilizado para medir la saturación de la hemoglobina por el oxigeno. Las técnicas oximétricas pueden dividirse en: 1) Espectrofotometría para el análisis de la Hb in vitro; 2) Oximetría de pulso (SpO2) para medición no invasiva de la saturación de la Hb y 3) Oximetría fibroptica para la medición invasiva de la saturación de la oxihemoglobina en vivo. Todas ellas se basan en principios espectrofotométricos que miden las porciones de luz transmitida y/o absorbida por parte de la Hb. Capnografía Concentración de dióxido de carbono en el medio ambiente. Utilizando una sonda, permite conocer la concentración de CO2 en la mezcla gaseosa administrada a los pacientes durante la anestesia general, lo que resulta muy útil en ciertas situaciones clínicas (dificultad de intubación, estados de hipercarpnia, embolia pulmonar, hipertermia maligna, etc.). Presión Sanguínea La existente en el interior de los vasos de la circulación corporal (intravascular); en sentido estricto es la presión arterial la que se mide en el sistema arterial a la altura del corazón y frente a la presión atmosférica y que depende, por un lado, del rendimiento cardiaco y de la resistencia de los vasos (tono y elasticidad), y por el otro, de la viscosidad de la sangre; constituye la fuerza impulsora o hemodinámica para la circulación de la sangre. Su regulación se efectúa mediante barorreceptores y quimiorreceptores que envían señales a los centros circulatorios, y los efectores son el sistema nervioso simpático y parasimpático, hormonas suprarrenales, etc. Gasto cardiaco Volumen de sangre bombeado por el corazón en la unidad de tiempo. Si se toma el minuto por unidad, el gasto cardiaco es igual al volumen de sangre expulsado por el corazón en cada sístole, multiplicado por el número de contracciones por minuto.

Tabla 2.1: Variables biológicas consideradas

2.2.3 Comunicación entre procesos La comunicación entre procesos se refiere al intercambio de información entre dos o más hilos o procesos. Dichos procesos pueden estar en la misma máquina o distribuidas en una red. El tema de las técnicas de comunicación entre procesos, Inter-Process Communications (IPC) es amplia, desafiante y dinámica. Todos los sistemas operativos proveen métodos para comunicación entre procesos. Tiempo atrás, UNIX soportaba unas cuántas construcciones rudimentarias para comu-

12 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales nicaciones entre procesos – como archivos protegidos, señales y tuberías, pipes –. A principios de los 80s se integraron otras facilidades como pilas de mensajes, semáforos y memoria compartida en la li- beración del sistema UNIX V de AT&T. Al mismo tiempo, la Distribución de Software de Berkeley, Berkeley Software Distribution agregó soporte para los protocolos de Internet y la interfaz socket como construcción de comunicaciones. A mediados de los 90s, los hilos y programación multihilos fueron incorporaciones significativas y permanentes a UNIX.[SHA] En el pasado, la IPC fue un conjunto de distintos acercamientos, pocos de los cuales eran portables entre distintas implementaciones de sistemas UNIX. [...] tras los esfuerzos de estandarización la situación mejoró, sin embargo las diferencias aún existen. La tabla 2.2 resume los distintos tipos de IPC que son soportados por distintas implementaciones. [STE05]

Single Unix FreeBSD Mac OS X Tipo de IPC Linux 2.4.22 Solaris 9 Specification 5.2.1 10.3 Half-duplex Si completa Si Si completa pipes FIFOS Si Si Si Si Si Si, Unix opcional, Unix Si, Unix Full-duplex Unix Domain permitidas Domain Domain Domain pipes Sockets Sockets Sockets Sockets opcional, Unix Si, Unix Named full- Unix Domain Unix Domain opción XSI Domain Domain duplex pipes Sockets Sockets Sockets Sockets Message XSI Si Si Si Queues Semaphores XSI Si Si Si Si Shared XSI Si Si Si Si Memory Sockets Si Si Si Si Si STREAMS opción XSI opcional Si *XSI – X/Open System Interfaces, XSI; es una especifcación suplementaria a la Single Unix Specification

Tabla 2.2: Soporte de IPC en distintas implementaciones

Sin embargo se han desarrollado otras implementaciones de IPC que establecen una capa sobre el sistema operativo, permitiendo así que se puedan implementar programas que ocupen interfaces o mensajes únicos que sean manejados por esas capas de forma transparente a las aplicaciones. Dichas interfaces de programación de aplicaciones, Application Programming Interfaces (API), pueden tener implementaciones o especificaciones para distintos sistemas operativos o distintos lenguajes de pro- gramación. Existen diversas tecnologías de IPC enfocadas a la solución de distintos tipos de proble-

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 13 mas o aplicaciones: DCOP, XML-RPC, SOAP, CORBA, ICE entre otras. En la siguiente sección se describirán algunas de ellas resaltando sus características y enfoques.

Interfaces de Programación de Aplicaciones Entre las APIs independientes de plataforma en las que nos enfocaremos, encontramos COR- BA, XML-RPC y sockets.

CORBA Common Object Request Broker Architecture, es un estándar diseñado para el soporte de IPC orientados a objetos. Existen distintas implementaciones o motores ORB , que definen una capa de software (middleware) que permite que los objetos puedan realizar llamadas a métodos de otros situa- dos en máquinas remotas, Remote Procedure Calls (RPC). Ésto es llevado a cabo mediante serializa- ción, marshalling, en la cual se trasforma la representación de los objetos en memoria a un formato apropiado para poder transmitirlo o almacenarlo. De las diversas implementaciones existentes de ORB, se incluyen ORBit, MICO CORBA y ACE ORB. En [PUD04] se muestra una tabla comparativa de distintas implementaciones de COR- BA con los lenguajes y características soportadas. CORBA posee varias características de interés empresarial y de desarrollo de aplicaciones web pues debido a su especificación y estandarización, la interoperatibilidad de sistemas, independencia de las tecnologías y lenguajes fortalecen sus beneficios en el desarrollo de dichos sistemas. En [MCH07] se pueden encontrar varios ejemplos del uso de CORBA en C.

XML-RPC Es un sistema de intercambio de mensajes para la llamada de procedimientos remotos basado en XML. Por tanto, es evidente que la sobrecarga de información – debido al uso de etiquetas XML para definir el contenido – puede no ser la mejor opción en entornos donde la velocidad de transferencia de información o cuotas de acceso estén limitadas.

Sockets Socket, es un concepto de la Universidad de Berkley incorporado en las implementaciones de Unix BSD 4.1 y 4.2 alrededor de 1982 [APL05]. Los sockets permiten que procesos en un anfitrión UNIX se comuniquen con otros procesos en una máquina remota dentro de una red. Los sockets compatibles BSD es la interfaz uniforme entre los procesos de usuario y las capas del protocolo de red en el núcleo del sistema. Los sockets pueden también ser utilizados para comunicarse con otros procesos dentro del mismo servidor, a lo que se le conoce como Inter-Process Communications (IPC). Posteriormente se desarrolló una variante especificada en el estándar de Interfaces para Sistemas Operativos Portables, Portable Operating System Interfaces (POSIX); este estándar definido por el Ins- tituto de Ingenieros Eléctricos y Electrónicos, Institute of Electrical and Electronics Engineers (IEEE)

14 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales define las llamadas al sistema necesarias para permitir que una misma aplicación pueda ejecutarse en distintas plataformas. Actualmente los sistemas Linux se apegan parcialmente al estándar POSIX, pues al comenzar a cobrar la IEEE por el estándar y no permitir su publicación en Internet, se creó otra especificación libre llamada Single UNIX Specification cubriendo puntos similares a la POSIX. Aunque se ha definido un subsistema UNIX sobre el núcleo de Windows NT que se apega al estándar POSIX [MS07] – ofreciendo ciertas características del susbsistema de modo de usuario UNIX –, en Windows los sockets fueron implementados bajo el nombre de winsocks – acrónimo de Windows sockets –. Si bien, muchas de las características de los sockets utilizados en Linux son similares a las implementadas en Windows, existen sutiles diferencias entre su implementación, más no en el sentido de uso. El flujo básico de un programa que haga uso de sockets, se muestra en la figura 2.2.

Figura 2.2: Flujo de un programa que utiliza sockets como cliente y servidor

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 15 Entre las APIs dependientes de la plataforma – en este caso UNIX – están: DCOP y DBUS.

DCOP El protocolo de comunicación de escritorio, Desktop Communication Protocol (DCOP), es un sistema de comunicación entre procesos IPC utilizado en sistemas KDE [BRO03]. DCOP es un mecanismo simple de IPC/RPC construido para operar sobre sockets – ya sea sockets de dominio Unix o Sockets TCP/IP –. DCOP se constituye sobre el protocolo de Intercambio entre Clientes, Inter Client Exchange (ICE), además presenta dependencias de Qt y ningún otra. De- bido a esto es extremadamente ligero, permitiendo que pueda ser enlazado a aplicaciones KDE de baja carga. La arquitectura cliente servidor de DCOP es simple. Cada aplicación que utiliza DCOP es un cliente que se conecta a un servidor DCOP el cual actúa como un director de tráfico, despachando mensajes o llamadas a su destino. Existen dos tipos de acciones que pueden realizarse con DCOP: mensajes “envía y olvida” y “llamadas”, las cuales bloquean la ejecución del programa hasta que una respuesta es devuelta.

DBUS DBUS, como DCOP se enfoca a la comunicación entre aplicaciones de escritorio en el mismo entorno de escritorio – bajo sistemas GNOME –. Sin embargo DBUS se construye en base a las experiencias y necesidades identificadas tras el uso de CORBA y DCOP enfocándose a las necesidades de proyectos de escritorio en particular [PEN]. DBUS no es la mejor opción para utilizarse en todas las aplicaciones - ya que no es un sistema IPC optimizado o dirigido a su uso en aplicaciones de propósito general, si no de escritorio -, aunque puede ser utilizado en otras aplicaciones distintas a las que fue diseñado.

Daemons: Procesos ejecutándose en segundo plano Los demonios, daemons, en Linux, son procesos en segundo plano que proveen de ciertos servicios. Es decir son programas servidores, que se ejecutan todo el tiempo, nunca o rara vez se apagan o son reinicializados, operan en segundo plano y responden a peticiones de otros procesos [END01]. Los pasos necesarios para convertir un proceso en un daemon y las consideraciones en el desarrollo de daemons, se enlistan a continuación: 1. Dameonize , convertirlo en un proceso que opere en segundo plano. Para llevar a cabo esto, primero debemos de crear un proceso utilizando la llamada fork(). Posteriormente debe de finalizar el padre dejando al proceso hijo como huérfano, así éste pasará a ser hijo del proceso init. 2. Independizar el proceso Es necesario eliminar la dependencia que tiene respecto a la terminal que lo inició. Esto es,

16 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales que el control está ligado a la terminal en la que se inició el proceso y es necesario independizar el proceso de dicha terminal asignándole un nuevo grupo de procesos utilizando la llamada setsid(). 3. Eliminar los descriptores de Entrada/Salida innecesarios 4. Establecer máscaras de creación de archivos 5. Establecer el directorio de ejecución. Esto es necesario para tener una dirección conocida del cual el servidor pueda acceder a archivos. 6. Exclusión mutua y ejecución de una sola copia. Permitiendo que una sola instancia del servidor acceda a la región crítica e información y al finalizar permita a otros servicios acceder a ésta. 7. Captura de señales Es necesario capturar las señales y actuar correctamente respecto a dichos eventos. 8. Registro de bitácoras. Es conveniente mantener registros sobre el funcionamiento o eventos que permitan almacenar mensajes sobre el comportamiento del servidor, y así poder detectar errores.

2.2.4 Sistemas distribuidos y modelo Cliente-Servidor Un sistema distribuido consiste de una colección de computadoras autónomas enlazadas por una red de computadoras y equipadas con software de sistemas distribuidos, éste les permite coordi- nar sus actividades y compartir recursos del sistema – hardware, software e información. Los modelos más conocidos de sistemas distribuidos son el modelo cliente-servidor y el modelo basado en objetos. El modelo cliente servidor, es el modelo más conocido y ampliamente adoptado para sistemas distribuidos; éste modelo consiste en un conjunto de procesos servidor, cada uno actuando como un administrador de recursos para una colección de recursos de un determinado tipo, y un conjunto de procesos cliente cada uno desempeñado una tarea que requiere acceso a ciertos recursos de hardware y software compartido [COU95]. Es así como una aplicación servidor provee acceso a una variedad de facilidades y recursos com- partidos del sistema; las aplicaciones que ejecutan los usuarios para acceder a dichos recursos compar- tidos en la red, se denominan clientes. El modelo cliente servidor provee un acercamiento efectivo de propósito general para compartir información y recursos en sistemas distribuidos. El modelo puede ser implementado en una variedad amplia de entornos de hardware y software. Las computadores utilizadas para ejecutar los procesos clientes y servidor pueden ser de distintos tipos y no hay necesidad de distinguirlas entre ellas; ambos procesos pueden ser ejecutados en la misma computadora – así como también un proceso servidor puede utilizar los servicios de otro servidor, pareciendo un cliente al último.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 17 2.2.5 Sistemas de Tiempo Real Un Sistema en Tiempo Real, Real Time System (RTS) es aquel sistema que responde a estímu- los externos y el tiempo en el que debe producir resultados correctos, se encuentra especificado. Un RTS cumple tres condiciones primordiales [GUE03]: ● Contacto con el mundo físico ● Emisión de respuestas correctas ● Obtención de respuestas dentro de intervalos de tiempo establecidos. Generalmente se confunde esta noción de tiempo real con la rapidez de respuesta del sistema. Un RTS no necesariamente es rápido, lento o instantáneo; un RTS toma en cuenta las restricciones de tiempo impuestas por el mundo físico, clasificándolos así en: críticos, no críticos e inflexibles. En los sistemas críticos (hard), es imperativo que las respuestas ocurran estrictamente dentro de los periodos de tiempo especificados. Los requerimientos temporales de los sistemas no críticos (soft) son importantes, pero funcionan correctamente si de manera ocasional alguna restricción se pierde, aunque su desempeño es de- gradado pero no se destruye el sistema por el hecho de fracasar en el tiempo de entrega de la informa- ción. Los sistemas inflexibles (firm) son no críticos, sin embargo el sistema no sirve cuando no se respetan las restricciones de tiempo. En este trabajo se considerará un sistema de tiempo real no crítico, ya que no existen elementos que actúen directamente con el paciente respecto a las respuestas del sistema.

Tolerancia a Fallos Todos los sistemas informáticos tienen distintos niveles de tolerancia a fallos. En algunos sistemas la existencia de fallas, puede no representar un gran compromiso al funcionamiento del sistema o a los resultados sin embargo, en otros sistemas en los que se necesite controlar algún proceso costoso o vidas humanas, el riesgo de que el sistema presente fallas que inhabiliten su funcionamiento o en- tregue resultados erróneos nos obliga a establecer técnicas que permitan el tratamiento de estas fallas. “Una falla en un Sistema de Tiempo Real (STR) es el incumplimiento de una o de varias de las especificaciones requeridas por el mundo físico con el cual interactúa” [BUR03]. En general existen cuatro causas de defectos que pueden propiciar el fallo de un sistema embe- bido [BUR03]. ● Especificación inadecuada. ● Defectos provocados por errores de diseño en los componentes de software ● Defectos provocados por fallos en uno o más componentes del procesador de los sistemas embebidos.

18 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ● Defectos provocados por una interferencia transitoria o permanente en el subsistema de comunicaciones adyacente. Así como también se definen tres tipos de fallos: ● Fallos transitorios. Aquellos que comienzan en un instante de tiempo, se mantiene en el sistema un cierto periodo y desaparece. ● Fallos permanentes. Comienzan en un instante determinado y permanecen en el sistema hasta que son reparados. ● Fallos intermitentes. Fallos transitorios que ocurren ocasionalmente. La creación de sistemas fiables, debe considerar todos los puntos anteriores, para así evitar que éstos ocasionen un comportamiento erróneo en el sistema. En [BUR03] se muestran los modos de fallo existentes, que corresponden a salidas con valores erróneos, retrasos en las salidas y no controlados. Dichos modos de fallo son atacadas por dos herramientas: La prevención de fallos y la tolerancia a fallos.

Técnicas de tolerancia a fallos Las técnicas de tolerancia a fallas pueden conformarse por software, hardware o ambas [BUR03]. Las técnicas por hardware se obtienen utilizando redundancia modular y módulos de respaldo. Las técnicas de redundancia modular, se basan en el método de Montecarlo en el que que una misma entrada se reparte entre módulos de distinto hardware que realizan la misma operación y obtienen ciertas salidas, de las cuales se determina cuál es la mejor salida. Las técnicas que utilizan módulos de respaldo son aquellas en las que cuando al- gún módulo falla, entra otro módulo idéntico en operación. Las técnicas por software más utilizadas son los bloques de recuperación, n-versiones de programas, el cómputo impreciso y las técnicas de recuperación hacia atrás o hacia adelante (manejo de excepciones)[BUR03]. Los bloques de recuperación se componen de un conjunto de módulos de software alternativos. Éstos se diseñan para producir resultados similares con posibles varia- ciones en la calidad de resultados o en los tiempos de ejecución. El resultado más deseable se produce por un bloque primario, y los demás bloques proporcionan informa- ción adicional. Las nversiones de programas están formadas de distintas versiones de los módulos que se ejecutan de forma paralela. Cada una realiza la misma función sin embargo es desarrollada por distintos equipos de desarrolladores. Así pues, se pretende que no se presenten las mismas fallas en los distintos bloques realizados.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 19 El cómputo impreciso propone evitar las fallas de tiempos, reduciendo la precisión de los resultados en forma controlada, considerando así que el resultado de la tarea es impreciso más sin embargo el sistema sigue funcionando y entregando respuestas dentro de los márgenes definidos. Las técnicas de recuperación hacia atrás utilizan puntos de verificación (check- points), los cuales se utilizan para minimizar la pérdida de procesamiento en un ambiente sujeto a fallos. Un checkpoint almacena el estado de una tarea de la aplicación en un punto estable. La aplicación así almacena varios puntos y en el caso de presentarse un fallo, se recupera el checkpoint más reciente. La técnica de recuperación hacia adelante se refiere al manejo de excepciones, en las cuales tras determinarse un estado de error, la aplicación realiza un procedimiento de recuperación, en el cual se supone se han considerado los posibles eventos que pudieran arrojar dichas excepciones y se determinan las acciones a realizar.

2.2.6 Aplicaciones Web El desarrollo de Internet se basa principalmente en el protocolo HTTP, el cual permite la transferencia de hipertexto – texto que contiene elementos a partir de los cuales se puede acceder a otra información, según la RAE – utilizando una red de computadoras. El primer estándar desarrollado por el Consorcio de Internet, World Wide Web Consortium (W3C), fue el lenguaje de marcado de hipertexto (HTML); utilizando HTML se pueden presentar a los usuarios contenidos con informa- ción de su interés, la interactividad en este modelo se limitaba a formularios que permiten a los usuarios introducir información y transmitirla a un servidor el cual se encargará de procesar dicha infor- mación y emitir una respuesta, que nuevamente se mostrará al usuario. En éste primer acercamiento a las aplicaciones basadas en Internet o aplicaciones Web, las tecnologías de procesamiento se centra- ban en el desarrollo de aplicaciones en el lado del servidor (Server-Side Applications). En la actualidad no es posible pensar en Internet sin pensar en las aplicaciones basadas en web, así como tampoco es posible que los desarrolladores no consideren tecnologías o herramientas web que han ganado su lugar gracias a las características que ofrecen y a la aceptación por parte de las empresas y la comunidad. Las tecnologías de Internet – mas específicamente aquellas relacionadas con interfaces gráficas interactivas – han permitido el surgimiento de nuevos paradigmas en el desarrollo web, tal es el caso de las aplicaciones web que ya constituyen un reemplazo potencial a las aplicaciones de escritorio; por citar un ejemplo, las aplicaciones de Google docs & spreadsheets representan una alternativa de procesador de textos y hojas de cálculo en línea, a los más utilizados Microsoft Word y Excel; así pues es posible acceder a dichas aplicaciones con dispositivos de características más limitadas que un equipo de escritorio contando solo con un navegador– generalmente denominados clientes ligeros (thin- clients) – y acceso a Internet. Gracias a la incorporación y la disponibilidad de servicios de acceso a internet a múltiples dispositivos móviles, el uso de aplicaciones web será cada vez más común. Esto implica que – durante la implementación de dichas aplicaciones – es importante considerar las capacidades de los dispositivos,

20 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales sin embargo las tendencias en su desarrollo indican que se incorporarán distintas tecnologías que ha- rán indiferente el uso de un dispositivo u otro con mayores capacidades. Entre dichas tecnologías de las que seguramente se seguirán considerando durante algún tiempo más se encuentran: Javascript, XML, XSLT y AJAX.

2.2.7 Tecnologías de Internet

Javascript Es un lenguaje interpretado que permite que los desarrolladores puedan determinar cómo puede interactuar el usuario con una página web – permitiendo el procesamiento de información en el lado del cliente. Inicialmente fue incorporado en la versión 2.0 del navegador Netscape; desde entonces Javascript ha sido una de las tecnologías principalmente utilizadas en el desarrollo de aplicaciones web. En 1997 fue adoptado como un estándar ECMA, denominándolo ECMAScript. Javascript ofrece una sintaxis bastante similar a la de Java y C sin embargo no es un lenguaje orientado a objetos, aunque se han creado ciertas técnicas para dotar de algunas de esas características al lenguaje. Javascript no se compone únicamente de ECMAScript, si no también del modelo de objeto del documento, Document Object Model (DOM) y del Modelo objeto del navegador, Browser Object Mo- del (BOM), con los cuales se puede manejar información del navegador y del documento, además de las características de procesamiento provistas por ECMAScript. El libro [ZAK05] puede considerarse como una referencia bastante recomendable para el desarrollo de páginas web con JavaScript, uso de técnicas avanzadas, AJAX, consumo de Web services, entre otros temas.

XML Lenguaje de marcado extensible(eXtensible Markup Language) XML es un lenguaje que es utilizado para definir de forma estandarizada documentos e infor- mación basado en un formato de texto, que pueden ser fácilmente transportados utilizando los protocolos de Internet [BEN03]. XML se deriva de un lenguaje llamado Lenguaje de Marcado Generalizado Estándar, Standard Generalized Markup Language (SGML). El propósito del SGML era definir la sintaxis de los lenguajes de marcado para representar información utilizando etiquetas. Las etiquetas consisten en elementos de texto delimitados por los símbolos menor que (<) y mayor que (>). Las etiquetas de inicio, inician un área en particular y se definen en el formato ; las etiquetas finales, indican el fin del área, y se representan en el formato . SGML también define atributos para las etiquetas, los cuales son valores definidos dentro de ellas, como por ejemplo: , en el cual el atributo src tiene el valor imagen.src. Las reglas para formar documentos XML – en su versión 1.0 – están especificadas en el docu-

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 21 mento [wW306]. XML ha gozado de un gran apoyo por parte de los desarrolladores de software, pues éste ha sido base para diversas aplicaciones de intercambio de información y almacenamiento al ofrecer infor- mación estructurada y formatos simples que pueden ser entendidos por una gran cantidad de lenguajes de programación; ésto se ve reflejado al observar las aplicaciones que se han desarrollado a su alrededor:

XML-RPC, Llamadas a Procedimientos Remotos por Comunicación entre procesos, XML, XML Remote Procedure Calls InterProcess Communications (IPC) SOAP Protocolo de Acceso Simple a Objetos, Simple Object Access Protocol

OpenDocument – utilizado en OpenOffice Almacenamiento de documentos ofimáticos OOXML – utilizado en Microsoft Office 2007

Almacenamiento e intercambio de documentos médicos (definidos en los estándares del HL7)

XAML Definición de interfaces gráficas XUL – utilizado en Mozilla Firefox

Desarrollo de aplicaciones web AJAX – utiliza el objeto XMLHttpRequest para manejar las peticiones en segundo plano Documentación DocBook

Representación de imágenes vectoriales SVG

Descripción notaciones matemáticas MathML

Bases de Datos

Además de ser comúnmente utilizado en el desarrollo de aplicaciones para el almacenamiento de configuraciones e incluso en la redefinición del lenguaje de Marcado de Hipertexto, Hypertext Markup Lan- guage (HTML), el XHTML.

Existe una gran cantidad de libros y páginas de Internet sobre XML, como [BEN03]. De hecho, pueden encontrarse uno o dos capítulos sobre XML en casi cualquier libro sobre desarrollo en Java, C# o de desarrollo de aplicaciones para Internet.

XSLT Transformaciones de Lenguaje de hojas de estilo extensibles (Extensible Stylesheet Language Transformations) XSLT es un lenguaje basado en XML que permite la manipulación y transformación de código

22 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales XML en cualquier otro formato basado en texto. Generalmente se utiliza para transformar XML en HTML, aunque ése es solamente uno de sus usos. La recomendación de Transformación XSL describe el proceso de aplicar una hoja de estilos XSL a un documento XML utilizando un motor de transformación [wW399]. Las transformaciones XSLT han sido utilizadas para convertir o acoplar el formato XML a un formato que sea comprensible o utilizable por la aplicación que lo necesite. Así, es posible definir cierta información en un formato claro para los humanos y el motor de transformación se encargará de traducir dicho formato en otro definido por las plantillas en la hoja de estilos XSL. Un ejemplo de dichas transformaciones se da en el desarrollo de interfaces gráficas usando GLADE en Linux. El archivo generado es un XML que posteriormente – en tiempo de ejecución o compilación, el motor se encarga de transformar en una interfaz gráfica basada en GTK.

Ajax Javascript asíncrono y XML (Asynchronous Javascript and XML) El desarrollo de las aplicaciones de Internet ha supuesto un problema su poca interactividad. La transmisión de información entre el cliente y servidor se ejecuta bajo los métodos GET y POST definidos en el protocolo HTTP [wW3C99] – lo cual representa que la comunicación entre el navegador y el servidor siempre se lleva a cabo tras la petición del usuario – al hacer clic sobre un botón o un vínculo. Se han desarrollado diversas técnicas que permiten carga asíncrona de recursos, empezando con el uso de los elementos iframe y layer y utilizando Javascript pueden cargar información en segundo plano y mostrarla al haberla cargado completamente; posteriormente Microsoft introduce un objeto llamado XMLHttpRequest que permitiría realizar esas operaciones de una forma más simple utilizando el lenguaje XML; el cual se implementaría posteriormente por otros desarrolladores de navegadores proporcionando así una cierta interfaz común para la transferencia asíncrona. Sin embargo la implementación de dichos objetos es inconsistente – aunque el W3C ha comenzado a elaborar una especificación sobre este objeto – las diferencias en su implementación en los distintos navegadores ha ocasionado que sea necesario utilizar ciertas técnicas para asegurar una compatibilidad entre ellos. En la figura 2.3 podemos ver la diferencia entre los modelos de comunicaciones síncrono y asíncrono. El objeto XMLHttpRequest es parte esencial de Ajax, pues es gracias al uso de dicho obje- to y el lenguaje Javascript, permitiendo un mayor grado de interactividad y facilidad de uso de las aplicaciones Web.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 23 Figura 2.3: Modelos de aplicaciones web

Además de las ventajas ofrecidas por el manejo asíncrono de la información, es importante se- ñalar que esa asincronía derivada en un incremento de la interactividad con el usuario se explota utilizando las técnicas del HTML Dinámico, Dynamic HTML (DHTML). En el apéndice B, se encuentra una prueba de streaming de datos, utilizando técnicas de Ajax y dibujado dinámico de gráficas. Existen muchas referencias en la web sobre Ajax, sin embargo [ZAK06] es un libro ampliamente recomendado en el que consideran desde Ajax básico, hasta manejo de Servicios Web usando Ajax.

Nuevas Tendencias En la actualidad se presentan nuevas opciones en tecnologías que permiten desarrollar aplicaciones que permiten mejorar el grado de interactividad en las aplicaciones web, dichas aplicaciones se denominan Aplicaciones Ricas de Internet, Rich Internet Applications (RIAs), siendo Ajax una de las técnicas utilizadas para este propósito. Adobe Flash ha mantenido una buena posición durante los úl- timos años proveyendo grandes capacidades multimedia aunque el desarrollo en él se ha visto bastante limitado en muchos aspectos, pues es complejo desarrollar una aplicación completamente utilizando las funciones provistas en él. Sin embargo, se han creado herramientas que permiten crear dichas interfaces de una forma más sencilla y se enfocan más directamente al desarrollo de RIAs, por citar al-

24 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales gunas de ellas, Adobe Flex y Open Laszlo. Recientemente otras compañías han desarrollado alternativas que compiten con Flash; por parte de Microsoft se encuentra Silverlight y por Sun Microsystems se presenta JavaFX, con lo que se busca incorporar a los desarrolladores de sus plataformas en el desarrollo de aplicaciones de Internet.

2.2.8 Frameworks para el desarrollo de aplicaciones Web Hablando de desarrollo de aplicaciones web, existen una gran cantidad de herramientas orientadas a una amplia variedad de usos. Existen también entornos o aplicaciones que permiten que el servidor pueda no sólo ofrecer contenido estático – como elementos HTML, imágenes, audio –, si no también contenido dinámico generado en base a peticiones a bases de datos, interacción con otros sistemas, etc. Entre esas herramientas encontramos también algunos marcos de trabajo, frameworks, que proveen una cierta metodología para el desarrollo de ciertas aplicaciones. En la tabla 2.3 se muestran algunos de los frameworks para desarrollo Web más utilizados junto con el lenguaje en el que está basado [wWAF07].

Lenguaje Frameworks* DotNetNuke · MonoRail · Apache Spring .NET · Apache Maverick .NET · ASP .NET User Interfaces Processs (UIP) Application Block Cold Fusion ColdSpring · FuseBox · Mach-II · Model-Glue Apache Cocoon · Apache Struts · AppFuse · Aranea Framework · Google Web Toolkit · Grails · Hamlets · Java Server Faces · Jboss Seam · jZeno · Mentawai Java · OpenLaszlo · Open Xava · Reasonable Server Faces (RSF) · RIFE · Shale Framework · Smart Client · Spring Framework · Stripes · Tapestry · ThinWire · WebObjects · WebWork · Wicket Framework · ZK Framework AJILE · Clean AJAX · Dojo Toolkit · Echo · Ext · jQuery · Microsoft AJAX Library · MichiKit · MooTools · Prototype Javascript Framework · qooxdoo · Client-side Rialto Toolkit · Rico · script-aculo.us · SmartClient · Spry Framework · Taconite framework · Yahoo! UI Library Perl Catalyst · Interchange · Jifty · Maypole · Mason Akelos PHP Framework · CakePHP · Canvas · CodeIgniter · DIY Framework PHP · FUSE · Horde · PHP For Applications · PHPOpenbiz · PRADO · Qcodo · Seagull PHP Framework · Symfony · Zend Framework · Zoop Framework CherryPy · Django · Karrigell · Nevow · Porcupine · Pylons · Spyce · Python TurboGears · TwistedWeb · Webware · web.py · Zope Ruby Camping · Nitro · IOWA · Ramaze · Cerise · Merb · Ruby on Rails Alpha Five · Fusebox (ColdFusion and PHP) · Helma Object Publisher Otros / Múltiples ( Server-side ) · Lift (Scala) · Magic (Scheme) · OpenACS (Tcl) · Seaside Lenguajes (Smalltalk) · UnCommon Web (Common Lisp) · Yaws (Erlang) * Los marcados en negritas siguen el patrón MVC

Tabla 2.3: Lista de Frameworks para desarrollo de Aplicaciones Web

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 25 Frameworks para desarrollo de aplicaciones Web orientadas al modelo MVC El patrón modelo, vista controlador, Model View Controller (MVC), es un patrón arquitectóni- co que busca separar ciertas aplicaciones en 3 etapas, cada una de las cuales se enfocan a la representa- ción lógica de la información, la etapa de reglas de negocio o procesamiento, y la visualización o interfaz gráfica. Existen distintas implementaciones en las diversas tecnologías existentes para desarrollar aplicaciones en el lado del servidor. Entre los que utilizan el lenguaje Java encontramos Apache Struts, Grails y Java Server Faces (JSF); de los que utilizan .NET están MonoRail, Apache Spring .NET y Maverick .NET; sin embargo destaca Ruby on Rails – basado en Ruby – debido a la facilidad y claridad del desarrollo de soluciones simples en dicho marco de trabajo. Ya que la implementación del servidor será bajo el sistema operativo Linux, no consideramos .NET como alternativa pues, aunque el proyecto Mono [www.mono-project.com] se encuentra en un nivel lo suficientemente estable, es preferible contar con herramientas que cuenten con el respaldo necesario de las compañías o comunidades correspondientes en dicho sistema operativo. Las tecnologías sobre las cuales desarrollaremos esta actividad, serán Ruby on Rails, Apache Struts y Cake PHP.

Ruby on Rails Ruby on Rails (RoR) surge en 1994 como un proyecto de Basecamp, una herramienta de ad- ministración de proyectos de la compañía 37 signals. El verdadero aporte de Ruby on Rails al desarrollo de aplicaciones Web es el popularizar ciertas características que permiten manejar algunas tareas de forma más sencilla y automatizada; un ejemplo de ello es el scaffolding y el mapeo objeto relacional, object-relational mapping (ORM) [wROR07] y [ROR07]. Scaffolding es una técnica utilizada en algunos frameworks MVC en el que el programador escri- be cierta especificación de la estructura de la aplicación y la base de datos y un compilador utiliza dicha especificación para generar el código que la aplicación utiliza para las operaciones de crear, leer, actualizar y borrar, create read update delete (CRUD), registros de una base de datos. Actualmente se han adaptado dichos métodos a otros frameworks distintos a RoR como Monorail, Symfony, Ca- kePHP, ModelGlue, Grails y Gaia Flash. RoR está basado en Ruby, el cual es un lenguaje que combina la sintaxis de Perl y Smalltalk con algunas características de Python, Lisp, Dylan y CLU. Los principios fundamentales de Ruby On Rails incluye la Convención sobre la configuración, Convention over Configuration (CoC), y No te repitas, Don't Repeat Yourself (DRY). El primero implica que el desarrollador solamente necesita especificar los aspectos no convencionales de la aplica- ción. DRY es una filosofía de procesos que busca reducir redundancia, principalmente en computa- ción. DRY es un principio que enfatiza que la información no debe ser duplicada, por que la duplica- ción incrementa la dificultad de cambio, puede decrecer la claridad y puede originar inconsistencia. Más que adjudicar todas esas características a Ruby on Rails, es importante resaltar el impacto

26 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales que ha ocasionado y que gracias a su popularidad se han afianzado términos y filosofías que son importantes en el desarrollo de aplicaciones. En Internet podemos encontrar gran cantidad de documentación y ejemplos del desarrollo de aplicaciones en RoR. Por ejemplo, supongamos tenemos una tabla en una base de datos con el nombre People. Y queremos crear todas las operaciones sobre una Persona, es decir, registrar una persona, visualizar y poder modificar su información y eliminar alguna persona registrada. La generación de la aplicación se reduce a las siguientes operaciones: Antecedentes: Tenemos una tabla People en una base de datos. La tabla contendrá la informa- ción que es deseable almacenar, como los nombres, apellidos, edad, etcétera. También tenemos instalado el framework Rails y el controlador de la base de datos respectivo. 1. Nos situamos en la carpeta donde deseamos crear la aplicación. 2. Tecleamos

rails nombre_aplicacion

3. Dentro de la carpeta nombre_aplicacion/config modificamos el archivo database.yml, introducimos el nombre del controlador del manejador de la base de datos, el nombre de usuario y contraseña de acceso a la base de datos y el nombre de la base de datos correspondiente. 4. Tecleamos

ruby script/generate scaffold Person

5. Tecleamos

ruby script/server

6. Accedemos a http://localhost:3000/people Con estos pasos hemos creado una aplicación utilizando el modelo MVC, y podemos realizar las operaciones CRUD sobre personas. La herramienta scaffold ha creado el modelo, vista y controladores sobre los registros de la base de datos. La convención sobre los nombres de las tablas y clases en la generación de la aplicación, ha permitido que todo esto se realice automáticamente, haciendo en este caso el mapeo de Person – como clase – a una tabla contenedora de personas – People en inglés –.

Apache Struts Apache Struts es un framework para desarrollar aplicaciones Java Empresariales. Utiliza y ex- tiende el API Java Servlet para alentar a los desarrolladores a adoptar la arquitectura MVC [wAST07] y [AST07]. La meta de Struts es separar el modelo (lógica de aplicación que interactua con la base de datos) de la vista (páginas HTML presentadas al cliente) y el controlador (instancia que transfiere la infor-

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 27 mación entre la vista y el modelo). Struts provee el controlador (un servlet conocido como Action- Servlet) y facilita la escritura de plantillas para la capa de vista o presentación. El programador de aplicaciones Web es responsable de escribir el código del modelo y crear un archivo de configuración central llamado struts-config.xml que enlaza las tres capas. No existe herramienta alguna como scaffold en RoR, para Struts. Tampoco contamos con un método o framework para el mapeo objeto relacional, con la cual podamos servirnos del patrón Active Record y manipular los registros de una base de datos como un objeto. Para ésto, es necesario utilizar alguna otra herramienta como Hibernate. NetBeans ofrece ciertas funcionalidades que permiten un desarrollo más ágil de aplicaciones basadas en Struts y JSF como framework de arquitectura e Hiber- nate como framework de persistencia. Struts 1.x es criticado debido a distintas carencias en su diseño, sin embargo en las versiones 2.x se mejoran muchos de esos aspectos. En [NBD06] podemos encontrar un videotutorial de cómo utilizar dichas herramientas dentro de NetBeans 5.5 y generar una aplicación similar a la que se ha expuesto anteriormente en RoR.

Spring Framework Es un framework de código abierto de desarrollo de aplicaciones para la plataforma Java. Inicial- mente no fue diseñado para seguir el patrón MVC, sin embargo los desarrolladores de Spring decidie- ron escribir su propio framework de red como una reacción al pobre diseño del popular Struts[wSPR07]. Spring ha ganado una gran popularidad debido a que las características del núcleo del Frame- work Spring son útiles en cualquier aplicación Java y existen muchas extensiones y mejoras para cons- truir aplicaciones basadas en web sobre la plataforma empresarial de Java; y por ello ha sido reconoci- do estratégicamente como un importante framework.

Grails Grails es un proyecto que intenta imitar las características de Ruby on Rails sobre una plataforma Java, mediante el uso de Groovy – el cual es un lenguaje de programación orientado a objetos para la plataforma Java como una alternativa a dicho lenguaje de programación, con características similares a Python, Ruby, Perl y Smalltalk [wGRO07] –. Grails utiliza Spring MVC como framework de aplicaciones web debido a su gran extensibilidad, además soporta Hibernate como framework para ORM [wGRA07]. Para desarrollar el mismo ejemplo en Grails, se siguen los mismos pasos que en Ruby on Rails. Antecedentes: Tener instalado grails y el paquete dbmapper – instalándolo con el comando grails install-plugin dbmapper. 1. Nos situamos en la carpeta donde deseamos crear la aplicación. 2. Tecleamos

grails create-app nombre_aplicacion

28 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3. Dentro de la carpeta nombre_aplicacion/grails-app/conf modificamos el archivo DataSource.groovy, introducimos el nombre del controlador del manejador de la base de datos, el nombre de usuario y contraseña de acceso a la base de datos y el nombre de la base de datos correspondiente. 4. Tecleamos

grails generate-domain-classes

5. Tecleamos

grails generate-all

6. Tecleamos

grails run-app

7. Accedemos a http://localhost:8080/nombre_aplicacion

Cake PHP Cake es un framework para el desarrollo de aplicaciones rápidas en PHP. Es una estructura de librerías clases y una infraestructura en tiempo de ejecución para programadores de aplicaciones Web inspirado en el framework de Ruby on Rails [wCAK07]. En el caso de Cake PHP, el framework no se encarga de generar la estructura de directorios para cada aplicación nueva, así que es necesario utilizar la que tiene en el momento de la instalación. De la misma forma que en el caso anterior, se necesita tener una base de datos como la especificada anteriormente. 1. Creamos un archivo de modelo. Dentro del directorio /app/models, creamos un archivo person.php con el siguiente código:

2. Creamos un archivo de controlador. Dentro del directorio /app/controllers creamos un archivo person_controller.php con el código siguiente:

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 29 3. Al declarar la variable $scaffold, Cake automáticamente generará el manejador de Per- sonas. 4. En el navegador accedemos a la dirección donde tengamos instalado Cake y al subdi- rectorio/people.

Frameworks del lado del cliente Entre los frameworks del lado del cliente que pueden interesarnos, son aquellos basados en AJAX – según se estableció en los apartados de tecnologías web y dibujado de gráficas dinámicas – así pues, entro los frameworks existentes más utilizados para el desarrollo de aplicaciones o interfaces ricas en el lado del cliente se encuentran: prototype.js, dojo, jquery, spry y mootols.

Prototype.js Prototype es un framework basado en JavaScript orientado al desarrollo sencillo y dinámico de aplicaciones Web, implementa las técnicas de AJAX y aunque no ofrece efectos visuales, existen otros frameworks que se basan en Prototype para ofrecer estas características como Rico y Script.aculo.us [PRO07]. Muchos otros frameworks utilizan sintaxis o se basaron inicialmente en Prototype, por lo que se conservan algunas convenciones en su manejo.

MooTools Entre sus ventajas se encuentra su bajo tamaño y la librería de efectos. Mootools consiste en una librería núcleo llamada core.js, extensible utilizando otros componentes y plugins [MOO07]. MooTools es compatible con Safari, Internet Explorer 6 y 7, Firefox, Opera y Camino.

jQuery Es una librería rápida y concisa que simplifica el procesamiento de documentos HTML, manejar eventos, ejecutar animaciones y agregar interacciones AJAX a aplicaciones web [JQU07].

HL7 Health Level Seven (HL7) es una organización de desarrollo de estándares, Standard Develo- ping Organization (SDO) acreditada por el Instituto Nacional Americano de Estándares, American National Standards Institute (ANSI) operando en el área del cuidado de la salud. La mayoría de los SDO produce estándares (algunas veces llamados especificaciones o protocolos) para un dominio particular del cuidado de la salud como farmacia, dispositivos médicos, imágenes o transacciones de seguros. El dominio del HL7 es la información clínica y administrativa [wHL707]. Dentro de los estándares producidos por el HL7 se encuentra la Arquitectura de Documentos Clínicos, Clinical Document Architecture (CDA), la cual era conocida hasta ahora como Arquitectura

30 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales de Registros de Pacientes, Patient Record Architecture (PRA), provee de un modelo de intercambio para documentos clínicos y acerca a la industria del cuidado de la salud a la realización de registros médicos electrónicos. Mediante el uso del XML, el Modelo de Información de Referencia, Reference Information Mo- del (RIM) y vocabularios codificados, el CDA crea documentos tanto legibles para las máquinas – así pues son fácilmente analizados y procesados de forma electrónica – y legibles por las personas – así pueden ser fácilmente recuperados y utilizados por las personas que lo necesiten. Los documentos CDA pueden ser mostrados utilizando navegadores Web que soporten XML o aplicaciones inalám- bricas como teléfonos celulares.

Conformación del expediente médico La Norma Oficial Mexicana (NOM) 168-SSA1-1999, [...]establece los criterios científicos, tec- nológicos y administrativos obligatorios en la elaboración, integración, uso y archivo del expediente médico [NOM99]. Los requisitos generales para la elaboración del expediente, se definen a continuación. Todo expediente clínico deberá contener los siguientes datos generales: ● Tipo, nombre y domicilio del establecimiento y, en su caso, nombre de la institución a la que pertenece. ● En su caso nombre y denominación social del propietario o concesionario. ● Nombre, sexo, edad y domicilio del usuario. En [NOM99] se consideran otros puntos para las notas médicas en servicios de hospitalización, urgencias, reportes del personal profesional, técnico y auxiliar y otros documentos. Sin embargo para efectos de este trabajo, se considerarán los puntos más estrechamente relacionados con el monitoreo y el almacenamiento de la información obtenida para en base a ésta generar los expedientes.

2.3 Resumen Las tecnologías definidas en este capítulo, suponen la base del desarrollo de este proyecto. Si bien en él no se ha profundizado en el desarrollo de las aplicaciones web, fundamentos e historia; se invita al lector a leer un poco más en la bibliografía recomendada pues no cabe de más saber cómo funcionan las aplicaciones actuales y cómo podrían implementarse nuevas. También se esbozan las características de algunos documentos que son necesario obtener para así aclarar cuáles son las necesidades y que documentos son necesarios que elabore el sistema.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 31

Capítulo 3 Análisis y Diseño de la Aplicación

“Aunque el ingenio humano pueda crear invenciones varias que, por la ayuda de varias máquinas respondiendo al mismo fin, nunca producirá ninguna invención más bella, ni más simple, ni más apropiada que las que hace la Naturaleza; por que en sus invenciones nada falta, ni nada es superfluo, y [la Naturaleza] no necesita contrapeso cuando crea miembros apropiados para el movimiento en los cuerpos de los animales.” Leonardo di Ser Piero da Vinci

3.1 Introducción En el capítulo 1 se estableció una propuesta de solución al problema planteado del monitoreo remoto de signos vitales, se proporcionaron algunos objetivos que el sistema debe cumplir. En este ca- pítulo se detallarán los requerimientos del sistema para poder realizar el análisis y diseño correspondientes. De acuerdo al planteamiento previo, los objetivos generales del sistema son: ● El sistema debe permitir visualizar los monitores de forma remota, además de brindar la capacidad de visualizar todos los parámetros del monitor in situ. ● El sistema debe almacenar alarmas y la información obtenida por los monitores de signos vitales y permitir su posterior consulta. Esta primera aproximación se detalla en la tabla 3.1, en la que se muestran los requerimientos del sistema y se catalogan en base a la clasificación de requerimientos del modelo F.U.R.P.S.+2 – Fun- cionalidad, Facilidad de uso, Confiabilidad, Desempeño y Soporte ; Functionality, Usability, Reliabi- lity, Performance and Supportability – .

2 Grady, R. and Caswell, D., Software Metrics: Establishing a Company-Wide Program, Prentice Hall, 1987

33 Funcionalidad Características ● El sistema en el monitor de signos vitales, debe de recuperar la información obtenida por el sistema de adquisición y formar paquetes que serán transmitidos al servidor de monitores de signos vitales (VSM Server). ● El sistema del servidor debe de recibir la información y almacenarla en el disco duro. ● El sistema del servidor debe permitir recuperar la información almacenada sobre cierto paciente en la forma de un expediente médico que siga el estándar HL7. ● El sistema debe de mostrar las alertas formadas por los monitores para que así el staff médico que se encuentre utilizando el monitor en la central de enfermeras, pueda responder a ellas. Conectividad ● Los monitores de signos vitales se conectarán al servidor de forma inalámbrica. Seguridad ● El sistema debe ser accesible desde la red LAN del hospital. ● Para acceder al sistema Web, los miembros del staff deben de autenticarse con la contraseña y nombre de usuarios asignados al momento de su registro. Facilidades de uso Factores humanos y Estéticos ● La disposición de ventanas y elementos de acción (botones, menús) debe de lograr una interfaz clara y familiar al usuario de los monitores de signos vitales. ● La interfaz gráfica debe de tener fondos oscuros que permitan resaltar el contraste con la información mostrada en pantalla. ● En todo momento no se debe de perder de vista la información del electrocardiograma (ECG) de los pacientes. ● Las alarmas deben visualizarse de modo tal que no interfieran con el funcionamiento o visualización de los demás elementos del sistema, pero debe ser visible y obtenerse el foco de atención del usuario. ● La información mostrada en pantalla sobre los monitores de signos vitales, debe de representarse en color rojo al arrojarse ciertas alarmas. Confiabilidad Frecuencia y severidad de fallas ● La frecuencia de fallas debe ser baja.

34 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ● Al presentarse una falla el sistema debe continuar su funcionamiento normal. Recuperación a fallos ● Puede ser necesario considerar algunas técnicas de tolerancia a fallos para asegurar la integridad de la información de los expedientes médicos. Rendimiento ● El sistema debe soportar un máximo de 20 monitores de signos vitales funcionando al mismo tiempo. Requisitos de Implementación Estándares Requeridos ● Se requiere que el formato de los expedientes médicos siga las especificaciones definidas para el expediente médico electrónico del IMSS, quienes siguen los estándares definidos por el HL7; además de la NOM-168-SSA1-1998. Lenguajes de implementación ● Para los monitores de signos vitales debe de manejarse las herramientas incluidas en Borland C++ Builder 2006, además de cualquier otra libre que funcione sobre Windows XP Embbeded. ● En los servidores, los lenguajes, herramientas, sistemas operativos y manejadores de bases de datos no están restringidos. Requisitos de Interfaz El hardware que se considera para los monitores de signos vitales es una computadora (PC), implementado por el Centro de Investigación e Innovación Tecnológica del Instituto Politécnico Nacional (CIITEC-IPN) con las siguientes características: Motherboard y chipset VIA (rendimiento similar a un Pentium 4) 512 MB RAM Monitor Táctil Tarjetas de adquisición de signos vitales (varias) Tarjeta de red inalámbrica IEEE 802.11g El hardware requerido para el servidor, no se encuentra restringido.

Tabla 3.1: Especificación de Requerimientos del Sistema

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 35 3.2 Arquitectura de la Aplicación

3.2.1 Escenarios La información sobre las camas o monitores no presenta una gran cantidad de movimientos. De hecho, solamente se registran una vez y son ocasionales las operaciones de modificación o eliminación. Escenario 0: “Registro de enfermeras y médicos en el sistema”. Un médico o enfermera necesita ser registrado en el sistema. El administrador recopila su infor- mación (nombre) y se le asigna automáticamente un identificador en el sistema, un nombre de usuario y una contraseña. Tras haberse registrado cualquiera de ellos puede ser asignado a pacientes que se encuentren en el sistema. Escenario 1: "Llegada de un paciente al área de terapia intensiva" Antecedentes: Deben de estar registrados en el sistema médicos, enfermeras y las camas que pueden asignarse. Un paciente es asignado al área de terapia o cuidado intensivo. Una enfermera lo recibe y obtiene su información demográfica, perfil médico (padecimientos), posteriormente le asigna una cama y lo registra en el sistema. Finalmente se le asigna una enfermera y algún doctor si no han sido asignados anteriormente. Y se registra el evento "Paciente admitido, hora de entrada". Escenario 2: “Monitoreo de los pacientes” Antecedentes: Ya existen pacientes registrados y en actual monitoreo. Los monitores se encuentran conectados al sistema y transmiten información a la central. El sistema de adquisición recibe información de los sensores. El sistema en el monitor se encarga de recopilar la información obtenida por dicho sistema y forma paquetes que serán transmitidos al Servidor (VSM Server). La pantalla principal del sistema muestra el estado global de todos los pacientes por medio de recuadros en mosaico que contienen una parte de la información que se visualiza en un monitor completo. Escenario 2.1: “Autenticación de un cliente web” Antecedentes: Al dar de alta un médico o enfermera, se les asigna un nombre de usuario y contrase- ña, con lo cual pueden acceder como clientes Web utilizando un navegador Web. Un miembro del staff accede al sistema utilizando un navegador web. Se le mostrará una pantalla donde necesite introducir su nombre de usuario y contraseña, Escenario 3: “Visualización del monitor completo” Antecedentes: Ya existen pacientes registrados y en actual monitoreo. Los monitores se encuentran conectados al sistema y transmiten información a la central. Un miembro del staff puede seleccionar un monitor de aquellos que se muestran en la pantalla de monitoreo global y podrá visualizar el monitor completo – o detallado – de dicho paciente. En dicha pantalla puede tener la opción de regresar a la vista global, seleccionar otro monitor o paciente y

36 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales consultar el expediente del paciente, donde se mostrará la información registrada del paciente al registrarse. Además, se ofrece la opción de que pueda accederse al historial de monitoreo. Escenario 4: “Selección de monitor/paciente” Antecedentes: Esta opción es la opción por defecto en el caso de acceder al sistema utilizando un navegador Web. Un miembro del staff que ha seleccionado dicha opción o un usuario, que accede por un navegador – denominado cliente Web – puede seleccionar de una lista el nombre del un paciente que se encuentre en monitoreo, y será dirigido a la visualización del monitor completo de dicho paciente. Escenario 5: “Consulta de expediente médico” Antecedentes: Haber seleccionado la opción de expediente médico dentro del monitor extendido. Un miembro del staff o un cliente Web, pueden acceder al expediente médico donde se mostra- rá la información capturada en el registro del paciente, hora de entrada, sus médicos y enfermeras asignados y otra información de importancia que se haya generado en el transcurso del monitoreo como alarmas activadas. Escenario 6: “Situación de alarma” Cuando un monitor de signos vitales que se encuentre registrado en el sistema arroje una alarma, ésta debe visualizarse dentro de cualquier ventana que se encuentre utilizando el staff en la forma de un aviso emergente describiendo brevemente la situación de alarma y en qué monitor o cama se presentó.

3.2.2 Actores

Administrador Es parte del staff y es quien puede registrar nuevos usuarios al sistema, dar de alta pacientes, asignarles médicos y enfermeras, modificarlos o darlos de baja.

Staff Miembro del cuerpo de médicos y enfermeras que puede acceder al sistema para visualizar los monitores, expedientes e historial de monitoreo de los pacientes asignados al sistema. La principal diferencia entre los miembros del staff a los Clientes Web, es el medio de acceso, limitándose éste al acceso desde la central de enfermeras.

Cliente Web Miembro del staff que accede al sistema utilizando un navegador Web.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 37 Sistema de Adquisición Sistema desarrollado por el CIITEC – IPN en los monitores, encargado de obtener informa- ción de los sensores. Existe un subsistema encargado de recopilar la información obtenida por el Sis- tema de Adquisición y formar paquetes para transmitirlos posteriormente al Servidor ofreciendo así al Monitor de Signos Vitales, de ciertas capacidades de comunicación en red.

3.3 Consideraciones del diseño La actividad inicial del diseño de cada uno de los módulos había considerado que el sistema po- día dividirse en módulos. Sin embargo tras la investigación, especificación de requerimientos y el aná- lisis del sistema, nos hemos dado cuenta de que el diseño basado en módulos no es la mejor solución al problema, pues no se estaba considerando el funcionamiento del sistema en general – era proponer una arquitectura sin siquiera haber comenzado el diseño –. Es así como en el diseño podemos ver objetos que pueden ser catalogados con esos roles: Almacenamiento, Tratamiento de las alarmas, de Monitoreo y del Núcleo (principales), más sin embargo no necesariamente componen subsistemas por sí mismos. Tras haber finalizado el diseño podremos definir la arquitectura adecuada. Utilizando la simbología del análisis de robustez, robustness analysis y la asignación de estereoti- pos a las clases identificadas, podemos diseñar el sistema de forma tal que se siga el modelo MVC en los casos correspondientes.

38 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3.4 Casos de uso Generales

3.4.1 Nivel Cero En el diagrama que se muestra en la figura 3.1 se engloban los casos de uso principales del sistema. Además de dividir el sistema en dos subsistemas – cada uno correspondiente tanto al monitor de signos vitales como al servidor de monitores –, también se pueden categorizar los casos de uso en Administrativos y de Monitoreo.

Figura 3.1: Diagrama del nivel cero de casos de uso del servidor de monitores

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 39 3.4.2 VSM Server

Autenticar Este caso de uso es el antecedente a los demás casos de uso administrativos del sistema, pues verifica que el usuario pueda acceder al mismo y restringe las opciones que se presentan al usuario. Las secuencias de autenticación de usuarios se muestran en las figuras 3.8, 3.9 y .

ID Caso de uso: CU.S.Auth Nombre de Caso de Uso: Autenticar Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 17/10/2007 Fecha de actualización:

Actores: Usuario (Administrador, Staff, Cliente Web) Descripción: Es el caso de uso correspondiente a la autenticación del usuario. Presenta las opciones a las que éste puede acceder dependiendo de su nivel de acceso. Disparador: Selección de la opción Inicio de Sesión en una pantalla de inicio Precondiciones: Poscondiciones: Al haberse autentificado, les serán mostradas las opciones a las que pueden acceder para utilizar el sistema. Flujo Normal 1. El usuario introduce su nombre de usuario y su contraseña en los campos correspondientes y da clic en un botón de Iniciar Sesión. 2. El sistema verifica que el nombre de usuario y contraseña correspondan con los almacenados y verifica su nivel de acceso (Administrador, Staff o Cliente Web). 3. Tras haberse verificado el nivel de acceso, se muestran las opciones correspondientes a dicho nivel. 1. En el nivel de administrador se muestran las opciones de Administración de pacientes, Administración de médicos y enfermeras 2. En el nivel de staff, se muestra el monitor global. 3. En el nivel de Cliente Web, se muestra la selección de monitores extendidos. Flujos Alternativos: El nombre de usuario o contraseña son incorrectos El sistema muestra un aviso que contiene el mensaje “Nombre de usuario y/o contraseña incorrectos, favor de verificarlos”.

Tabla 3.2: Caso de uso Autenticación

40 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Administrar personas Este caso de uso engloba a los casos de uso que realizan operaciones administrativas – registro, modificación de información, consulta y eliminación del sistema – para cada uno de los miembros que operan en el sistema – enfermeras, médicos y pacientes –, en la figura 3.2 se muestra el diagrama del caso de uso correspondiente. Ya que el objetivo principal del proyecto es la obtención de los signos vitales, su monitoreo y almacenamiento, se hará un mayor análisis respecto a los casos de uso correspondientes. Por lo tanto, los casos de uso derivados de Administración se describen fuera del cuerpo principal del trabajo y más detalladamente en el Anexo A.

ID Caso de uso: CU.S.Admin Nombre de Caso de Uso: Administrar personas Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 17/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Es el caso de uso correspondiente a la administración – registro, modificación de información y eliminación – de pacientes, médicos y enfermeras. Disparador: Selección de la opción Administración en la pantalla principal. Precondiciones: El Administrador debe haber accedido al menú de administración autenticándose en una pantalla inicial. Poscondiciones: Al registrarse un paciente se almacena la información necesaria para establecer su expediente médico. Flujo Normal Al Administrador le son mostradas las categorías de administración: Administración de pacientes, administración de médicos y administración de enfermeras, además de las opciones para volver al menú anterior. Flujos Alternativos: Cancelación de la operación. Regresa a las opciones de la pantalla principal

Tabla 3.3: Caso de uso Administrar personas

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 41 Figura 3.2: Diagrama de casos de uso de Administrar personas

42 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Ver monitores Este caso de uso considera las operaciones de acceso para visualización de los monitores remotos. Permite acceder al monitor global a los miembros del staff que se hayan autenticado como tales pero el acceso no está permitido como cliente Web. Así, el monitor global será accedido por el staff desde la central de enfermeras y sólo se permitirá el acceso a un monitor a la vez a los Clientes Web. El diagrama de casos de uso asociado, se muestra en la figura 3.3 y las secuencias asociadas se presentan en las figuras 3.10 y 3.11.

ID Caso de uso: CU.S.Admin.1 Nombre de Caso de Uso: Ver monitores Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Staff, Cliente Web Descripción: Permite el acceso a la visualización de monitores: el monitor global y monitores extendidos. Disparador: Selección de la opción Ver Monitores dentro de las opciones de la pantalla principal. Precondiciones: El usuario se ha autenticado en el sistema. Existen monitores conectados al sistema así como pacientes, médicos y enfermeras. Poscondiciones: Flujo Normal: Al usuario le son mostradas las opciones existentes: 1. Si el rol del usuario es staff y accede desde la central de enfermeras, le son mostradas las opciones de Ver Monitor Figura 3.3Global: Diagrama y Ver de casos detalle de uso de de monitor Ver monitores. 2. Si el usuario es un Cliente Web, es dirigido directamente al caso de uso Ver detalle de monitor. Flujos Alternativos: Ver monitores

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 43 Ver detalle de monitor Este caso de uso describe el acceso a un solo monitor. El staff puede así visualizar la informa- ción completa del monitor de signos vitales de un paciente a la vez, a diferencia del monitor global en el cual se muestra la información reducida de todos los pacientes. El diagrama se encuentra en la figura 3.4.

ID Caso de uso: CU.S.Admin.1 Nombre de Caso de Uso: Ver detalle de monitor Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Staff, Cliente Web Descripción: Permite el acceso a la visualización de monitores: el monitor global y monitores extendidos. Disparador: Selección de la opción Ver detalle de monitor dentro de las opciones de la pantalla principal. Se ha seleccionado uno de los monitores visibles dentro del monitor global. Precondiciones: El usuario se ha autenticado en el sistema. Existen monitores conectados al sistema así como pacientes, médicos y enfermeras. Poscondiciones: Flujo Normal: El usuario ha accedido desde la pantalla principal. 1. Se muestra una lista desplegable con los monitores disponibles. 2. El usuario selecciona una lista Flujos Alternativos:

Figura 3.4: Diagrama de casos de uso Ver detalle de monitor

44 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Administrar monitores Estos casos de uso se refieren al manejo de la conexión con el monitor, el registro del monitor en el sistema, el emparejamiento de los dispositivos y la transmisión de comandos – por ejemplo, para el establecimiento de la información que es necesaria transmitir a una frecuencia más alta para su despliegue en pantalla. El diagrama del caso de uso se muestra en la figura 3.5, además las secuencias consideradas dentro de este caso de uso, se presentan en la figura 3.13, 3.14 y 3.15.

ID Caso de uso: CU.S.Admin.1 Nombre de Caso de Uso: Administrar monitores Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Monitor de Signos Vitales Descripción: Es el caso de uso principal que utiliza el Monitor de Signos Vitales para comunicarse con el Servidor de monitores. Contempla los casos de uso de registro del monitor en el sistema, emparejamiento y el establecimiento de la frecuencia del monitor. Disparador: El Monitor de Signos Vitales se conecta al sistema y transmite ciertos mensajes administrativos. Precondiciones: Existe una conexión física entre el Monitor de Signos Vitales y el Servidor de monitores. Poscondiciones: Dependiendo de la operación realizada, se registrará un monitor en el sistema o se habrá establecido la frecuencia a la que el Monitor de Signos Vitales debe transmitir determinada información. Flujo Normal: 1. El Monitor de Signos Vitales accede o transmite un mensaje conteniendo información administrativa es decir, no corresponde a un mensaje de información ni de alerta. 2. El Servidor de monitoreo responde a los eventos en base al caso de uso asociado. Flujos Alternativos:

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 45 Figura 3.5: Diagrama de casos de uso de Administración de monitores

46 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Recibir información Este caso de uso se compone de las operaciones necesarias para recibir la información del monitor y procesarla. La secuencia relacionada al caso de uso, se muestra en la figura 3.12. Las actividades relacionadas a la recepción y procesamiento de la información, se muestran en las figuras 3.23, 3.24 y 3.25; además, las secuencias asociada a este aso de uso se presentan en las figuras 3.12 y 3.17.

ID Caso de uso: CU.S.Admin.1 Nombre de Caso de Uso: Recibir información Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Monitor de Signos Vitales Descripción: Es el caso de uso que se ejecuta al obtener información del Monitor de Signos Vitales. La información recibida se procesa y direcciona al caso de uso correspondiente – ya sea Procesamiento de Información o Procesamiento de Alarmas -. Disparador: Se reciben mensajes de información provenientes del Monitor de Signos Vitales, en el Servidor de monitores. Precondiciones: Existe una conexión física entre el Monitor de Signos Vitales y el Servidor de monitores. Poscondiciones: Los mensajes recibidos de los Monitores de signos vitales, serán procesados y se ejecutarán operaciones relacionadas al contenido. Flujo Normal: Se recibe un mensaje de información del Monitor de Signos Vitales. El Servidor de monitores, procesa el mensaje y lo dirige a un proceso encargado de los mensajes de información y a otro encargado de los mensajes de alerta.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 47 3.4.3 Monitor de Signos Vitales

Nivel Cero Los casos de uso asociados al Monitor de Signos Vitales, contempla solamente el caso de trans- misión, el cual se encargará de formar paquetes de información o alarmas, y los transmitirá al Servi- dor de monitores.

Figura 3.6: Diagrama del nivel cero de casos de uso del monitor de signos vitales

Transmitir Este caso de uso describe el comportamiento del monitor de signos vitales, en el que el sistema de adquisición se encarga de formar los paquetes que serán transmitidos al servidor de monitores de signos vitales dependiendo de las políticas establecidas. El diagrama de casos de uso asociado se presenta en la figura 3.7 y el diagrama de actividades que describe mejor el comportamiento de este proceso se muestra en la figura 3.22.

48 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ID Caso de uso: CU.S.Admin.1 Nombre de Caso de Uso: Transmitir Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Sistema de Adquisición, Servidor de monitores (receptor) Descripción: Es el caso de uso asociado a las operaciones de transmisión de información. La información obtenida por el Sistema de adquisición – desarrollado por el CIITEC -IPN -, se empaquetará y transmitirá al Servidor de monitores. Disparador: Un temporizador se activa al llegar a cierto tiempo. Toda la información obtenida por el Sistema de Adquisición se ha recopilado en un paquete y al cumplirse el plazo del temporizador se activa el caso de uso. Precondiciones: El temporizador ha llegado a 0 y se ha reiniciado. El Sistema de Adquisición obtiene información de los sensores asociados en el monitor. Poscondiciones: Se formará un paquete con la información recopilada y se transmitirá al Servidor de monitores. Flujo Normal: 1. El Sistema de adquisición recopila información durante el tiempo que el temporizador funcione. 2. Cuando el temporizador ha cumplido su plazo, se forma un paquete con la información obtenida. 3. Se forma un nuevo paquete en el cual se almacena la información que se ha recopilado durante este proceso. 4. Al finalizar de transmitirse la información el temporizador se restablece y comienza nuevamente el ciclo. Flujos Alternativos: 1. No hay conexión disponibles 1. No se realiza ninguna transmisión. 2. Hay alertas 1. Al existir alertas, el Monitor de Signos Vitales puede transmitirlas de forma inmediata Servidor de monitores.

Figura 3.7: Diagrama de casos de uso de Transmisión

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 49 3.5 Diagramas de Secuencia

Autenticación de usuarios

Figura 3.8: Secuencia Autenticación Administrador

Figura 3.9: Secuencia Autenticación Staff

50 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Visualización de monitores

Figura 3.10: Secuencia Ver monitor global

Figura 3.11: Secuencia Ver detalle de monitor

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 51 Recepción de información

Figura 3.12: Secuencia Recibir información

Administración de monitores

Secuencia registro

Figura 3.13: Secuencia Registro de monitor

52 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Secuencia emparejamiento

Figura 3.14: Secuencia Emparejamiento de monitor

Secuencia establecer frecuencia

Figura 3.15: Secuencia Establecer Frecuencia de Monitor

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 53 Streaming

Figura 3.16: Secuencia de Streaming

Procesar alerta

Figura 3.17: Secuencia Procesar Alerta

54 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3.6 Diagrama de Clases

Clases persistentes

Figura 3.18: Diagrama de Clases Persistentes

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 55 Diagrama General

Figura 3.19: Diagrama general de clases

56 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Paquete Communications

Figura 3.20: Diagrama de clases del paquete Communications

Paquete WebApp

Figura 3.21: Diagrama de clases del paquete WebApp

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 57 3.7 Diagramas de Actividades

Transmisión

Figura 3.22: Actividades de Transmisión de información

58 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Recepción de Información

Figura 3.23: Actividades de Recepción de Información

Procesamiento de Información

Figura 3.24: Actividades de Procesamiento de Información

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 59 Almacenamiento de Información

Figura 3.25: Actividades para Almacenamiento de Información

60 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3.8 Diagramas de Paquetes

Diagrama general de paquetes

Figura 3.26: Diagrama de paquetes

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 61 3.9 Diagramas de Despliegue

Figura 3.27: Diagramas de despliegue

62 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3.10 Diseño de la base de datos En el sistema, es necesario almacenar información de los pacientes, médicos y enfermeras para poder mantener un registro sobre el expediente o historial médico de los pacientes, la información obtenida por los monitores y determinar quienes fueron los médicos y enfermeras asignados a su caso. Dicha información de la cual debe generarse el expediente médico está contenida dentro de la NOM-168-SSA1-1998. Ya que el sistema no busca llevar la administración del personal, se consideran por el momento la información general establecida en las generalidades de la NOM-168-SSA1-1998:

Información requerida Pacientes Nombre (s), apellidos, sexo, fecha de nacimiento, domicilio. Médicos Nombres(s), apellidos Enfermeras Nombres(s), apellidos Institución que brinda el servicio Tipo, nombre y domicilio del establecimiento

En las figuras 3.28 y 3.29 se muestran el diagrama entidad-relación y el modelo relacional.

Figura 3.28: Diagrama Entidad-Relación

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 63 Figura 3.29: Modelo Relacional 64 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3.11 Puntos clave del diseño

3.11.1 Caracterización de la información a transmitir

Formación del mensaje Cada sensor transmite 16 bits de información (2 Bytes). Esa información es transmitida utilizando IEEE 802.11g/n. El tamaño del paquete es variable con un encabezado de 2 bytes, compuesto por el identificador del monitor, el tipo de mensaje y el tamaño del paquete.

Encabezado del mensaje El contenido del mensaje es variable, sin embargo todos los mensajes contienen campos que permiten identificar el monitor que genera el mensaje, el tipo de mensaje y el tamaño del mensaje. Identificador del monitor Éste es un número de 6 bits indicando el identificador del monitor en el servidor. El monitor podría tener un identificador propio que permita mantener una mejor seguridad en los dispositivos, sin embargo en efectos de programación, este indicador toma esos valores. La longitud del identificador, permite el manejo de 64 monitores máximo. Tipo de mensaje Campo de 2 bits conteniendo el tipo de mensaje

Binario Decimal Valor 00 0 Sin asignar 01 1 Mensaje de control 10 2 Mensaje de información simple 11 3 Mensaje de alerta

Tabla 3.4: Tipos de mensaje

Tamaño del paquete Campo de 8 bits que indica la longitud del mensaje en kilobytes, teniendo así un tamaño máxi- mo de 256 kilobytes. En el caso de que la longitud del mensaje sea menor a 1 kilobyte, el mensaje será rellenado con bits sin información, hasta llenar el kilobyte.

Mensaje de control El mensaje de registro contiene la información del monitor y el estado del mismo.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 65 La estructura de este mensaje no se encuentra bien definida actualmente, pues no se han determinado los servicios que debe ofrecer el servidor a los monitores y los servicios de control que deben de ofrecerse en el monitor, como pueden ser retransmisión de tramas, cambio en el tamaño de paquetes, o en la frecuencia de transmisión. Véase modelo de transmisión

Mensaje de información simple Los mensajes de información simple se reciben por los puertos de comunicaciones asignados por el servidor. El mensaje de información simple contiene la información proveniente de los dispositivos de adquisición en el monitor de signos vitales. Los dispositivos de adquisición están identificados por un número, el cual corresponde a alguno de los dispositivos que se enlistan a continuación.

Variable obtenida (dispositivo *) Id ECG 1 Oximetría de pulso 13 Capnografía 14 Presión respiratoria (ventilador) 15 Flujo y volumen 15 respiratorios(ventilador) Presión no invasiva 16 Presión invasiva 17 Gastocardiaco 18 Temperatura 19 * Los dispositivos de adquisición generalmente se relacionan con sólo una variable. En el caso del ventilador, éste obtiene tres variables distintas.

Tabla 3.5: Dispositivos de adquisición La composición del mensaje se muestra en la figura 3.30.

Figura 3.30: Formación del mensaje

66 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales La información del sensor, debe estar codificada de tal forma que pueda ser delimitada, es decir conozcamos el inicio y el fin del paquete de información. Esto puede lograrse utilizando cadenas delimitadoras o un campo de tamaño del contenido. Las cadenas de inicio y fin (delimitadoras), contienen una secuencia de bits que no debe aparecer en el campo de información. Para poder lograr esto, podemos usar la técnica de relleno de bits (bit stuffing). Al considerar que un mensaje puede contener más de un paquete de información del mismo sensor, la longitud varía nuevamente, con lo cual es necesario considerar el tamaño máximo de los paquetes y las frecuencias de aparición para determinar así el tamaño máximo del mensaje y modificar el campo de tamaño.

Hasta el momento se cuenta con la información mostrada en la siguiente tabla:

Dispositivo Frecuencia de Tamaño de mensaje Observaciones mensaje Ventilador 10 Hz Variable Obtiene la presión, flujo y volumen 4 bytes de cabecera respiratorios y los estados de las 3 - 150 bytes de contenido alarmas del dispositivo. Tamaño máximo: 154 bytes Capnografía 20 Hz Constante 11 bytes de cabecera 5 bytes de contenido Tamaño constante de 21 bytes Electrocardiograma 1000Hz, 500Hz Variable Contiene la información de los 12 y 100Hz Tamaño tentantivo: 80 canales del ECG bytes máximo.

Tabla 3.6: Caracterización de los dispositivos

Información del sensor Cada uno de los dispositivos de adquisición generan distintas tramas de bits, cada una de las cuales contienen información respecto a lo adquirido por los dispositivos, a su estado y a las alarmas asociadas a su funcionamiento y estado clínico del paciente. Un ejemplo de la formación de paquetes del dispositivo ventilador, que nos brinda informa- ción sobre presión, flujo y volumen respiratorios se muestra a continuación:

1 byte 1 byte 3 a 150 bytes 1 byte 1 byte Delimitador Cantidad de datos Datos CRC Checksum

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 67 El paquete de datos está compuesto de la siguiente forma:

1 byte Variable según tipo Tipo Datos

Donde los tipos más comunes se muestran en la tabla 3.7.

Tipo Descripción 85 Lectura del porcentaje de oxigeno 86 Valores al final de cada inspiración 87 Valores al fin de cada espiración 102 Paquetes con información de valores programados 103 Alarmas 104 Estado del funcionamiento del respirador 105 Bloque de datos con valores para graficar curvas durante tiempo inspiratorio 106 Bloque de datos con valores para graficar curvas durante tiempo espiratorio

Tabla 3.7: Tipos de mensajes de datos del ventilador

Entonces el modelo de paquete propuesto consideraría parte de los campos del paquete de in- formación proveniente de los dispositivos de adquisición o bien, información previamente procesada en el monitor de signos vitales.

Mensaje de alerta Los mensajes de alerta se reciben únicamente en el puerto de alertas del monitor. Si bien el mensaje simple por sí mismo contiene las alertas, se puede considerar el manejo de un mensaje dedicado únicamente a las alertas. Teniendo así dos opciones, manejar las alertas respecto a la información recibida en los mensajes de información y/o manejar las alertas respecto a otros mensajes, denominados “mensajes de alerta”. Los monitores de signos vitales pueden arrojar dos tipos de alarmas: alarmas clínicas y errores del equipo. Las alarmas clínicas se relacionan al estado del paciente, y éstas alarmas son generadas por el equipo de adquisición en cada uno de los monitores de signos vitales. Los errores del equipo están relacionados al funcionamiento de los dispositivos utilizados para la adquisición. Cada uno de los dispositivos genera distintos tipos de alarmas con formatos y contenidos diferentes. Dichas alarmas deben de derivar en una alerta audiovisual que se despliega en pantalla.

68 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Los mensajes de alerta contienen el identificador del sensor y el código de la alerta relacionados al mismo y un parámetro de prioridad. Estos mensajes permitirán que en el servidor se puedan mostrar alguna alerta audiovisual una vez analizando dicho paquete. El parámetro de prioridad, debe establecer que en caso de existir varias alertas, estas deben de cumplirse en base a dicha prioridad. Así un mensaje de alerta con una prioridad más alta que cualquier otro en la pila de alertas, debería de atenderse antes que los demás. Un ejemplo del contenido de un mensaje de alerta definido dentro de los paquetes de informa- ción del ventilador se muestra a continuación.

Alarmas Byte Detalle Tipo 1 103 Alarmas activadas 2 Cada bit representa el estado de una alarma. Si el bit correspondiente a una alarma es 1, la alarma esta activa. 0: Ventilación de emergencia 1: Presión máxima 2: Presión continuada alta 3: Baja presión de aire 4: Baja presión de oxígeno 5: Porcentaje del oxígeno menor al 18% 6: Baja carga de batería 7: Perdida de energía Alarmas activadas 3 0: Desconexión de circuito 1: Presión mínima 2: Volumen tidal máximo 3: Volumen tidal mínimo 4: Porcentaje de oxígeno bajo 5: Porcentaje de oxígeno alto 6: Condición de apnea 7: Falla de soplador Alarmas activadas 4 0: Fuga mayor a 50 L/min 1: Frecuencia máxima 2: Pérdida de PEEP 3: Volumen minuto máximo 4: Volumen minuto mínimo 5: Nebulización interrumpida 6: Baja presión de aire y oxígeno 7: No utilizado, siempre debe ser cero

Tabla 3.8: Tipos de alarmas arrojadas por el ventilador

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 69 3.11.2 Diseño de las interfaces gráficas

Inicio de sesión La pantalla de inicio de sesión consta únicamente de un formulario en el que es necesario introducir el nombre de usuario y contraseña, dar clic en el botón de Aceptar y serán dirigidos a otra pági- na en caso de corresponder correctamente – dependiendo del perfil que tengan asignados – o les será mostrado un mensaje de error, en el cual es necesario volver a introducir el nombre de usuario y con- traseña correctos para poder continuar.

Figura 3.31: Formulario de autenticación

70 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Registro Generalmente, los formularios de registro constan únicamente de campos de texto en los que es necesario introducir la información correspondiente para registrar un paciente, médico o enfermera en el sistema.

Figura 3.32: Formulario de registro genérico

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 71 Búsqueda Los formularios de búsqueda únicamente contienen un campo de texto con el cual se realizará la búsqueda dentro del nombre completo del paciente, médico o enfermera. El formulario de búsque- da permite posteriormente acceder a las opciones de visualizar, modificar o eliminar el registro completo de quien corresponde.

Figura 3.33: Formulario de búsqueda

72 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Central de enfermeras La pantalla de visualización de información consta de elementos comunes que se busca conser- var en la interfaz gráfica a lo largo del uso de la aplicación. Los elementos que podemos identificar en primera instancia, son las barras superior e inferior. La barra superior es informativa, puede mostrar parámetros como la hora, nombre del paciente u otra información relevante. La barra inferior es para navegación. Permite ,en el caso de utilizar monitores extendidos, visualizar el siguiente monitor o regresar al anterior o regresar al menú principal y acceder a la administra- ción de médicos, pacientes y enfermeras. Esta barra también esta considerada para incorporarse a las interfaces administrativas.

Figura 3.34: Distribución general de los elementos de la interfaz gráfica de la aplicación

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 73 Monitor global El monitor global permite visualizar todos los monitores de signos vitales de forma reducida, es decir, mostrando solamente el electrocardiograma; algunos parámetros numéricos y el nombre del paciente. Una vez seleccionando un monitor podemos acceder a su información extendida , es decir, al monitor de signos vitales extendido.

Figura 3.35: Monitor global y detalle de monitor reducido

74 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Monitor extendido El monitor extendido busca presentar la misma información que los monitores de signos vitales in situ. Los monitores extendidos presentan todas las gráficas y parámetros numéricos disponibles sobre la adquisición de signos vitales.

Figura 3.36: Distribución de elementos del monitor extendido

Otros elementos de la interfaz

Región de alarmas Se han planeado dos formas de mostrar las alertas. Una puede ser considerada como una alerta visual invasiva y otra no invasiva. En la alerta invasiva, buscamos que se muestre una pantalla o región por encima de todo lo de- más, que indique la existencia de una alarma y los detalles de la misma bloqueando a los demás elementos de la interfaz hasta no haber aceptado el aviso. En la alerta no invasiva, se busca que bajo la región de la barra superior o sobre la región de la barra inferior, se muestre un aviso de alerta conteniendo los detalles de la misma sin necesidad de blo- quear el acceso a los demás elementos de la interfaz.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 75 Figura 3.37: Visualización de alarmas

Mapa de navegación

Figura 3.38: Mapa de navegación de la aplicación

76 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 3.12 Resumen En este capítulo se han establecido los modelos de análisis y diseño de la aplicación lo que servi- rá de guía para iniciar el desarrollo del sistema. Se han establecido los escenarios y respecto a ésto las interacciones de los usuarios con el sistema. También se definió la arquitectura del sistema respecto a los subsistemas existentes y su emplazamiento en los dispositivos que participan en su funcionamien- to. Se determinaron la estructura de la base de datos y los diagramas correspondientes. Además se evaluaron los manejadores de bases de datos candidatos, en los cuales se consideraron términos de rendimiento en base a los resultados obtenidos en [GLO05], aunque en [POS07] se menciona que Oracle presenta un mayor rendimiento que cualquiera de ambas, se planea que si se llegara a presentar la necesidad debería de utilizarse dicho manejador. La incorporación de cualquier manejador no supone un esfuerzo adicional al ajustarse a la mayoría del estándar SQL. Se definieron también los formatos de mensaje y protocolos para la transmisión de información entre los monitores y el servidor de monitores. Además de las consideraciones en la interfaz gráfica y la estructura de navegación que estará disponible para los clientes Web. Es así como se ha optado por utilizar las siguientes tecnologías en el desarrollo de la aplicación: Para el desarrollo del monitor de signos vitales: Sistema Operativo: Microsoft Windows XP embedded edition Lenguaje de implementación del sistema : C++. Tecnología IPC: Sockets. Para el desarrollo del servidor de monitores: Encontramos en el servidor dos tipos de aplicaciones: aplicaciones de monitoreo y aplicaciones administrativas. Las primeras encargadas de interactuar con los monitores de signos vitales, obtener información y almacenarla y encaminarla a los clientes Web; las segundas se refieren a las aplicaciones necesarias para llevar la etapa administrativa Sistema Operativo: Basado en Linux. Lenguaje de implementación para aplicación de monitoreo: C++. Framework para el desarrollo de la aplicación administrativa: Grails (basado en el Spring Fra- mework MVC) Sistema Gestor de Bases de Datos: PostgreSQL. Para el desarrollo de las aplicaciones para clientes web: Páginas HTML, utilizando scripts de Javascript y los objetos XMLHttpRequest y Canvas para la transmisión de información y el dibujado dinámico de gráficas para el navegador Web.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 77

Capítulo 4 Desarrollo

“La suprema facultad del hombre no es la razón, sino la imaginación” Juan O'Gorman

4.1 Introducción En el capítulo anterior, se ha presentado el funcionamiento del sistema respecto a la adminis- tración de la información sin embargo, existen otros conceptos que no habían sido considerados en la etapa del diseño generalmente relacionadas con el uso de algunas tecnologías en niveles distintos a los ya presentados; así como también puede observarse la separación de elementos funcionales respecto al procesamiento de información, visualización, adquisición, almacenamiento y distribución a los clientes. En la figura 4.1 se muestra un diagrama general de los componentes del sistema y las tecnologí- as utilizadas

Figura 4.1: Diagrama General del Sistema de Monitoreo Web de Signos Vitales

79 Es así como se identifican las aplicaciones necesarias en el sistema para su funcionamiento, ade- más de un simulador que permitirá manejar el conjunto de funciones desarrolladas y probar su inte- gración con otras etapas del sistema. Para evitar confusiones en el nombramiento de las etapas, se ha decidido asignarles nombres particulares que permitan una mayor claridad al tratarse de distintos componentes del sistema.

Así pues, Amande (almendra) corresponde a la aplicación encargada de recopilar información de los monitores de signos vitales, almacenar alarmas y distribuir la información a los clientes web; cabe destacar que el conjunto de funciones (API) desarrollado para esta aplicación se denomina Châ taigne (castaña). Pistache es la aplicación encargada de administrar la información sobre los modelos de dominio de la aplicación, es decir: médicos, enfermeras, pacientes, monitores, alarmas y asignaciones de médicos, monitores y enfermeras. Finalmente Noisette (avellana) son el conjunto de scripts utilizados para obtener la información recopilada en Amande y mostrarla en una página web.

4.2 Amande Amande es la aplicación encargada de obtener información de los monitores de signos vitales mediante algún mecanismo de comunicación entre procesos – el cual se ha implementado por medio de sockets – y procesa la información ya sea almacenándola en la base de datos, o transmitiéndola a los clientes Web. También es la encargada de manejar los múltiples monitores de signos vitales que puedan conectarse al sistema además de los clientes Web. Las que podemos definir como tareas principales de éste módulo dentro del sistema son: ● La transmisión de información de los monitores de signos vitales al servidor Amande. ● El almacenamiento y procesamiento de información. ● La transmisión de información a clientes web.

4.2.1 Transmisión de información de los monitores de signos vitales al módulo Amande La transmisión de información no implica simplemente conectar un cliente y transmitir la in- formación en formato binario, pues es imprescindible conocer qué tipo de información voy a recibir, cuál es la cantidad de información; y un punto adicional que puede escapar a primera vista: el protocolo de conexión para identificar el monitor que quiere conectarse y permitir su conexión. Un servidor de signos vitales se conecta al servidor Amande y comienza a transmitir informa- ción de los sensores. Amande recibe un paquete en el que se encuentra la medición de un valor correspondiente a un sensor determinado. Dependiendo del tipo de información se determina si es necesario almacenarla o no. Los paquetes deben de mantener una cierta estructura que permita su correcta representación

80 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales en memoria tanto para el monitor de signos vitales como al servidor Amande; la definición de esta estructura y los demás conceptos relacionados a la aplicación que permitan el manejo de los paquetes forman parte del API Châtaigne desarrollado para el sistema. En el apéndice D se muestran los aspectos relacionados al protocolo de conexión y a la forma- ción y transmisión de paquetes tanto para el módulo Amande como para el simulador.

4.2.2 Châtaigne: API de propósito específico para el Sistema de Monitoreo Web de Signos Vitales Como se ha visto anteriormente, ha sido necesario crear un protocolo que defina la estructura con la que son transmitidos al servidor Amande los paquetes de información, así como también las rutinas para la serialización y deserialización de éstos paquetes para su transmisión en la red; sin embargo, esas no son las únicas rutinas relacionadas con la aplicación, pues también se han implementado aquellas relacionadas con el manejo de conexiones de los monitores, manejo de conexiones y transmisión a los clientes Web, además del almacenamiento en la base de datos. Las tareas correspondientes al API se definen como: ● Definición de la estructura que representa la información proveniente de los sensores y su asociación con una determinada categoría y sensor. ● Definición de la estructura de los módulos que permitan accesos a la base de datos ● Rutinas para la conversión de una estructura de información binaria en una representación útil para su transmisión sobre la red e incluso sobre protocolos basados en texto. Es así como el API Châtaigne junto con otras librerías forman la base para el desarrollo del servidor Amande. En la figura 4.2 se plantea el diagrama a bloques de Amande.

Figura 4.2: Diagrama de bloques de Amande: Servidor de monitoreo

Estructura de la información de los sensores La información proveniente de los sensores no se compone simplemente de un campo en el que se encuentre la información necesaria para realizar la gráfica y demás cálculos de un determinado signo vital, pues el sensor obtiene distintas variables que pueden servir para cualquiera de las dos tareas

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 81 mencionadas y es debido a ésto que la información obtenida puede caer dentro de distintas categorías o se encuentre asociada a alguna característica específica del signo vital. Un ejemplo de lo anterior es el de la información obtenida por el ventilador: La información obtenida puede estar compuesta por la información para el graficado en el tiempo de inspiración o en el tiempo de espiración; o bien puede representar la información numérica sobre el porcentaje de oxígeno, del flujo respiratorio, entre otros. Debido a los puntos anteriores, es necesario que un paquete de información mantenga tanto el valor de la medición así como también contenga información sobre dicha medición y el sensor al que corresponde dentro del monitor de signos vitales.

Estructura de los módulos del servidor Los módulos del servidor son las clases que utiliza el servidor Amande para realizar algunas operaciones específicas como pueden ser: el almacenamiento de las alarmas en la base de datos, el procesamiento de las éstas o su transmisión a los clientes Web. Las clases asociadas a un determinado tipo de sensor se agrupan y utilizan clases base similares, lo que permite la extensibilidad del sistema ya sea extendiendo clases nuevas de las clases base o modi- ficándolas incluyendo nuevas operaciones. En el caso de las clases que hacen uso de las librerías para el acceso al a base de datos, éstas deben implementar el uso de dicha librería o bien derivarse de una clase base que contiene los métodos necesarios, evitando a sí repetición en el código y además permitiendo que las modificaciones poste- riores sobre el acceso a la base de datos se modifiquen simplemente en esa clase.

Conversión de estructura binaria a representación en texto La serialización es un concepto que recientemente se ha utilizado bastante al buscarse la interoperatibilidad entre sistemas utilizando XML en SOAP o XML-RPC. La serialización se define como el proceso necesario para convertir un objeto a un formato que se pueda transportar o almacenar, siendo su complemento la deserialización, la cual convierte una secuencia determinada en un objeto. Si bien existen varias librerías que nos pueden permitir serializar un objeto determinado para su transmisión a otros sistemas, éstos mecanismos pueden no ser los más óptimos al introducir metain- formación a la trama de datos generando en algunos casos una secuencia más grande de información que la que originalmente era. Es por ello que buscamos serializarlo de una forma que nos permita mantener simplemente la información necesaria introduciendo una cantidad baja de información adicional que permita conocer el tamaño de la trama y los tipos de datos correspondientes. En el apéndice D se desarrolla más a fondo la estructura del protocolo y de la formación de paquetes, además de la serialización y deserialización involucrada en el API Châtaigne.

82 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Uso del API La formación de paquetes en el monitor sigue la estructura definida en los objetos establecidos. Se puede resumir la formación y transmisión de paquetes en los siguientes pasos: 1. Obtención de información de las tarjetas de adquisición (manejado por el monitor de signos vitales). En el caso del simulador pueden generarse señales de prueba (seno, coseno) o bien utilizar archivos de mediciones. 2. Creación de objetos relacionados a la información.

PISensor *x= new PISensor(informacion); o bien PASensor *xa= new PASensor(informacion_alarma);

3. Encapsulamiento de distintos paquetes de información o alarma en un contenedor.

ContenedorInformacion *ci= new Contenedor(); ci->add(x1);....ci->add(xn);

4. Serialización y transmisión

ci->serialize(); socket->Send(ci->serialize(), ci->tamaño);

En el servidor, se recibe el paquete formado por el tamaño del paquete y su contenido binario. Así pues la recepción de información necesita un búfer en el cual almacenar información hasta que pueda ser procesada. Suponiendo que se ha recibido la información completa, los pasos que realiza el servidor para procesar la información se resumen en los siguientes puntos: 1. Recepción de la información 2. Deserialización

ContenedorInformacion *ci= (new ContenedorInformacion())- >deserialize(info_recibida)

3. Procesamiento. En éste punto se conoce el contenedor de información y es posible extraer todos los paquetes de información o alarma contenidos en él. Así pues se tienen clases que procesan dicha información, es decir manejan los paquetes existentes en el contenedor.

Es necesario destacar que se consideran dos canales de comunicaciones: información y alarmas, por los cuales se transmitirán Contenedores que incluyan solamente paquetes de información o de alarma.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 83 Procesamiento de los paquetes En esta etapa del proyecto se considera el almacenamiento de las alarmas como actividad principal. Aquí también se incorporaron clases que permitieron la conexión a una base de datos y es in- corporada a una clase denominada ModuloAmande de la cual derivan todos los demás módulos de manejo o procesamiento de información que requieran acceso a la base de datos, utilizando los comandos siguientes:

this->connectDatabase() //Para iniciar la conexión //a la base de datos this->disconnectDatabase() //Para terminar la conexión //con la base de datos this->consultDB(char *) //Para realizar una consulta //u operación

Para almacenar información en la base de datos, cada módulo tiene que establecer sus propios parámetros, es decir la consulta, y los parámetros necesarios para realizarla. Generalmente al derivar de la clase ModuloAmande, se obtienen los métodos mencionados anteriormente.

Libpqxx: Librería de conexión a base de datos PostgreSQL La conexión a la base de datos se logró utilizando el API libpqxx para acceder a bases de datos PostgreSQL. Libpqxx es el API para clientes de PostgreSQL, utilizado para escribir aplicaciones que necesiten acceder a bases de datos administradas por postgres. Las librerías tienen una licencia BSD revisada, lo cual permite su incorporación en proyectos tanto de código abierto, como aplicaciones privativas. Se requiere agregar el parámetro -lpqxx para la compilación de la aplicación.

Almacenamiento de alarmas Ya que el sistema en general considera dos subsitemas, uno de monitoreo y uno administrativo, es necesario establecer una correspondencia en identificadores tanto en sensores como en los tipos de alarma registrados. Es decir, mientras en la aplicación de monitoreo se establece que el identificador para el sensor Electrocardiógrafo tiene un valor de 12, en la base de datos del sistema administrativo, se le ha asignado un un valor de 1. En la lista siguiente se muestran las correspondencias de dichos identificadores:

84 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Lista de sensores

Identificador Descripción del sensor BD C++ Electrocardiografo 1 12 Oxímetro 2 13 Capnógrafo 3 14 Ventilador 4 15 Presión No Invasiva 5 16 Presión Invasiva 6 17 Gastocardiaco 7 18 Temperatura 8 19

Así pues al recibir una alarma, el módulo relacionado en Amande se encargará de realizar la operación de inserción en la base de datos permitiendo que, conteniendo solamente unos cuantos campos de datos en el paquete de información, pueda relacionarse la alarma con la información pre- establecida en la base de datos. Por ejemplo, un paquete de alarmas del ventilador se compone solamente de 3 bytes en los cuales cada uno de sus bits representa una bandera o una posible alarma arrojada. Así, es posible transmitir en 3 bytes hasta 24 alarmas en un solo paquete. El servidor Amande recibe dicho paquete y al pro- cesarlo, introduce la información en la base de datos relacionando las alarmas con un determinado sensor y una determinada sesión de monitoreo – en la que se relaciona el paciente con un determinado monitor. Y al tener las descripciones de las posibles alarmas que puede arrojar un ventilador, éste puede mostrar la alarma completa al usuario.

4.2.3 Simulador El simulador es la herramienta utilizada para probar la generación de paquetes y su transmisión al servidor Amande; ésta herramienta usa también como base el API Châtaigne y mediante ésta genera los paquetes de información que son posteriormente transmitidos utilizando las herramientas provistas por el entorno de desarrollo Borland C++Builder. En la figura 4.3 se muestra el diagrama a bloques de la composición del simulador de monitores de signos vitales.

Figura 4.3: Diagrama de bloques del simulador

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 85 Ya que se han implementado las características de conectividad – las rutinas de sockets Linux – dentro de Châtaigne, y ésta son incompatibles con las establecias en Windows, fue necesario utilizar algún mecanismo que permita que el compilador las utilice en un sistema y no en otro, por ello se establece la necesidad de utilizar la directiva del preprocesador -DLINUX en la compilación del sistema en Linux. La tarea del simulador se reduce a simplemente utilizar las clases diseñadas para generar paquetes. Los paquetes generados por el simulador son unicamente los valores de una función matemática ajustada a unos ciertos valores umbral – para considerar todo el rango de valores posibles dependiendo del tamaño del paquete de datos – y el uso de dicho valor como contenido de un paquete de infor- mación el cual es introducido a un Contenedor de Información y es serializado. El contenedor serializado es transmitido al servidor de monitores Amande, y repite toda la operación durante un tiempo indeterminado. Además, el simulador también permite generar paquetes de alarma estableciendo los bits activa- dos y posteriormente transmitirlos al presionar un botón. Dichas características se consideran suficientes en el simulador para la prueba de las capacidades del sistema.

4.2.4 Consideraciones de desempeño El manejo de múltiples monitores dentro del sistema, es algo deseable; sin embargo la recep- ción y procesamiento de información de múltiples monitores simultáneos es una operación más compleja en el aspecto que hay que determinar el origen de la información y realizar las operaciones relacionadas con los paquetes transmitidos manteniendo una integridad en la información y permitiendo la correcta transmisión de todos los monitores; e incluso, se complica aún más al considerar también a los posibles clientes Web que pueden acceder a la información. Todas estas tareas implican el uso de mecanismos que permitan concurrencia y atacar los problemas inherentes a ella. El funcionamiento general del servidor Amande se divide en los siguientes pasos: 1. Se genera el proceso principal de la aplicación, el cual recibe las conexiones de los monitores de signos vitales y les asigna una estructura en memoria. 2. Se generan dos subprocesos que se encargan de vigilar constantemente si existe informa- ción disponible proveniente de los monitores de signos vitales. Un subproceso se relaciona a la información general y el otro a las alarmas. 3. Al obtener información, se genera un subproceso que procesa ese paquete de información y éste a su vez genera uno o más subprocesos que redirigen el paquete de información a los clientes Web conectados. Además existe otro subproceso encargado de recibir las conexiones de los clientes Web y les asigna una estructura en memoria además de un hilo que mantendrá activa la conexión por un momento determinado y lo cerrará tras haberse cumplido ese tiempo.

86 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Para poder asegurarnos que no exista algún problema al querer acceder a un recurso cuando éste sea modificado o eliminado, se utilizaron los sellos o cerrojos de exclusión mutua (mutex) los cuales permitirán que solo un proceso pueda modificarlo y tras haber realizado las operaciones sobre tal recurso, pueda entregar la propiedad a otro proceso. Existen una gran cantidad de recursos en el que se realizan observaciones sobre el diseño y desarrollo de aplicaciones para evitar que se puedan presentar esos problemas, sin embargo la problemáti- ca puede presentarse de dos formas: ● Un proceso externo interfiere en las acciones de otro proceso seguro (interno), ocasio- nando un mal funcionamiento en el sistema; generalmente éstos eventos pueden ser utilizan- dos por un atacante para causar el problema. ● La interferencia entre varios procesos seguros, se da al ejecutarse la misma rutina inten- tando acceder a los mismos recursos interfiriendo con el funcionamiento normal de éstos. De los principales problemas que se presentan – y que suelen presentar una gran complejidad en el desarrollo de sistemas concurrentes – son las que se consideran bajo condiciones de carrera y que pueden derivar en condiciones de deadlock o bloqueo mutuo en el que un proceso A espera un recurso que es utilizado por otro proceso B y éste a su vez espera que el proceso A libere el recurso. Los problemas relacionados con los procesos concurrentes pueden tener grandes repercusiones en el desempeño y confiabilidad del sistema, por lo que es de gran importancia realizar una gran cantidad de pruebas sobre el correcto funcionamiento de los sistemas evitando así que existan errores que no son descubiertos más que durante el uso constante de éstos.

4.2.5 Transmisión de información a clientes Web En la propuesta del sistema, se eligió el utilizar clientes Web como el motor para la interfaz grá- fica de la aplicación, pues puede ser vista como una máquina virtual – si bien no con todas las carac- terísticas de una, pero con algunas suficientes – que ha sido implementada en distintos sistemas operativos, dispositivos estáticos y móviles y, que debido a la inclusión de nuevas tecnologías de interfaces humano computadora, mejoras en las características de los dispositivos y sobre todo, por la incor- poración de Internet a nuestra vida cotidiana, presentan mejoras cada vez más complejas y eficientes para permitir utilizarlos como mecanismo encargado de manejar las vistas o interfaces gráficas en los sistemas. La primera problemática planteada por el uso de un navegador es que éstos responden a peticiones y respuestas bajo el protocolo HTTP, lo que ocasiona que un sistema – que requiera utilizar el navegador Web en la etapa de Vista dentro del modelo MVC – tenga que manejar dicho protocolo implementando características de servidores Web, extendiendo de clases que permitan dichas caracte- rísticas o buscar un mecanismo para interactuar con el servidor Web.

Inicialmente se establecía el desarrollo de módulos de Apache para obtener la información del

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 87 monitor Amande y dirigirla a los clientes Web sin embargo, la documentación de Apache a nivel de desarrollador es confusa y suele cambiar mucho entre versiones del servidor e incluso, llegan a depre- ciarse algunas funciones del API al cambiar entre subversiones. Lo cual , y tras investigar por alternativas, nos permitió considerar otros servidores que presentan en ocasiones un mejor rendimiento que Apache. El sistema Amande debe interactuar, entonces, con el servidor Web y transmitir la información proveniente de los monitores de signos vitales a los clientes Web que deseen acceder a ésta. Para realizar dicha transmisión y permitir que la información se transmita de una forma más directa, se plante- an algunas técnicas similares a las del streaming de audio y video.

Streaming Definimos streaming de datos como la capacidad de la aplicación para transmitir información al cliente web (navegador) utilizando una conexión persistente (keep-alive de HTTP), considerando que la información sigue un determinado formato y el cliente puede procesar dicha información y mostrarla. Ajax, es un conjuntos de tecnologías que utilizan como mecanismo de transferencia de infor- mación el objeto XMLHttpRequest, así pues, para poder utilizarlo, se sugiere utilizar el lenguaje XML para la transferencia de información, más no por ello es el único. Para una aplicación que realiza pocas peticiones de información utilizando un modelo de cone- xión/desconexión, XML puede ser una buena opción para la representación de los datos sin embargo, en nuestra aplicación es necesario: 1. Mantener una conexión abierta para transmitir un flujo de información 2. Transmitir la información en cierto formato que permita aprovechar las características de los navegadores para su procesamiento. Es por ello que se necesitan incorporar algunas técnicas que puedan permitirnos dichas caracte- rísticas.

Conexión persistente En teoría, una conexión persistente nos permite que ésta permanezca abierta hasta que se ha transmitido la totalidad de la información a un cliente. Ésto puede lograrse manteniendo un socket abierto y transmitiendo toda la información a un cliente web, cerrándolo al finalizar. Sin embargo al aplicar ésta solución se presentan unas ciertas limitantes: El paradigma inicial de las aplicaciones web se basaba en peticiones y respuestas únicas, es decir, el cliente realiza una petición por un cierto recurso al servidor y recibe una respuesta – figura 4.43. Un ejemplo de ello puede ser un formulario: Cuando uno llena un formulario y da clic en el botón de Enviar, ésta información es transmitida y recibimos – generalmente – una respuesta de que

3 Basada en la figura 2 presentada en www.uberbin.net/archivos/internet/ajax-un-nuevo-acercamiento-a-aplicaciones- web.php

88 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales nuestra información ha sido transmitida. Es así como el intercambio de información entre el cliente y el servidor se lleva bajo una petición inicial.

Figura 4.4: Modelo de transmisión en Internet

Se han ideado múltiples técnicas para transmitir información en un segundo plano (transmisión asíncrona) buscando evitar el cargar nuevamente toda una página para observar un cambio mínimo proveyendo así de una mayor interactividad o una mejor experiencia de usuario. El objeto XMLHttpRequest permite realizar dichas conexiones en segundo plano y procesar la respuesta del servidor utilizando JavaScript. Así pues, el cliente puede realizar las peticiones cada cier- to tiempo o mantener una conexión abierta esperando la información y procesándola en segundo plano con la siguiente restricción establecida por los navegadores: Las peticiones pueden ser realizadas úni- camente al servidor que contiene el mismo recurso que las solicita – ésto es para evitar que se lea informa- ción de otros servidores, sin embargo se ha trabajado para establecer políticas de acceso para dichos eventos [wAC08] y [wCX08]; así pues su manejo, se resume en la siguiente definición de la docu- mentación de Ajax en Prototype.js [wIA08]: “Recuerde que por razones de seguridad (ésto es prevenir ataques de cross-site scriptting) las peticiones Ajax sólamente pueden ser realizadas con URLs del mismo protocolo, servidor y puerto de la pági- na que contiene la petición Ajax. Algunos navegadores pueden permitir URLs arbitrarias, sin embargo no debería confiar en éste soporte”.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 89 Con ésto es más difícil realizar un método universal para acceder a recursos de otros servidores.

Una posible solución implicaría que la aplicación que provea la información también imple- mente características de un servidor Web, procesar las peticiones y responder a ellas utilizando el protocolo HTTP. Otra solución es que la aplicación resida en el servidor como una extensión de éste o bien utilizar ciertos métodos para sobrepasar las directivas de los navegadores – con lo cual se presenta la problemática de la diversidad de los navegadores y sus implementaciones para las políticas de seguridad.

Considerando las restricciones anteriores, la incorporación de una parte de la aplicación a un servidor es evidente; quedando así las siguientes opciones: 1. Utilizar alguna tecnología del lado del servidor como ASP, JSP, PHP, etc. 2. Utilizar extensiones del servidor 3. Utilizar CGI La primera y la tercera opción son muy similares, pues están basados en alguna aplicación que reside en el servidor y responde a las peticiones que lleguen a él, se procesan y éstos generan una respuesta en un determinado formato – generalmente HTML – el cual es redirigido por el servidor. La diferencia radica en la cantidad de aplicaciones adicionales que es necesario estar ejecutando para el procesamiento. ● ASP necesita ejecutarse sobre servidores IIS y , en su caso, utilizar el .NET Framework para poder funcionar. ● JSP y las tecnologías de Java necesitan ejecutarse sobre un contenedor de aplicaciones – como Tomcat, Jetty o Jboss – y el entorno de ejecución de Java para funcionar. ● PHP requiere de activar ciertos módulos en el servidor y descargar las aplicaciones necesarias.

Un CGI es simplemente una aplicación – programada en C, PERL, Python u otros lenguajes – que es cargada por el servidor en cada petición, cuyos flujos entrada/salida son manejados por el servidor y deben generar la salida indicada para las peticiones que le sean realizadas. Las extensiones del servidor permiten un mejor rendimiento al formar parte de éste, sin embargo suelen presentar más in- compatibilidades en su distribución, pues se utilizan librerías y funciones o llamadas específicas del servidor en cuestión. Entonces teniendo una tecnología establecida, es necesario establecer cómo se realizará la cone- xión con la aplicación del servidor de monitoreo para poder transmitir la información a los clientes, además es necesario saber que capacidades tenemos para el manejo de múltiples conexiones persistentes.

90 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Debido a las características de las tecnologías del lado del servidor respecto al consumo de memoria, no son consideradas. El desarrollo de módulos Apache es complicado al ser necesaria una gran cantidad de conocimiento sobre el servidor Apache HTTP a nivel de desarrollo, pues existen funciones que requieren de un API también diseñado por Apache para procesar la información y establecer entornos y variables que solo los desarrolladores de extensiones de Apache y de Apache mismo están familiarizados. Además, tras varias pruebas de memoria compartida y conexiones persistentes, se de- terminó que ésos factores pueden ser una gran limitante respecto al tiempo. El problema principal es que los recursos no son estáticos como un video o un archivo al que se desee acceder, si no que la información está cambiando constantemente, es por ello que no basta con un servidor o una aplicación “estática” que presentará ciertas respuestas definidas tras una determinada petición. Finalmente se optó por CGI y más aún por FastCGI, el cual es una extensión de CGI basado en un determinado protocolo, que permite la interacción con el servidor web funcionando éste como una pasarela pero dejando a la aplicación todo el control sobre el procesamiento de la petición y la respuesta. Además, evita la problemática de cargar una nueva instancia de la aplicación tras cada peti- ción del recurso. Así, la aplicación del servidor de monitoreo queda con otro puerto más en el cual se realizará la comunicación con el servidor web, evitando el tener que establecer la información en memoria compartida con el costo de que el servidor Amande debe de manejar todas las cuestiones relacionadas con las conexiones Web. Además, debido a sus bajos requisitos de ejecución, una extensibilidad y desempeño excepcio- nales y el soporte del protocolo FastCGI, se opta por utilizar el servidor Lighttpd [http://www.lighttpd.net/] – el cual es utilizado por una gran cantidad de proyectos que tienen una gran cantidad de tráfico como YouTube, para servir los videos y las imágenes miniatura, Flickr, entre otros.

FastCGI “FastCGI es una interfaz rápida, abierta y segura de un servidor Web que resuelve los problemas de desempeño inherentes a los CGI sin introducir ninguno de los nuevos problemas asociados a la escritura de las aplicaciones en las APIs de bajo nivel de los servidores Web. [...] Las consideraciones clave en el diseño de FastCGI incluyen la minimización del costo de migrar aplicaciones CGI soportando tanto programación de un solo hilo como la multihilo, soportando configuraciones distribuidas para la extensibilidad y alta disponibilidad y generalización de los roles que las aplicaciones de pasarela pueden ejecutar además del rol de “generador de respuestas” clásico de los CGI” [wFCG96]. El utilizar las librerías de FastCGI nos permite que el programa pueda tomar el rol clásico de un CGI utilizando las librerías fcgi_stdio.h, sin embargo al utilizar las librerías fcgiapp.h, la compatibilidad en el modo CGI se pierde, pero nos permite utilizar operaciones nuevas relacionadas con el manejo del objeto request. Al conectarse un cliente Web, el servidor lighttpd recibe la petición y la redirige al proceso que tiene asignado usando la extensión FastCGI; el proceso asignado recibe una petición en su puerto de escucha que está en espera usando la llamada FCGX_Accept_r. Ésta petición se obtiene en una estruc-

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 91 tura que mantiene la información de la petición misma y otros elementos adicionales, así pues la apli- cación será la encargada de leer la información de la petición (GET o POST), escribir la respuesta, forzar la limpieza del buffer del servidor Web al cliente – para efectos del streaming – y finalizar la co- nexión del cliente Web. Una vez teniendo las tecnologías óptimas para el ofrecimiento de conexiones persistentes con los clientes, es necesario también considerar el formato en el que se transmitirá la información.

Formato En un principio se estableció que el modelo que se utilizaría para el procesamiento de informa- ción en los clientes web, consideraba que los paquetes se definían en formato binario y eran transmitidos codificándolos previamente con el método Base64. Sin embargo el procesamiento de tales paquetes refleja un mayor uso de memoria necesaria por el intérprete Javascript en el navegador y, por consecuencia, en el rendimiento de la aplicación. Una situación similar surge al utilizar XML y tener que realizar un cierto procesamiento para poder obtener la información además, la cantidad de infor- mación necesaria para seguir el formato, es mucho mayor a la binaria – aunque el procesamiento puede ser más ligero al incorporarse rutinas para el manejo nativo de XML en los intérpretes Javascript. Considerando lo anterior, se opta por la Representación Nativa de Objetos en Javascript, Ja- vaScript Object Notation (JSON), lo cual nos permite aprovechar las funciones nativas de los intér- pretes – incluso el procesador nativo, para manejar la información más rápidamente con el equivalen- te costo del mayor tamaño de la trama – que con las velocidades actuales de las redes, y esperando unas mayores en el futuro, puede solventarse. JSON forma parte de la especificación ECMA-262, ECMAScript o mejor conocida como Ja- vascript. JSON, define una estructura similar a la de los arreglos en Javascript, y puede ser en ocasiones más ligera que el XML, aunque la característica que más nos interesa de JSON es la existencia de métodos para convertir un objeto serializado en un objeto para utilizarlo en Javascript sin necesidad de tener que crear rutinas para interpretarlo que consuman más recursos. La representación de un objeto que contiene la información de una persona se muestra a conti- nuación:

{ "nombre": "Juan", "apellido": "Sánchez", "direccion": { "calle": "Norte 43", "ciudad": "México", "estado": "Distrito Federal" }, "telefonos": [ "212 555-1234", "646 555-4567" ] }

92 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Puede observarse que el texto es legible por los humanos y al evaluarse en Javascript – mediante el método eval() – se crea un objeto del cual podemos obtener su información utilizando simplemente la notación punto (.); en el siguiente código puede verse utilizada la estructura anterior

var serializada= “{ "nombre": "Juan", "apellido": "Sánchez", "direccion": { "calle": "Norte 43", "ciudad": "México", "estado": "Distrito Federal" }, "telefonos": [ "212 555-1234", "646 555-4567" ] }” var Persona= eval(serializada); alert(Persona.nombre); // Arrojará una alerta con el // texto “Juan” alert(Persona.telefonos[0]); //Muestra “212 555-1234”

JAULA: API para manejo de objetos JSON en C++ Jaula, es un proyecto de código abierto para la codificación y decodificación de objetos JSON en flujos de datos. Permite generar objetos JSON y serializarlos; así pues en la implementación se ha optado por crear una clase controladora de los Contenedores de Información y que permitirá, dado un Contenedor, generar un objeto JSON para aprovechar la serialización en dicho formato para su posterior transmisión. Si bien el proyecto Jaula no ha presentado movimientos desde hace cierto tiempo, es lo suficientemente maduro como para hacer uso de él e implementarlo en el sistema. El siguiente código muestra la generación de un objeto JSON y varios elementos que pueden componerlo, como arreglos, objetos, valores numéricos, etcétera.

Value_Object contenedor; Value_Array paquetes; for (unsigned int i=0; i<5; i++) { Value_Object paquete; // Crea un objeto // temporal Value_Number tipo=(int)i; // Crea un elemento // número //Agrega un elemento entero paquete.insertItem("campo", tipo);

Value_Array arreglo; //Crea un arreglo for (unsigned int j=0; j<10; j++) { Value_Number id= j; arreglo.addItem(id);

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 93 } paquete.insertItem("nums", arreglo); paquetes.addItem(paquete); } contenedor.insertItem("paquetes", paquetes);

Al final, el objeto contenedor tendrá un elemento paquetes con 5 elementos paquete cada uno con un número llamado campo del 0 al 4 y con un arreglo de números llamado nums del 0 al 10. Es importante notar que en el desarrollo de los servidores web, se buscan mecanismos que permitan un menor consumo de la memoria, o respuestas más rápidas. Entre estos mecanismos, se encuentra uno muy común que permite almacenar las respuestas generadas por un CGI en cache y libe- rarlo cuando el CGI ha terminado de escribir, o bien aquellas que comprimen la información al transmitirla a los clientes web, estableciendo un parámetro para que el navegador se haga cargo de la decompresión al recibirla.

En Lighttpd, ésta configuración se establece en base a los tipos MIME que pueda proveer. Así pues, el tipo correspondiente a las páginas web (text/html) se comprimirá al transmitirse al cliente web; sin embargo éste es un comportamiento que no se desea al transmitir los paquetes JSON pues, es necesario definir el tipo MIME corresponiente a JSON y además queremos que al momento de que el servidor Amande transmita la información, inmediatamente se transmita a los clientes y no se almacene en el caché. Es por ello que en Amande, se establece el tipo mime de la respuesta, como application/json evitando así que el servidor web almacene la respuesta dependiendo del tipo mime, y se ofrezca el tipo de contenido correcto.

Manejo de la información en el cliente Generalmente el streaming maneja una técnica para asegurar mostrar la información – audio o video – de forma “natural” haciendo uso de un buffer. Así se obtiene una determinada cantidad de in- formación que asegure la reproducción del medio durante un cierto tiempo y se muestra al usuario. En nuestro caso el mecanismo utilizado puede residir tanto en el cliente como en la formación de paquetes en el servidor, estableciendo peticiones con un offset o mecanismos similares. El paquete contenedor de información, contiene las mediciones de los monitores de signos vitales; éstas pueden ser agrupadas durante un determinado tiempo y transmitidas al cliente web. Así podemos recibir una cierta cantidad de información y mostrar los elementos uno a uno cada cierto tiempo, con un comportamiento más natural para las señales. El problema en este aspecto, reside en que, ya que la información es recibida por partes, un contenedor pudiera no ser recibido en su totalidad, o bien podríamos recibir múltiples contenedores en un cierto tiempo. Por ello se propuso el separar los contenedores con un delimitador “#”, mostrando una estructura como la siguiente:

94 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales { "paquetes" : [ { "datos" : [ { "tipo_dato" : 105, "valores" : [ 255, 255, 255, 255, 255, 255 ] }, { "tipo_dato" : 105, "valores" : [ 71, 250, 71, 250, 71, 250 ] }, { "tipo_dato" : 105, "valores" : [ 163, 233, 163, 233, 163, 233 ] }, { "tipo_dato" : 105, "valores" : [ 144, 207, 144, 207, 144, 207 ] } ], "sensor" : 15, "tipo" : 2 } ] }#{ "paquetes" : [ { "datos" : [ { "tipo_dato" : 105, "valores" : [ 255, 255, 255, 255, 255, 255 ] }, { "tipo_dato" : 105, "valores" : [ 71, 250, 71, 250, 71, 250 ] }, { "tipo_dato" : 105, "valores" : [ 163, 233, 163, 233, 163, 233 ] }, { "tipo_dato" : 105, "valores" : [ 144, 207, 144, 207, 144, 207 ] } ], "sensor" : 15, "tipo" : 2 } ] }#{ "paquetes" : [ { "datos" : [ { "tipo_dato" : 105, "valores" : [ 255, 255, 255, 255, 255, 255 ] }, { "tipo_dato" : 105, "valores" : [ 71, 250, 71, 250, 71, 250 ] }, { "tipo_dato" : 105, "valores" : [ 163, 233, 163, 233, 163, 233 ] }, { "tipo_dato" : 105, "valores" : [ 144, 207, 144, 207, 144, 207 ] } ], "sensor" : 15, "tipo" : 2 } ] }#

Así, un contenedor estará completo en memoria al presentarse un “#”. En el recuadro anterior, podemos ver que lo obtenido en esta petición por el objeto XMLHttpRequest, contiene distintos contenedores separados por el delimitador, y que todos han sido recibidos completamente. El objeto XMLHttpRequest (XHR) no nos permite modificar su contenido, ni tampoco nos ofrece la capacidad de limpiar el buffer de información obtenido por su petición, además al tener cada vez una mayor cantidad de información en memoria, las aplicaciones se ralentizan. Es por ello que se planea manejar conexiones múltiples en las que cada determinado tiempo – ya sea establecido por el servidor o por el navegador – se libere la conexión y se cree una nueva, eliminando así de memoria el contenido del objeto XHR, la figura 2 muestra los posibles esquemas del manejo de objeto XHR.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 95 Figura 4.5: Esquemas de manejo del objeto XMLHttpRequest

En un principio se planteó la posibilidad de tener conexiones paralelas, en las que un objeto XHR obtuviera información y en un determinado tiempo, se creara otro objeto XHR que al comenzar a obtener la información del anterior, liberaba éste último hasta que nuevamente al transcurrir cierto tiempo, fuera liberado por uno nuevo. El problema encontrado en éste modelo se presenta al interactuar con el servidor: El servidor limita las conexiones de la misma fuente al mismo recurso lo que representa que el cliente web no puede tener dos conexiones al mismo recurso del navegador al mismo tiempo. Por lo tanto, se plantea el escenario en que tras eliminarse un objeto XHR, se cree otro y se mantenga así una sola conexión para el navegador.

4.2.6 Posibles mejoras El manejo del buffer en Amande no ha sido el mejor acercamiento, pues en ocasiones – más generalmente cuando los paquetes de información provenientes de los monitores de signos vitales son más grandes que el buffer disponible – el contenedor de información recibido se encuentra incomple- to y necesita una segunda transmisión. Sin embargo al manejar un solo buffer, éste paquete se mezcla con los provenientes de los demás monitores, lo cual ocasiona que no pueda deserializarse ni éste ni los demás. Otra mejora se refiere a la planificación o despliegue de procesos en el momento de la distribu- ción de los paquetes. Ya que cada uno serializa cada vez, puede ser necesario esa serialización si se realiza sólamente una vez y también sólamente se crean los procesos necesarios y no los de todos los clientes Web. Sería útil que la asignación de pacientes pudiera hacerse desde el monitor de signos vitales a di-

96 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ferencia de como se maneja desde la aplicación administrativa. Sin embargo esto implica que ha de modificarse el protocolo de conexión o bien han de agregarse nuevos comandos que nos permitan obtener la lista de los pacientes disponibles y también para realizar la asignación. Respecto a la extensibilidad del sistema, si se desea manejar otro manejador de base de datos, es necesario encontrar las librerías que nos permitan acceder a éste. Y modificar las clases que acceden a la base de datos. Podría ser conveniente el mejorar dichas clases para abstraer las funciones necesarias en ModuloAmande y simplemente realizar llamadas a ésta y no manejar objetos de la librería libpqxx dentro de las derivadas de ModuloAmande. Algo que sería sumamente interesante es la de la definición de los sensores en algún archivo de configuración o de extensión en XML o JSON, en el que simplemente se definan longitudes, constantes, y las asignaciones de los tipos de paquetes. Sin embargo puede hacer más complejo el sistema al generar incluso clases en tiempo de ejecución y proveer una integración más pobre con un IDE.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 97 4.3 Noix: Sistema Web

Anteriormente se ha establecido que el servidor web seleccionado para la aplicación es Lighttpd. Éste ha sido elegido gracias a sus características respecto al rendimiento y a la capacidad de utilizar FastCGI como mecanismo de comunicación con otras aplicaciones, lo que nos permite manejar las peticiones de los clientes Web desde el servidor Amande. Entre otras características, Lighttpd también puede funcionar como proxy, equilibrando las peticiones que se realicen y dirigiéndolas a otros servidores en base a distintas políticas de balanceo de carga, como la Round-Robin. En esta aplicación no es necesario establecer políticas de balanceo, pero pudieran ser convenientes en un sistema más complejo como en un Sistema de Información Hospita- lario. Sin embargo, el sistema está también compuesto por el módulo de administración de informa- ción donde los médicos y enfermeras podrán registrar nuevos pacientes y asignaciones; además, tam- bién se maneja como módulo la etapa encargada de realizar las conexiones al servidor Amande y proveer de interactividad a la aplicación en la capa de Vista. En la figura 4.6 se representan los módulos que componen la etapa Web.

Figura 4.6: Diagrama de bloques de Noix: Sistema Web

4.3.1 Pistache Pistache es la aplicación encargada de la administración de los modelos de dominio de la aplica- ción: enfermeras, médicos, pacientes, alarmas, monitores y las asignaciones, entre otros. Dentro de las capacidades de éste sistema están la de proveer de información a las páginas web en formato JSON cuando sea necesario y manejar la seguridad o control de accesos.

98 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Aplicaciones en Grails En el capítulo anterior se manejaron los pasos necesarios para la creación de una aplicación en Grails, cumpliendo anteriormente con los requisitos establecidos para su ejecución – como son el contar con una instalación correcta del kit de desarrollo de Java principalmente. Los modelos de dominio también han sido manejados en el capítulo anterior, sin embargo para una mejor comprensión de los términos, es recomendable revisarlos en el apéndice correspondiente. El desarrollo de la aplicación supone un problema de conocimiento del sistema y más aún del lenguaje utilizado en Grails llamado Groovy. Con éste lenguaje se definen los modelos de dominio y los controladores los cuales por convención están relacionados con una vista o página GSP nombrado de la misma forma que el método en el controlador. En el siguiente listado se muestra el código del modelo de dominio del Paciente.

class Paciente{ String nombres String apellidoPaterno String apellidoMaterno String sexo Date fechaNacimiento Float peso Float estatura String calle Integer numero String colonia String estado String delegacion String CP String telefono String tipoSangre

String toString(){ apellidoPaterno.toUpperCase()+" "+apellidoMaterno.toUpperCase()+", "+nombres } int edad() { (new Date()).getYear()-fechaNacimiento.getYear() }

static hasMany=[asignacion:AsignacionMedicoPaciente]

static constraints = { nombres(size:0..100) apellidoPaterno(maxSize:20) apellidoMaterno(maxSize:20) sexo(inList:["M", "F"]) calle(size:0..30) colonia(size:0..30) estado(size:0..20) delegacion(size:0..30) CP(size:0..5)

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 99 telefono(size:0..10) tipoSangre(size:0..3, inList: "A+","B+","AB+","O+","A-","B-","AB-","O-"]) } }

Siguiendo el modelo MVC, el modelo de dominio está relacionado con la información existente en la base de datos, y representa la abstracción del concepto que se desea incorporar en el sistema. Dentro de la abstracción o definición del modelo, también Grails nos permite establecer las correspondencias en las relaciones con otros modelos, las restricciones del modelo para validaciones y su correcto almacenamiento, así como también nos permite crear métodos que nos permita obtener una mayor información sobre el dominio aunque no esté relacionado directamente con la base de datos. Es conveniente rescatar que siguiendo la filosofía de la “Convención sobre la configuración”, al definir los modelos de dominio, se realiza automáticamente el Mapeo Objeto-Relacional (ORM) con la base de datos que se haya configurado, con lo cual se observa que es más importante establecer correctamente el diseño del sistema más que comenzar con el diseño de la base de datos.

El controlador se encarga de realizar las operaciones de interacción del modelo de dominio con el entorno de la aplicación. Es decir, incorpora las operaciones para registrar, eliminar, modificar y demás operaciones en las que tengan que realizarse sobre los modelos. En el siguiente listado se muestra el código del controlador de paciente.

import grails.converters.JSON class PacienteController {

def index = {redirect(action: list, params: params)}

// the delete, save and update actions only accept POST requests def allowedMethods = [delete: 'POST', save: 'POST', update: 'POST']

def list = { if (!params.max) params.max = 10 [pacienteList: Paciente.list(params)] }

def show = { redirect(action: view, id: params.id) //[ paciente : Paciente.get( params.id ) ] }

def delete = { def paciente = Paciente.get(params.id) if (paciente) { paciente.delete() flash.message = "paciente.deleted"

100 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales flash.args = [params.id] flash.defaultMessage = "Paciente ${params.id} deleted" redirect(action: list) } else { flash.message = "paciente.not.found" flash.args = [params.id] flash.defaultMessage = "Paciente not found with id ${params.id}" redirect(action: list) } }

def edit = { def paciente = Paciente.get(params.id)

if (!paciente) { flash.message = "paciente.not.found" flash.args = [params.id] flash.defaultMessage = "Paciente not found with id ${params.id}" redirect(action: list) } else { return [paciente: paciente] } }

def update = { def paciente = Paciente.get(params.id) if (paciente) { paciente.properties = params if (!paciente.hasErrors() && paciente.save()) { flash.message = "paciente.updated" flash.args = [params.id] flash.defaultMessage = "Paciente ${params.id} updated" redirect(action: show, id: paciente.id) } else { render(view: 'edit', model: [paciente:paciente])

} } else { flash.message = "paciente.not.found" flash.args = [params.id] flash.defaultMessage = "Paciente not found with id ${params.id}" redirect(action: edit, id: params.id) } }

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 101 def create = { def paciente = new Paciente() paciente.properties = params return ['paciente': paciente] }

def save = { def paciente = new Paciente(params) if (!paciente.hasErrors() && paciente.save()) { flash.message = "paciente.created" flash.args = ["${paciente.id}"] flash.defaultMessage = "Paciente ${paciente.id} created" redirect(action: show, id: paciente.id) } else { render(view: 'create', model: [paciente: paciente]) } }

def view = { [paciente: Paciente.get(params.id), alarmas: Alarma.findAll('from Alarma as a where a.asignacion.paciente.id=' + params.id)] }

def json = { render Paciente.get(params.id) as JSON }

def json_from_monitor = { def asignacion= Paciente.find("from Paciente as p where p.id= (select asig.paciente.id from AsignacionMonitorPaciente as asig where asig.monitor.id="+params.id+")") render asignacion as JSON } }

En el controlador encontramos los métodos para listar, mostrar, editar, eliminar, actualizar, ver y transformar a formato JSON. Los últimos tres métodos no son generados de forma automática, pues éstos se han definido para poder recopilar información específica sobre el paciente o bien realizar una función distinta. Otro punto que hay que remarcar son los enunciados que tienen una forma similar a esta:

[pacienteList: Paciente.list(params)]

éstos, permiten realizar la asignación de un modelo en específico en el entorno del GSP correspondiente a su vista. Así, en ésta línea se hace la asignación de una variable llamada pacienteList la cual está compuesta por la lista de Pacientes en el sistema. Otro método que no está relacionado di-

102 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales rectamente con una vista GSP, es el método render. Éste permite representar en texto un determinado objeto y además utilizando un convertidor, nos permite obtener la información en un formato es- pecífico. En el controlador de pacientes, la vista en formato JSON de un paciente se hacen con las lí- neas:

def json = { render Paciente.get(params.id) as JSON }

Es importante notar también las sentencias utilizadas en la última operación del controlador.

La primera línea define una nueva operación y su nombre: json_from_monitor. La siguiente línea define la variable asignacion, con el contenido de todos los pacientes encon- trados con la búsqueda: “de los pacientes, obtenido cada uno con nombre p, donde el identificador de p sea igual al identificador del paciente de una asignación de todas las existentes en AsignacionMo- nitorPaciente nombrada como asig, donde el identificador del monitor de la asignación sea igual al elemento id de los parámetros de la consulta”. Al final, el resultado será mostrado como JSON. El lenguaje de la consulta es muy similar a SQL, sin embargo presenta algunas diferencias inherentes al manejo de objetos, gracias a que la capa ORM se establece sobre Hibernate, e Hibernate ocupa una mo- dificación del lenguaje SQL denominada HQL. Así pues, se han considerado los siguientes modelos de dominio:

Alarma Representa una alarma de cierto tipo de alarma (TipoAlarma) generada en un monitor (Monitor) haciendo referencia a una determinada asignación en un momento específico. AsignacionEnfermeraPaciente Representa la asignación de un paciente a una determinada enfermera. Almacena también la fecha de la asignación. AsignacionMedicoPaciente Representa la asignación de un paciente a un determinado médico Almacena también la fecha de la asignación. AsignacionMonitorPaciente Representa la asignación de un paciente a un determinado monitor. Almacena también la fecha de la asignación. Ésta asignación permite el correcto almacenamiento de las alarmas. Enfermera Representa la información de una enfermera. Para efectos de éste sistema, se utilizará simplemente el nombre completo.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 103 Médico Representa la información de un médico. Para efectos de éste sistema, se utilizará simplemente el nombre completo. Monitor Representa la información de un monitor. En este caso se usará el identificador del monitor y el número de cama en el que se encuentra asignado. Paciente Representa la información de un paciente. Considera el nombre completo, su dirección, teléfono, fecha de nacimiento, peso y estatura. Rol Se refiere al manejo de los roles existentes en el sistema. (Administrador, Médico y Enfermera) Sensor Representa los sensores existentes en el sistema. TipoAlarma Representa los posibles tipos de alarmas existentes en el sistema asociado a un determinado Sensor. Usuario Representa los usuarios existentes en el sistema.

Ya que Hibernate se encarga del ORM, es necesario establecer la información sobre la base de datos a utilizar, el controlador de conexión y el nombre de usuario y contraseña de acceso a las mismas. Para especificar los parámetros de la conexión con la base de datos, se modifica el archivo Data- Source.groovy. En el apéndice E se muestra la configuración del entorno de Grails. El modelo relacional de la aplicación se muestra en la siguiente figura:

104 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 105 Seguridad: Control de Accesos Como se ha visto en algunos de los modelos presentados anteriormente, en esta actividad tam- bién se han incorporado esquemas de seguridad utilizando el plugin de Grails: Acegi. Éste basa sus políticas en un archivo de configuración que el control de acceso a las rutas definidas asignados a los perfiles de los usuarios, utilizando la directiva RequestMapString dentro del archivo AcegiConfig.groovy:

requestMapString = """ CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /login/**=IS_AUTHENTICATED_ANONYMOUSLY /medico/**=ROLE_ADMINISTRADOR /enfermera/**=ROLE_ADMINISTRADOR,ROLE_ENFERMERA /sensor/**=IS_AUTHENTICATED_FULLY """

En este caso, se establece que el controlador de login – y todas las vistas asociadas, son accesibles por cualquier usuario sin una previa autenticación. Más no es así para el controlador de médico y enfermera, los cuales sólo pueden ser accedidos siendo ADMINISTRADOR y además el controlador de enfemera puede ser accedido también por los usuarios con el rol ENFERMERA. En el caso del controlador de sensor, éste puede ser accedido por cualquier usuario que haya sido previamente autenticado.

106 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales La tabla de control de accesos se muestra a continuación:

Rol Administrador Médico Enfermera Operaciones Crear/Registrar x x x Borrar x x x Actualizar x x x Paciente Ver/Mostrar x x x Crear/Registrar x x x Borrar x x Actualizar x x Médico Ver/Mostrar x x Crear/Registrar x x x Borrar x x x Actualizar x x x

Enfermera Ver/Mostrar x x x Crear/Registrar Borrar Automático en el sistema. Actualizar Monitor Ver/Mostrar x x x Crear/Registrar Automático en el sistema Borrar Al arrojarse alarmas en el sistema, se Actualizar deben de almacenar en la base de datos Alarma Ver/Mostrar x x x Crear/Registrar Automático en el sistema Borrar Los sensores y sus identificadores Actualizar serán asignados de forma Sensor automática Ver/Mostrar Crear/Registrar Automático en el sistema Borrar Los tipos de alarmas y sus Actualizar identificadores serán asginados de

TipoAlarma forma automática Ver/Mostrar Crear/Registrar x x x Borrar x x x

iente Actualizar x x x

Asginación Asginación Ver/Mostrar x x x Enfermera/Pac Crear/Registrar x x Borrar x x

nte Actualizar x x Asignación Asignación

Médico/Pacie Ver/Mostrar x x x Crear/Registrar x x x Borrar x x x

nte Actualizar x x x

Asignación Asignación Ver/Mostrar x x x Monitor/Pacie Internacionalización (i18N) También se establecieron las plantillas de internacionalización para la aplicación en las cuales los elementos de la vista en lugar de contar con un texto en específico, se asigna una variable cuyo valor es cargado por la aplicación al determinar el idioma preferido del navegador.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 107 4.3.2 Noisette Pistache maneja la información en la base de datos y presenta una interfaz homogénea a la apli- cación, además permite el acceso a la información de la base de datos y su integración para su uso real. Pistache provee de las características de control de accesos al sistema y permite la administración de información sin embargo, la información obtenida por el servidor Amande se visualiza en scripts externos a Pistache, buscando un poco su independencia y un mejor rendimiento al ser provisto por el servidor Web y no por un contenedor de aplicaciones. Noisette es el conjunto de scripts utilizados para realizar las conexiones al servidor Amande y de procesar la información y visualizarla en la página Web; Noisette contempla también de los archivos de estilo visual y recursos adicionales que permitan mantener la homogeneidad en el aspecto visual y características interactivas. Para ello, Noisette se compone de un API que permite manejar algunos elementos de la interfaz de una forma más sencilla que la utilizada normalmente. La figura 4.7 muestra el diagrama a bloques del módulo Noisette.

Figura 4.7: Diagrama de bloques de Noisette

Las tareas del módulo o scripts Noisette, se dividen en: ● Manejar los elementos de la interfaz gráfica ● Obtener y procesar la información del servidor Amande

Manejo de elementos de la Interfaz Gráfica El API de la aplicación Noisette se encarga de manejar elementos como la barra de estado, las consolas o regiones de alertas y el dibujado de los objetos Canvas. Utiliza el framework Prototype.js para el acceso a los elementos HTML y el manejo de conexiones Ajax, y el framework Script.aculo.us para las animaciones de algunas regiones. Protoype.js nos permite utilizar clases en Javascript de una forma más sencilla que la de utilizar el patrón Factory que normalmente se usa al querer manejar objetos propios. Así la definición de clases se reduce a la creación de una clase y su consiguiente definición, por ejemplo:

var StatusBar = Class.create(); StatusBar.prototype = { elementos:new Array(), divDomId:"",

108 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales initialize: function(divId){ this.divDomId = divId; }, addItem:function(item){ this.elementos.push(item); this.update(); }, ... , update:function(){ var cadena=""; this.elementos.each(function(item){ cadena=cadena+"

"+item.contenido+"

"; }); cadena= "

"+cadena+"

"; //alert(cadena); Element.replace(this.divDomId, cadena); } };

Las clases que nos permiten manejar elementos de la interfaz gráfica, incorporan su definición de clase y las rutinas necesarias para realizar modificaciones sobre la Vista. Para ello, es necesario asignarle una región div en la página HTML o GSP en la que se desee incorporar; los métodos de la clase utilizan rutinas para reemplazar el contenido del div e incorporar los cambios generados por la clase, relegando la responsabilidad del div a ella y no necesitando de algún código externo para modificarlo. Por ejemplo, el incorporar un nuevo elemento en la barra de estado, se reduce a agregar la linea siguiente en cualquier región del código

barraEstado.addItem({id:"icono",contenido:"Finalizar sesión"});

En la que solamente es necesario agregar un arreglo con el identificador que se utilizará en el arreglo interno de elementos de la barra de estado y el código del elemento a introducir.

Estilo Visual Si bien el manejo de los elementos visuales recae en los scripts que usan como motor Prototy- pe.js, los aspectos visuales en cuanto a colores, imágenes, dimensiones de las regiones, etc; son maneja- das utilizando hojas de estilo en cascada, Cascade Style-Sheets (CSS); permitiéndonos realizar modificaciones del tema modificando únicamente la estructura de dichos archivos y promoviendo que puedan existir otros estilos visuales que se ajusten a las necesidades de los usuarios. El estilo visual desarrollado busca mantener un buen contraste y una consistencia en toda la aplicación.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 109 Obtención y procesamiento de información del servidor Amande La implementación de la obtención de información también se manejo mediante el objeto correspondiente provisto por Prototype.js: Los objetos Ajax.Request y Ajax.PeriodicalUpdater. Los objetos Ajax.Request y Ajax.PeriodicalUpdater, manejan una estructura similar en su uso, con la diferencia que el segundo realiza una conexión periódica. El constructor de un objeto Ajax presenta una estructura similar a la siguiente:

new Ajax.PeriodicalUpdater('products', '/some_url', { method: 'get', insertion: Insertion.Top, frequency: 1, decay: 2 });

Incluso es posible introducir manejadores de los posibles eventos que se presentan durante la conexión: onSuccess, onFailure, onUninitialized, onLoading, onLoaded, onInteractive, onComplete y onException. Por ejemplo la inclusión de los manejadores de eventos implica solo agregarlos dentro de los parámetros opcionales del objeto.

new Ajax.Request('/some_url', { method:'get', onSuccess: function(transport, json){ alert(json ? Object.inspect(json) : "no JSON object"); } });

Así, tras recibir un flujo de información, éste es procesado y se obtienen los paquetes que contiene, para así deserializar el objeto JSON – utilizando la función evalJSON() de Prototype.js – y poder utilizar su información para graficarla o modificar algún campo de la Vista.

Dibujado en el objeto Canvas El uso de un objeto canvas implica la existencia de dicho objeto en el documento HTML y de la inicialización del contexto para comenzar el dibujado. Si bien el código necesario para realizar los pasos mencionados no es muy complejo, al utilizarlo en distintos puntos conviene encapsularlo en una clase, además de traer como ventaja el poder modificar los criterios del graficado en todas las ins- tancias de dicha clase. El código que define la clase se enlista a continuación – cabe destacar que los parámetros de ini- cialización consisten del identificador del objeto canvas dentro del documento y las dimensiones de dicho objeto:

110 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales var Canvas = Class.create(); Canvas.prototype = { width: 400, height: 200, cx: 0, pasoX: 5, cy: 75, px: 0, py: 75, color: "#FFFFFF", ctx: null, initialize: function(idCanvas, w, h){ this.width= w; this.height= h; var canvas = null; canvas=$(idCanvas); if(canvas!=null) { canvas.style.width= w; canvas.style.height= h; }else alert("no se asignó el objeto canvas idCanvas:"+idCanvas); this.cy= this.height/2; this.py= this.cy; if (canvas.getContext) { this.ctx = canvas.getContext('2d'); this.ctx.strokeStyle = this.color; this.ctx.beginPath(); this.ctx.moveTo(this.px, this.py);

} }, grafica: function(puntoY){

//Establece el punto en el canvas this.px = this.px + this.pasoX; this.py = this.cy + puntoY; this.ctx.lineTo(this.px + this.cx, this.py); this.ctx.stroke(); if ((this.px % this.width) == 0) { //limpiamos pantalla this.ctx.closePath(); this.ctx.fillStyle = "Black"; this.ctx.fillRect(0, 0, this.width, this.height);

this.ctx.beginPath(); this.cx = this.cx – this.width; this.ctx.moveTo(this.px + this.cx, this.py); } } }

Finalmente su uso se reduce a utilizar el método grafica del objeto donde se quiera dibujar el punto.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 111 4.3.3 Mapa de sitio Tomando en cuenta las aplicaciones que forman parte de Noix, en la figura 4.8 se presenta la estructura y distribución de los componentes Web dentro de la aplicación y los contenedores relacionados.

112 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Figura 4.8: Mapa de Sitio

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 113

Capítulo 5 Conclusiones y Trabajos Futuros

El área de Telemedicina es un área poco explotada posiblemente debido a que la cantidad de conocimientos y requerimientos que son necesarios para poder llevar a cabo sistemas de información hospitalarios y soluciones médicas, son muy exigentes. En ocasiones uno no está preparado para hacer frente a sistemas cuya complejidad puede ser amplia al tener requisitos muy estrictos en tiempo de respuesta y ésta además deba de actuar de forma correcta en base a los eventos que se presenten con los pacientes; e incluso, el considerar que en sistemas como éste y otros más en los que se involucran vidas de personas o grandes cantidades de dinero es uno de los factores primordiales para los desarrolladores o proveedores de soluciones. Sin embargo, el desarrollo en el área presenta un gran nicho de mercado no sólo para el área de Telemática si no para cualquier área que pueda brindar soluciones médicas. El presente trabajo establece algunas de las bases o consideraciones respecto a la inclusión de tecnologías Web en aplicaciones de monitoreo y que pueden ser extendidas no sólo al monitoreo de signos vitales si no a el monitoreo de otros elementos que pueden tener requisitos no tan exigentes como pudieran ser las de el área médica. Además, ofrece información sobre las experiencias y posibles soluciones que pueden aplicarse en desarrollos relacionados o con transmisión de información en Streaming y su procesamiento en un cliente Web utilizando las técnicas soportadas por los navegadores actuales, tomando en cuenta que las prestaciones de los dispositivos móviles tienden a hacer de és- tos terminales en las que el acceso a Internet permita manejar toda nuestra información en línea, en las que el procesamiento de información y provisión de aplicaciones sea manejada por servidores en los cuales cada vez deben cuidarse más la optimización de recursos y mejora de sus capacidades tanto en el desarrollo de sistemas como en la integración del hardware.

115

Apéndice A Modelos de Caso de uso

A.1 Administración de pacientes La administración de pacientes engloba las operaciones de registro de pacientes, asignaciones de monitores, modificación de información y eliminación de su registro en el sistema.

ID Caso de uso: CU.S.Admin.1 Nombre de Caso de Uso: Administración de pacientes Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Es el caso de uso correspondiente al registro, modificación y eliminación de un paciente de la base de datos del sistema. Disparador: Selección de la opción Administración de pacientes dentro de las opciones de Administración. Precondiciones: El administrador debe haber accedido al menú de administración autenticándose en una pantalla inicial. Deben de existir médicos y enfermeras registrados previamente en el sistema, así como también deben existir monitores activos y disponibles. Poscondiciones: Al registrarse un paciente se almacena la información necesaria para establecer su expediente médico. Flujo Normal El Administrador al seleccionar la opción de Administración de pacientes, le son mostradas las opciones de Registrar paciente, Modificar información del paciente y Dar de baja el paciente, además de las opciones para volver al menú anterior. Flujos Alternativos: Cancelación de la operación.

Tabla A.1: Caso de uso Administración de pacientes

117 Figura A.1: Diagrama de casos de uso de Administración de pacientes

118 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ID Caso de uso: CU.S.Admin.1.1 Nombre de Caso de Uso: Registrar paciente Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Operaciones necesarias para registrar un paciente en el sistema. Disparador: Selección de la opción Registrar Paciente dentro de las opciones mostradas por Administración de pacientes. Precondiciones: Hay monitores disponibles y registrados en el sistema. Poscondiciones: El paciente ha sido registrado en el sistema. Ahora es posible asignar un monitor al paciente. Flujo Normal 1. El administrador introduce la información personal del paciente en un formulario. 2. El sistema verifica la integridad de la información, que los datos estén completos y correctos. 3. El sistema verifica que el paciente no se encuentre previamente registrado y lo almacena en la base de datos. 4. El sistema le asigna automáticamente un identificador y muestra un mensaje en pantalla conteniendo un mensaje de “Registro exitoso”. 5. El Administrador asigna un monitor disponible al paciente. Flujos Alternativos: 1. Paciente registrado previamente 1.1.Si el paciente ha sido registrado previamente, se muestra un mensaje de “Paciente registrado anteriormente. Verifique la información introducida” 1.2.El Administrador modifica la información o cancela la operación. Extensiones: Asignar monitor Notas:

Tabla A.2: Caso de uso Registrar paciente

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 119 ID Caso de uso: CU.S.Admin.1.2 Nombre de Caso de Uso: Modificar información de paciente Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Permite modificar la información registrada del paciente Disparador: Selección de la opción Modificar información de paciente dentro de las opciones de Administración de pacientes. Precondiciones: Existen pacientes registrados previamente. Poscondiciones: La información del paciente será actualizada en el sistema. Flujo Normal 1. El Administrador busca un paciente – se utiliza el caso de uso correspondiente. 2. Se presenta el formulario con la información obtenida del paciente. 3. El Administrador introduce la nueva información. 4. La información es validada por el sistema para verificar esté completa y sea correcta. 5. El sistema guarda los cambios Flujos Alternativos: 1. El paciente no existe en el sistema Dicha secuencia se encuentra en el caso de uso buscar paciente. Inclusiones: Buscar paciente Notas:

Tabla A.3: Caso de uso Modificar información de paciente

120 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ID Caso de uso: CU.S.Admin.1.3 Nombre de Caso de Uso: Eliminar paciente Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Operaciones necesarias para eliminar la información de un paciente del sistema. Disparador: Selección de la opción Eliminar paciente de las opciones de Administración de Pacientes. Precondiciones: Existen pacientes registrados en el sistema Poscondiciones: La información del paciente seleccionado será eliminada del sistema. Flujo Normal: 1. El Administrador busca el paciente 2. Se muestra una pantalla al Administrador confirmando la eliminación del paciente seleccionado del sistema. 3. El sistema pregunta por la contraseña de administrador. 4. El administrador introduce su contraseña 5. El sistema confirma la contraseña y elimina al paciente del sistema y muestra al usuario un aviso indicando que “el paciente ha sido eliminado del sistema”. Flujos Alternativos: 2. El paciente no existe en el sistema Dicha secuencia se encuentra en el caso de uso buscar paciente. Inclusiones: Buscar paciente Notas: Ésta opción solo podrá ser ejecutada en caso de que sea estrictamente necesario eliminar la información, ya que conforme a [NOM99], el expediente médico deberá conservarse un mínimo de 5 años. Debe considerarse antes la modificación de la información en caso de existir errores en la información del paciente y no eliminarse.

Tabla A.4: Caso de uso Eliminar Paciente

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 121 ID Caso de uso: CU.S.Admin.1.3 Nombre de Caso de Uso: Buscar paciente Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Permite buscar un paciente para modificar o eliminar su información del sistema. Disparador: Acceso mediante las opciones de modificación o eliminación de paciente. Puede también accederse a la búsqueda y mediante ésta dirigirse a la modificación o eliminación respectivas. Precondiciones: Existen pacientes registrados previamente en el sistema. Poscondiciones: Flujo Normal: 1. El administrador introduce el nombre del paciente y presiona el botón de búsqueda. 2. El sistema devuelve una lista con los resultados de la búsqueda. 3. Si existen más de un resultado, el usuario selecciona uno de la lista y le es devuelta la información de dicho usuario. 4. Si solamente existe un resultado, le es devuelta la información al usuario de dicho resultado. Flujos Alternativos: 1. No existe ningún paciente con el nombre indicado El sistema devuelve un aviso de que no pudo encontrar al paciente con el nombre introducido. Inclusiones: Notas:

Tabla A.5: Caso de uso Buscar paciente

122 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales A.1.1 Secuencias de Administración de Pacientes Las secuencias administrativas de médicos, pacientes y enfermeras, presentan grandes similitu- des. En este apartado también se especificarán las secuencias administrativas – en este caso para la Ad- ministración de Pacientes –.

Figura A.2: Secuencia de Administración de pacientes

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 123 Figura A.3: Secuencia Agregar paciente

Figura A.4: Secuencia Modificar paciente

124 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Figura A.5: Secuencia Buscar paciente

Figura A.6: Baja de pacientes

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 125 A.2 Administración de médicos La administración de médicos engloba las operaciones de registro de médicos, asignaciones de pacientes, modificación de información y eliminación de su registro en el sistema.

ID Caso de uso: CU.S.Admin.2 Nombre de Caso de Uso: Administración de médicos Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Es el caso de uso correspondiente al registro, modificación y eliminación de un médico dentro del sistema. Disparador: Selección de la opción Administración de médicos dentro de las opciones de Administración. Precondiciones: El Administrador debe haber accedido al menú de administración autenticándose en una pantalla inicial. Poscondiciones: Se habrá agregado un médico, modificado su información o eliminado del sistema. Flujo Normal 1. El Administrador al seleccionar la opción de Administración de médicos, le son mostradas las opciones de Registrar médico, Modificar información del médico y Dar de baja el médico, además de las opciones para volver al menú anterior. 2. El Administrador selecciona una opción de las mostradas. Flujos Alternativos: Cancelación de la operación. Excepciones: Notas:

Tabla A.6: Caso de uso Administración de médicos

126 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Figura A.7: Diagrama de casos de uso de Administración de médicos

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 127 ID Caso de uso: CU.S.Admin.2.1 Nombre de Caso de Uso: Registrar médico Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Operaciones necesarias para registrar un médico en el sistema. Disparador: Selección de la opción Registrar Médico dentro de las opciones mostradas por Administración de médicos Precondiciones: Poscondiciones: El médico ha sido registrado en el sistema. Ahora es posible asignar pacientes al médico. Flujo Normal 1. El administrador introduce la información personal del médico en un formulario. 2. El sistema verifica la integridad de la información, que los datos estén completos y correctos. 3. El sistema verifica que el médico no se encuentre previamente registrado y lo almacena en la base de datos. 4. El sistema le asigna automáticamente un identificador y muestra un mensaje en pantalla conteniendo un mensaje de “Registro exitoso” y muestra el nombre de usuario y contraseña asignados al médico. Flujos Alternativos: 1. Médico registrado previamente 1.1.Si el médico se encuentra registrado, se cancela la operación mostrando una alerta visual con el mensaje “No se pudo registrar en el sistema, el médico ya se encuentra registrado anteriormente.” 1.2.El formulario se mantiene con la información que se pretende transmitir para que el Administrador cambie la información o cancele la operación. 2. Información introducida inválida 2.1.Si la información introducida es inválida, el sistema muestra un mensaje en pantalla con la leyenda “La información introducida es incorrecta, verifique el contenido”. Inclusiones: Asignar paciente Notas: En futuras revisiones se considerará el caso de que el médico pueda registrarse sin intervención de un administrador quien posteriormente se encargará de validar el registro para que el sistema proceda al almacenamiento de la información y asignaciones de nombre de usuario y contraseña. Puede considerarse también que el nombre de usuario y contraseña sean enviados a la dirección de correo electrónico del médico, que se almacenó en el sistema.

Tabla A.7: Caso de uso Registrar médico

128 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ID Caso de uso: CU.S.Admin.2.2 Nombre de Caso de Uso: Modificar información de médico Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Permite modificar la información registrada del médico Disparador: Selección de la opción Modificar información de médico dentro de las opciones de Administración de médicos. Precondiciones: Existen médicos registrados previamente. Poscondiciones: La información del médico será actualizada en el sistema. Flujo Normal 1. El Administrador selecciona al médico de una lista. 2. Se presenta el formulario con la información obtenida del médico. 3. El Administrador introduce la nueva información. 4. La información es validada por el sistema para verificar esté completa y sea correcta. 5. El sistema guarda los cambios Flujos Alternativos: Inclusiones: Notas:

Tabla A.8: Caso de uso Modificar información de médico

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 129 ID Caso de uso: CU.S.Admin.2.3 Nombre de Caso de Uso: Baja de médico Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Operaciones necesarias para eliminar la información de un médico del sistema. Disparador: Selección de la opción Eliminar médico de las opciones de Administración de Médicos. Precondiciones: Existen médicos registrados en el sistema Poscondiciones: La información del médico seleccionado será eliminada del sistema. Flujo Normal 1. El Administrador selecciona al médico de una lista. 2. Se muestra una pantalla al Administrador confirmando la eliminación del médico seleccionado del sistema. 3. El sistema pregunta por la contraseña de administrador. 4. El administrador introduce su contraseña 5. El sistema confirma la contraseña y elimina al médico del sistema y muestra al usuario un aviso indicando que “el médico ha sido eliminado del sistema”. Flujos Alternativos: Inclusiones: Notas: Dicha operación puede no ser nunca utilizada, sin embargo el comportamiento de dicha operación, se expresa en este apartado. Al dar de baja un médico, se asignan los registros de los pacientes correspondientes al hospital. Es decir, no le es asignado un médico.

Tabla A.9: Caso de uso Eliminar médico

130 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ID Caso de uso: CU.S.Admin.2.2 Nombre de Caso de Uso: Asignar paciente Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 110/10/2007 Fecha de actualización:

Actores: Administrador Descripción: A un médico o enfermera le es asignado un nuevo paciente. Disparador: Selección de la opción Asignar paciente de las opciones de Administración de médicos o Administración de enfermeras. Selección de la opción de Asignar paciente dentro de la operación de Registrar médico o Registrar enfermeras. Precondiciones: Existen médicos, enfermeras y pacientes registrados anteriormente en el sistema Poscondiciones: Se realizará una nueva asignación de paciente al médico o enfermera. En la asignación, se almacenará la fecha de la asignación del paciente. Flujo Normal El Administrador selecciona un paciente de la lista de pacientes que se encuentran asignados a un monitor (activos). Selecciona la opción de asignar. Flujos Alternativos: Cancelación de la operación. Inclusiones: Notas: No se manejan estados de asignaciones, es decir si el médico asignado es su médico actual o si la enfermera asignada es su enfermera actual.

Tabla A.10: Caso de uso Asignar paciente

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 131 A.3 Administración de enfermeras La administración de enfermeras comprende de las operaciones de registro de enfermeras, asignaciones de pacientes, modificación de información y eliminación de su registro en el sistema.

ID Caso de uso: CU.S.Admin.2 Nombre de Caso de Uso: Administración de enfermeras Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Es el caso de uso correspondiente al registro, modificación y eliminación de una enfermera dentro del sistema. Disparador: Selección de la opción Administración de enfermeras dentro de las opciones de Administración. Precondiciones: El Administrador debe haber accedido al menú de administración autenticándose en una pantalla inicial. Poscondiciones: Se habrá agregado una enfermera, modificado su información o eliminado del sistema. Flujo Normal 1. El Administrador al seleccionar la opción de Administración de enfermeras, le son mostradas las opciones de Registrar enfermeras, Modificar información de enfermera y Dar de baja una enfermera, además de las opciones para volver al menú anterior. 2. El Administrador selecciona una opción de las mostradas. Flujos Alternativos: Cancelación de la operación. Excepciones: Notas:

Tabla A.11: Caso de uso Administración de enfermeras

132 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ID Caso de uso: CU.S.Admin.2.1 Nombre de Caso de Uso: Registrar enfermera Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Operaciones necesarias para registrar una enfermera en el sistema. Disparador: Selección de la opción Registrar Enfermera dentro de las opciones mostradas por Administración de enfermeras Precondiciones: Poscondiciones: La enfermera ha sido registrada en el sistema. Ahora es posible asignarle pacientes. Flujo Normal 1. El administrador introduce la información personal de la enfermera en un formulario. 2. El sistema verifica la integridad de la información, que los datos estén completos y correctos. 3. El sistema verifica que la enfermera no se encuentre previamente registrada y almacena su información en la base de datos. 4. El sistema le asigna automáticamente un identificador y muestra un mensaje en pantalla conteniendo un mensaje de “Registro exitoso” y muestra el nombre de usuario y contraseña asignados a la enfermera. Flujos Alternativos: 1. Enfermera registrada previamente 1.1.Si la enfermera se encuentra registrada, se cancela la operación mostrando una alerta visual con el mensaje “No se pudo registrar en el sistema, la enfermera ya se encuentra registrada anteriormente.” 1.2.El formulario se mantiene con la información que se pretende transmitir para que el Administrador cambie la información o cancele la operación. 2. Información introducida inválida 2.1.Si la información introducida es inválida, el sistema muestra un mensaje en pantalla con la leyenda “La información introducida es incorrecta, verifique el contenido”. Inclusiones: Asignar paciente Notas: En futuras revisiones se considerará el caso de que el médico pueda registrarse sin intervención de un administrador quien posteriormente se encargará de validar el registro para que el sistema proceda al almacenamiento de la información y asignaciones de nombre de usuario y contraseña. Puede considerarse también que el nombre de usuario y contraseña sean enviados a la dirección de correo electrónico del médico, que se almacenó en el sistema.

Tabla A.12: Caso de uso Registrar enfermera

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 133 ID Caso de uso: CU.S.Admin.2.2 Nombre de Caso de Uso: Modificar información de enfermera Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Permite modificar la información registrada de la enfermera Disparador: Selección de la opción Modificar información de enfermera dentro de las opciones de Administración de enfermeras. Precondiciones: Existen enfermeras registradas previamente. Poscondiciones: La información de la enfermera será actualizada en el sistema. Flujo Normal 1. El Administrador selecciona a la enfermera de una lista. 2. Se presenta el formulario con la información obtenida de la enfermera. 3. El Administrador introduce la nueva información. 4. La información es validada por el sistema para verificar esté completa y sea correcta. 5. El sistema guarda los cambios Flujos Alternativos: Inclusiones: Notas:

Tabla A.13: Caso de uso Modificar información de enfermera

134 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales ID Caso de uso: CU.S.Admin.2.3 Nombre de Caso de Uso: Baja de enfermera Creado por: Mario A. García Torrea Última actualización por: Fecha de creación: 10/10/2007 Fecha de actualización:

Actores: Administrador Descripción: Operaciones necesarias para eliminar la información de un médico del sistema. Disparador: Selección de la opción Eliminar enfermera de las opciones de Administración de Enfermeras. Precondiciones: Existen enfermeras registrados en el sistema Poscondiciones: La información de la enfermera seleccionada será eliminada del sistema. Flujo Normal 1. El Administrador selecciona a la enfermera de una lista. 2. Se muestra una pantalla al Administrador confirmando la eliminación de la enfermera seleccionada del sistema. 3. El sistema pregunta por la contraseña de administrador. 4. El administrador introduce su contraseña 5. El sistema confirma la contraseña y elimina la información de la enfermera del sistema y muestra al usuario un aviso indicando que “la enfermera ha sido eliminada del sistema”. Flujos Alternativos: Inclusiones: Notas: Dicha operación puede no ser nunca utilizada, sin embargo el comportamiento de dicha operación, se expresa en este apartado. Al dar de baja un médico, se asignan los registros de los pacientes correspondientes al hospital. Es decir, no le es asignado una enfermera.

Tabla A.14: Caso de uso Eliminar enfermera

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 135

Apéndice B Diccionario de Datos

Tabla Paciente Descripción Contiene la información demográfica del paciente Campos Nombre Descripción Tipo de Posibles Valores Longitud dato id Identificador del paciente integer autogenerado nombres Nombre(s) varchar 100 apellido_paterno Apellido Paterno varchar 20 apellido_materno Apellido Materno varchar 20 F – Femenino sexo Sexo del paciente char 1 M – Masculino fecha_nacimiento Fecha de nacimiento date Peso del paciente en peso float kilogramos Estatura del paciente en estatura float metros Calle del domicilio calle varchar 30 particular Número del domicilio numero integer 10 particular Colonia del domicilio colonia varchar 30 particular Estado del domicilio estado varchar 20 particular Delegación del domicilio delegacion varchar 20 particular Código postal del cp varchar 5 domicilio particular telefono Teléfono particular varchar 10

137 Tabla Médico Descripción Contiene la información básica del médico Campos Nombre Descripción Tipo de Posibles Valores Longitud dato id Identificador del médico integer autogenerado nombres Nombre(s) varchar 100 apellido_paterno Apellido Paterno varchar 20 apellido_materno Apellido Materno varchar 20

Tabla Enfermera Descripción Contiene la información básica de la enfermera Campos Nombre Descripción Tipo de Posibles Valores Longitud dato Identificador de la id integer autogenerado enfermera nombres Nombre(s) varchar 100 apellido_paterno Apellido Paterno varchar 20 apellido_materno Apellido Materno varchar 20

Tabla Monitor Descripción Contiene la información básica del monitor Campos Nombre Descripción Tipo de Posibles Valores Longitud dato id Identificador del paciente integer autogenerado Número de cama al que se numero_cama encuentra asignado el integer monitor

138 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Tabla Sensor Descripción Contiene la información sobre cada uno de los sensores registrados en el sistema Campos Nombre Descripción Tipo de Posibles Valores Longitud dato Identificador del sensor en id integer autogenerado el sistema tipo Tipo del sensor integer 10 unidades Unidades correspondientes varchar 'kg', 'm', 'bps', ... 20

Tabla Alarma Descripción Contiene la información sobre las alarmas arrojadas. Campos Nombre Descripción Tipo de Posibles Valores Longitud dato Identificador de la alarma id integer autogenerado en el sistema Fecha en la que es arrojada fecha date la alarma Identificador del monitor monitor_id que arroja la alarma integer (referencía Monitor) Tipo de alarma al que tipo_alarma_id corresponde (referencía integer TipoAlarma)

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 139 Tabla TipoAlarma Descripción Contiene los tipos de alarmas disponibles en el sistema (Neceistan ser registrados en la base de datos) Campos Nombre Descripción Tipo de Posibles Valores Longitud dato Identificador del tipo de id integer autogenerado alarma descripción Descripción de alarma varchar 100 existente en la tabla Sensor_id Sensor al que corresponde integer Sensor AGREGAR VALOR REGISTRADO

Tabla Medico_Paciente Descripción Tabla de relación entre médicos y pacientes Campos Nombre Descripción Tipo de Posibles Valores Longitud dato existente en la tabla Paciente_id Identificador de paciente integer Paciente existente en la tabla Medico_id Identificador de médico integer Médico Fecha de asignación del fecha_asignacion date médico al paciente

Tabla Enfermera_Paciente Descripción Tabla de relación entre pacientes y enfermeras Campos Nombre Descripción Tipo de Posibles Valores Longitud dato existente en la tabla Enfermera_id Identificador de enfermera integer Enfermera existente en la tabla Paciente_id Identificador de paciente integer Paciente Fecha de asignación de la fecha_asignacion date enfermera al paciente

140 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Tabla Monitor_Paciente Descripción Relación entre Pacientes y Monitores Campos Nombre Descripción Tipo de Posibles Valores Longitud dato idRelacion Identificador de la relación integer autogenerado existente en la tabla Paciente_id Identificador del paciente integer Paciente existente en la tabla Monitor_id Identificador del monitor integer Monitor

Tabla Monitor_Paciente_Monitoreo Descripción Relación del monitoreo realizado a un determinado paciente añadido a un determinado monitor. (La relación no puede deshacerse debido a que el monitor puede ser utilizado por varios pacientes en momentos distintos, y es necesario poder obtener el monitoreo de cierto paciente independientemente de los monitores utilizados) Campos Nombre Descripción Tipo de Posibles Valores Longitud dato existente en la tabla Paciente_id Identificador del paciente integer Paciente existente en la tabla Monitor_Id Identificador del monitor integer Monitor Identificador del existente en la tabla Monitoreo_Id integer monitoreo Monitoreo Fecha en la que se realiza el Fecha date monitoreo

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 141

Apéndice C Análisis de las alternativas para el desarrollo Web

C.1 Streaming de datos y dibujado dinámico de gráficas

C.1.1 Streaming: Manejo de flujos de información El streaming ha sido explotado en cuestiones de audio y video en Internet, pues éstas son sus aplicaciones principales [wDWE07]. Sin embargo puede ser posible el caso de transmisión de infor- mación – no necesariamente audiovisual – de forma continua con la cual pretendemos realizar las gráficas de las variables obtenidas. Es por ello que necesitamos realizar pruebas para determinar las políticas o estrategias de transmisión de información a los dispositivos que visualizarán la informa- ción. Para lograr este objetivo se propone realizar pruebas de streaming de información que permiti- rán identificar los puntos que hay que tomar en cuenta para el desarrollo del sistema.

El objeto XMLHttpRequest El objeto XMLHttpRequest es el corazón de las Aplicaciones Ricas de Internet. El objeto XMLHttpRequest permite que los scripts puedan obtener información en segundo plano y realizar un procesamiento con lo obtenido o visualizarlo.

Método Descripción abort() Cancela la petición actual getAllResponseHeaders() Devuelve el conjunto completo de encabezados http como una cadena getResponseHeader("headername") Devuelve el valor del encabezado http especificado open("method","URL",async,"uname", Especifica el método, URL y otros atributos opcionales de una "pswd") petición. El método parámetro puede tener un valor de “GET”, “POST”, o “PUT” (utilice “GET” cuando pida información y “POST” cuando transmita información (especialmente si la longitud de la información es mayor a los 512 bytes)).

143 El parámetro URL puede ser tanto una URL relativa como una completa. El parámetro async especifica si la petición debe ser manejada como asíncrona o no. true significa que el procesamiento continua después del método send() sin esperar una respuesta. false indica que el script debe esperar una respuesta antes de continuar con el procesamiento. send(content) Envía la petición setRequestHeader("label","value") Agrega un par etiqueta/valor al encabezado http que será transmitido.

Propiedad Descripción onreadystatechange En manejador de eventos para el evento que se dispara tras cada cambio de estados readyState Devuelve el estado del objeto: 0 = no inicializado 1 = cargando 2 = cargado 3 = interactivo 4 = completo responseText Devuelve la respuesta como una cadena responseXML Devuelve la respuesta como XML. Esta propiedad devuelve un objeto de documento XML, el cual puede ser examinado o analizado utilizando propiedades y métodos de un árbol de nodos W3C DOM status Devuelve el estado como un número (e.g. 404 para “No encontrado” o 200 para “OK”) statusText Devuelve el estado como una cadena (e.g. "Not Found" u "OK")

Tabla C.1: Referencia del objeto XMLHttpRequest4

C.1.2 Prueba de streaming de datos Una aplicación web genera un flujo de datos consistente en la información de una señal coseno. El código de la aplicación se encuentra en el siguiente listado:

<% /*for(int i=0; i<20; i++) {

4 http://www.w3schools.com/dom/dom_http.asp

144 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales out.print("a"); out.flush();*/ double PI= 3.141592; int r=0; while(r<20) { for(double i=0; i<4; i+=0.1 ) { out.print(Math.sin(0.5*PI*i)); out.print(";"); } out.flush(); try{ Thread.sleep(30); }catch(Exception ex) { ex.printStackTrace(); } r++; } %>

Dicha información es recibida en el formato double; double; double; double;.... La informa- ción recibida se recibe por una conexión realizada por un objeto XMLHttpRequest. La información se procesa en el cliente por una sección de código Javascript y se muestra en un objeto Canvas. El listado muestra el código en el cliente que procesa la información.

Prueba de conexion Cliquez ici

Límites de Javascript El uso de Javascript supone ciertas limitantes que podrían degradar el desempeño. Se busca que la transmisión optimice el uso del ancho de banda y el uso del procesador tanto en el lado del cliente y del servidor. Sin embargo dichas variables están estrechamente relacionadas. Podemos mejorar el uso del ancho de banda, sin embargo se necesitarían técnicas más complejas para poder procesar la in- formación recibida. Para aclarar la propuesta se establece el siguiente modelo. Queremos transmitir un número de punto flotante, ignorando por un momento la resolución o cantidad de bits necesarios para poder alojarlos en memoria – considere- mos que un número de punto flotante necesita 16 bits para representarse –, la forma en la que transmitimos un número por HTTP se reduce a la transmisión del texto como tal; es decir, se transmitirá el número 1.5678 como el conjunto de 6 caracteres y cada caracter podría componerse de 8 bits, así pues la cadena 1.5678 constará de 48

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 147 bits para representarse a diferencia de los 16 bits necesarios por el tipo de dato. Una primera mejora es transformar la representación a una cadena de dos caracteres, para así poder representar los 8 bits más significativos en el primer caracter y los menos significativos en el segundo caracter. Ésta primera aproximación, nos permite utilizar mejor el ancho de banda, sin embargo aumenta el procesamiento tanto en el cliente como en el servidor, más aún en el cliente. Además que introduce una segunda consideración, los caracteres de separación “;” tienen también su representación como un bloque de 8 bits. Entonces necesitamos asegurarnos que la cadena de bits que consiste en el caracter delimitador no aparezca dentro de la representación de un dato. Esto se logra mediante bit stuffing, lo cual también aumenta la carga de procesamiento en el cliente más que en el servidor. La solución propuesta entonces, supondría que podemos realizar un buen manejo de máscaras de bits en Javascript. Las operaciones binarias en Javascript se pueden efectuar solamente entre números de 32 bits. Lo cual implica que necesitamos procesar los 32 bits y separarlos en un flotante de 16 bits o extender la resolución o transmitir dos flotantes de 16 bits dentro de la cadena de 32 bits (compuesto por 4 caracteres). Dicha transformación es la que supone un reto para la optimización del uso de los recursos, que si bien puede ser innecesaria, pues se está trabajando sobre una LAN, debe de ser considerada en la optimización del sistema y en el desarrollo de las aplicaciones tanto en cliente como en servidor. En vista de las limitantes expuestas anteriormente, se propone utilizar codificación base64 para la transmisión de información, pues Javascript cuenta también con métodos para el manejo de la in- formación codificada de esa forma y puede permitirnos no utilizar las técnicas de bit stuffing y otras así; sin embargo una de las limitantes que puede ofrecer este modelo sigue siendo el manejo de los paquetes, por lo cual se delimitarán utilizando algún caracter fuera de la codificación base 64 – cuyos caracteres base son “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrs- tuvwxyz0123456789+/” – y así poder recuperar los paquetes tras la transmisión streaming del servidor.

C.1.3 Dibujado dinámico de gráficas en el navegador El alcance la prueba anterior, nos demuestra el uso del objeto Canvas – existente en al menos los navegadores más utilizados y utilizado como parte del DHTML– y muestra una de las opciones disponibles; entre otras opciones podemos mencionar a SVG, Adobe Flash, Microsoft Silverlight y Applets de Java.

148 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Figura C.1: Captura de pantalla del test de bubblemark.com

En el sitio [GAV07], podemos encontrar pruebas enfocadas al desempeño de distintas herramientas – con las que podemos desarrollar Aplicaciones Ricas de Internet, Rich Internet Applications – respecto a la animación de unas burbujas que rebotan y chocan. Como es de suponerse, las aplicaciones que se ejecutan sobre un plugin, presentan un mejor rendimiento a las que se ejecutan con el motor Javascript del navegador. Sin embargo el uso de los plugins requiere que el usuario los tenga instalados y éstos plugins podrían no existir en la plataforma que utilicen los clientes o los dispositivos, como una PDA, un teléfono celular o un iPhone. Basándonos tanto en la disponibilidad en los navegadores actuales y su desempeño, se escoge DHTML como base para el desarrollo de la aplicación además, se considera el uso de Applets Java como segunda opción y Flash como tercera. El uso de DHTML puede orientarnos a utilizar algunas otras tecnologías o considerar los objetos incorporados al navegador como el objeto Canvas o utilizar el soporte SVG existente en los nuevos navegadores.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 149 Miembros Soportado Notas width Si - height Si - toDataURL() Si - toDataURL() No - Opera soporta "2d" y getContext() Si "opera-2dgame" como parámetros.

Tabla C.2: Soporte del objeto Canvas5

5 http://www.opera.com/docs/specs/opera9/canvas/

150 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Miembros Soportado Notas canvas Si - save() Si - restore() Si - scale(x, y) Si - rotate(angle) Si - translate(x, y) Si - transform(m11, m12, m21, m22, dx, dy) No - setTransform(m11, m12, m21, m22, dx, dy) No - globalAlpha Si - globalCompositeOperation Si - strokeStyle Si - fillStyle Si - createLinearGradient(x0, y0, x1, y1) Si - createRadialGradient(x0, y0, r0, x1, y1, r1) Si - createPattern(image, repetition) Si - lineWidth Si - lineCap Si - lineJoin Si - miterLimit Si - El soporte es shadowOffsetX No opcional El soporte es shadowOffsetY No opcional El soporte es shadowBlur No opcional El soporte es shadowColor No opcional clearRect(x, y, w, h) Si - fillRect(x, y, w, h) Si - strokeRect(x, y, w, h) Si - beginPath() Si - closePath() Si - moveTo(x, y) Si - lineTo(x, y) Si - quadraticCurveTo(cpx, cpy, x, y) Si - bezierCurveTo(cp1x, cp1y, cp2x, cp2y, x, y) Si - arcTo(x1, y1, x2, y2, radius) Si - rect(x, y, w, h) Si -

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 151 Miembros Soportado Notas arc(x, y, radius, startAngle, endAngle, anticlockwise) Si - fill() Si - stroke() Si - clip() Si - isPointInPath(x, y) No - drawImage(image, dx, dy) Si - drawImage(image, dx, dy, dw, dh) Si - drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh) Si - getImageData(sx, sy, sw, sh) No - putImageData(image, dx, dy) No -

Tabla C.3: Soporte de CanvasRenderingContext2D

152 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Apéndice D Protocolos del Sistema

En este apartado se enlistan los protocolos utilizados para la transmisión de información entre los monitores de signos vitales y la central de enfermeras.

D.1 Notas sobre la implementación

D.1.1 Sobre el manejo de memoria y cadenas Las funciones malloc y memcpy están contenidas dentro de distintos archivos de inclusión en gcc (Linux) y en Borland C++ Builder (Windows), el primero está contenido en stdlib en ambos com- piladores y la segunda está incluída en mem.h para Borland C++ Builder y en string.h para gcc. Hay que recalcar que hay que evitar el uso de la librería string.h y las funciones contenidas para el manejo de cadenas, pues los datos de las cadenas de mensaje en ocasiones pueden tener valores me- nores a los alfanuméricos ASCII – incluso el valor null '\0' – con lo cual podría obligar a las funciones a no considerar dichos valores y entregar cadenas truncas.

D.1.2 Sobre la compilación en Linux El API desarrollado promueve esta diferenciación y plantea que ha de utilizarse la etiqueta -D para agregar la definición de la directiva LINUX para la correcta compilación de las aplicaciones bajo éste sistema. En compilación desde línea de comandos es necesario introducir la directiva de la siguiente forma:

g++ foo.c -o foo -DLINUX

D.1.3 Sobre la compilación en Windows Para hacer uso del API desarrollado bajo sistemas Windows, es necesario considerar que la im- plementación de la clase Monitor (MonitorCore) incluye las directivas para el manejo de sockets bajo el entorno de desarrollo de Borland C++ Builder 2006. Sin embargo ésta es la única clase que hace uso de alguna implementación fuera del estándar – si bien también lo son aquellas relacionadas con sockets como Socket, ClientSocket, ServerSocket y SocketManager, en el apartado anterior se ha definido

153 como permitir la compilación en Linux.

D.2 Protocolo de transmisión de información al Servidor Amande

Consideraciones para API C++ Namespace: Package Clase: PComando

La secuencia para que un monitor de signos vitales pueda conectarse al servidor de monitores se puede resumir en los pasos siguientes: 1. Al conectarse un monitor, el servidor transmite un paquete de comando del tipo respuesta con el parámetro petición de autenticación. RESP(RESP_PET_AUTH) 2. El monitor responde con un paquete de comando del tipo autenticación con su identifi cador de monitor como parámetro. AUTH(ID) 3. El servidor verifica si éste monitor se encuentra registrado ya dentro de su lista de monitores activos – verifica que su sesión no haya sido iniciada. En caso de no estar previamente conectado – para evitar conexiones múltiples y recepción de información de múltiples clientes sobre una sesión – el servidor envía un comando del tipo respuesta con el pará- metro autenticación correcta. RESP(RESP_AUTH_OK) 4. El servidor transmite un comando de tipo respuesta con el parámetro listo para recibir. RESP(RESP_READY_TO_RECIEVE) 5. El monitor comienza su transmisión de información haciendo uso de paquetes contene dores.

154 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales D.2.1 Contenedores

API Châtaigne Namespace: Package Clase: ContenedorInformacion

El contenedor es el elemento fundamental para la transmisión de información sobre las conexiones establecidas entre los monitores de signos vitales y el servidor de monitores. El contenedor forma una capa de abstracción para la formación de paquetes sobre la cual se incluye información sobre los tipos de paquetes y sensor correspondiente como también podría considerar la inclusión de otros campos como el tamaño o información especial. Para determinar si los mensajes corresponden a mensajes de información o de alarma se utilizan los indicadores && y ## respectivamente para marcar el inicio del paquete; los campos siguientes definen el identificador del sensor, el tipo de mensaje, el tamaño y el contenido obtenido por la serialización del paquete correspondiente. Los campos de tipo y tamaño son opcionales, pues existen paquetes de información que por seguir una convención no es necesario conocer el tamaño o tipo, pues éstos son conocidos. Los contenidos de los tipos de mensajes y otros campos corresponden a los valores constantes definidos en el API. Un contenedor serializado mantiene generalmente la siguiente estructura:

tipo tipo tipo tamaño n bytes m bytes x bytes sensor sensor sensor Paquete Paquete Paquete n+m+x && N Información ... ## M Alarma ... && X Información ... serializado serializada serializado

No se ha considerado el caso en el que el tamaño del contenido de los paquetes individuales sobrepase los 256 bytes.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 155 D.2.2 Protocolo del Ventilador

Paquete de Información

API Châtaigne Namespace: Package Clase: PIVentilador / DatosVentilador

Tamaño en bytes (sin Tipo Descripción contar el campo de Ocurrencias tipo) 85 Lectura del porcentaje de oxígeno 1 cada 10 segundos cada fin de 86 Valores al final de cada inspiración 9 inspiración 87 Valores al final de cada espiración 16 cada fin de espiración 88 Flujo Contínuo 1 89 Volumen por minuto 2 90 Volumen 2 91 Presión de control 1 92 Presión de soporte 1 93 PEEP 1 94 Frecuencia 1 cada cambio de alguno de los valores 95 Tiempo inspiratorio 2 programados 96 Mezcla 1 97 Sensibilidad 2 98 Tiempo superior 2 99 Tiempo Inferior 2 100 Presión Superior 1 101 Presión Inferior 1 Paquete de información de valores 102 12 cada cambio de modo programados 103 Alarmas 3 cada ocurrencia Estado de funcionamiento del modo de espera o 104 1 respirador calibración de línea Bloque de datos con valores para cada 40ms durante 105 graficar curvas durante el tiempo 6 tiempo inspiratorio inspiratorio Bloque de datos con valores para cada 40ms durante 106 graficar curvas durante el tiempo 6 tiempo espiratorio espiratorio

156 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales La serialización de un paquete de información de ventilador, está compuesto de la siguiente estructura

1 byte n bytes 1 byte n bytes Tipo Paq. Datos Contenido Paq. Datos ... Tipo Paq. Datos Contenido Paq. Datos

Ejemplo

1 byte 6 bytes 1 byte 6 bytes 105 255 255 255 255 255 255 85 84

El paquete de información de ventilador anterior se compone de dos paquetes de datos, el primero contiene el bloque de datos para el graficado curvas durante el tiempo inspiratorio; el segundo paquete de datos corresponde a la lectura del porcentaje de oxígeno con un valor del 84%.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 157 Paquete de Alarma del Ventilador

API Châtaigne Namespace: Package Clase: PAVentilador

El paquete de Alarma del ventilador está compuesto por tres campos que contienen las bande- ras relacionadas con los eventos que pueden presentarse en el monitor de signos vitales.

La serialización de un paquete de alarma del ventilador, está compuesta de la siguiente forma:

1 byte 1 byte 1 byte Indicadores 1 Indicadores 2 Indicadores 3

Uso de las rutinas para formación de paquetes Se han definido ya las estructuras de los paquetes de información de los ventiladores, y es el

158 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales API Châtaigne el que ofrece rutinas que siguen la estructura definida y facilitan la formación de paquetes de información. Suponiendo que necesitamos crear un paquete que contenga la información de una señal seno (con un rango de valores de 0 a 65, 535, es decir de 16 bits), se agrega la información a un paquete de datos de ventilador y se establece el tipo del dato, en este caso de un bloque de datos para gráficas de tiempo inspiratorio.

//Creamos un paquete de información de ventilador PIVentilador *paquete= new PIVentilador();

//Generamos los datos union d{ unsigned char c[2]; int r; }medicion;

for(double i=0; i<1; i+=0.3) { medicion.r=(int)(65535*(1+cos(i))/2); // Podemos asignar de una vez los tres canales en un // arreglo unsigned char dato[6]; dato[0]=medicion.c[0]; dato[1]=medicion.c[1]; dato[2]=medicion.c[0]; ... //Se crean así tantos datos de ventilador como sea //necesario. DatoVentilador *dv= new DatoVentilador( DatoVentilador::BLOQUE_DATOS_GRAFICAS_TIEMPO_ INSPIRATORIO, dato);

//Agregamos el dato de ventilador al paquete paquete->agregarPaqueteDatos(dv); }

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 159 D.2.3 Notas sobre los demás protocolos Los protocolos de los demás sensores no está completamente definido, pues durante el desarrollo del monitor de signos vitales es necesario definir cuáles alarmas serán consideradas en él y que pa- rámetros deben de arrojar. Sin embargo, el protocolo y la estructura relacionada al ventilador es una buena plantilla para el desarrollo de no sólo los otros sensores si no también para las aplicaciones en las que pueda ser necesario transmitir señales para el graficado además de otros tipos de señales.

D.3 Protocolo de transmisión a clientes Web Al realizarse una conexión de un cliente web, el módulo Amande lo agrega a una lista de clientes para acceder a éstos y transmitir en multidifusión las alarmas; las cuestiones respecto a la conexión se manejan en el apartado de Streaming en Amande. El cliente web espera la información proveniente del servidor de monitores en base al parámetro enviado al inicio de su conexión indicando de qué monitor requiere información; posteriormente, el cliente procesa el paquete obtenido en formato JSON y visualiza su contenido, ya sea en las gráficas o en los parámetros numéricos. Es así como podemos establecer el protocolo de conexión y transmisión a clientes web en los siguientes pasos: 1. El cliente web realiza una petición de conexión al recurso “alohomora” del servidor enviando como parámetro GET mid=X; es decir la cadena de conexión es /alohomora? mid=X. Donde X es el identificador del monitor de quien se desea obtener información. 2. Se conecta un cliente Web al servidor Lighttpd, éste dirige la conexión al servidor de monitores mediante el protocolo FastCGI. 3. El servidor de monitores (Amande) agrega un objeto que contiene el descriptor de flujo de la conexión, el identificador del cliente web y la petición de monitor establecida en la cadena de conexión. 4. Al recibir un paquete de información, Amande genera los procesos necesarios para distribuir el paquete a todos los clientes web conectados. Cada proceso se encarga de discriminar si el paquete recibido le corresponde o no. 5. El paquete de información es serializado en formato JSON y estransmitido al cliente Web.

En Châtaigne, el serializador contenido en la clase WebModule convierte un Paquete de Infor- mación a su respectiva cadena JSON con la función serialize().

160 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales D.3.1 Formato del paquete JSON Las estructuras de los paquetes de información en JSON difieren tanto para las alarmas como para los paquetes de información, pues el de alarmas considera unos campos adicionales relacionados con los identificadores de éstas en la base de datos.

Paquete de información La estructura de un paquete de información en JSON se muestra a continuación:

Por ejemplo, considerando el paquete siguiente:

{ "paquetes" : [ { "datos" : [ { "tipo_dato" : 105, "valores" : [ 255, 255, 255, 255, 255, 255 ] }, { "tipo_dato" : 105, "valores" : [ 71, 250, 71, 250, 71, 250 ] }, { "tipo_dato" : 105, "valores" : [ 163, 233, 163, 233, 163, 233 ] }, { "tipo_dato" : 105, "valores" : [ 144, 207, 144, 207, 144, 207 ] } ], "sensor" : 15, "tipo" : 2 } ] }

El paquete contiene cuatro mediciones o datos, sin embargo éste corresponde al sensor 15 (Ventilador) y es de tipo 2 (información). Las mediciones contenidas son del tipo 105 (bloque de datos para gráficas de tiempo inspiratorio).

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 161

Apéndice E Instalación del Sistema

E.1 Establecimiento del entorno de producción

E.1.1 Instalación de Linux en el servidor Se ha escogido la distribución Ubuntu-Linux al permitirnos instalar un sistema básico, sin necesidad de configurar uno desde una distribución mínima o instalar una gran cantidad de paquetes sin necesitarlos. La instalación del sistema se reduce a: ● Cargar el disco de Ubuntu-Linux en la computadora al iniciar. ● Seleccionar Iniciar la instalación ● Establecer las opciones de idioma, teclado, zona horaria ● Establecer las particiones en las que se instalará el sistema (o permitir el particionamien- to automático) ● Introducir el nombre de usuario y contraseña de administrador ● Seleccionar iniciar la copia de archivos al sistema y reiniciar. En [CSU08] y una búsqueda en google por la instalación de Ubuntu, puede encontrar una gran cantidad de referencias de la instalación de Ubuntu-Linux.

E.1.2 Configuración de las aplicaciones necesarias Si bien todas las aplicaciones siguientes se instalan mediante el comando

apt-get install lighttpd postgresql

La configuración de éstas representan modificaciones a archivos para permitir el correcto funcionamiento del sistema.

163 Sistema Gestor de Bases de Datos PostgreSQL Una vez que se ha instalado el paquete PostgreSQL y sus dependencias, se ha creado un nuevo usuario llamado postgres. Por seguridad, se recomienda establecer la contraseña del usuario del sistema postgres con el comando:

sudo passwd postgres

Accedemos al shell de administración de PostgreSQL con el comando

sudo su postgres -c "psql template1"

Y establecemos la contraseña del usuario postgres de la base de datos con el comando:

template1=# ALTER USER postgres WITH PASSWORD 'nueva_contraseña';

Creamos también el usuario smonitoreo de la aplicación de monitoreo de signos vitales

template1=# CREATE USER smonitoreo WITH PASSWORD 'monitorvsm8862';

Y creamos la base de datos vsmsysdb con el comando

template1=# CREATE DATABASE vsmsysdb;

Tecleamos \q para salir del shell de administración de PostgreSQL.

Servidor lighttpd La configuración del servidor lighttpd se mantiene bajo el directorio /etc/lighttpd y se compone por un archivo lighttpd.conf en el que se almacenará la configuración general, y las carpetas conf available y confenabled contienen los archivos de configuración de los módulos disponibles y los habilitados respectivamente. Es necesario también notar que el puerto de escucha predeterminado del servidor, es el 80; si es necesario modificar el puerto de escucha, también se encontrará dicha opción dentro del archivo de configuración principal del servidor. Para la edición de los archivos de configuración utilizamos el editor nano – puede utilizarse cualquier editor, sin embargo nano es bastante simple e intuitivo. En el archivo lighttpd.conf es necesario habilitar las siguientes secciones (quitando el símbolo # al inicio de la línea) o bien escribirlas. Así la sección modules debe de contener al menos los siguientes módulos habilitados

164 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales server.modules = ( "mod_access", "mod_alias", "mod_accesslog", "mod_compress", "mod_fastcgi", "mod_proxy", )

Y la línea siguiente debe de estar comentada, pues queremos que no dirija las peticiones de /images/ a otra ubicación

# "/images/" => "/usr/share/images/"

Para finalizar la edición y guardar los cambios, presionamos Ctrl-O y para salir del editor Ctrl- X.

Copiamos los archivos de configuración de los módulos que habilitamos (fastcgi y proxy) de la carpeta conf-available a la carpeta conf-enabled

sudo cp /etc/lighttpd/conf-available/10-proxy.conf /etc/lighttpd/conf-enabled

sudo cp /etc/lighttpd/conf-available/10-fastcgi.conf /etc/lighttpd/conf-enabled

El archivo 10-proxy.conf debe de tener las siguientes líneas al final

proxy.debug=1 #puede deshabilitarse el debug con un valor 0 proxy.server=( #las peticiones a Pistache se dirigen a la siguiente dirección, #donde esté situado el contenedor de aplicaciones

"/pistache"=>( ("host" => "127.0.0.1", "port" => 8080) ))

En el archivo 10-fastcgi.conf por default, el módulo fastcgi viene configurado para su uso con PHP. Por lo tanto comentamos dicha sección y agregamos al final las siguientes líneas

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 165 fastcgi.debug=1 fastcgi.server = ( ".php" => (( "bin-path" => "/usr/bin/php5-cgi", "socket" => "/tmp/php.socket" )) ,"/alohomora" => (( "host" => "127.0.0.1", "port" => 2090, "check-local" =>"disable", "max-procs" => 4, "idle-timeout"=> 20, "min-procs" =>1, "bin-copy-environment" => ( "PATH", "SHELL", "USER" ) )) )

Guardamos el archivo y reiniciamos el servidor con el comando

sudo /etc/init.d/lighttpd restart

Entorno de ejecución de Java El entorno de ejecución Java (Java Runtime Environment formando parte de Java Platform Standard Edition, JSE), puede instalarse desde los repositorios considerando las siguientes ventajas y desventajas. Las aplicaciones de los repositorios oficiales han sido probadas para su instalación y ejecución en el sistema, sin embargo pueden no tener las versiones más actuales de las éstas. Además por cuestiones legales, pueden no existir las aplicaciones en los repositorios. Es por ello que en ocasiones, las aplicaciones han de instalarse descargando los binarios desde las páginas oficiales. En el caso de la JRE, la descarga está disponible bajo el nombre Java SE Runtime Environ- ment. Obtenemos el binario y lo instalamos con el siguiente método: Cambiamos el permiso de ejecución del instalador y lo ejecutamos

chmod +x jre-6-linux-i586.bin sudo ./jre-6-linux-i586.bin

Aceptamos la licencia y se habrán extraído los archivos de la JRE. Es necesario moverlos a una ubicación más apropiada para la creación de enlaces simbólicos o cuestiones relacionadas con el classpath.

sudo mv jre1.6.0 /usr/lib/jvm

166 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Por default, el sistema incluye una versión open source de java y javac, bajo los paquetes java-gcj, sin embargo es necesario indicarle al sistema que los comandos java y javac son provistos por una determinada aplicación.

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/bin/java" 1

Y establecemos la alternativa

sudo update-alternatives --set java /usr/lib/jvm/bin/java

El establecimiento del classpath es en ocasiones lo más complicado debido a que puede hacerse para una sola sesión de Terminal con el comando export o para las distintas sesiones que inicia el sistema – como la sesión gráfica, la de terminales, las del sistema, etc. Y en ocasiones algunas no son utilizadas por otras. Las opciones para agregar el classpath son, agregarlos en los archivos /etc/environment o en el archivo ~/.profile (Preferentemente, se hace en el primero). En el primero se establece como JAVA_HOME=”/usr/lib/jvm”; y en el segundo con sentencias export JAVA_HOME="/usr/lib/jvm/" . La configuración del Kit de Desarrollo de Java (JDK) es similar.

Instalación del servidor de aplicaciones Jetty Para el desarrollo del proyecto se utilizó la versión 6.1.9 de Jetty Descargamos el servidor de aplicaciones Jetty con el comando wget

wget http://dist.codehaus.org/jetty/jetty-6.1.9/jetty-6.1.9.zip

Y lo extraemos con unzip jetty-6.1.9 Para ejecutar el servidor de aplicaciones se utiliza el comando

java -jar jetty-6.1.9/start.jar

Por defecto, el puerto de escucha del servidor es el 8080 y corresponde con el de la configura- ción de lighttpd. En todo caso sería necesario modificar la configuración del archivo 10-proxy.conf y establecer un nuevo puerto.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 167 E.2 Instalación del Sistema de Monitoreo Web de Signos Vitales

E.2.1 Instalación de Noisette Noisette son las aplicaciones – o más específicamente las páginas y scripts – necesarias para visualizar la información capturada por el servidor Amande. Requisitos Se requiere que la configuración del servidor lighttpd sea correcta. Instalación La instalación se reduce a copiar los archivos contenidos en el directorio Pistache en la carpeta / var/www o bien, en crear los enlaces simbólicos a dicha carpeta, además de establecer los permisos de lectura necesarios en el sistema.

E.2.2 Instalación de Pistache La aplicación Pistache, es la encargada de la administración de información del sistema, más es- pecífcamente la de pacientes, médicos, enfermeras, monitores y alarmas. Requisitos Los requisitos de dicha aplicación son la correcta configuración del sistema de base de datos PostgreSQL, la instalación del JRE y del contenedor de aplicaciones Jetty. Instalación Su instalación se reduce a copiar el archivo .WAR de la aplicación Pistache en el directorio jetty-6.1.9/webapps

E.2.3 Instalación de Amande Amande es la aplicación encargada de obtener información de los monitores de signos vitales, procesarla y transmitirla a los clientes Web. Ya que la plataforma de desarrollo a la de producción varía en la instalación de librerías, etc, es recomendable recompilar la aplicación, para lo cual se proporciona un Make file, estableciendo así la instalación en tres pasos:

./configure make sudo make install

Sin embargo, se proveen archivos binarios que eliminan la necesidad de recompilar y conseguir las librerías de desarrollo (x-dev).

168 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Requisitos Es necesario tener instaladas las librerías libpqxx, libjaula y libfcgi. Pudiendo éstas ser instaladas utilizando el comando

sudo apt-get install libpqxx-2.6.9ldbl libfcgi

La librería jaula está disponible desde morongo.homelinux.net/jaula La instalación de un paquete .deb en el sistema se efectúa utilizando el comando:

sudo dpkg -i paquete.deb

Instalación Puede ejecutarse simplemente el binario de Amande en sistemas de 32 bits.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 169

Apéndice F Escenarios y casos de prueba

Personajes

Marco Domínguez. Médico Marco es un médico de 42 años que acaba de ingresar al hospital y recientemente ha concluido sus estudios de cirugía pulmonar. A él le agrada la tecnología, constantemente busca informarse sobre los nuevos dispositivos como teléfonos y computadoras. Considera que la tecnología puede apoyar mucho su área al permitirle acceder a información importante sobre sus pacientes desde cualquier lado no sin antes haber introducido una contraseña que le permita sólo a él acceder a ésta. Para él el mantener información clínica en un medio electrónico le evitaría muchos problemas con el papeleo que hay que hacer constantemente.

Elisa López. Enfermera Elisa es una enfermera que lleva bastante tiempo en el hospital. Le gusta mucho el cuidar a los enfermos y en especial platicar con las personas mayores que se encuentran en el hospital. Cree que todos tienen una bella historia que contar. Ya que el contacto que tuvo con las computadoras fue muy breve en su estancia en la universidad, nunca le han llamado demasiado la atención sin embargo se sorprende de la cantidad de cosas que pueden realizar y cree que en algún momento podrían existir robots que pudieran suplantarla, sin embargo se tranquiliza al pensar que un robot no podrá suplan- tar la labor que realiza la enfermera al cuidar y ayudar a los pacientes.

171 Pedro Gómez. Paciente Pedro tiene 28 años. Es un diseñador gráfico y en la actualidad realiza trabajos a varias cadenas de restaurantes en el norte del país. Le gusta viajar e ir de fiesta. Uno de sus principales problemas es su excesivo consumo de alcohol. En una ocasión estuvo a punto de tener un accidente muy fuerte en su automóvil por conducir en estado de ebriedad, sin embargo solamente se dañó su automóvil un poco. Muy a pesar de ello le gustan los deportes extremos y considera que necesita tener adrenalina en su cuerpo para poder disfrutar los retos.

Pablo Mendoza. Paciente Pablo es un señor de 72 años que ha tenido una vida plena. En su juventud ayudó en un taller de carpintería, lo que le permitió aprender el oficio y posteriormente puso su propio taller. Siempre tuvo mucho trabajo y gracias a ello pudo comprar una casa y posteriormente pudo poner una peque- ña tienda, la cual atendía su esposa; así el dinero que ganaba en el taller y en la tienda, les servía para mantenerse y para pagar los estudios de sus hijos. En la actualidad sus dos hijos ya están casados y tienen su propia familia y en ocasiones los visita sin embargo, le agrada más compartir su tiempo con su esposa mientras la ayuda a atender la tienda.

172 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Escenarios

Antecedentes El hospital ha instalado un nuevo sistema con el que se busca mantener un mejor orden en cuanto al personal médico. Durante su instalación, se planteó la posibilidad de probar un nuevo sistema que permita almacenar la información de los pacientes en la forma de un pequeño expediente e incluso poder visualizar la información de los signos vitales de éstos de forma remota, cuando se encuentran en el área de terapia intensiva.

Primer escenario: Pablo Mendoza llega al hospital, pues siente una pequeña molestia en el pecho.

Elisa acaba de ser informada del sistema y tras haber tomado un pequeño curso para manejar el sistema, recibe al Sr. Mendoza y determina que un médico debe de revisarlo. Sin embargo debe registrar la información del paciente y debe de asignarle un médico. Elisa introduce su nombre de usuario y su contraseña en la ventana inicial del sistema y éste le permite acceder a un panel desde donde puede registrar la entrada de un nuevo paciente. Selecciona la opción de Pacientes y posteriormente selecciona el botón de Nuevo paciente. Ahí comienza a pre- guntarle cierta información básica al Sr. Mendoza – quien le pide que se refiera a el como Don Pablo o Pablo, pues no le agradan las formalidades – e introduce esa información seleccionando cada uno de los recuadros. Al finalizar de llenar todos los recuadros, Elisa recuerda – atinadamente – que debe de utilizar el ratón para presionar un botón que dice Registrar. En ese momento se muestra en la pantalla la información de Don Pablo. Se da cuenta que hubo un error en su fecha de nacimiento, pues el Sr. Mendoza nació en abril y por error ella seleccio- nó mayo. Recuerda entonces que para modificar su información solamente es necesario presionar el botón de Modificar y vuelven a aparecer en la pantalla los recuadros que le permiten modificar la in- formación que acaba de introducir. Al terminar la modificación se asegura de que la información sea correcta y presiona el botón de Guardar. Elisa le pide al Sr. Mendoza que espere un momento para dirigirlo con un médico que pueda revisarlo.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 173 Segundo escenario: A Pablo Mendoza le es necesario realizar una operación en uno de sus pulmones. Elisa dirige al Sr. Mendoza con el Doctor Domínguez. Tras haber revisado Marco a Don Pa- blo, le indica que es posible que sea un problema en sus pulmones probablemente debido a su extensa exposición a solventes y otras sustancias en su carpintería; por lo que pide a la enfermera Elisa que le asigne su caso y que programe una biopsia a pulmón abierto para examinar el tejido pulmonar en búsqueda de alguna infección o cáncer pulmonar. Elisa entonces accede nuevamente al sistema y selecciona la opción de Asignación de médicos y asigna el médico Marco Domínguez al paciente Pablo Mendoza. Además sabe que debe asignarle un monitor de signos vitales pues el sistema de prueba necesita que se realice dicha asignación. Así pues verifica que el monitor que va a asignarle esté disponible (sin asignar) y presiona el botón iz- quierdo del ratón sobre la imagen de dicho monitor. Se muestran varios recuadros con la informa- ción de la fecha de asignación y dos recuadros que permiten seleccionar el paciente y el monitor que quiere asignarle. Al haber puesto todos los campos de forma correcta, presiona el botón de Registrar. Más tarde, Marco realiza la biopsia y extrae el material suficiente para enviarlo al laboratorio. La operación no ocasionó ningún percance, sin embargo Pablo debe pasar la noche en terapia intensiva y posteriormente solamente se encontrará bajo supervisión médica un par de días más.

Tercer escenario: Llega Pedro Gómez tras sufrir un accidente en automóvil Más tarde, un cuerpo de paramédicos lleva a un joven de mediana edad al hospital. El joven ha salido herido en un accidente de tránsito y si bien no presenta golpes graves, se encuentra con una he- rida profunda en la parte baja del pecho. Elisa recibe a los paramédicos y lo dirige Urgencias, donde es llamado Marco – quien esa noche tiene guardia – para la valoración e intervención del muchacho. El paramédico le indica a Elisa que en sus pertenencias llevaba una identificación de la cual pueden obtener su información personal. Elisa ingresa al sistema y registra un nuevo paciente, realiza la asignación del médico y también le asigna un monitor de signos vitales. Además recuerda que debe registrarse como enfermera del paciente; para ello, en la ventana de Inicio, selecciona la opción de asignación de enfermera y crea una nueva asignación al presionar Nueva asignación e introducir los datos correctos y presionar el botón de Registrar. Marco realiza una intervención médica compleja, pero exitosa. Pedro Gómez – como se llama- ba el joven – debe permanecer bajo supervisión médica en el área de terapia intensiva por un par de días.

174 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Cuarto escenario: Marco quiere visualizar el monitor de Pedro y Pablo desde su computadora de escritorio. Marco se encuentra en una sala en la que puede descansar un rato; piensa que ése ha sido un día pesado pero muy gratificante. Ha podido aplicar exitosamente lo aprendido en su formación como cirujano. De pronto recuerda que le habían comentado que podría ver la información de los monitores de signos vitales desde su computadora, así que la enciende e ingresa al portal interno del hospital. Ahí selecciona un enlace hacia el nuevo sistema. Introduce su nombre de usuario y su con traseña y le es mostrada una pantalla con varios monitores, dos de ellos con asignaciones activas con el nombre de Pedro Gómez y otro con el nombre de Pablo Mendoza. Desea ver si el estado de Pedro no ha presentado complicaciones. Selecciona pues el monitor con el nombre del paciente y ve una pantalla en la que se encuentra información sobre el estado actual del paciente. No se ve complica- ción alguna en su situación actual – piensa – más sería interesante ver si no ha presentado alguna alarma de su estado. Así pues selecciona la opción de Expediente y lo dirige a una pantalla donde ve la información del paciente y puede ver que no hubo alguna complicación posterior. Al terminar de ver esa información, cierra su sesión seleccionando el botón correspondiente y apaga la computadora.

Quinto escenario: Pablo es dado de alta. Don Pablo no ha presentado ningún problema durante su estancia en el hospital. Las pruebas del laboratorio habían confirmado que el padecimiento del Sr. Mendoza era una infección que es posible tratarse y requieriría no demasiados cuidado en lo demás Marco considera que su salud es exce- lente; así pues, tras un par de días en el hospital, Pablo es dado de alta del hospital. Su hijo viene por él y agradece las atenciones que tuvieron con su padre en su estancia. Elisa recuerda que no había terminado la asignación del monitor de signos vitales a Pablo e inicia su sesión y selecciona la opción de Asignaciones de monitores; en la lista que se muestra en la pantalla, selecciona la asignación del paciente: Mendoza, Pablo y le es mostrada la información sobre la asignación. Presiona el botón de Modificar y en las opciones de Modificar asignación de monitor, hace clic sobre el recuadro que dice activado y presiona el botón de Actualizar. Tras ver que la infor- mación ha sido actualizada, presiona el botón de Inicio y se da cuenta que el monitor que antes tenía asignado Don Pablo, ahora aparece sin asignar. ¡Que complejo es quitar la asignación de un monitor! – considera acertadamente – Espero que en un nuevo sistema sea más sencillo esa operación. Finalmente presiona la opción de Finalizar se sión.

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales 175 Sexto escenario: El monitor de Pedro arroja una alarma. Elisa lo atiende y su estado regresa a normal. Marco nuevamente quiere revisar el estado de Pedro, ha presentado una gran mejoría última- mente y cree que pronto será dado de alta. Así que nuevamente selecciona el monitor que tiene asignado y se asegura de que su estado es normal, posteriormente selecciona la opción de ver el Expe diente y ahí se da cuenta que dentro del registro se muestra una alarma y su descripción. Intrigado se dirige con la enfermera y le pregunta por dicha alarma. Elisa le explica que precisamente se arrojó una alarma cuando era la hora de la comida del doctor, sin embargo fue atendida oportunamente y desde entonces el paciente no ha presentado ningúna otra y su estado es estable. Podría ser útil el que me informara al teléfono celular automáticamente – pensó el doctor – po- dría ser una buena mejora al sistema.

176 Desarrollo de un Sistema de Monitoreo Web de Signos Vitales Bibliografía [APL05] W. Richard Stevens et Stephen A. Rago. Advanced Programming in the UNIX® Environment. . 2005. Addison Wesley Professional. [BEN03] BENZ, Brian; DURANT, John R.. XML Programming Bible. . 2003. Wiley Publishing. ISBN: 0-7645-3829-2 [BUR03] BURNS, Alan; WELLINGS, Andy. Sistemas de Tiempo Real y Lenguajes de Programación. tercera edición. 2003. Addison Wesley. ISBN: 84-7829-058-3 [COU95] COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Distributed Systems: Concepts and Design. second edition. 1995. Addison-Wesley. ISBN: 0-201-62433-8 [GAL04] GALLEGOS GALLEGOS, Patricia. "Diseño del sistema de comunicación y manejo de datos de un monitor para unidad de cuidados coronarios". Director: Alfonso Gutiérrez Aldana. Instituto Politécnico Nacional, Centro de Investigación en Computación. 2004. [GUE03] GUEVARA LÓPEZ, Pedro; MEDEL JUÁREZ, José de Jesús. Introducción a los Sistemas en Tiempo Real. . 2003. Instituto Politécnico Nacional. ISBN: 970-36-0105-7 [HUS00] L. HUSTON, Terry; L. HUSTON, Janis, Is Telemedicine A Practical Reality?, (2000). [JES04] JESÚS ORTIZ, Judith G.; DOMANDHA ALVARADO, Israel. "Sistema activo y monitoreo del censado de signos vitales". Director: . Instituto Politécnico Nacional, Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas. 2004. [JUN05] JUNG, D.K., Biosignal Monitoring System for Mobile Telemedicine, (2005). [KOM05] KOMIYA, Ryoichi, A Proposal for Telemedicine Reference Model for Future Standarization, (2005). [LEE97] HO SUNG, Lee et al, Remote Patient Monitoring Service through World- Wide Web, (1997). [NOM99] Comité Consultivo Nacional deNormalización de Regulación y Fomento Sanitario. Norma Oficial Mexicana NOM-168-SSA1-1998, del expediente clínico. . 1999. Diario Oficial de la Federación. ISBN: [PER95] PEREDNIA, D.A.; ALLEN, A., Telemedicine Technology and clinical

CLXXVII applications, (1995). JAMA [POL01] POLLARD, J.K.; ROHMAN, S.; FRY, M.E., A Web-Based Mobile Medical Monitoring System, (2001). International Workshop on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications [ROD05] RODRÍGUEZ ROBLEDO, Gricelda. "Sistema Ubícuo de Historia Clínica del Paciente". Director: Jesús Manuel Olivares Ceja. Instituto Politécnico Nacional, Centro de Investigación en Computación. 2005. [SHA] SHAPLEY GRAY, John. Interprocess Communications in Linux: The Nooks and Crannies. . 2003. Prentice Hall. ISBN: 0130460427 [STE05] STEVENS, Richard; RAGO, . Advanced Programming in the UNIX® Environment. . 2005. Addison Wesley. ISBN: 0201433079 [TIE97] TIERNEY, LM Jr; WHOOLEY MA; SAINT S., Oxygen saturation: a fifth vital sign?, (1997). [ZAK05] ZAKAS, Nicholas C.. Professional JavaScript™ for Web Developers. . 2005. Wiley Publishing. ISBN: 978-0-7645-7908-0 [ZAK06] ZAKAS, Nicholas C.; MC PEAK, Jeremy; FAWCETT, Joe. Professional Ajax. . 2006. Wrox. ISBN: 0471777781

Referencias Web [AST07] Apache Software Foundation,Apache Struts, 2007, http://struts.apache.org/ [BRO03] BROWN, Preston et al,DCOP: Desktop COmmunications Protocol, 2003, http://developer.kde.org/documentation/other/dcop.html [CSU08] Canonical Ltd,Documentation for Ubuntu, 2008, https://help.ubuntu.com/ [END01] EnderUNIX,EnderUNIX Community, 2001, http://www.enderunix.org/documents/eng/daemon.php [GAV07] GAVRILOV, Alexey ,Bubblemark animation test , 2007, http://bubblemark.com/ [GLO05] GLOWIAK, Maciej,Mysql vs postgres, 2005, http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres#Benchmark [JQU07] John Resig and the jQuery team,jQuery: The Write Less, Do More, JavaScript Library, 2007, http://jquery.com/ [MCH07] McHALE, Ciaran,CORBA Explained Simply, 2007, http://www.ciaranmchale.com/corba-explained-simply/

CLXXVIII [MOO07] Valerio Proietti,mootools: the compact javascript framework, 2007, http://mootools.net/ [MS07] Microsoft Corporation,Windows Services for UNIX, 2007, http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx [NBD06] NetBeans Documentation,Creating a CRUD application with Java EE 5 and NetBeans 5.5, 2006, http://www.netbeans.org/kb/55/persistence- demo.html [PEN] PENNINGTON, Havoc et al,D-Bus Tutorial, , http://dbus.freedesktop.org/doc/dbus-tutorial.html [POS07] PostgreSQL,Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007, 2007, http://www.postgresql.org/docs/techdocs.83 [PRO07] Prototype Core Team,Prototype JavaScript framework: Easy Ajax and DOM manipulation for dynamic web applications, 2007, http://www.prototypejs.org/ [PUD04] Puder.org,CORBA Product Profiles, 2004, http://www.puder.org/corba/matrix/ [ROR07] David Heinemeier Hansson and RoR Community,Ruby On Rails, 2007, http://www.rubyonrails.org/ [wAC08] W3C,Access Control for Cross-site Requests, , http://www.w3.org/ TR/access-control/ [wAST07] Wikipedia contributors,Apache Struts, 2007, http://en.wikipedia.org/w/index.php?title=Apache_Struts&oldid=167124730 [wCAK07] Wikipedia contributors,CakePHP, 2007, http://en.wikipedia.org/w/index.php?title=CakePHP&oldid=168374394 [wCX08] Mozilla.org,Cross-Site XMLHttpRequest, 2008, http://developer.mozilla.org/en/docs/Cross-Site_XMLHttpRequest [wDIS07] Discapnet, El portal de la discapacidad,Discapnet: Servicio de glosario, 2007, http://www.discapnet.es/Discapnet/Castellano/Glosario/ [wDWE07] DesarrolloWeb.com,Qué es Streaming, 2007, http://www.desarrolloweb.com/articulos/482.php [wEME07] e-México,Portal e-Salud, 2007, www.e-mexico.gob.mx/wb2/eMex/ eMex_Informatica_Medica [wFCG96] BROWN, Mark R.,FastCGI: A High-Performance Gateway Interface , 1996, http://www.fastcgi.com/devkit/doc/www5-api-workshop.html [wGRA07] Wikipedia contributor,Grails (Framework), 2007, http://en.wikipedia.org/w/index.php?title=Grails_%28Framework

CLXXIX %29&oldid=164959043 [wGRO07] Wikipedia Contributors,Groovy, 2007, http://en.wikipedia.org/w/index.php?title=Groovy&oldid=160244919 [wHL707] HL7,About Health Level Seven, 2007, http://www.hl7.org/about/ [wIA08] Prototype.org,Introduction to Ajax, 2008, http://www.prototypejs.org/learn/introduction-to-ajax [wROR07] Wikipedia contributors,Ruby on Rails, 2007, http://en.wikipedia.org/w/index.php?title=Ruby_on_Rails&oldid=168135351 [wSPR07] Wikipedia contributors,Spring Framework, 2007, http://en.wikipedia.org/w/index.php?title=Spring_Framework&oldid=165419478 [wW306] W3C,Extensible Markup Language (XML) 1.0 (Fourth Edition), 2006, http://www.w3.org/TR/xml [wW399] W3C,XSL Transformations (XSLT)Version 1.0, 1999, http://www.w3.org/TR/xslt [wW3C99] W3C, Hypertext Transfer Protocol - HTTP/1.1, 1999, http://www.w3.org/Protocols/rfc2616/rfc2616.html [wWAF07] Wikipedia contributors,List of web application frameworks, 2007, http://en.wikipedia.org/w/index.php? title=List_of_web_application_frameworks&oldid=167787828

CLXXX Glosario

Ajax JavaScript Asíncrono y XML, Asynchronous JavaScript and XML. Es un grupo interrelacionado de técnicas de desarrollo Web utilizadas para crear aplicaciones Web interactivas.

API Application Interfaz de programación de aplicaciones, Application Programming In- Programming Interface terface. Es el conjunto de funciones y procedimientos que ofrece cierta libre- ría o servicio para ser utilizado por otro software como una capa de abstrac- ción.

Bit Stuffing En la transmisión de datos y telecomunicaciones relleno de bits, bit stuffing es la inserción de bits sin información en los datos. El relleno de bits se utiliza para distintos propósitos como para limitar el número de bits consecutivos del mismo valor en la información a ser transmitida. Un bit del valor opuesto es insertado tras la cantidad de bits máxima permitida. Ya que ésta es una regla general, el receptor no necesita informa- ción extra acerca de los bits agregados para obtener nuevamente la trama ori- ginal. Ésto se utiliza para crear transiciones adicional para asegurar la transmi- sión fiable o para asegurar que ciertas palabras reservadas – como secuencias de sincronización –, no estén contenidas dentro del mensaje.

Capnografía Concentración de dióxido de carbono en el medio ambiente. Utilizan-

do una sonda, permite conocer la concentración de CO2 en la mezcla gaseosa administrada a los pacientes durante la anestesia general, lo que resulta muy útil en ciertas situaciones clínicas (dificultad de intubación, estados de hipercarpnia, embolia pulmonar, hipertermia maligna, etc.) [wDIS07].

Electrocardiograma Registro de la actividad eléctrica producida por el corazón, mediante el sensado y amplificación de los pequeños potenciales generados por éste durante el ciclo cardíaco .

Expediente clínico, Es el conjunto de documentos escritos, gráficos e imagenológicos o de expediente médico cualquier otra índole, en los cuales el personal de salud, deberá hacer los registros, anotaciones y certificaciones correspondientes a su intervención, con arreglo a las disposiciones sanitarias [NOM99].

FastCGI Es un protocolo creado para interconectar programas interactivos con un servidor web. FastCGI es una variación del anteriormente utilizado: CGI.

CLXXXI Framework Un framework o marco de trabajo de software, es un diseño reutilizable para un sistema de software; puede incluir programas de soporte, librerías de código u otro software que pueda ayudar a desarrollar y a unir los diferentes componentes de un proyecto de software.

Gasto cardiaco Volumen de sangre bombeado por el corazón en la unidad de tiempo. Si se toma el minuto por unidad, el gasto cardiaco es igual al volumen de sangre expulsado por el corazón en cada sístole, multiplicado por el número de contracciones por minuto [wDIS07].

HIS, Hospital Un Sistema de Información Hospitalario es un sistema de información Information System integrado y comprensible diseñado para administrar los aspectos administrativos, clínicos y financieros de un hospital. Estos sistemas abarcan tanto el procesamiento de la información en papel como los dispositivos de procesamiento de información.

HL7, Health Level Organización de desarrollo de estándares, Standard Developing Organi- Seven zation (SDO) acreditada por el Instituto Nacional Americano de Estándares, American Nacional Standards Institute (ANSI) operando en el área del cuidado de la salud.

JSON Notación de Objetos en JavaScript, JavaScript Object Notation. Es un formato ligero para el intercambio de información. Es un formato basado en texto que puede ser leído por las personas para representar estructuras de datos simples y arreglos asociativos (denominados objetos).

Oximetría de pulso Termino relativo al método utilizado para medir la saturación de la hemoglobina por el oxigeno. Las técnicas oximetricas pueden dividirse en: 1) Espectrofotometría para el análisis de la Hb in vitro; 2) Oximetria de pulso

(SpO2) para medición no invasiva de la saturación de la Hb y 3) Oximetria fibroptica para la medición invasiva de la saturación de la oxihemoglobina en vivo. Todas ellas se basan en principios espectrofotometricos que miden las porciones de luz transmitida y/o absorbida por parte de la Hb [wDIS07].

Presión Sanguínea La existente en el interior de los vasos de la circulación corporal (intravascular); en sentido estricto es la presión arterial la que se mide en el sistema arterial a la altura del corazón y frente a la presión atmosférica y que depende, por un lado, del rendimiento cardiaco y de la resistencia de los vasos (tono y elasticidad), y, por el otro, de la viscosidad de la sangre; constituye la fuerza impulsora o hemodinámica para la circulación de la sangre. Su regulación se efectúa mediante barorreceptores y quimiorreceptores que envían señales a los centros circulatorios, y los efectores son el sistema nervioso simpático y parasimpático, hormonas suprarrenales, etc [wDIS07].

CLXXXII Socket Es un mecanismo de Comunicación entre Procesos (IPC) que define la interfaz entre una aplicación y la pila del protocolo TCP/IP provista por el sistema operativo. Es un enlace de comunicaciones bidireccional que es asignado a un proceso que desea comunicarse con otros.

CLXXXIII