DESARROLLO DE UN SISTEMA DE MONITOREO WEB DE SIGNOS VITALES.pdf

7/26/2019 DESARROLLO DE UN SISTEMA DE MONITOREO WEB DE SIGNOS VITALES.pdf

1/196

INSTITUTO POLITCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA EN INGENIERA YTECNOLOGAS AVANZADAS

UPIITA

Trabajo Terminal

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales

Que para obtener el ttulo de

Ingeniero en TelemticaPresenta

Mario Alberto Garca Torrea

Asesores

I!" Fraci#co Atoio Polaco Motelo!o

M" e C" No$ Sierra Ro%ero

Dr" e F" Fera&o Marte' Pi()

M$*ico D" F" a +, &e %a-o &el +../


2/196

INSTITUTO POLITCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA EN INGENIERA YTECNOLOGAS AVANZADAS

UPIITA

Trabajo Terminal

Desarrollo de un Sistema de Monitoreo Web de Signos Vitales

Que para obtener el ttulo de

Ingeniero en TelemticaPresenta

Mario Alberto Garca Torrea

Asesores

I!" Fraci#co AtoioPolaco Motelo!o

M" e C" No$ SierraRo%ero

Dr" e F" Fera&oMarte' Pi()

Presidente del Jurado Profesor Titular

M" e C" Mi!0el F$li* MataRi1era

M" e C" S0#aa Araceli S2c3e'N24era


3/196

Agradecimientos

A mi familia

Por e#e(ar%e a creer - a-0&ar%e a crecer5 6or70e #ie%6re 3a e#ta&o a3 c0a&o lo#3e ece#ita&o5 6or e#e(ar%e 70e la# %e4ore# co#a# &e la 1i&a o #o %2# 70e a70ella#70e 3ace%o# co el cora')8 e la# 70e 6o&e%o# #o(ar - alca'ar8 - 6or la# 70e&ebe%o# &e l0c3ar"Gracia# 6a62 6or t0 #abi&0ra - 6or to&o# lo# co#e4o# 70e %e 3a# bri&a&o"Gracia# %a%2 6or 6roc0raro# #ecille' - 6or e#e(aro# a a%ar"Gracia# 3er%ao 6or70e 9 a070e #ie%6re b0#ca# la :or%a &e %ole#tar%e 9 e#t2# a3cre-e&o e %"

A mis amigos

Por70e 3a crei&o e % - %e 3a a6o-a&o co #0 co%6a(a8 #0 ale!ra - co#e4o#"Gracia# 6or a-0&ar%e a crecer - a creer 70e to&o e# 6o#ible #i real%ete 70ere%o# 70ea# lo #ea5 - #obre to&o #i cree%o# e o#otro# %i#%o#" Gracia# 6or #0 co:ia'a83oe#ti&a& - 6or &e6o#itar ta%bi$ e % 0a 6arte &e #0# 1i&a#"

A mis profesoresPor70e #ie%6re 6roc0raro crear 6er#oa# ca6ace#8 6or obli!aro# a crecer o #)lo elo aca&$%ico #io co%o 6er#oa#" Gracia# 6or #0# co#e4o# - e*6eriecia#" Gracia# 6orcreer e 70e e# 6o#ible 0 %e4or :0t0ro - 3acero# 6arte &e $l"

Al Instituto Politcnico NacionalPor70e a 6e#ar &e la# li%itate#8 #i!0e 6roc0ra&o :or%ar 4)1ee# co 0e1a# i&ea# -%2# #0e(o#" Por70e o# 3a &a&o la# 3erra%ieta# t$cica# - la# e*6eriecia# &e #0!ete 6ara :or%aro# - 3acero# crecer"

A MicoPor70e a; creo e #0 !ete - e#o !eera e#6era'a# e 70e #e 60e&e lo!rar 0 %e4or6a# #i #0 !ete8 &etro &e 0 %arco re#6o#able - 3oe#to8 co%6re&e 70e #o%o# 0aaci) - o 0 c;%0lo &e i&i1i&0ali&a&e#"

A !ios Por 6er%itir%e coocer !ra&e# 6er#oa# - coce&er%e tie%6o 6ara &i#:r0tarlo#5 6or&aro# #al0&8 ale!ra8 e#6era'a - co:ia'a e o#otro# %i#%o# 6ara a6re&er &el6a#a&o8 crear 0 0e1o 6re#ete - co:iar e 0 %e4or :0t0ro"


4/196

Lista de Contenidos

Captulo 1 Introduccin1.1 Antecedentes 11.2 Planteamiento del problema 1

1.2.1 Solucin propuesta 11.3 Objetivos 2

1.3.1 Objetivo General 21.3.2 Objetivos Especficos 2

1. !ustificacin 31." #eneficios Esperados 1.$ Alcances % &mites 1.' Or(ani)acin de la *esis

Captulo 2 Marco Terico2.1 +ntroduccin '2.2 Estado del arte ,

2.2.1 Antecedentes ,2.2.2 -onitoreo de si(nos vitales 11

ariables biol(icas consideradas 112.2.3 /omunicacin entre procesos 12

+nterfaces de Pro(ramacin de Aplicaciones 1/O0#A-&0P/Socets4/OP4#5S

4aemons6 Procesos ejecut7ndose en se(undo plano 1$2.2. Sistemas distribuidos % modelo /lienteServidor 1'2.2." Sistemas de *iempo 0eal 18

*olerancia a 9allos 18

*:cnicas de tolerancia a fallos 1,2.2.$ Aplicaciones ;eb 2ivel /ero 3,3..2 S- Server en /-anejo de la informacin en el cliente ,

.2.$ Posibles mejoras ,$.3 >oi=6 Sistema ;eb ,8.3.1 Pistac@e ,8

Aplicaciones en Grails ,,Se(uridad6 /ontrol de Accesos+nternacionali)acin Hi18>I

.3.2 >oisette 1


8/196

A.1 Administracin de pacientes 11'A.1.1 Secuencias de Administracin de Pacientes 123

A.2 Administracin de m:dicos 12$A.3 Administracin de enfermeras 132

Ap#ndice $ Diccionario de Datos

Ap#ndice C Anlisis de las alternati%as para el desarrollo &e/.1 Streamin( de datos % dibujado din7mico de (r7ficas 13

/.1.1 Streamin(6 -anejo de flujos de informacin 13El objeto -&ttp0eCuest 13

/.1.2 Prueba de streamin( de datos 1&mites de !avascript 1'

/.1.3 4ibujado din7mico de (r7ficas en el nave(ador 18

Ap#ndice D 'rotocolos del (iste)a4.1 >otas sobre la implementacin 1"34.1.1 Sobre el manejo de memoria % cadenas 1"34.1.2 Sobre la compilacin en &inu= 1"34.1.3 Sobre la compilacin en ;indo?s 1"3

4.2 Protocolo de transmisin de informacin al Servidor Amande 1"4.2.1 /ontenedores 1""4.2.2 Protocolo del entilador 1"$

PaCuete de +nformacin 1"$PaCuete de Alarma del entilador 1"8

5so de las rutinas para formacin de paCuetes 1"84.2.3 >otas sobre los dem7s protocolos 1$oisette 1


13/196

.esu)enAbstract: 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 nmeric data in !eb browsers" This Information System

also handles information abot physicians, nrses, patients in addition to therelationships among them and the patient#s medical record"

En las unidades de cuidados intensivos se da soporte a los sistemas or(7nicosde los pacientes Cue se encuentran crticamente enfermosJ reCuiriendo supervisin% monitoreo intensivoJ es aCu donde se encuentra uno de los principales puntos deatencin dentro del 7rea telem:dica.

En el presente trabajo se desarrolla un sistema Cue recopila la informacinobtenida por los monitores de si(nos vitales correspondientes a los pacientes de terapia intensiva dentro de un @ospitalK dic@a informacin se visuali)a por el staffm:dico tanto en la central de enfermeras como mediante el acceso al sistema mediante una p7(ina ?eb utili)ando un nave(adorJ @aciendo uso de la red interna del@ospital.

Palabras clave6 monitoreo web, monitoreo de signos vitales, ajax, programacinen red, signos vitales, telemedicina, sistemas de informacin hospitalarios.

X


14/196

Captulo 1 Introduccin

Cualquier tecnologa suficientemente avanzada,es indistinguible de la magia.

!rthur Charles Clar"e

1/1 Antecedentes&a telemedicina puede ser definida como el uso de las tecnolo(as de telecomunicaciones para

proveer informacin % servicios m:dicos LPE0,"M. *ambi:n busca la conver(encia de informacinm:dica para propsitos de dia(nstico % tratamiento de pacientes utili)ando computadorasJ enlacesde telecomunicacionesJ audioJ video % eCuipo de im7(enes especiali)ado. &a telemedicina consistetanto en consultas interactivas en tiempo real como el procesamiento de informacin del pacientepara su posterior dia(nstico HasncronoI L5S


15/196

alarmas (eneradas en los monitoresJ al personal indicado. &a fi(ura1.1muestra un bosCuejo del dia(rama (eneral del sistema.

1/3 0!eti%os

1.3.1 Objetivo General4esarrollar un sistema en tiempo real Cue permita el acceso remoto a la informacin obtenida

por monitores de si(nos vitales.

1.3.2 Objetivos Especficos Obtener informacin de cada uno de los monitores.

4efinir el modelo de comunicaciones Cue ase(ure el correcto funcionamiento del sistema.

2

#igura $.$% &iagrama esquem'tico de la solucin propuesta

4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


16/196

4iri(ir la informacin a los mdulos correspondientes.

Almacenar la informacin recibida en el disco duro.

Establecer el modelo de almacenamiento Cue cause una menor car(a al sistema.

4esple(ar la informacin en un monitor (eneral.

-anejar las alarmas. 4esple(ar las alarmas en el monitor (eneral.

Almacenar las alarmas.

Publicar la informacin en un servidor ?eb para el acceso remoto.

Generar el e=pediente m:dico del paciente.

1/4 usti,icacin

&a telemedicina ofrece un 7rea bastante amplia de aplicacin de la telem7tica pues :sta ofrecesoluciones Cue aprovec@an la siner(ia e=istente entre las telecomunicaciones % la inform7ticaJ %a Cuese necesita no slo el conocimiento de un 7rea u otraJ si no de ambas para poder optimi)ar el uso derecursos al ser estos limitados % emplear % mejorar t:cnicas Cue ase(uren los reCuisitos de estabilidad % se(uridad de dic@os sistemas.

Si bien en un principio los costos de investi(acin e implementacin de sistemas de telemedicina pudieran ser elevadosJ ofrecer servicios remotos puede presentar una reduccin en costos al no tener necesidad de encontrarse directamente el paciente con el m:dicoK reduciendo as la cantidad deconsultas fsicas. Adem7s una de las principales aplicaciones se presenta al ofrecer servicios en lu(ares

donde tener instalaciones m:dicas pueda ser costoso % la solucin de teleconsultas pueda ser altamente conveniente.

En -:=ico e=isten pocas empresas Cue se dedican al desarrollo e implementacin de estos sistemasJ pues se @a visto Cue soluciones como la propuestaJ @a sido apenas objeto de investi(acin %pruebas en otras universidades o centros de investi(acinJ pues el reto de reali)ar un sistema m:dicoJradica no slo en el uso de las @erramientas idneas para su implementacin si no tambi:n implicainvesti(acin % desarrollo de nuevas tecnolo(as % responsabilidad al desarrollar aplicaciones del 7ream:dica.

Nste pro%ecto est7 enfocado principalmente al monitoreo en tiempo real de ciertas variables %aunCue se busca definirlo para informacin de cualCuier tipoJ el trabajo se enfocar7 a variables m:dicas. El principal reto es ofrecer una baja latencia adem7s de caracteri)ar el sistema de forma (en:rica %especiali)arlo en aplicaciones telem:dicas fijas buscando CueJ a futuroJ puedan implementarse aplicaciones telem:dicas mviles utili)ando el modelo propuesto. As puesJ uno de los alcances de este pro%ecto es proporcionar t:cnicas o modelos Cue permitan la implementacin de streamingde datosJofrecer nuevas perspectivas en cuanto a su uso para monitoreo de cualCuier proceso mediante @erramientas ;eb.



17/196

1/5 $ene,icios *sperados

4esarrollar un sistema Cue permita un mejor acceso a la informacin de los monitores desi(nos vitales por el staffm:dico.

-ejorar la administracin de e=pedientes m:dicos al almacenarlos en formato di(ital.

Establecer los criterios necesarios para el desarrollo de aplicaciones de monitoreo remotoJpara permitir utili)ar esta investi(acin en desarrollos futuros.

1/ Alcances y L)ites

&a meta principal de cualCuier sistema de monitoreo es clara. El sistema debe a%udar al usuario un m:dicoJ enfermera o t:cnico a @acer su trabajo m7s efectivoJ interesante % menos e=tenuante1.

AunCue lo establecido en este pro%ecto es principalmente una aplicacin de distintas tecnolo(asJ se busca definir los puntos Cue son necesarios considerar al implementar este tipo de sistemas % va

rios similaresJ pues aunCue aCu se consideran seDales cu%a latencia debe ser bajaJ pueden usarse loscriterios establecidos en :ste desarrollo en monitoreo de seDales cu%as caractersticas no impliCuenCue deba ser tan r7pido su procesamiento.

El sistema se desarrollar7 considerando 2< monitores de si(nos vitales.

El formato del e=pediente m:dico se ape(ar7 a los reCuerimientos o definiciones delos est7ndares establecidos por el &'.

1/ 0r-aniacin de la Tesis

En el captulo 1 se @an establecido los conceptosJ objetivos e ideas Cue definen el conte=to deltrabajo desarrollado en esta tesisK es decirJ el planteamiento del problema % la solucin propuesta.

El captulo 2 busca ampliar al(unos conceptos definidos en el captulo 1 e=poniendo el estadodel arte de los sistemas de monitoreo m:dicosJ telemedicina % las tecnolo(as e=istentes Cue permitenel desarrollo de aplicaciones ?eb. a Cue cae fuera del alcance de esta tesis el establecer todo el desarrollo tericoJ t:cnicasJ procedimientos % tecnolo(asK el marco terico solo contiene la informacinsuficiente para introducir al lector a los puntos definidos % determinar la forma en la Cue buscamosutili)ar dic@as tecnolo(as.

As puesJ se invita al lector a investi(ar m7s sobre las tecnolo(as e=istentes % las tendencias tecnol(icas Cue circundan el desarrollo de sistemas como el propuesto % lo e=@ortamos a consultar labiblio(rafa en la cual nos @emos apo%ado.

1 Steven 0. 4ellerJ et al. (tilization of a )mall Computer for *eal +ime Continuous atient -onitoring.A/-

4 4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


18/196

En el captulo 3 se muestra el an7lisis % diseDo del sistema propuesto.

El captulo presenta el desarrollo del pro%ecto en base a su implementacin % el manejo de lastecnolo(as definidas en el captulo 2.

El captulo " muestra las pruebas % los resultados obtenidos en :stas.

9inalmenteJ el captulo $ contiene las conclusiones obtenidas en base a las pruebas % e=periencias en el desarrollo del pro%ecto.



19/196


20/196

Captulo 2 Marco Terico

l esfuerzo de utilizar las m'quinas para emular el pensamiento humano siempre me ha parecidobastante est/pido. referira usarlas para emular algo mejor

dsger &ij"stra

2/1 Introduccin4ebido a la arCuitectura del sistema % su interaccin con dos tipos de clientes uno encar(ado

de proveer la informacin correspondiente % los otros capaces de visuali)ar la informacin obtenidade los primeros se propone dividir el sistema en dos subsistemas6 Administrativo % de -onitoreo.

El subsistema administrativo ser7 el encar(ado de permitir al usuario el re(istro de nuevos elementos en el sistemaJ es decir re(istrar m:dicosJ pacientes % enfermerasJ % permitir las operaciones deactuali)acin de informacinJ eliminacin % consulta. El subsistema de monitoreo consistir7 de lasaplicaciones necesarias para la transmisin de informacin desde los monitores de si(nos vitales a unservidor centralJ al procesamiento de la informacin recibida % su almacenamiento % distribucin alos clientes ;eb.

En base a lo establecido anteriormenteJ se lo(ran identificar en el sistema ciertas problem7ticasen las Cue debemos de interesarnos % Cue establecen la base de la investi(acin necesaria para el desarrollo del sistema6

Transmisi$n

*anto los monitores como el servidor de monitores e incluso los clientes ;ebJconllevan distintos enfoCues de transmisin de informacin adem7sJ se @a establecido

Cue dic@a transmisin se establecer7 de forma inal7mbricaK por lo tantoJ @abiendo establecido Cue la tecnolo(a de transmisin ser7 utili)ando +EEE 8


21/196

Acceso y mantenimiento de la informaci$n

El servidor de monitoreo adem7s de recopilar informacin de los monitores desi(nos vitalesJ debe de permitir almacenar % visuali)ar dic@a informacin % relacionarlaa los pacientes correspondientes. Adem7sJ al llevarse tambi:n un determinado controlsobre los m:dicos % enfermerasJ sus pacientes asi(nados % el acceso a la informacin delos pacientes Cue les correspondan Hcontrol de accesosIJ es necesario @acer uso de @erramientas Cue nos permitan manejar esa informacinJ mantener los re(istros % modificar % visuali)ar la informacin.

Al ser sistemas Cue permiten el acceso desde la red o en una determinada posibilidad desde +nternetJ as mismo se considera de (ran importancia el uso de @erramientas Cue nos brinden esas capacidades por lo tantoJ se necesita reali)ar una investi(acin sobre losframewor"spara el desarrollo de aplicaciones ;eb.

Acceso !eb

Adem7s de ofrecer las caractersticas de recopilacin % administracin de la informacinJ la visuali)acin de la misma es tambi:n importante. &a visuali)acin de lainformacin necesita presentar un entorno sencillo % familiar al usuarioK as puesJ parapoder presentar la informacin lo m7s similar posible a su visuali)acin en un monitorin situJ es necesario considerar las t:cnicas Cue nos permitan obtener % procesar flujosde datos Hstreamin(I % visuali)arlos.

Es por ello Cue se establece la necesidad de investi(ar sobre los objetos o @erramientas Cue nos permitan reali)ar dic@as actividades en entornos ;eb es decirJ crearAplicaciones 0icas de +nternet.

Es debido a lo anterior Cue en este captulo se establecer7n los conceptos necesarios para el se(uimiento de esta tesis. &os primeros puntos se enfocar7n al monitoreo de si(nos vitalesJ se definir7nlos puntos Cue se deben de considerar en este tipo de monitoreo % se listar7n % definir7n los tipos deseDales biol(icas a las Cue @aremos referencia en el trabajoK posteriormenteJ se mostrar7 una perspectiva (eneral de los modelosJ t:cnicas % tecnolo(as e=istentes para el desarrollo del sistema. En la fi(ura2.1se muestran las consideraciones de tecnolo(as necesarias para llevar a cabo el pro%ecto.

" 4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


22/196

En los captulos si(uientes se desarrollar7 el an7lisis % diseDo del sistemaJ posteriormente se des

cribir7 la implementacin % se listar7n las pruebas del sistema % los resultados obtenidos. Si bien el orden l(ico del pro%ecto de investi(acin a mi parecer debe contemplar primero el an7lisis % el diseDo del sistema % posteriormente establecer las tecnolo(as necesarias para su desarrolloJ aCu suponemos Cue es necesario antes establecer las tecnolo(as % @acer uso de :stas para definir el diseDo.

2/2 *stado del arte

2.2.1 #ntece$entes

&a telemedicina puede ser definida como el uso de las tecnolo(as de telecomunicaciones paraproveer informacin % servicios m:dicos LPE0,"M. *ambi:n busca la conver(encia de informacinm:dica para propsitos de dia(nstico % tratamiento de pacientes utili)ando computadorasJ enlacesde telecomunicacionesJ audioJ video % eCuipo de im7(enes especiali)ado. &a telemedicina consistetanto en consultas interactivas en tiempo real como el procesamiento de informacin del pacientepara su posterior dia(nstico HasncronoI L5S


23/196

nua. Se considera Cue la telemedicina es una aplicacin importante de las *ecnolo(as de +nformacin % /omunicaciones H*+/QsI % forma parte tambi:n del concepto esalud L?E-E


24/196

%ecto Cue se propone en esta tesis tiene una e=tensin ma%orJ ambos trabajos pueden ser de (ran a%uda durante el desarrollo de este pro%ecto.

En el mercado e=isten dispositivos Cue permiten la visuali)acin en una central de enfermeras de los monitores de si(nos vitales Cue se encuentren conectados a :lJ principalmente desarrolladospor la empresa-ennen -edicalcorrespondiendo al modelo nguard 5iew.

2.2.2 'onitoreo $e si(nos vitalesistricamenteJ las tasas de respiracin % pulso @an sido los primeros si(nos vitales debido a

Cue su determinacin no recae en cualCuier instrumento Cue un reloj. &a temperatura corporalJpresin san(unea % saturacin de o=(eno reCuieren instrumentos CueJ estrictamente @ablandoJdeben ser considerados pruebas de dia(nstico m7s Cue si(nos vitales. &a adicin de los tres anterioresa las tasas de pulso % respiratorias se @a debido a Cue los instrumentos utili)ados termmetroJesfi(momanmetro % monitor de o=(eno dactilar son poco costososJ reutili)ables % no invasivos. Esm7sJ la informacin derivada de los cinco refleja el funcionamiento fisiol(ico crucial L*+E,'M.

El monitoreo de si(nos vitales se reali)a in situpor un dispositivo denominado monitor m:dicoo monitor de si(nos vitales el cual adCuiere las seDales necesarias % reali)a el procesamiento apropiadopara determinar los si(nos vitales del paciente.

ariales iol-icas consideradas

&os si(nos vitales considerados en el desarrollo del pro%ecto se definen en la tabla acontinuacin L?4+S


25/196

Variable %escripci$n

&lectrocardiograma Es el re(istro de la actividad el:ctrica producida por el cora)nJmediante la medicin % amplificacin de los peCueDos potenciales(enerados por este durante el ciclo cardaco.

'(imetr)a de plso *:rmino relativo al m:todo utili)ado para medir la saturacin de la

@emo(lobina por el o=i(eno. &as t:cnicas o=im:tricas puedendividirse en6 1I Espectrofotometra para el an7lisis de la b in vitroK2I O=imetra de pulso HSpO2I para medicin no invasiva de lasaturacin de la b % 3I O=imetra fibroptica para la medicininvasiva de la saturacin de la o=i@emo(lobina en vivo. *odas ellas sebasan en principios espectrofotom:tricos Cue miden las porciones delu) transmitida %Uo absorbida por parte de la b.

*apnograf)a /oncentracin de di=ido de carbono en el medio ambiente.5tili)ando una sondaJ permite conocer la concentracin de /O2 enla me)cla (aseosa administrada a los pacientes durante la anestesia(eneralJ lo Cue resulta mu% til en ciertas situaciones clnicas

Hdificultad de intubacinJ estados de @ipercarpniaJ embolia pulmonarJ@ipertermia mali(naJ etc.I.

+resi$n Sang)nea &a e=istente en el interior de los vasos de la circulacin corporalHintravascularIK en sentido estricto es la presin arterial la Cue se mideen el sistema arterial a la altura del cora)n % frente a la presinatmosf:rica % Cue dependeJ por un ladoJ del rendimiento cardiaco %de la resistencia de los vasos Htono % elasticidadIJ % por el otroJ de laviscosidad de la san(reK constitu%e la fuer)a impulsora o@emodin7mica para la circulacin de la san(re. Su re(ulacin seefecta mediante barorreceptores % Cuimiorreceptores Cue envan

seDales a los centros circulatoriosJ % los efectores son el sistemanervioso simp7tico % parasimp7ticoJ @ormonas suprarrenalesJ etc.

asto cardiaco olumen de san(re bombeado por el cora)n en la unidad de tiempo.Si se toma el minuto por unidadJ el (asto cardiaco es i(ual al volumende san(re e=pulsado por el cora)n en cada sstoleJ multiplicado por elnmero de contracciones por minuto.

+abla 2.$% 5ariables biolgicas consideradas

2.2.3 )o*unicacin entre procesos&a comunicacin entre procesos se refiere al intercambio de informacin entre dos o m7s @ilos

o procesos. 4ic@os procesos pueden estar en la misma m7Cuina o distribuidas en una red.

El tema de las t:cnicas de comunicacin entre procesosJ 0nter1rocess Communications H+P/I esampliaJ desafiante % din7mica. *odos los sistemas operativos proveen m:todos para comunicacin entre procesos. *iempo atr7sJ 5>+ soportaba unas cu7ntas construcciones rudimentarias para comu



26/196

nicaciones entre procesos como arc@ivos prote(idosJ seDales % tuberasJpipes. A principios de los8+ de A*V*. Al mismo tiempoJ la 4istribucin de Soft?are de #erele%J6er"ele4 )oftware &istributiona(re( soporte para los protocolos de +nternet % la interfa) soc"etcomoconstruccin de comunicaciones. A mediados de los ,+.LSAM

En el pasadoJ la 0Cfue un conjunto de distintos acercamientosJ pocos de los cuales eran portables entre distintas implementaciones de sistemas 5>+. L...M tras los esfuer)os de estandari)acin lasituacin mejorJ sin embar(o las diferencias an e=isten. &a tabla 2.2resume los distintos tipos de+P/ Cue son soportados por distintas implementaciones. LS*Eamed fullduple= pipes

opcin S+5ni= 4omain

Socets

opcionalJ 5ni=4omainSocets

5ni= 4omainSocets

SiJ 5ni=4omainSocets

-essa(eBueues

S+ Si Si Si

Semap@ores S+ Si Si Si Si

S@ared-emor%

S+ Si Si Si Si

Socets Si Si Si Si Si

S*0EA-S opcin S+ opcional Si

78)0 9 8:;pen )4stem 0nterfaces, 8)0< es una especifcacin suplementaria a la )ingle (nix)pecification

+abla 2.2% )oporte de 0C en distintas implementaciones

Sin embar(o se @an desarrollado otras implementaciones de +P/ Cue establecen una capa sobreel sistema operativoJ permitiendo as Cue se puedan implementar pro(ramas Cue ocupen interfaces omensajes nicos Cue sean manejados por esas capas de forma transparente a las aplicaciones. 4ic@asinterfaces de pro(ramacin de aplicacionesJ!pplication rogramming 0nterfacesHAP+IJ pueden tenerimplementaciones o especificaciones para distintos sistemas operativos o distintos len(uajes de pro(ramacin. E=isten diversas tecnolo(as de +P/ enfocadas a la solucin de distintos tipos de proble



27/196

mas o aplicaciones6 4/OPJ -&0P/J SOAPJ /O0#AJ +/E entre otras. En la si(uiente seccin sedescribir7n al(unas de ellas resaltando sus caractersticas % enfoCues.

Inter,aces de 'ro-ra)acin de Aplicaciones

Entre las AP+s independientes de plataforma en las Cue nos enfocaremosJ encontramos /O0

#AJ -&0P/ % soc"ets.

)O+,#

Common ;bject *equest 6ro"er !rchitectureJ es un est7ndar diseDado para el soporte de +P/orientados a objetos. E=isten distintas implementaciones o motores O0# J Cue definen una capa desoft?are Hmiddle?areI Cue permite Cue los objetos puedan reali)ar llamadas a m:todos de otros situados en m7Cuinas remotasJ *emote rocedure CallsH0P/I. Nsto es llevado a cabo mediante seriali)acinJ marshallingJ en la cual se trasforma la representacin de los objetos en memoria a un formatoapropiado para poder transmitirlo o almacenarlo.

4e las diversas implementaciones e=istentes de O0#J se inclu%en O0#itJ -+/O /O0#A %A/E O0#. En LP54+ se comuniCuen con otros procesos en una m7Cuina remota dentro de una red. &os soc"etscompatibles #S4 es la interfa) uniforme entre los procesos de usuario % las capas del protocolo de reden el ncleo del sistema. &os soc"etspueden tambi:n ser utili)ados para comunicarse con otros procesos dentro del mismo servidorJ a lo Cue se le conoce como 0nter1rocess CommunicationsH+P/I.

Posteriormente se desarroll una variante especificada en el est7ndar de +nterfaces para SistemasOperativos PortablesJ ortable ;perating )4stem 0nterfacesHPOS+IK este est7ndar definido por el +nstituto de +n(enieros El:ctricos % ElectrnicosJ 0nstitute of lectrical and lectronics ngineersH+EEEI



28/196

define las llamadas al sistema necesarias para permitir Cue una misma aplicacin pueda ejecutarse endistintas plataformas. Actualmente los sistemas &inu= se ape(an parcialmente al est7ndar POS+Jpues al comen)ar a cobrar la +EEE por el est7ndar % no permitir su publicacin en +nternetJ se creotra especificacin libre llamada )ingle (=08 )pecificationcubriendo puntos similares a la POS+.

AunCue se @a definido un subsistema 5>+ sobre el ncleo de ;indo?s >* Cue se ape(a al

est7ndar POS+ L-S


29/196

Entre las!0sdependientes de la plataforma en este caso 5>+ est7n6 4/OP % 4#5S.

)O/

El protocolo de comunicacin de escritorioJ &es"top Communication rotocolH4/OPIJ es unsistema de comunicacin entre procesos +P/ utili)ado en sistemas R4E L#0O?.Posteriormente debe de finali)ar el padre dejando al proceso @ijo como @u:rfanoJ as :stepasar7 a ser @ijo del proceso init.

1" Independiar el proceso

Es necesario eliminar la dependencia Cue tiene respecto a la terminal Cue lo inici. Esto esJ



30/196

Cue el control est7 li(ado a la terminal en la Cue se inici el proceso % es necesario independi)ar el proceso de dic@a terminal asi(n7ndole un nuevo (rupo de procesos utili)ando lallamada setsid>?.

7" &liminar los descriptores de &ntrada;Salida innecesarios

4" &stablecer m" *aptra de se?ales

Es necesario capturar las seDales % actuar correctamente respecto a dic@os eventos.

@" egistro de bit


31/196

2.2. Siste*as $e 5ie*po +eal5n Sistema en *iempo 0ealJ *eal +ime )4stemH0*SI es aCuel sistema Cue responde a estmu

los e=ternos % el tiempo en el Cue debe producir resultados correctosJ se encuentra especificado.

5n 0*S cumple tres condiciones primordiales LG5E


32/196

4efectos provocados por una interferencia transitoria o permanente en el subsistema decomunicaciones ad%acente.

As como tambi:n se definen tres tipos de fallos6

9allos transitorios. ACuellos Cue comien)an en un instante de tiempoJ se mantiene en elsistema un cierto periodo % desaparece.

9allos permanentes. /omien)an en un instante determinado % permanecen en el sistema @asta Cue son reparados.

9allos intermitentes. 9allos transitorios Cue ocurren ocasionalmente.

&a creacin de sistemas fiablesJ debe considerar todos los puntos anterioresJ para as evitar Cue:stos ocasionen un comportamiento errneo en el sistema.

En L#50


33/196

El c$mpto imprecisopropone evitar las fallas de tiemposJ reduciendo la precisinde los resultados en forma controladaJ considerando as Cue el resultado de la tarea esimpreciso m7s sin embar(o el sistema si(ue funcionando % entre(ando respuestas dentro de los m7r(enes definidos.

&as t:cnicas de recperaci$n hacia atr


34/196

sin embar(o las tendencias en su desarrollo indican Cue se incorporar7n distintas tecnolo(as Cue @ar7n indiferente el uso de un dispositivo u otro con ma%ores capacidades. Entre dic@as tecnolo(as delas Cue se(uramente se se(uir7n considerando durante al(n tiempo m7s se encuentran6 !avascriptJ-&J S&* % A!A.

2.2.! 5ecnolo(as $e Internet

a%ascript

Es un len(uaje interpretado Cue permite Cue los desarrolladores puedan determinar cmo puede interactuar el usuario con una p7(ina ?eb permitiendo el procesamiento de informacin en ellado del cliente. +nicialmente fue incorporado en la versin 2.< del nave(ador >etscapeK desde entonces !avascript @a sido una de las tecnolo(as principalmente utili)adas en el desarrollo de aplicaciones?eb. En 1,,' fue adoptado como un est7ndar E/-AJ denomin7ndolo E/-AScript. !avascriptofrece una sinta=is bastante similar a la de !ava % / sin embar(o no es un len(uaje orientado a objetosJ aunCue se @an creado ciertas t:cnicas para dotar de al(unas de esas caractersticas al len(uaje.

!avascript no se compone nicamente de E/-AScriptJ si no tambi:n del modelo de objeto deldocumentoJ &ocument ;bject -odelH4O-I % del -odelo objeto del nave(adorJ 6rowser ;bject -o1delH#O-IJ con los cuales se puede manejar informacin del nave(ador % del documentoJ adem7s delas caractersticas de procesamiento provistas por E/-AScript.

El libro LWAR


35/196

mento L?;3


36/196

-& en cualCuier otro formato basado en te=to. Generalmente se utili)a para transformar -& en*-&J aunCue :se es solamente uno de sus usos.

&a recomendacin de *ransformacin S& describe el proceso de aplicar una @oja de estilosS& a un documento -& utili)ando un motor de transformacin L?;3,,M.

&as transformaciones S&* @an sido utili)adas para convertir o acoplar el formato -& a un

formato Cue sea comprensible o utili)able por la aplicacin Cue lo necesite. AsJ es posible definir cierta informacin en un formato claro para los @umanos % el motor de transformacin se encar(ar7 detraducir dic@o formato en otro definido por las plantillas en la @oja de estilos S&.

5n ejemplo de dic@as transformaciones se da en el desarrollo de interfaces (r7ficas usandoG&A4E en &inu=. El arc@ivo (enerado es un -& Cue posteriormente en tiempo de ejecucin ocompilacinJ el motor se encar(a de transformar en una interfa) (r7fica basada en G*R.

A!a8

!avascript asncrono % -& H!s4nchronous Davascript and 8-I

El desarrollo de las aplicaciones de +nternet @a supuesto un problema su poca interactividad. &atransmisin de informacin entre el cliente % servidor se ejecuta bajo los m:todos GE* % POS* definidos en el protocolo **P L?;3/,,M lo cual representa Cue la comunicacin entre el nave(ador% el servidor siempre se lleva a cabo tras la peticin del usuario al @acer clic sobre un botn o unvnculo.

Se @an desarrollado diversas t:cnicas Cue permiten car(a asncrona de recursosJ empe)ando conel uso de los elementos iframe% la4er% utili)ando !avascript pueden car(ar informacin en se(undoplano % mostrarla al @aberla car(ado completamenteK posteriormente -icrosoft introduce un objetollamado5M3Dttpe9estCue permitira reali)ar esas operaciones de una forma m7s simple utili

)ando el len(uaje -&K el cual se implementara posteriormente por otros desarrolladores de nave(adores proporcionando as una cierta interfa) comn para la transferencia asncrona. Sin embar(o laimplementacin de dic@os objetos es inconsistente aunCue el ;3/ @a comen)ado a elaborar unaespecificacin sobre este objeto las diferencias en su implementacin en los distintos nave(adores@a ocasionado Cue sea necesario utili)ar ciertas t:cnicas para ase(urar una compatibilidad entre ellos.

En la fi(ura 2.3podemos ver la diferencia entre los modelos de comunicaciones sncrono %asncrono. El objeto -&ttp0eCuest es parte esencial de Aja=J pues es (racias al uso de dic@o objeto % el len(uaje !avascriptJ permitiendo un ma%or (rado de interactividad % facilidad de uso de lasaplicaciones ;eb.



37/196

Adem7s de las ventajas ofrecidas por el manejo asncrono de la informacinJ es importante seDalar Cue esa asincrona derivada en un incremento de la interactividad con el usuario se e=plota utili

)ando las t:cnicas del *-& 4in7micoJ &4namic 3+-H4*-&I.

En el ap:ndice #J se encuentra una prueba de streaming de datosJ utili)ando t:cnicas de Aja= %dibujado din7mico de (r7ficas.

E=isten muc@as referencias en la ?eb sobre Aja=J sin embar(o LWAR


38/196

(unas de ellasJ Adobe 9le= % Open &as)lo.

0ecientemente otras compaDas @an desarrollado alternativas Cue compiten con 9las@K por parte de -icrosoft se encuentra Silverli(@t % por Sun -icros%stems se presenta !ava9J con lo Cue sebusca incorporar a los desarrolladores de sus plataformas en el desarrollo de aplicaciones de +nternet.

2.2." 7ra*e8or0spara el $esarrollo $e aplicaciones 6ebablando de desarrollo de aplicaciones ?ebJ e=isten una (ran cantidad de @erramientas orien

tadas a una amplia variedad de usos. E=isten tambi:n entornos o aplicaciones Cue permiten Cue elservidor pueda no slo ofrecer contenido est7tico como elementos *-&J im7(enesJ audio J si notambi:n contenido din7mico (enerado en base a peticiones a bases de datosJ interaccin con otros sistemasJ etc. Entre esas @erramientas encontramos tambi:n al(unos marcos de trabajoJframewor"sJ Cueproveen una cierta metodolo(a para el desarrollo de ciertas aplicaciones.

En la tabla 2.3se muestran al(unos de losframewor"spara desarrollo ;eb m7s utili)ados juntocon el len(uaje en el Cue est7 basado L?;A9


39/196

"ra)e:or;s para desarrollo de aplicaciones &e orientadas al )odeloMC

El patrn modeloJ vista controladorJ-odel 5iew ControllerH-/IJ es un patrn arCuitectnico Cue busca separar ciertas aplicaciones en 3 etapasJ cada una de las cuales se enfocan a la representacin l(ica de la informacinJ la etapa de re(las de ne(ocio o procesamientoJ % la visuali)acin o in

terfa) (r7fica.E=isten distintas implementaciones en las diversas tecnolo(as e=istentes para desarrollar aplica

ciones en el lado del servidor. Entre los Cue utili)an el len(uaje !ava encontramos !pache )truts,Arails % Dava )erver #aces >D)#?K de los Cue utili)an .>E* est7n-ono*ailJ !pache )pring .=+ %-averic" .=+K sin embar(o destaca *ub4 on *ails basado en 0ub% debido a la facilidad % claridad del desarrollo de soluciones simples en dic@o marco de trabajo.

a Cue la implementacin del servidor ser7 bajo el sistema operativo &inu=J noconsideramos .>E* como alternativa puesJ aunCue el pro%ecto -ono L???.monoproject.comM seencuentra en un nivel lo suficientemente estableJ es preferible contar con @erramientas Cue cuenten

con el respaldo necesario de las compaDas o comunidades correspondientes en dic@o sistema operativo. &as tecnolo(as sobre las cuales desarrollaremos esta actividadJ ser7n 0ub% on 0ailsJ Apac@e Struts% /ae PP.

+ub on +ails

0ub% on 0ails H0o0I sur(e en 1,, como un pro%ecto de #asecampJ una @erramienta de administracin de pro%ectos de la compaDa 3' si(nals. El verdadero aporte de 0ub% on 0ails al desarrollo de aplicaciones ;eb es el populari)ar ciertas caractersticas Cue permiten manejar al(unas tareasde forma m7s sencilla % automati)adaK un ejemplo de ello es el scaffolding% el mapeo objeto relacionalJ object1relational mappingHO0-I L?0O0


40/196

Cue @a ocasionado % Cue (racias a su popularidad se @an afian)ado t:rminos % filosofas Cue son importantes en el desarrollo de aplicaciones.

En +nternet podemos encontrar (ran cantidad de documentacin % ejemplos del desarrollo deaplicaciones en 0o0. Por ejemploJ supon(amos tenemos una tabla en una base de datos con el nombre People. Cueremos crear todas las operaciones sobre una PersonaJ es decirJ re(istrar una personaJ

visuali)ar % poder modificar su informacin % eliminar al(una persona re(istrada. &a (eneracin de laaplicacin se reduce a las si(uientes operaciones6

Antecedentes6 *enemos una tabla People en una base de datos. &a tabla contendr7 la informacin Cue es deseable almacenarJ como los nombresJ apellidosJ edadJ etc:tera. *ambi:n tenemos instalado el frame?or 0ails % el controlador de la base de datos respectivo.

1. Nos situamos en la carpeta donde deseamos crear la aplicacin.

2. Tecleamos

rails nombre_aplicacion

3. Dentro de la carpeta nombre_aplicacion/config modificamos el archivo database.ymlintroducimos el nombre del controlador del mane!ador de la base de datos el nombre deusuario y contrase"a de acceso a la base de datos y el nombre de la base de datos

correspondiente.

#. Tecleamos

ruby script/generate scaffold Person

$. Tecleamos

ruby script/server

%. &ccedemos ahttp'//localhost'3(((/people/on estos pasos @emos creado una aplicacin utili)ando el modelo -/J % podemos reali)ar

las operaciones /054 sobre personas. &a @erramienta scaffold@a creado el modeloJ vista % controladores sobre los re(istros de la base de datos. &a convencin sobre los nombres de las tablas % clases enla (eneracin de la aplicacinJ @a permitido Cue todo esto se realice autom7ticamenteJ @aciendo eneste caso el mapeo de Person como clase a una tabla contenedora de personas People en in(l:s.

#pac9e Struts

Apac@e Struts es un framewor"para desarrollar aplicaciones !ava Empresariales. 5tili)a % e=tiende el AP+ !ava Servlet para alentar a los desarrolladores a adoptar la arCuitectura -/ L?AS*


41/196

macin entre la vista % el modeloI. Struts provee el controlador Hun servlet conocido como ActionServletI % facilita la escritura de plantillas para la capa de vista o presentacin. El pro(ramador deaplicaciones ;eb es responsable de escribir el cdi(o del modelo % crear un arc@ivo de confi(uracincentral llamado strutsconfi(.=ml Cue enla)a las tres capas.

>o e=iste @erramienta al(una como scaffolden 0o0J para Struts. *ampoco contamos con un

m:todo oframewor"para el mapeo objeto relacionalJ con la cual podamos servirnos del patrn Active0ecord % manipular los re(istros de una base de datos como un objeto. Para :stoJ es necesario utili)aral(una otra @erramienta como ibernate. >et#eans ofrece ciertas funcionalidades Cue permiten undesarrollo m7s 7(il de aplicaciones basadas en Struts % !S9 como frame?or de arCuitectura e ibernate como frame?or de persistencia. Struts 1.= es criticado debido a distintas carencias en su diseDoJsin embar(o en las versiones 2.= se mejoran muc@os de esos aspectos.

En L>#4et#eans "." % (enerar una aplicacin similar a la Cue se @a e=puesto anteriormente en 0o0.

Sprin( 7ra*e8or0

Es unframewor"de cdi(o abierto de desarrollo de aplicaciones para la plataforma !ava. +nicialmente no fue diseDado para se(uir el patrn -/J sin embar(o los desarrolladores de Sprin( decidieron escribir su propio framewor" de red como una reaccin al pobre diseDo del popularStrutsL?SP0


42/196

3. Dentro de la carpeta nombre_aplicacion/grails)app/conf modificamos el archivo

Data*ource.groovy introducimos el nombre del controlador del mane!ador 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.#. Tecleamos

grails generate-domain-classes

$. Tecleamos

grails generate-all

%. Tecleamos

grails run-app

+. &ccedemos ahttp'//localhost',(,(/nombre_aplicacion

)a0e /:/

/ae es un frame?or para el desarrollo de aplicaciones r7pidas en PP. Es una estructura delibreras clases % una infraestructura en tiempo de ejecucin para pro(ramadores de aplicaciones ;ebinspirado en el frame?or de 0ub% on 0ails L?/AR


43/196

3. Al declarar la variable \scaffoldJ /ae autom7ticamente (enerar7 el manejador de Personas.

. En el nave(ador accedemos a la direccin donde ten(amos instalado /ae % al subdirectorioUpeople.

"ra)e:or;s del lado del clienteEntre los framewor"sdel lado del cliente Cue pueden interesarnosJ son aCuellos basados en

A!A se(n se estableci en los apartados de tecnolo(as ?eb % dibujado de (r7ficas din7micas aspuesJ entro losframewor"se=istentes m7s utili)ados para el desarrollo de aplicaciones o interfaces ricasen el lado del cliente se encuentran6 protot%pe.jsJ dojoJ jCuer%J spr% % mootols.

/rototpe.js

Protot%pe es unframewor"basado en !avaScript orientado al desarrollo sencillo % din7mico deaplicaciones ;ebJ implementa las t:cnicas de A!A % aunCue no ofrece efectos visualesJ e=isten otros

frame?ors Cue se basan en Protot%pe para ofrecer estas caractersticas como 0ico % Script.aculo.usLP0Oacional Americano de Est7ndaresJ !merican

=ational )tandards 0nstituteHA>S+I operando en el 7rea del cuidado de la salud. &a ma%ora de losS4O produce est7ndares Hal(unas veces llamados especificaciones o protocolosI para un dominio particular del cuidado de la salud como farmaciaJ dispositivos m:dicosJ im7(enes o transacciones de se(uros. El dominio del &' es la informacin clnica % administrativa L?&'


44/196

de 0e(istros de PacientesJ atient *ecord !rchitectureHP0AIJ provee de un modelo de intercambiopara documentos clnicos % acerca a la industria del cuidado de la salud a la reali)acin de re(istrosm:dicos electrnicos.

-ediante el uso del -&J el -odelo de +nformacin de 0eferenciaJ *eference 0nformation -o1delH0+-I % vocabularios codificadosJ el /4A crea documentos tanto le(ibles para las m7Cuinas as

pues son f7cilmente anali)ados % procesados de forma electrnica % le(ibles por las personas aspueden ser f7cilmente recuperados % utili)ados por las personas Cue lo necesiten. &os documentos/4A pueden ser mostrados utili)ando nave(adores ;eb Cue soporten -& o aplicaciones inal7mbricas como tel:fonos celulares.

)onfor*acin $el eorma Oficial -e=icana H>O-I 1$8SSA11,,,J L...Mestablece los criterios cientficosJ tecnol(icos % administrativos obli(atorios en la elaboracinJ inte(racinJ uso % arc@ivo del e=pedientem:dico L>O-,,M.

&os reCuisitos (enerales para la elaboracin del e=pedienteJ se definen a continuacin. *odo e=pediente clnico deber7 contener los si(uientes datos (enerales6

*ipoJ nombre % domicilio del establecimiento %J en su casoJ nombre de la institucin ala Cue pertenece.

En su caso nombre % denominacin social del propietario o concesionario.

>ombreJ se=oJ edad % domicilio del usuario.

En L>O-,,M se consideran otros puntos para las notas m:dicas en servicios de @ospitali)acinJur(enciasJ reportes del personal profesionalJ t:cnico % au=iliar % otros documentos. Sin embar(o paraefectos de este trabajoJ se considerar7n los puntos m7s estrec@amente relacionados con el monitoreo %

el almacenamiento de la informacin obtenida para en base a :sta (enerar los e=pedientes.

2/3 .esu)en

&as tecnolo(as definidas en este captuloJ suponen la base del desarrollo de este pro%ecto. Sibien en :l no se @a profundi)ado en el desarrollo de las aplicaciones ?ebJ fundamentos e @istoriaK seinvita al lector a leer un poco m7s en la biblio(rafa recomendada pues no cabe de m7s saber cmofuncionan las aplicaciones actuales % cmo podran implementarse nuevas. *ambi:n se esbo)an lascaractersticas de al(unos documentos Cue son necesario obtener para as aclarar cu7les son las necesi

dades % Cue documentos son necesarios Cue elabore el sistema.



45/196


46/196

Captulo 3 Anlisis y Diseo de la

Aplicacin

!unque el ingenio humano pueda crear invenciones varias que,por la a4uda de varias m'quinas respondiendo al mismo fin,

nunca producir' ninguna invencin m's bella, ni m's simple,ni m's apropiada que las que hace la =aturaleza del @ospital. Para acceder al sistema ;ebJ los miembros del staffdeben de autenticarse

con la contraseDa % nombre de usuarios asi(nados al momento de sure(istro.

.acilidades de so

9actores @umanos % Est:ticos

&a disposicin de ventanas % elementos de accin HbotonesJ mensI debede lo(rar una interfa) clara % familiar al usuario de los monitores de si(nosvitales.

&a interfa) (r7fica debe de tener fondos oscuros Cue permitan resaltar elcontraste con la informacin mostrada en pantalla.

En todo momento no se debe de perder de vista la informacin delelectrocardio(rama HE/GI de los pacientes.

&as alarmas deben visuali)arse de modo tal Cue no interfieran con elfuncionamiento o visuali)acin de los dem7s elementos del sistemaJ perodebe ser visible % obtenerse el foco de atencin del usuario.

&a informacin mostrada en pantalla sobre los monitores de si(nos vitalesJdebe de representarse en color rojo al arrojarse ciertas alarmas.

*onfiabilidad

9recuencia % severidad de fallas

&a frecuencia de fallas debe ser baja.



48/196

Al presentarse una falla el sistema debe continuar su funcionamientonormal.

0ecuperacin a fallos

Puede ser necesario considerar al(unas t:cnicas de tolerancia a fallos paraase(urar la inte(ridad de la informacin de los e=pedientes m:dicos.

endimiento

El sistema debe soportar un m7=imo de 2< monitores de si(nos vitalesfuncionando al mismo tiempo.

e9isitos de Implementaci$n

Est7ndares 0eCueridos

Se reCuiere Cue el formato de los e=pedientes m:dicos si(a lasespecificaciones definidas para el e=pediente m:dico electrnico del +-SSJCuienes si(uen los est7ndares definidos por el &'K adem7s de la

>O-1$8SSA11,,8.&en(uajes de implementacin

Para los monitores de si(nos vitales debe de manejarse las @erramientasincluidas en 6orland CJJ 6uilder 2KKLJ adem7s de cualCuier otra libre Cuefuncione sobre @indows 8 mbbeded.

En los servidoresJ los len(uajesJ @erramientasJ sistemas operativos %manejadores de bases de datos no est7n restrin(idos.

e9isitos de Interfa

El hardware Cue se considera para los monitores de si(nos vitales es una

computadora HP/IJ implementado por el /entro de +nvesti(acin e +nnovacin*ecnol(ica del +nstituto Polit:cnico >acional H/++*E/+P>I con las si(uientescaractersticas6

-otherboard 4 chipset+A Hrendimiento similar a un Pentium I"12 -# 0A--onitor *7ctil*arjetas de adCuisicin de si(nos vitales HvariasI*arjeta de red inal7mbrica +EEE 8


49/196

3/2 Ar=uitectura de la Aplicacin

3.2.1 Escenariosa informacin sobre las camas o monitores no presenta una gran cantidad de movimientos. &e he1

cho, solamente se registran una vez 4 son ocasionales las operaciones de modificacin o eliminacin.

&scenario 6: Kegistro de enfermeras y mLdicos en el sistema"

5n m:dico o enfermera necesita ser re(istrado en el sistema. El administrador recopila su informacin HnombreI % se le asi(na autom7ticamente un identificador en el sistemaJ un nombre de usuario % una contraseDa. *ras @aberse re(istrado cualCuiera de ellos puede ser asi(nado a pacientes Cue seencuentren en el sistema.

&scenario 2: N3legada de n paciente al


50/196

consultar el e=pediente del pacienteJ donde se mostrar7 la informacin re(istrada del paciente al re(istrarse. Adem7sJ se ofrece la opcin de Cue pueda accederse al @istorial de monitoreo.

&scenario 4: KSelecci$n de monitor;paciente

!ntecedentes% sta opcin es la opcin por defecto en el caso de acceder al sistema utilizando un na1vegador @eb.

5n miembro del staffCue @a seleccionado dic@a opcin o un usuarioJ Cue accede por un nave(ador denominado cliente ;eb puede seleccionar de una lista el nombre del un paciente Cue seencuentre en monitoreoJ % ser7 diri(ido a la visuali)acin del monitor completo de dic@o paciente.

&scenario 0: K*onslta de e(pediente mLdico

!ntecedentes% 3aber seleccionado la opcin de expediente mMdico dentro del monitorextendido.

5n miembro del staffo un cliente ;ebJ pueden acceder al e=pediente m:dico donde se mostrar7 la informacin capturada en el re(istro del pacienteJ @ora de entradaJ sus m:dicos % enfermerasasi(nados % otra informacin de importancia Cue se @a%a (enerado en el transcurso del monitoreocomo alarmas activadas.

&scenario =: KSitaci$n de alarma

/uando un monitor de si(nos vitales Cue se encuentre re(istrado en el sistema arroje una alarmaJ :sta debe visuali)arse dentro de cualCuier ventana Cue se encuentre utili)ando el staffen la formade un aviso emer(ente describiendo brevemente la situacin de alarma % en Cu: monitor o cama sepresent.

3.2.2 #ctores

Ad)inistrador

Es parte del staff % es Cuien puede re(istrar nuevos usuarios al sistemaJ dar de alta pacientesJasi(narles m:dicos % enfermerasJ modificarlos o darlos de baja.

(ta,,

-iembro del cuerpo de m:dicos % enfermeras Cue puede acceder al sistema para visuali)ar losmonitoresJ e=pedientes e @istorial de monitoreo de los pacientes asi(nados al sistema. &a principal diferencia entre los miembros del staff a los /lientes ;ebJ es el medio de accesoJ limit7ndose :ste al ac

ceso desde la central de enfermeras.

Cliente &e

-iembro del staffCue accede al sistema utili)ando un nave(ador ;eb.

3!4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


51/196

(iste)a de Ad=uisicin

Sistema desarrollado por el /++*E/ +P> en los monitoresJ encar(ado de obtener informacin de los sensores. E=iste un subsistema encar(ado de recopilar la informacin obtenida por el Sistema de AdCuisicin % formar paCuetes para transmitirlos posteriormente al Servidor ofreciendo as al-onitor de Si(nos italesJ de ciertas capacidades de comunicacin en red.

3/3 Consideraciones del diseo

&a actividad inicial del diseDo de cada uno de los mdulos @aba considerado Cue el sistema poda dividirse en mdulos. Sin embar(o tras la investi(acinJ especificacin de reCuerimientos % el an7lisis del sistemaJ nos @emos dado cuenta de Cue el diseDo basado en mdulos no es la mejor solucinal problemaJ pues no se estaba considerando el funcionamiento del sistema en (eneral era proponeruna arCuitectura sin siCuiera @aber comen)ado el diseDo . Es as como en el diseDo podemos ver objetos Cue pueden ser catalo(ados con esos roles6 AlmacenamientoJ *ratamiento de las alarmasJ de

-onitoreo % del >cleo HprincipalesIJ m7s sin embar(o no necesariamente componen subsistemaspor s mismos. *ras @aber finali)ado el diseDo podremos definir la arCuitectura adecuada.

5tili)ando la simbolo(a del an7lisis de robuste)J robustness anal4sis% la asi(nacin de estereotipos a las clases identificadasJ podemos diseDar el sistema de forma tal Cue se si(a el modelo -/ enlos casos correspondientes.

3" 4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


52/196

3/4 Casos de uso >enerales

3.4.1 >ivel )ero

En el dia(rama Cue se muestra en la fi(ura 3.1se en(loban los casos de uso principales del sistema.

Adem7s de dividir el sistema en dos subsistemas cada uno correspondiente tanto al monitorde si(nos vitales como al servidor de monitores J tambi:n se pueden cate(ori)ar los casos de uso enAdministrativos % de -onitoreo.

3%

#igura E.$% &iagrama del nivel cero de casos de uso del servidor de monitores



53/196

3.4.2 VS' Server

Autenticar

Este caso de uso es el antecedente a los dem7s casos de uso administrativos del sistemaJ pues ve

rifica Cue el usuario pueda acceder al mismo % restrin(e las opciones Cue se presentan al usuario. &assecuencias de autenticacin de usuarios se muestran en las fi(uras 3.8J 3.,% .

I1 )aso $e uso? ).S.#ut9

>o*bre $e )aso $e 2so? #utenticar

)rea$o por? 'ario #. Garca 5orrea @lti*a actualiAacin por?

7ec9a $e creacin? 1!B1&B2&&! 7ec9a $e actualiAacin?

#ctores? ?suario @Ad)inistrador (ta,, Cliente &eB

1escripcin? Es el caso $e uso correspon$iente a la autenticacin $el usuario./resenta las opciones a las Cue =ste pue$e acce$er $epen$ien$o $esu nivel $e acceso.

1ispara$or? Seleccin $e la opcin Inicio de (esinen una pantalla $e inicio

/recon$iciones?

/oscon$iciones? #l 9aberse autentifica$oD les sern *ostra$as las opciones a las Cuepue$en acce$er para utiliAar el siste*a.

7lujo >or*al 1. El usuariointro$uce su no*bre $e usuario su contraseFaen los ca*pos correspon$ientes $a clic en un botn $eIniciar (esin.

2. El siste*a verifica Cue el no*bre $e usuario contraseFacorrespon$an con los al*acena$os verifica su nivel $eacceso #$*inistra$orD Staff o )liente 6ebH.

3. 5ras 9aberse verifica$o el nivel $e accesoD se *uestran lasopciones correspon$ientes a $ic9o nivel.1. En el nivel $e a$*inistra$or se *uestran las opciones $e

#$*inistracin $e pacientesD #$*inistracin $e *=$icos enfer*eras

2. En el nivel $e staffD se *uestra el *onitor (lobal.3. En el nivel $e )liente 6ebD se *uestra la seleccin $e

*onitores eo*bre $e usuario Bo contraseFa incorrectosD favor $everificarlosJ.

+abla E.2% Caso de uso !utenticacin

4& 4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


54/196

Ad)inistrar personas

Este caso de uso en(loba a los casos de uso Cue reali)an operaciones administrativas re(istroJmodificacin de informacinJ consulta % eliminacin del sistema para cada uno de los miembrosCue operan en el sistema enfermerasJ m:dicos % pacientes J en la fi(ura3.2se muestra el dia(ramadel caso de uso correspondiente.

a Cue el objetivo principal del pro%ecto es la obtencin de los si(nos vitalesJ su monitoreo %almacenamientoJ se @ar7 un ma%or an7lisis respecto a los casos de uso correspondientes. Por lo tantoJlos casos de uso derivados de Administracin se describen fuera del cuerpo principal del trabajo % m7sdetalladamente en el Ane=o A.

I1 )aso $e uso? ).S.#$*in

>o*bre $e )aso $e 2so? #$*inistrar personas


7ec9a $e creacin? 1!B1&B2&&! 7ec9a $e actualiAacin?

#ctores? Ad)inistrador

1escripcin? Es el caso $e uso correspon$iente a la a$*inistracin K re(istroD*o$ificacin $e infor*acin eli*inacin K $e pacientesD *=$icos enfer*eras.

1ispara$or? Seleccin $e la opcin Ad)inistracinen la pantalla principal.

/recon$iciones? El Ad)inistrador$ebe 9aber acce$i$o al *enL $e a$*inistracinautenticn$ose en una pantalla inicial.

/oscon$iciones? #l re(istrarse un paciente se al*acena la infor*acin necesaria paraestablecer su eor*al #l Ad)inistradorle son *ostra$as las cate(oras $e a$*inistracin?Ad)inistracin de pacientesD ad)inistracin de )#dicos ad)inistracin de en,er)erasD a$e*s $e las opciones para volveral *enL anterior.

7lujos #lternativos? )ancelacin $e la operacin.+e(resa a las opciones $e la pantalla principal

+abla E.E% Caso de uso !dministrar personas



55/196

42

#igura E.2% &iagrama de casos de uso de !dministrarpersonas



56/196

er )onitores

Este caso de uso considera las operaciones de acceso para visuali)acin de los monitores remotos. Permite acceder al monitor (lobal a los miembros del staffCue se @a%an autenticado como talespero el acceso no est7 permitido como cliente ;eb. AsJ el monitor (lobal ser7 accedido por el staffdesde la central de enfermeras % slo se permitir7 el acceso a un monitor a la ve) a los /lientes ;eb.

El dia(rama de casos de uso asociadoJ se muestra en la fi(ura 3.3 % las secuencias asociadas sepresentan en las fi(uras 3.1< % 3.11.

I1 )aso $e uso? ).S.#$*in.1

>o*bre $e )aso $e 2so? Ver *onitores


7ec9a $e creacin? 1&B1&B2&&! 7ec9a $e actualiAacin?

#ctores? (ta,, Cliente &e

1escripcin? /er*ite el acceso a la visualiAacin $e *onitores? el *onitor (lobal *onitores e


57/196

er detalle de )onitor

Este caso de uso describe el acceso a un solo monitor. El staffpuede as visuali)ar la informacin completa del monitor de si(nos vitales de un paciente a la ve)J a diferencia del monitor (lobal enel cual se muestra la informacin reducida de todos los pacientes. El dia(rama se encuentra en la fi(ura3..


>o*bre $e )aso $e 2so? Ver $etalle $e *onitor



#ctores? (ta,, Cliente &e

1escripcin? /er*ite el acceso a la visualiAacin $e *onitores? el *onitor (lobal

*onitores e


58/196

Ad)inistrar )onitores

Estos casos de uso se refieren al manejo de la cone=in con el monitorJ el re(istro del monitoren el sistemaJ el emparejamiento de los dispositivos % la transmisin de comandos por ejemploJ parael establecimiento de la informacin Cue es necesaria transmitir a una frecuencia m7s alta para su desplie(ue en pantalla.

El dia(rama del caso de uso se muestra en la fi(ura 3."J adem7s las secuencias consideradas dentro de este caso de usoJ se presentan en la fi(ura3.13J3.1% 3.1".


>o*bre $e )aso $e 2so? #$*inistrar *onitores



#ctores? Monitor de (i-nos itales1escripcin? Es el caso $e uso principal Cue utiliAa el Monitor de (i-nos itales

para co*unicarse con el (er%idor de )onitores.)onte*pla los casos $e uso $e re-istro del )onitor en el siste)aDe)pare!a)iento el estaleci)iento de la ,recuencia del)onitor.

1ispara$or? El 'onitor $e Si(nos Vitales se conecta al siste*a trans*ite ciertos*ensajes a$*inistrativos.

/recon$iciones? E


59/196

4

#igura E.P% &iagrama de casos de uso de !dministracin de monitores



60/196

.eciir in,or)acin

Este caso de uso se compone de las operaciones necesarias para recibir la informacin del monitor % procesarla. &a secuencia relacionada al caso de usoJ se muestra en la fi(ura 3.12.

&as actividades relacionadas a la recepcin % procesamiento de la informacinJ se muestran en

las fi(uras 3.23J 3.2% 3.2"K adem7sJ las secuencias asociada a este aso de uso se presentan en las fi(uras 3.12% 3.1'.


>o*bre $e )aso $e 2so? +ecibir infor*acin



#ctores? Monitor de (i-nos itales

1escripcin? Es el caso $e uso Cue se ejecuta al obtener infor*acin $el Monitorde (i-nos itales. -a infor*acin recibi$a se procesa $irecciona alcaso $e uso correspon$iente K a sea /rocesa*iento $e Infor*acino /rocesa*iento $e #lar*as .

1ispara$or? Se reciben *ensajes $e infor*acin provenientes $el Monitor de(i-nos italesD en el (er%idor de )onitores.

/recon$iciones? E


61/196

3.4.3 'onitor $e Si(nos Vitales

9i%el Cero

&os casos de uso asociados al -onitor de Si(nos italesJ contempla solamente el caso de trans

misinJ el cual se encar(ar7 de formar paCuetes de informacin o alarmasJ % los transmitir7 al Servidor de monitores.

Trans)itir

Este caso de uso describe el comportamiento del monitor de si(nos vitalesJ en el Cue el sistemade adCuisicin se encar(a de formar los paCuetes Cue ser7n transmitidos al servidor de monitores desi(nos vitales dependiendo de las polticas establecidas.

El dia(rama de casos de uso asociado se presenta en la fi(ura 3.'% el dia(rama de actividadesCue describe mejor el comportamiento de este proceso se muestra en la fi(ura3.22.

4"

#igura E.L% &iagrama del nivel cero de casos de uso del monitor de signos vitales



62/196


>o*bre $e )aso $e 2so? 5rans*itir



#ctores? (iste)a de Ad=uisicin (er%idor de )onitores @receptorB1escripcin? Es el caso $e uso asocia$o a las operaciones $e trans*isin $e

infor*acin.-a infor*acin obteni$a por el (iste)a de ad=uisicinK$esarrolla$o por el )II5E) I/> D se e*paCuetar trans*itir al(er%idor de )onitores.

1ispara$or? n te*poriAa$or se activa al lle(ar a cierto tie*po.5o$a la infor*acin obteni$a por el (iste)a de Ad=uisicinse 9arecopila$o en un paCuete al cu*plirse el plaAo $el te*poriAa$or seactiva el caso $e uso.

/recon$iciones? El te*poriAa$or 9a lle(a$o a & se 9a reinicia$o. El (iste)a de

Ad=uisicinobtiene infor*acin $e los sensores asocia$os en el*onitor.

/oscon$iciones? Se for*ar un paCuete con la infor*acin recopila$a se trans*itiral (er%idor de )onitores.

7lujo >or*al? 1. El Siste*a $e a$Cuisicin recopila infor*acin $urante eltie*po Cue el te*poriAa$or funcione.

2. )uan$o el te*poriAa$or 9a cu*pli$o su plaAoD se for*a unpaCuete con la infor*acin obteni$a.

3. Se for*a un nuevo paCuete en el cual se al*acena lainfor*acin Cue se 9a recopila$o $urante este proceso.

4. #l finaliAar $e trans*itirse la infor*acin el te*poriAa$or se

restablece co*ienAa nueva*ente el ciclo.7lujos #lternativos? 1. >o 9a coneo se realiAa nin(una trans*isin.2. :a alertas

1. #l e


63/196

3/5 Dia-ra)as de (ecuencia

Autenticacin de usuarios

&

#igura E.R% )ecuencia !utenticacin !dministrador

#igura E.S% )ecuencia !utenticacin )taff



64/196

isualiacin de )onitores

1

#igura E.$$% )ecuencia 5er detalle de monitor

#igura E.$K% )ecuencia 5er monitor global



65/196

.ecepcin de in,or)acin

Ad)inistracin de )onitores

Secuencia re(istro

2

#igura E.$2% )ecuencia *ecibir informacin

#igura E.$E% )ecuencia *egistro de monitor



66/196

Secuencia e*pareja*iento

Secuencia establecer frecuencia

3

#igura E.$O% )ecuencia mparejamiento de monitor

#igura E.$P% )ecuencia stablecer #recuencia de -onitor



67/196

(trea)in-

'rocesar alerta

4

#igura E.$L% )ecuencia de )treaming

#igura E.$Q% )ecuencia rocesar !lerta



68/196

3/ Dia-ra)a de Clases

Clases persistentes

#igura E.$R% &iagrama de Clases ersistentes



69/196

Dia-ra)a >eneral

#igura E.$S% &iagrama general de clases



70/196

'a=uete Co))unications

'a=uete &eApp

!

#igura E.2$% &iagrama de clases del paquete @eb!pp

#igura E.2K% &iagrama de clases del paquete Communications



71/196

3/ Dia-ra)as de Acti%idades

Trans)isin

"

#igura E.22% !ctividades de +ransmisin de informacin



72/196

.ecepcin de In,or)acin

'rocesa)iento de In,or)acin

%

#igura E.2E% !ctividades de *ecepcin de 0nformacin

#igura E.2O% !ctividadesde rocesamiento de

0nformacin



73/196

Al)acena)iento de In,or)acin

&

#igura E.2P% !ctividades para !lmacenamiento de0nformacin



74/196

3/ Dia-ra)as de 'a=uetes

Dia-ra)a -eneral de pa=uetes

1

#igura E.2L% &iagrama de paquetes



75/196

3/ Dia-ra)as de Desplie-ue

2

#igura E.2Q% &iagramas de despliegue



76/196

3/1E Diseo de la ase de datos

En el sistemaJ es necesario almacenar informacin de los pacientesJ m:dicos % enfermeras parapoder mantener un re(istro sobre el e=pediente o @istorial m:dico de los pacientesJ la informacin

obtenida por los monitores % determinar Cuienes fueron los m:dicos % enfermeras asi(nados a su caso.4ic@a informacin de la cual debe (enerarse el e=pediente m:dico est7 contenida dentro de la>O-1$8SSA11,,8.

a Cue el sistema no busca llevar la administracin del personalJ se consideran por el momentola informacin (eneral establecida en las (eneralidades de la >O-1$8SSA11,,86

Informaci$n re9erida

Pacientes >ombre HsIJ apellidosJ se=oJ fec@a de nacimientoJ domicilio.

-:dicos >ombresHsIJ apellidos

Enfermeras >ombresHsIJ apellidos

+nstitucin Cue brinda el servicio *ipoJ nombre % domicilio del establecimiento

En las fi(uras 3.28 % 3.2,se muestran el dia(rama entidadrelacin % el modelo relacional.

3

#igura E.2R% &iagrama ntidad1*elacin



77/196

4

#igura E.2S% -odelo *elacional



78/196

3/11 'untos cla%e del diseo

3.11.1 )aracteriAacin $e la infor*acin a trans*itir

"or)acin del )ensa!e

/ada sensor transmite 1$ bits de informacin H2 #%tesI. Esa informacin es transmitida utili)ando +EEE 8


79/196

&a estructura de este mensaje no se encuentra bien definida actualmenteJ pues no se @an determinado los servicios Cue debe ofrecer el servidor a los monitores % los servicios de control Cue debende ofrecerse en el monitorJ como pueden ser retransmisin de tramasJ cambio en el tamaDo de paCuetesJ o en la frecuencia de transmisin. 5Mase modelo de transmisin

Mensa!e de in,or)acin si)ple

os mensajes de informacin simple se reciben por los puertos de comunicaciones asignados por el ser1vidor.

El mensaje de informacin simple contiene la informacin proveniente de los dispositivos deadCuisicin en el monitor de si(nos vitales.

&os dispositivos de adCuisicin est7n identificados por un nmeroJ el cual corresponde a al(uno de los dispositivos Cue se enlistan a continuacin.

Variable obtenida Bdispositivo FC Id

E/G 1

O=imetra de pulso 13

/apno(rafa 1

Presin respiratoria HventiladorI 1"

9lujo % volumenrespiratoriosHventiladorI

1"

Presin no invasiva 1$

Presin invasiva 1'

Gastocardiaco 18

*emperatura 1,

^ &os dispositivos de adCuisicin (eneralmentese relacionan con slo una variable. En el casodel ventiladorJ :ste obtiene tres variablesdistintas.

+abla E.P% &ispositivos de adquisicin

&a composicin del mensaje se muestra en la fi(ura3.3


80/196

&a informacin del sensorJ debe estar codificada de tal forma Cue pueda ser delimitadaJ es decircono)camos el inicio % el fin del paCuete de informacin. Esto puede lo(rarse utili)ando cadenas delimitadoras o un campo de tamaDo del contenido. &as cadenas de inicio % fin HdelimitadorasIJ contienen una secuencia de bits Cue no debe aparecer en el campo de informacin. Para poder lo(rar estoJpodemos usar la t:cnica de relleno de bits Hbit stuffingI.

Al considerar Cue un mensaje puede contener m7s de un paCuete de informacin del mismosensorJ la lon(itud vara nuevamenteJ con lo cual es necesario considerar el tamaDo m7=imo de los paCuetes % las frecuencias de aparicin para determinar as el tamaDo m7=imo del mensaje % modificar elcampo de tamaDo.

asta el momento se cuenta con la informacin mostrada en la si(uiente tabla6

%ispositivo .recencia demensaje

Tama?o de mensaje 'bservaciones

entilador 1< ) ariable

b%tes de cabecera3 1"< b%tes de contenido*amaDo m7=imo6 1"b%tes

Obtiene la presinJ flujo % volumen

respiratorios % los estados de lasalarmas del dispositivo.

/apno(rafa 2< ) /onstante11 b%tes de cabecera" b%tes de contenido*amaDo constante de 21b%tes

Electrocardio(rama 1


81/196

El paCuete de datos est7 compuesto de la si(uiente forma6

1 b%te ariable se(n tipo

*ipo 4atos

4onde los tipos m7s comunes se muestran en la tabla 3.'.

Tipo %escripci$n

8" &ectura del porcentaje de o=i(eno

8$ alores al final de cada inspiracin

8' alores al fin de cada espiracin

1


82/196

&os mensajes de alerta contienen el identificador del sensor % el cdi(o de la alerta relacionadosal mismo % un par7metro de prioridad. Estos mensajes permitir7n Cue en el servidor se puedan mostrar al(una alerta audiovisual una ve) anali)ando dic@o paCuete.

El par7metro de prioridadJ debe establecer Cue en caso de e=istir varias alertasJ estas deben decumplirse en base a dic@a prioridad. As un mensaje de alerta con una prioridad m7s alta Cue cual

Cuier otro en la pila de alertasJ debera de atenderse antes Cue los dem7s.5n ejemplo del contenido de un mensaje de alerta definido dentro de los paCuetes de informa

cin del ventilador se muestra a continuacin.

Alarmas /yte %etalle

*ipo 1 1o utili)adoJ siempre debe ser cero

+abla E.R% +ipos de alarmas arrojadas por el ventilador

%4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


83/196

3.11.2 iseFo $e las interfaces (rficas

Inicio de sesin

&a pantalla de inicio de sesin consta nicamente de un formulario en el Cue es necesario intro

ducir el nombre de usuario % contraseDaJ dar clic en el botn de Aceptar % ser7n diri(idos a otra p7(ina en caso de corresponder correctamente dependiendo del perfil Cue ten(an asi(nados o les ser7mostrado un mensaje de errorJ en el cual es necesario volver a introducir el nombre de usuario % contraseDa correctos para poder continuar.

!&

#igura E.E$% #ormulario de autenticacin



84/196

.e-istro

GeneralmenteJ los formularios de re(istro constan nicamente de campos de te=to en los Cue esnecesario introducir la informacin correspondiente para re(istrar un pacienteJ m:dico o enfermeraen el sistema.

!1

#igura E.E2% #ormulario de registro genMrico



85/196

$Fs=ueda

&os formularios de bsCueda nicamente contienen un campo de te=to con el cual se reali)ar7la bsCueda dentro del nombre completo del pacienteJ m:dico o enfermera. El formulario de bsCueda permite posteriormente acceder a las opciones de visuali)arJ modificar o eliminar el re(istro completo de Cuien corresponde.

!2

#igura E.EE% #ormulario de b/squeda



86/196

Central de en,er)eras

&a pantalla de visuali)acin de informacin consta de elementos comunes Cue se busca conservar en la interfa) (r7fica a lo lar(o del uso de la aplicacin. &os elementos Cue podemos identificar enprimera instanciaJ son las barras superior e inferior.

&a barra superior es informativaJ puede mostrar par7metros como la @oraJ nombre del pacienteu otra informacin relevante.

&a barra inferior es para nave(acin. Permite Jen el caso de utili)ar monitores e=tendidosJ visuali)ar el si(uiente monitor o re(resar al anterior o re(resar al men principal % acceder a la administracin de m:dicosJ pacientes % enfermeras. Esta barra tambi:n esta considerada para incorporarse a lasinterfaces administrativas.

!3

#igura E.EO% &istribucin general de los elementos de la interfaz gr'fica de la aplicacin



87/196

Monitor -loal

El monitor (lobal permite visuali)ar todos los monitores de si(nos vitales de forma reducidaJ esdecirJ mostrando solamente el electrocardio(ramaK al(unos par7metros num:ricos % el nombre del paciente. 5na ve) seleccionando un monitor podemos acceder a su informacin e=tendida J es decirJ almonitor de si(nos vitales e=tendido.

!4

#igura E.EP% -onitor global 4 detalle de monitor reducido



88/196

Monitor e8tendido

El monitor e=tendido busca presentar la misma informacin Cue los monitores de si(nos vitalesin situ. &os monitores e=tendidos presentan todas las (r7ficas % par7metros num:ricos disponibles sobre la adCuisicin de si(nos vitales.

0tros ele)entos de la inter,a

+e(in $e alar*as

Se @an planeado dos formas de mostrar las alertas. 5na puede ser considerada como una alertavisual invasiva % otra no invasiva.

En la alerta invasivaJ buscamos Cue se muestre una pantalla o re(in por encima de todo lo dem7sJ Cue indiCue la e=istencia de una alarma % los detalles de la misma bloCueando a los dem7s ele

mentos de la interfa) @asta no @aber aceptado el aviso.

En la alerta no invasivaJ se busca Cue bajo la re(in de la barra superior o sobre la re(in de labarra inferiorJ se muestre un aviso de alerta conteniendo los detalles de la misma sin necesidad de bloCuear el acceso a los dem7s elementos de la interfa).

!

#igura E.EL% &istribucin de elementos del monitor extendido



89/196

Mapa de na%e-acin

!

#igura E.ER% -apa de navegacin de la aplicacin

#igura E.EQ% 5isualizacin de alarmas



90/196

3/12 .esu)en

En este captulo se @an establecido los modelos de an7lisis % diseDo de la aplicacin lo Cue servir7 de (ua para iniciar el desarrollo del sistema. Se @an establecido los escenarios % respecto a :sto las

interacciones de los usuarios con el sistema. *ambi:n se defini la arCuitectura del sistema respecto alos subsistemas e=istentes % su empla)amiento en los dispositivos Cue participan en su funcionamiento.

Se determinaron la estructura de la base de datos % los dia(ramas correspondientes. Adem7s seevaluaron los manejadores de bases de datos candidatosJ en los cuales se consideraron t:rminos derendimiento en base a los resultados obtenidos en LG&O


91/196


92/196

Captulo 4 Desarrollo

a suprema facultad del hombre no es la razn,sino la imaginacin

Duan ;FAorman

4/1 IntroduccinEn el captulo anteriorJ se @a presentado el funcionamiento del sistema respecto a la adminis

tracin de la informacin sin embar(oJ e=isten otros conceptos Cue no @aban sido considerados en laetapa del diseDo (eneralmente relacionadas con el uso de al(unas tecnolo(as en niveles distintos a los%a presentadosK as como tambi:n puede observarse la separacin de elementos funcionales respecto alprocesamiento de informacinJ visuali)acinJ adCuisicinJ almacenamiento % distribucin a los clientes.

En la fi(ura .1se muestra un dia(rama (eneral de los componentes del sistema % las tecnolo(as utili)adas

!%

#igura O.$% &iagrama Aeneral del )istema de -onitoreo @eb de )ignos 5itales


93/196

Es as como se identifican las aplicaciones necesarias en el sistema para su funcionamientoJ adem7s de un simulador Cue permitir7 manejar el conjunto de funciones desarrolladas % probar su inte(racin con otras etapas del sistema. Para evitar confusiones en el nombramiento de las etapasJ se @adecidido asi(narles nombres particulares Cue permitan una ma%or claridad al tratarse de distintoscomponentes del sistema.

As puesJ AmandeHalmendraI corresponde a la aplicacin encar(ada de recopilar informacinde los monitores de si(nos vitalesJ almacenar alarmas % distribuir la informacin a los clientes ?ebKcabe destacar Cue el conjunto de funciones HAP+I desarrollado para esta aplicacin se denomina Ch-taigneBcastaDaI. Pistachees la aplicacin encar(ada de administrar la informacin sobre los modelosde dominio de la aplicacinJ es decir6 m:dicosJ enfermerasJ pacientesJ monitoresJ alarmas % asi(naciones de m:dicosJ monitores % enfermeras. 9inalmenteNoisetteHavellanaI son el conjunto de scriptsutili)ados para obtener la informacin recopilada en!mande% mostrarla en una p7(ina ?eb.

4/2 A)ande!mande es la aplicacin encar(ada de obtener informacin de los monitores de si(nos vitales

mediante al(n mecanismo de comunicacin entre procesos el cual se @a implementado por mediode socets % procesa la informacin %a sea almacen7ndola en la base de datosJ o transmiti:ndola alos clientes ;eb. *ambi:n es la encar(ada de manejar los mltiples monitores de si(nos vitales Cuepuedan conectarse al sistema adem7s de los clientes ;eb.

&as Cue podemos definir como tareas principales de :ste mdulo dentro del sistema son6

&a transmisin de informacin de los monitores de si(nos vitales al servidor!mande.

El almacenamiento % procesamiento de informacin. &a transmisin de informacin a clientes ?eb.

4.2.1 5rans*isin $e infor*acin $e los *onitores $e si(nosvitales al *$ulo #*an$e&a transmisin de informacin no implica simplemente conectar un cliente % transmitir la in

formacin en formato binarioJ pues es imprescindible conocer Cu: tipo de informacin vo% a recibirJcu7l es la cantidad de informacinK % un punto adicional Cue puede escapar a primera vista6 el protocolo de cone=in para identificar el monitor Cue Cuiere conectarse % permitir su cone=in.

5n servidor de si(nos vitales se conecta al servidor !mande% comien)a a transmitir informacin de los sensores.!manderecibe un paCuete en el Cue se encuentra la medicin de un valor correspondiente a un sensor determinado. 4ependiendo del tipo de informacin se determina si es necesario almacenarla o no.

&os paCuetes deben de mantener una cierta estructura Cue permita su correcta representacin

"& 4esarrollo de un Sistema de -onitoreo ;eb de Si(nos itales


94/196

en memoria tanto para el monitor de si(nos vitales como al servidor AmandeK la definicin de esta estructura % los dem7s conceptos relacionados a la aplicacin Cue permitan el manejo de los paCuetesforman parte del!0 ChUtaigne desarrollado para el sistema.

En el ap:ndice 4 se muestran los aspectos relacionados al protocolo de cone=in % a la formacin % transmisin de paCuetes tanto para el mdulo!mandecomo para el simulador.

4.2.2 )9Mtai(ne? #/I $e propsito especfico para el Siste*a $e'onitoreo 6eb $e Si(nos Vitales/omo se @a visto anteriormenteJ @a sido necesario crear un protocolo Cue defina la estructura

con la Cue son transmitidos al servidor!mande los paCuetes de informacinJ as como tambi:n lasrutinas para la seriali)acin % deseriali)acin de :stos paCuetes para su transmisin en la redK sin embar(oJ esas no son las nicas rutinas relacionadas con la aplicacinJ pues tambi:n se @an implementado aCuellas relacionadas con el manejo de cone=iones de los monitoresJ manejo de cone=iones %transmisin a los clientes ;ebJ adem7s del almacenamiento en la base de datos.

&as tareas correspondientes al AP+ se definen como6 4efinicin de la estructura Cue representa la informacin proveniente de los sensores % su

asociacin con una determinada cate(ora % sensor.

4efinicin de la estructura de los mdulos Cue permita

Documents

DESARROLLO DE UN SISTEMA DE MONITOREO WEB DE SIGNOS VITALES.pdf