View
6
Download
0
Category
Preview:
DESCRIPTION
historia, requerimientos, implementacion en java
Citation preview
1
Resumen Se implementar una arquitectura peer-to-peer
(P2P) de redes ya que se ha convertido en una de las aplicaciones
ms populares utilizados en Internet debido a sus beneficios de
administrar los recursos de una manera fcil y porque equilibra
las cargas de trabajo. Por lo tanto, la construccin de una
plataforma de telemedicina basada en agentes basado en la
arquitectura de redes P2P, tambin se implementara tablas hash
al momento de enviar las listas de las cirugas al cliente, se
implementara video streaming para poder enviar establecer la
comunicacin del cliente con las caras web, el programa tendr
una interfaz grfica en Java.
ndice de trminos JMF, hilos, tablas hash, telemedicina,
I. OBJETIVOS
A. Objetivos generales
Desarrollar e implementar un sistema de telemedicina para el monitoreo de distintos quirfanos en tiempo
real a travs de cmaras web.
Conocer la aplicabilidad de una Hashtable, a una red de sistemas distribuidos.
Emisin de manera directa, transmitir los flujos de datos (Audio y Video) hacia el cliente.
B. Objetivos especficos
Disear e implementar tablas hash para listar todo el horario de cirugas de los quirfanos.
Conocer el significado de una red de telemedicina y su aplicacin a la vida diaria, como un sistema
distribuido.
Implementar interfaz grfica en java para que sea agradable al usuario.
Adquirir las cmaras web que estarn grabando en tiempo real.
Implementar video streaming en Java.
Implementar una arquitectura capaz de cumplir con los requerimientos deseados.
II. INTRODUCCIN
Qu es telemedicina? Es cualquier acto mdico realizado sin
contacto fsico directo entre el profesional y el paciente, o
entre profesionales entre s, por medio de algn sistema
telemtico. En otras palabras, la telemedicina utiliza las
tecnologas de la informacin y las telecomunicaciones (por
medio de los sistemas telemticos) para proporcionar o
soportar la asistencia mdica, independientemente de la
distancia que separa a los que ofrecen el servicio. Se ha visto
su aplicabilidad en variedad de
Escenarios de la Medicina, como por ejemplo: Dermatologa,
Psiquiatra, Cardiologa, Radiologa, Neurologa, Cirugas, etc.
III. MARCO TERICO
A. Historia, actualidad y tendencias futuras
La historia de la Telemedicina ha seguido el ritmo del
desarrollo de las telecomunicaciones: el telgrafo, el telfono,
la radio, la televisin y los enlaces por satlite se han
aprovechado para uso mdico desde el primer momento de su
introduccin.
Desde inicios de la centuria de 1900 se ha usado la medicina a
distancia y existen ejemplos de equipos que fueron
desarrollados para la transmisin de resultados de rayos X a
travs del telgrafo en Australia. Otros medios de
comunicacin tambin se han utilizado para la transmisin de
informacin en diferentes actividades de atencin de la salud
en el mundo entero. Se tienen referencias del uso de sistemas
de radiotelegrafa ya en 1920 en los pases nrdicos y en Italia
para asistencia martima. [1]
Los avances sobre la telemedicina se han venido realizando en
los ltimos 20 a 30 aos pero su aparicin fue mucho ms
antigua. En el ao de 1924 en una revista de Radio News
figuraba un dibujo de un mdico examinando a un paciente
mediante un radio que tena una pantalla de televisin as que
esta fue la primera idea que se obtuvo de la telemedicina. Pero
la verdadera prctica de la telemedicina empez en los aos
cincuenta en los Estados Unidos, sin duda el pionero en este
campo hasta la fecha.
La telemedicina se divide en fases:
La telemedicina pre-electrnica: se la ha practicado desde la
edad media, constaba en enviar las recetas por correo donde el
paciente escriba a su mdico su historial y la respuesta del
mdico incluido diagnstico, instrucciones y recetas.
La Telemedicina electrnica: primero se utilizaba
comunicaciones analgicas como telefona, telegrafa y radio.
Despus y la que actualmente se emplea son las
comunicaciones digitales.
La comunicacin inalmbrica: la explosin de la telefona
mvil, que completa en el campo de la investigacin la
transmisin de videos con imgenes. Las tcnicas de conexin
inalmbrica tambin incluyen el uso de las comunicaciones
por satlite de bajo costo para facilitar el acceso a internet. [2]
A principios de los aos setenta, la aparicin de las
minicomputadoras permiti que las unidades organizacionales
o departamentos individuales de los hospitales adquirieran sus
computadoras y desarrollaran aplicaciones propias. A finales
Telemedicina Edgar O. Muoz Juan P. Narvez Christian P. Snchez Ral B. Suquinagua Anthony Velasco
2
de 1970 y principios de los aos ochenta, fue accesible la
microcomputadora, por lo que las organizaciones pudieron
adquirir y desarrollar aplicaciones, mientras que los individuos
se incorporaban a la industria del software. En 1970 Texas
Instruments lanza el primer comercial sobre el uso de
computadoras dirigido a los mdicos.
Los primeros artculos sobre el uso de las computadoras en
medicina aparecen en las revistas mdicas alrededor de la
dcada de 1960. En 1965 Robert Ledley publica el libro Use
of Computers in Biology and Medicine, en 1969 Ledley y
Lusted publican Reasoning Foundations of Medical Diagnosis, uno de los primeros artculos que marca el inicio de la informtica mdica.
En 1970, William Schwartz sugiere los impactos y retos del
uso de las computadoras en la prctica mdica. Y en esta
misma dcada empieza la bsqueda de los lenguajes de
programacin y vocabularios especializados para las
aplicaciones de salud y biomdicas. En el hospital general de
Massachusetts surge el lenguaje de programacin MUMPS
(MGH Utility Multi-Programming System).
Principales experiencias de registro mdico electrnico:
A continuacin se detallan algunos proyectos relevantes de
expediente clnico electrnico en hospitales universitarios:
COSTAR (Computer Stored Ambulatory Record): fue desarrollado en Harvard y estuvo disponible
pblicamente en 1975 para luego ser implementado
en cientos de sitios alrededor del mundo.
HELP (Health Evaluation through Logical Processing): fue desarrollado por la Universidad de
Utah e introducido al mercado por 3M Corporation.
Puede considerarse precursor del sistema de soporte a
las decisiones.
TMR (The Medical Record): fue desarrollado en la Universidad de Duke.
THERESA: fue desarrollado por el hospital Grady Memorial y la Universidad de Emory, dirigido a que
el registro fuera hecho por mdicos.
CHCS (Composite Health Care System): fue desarrollado por el Departamento de Defensa de los
Estados Unidos. Es un sistema del tipo CPR y ha sido
utilizado ampliamente en el mundo.
DHCP (Decentralized Hospital Computer Program): fue desarrollado por la Administracin de Veteranos.
Estos proyectos presentaron diversos problemas tcnicos y
de programacin que an persisten, incluyendo el uso de
vocabularios e interfaces no estndares. Sin embargo, son
precursores de ideas y tecnologas que se siguen aplicando
hasta hoy, como por ejemplo, el lenguaje de programacin
MUMPS.
En 1925, un mdico del hospital de Maynard Columbus
envi un radiotelegrama solicitando antitoxina para combatir
la epidemia de difteria que estaba atacando a los nios de la
comunidad y que representaba un riesgo de salud pblica.
Dicho telegrama tambin fue reenviado a otros puntos de
Alaska buscando rastrear otros lugares donde se dispusiera de
la antitoxina, para lo que se coordinaron 20 trineos que
empleaban a 150 perros. Esta experiencia revela una
coordinacin exitosa donde se mezcla la tecnologa moderna
con medios antiguos.
A partir del ao 1935 en Italia, se hizo asistencia mdica
remota a la tripulacin de navos en mar por medio del
International Radio Medical Centre (CIRM). El CIRM provee
por radio asistencia mdica gratuita a los navos y a otras
embarcaciones.
En 1959, el Centro Mdico de la Universidad de Nebraska
da inicio al uso del circuito cerrado de televisin (CCTV) de
dos vas para la enseanza y el tratamiento en psiquiatra. La
televisin se emple para unir al centro mdico con los
hospitales en reas rurales y apoyar a los programas de
educacin.
A mediados de los aos sesenta, se estableci el servicio de
circuito cerrado de televisin entre el departamento de
radiologa y el rea de emergencias del hospital general de
Washington.
En 1970, se estableci un sistema interactivo de televisin
empleando microondas que facilit la transmisin del
aeropuerto Logan en Boston al hospital general de
Massachusetts para dar apoyo mdico a los viajeros.
En 1980, con la introduccin de las computadoras, se pasa
de las aplicaciones basadas en el uso de la televisin en tiempo
real a la modalidad de almacenamiento y envo. Dicha
modalidad consiste en recolectar datos e informacin en
formato digital, almacenarla y, posteriormente, transmitirla a
un sitio receptor. De esta forma se elimina la necesidad de
requerir al paciente, a los mdicos y al equipo de soporte de
manera simultnea, lo que se conoce como store and forward.
Fig. 1 Cronologia de la Telemedicina
En los aos noventa hay un resurgimiento que se ha
denominado la segunda era de la telemedicina. En esta dcada
hubo una gran proliferacin de experimentos de telemedicina,
muchos de ellos con un objetivo de continuidad y rentabilidad.
Es innegable que el desarrollo de la telesalud ha seguido el
ritmo de las telecomunicaciones y las TIC:
1876: Telfono.
1895: Radio.
1925: Televisin.
1957: Satlite.
1971: Pics.
1980: Internet.
1990: Mvil. Finalmente, una de las experiencias con las que se inicia la
primera dcada del siglo XXI es la extraccin de la vescula de
un paciente en Estrasburgo, realizada por un brazo robot y
dirigido por un mdico ubicado en Nueva York.
ltimas dcadas
La primera generacin de programas de telemedicina
basados en imagen enfrent los retos de requerir amplios
anchos de banda y no contar con desarrollos avanzados en
3
compresin de datos, al mismo tiempo que las tecnologas y
servicios de Internet se encontraban en etapas iniciales. Junto
con el progreso tecnolgico ha surgido internacionalmente el
debate de cmo apoyar el incremento en el acceso, la calidad,
la seguridad y la eficiencia del sector salud haciendo uso de
las tecnologas de informacin.
Fig. 2 Avance de las tecnologias
B. Necesidades locales o regionales
En Amrica Latina y el Caribe, regin donde los sistemas
de salud en el sector pblico an estn en estructuracin, el
proceso de incorporacin de las TIC ya est en desventaja con
respecto a los pases desarrollados. La complejidad para
ejecutar proyectos de telesalud es bastante ms grande, al
mismo tiempo que su implementacin puede contribuir al
desarrollo de un sistema de salud que satisfaga las necesidades
de la mayora de la poblacin.
1. Incorporacin de los recursos de telesalud en la atencin
primaria
Se observa que, en general, los proyectos de telesalud en
Amrica Latina se centran en la incorporacin de sus recursos
en la atencin primaria. Se trata de algo bastante prometedor
pues se ha planteado que la atencin primaria es la gran
estructuradora y coordinadora del proceso de cuidados del
paciente. En el contexto de sistemas de salud en proceso de
construccin, la prioridad de incorporar la telesalud en la
atencin primaria puede contribuir al progreso de las acciones
de salud en los distintos pases.
2. Necesidad de complejizar los recursos de telesalud
asignados a la atencin primaria para adaptarlos al perfil
epidemiolgico y de desarrollo de la regin
En algunos pases ya existen experiencias en actividades de
telesalud en radiologa, cardiologa y en cuidados semi-
intensivos. Sin embargo, en general, los proyectos son muy
bsicos porque exigen infraestructura de menor costo. Por otra
parte, a pesar de ser un proceso importante por permitir que
los proyectos se lleven a cabo sin grandes inversiones en
infraestructura, en este caso el perfil de incorporacin de los
recursos de telesalud es ms bsico que el perfil de los pases
del primer mundo, segn el informe de la OMS.
Debe observarse este aspecto, ya que, como los pases
buscan avanzar en la incorporacin de otros recursos de
telesalud en propedutica, precisan probar proyectos piloto
importantes de tele-monitoreo domiciliario para pacientes
hipertensos y diabticos. Los proyectos piloto de tele-
monitoreo centrados en tecnologas mviles podran ubicar a
Amrica Latina en el reciente ciclo de incorporacin de la
telesalud basada en estas tecnologas. Ya se constata una
brecha entre las experiencias latinoamericanas y el proceso en
marcha.
3. Potenciar la formacin a distancia aprovechando la
estructura de los proyectos de telesalud
El proceso formativo necesario para los proyectos de
telesalud ha ocupado un lugar secundario en el proceso de
incorporacin de recursos de telesalud en Amrica Latina. A
pesar de estar indicado y previsto, no se ha potenciado como
debera cuando se ven los resultados de los proyectos
nacionales. La contribucin de la telesalud al proceso de
formacin de profesionales del rea puede ser muy relevante,
pues crea una base slida de legitimidad, particularmente, en
un territorio tan extenso como el de Amrica Latina.
4. Realizacin de proyectos piloto o de demostracin
La experiencia de proyectos piloto del sector pblico en
instituciones, municipios o estados, donde se replican
experiencias de los dems pases, permite que aquellos que no
han iniciado los proyectos nacionales construyan las bases
concretas para los prximos pasos. Este proceso ha sido muy
importante en la experiencia latinoamericana, ya que impulsa
los proyectos nacionales.
Adems tenemos que tomar en consideracin diferentes
aspectos:
1) Garantizar y promover la formulacin, la implementacin y la evaluacin de polticas pblicas
eficaces, integradas y sostenibles sobre el uso y la
implementacin de las tecnologas de la informacin
y de las comunicaciones en el mbito sanitario.
2) Mejorar la salud pblica por medio del uso de herramientas y metodologas basadas en tecnologas
innovadoras de la informacin y las comunicaciones.
3) Fomentar y facilitar la colaboracin horizontal entre los pases para el desarrollo de una agenda digital en
materia de salud para la regin.
4) Gestin del conocimiento y formacin en alfabetizacin digital y TIC como elementos clave
para la calidad asistencial, la promocin y la
prevencin de enfermedades (OPS, 2011).
El Programa Nacional de Telemedicina/Telesalud se
enmarca en el Plan Nacional del Buen Vivir, que tiene como
meta fundamental fortalecer el modelo de atencin de salud
mediante una red de referencia y contra referencia desde la
atencin primaria, a nivel hospitalario de segundo y tercer
nivel, por medio de herramientas telemticas, contribuyendo a
que el Sistema Nacional de Salud (SNS) llegue de manera
universal y sin costo a toda la poblacin ecuatoriana, mediante
consultas clnicas y de especialidad, a distancia, o con carcter
emergente, consultas diagnsticas y de segunda opinin.
Promoviendo programas de gestin, capacitacin, consulta
bibliogrfica, as como promocin, prevencin, investigacin
4
e interculturalidad, para garantizar los principios de
universalidad, equidad, calidad y eficiencia del sistema en su
red pblica integral de salud.
El Programa Nacional de Telemedicina/Telesalud se lleva a
cabo gracias al liderazgo del Ministerio de Salud Pblica
(MSP), mediante el Proceso de Ciencia y Tecnologa (PCYT)
y la decidida participacin y cooperacin de diversas
instituciones pblicas y privadas; viabilizando la propuesta
mediante el desarrollo de proyectos que paulatinamente darn
cobertura a las 24 provincias del pas y con la suscripcin de
convenios interinstitucionales entre el MSP, MINTEL,
Secretara Nacional de Planificacin y Desarrollo
(SENPLADES), Secretara Nacional de Telecomunicaciones
(SENATEL), Fuerzas Armadas del Ecuador (FAE) y
universidades, entre otras instituciones.
Visin general de la ejecucin
La ejecucin de la propuesta implica:
1. Infraestructura fsica y de conectividad. 2. Equipar a las unidades de salud seleccionadas. 3. Proveer la conectividad adecuada. 4. Capacitar al personal de salud, al personal de soporte
y a la comunidad.
5. Establecer la red de operabilidad administrativa, tcnica y mdica para incursionar en esta nueva
forma de gestin y prestacin de servicios de salud.
6. Elaborar paralelamente la legislacin sobre telemedicina: ley, poltica, modelo de atencin,
normas, guas y procedimientos.
Fases de implementacin
La implementacin de la telemedicina y telesalud se ha
iniciado en la regin amaznica y se ha organizado en tres
fases:
Fase 1. El proyecto piloto (2009-2011) Morona Santiago y Pastaza, Napo, est en marcha y por
terminar. En esta fase se conectarn puntos aislados y
rurales de las provincias de Morona Santiago
(hospital de TAISHA, centro de salud (CS) San Jos
de Morona) y Pastaza (CS Musullacta, CS Santa.
Clara, Montalvo) con los hospitales provinciales de
Macas, Puyo, Tena y con los generales y de
especialidad Eugenio Espejo, maternidad Isidro
Ayora, peditrico Baca Ortiz; centro de teletrauma de
la FAE. Este proyecto fue financiado por el Fondo de
Telecomunicaciones (FODETEL).
Fase 2. Proyecto Sucumbos-Orellana-Zamora y Galpagos, propuesta aprobada y priorizada por
SENPLADES y financiada por el MINTEL, cubri
en el ao 2011-2012 la Amazona con el Proyecto
Sucumbos, Orellana, Zamora, Loja y Cuenca,
incluye puntos de las provincias amaznicas de
Sucumbos (HG Nueva Loja), Orellana (CSU Loreto,
HG Francisco de Orellana Coca), Zamora (HB
Zumba, HG Zamora) y dos hospitales de referencia
de la ciudad de Loja y Cuenca.
Complementacin de la Fase 1 y 2: inclusin de nuevos
puntos de la Amazona y Galpagos e integracin y
fortalecimiento de seis puntos de telemedicina gestionados por
la Universidad Tcnica Particular de Loja y dos puntos por la
Universidad Tecnolgica Equinoccial Quito.
Fase 3. Expansin a nivel nacional 2012-2014, en fase de gestin interinstitucional.
Instaurado el sistema a nivel nacional, progresivamente se
irn incluyendo nuevos puntos rurales y se ampliar el
equipamiento y prestacin de servicios de telemedicina.
C. Caractersticas y requerimientos de equipos
Captura de la imagen
Hay que tener presente que nuestro consultorio estar
provisto de los elementos habituales: caja de pruebas o
forptero digital, etc. Lo novedoso ser equipamiento de
captura que hayamos definido a priori: una cmara digital de
alta resolucin que hayamos acoplado a la lmpara de
hendidura mediante un codo con prisma o las lmparas de
hendidura digitales que ya traen incorporadas las cmaras de
filmacin.
Habr que asegurar la correcta captura de las imgenes,
sean estticas (cmara digital) o dinmicas (filmadora digital).
Para ello se aconseja usar los monitores a la hora de enfocar,
optimizando el nivel de iluminacin y de la hendidura y, sobre
todo, evitando los efectos de encandilamiento que suelen
haber al interponer las lupas de diagnstico. Aqu la cantidad
de luz y el espesor del haz son importantes a la hora de
asegurar que el especialista de la teleconsulta pueda apreciar
debidamente las imgenes transmitidas.
Recepcin de la imagen
A su vez, los monitores han de estar todos calibrados de igual
forma, en especial en lo relativo a la escala de colores, ya que
diferencias de escala pueden repercutir en los diagnsticos.
Esto sola ocurrir frecuentemente en los aos noventa, cuando
los monitores eran catdicos y con bajas frecuencias de
barrido. Esto se traduca habitualmente en la recepcin de
imgenes de mala calidad y que obligaba a modificar los
parmetros de cada monitor.
A su vez, la falta de estandarizacin en la calibracin (o del
hbito de controlarlo) poda resultar crtico, especialmente en
aquellos estudios diagnsticos codificados en colores, como
las topografas corneales. Aqu ya no solo se trataba de una
imagen distorsionada o de mala calidad de la consulta, sino
que el diagnstico poda verse alterado en funcin de los
colores percibidos en el sitio remoto.
Muestra
Se puede usar una variedad de pantallas, incluyendo los
monitores de ordenador, pantallas de televisin y dispositivos
mviles. El dispositivo de visualizacin y sus parmetros
asociados deben mostrar con precisin la imagen de patologa
5
para poder. El juicio profesional del patlogo puede utilizarse
para determinar si una imagen es satisfactoria para hacer un
diagnstico.
La presentacin coherente de imgenes es esencial y est
influenciada por software, los controladores de grficos y
dispositivos de visualizacin.
Transmisin
Para la transmisin de imgenes de telepatologa se necesita
capacidades de conectividad, ancho de banda y de
computacin apropiadas que deben estar en su lugar para
apoyar el tipo de imagen transmitida. El ancho de banda para
la visualizacin en tiempo real de las imgenes ser ms alto
que para la transmisin asncrona.
La tecnologa de compresin se puede aplicar siempre que
no ponga en peligro la imagen para uso clnico. La compresin
se define como matemticamente reversible (sin prdida) o
irreversible (con prdida). La compresin reversible siempre
se puede utilizar ya que no hay impacto en la imagen.
Irreversible de compresin se puede utilizar para reducir el
tiempo de transmisin slo si la calidad resultante es suficiente
para realizar de forma fiable la tarea clnica.
Seguridad y privacidad
Toda la transmisin de datos ser segura mediante el uso de
cifrado que cumple con los estndares reconocidos.
Las personas encargadas de la tecnologa deben familiarizarse
con las tecnologas disponibles en relacin con la
computadora y la seguridad del dispositivo mvil, y deben
ayudar a educar a los usuarios respecto de cuestiones tales
como las opciones de privacidad y seguridad. De la
videoconferencia se va a utilizar caractersticas de privacidad
estarn a disposicin de todas las partes participantes.
Caractersticas de privacidad deben incluir silenciamiento de
audio, silenciamiento de vdeo, y la capacidad de cambiar
fcilmente de lo pblico a modo de audio privado.
Cuando los proveedores utilizan un dispositivo mvil, especial
atencin se debe poner en la relativa intimidad de la
informacin que se comunica sobre dicha tecnologa.
IV. RETOS TECNOLGICOS Y ANLISIS DE SOLUCIONES
RECOMENDABLES
A. Heterogeneidad
Se tiene un problema al momento de utilizar la librera JMF
para dispositivos multimedia en la plataforma de Java debido a
que esta librera funciona nicamente en equipos de 32 bits y
la mayora de equipos hoy en da son de 64 bits, necesitamos
instalar otra plataforma de java para que la librera JMF
funcione en 64 bits, para esto es necesario descargar la
versin jdk para versin de 32 bits e instalar en nuestro equipo
de 64 bits, luego hecho esto necesitamos cargar esta nueva
plataforma en NetbeansIDE para esto necesitamos ir a las
propiedades del proyecto que estemos realizando y luego
cargamos la nueva plataforma Java de 32 bits para luego
proceder a correr nuestro proyecto, de esta manera se ejecutara
sin problemas nuestra librera JMF. La instalacin se explica a
continuacin.
Fig. 3 Agregar Plataforma de Java 32 Bits
Una vez hecho los pasos que se indica en la Fig. 3 se abrir
una ventana donde tenemos que buscar la ubicacin en la que
fue instalada la versin Java de 32 bits y se la agrega, nos
aparecer la nueva ventana donde se colocara el nombre con el
que se va a utilizar esta nueva plataforma.
Fig. 4 Colocar un nombre para la nueva plataforma
Aqu se hace clic en finalizar y se crea la nueva plataforma
para 32 bits, luego se carga esta en nuestro proyecto donde
estemos usando la librera JMF y procedemos a correrlo, as
funcionara en sistemas operativos de 32 o 64 bits.
B. Seguridad
Para la seguridad del servicio de telemedicina se implement
un sistema centralizo, la cual consta de un usuario y una
contrasea para poder iniciar sesin y poder enlazarse a un
peer, el cual estar uno en cada quirfano y se podr acceder a
sus cmaras. Adems esta seguridad cuenta con un numero de
tres intentos para poder iniciar sesin y en el caso de que se
supere este nmero el cdigo se cerrara y se tendr que cargar
nuevamente.
C. Extensibilidad
La telemedicina es un sistema que provee informacin y
servicios mdicos utilizando la tecnologa de comunicacin
remota y tecnologa multimedia. Esto tiene mucha importancia
6
en los roles de los diagnsticos mdicos y teraputicos. La
telemedicina se la puede utilizar para consulta remota,
consultar informacin o para aprender a distancia. Es basado
en comunicacin de computadoras y tecnologa multimedia,
primeramente captura datos mdicos como videos, hora y
saln donde se realiza la operacin. Luego realiza la
transmisin, almacenamiento y luego permite visualizar al
cliente que se haya enlazado. Este tipo de comunicacin
permite establecer una nueva relacin entre el doctor y el
paciente, o doctor con estudiante o personal mdico.
Este proyecto adems de poder enlazar las cmaras en
quirfanos de hospitales y ver las operaciones que se realizan
en ciertos horarios, tambin se las puede implementar para
poder hacer consultas mdicas sin la necesidad de acudir a una
clnica, ya que nicamente con un computador en nuestro
hogar podemos enlazarnos al hospital ms cercano y conversar
con un doctor para recibir un diagnstico. Tambin se lo
puede implementar para terapias de rehabilitacin para que los
pacientes hagan sus ejercicios en su hogar nicamente
siguiendo las indicaciones que el medico las indica.
D. Escalabilidad
En nuestras pruebas, el factor que ms afecta el rendimiento
del sistema fue la sobrecarga del lenguaje Java. Procesadores
ms rpidos pueden proporcionar un aumento de rendimiento
muy necesario para la mquina virtual de Java. Un mayor
desarrollo de mquinas virtuales Java eficientes utilizando
tcnicas de compilacin Just-In-Time tambin aumentar el
rendimiento del sistema. Incluso durante el ltimo ao, el
rendimiento de Java entregado ha multiplicado por cuatro. La
mquina cliente que ahora utilizamos es casi factor de dos ms
rpido que hace un ao, con lo ltimo en mquinas casi un
factor de dos por delante de ste. Implementaciones de Java
tambin han mejorado por un factor similar. Tratamientos de
fallos
E. Concurrencia
Nuestro sistema distribuido es estructura y centralizado, ya
que consta de un servidor principal, clientes y varios peers los
cuales sern los ubicados en un quirfano cada uno, para
poder evitar el problema de concurrencia se hizo que el
servidor este escuchando hasta que llegue la peticin de un
cliente, al recibir la peticin el servidor enva la lista de los
horarios de cada quirfano y el cliente escoge a la opcin a la
que desea y se conecta directamente al peer dejando al
servidor libre para seguir escuchando las peticiones de otros
clientes, ahora si otro cliente desea conectarse al mismo peer
este lo podr realizar sin ningn problema ya que el programa
esta implementado con hilos para que dos o ms puedan
conectarse al mismo servidor sin perder calidad de la
transmisin.
F. Transparencia
Para la transparencia de nuestro programa se basa en que el
cliente no vera ningn proceso que se est realizando entre
lneas, nicamente el cliente se enlazara al servidor principal
este le mandara las listas de las diferentes operaciones sin
ningn problema y el cliente solo pedir enlazarse a un peer,
al que el cliente desee, de esta manera el cliente se conecta al
peer, y puede recibir el video de que este transmitiendo ese
instante la cmara, de esta manera el cliente nunca vera el
proceso que est realizando internamente directamente
recibir el video en su ordenador sin ningn problema.
V. DISEO DE MODELO APLICADO A UN REA LOCAL O
REGIONAL
Fases de implementacin
La implementacin de la telemedicina y telesalud se ha
iniciado en la regin amaznica y se ha organizado en tres
fases:
Fase 1. El proyecto piloto (2009-2011) Morona Santiago y Pastaza, Napo, est en marcha y por
terminar. En esta fase se conectarn puntos aislados y
rurales de las provincias de Morona Santiago
(hospital de TAISHA, centro de salud (CS) San Jos
de Morona) y Pastaza (CS Musullacta, CS Santa.
Clara, Montalvo) con los hospitales provinciales de
Macas, Puyo, Tena y con los generales y de
especialidad Eugenio Espejo, maternidad Isidro
Ayora, peditrico Baca Ortiz; centro de teletrauma de
la FAE. Este proyecto fue financiado por el Fondo de
Telecomunicaciones (FODETEL).
Fase 2. Proyecto Sucumbos-Orellana-Zamora y Galpagos, propuesta aprobada y priorizada por
SENPLADES y financiada por el MINTEL, cubri
en el ao 2011-2012 la Amazona con el Proyecto
Sucumbos, Orellana, Zamora, Loja y Cuenca,
incluye puntos de las provincias amaznicas de
Sucumbos (HG Nueva Loja), Orellana (CSU Loreto,
HG Francisco de Orellana Coca), Zamora (HB
Zumba, HG Zamora) y dos hospitales de referencia
de la ciudad de Loja y Cuenca.
Complementacin de la Fase 1 y 2: inclusin de nuevos
puntos de la Amazona y Galpagos e integracin y
fortalecimiento de seis puntos de telemedicina gestionados por
la Universidad Tcnica Particular de Loja y dos puntos por la
Universidad Tecnolgica Equinoccial Quito.
Fase 3. Expansin a nivel nacional 2012-2014, en fase de gestin interinstitucional.
Instaurado el sistema a nivel nacional, progresivamente se
irn incluyendo nuevos puntos rurales y se ampliar el
equipamiento y prestacin de servicios de telemedicina.
Requerimientos operacionales
Un emisor.
Un receptor.
Un medio de comunicacin para transmitir la informacin necesaria: ser dotado por el Ministerio
de Telecomunicaciones y de la Sociedad de la
Informacin (MINTEL). Est por realizarse en las
unidades de la red de la fase 1.
Un medio de transformacin de la informacin.
Infraestructura fsica en unidades de salud (rea o sala de telemedicina) y de telecomunicaciones.
7
Componentes de la red de telemedicina
Centros consultantes (centros de atencin primaria: HB, CSU, CSR, PS); pacientes, mdicos en atencin
primaria.
Centros consultores (hospitales de segundo y tercer nivel: HG, HE, HES): mdicos de familia y mdicos
especialistas.
Red de telecomunicaciones, con requerimientos especficos en cuanto a capacidad de enlace o calidad
de servicio.
Equipamiento, que cumpla estndares de interoperabilidad: equipos mdicos, computacionales
y comunicaciones.
Recursos humanos gestor: coordinacin, gestin, direccin.
Recursos humanos de soporte: informtico, de telecomunicaciones y biomdico.
Recursos humanos de apoyo: administrativo.
Conectividad fases 1 y 2
De acuerdo con la localizacin de las unidades de salud, el
MINTEL define el tipo de conectividad:
Fibra ptica.
Plataformas satelitales.
ADSL.
Fig. 5 Salud Incluida en la Fase 1 y 2
Fig. 6 Equipos mdicos, computacin y comunicacin
VI. DESARROLLO E IMPLEMENTACIN DE MODELO PROPUESTO
Hemos credo conveniente utilizar para nuestro proyecto
una arquitectura estructurada dado que los nodos guardan
informacin til de encaminamiento (routing) para dirigir las
bsquedas. Gestionan una Tabla Hash Distribuida (DHT) y
permiten que cada peer sea responsable de una parte especca
del contenido de la red. Estas redes utilizan funciones Hash
distribuidas y asignan valores a cada contenido compartido y a
cada peer de la red.
Cada nodo sigue un protocolo de actuacin que relaciona
contenidos con peers responsables de estos contenidos. De
esta forma, siempre que un peer desee buscar ciertos
contenidos, utiliza este protocolo para determinar el/los
responsable(s) de los datos y despus dirige la bsqueda hacia
el/los peer(s) responsable(s). Algunos ejemplos de protocolos
utilizados en redes peer-to-peer estructuradas son: Chord,
Pastry, Tapestry, Content Adressable Network (CAN), y
Kadmelia
La Fig. 7 muestra un esquema de una red peer-to-peer de
tipo estructurada. Cuando un peer se inserta en la red P2P de
tipo estructurada, todos los objetos que comparte, tienen que
estar hasheados con una clave identicadora (K 1) y
posteriormente ser enviada conjuntamente con la direccin de
red del peer propietario (K1, I1) (resaltado en color azul) al
peer sucesor K1, donde nalmente este guarda la informacin
en su tabla de datos. Por otro lado, cuando un peer solicita una
consulta de la clave K1 (en rojo), este enva una peticin al
peer sucesor K1, y cuando llega la peticin le devuelve la
direccin I1 del peer propietario de los datos compartidos K1.
A partir de entonces, el peer solicitante ya puede descargar los
datos de la direccin
8
Fig. 7 Esquema de una red peer to peer de tipo estructurada
Dentro de estas arquitecturas estructuradas tenemos dos
clases: arquitectura estructurada centralizada y arquitectura
estructurada descentralizada.
La primera generacin de redes P2P empleaba una
estructura cliente-servidor. En este caso, el servidor central
mantiene una base de datos con informacin de los contenidos
compartidos por cada peer y sus respectivas direcciones. Cada
vez que un cliente se conecta o desconecta de la red, se
actualiza la base de datos del servidor. En este modelo, todos
los mensajes de bsqueda y control son enviados al servidor
centralizado. El servidor centralizado compara la solicitud de
sus clientes con el contenido de su base de datos y enva la
informacin de la direccin al cliente en cuestin. Una vez que
este es informado, el cliente contacta con el peer directamente
y accede al recurso solicitado. Los contenidos nunca son
almacenados en el servidor central.
Nos vamos a basar en la arquitectura estructurada
centralizada ya que proporciona un rendimiento muy elevado
cuando se trata de localizar recursos. Todos los peers de la red
deben registrarse, lo cual asegura que todas las bsquedas van
a ser ejecutadas rpida y ecientemente, siempre y cuando el
servidor este bien dimensionado. Debido a ser un modelo
centralizado, todo el coste y responsabilidad recae sobre una
sola mquina y por lo tanto presenta problemas de
escalabilidad y seguridad. Del mismo modo, es un sistema
costoso de mantener porque requiere la compra y
mantenimiento de mquinas dedicadas para realizar el
servicio. Adems, tambin presentan problemas relacionados
con la privacidad de datos de los usuarios. Algunos ejemplos
de redes peer-to-peer centralizadas son: Napster y Audiogala.
En la Fig. 8 se puede ver un esquema de una red peer-to-peer
centralizada.
Fig. 8 Esquema de una red peer to peer de tipo centralizada
A. Obtencin de videos y transmisin
Para poder enlazar las cmaras en Java se necesit instalar una
nueva librera, la cual se encuentra en la misma pgina de
Oracle, esta librera se llama JMF (Java Media Framework),
esta Liberia nos permiti utilizar los dispositivos multimedia
que se encuentran conectados en nuestra PC, para nuestro
programa nicamente se utiliz las cmaras de video, las
cuales van a estar instaladas una en cada peer, estas cmaras
se van a conectar al momento de que el cliente se enlace a un
peer, este momento las cmaras empiezan a transmitir el video
a manera de frames al cliente. Lo que hace nuestro programa
de multimedia es grabar el video que se captura en un instante
de tiempo, luego este buffer lo convierte a imgenes cada un
milisegundo en formato .jpg luego estas imgenes a travs del
protocolo de comunicacin RTP sern enviadas al cliente que
pidi la peticin, el cliente tendr una ventana en la cual se
irn mostrando todos los frames que vayan llegando desde el
peer y de esta manera se podr tener imgenes en tiempo real
de lo que est pasando en el cuarto peer.
VII. ANEXOS
A. Enlace de las cmaras a Java (con Java Media
Framework JMF)
Debido a que nuestro proyecto manejamos contenido
multimedia los cuales sern los videos que se transmitirn de
un peer a los clientes que inicien sesin en nuestro programa y
pidan la peticin de observar un video, para poder realizar esto
se necesit instalar una nueva librera especial de Java llamada
Java Media Framework (JMF). Pero Que es Java Media
Framework? Esta es una librera de java que no viene por
defecto con la plataforma jdk de Java que se instala en un
inicio por lo que es necesario descargarla de la pgina de
Oracle. Esta librera nos proporciona herramientas para la
captura, procesamiento y almacenamiento de datos
multimedia. Adems permite reproducir flujos multimedia
recibidos en tiempo real a travs de la red.
En Java Media Framework los datos multimedia pueden
proceder de diversas fuentes como: archivos locales o
remotos, video y audio en tiempo real o bajo demanda.
9
Algunas de las clases que se utiliz para poder enlazar las
cmaras son las siguientes y se explicara cules son sus
funciones:
CaptureDeviceManager: Esta clase nos permite listar todos los
dispositivos multimedia que se encuentran en nuestro
ordenador y nos permite guardarlos en listas para luego poder
utilizar cada uno de ellos.
CaptureDevice: Es un Hardware el cual es capaz de capturar
audio y video lo cual lo hacen las cmaras o micrfonos, etc.
La informacin que recogen estos dispositivos son
almacenados en un objeto CaptureDeviceInfo, cada
dispositivo posee un CaptureDeviceInfo.
Format: Este es un objeto que guarda el formato de la
informacin multimedia.
Player: Es un objeto que toma el video en la entrada y luego lo
permite visualizar en pantalla.
Antes de unir la parte multimedia al resto del programa
primero se realiz algunas pruebas para poder entender el
funcionamiento de la librera JMF, y primeramente se realiz
un listado de todos los dispositivos multimedio que posee
nuestro ordenador peer de la siguiente manera.
Fig. 9 Listado de dispositivos multimedia en la PC
Como se puede ver el dispositivo que obtiene los videos se
llama "vfw: Microsoft WDM Image Capture (Win32) :0" asi
que luego se procedi a escoger esta cmara para que luego
nos abra una ventana y nos deje visualizar el video en ese
instante.
Fig. 10 Cdigo para poder Enlazar la webcam en Java
Fig. 11 Visualizacin del video en tiempo real
De esta manera se pudo comprobar el correcto funcionamiento
de la librera JMF, ya con esto solo se necesit crear un
protocolo de comunicacin para que permitir la transmisin de
este video que ser el peer hacia el cliente que es el que pedir
la peticin de poder visualizar.
Problemas:
El problema que se nos present al utilizar esta nueva librera
de Java es que solo funcionaba con sistemas operativos de 32
bits, y la mayora de dispositivos hoy en da trabajan en SO de
64 bits, para solucionar esto se necesit descargar la
plataforma JDK de java pero para 32 bits y luego incorporar
esta nueva plataforma en el entorno NetbeansID, hecho esto se
necesit grabar nuestro proyecto en esta nueva plataforma y
hecho esto nuestro programa de multimedia empez a
funcionar correctamente sin ningn fallo.
-cuando no se realiza bien la conexin con el cliente y ce
cierra la pantalla del video en el pear, a veces cuando se quiere
10
realizar de nuevo la conexin, el driver de la cmara no le
reconoce que est disponible, y nos da error
Fig. 12 Error de enlazamiento de la cmara
-cuando se necesita conectarse el cliente con otro pear se debe
cerrar la conexin desde el pear que tiene la actual conexin,
para que pueda el cliente conectarse con otro pear
B. Aplicacin de DHT en el sistema
1) Visin general del funcionamiento de las Tablas
hash en la red de telemedicina.
Entonces, debido a toda la parte terica recopilada, se opt por
implementar las tablas hash en nuestro sistema de red de
telemedicina, el cual se lo planea realizar de la siguiente
manera:
Fig. 13 Diagrama de Bloques
En dnde;
SP significa servidor principal 1, 2, 3, , significa quirofano1,2,3, ,N respectivamente.
Como se puede apreciar cada quirfano funcionara como un
servidor remoto, y cada servidor remoto tendr su listado de
operaciones de cada da.
Como cada da debe existir un listado nuevo, se tom a la hora
de la operacin como la variable clave, y por otro lado al valor
asociado a la hora (la clave se la tomo como valor). Por lo que
de esta manera se generan las tablas hash de cada uno de los
quirfanos.
Por el momento se tiene pensado tener el listado de
operaciones de cada quirfano almacenado en un archivo de
texto, de la siguiente manera.
Fig. 14 Quirofano 1
Fig. 15 Quirofano 2
Fig. 16 Quirfano 3
En el momento que el cliente ingrese al sistema de red de
telemedicina, luego de haber ingresado su clave/contrasea, y
haga una peticin de listado general de operaciones. Entonces
en ese momento el servidor principal hace un llamado a todos
los quirfanos (servidores remotos) genera transparentemente
un listado general, en el cual el cliente puede elegir qu
operacin quiere ver y establecer un enlace para ver la
operacin y elegir la cmara que sea de su preferencia o que
est disponible.
11
Fig. 17 Ejecucin conexin servidores, que es el que genera el listado general,
haciendo una peticin a cada uno de los quirfanos de manera transparente
Como se puede ver al ejecutarse el cdigo llamado conexin servidores, se genera un listado general transparentemente, y como se puede ver en la Fig 16, se va generando
aleatoriamente, del servidor 1, o 2, o 3, esto se debe a que cada
servidor pertenece a un hilo, es decir se tendrn un numero de
hilo (conexiones servidor-quirfano), igual al nmero de
quirfanos disponibles. Debido a esto, y a que estn
sincronizados, se ve aparentemente en forma desordenada,
pero hay que tener en cuenta que esto sucede indistintamente
en cada quirfano, y de tal manera en cada quirfano se
encuentra en orden.
Como se puede observar en la siguiente Fig 17, se visualiza el
listado general, almacenado luego de la primera ejecucin
entre cliente y servidor principal, si existiera otra conexin
con otro cliente se generara otra conexin en otro socket y se
la realizara de la misma manera.
Fig. 18 Listado General
2) Explicacin de la utilizacin de DHT en cada uno
de los peer (quirfanos).
Fig. 19 Generacin de una DHT en el peer1
Como se puede observar, en la primera lnea nicamente se
hace una lectura del archivo palaras1.txt y se lo coloca en
modo escritura, en la lnea siguiente se crea una cadena de
strings la cual va a ser la que se lea de cada una de las lneas
del archivo txt, en la siguiente lnea se crea una DHT con las
sentencias de la plataforma java, en la siguiente lnea se crea
variables que cumplen la funcin de contadores, solo con el
fin de utilizarlas luego, en la siguiente lnea en el bucle while
se crea una sentencia la cual bsicamente indica que si la lnea
que se graba en el arreglo de strings en nula, es decir est
vaca, solo entonces se sale del bucle, de lo contrario en la
siguiente lnea dentro del bucle while se crea una separacin
en una variable como identificador de la DHT(clave), y lo que
resta del string queda como valor asociado a la clave del
identificador de la DHT, a la cual se podr acceder en
cualquier parte del peer, solamente llamando a su
identificador.
A continuacin se realizara una esquematizacin de que es lo
que ocurre en una DHT.
Primeramente se realizara la lectura de una lnea del
archivo.txt, en el cual el texto se encuentre dividido por un
igual, en el cual todo hacia la izquierda del igual es la clave, y
todo hacia la derecha del igual es el valor asociado.
Fig. 20 De un archivo txt a una DHT
12
Fig. 21 Envi de datos a la clase conexin
Como se puede ver en la Fig 19, pedazo de cdigo an se
encuentra en la clase peer1, pero en esta parte se enva los
datos a utilizar en la clase conexin del peer1, entonces se
puede ver que se designa un puerto que es mayor a 1024, para
garantizar una conexin estable, por eso no se eligi de
manera aleatoria, entonces se puede ver que los datos que se
envan a la clase conexin del peer1, son; clientsocket que es el nmero de socket al que se va a conectar, bandera que es una variable en la cual se guarda, cual es el nmero de
operaciones al da, y hashtable que es una estructura en la que se almacena de manera ordenada una clave que es la hora
de la operacin al da(de 1 a 24 horas), a cada hora est
asociado una cadena de strings, en la cual se puede encontrar
la ciruga a realizar, el quirfano a utilizar, el doctor que
realizara la operacin y todos los parmetros que se quieran
enviar como informacin.
Fig. 22 Clase conexin peer 1
Primeramente se deben instanciar nuevamente los objetos a
utilizar dependiendo de que tipo sean, como se puede observar
al momento de recibir la hashtale hay que declarar el tipo de
dato que se espera recibir, por lo que basta con declarar que se
espera una hashtable.
Fig. 23 Cdigo para enviar el listado de operaciones a la clase conexin
servidores
Como se puede ver en la Fig 21, se realiz un pequeo
algoritmo, en el cual se ve la utilizacin de las DHT, ya que se
compara cada una de las 24 horas del da ya que estas son las
clave, y si se encuentra una clave similar en la DHT, se la
enva como string a la clase conexin servidores (la cual
recibe en string pero de igual manera la almacena en una
DHT), y se imprimir en el peer1 un listado de las operaciones
diarias.
Cada momento que se enlace un nuevo cliente y haga una
peticin, se realizara una peticin a cada uno de los peers para
que generen este listado, por lo que si el listado ha sido
modificado, se visualizara la modificacin transparentemente,
y se visualizara de manera correcta.
Si se modific un archivo txt, y se desea actualizar la
visualizacin que tienen cada uno de los peer, para su
posterior envi del lista y que este listado este actualizado,
bastara con generar una nueva lectura de datos desde el
archivo txt, y un posterior almacenamiento en una DHT, con
una clave y un valor asociado a la clave, sin necesidad de
cambiar ningn parmetro de dimensin, que se lo hubiera
tenido que hacer en caso de haber utilizado arreglos de strings
como media de almacenamiento de string en vez de DHT.
Fig. 24 Visualizacin del listado de operaciones del da correspondientes al
peer1
Basta con decir que el mismo procedimiento, se realiza para
cada uno de los peers (los quirfanos que se encuentren
enlazados a esta red de telemedicina).
13
Fig. 25 Visualizacin del listado de operaciones del da correspondientes al
peer2
Fig. 26 Visualizacin del listado de operaciones del da correspondientes al
peer3
3) Explicacin de la utilizacin de las DHT en la
clase conexin servidores
Luego de que transparentemente se genere cada uno de los
hilos que conecta a cada uno de los servidores remotos
(quirfanos) se procede a almacenar lo que enviar cada uno de
los quirfanos en un listado general, que bsicamente es
guardar en un archivo de texto, lo que se enva en cada uno de
los peers, y se puede aadir algunos parmetro de
informacin, que pueden ser de cualquier tipo en este caso, se
aade el nmero de puerto, y el servidor del que viene en
string.
Fig. 27 Creacin de listado general
Luego que se almacena el listado general en el archivo txt,
como palabras.txt, se procede a la clase conexin del cliente,
el cual realiza la lectura de una lnea del archivo txt, y lo
almacena en una DHT, para su posterior enva al cliente.
Fig. 28 Cargar Base de datos
Ahora se procede a enviar la informacin de la tabla general al
cliente y l se enlaza directamente con el servidor, y con la
cmara que desee.
4) Creacin arreglo simple en la clase Cliente
Se cre este simple algoritmo, y se opt por un arreglo de
string, ya que el cdigo del cliente tiene que utilizar todos los
parmetros almacenados en el string que se enva como
cadena proveniente de una DHT, y el cdigo cliente tiene que
manipular estos datos a su antojo para que se visualice de
manera adecuado solo ciertos datos en la interfaz grfica.
Adems que en uno de los parmetros del arreglo se encuentra
el servidor y en puerto con el que se puede conectar a ese
servidor, datos que son muy importante para que el cliente se
pueda conectar directamente con el quirfano, y poder
visualizar sus operaciones.
14
Fig. 29 Madriz de Strings
5) Problemas:
Al momento de establecer la conexin, al utilizar tablas hash
se tuvieron problemas al enviar una tabla hash como
parmetro del constructor Connection
Fig. 30 Problema 1 envi Hashtable
Al momento de recibir la informacin, ya en el mismo mtodo
Connection, no se me reconoce la tabla hash.
Fig. 31 Antiguo problema al recibir la hashtable
Para corregir este inconveniente, se tiene que instancias cada
una de los objetos a utilizar en la clase conexin, dependiendo
de cul es el tipo de objeto que se espera recibir, en este caso
se tiene una hashtable.
Fig. 32 Solucion problema 1
C. Cliente (Realizado en la interfaz grfica de Usuario GUI).
Hasta ahora hemos desarrollado programas que nos ha
permitido centrarnos en todo aquello que tiene que ver tan solo
con la programacin con el lenguaje Java, sin tener que tratar
al mismo tiempo con ventanas, botones y otros elementos
similares.
Las interfaces graficas ofrecen al usuario ventanas, cuadros
de dialogo, botones y muchos elementos con los que ya
estamos muy acostumbrados a tratar.
Las aplicaciones son conducidas por eventos y se
desarrollan haciendo uso de las clases que para ello nos ofrece
la API de Java.
En general el cliente est formado por tres partes una de
ellas es el ingreso al sistema, la siguiente es la ventana
principal y la ltima son ventanas para mejorar la apariencia
al proyecto a continuacin se explicaran cada una de ellas.
1) Ventana de login. Hoy en da la seguridad es muy importante al momento de
desviar las amenazas que pretenden afectar al proyecto por esa
razn se realiz esta ventana con el objetivo de que ingresen
personas que le den un buen uso al proyecto.
Fig. 33 Ventana de ingreso
En general la ventana consta de 2 jText donde se va a
ingresar el nombre del usuario y en el otro la contrasea y un
botn de ingreso adems se ha colocado un fondo (imagen)
para que se agradable a la vista del usuario.
Fig. 34 Cdigo fuente del botn
La lgica del ingreso consiste en que se define una clave y
contrasea, luego mediante los jText el usuario ingresa textos
y el programa va comparando, si son el mismo ingresa, caso
contrario sale un mensaje de error.
Se permiten como mnimo 3 intentos de ingreso, si no
logra ingresar aparece un mensaje de advertencia y se cierra
el programa automticamente.
15
Fig. 35 Ventana de error de ingreso
Fig. 36 Ventana de 3 intentos de error
Al ingresar correctamente el usuario y contrasea pasa a la
ventana principal que se explicara a continuacin.
2) Ventana principal.
En general nos muestra un jTable donde se va a almacenar
la lectura de las listas obtenidas por el servidor, un Label
donde se va visualizar la hora, un jText que se va a usar como
un filtro para buscar en la lista principal tambin posee un
main donde se va hacer ingreso a las ventanas adicionales que
se explicaran despus.
Fig. 37 Ventana Principal
En el Label se implement la hora del da actual se
realiz utilizando una clase para calcular la hora a partir de
las libreras java.util.Calendar, java.util.Date, se utiliz un
Thread ya que se necesita que se realizan tareas
concurrentes.
Fig. 38 Clase para calcular la Hora
En el jText mediante la opcin de KeyTyped se logr
realizar una clase que busque al momento de escribir los
archivos de la lista que se encuentran el jTable.
Fig. 39 Cdigo Filtro
A continuacin se muestra la funcionalidad del filtro ya
que se escribi la palabra retina y busca en todo el listado principal todas las palabras que estn retina.
Fig. 40 Funcionalidad del Filtro
El main tiene en genera un main bar y main tems donde se
visualiza la ventana de autores, la ventana de mostrar historial
de todo lo que sucede en el sistema y la ventana de
informacin de personal mdico.
Fig. 41 Main
En el jTable se visualiza una lista que es enviada desde el
servidor mediante arreglos, esta es el listado que tienen
disponibles los peers. De la mismo forma que cada peer es un
quirfano distinto se usara como clave dicha informacin para
poder vincularnos directamente a cmara, eso se logra
mediante la clase que tiene la tabla de JTableMouseClicked
que usando la clave Quirfano 1 al dar clic en cualquier columna de la tabla se extrae el valor de dicha columna y se
compara si existe la palabra en ese texto se vincula al peer
caso contrario no pasa nada.
16
Fig. 42 Vincular Cmara con Peer
Cuando se genera el clic en cualquier columna a su vez
existe una clase que realiza la obtencin de la direccin ip
y el puerto para podernos conectar con los peer y este
enva un mensaje donde los peer tendrn que conectarse a
las cmaras en tiempo real.
En si tambin en esta parte gracias a que el servidor manda
mediante arreglos toda esta informacin se va almacenando en
un .txt para poder realizar la opcin de mostrar un historial,
tambin la opcin de mostrar a los doctores que realizan
dichas operaciones.
3) Ventanas de informacin. Como se mencion anterior mente existen tres ventanas las
cuales son:
a. Ventana de Informacin de doctores. Se realiz esta ventana con el objetivo que el usuario sepa
toda la informacin del doctor que se encuentra operando y si
algo suceda mal dicho usuario lo sepa.
La ventana consta de varios Jtext donde se visualiza la
informacin y de un scroll donde muestra la especialidad del
doctor.
Fig. 43 Scroll de especialidad del doctor
Fig. 44 Informacion Del Doctor
b. Ventana de Autores. Esta ventana es para que el usuario sepa quien realiz dicho
proyecto.
Fig. 45 Ventana de Autores
c. Ventana del Historial. Como se mencion anterior mente gracias a que llega toda la
informacin necesaria a la ventana principal se logra guardar
un texto donde se almacene toda la informacin que sucede en
el da, en la historia adems se muestra la hora de ingreso y
fecha para que exista un adecuado control.
Fig. 46 Ventana del Historial
Problemas.
Al momento de realizar una bsqueda en el filtro esta a su
vez genera tablas aleatorias es decir va variando el nmero de
columnas y filas por lo cual se nos hace difcil en cierto punto
utilizar el filtro y vincular a la cmara directamente, ya que la
cmara se vincula mediante la clase que obtiene el nmero de
la columna y fila preciso para extraer su texto y compara con
la palabra clave que era Quirfano as que el buscador solo sirve para ver ms rpido la ciruga o la hora que desee el
usuario mas no para ingresar directamente (vincularse con la
cmara).
Al momento de unir la interfaz grfica de la recepcin de
video con el cliente tuvimos problemas ya que ciertas clases
17
solo podan estar en public static main por lo que la solucin
fue ejecutar dicha ventana desde el inicio del programa.
Al iniciar el programa inicia conjuntamente con la venta de
transmisin de video la cual se mantiene inactiva hasta que se
enva una peticin al peer para que d la orden de visualizar el
video que pidi el cliente.
D. Implementacin del servidor con sus respectivos peers
El servidor cuenta con un hilo de escucha que se encargara
de atender los requerimientos del cliente. Adems esta
implementado la transmisin de listas mediante tablas Hash
Tambin se opt por colocar hilos para que el servidor
principal permanezca escuchando a los peers, ya que si un
peer no estuviera activo el hilo muere y sigue en marcha el
programa de otra forma si hubisemos puesto en el cdigo
general esto conllevara a un fracaso del algoritmo. Estos hilos
deben estar sincronizados para que no ocurran datos
incoherentes y por ltimo, tambin esta con la mxima
prioridad para que se ejecute de manera instantnea ya que
est planificado implementar otros hilos de una prioridad
inferior.
1) Servidor principal
Fig. 47 Escucha hasta que se pida una peticin
En la Fig.46 se muestra como el servidor principal espera
una peticin del cliente para empezar a trabajar, adems
agregamos unas variables globales a los peers para saber el
puerto socket y direccin IP del cliente a quien estamos dando
servicio.
En la Fig.40 esperamos dos segundos para que se cargue la
base de datos que el servidor recibe de los peers asociados,
seguidamente se lee un documento txt en donde se guard
todos los servicios que ofrecen los peers y se los enva al
cliente.
Fig. 48 Envi de servicios al cliente
Ahora bien, vamos analizar qu es lo que se hacen en la
recepcin de datos desde un peer en general (Fig.41).
Primeramente tenemos un hilos que escucha a dicho peer,
posteriormente le enviamos un mensaje al peer asociado
dicindole que es el servidor y necesita saber qu servicios
est ofreciendo por el momento, entonces el peer recepta el
mensaje e inmediatamente le enva la lista de servicios y los
almacena en un documento de texto.
Fig. 49 Hilo que se conecta con el peer 3
1) Cdigo peer
El peer lo nico que hace es escucha la peticin del servidor
o cliente y si es el servidor entonces enva los servicios que
ofrece y si es el cliente entonces abre una ventana para
empezar la transmisin de video (Fig.42)
18
Fig. 50 Cdigo del Peer
Adems se implement en las excepciones que si el servidor
no est disponible este le envi un mensaje al cliente
informndole que dicho servidor no est disponible.
VIII. CONCLUSIONES Y RECOMENDACIONES (REAS A
APLICAR, TEMAS A MEJORAR, TEMAS A INVESTIGAR)
Es necesario utilizar una librera externa de Java para poder enlazar los dispositivos multimedia a Java.
Se puede utilizar cualquier sistema operativo solo con descargar la plataforma de 32 bits de Java, de esta
manera se observa las imgenes sin ningn problema.
Al momento de realizar el cdigo, tener en cuenta cual es el tipo de objetos con los que se est
trabajando, ya que el enviar datos a otras clases para
que utilice cierta informacin, se necesita especificar
qu es lo que se quiere recibir, tener mucho cuidado
al respecto cuando se trabaja con DHT.
Al trabajar sobre UDP se tiene gran tendencia a la perdida de los frames, cuando se pierde un frame este
no se puede recuperar. En nuestro caso la perdida
dependa de la red, la perdida de frames no conlleva a
la perdida de la conexin
Los frames son muy tiles para la trasmisin en vivo de video, satisfacen los requerimientos del cliente
Es conveniente realizar de la mejor manera la parte de interfaz grfica ya que es la parte donde se vende
en el mercado, ya que es la primera presentacin del
proyecto en general.
Averiguar y tener conocimiento de todo lo relacionado a GUI de java ya que tiene un sin nmero
de aplicaciones y libreras que posee dicho medio.
Una recomendacin para diseos posteriores es realizar todos los documento es una base de datos
para que se factible como un proyecto grande
implementado en una empresa.
Una mejora para nuestro proyecto es la implementacin de actualizaciones de servicios de
cada peer.
IX. REFERENCIAS
Publicaciones peridicas: [1] J. F. Fuller, E. F. Fuchs, y K. J. Roesler, "Influencia de los armnicos en
la proteccin de sistemas de distribucin de potencia," IEEE Trans. Power Delivery, vol. 3, pp. 549-557, abril 1988.
[2] E. H. Miller, "A note on reflector arrays," IEEE Trans. Antennas Propagat., a ser publicado.
[3] R. J. Vidmar. (1992, Aug.). On the use of atmospheric plasmas as electromagnetic reflectors. IEEE Trans. Plasma Sci. [Online]. 21(3), pp.
876-880. Disponible en : http://www.halcyon.com/pub/journals/21ps03-vidmar
Libros: [4] E. Clarke, Circuit Analysis of AC Power Systems, vol. I. New York:
Wiley, 1950, p. 81. [5] G. O. Young, "Synthetic structure of industrial plastics," en Plastics, 2a
ed., vol. 3, J. Peters, Ed. New York: McGraw-Hill, 1964, pp. 15-64.
[6] J. Jones. (1991, Mayo 10). Networks. (2a ed.) [Online]. Disponible en: http://www.atm.com
Reportes tcnicos: [7] E. E. Reber, R. L. Mitchell, and C. J. Carter, "Oxygen absorption in the
Earth's atmosphere," Aerospace Corp., Los Angeles, CA, Tech. Rep. TR-0200 (4230-46)-3, Nov. 1968.
[8] S. L. Talleen. (1996, Apr.). The Intranet Architecture: Managing information in the new paradigm. Amdahl Corp., Sunnyvale, CA. [Online]. Disponible en: http://www.amdahl.com/doc/products/bsg/intra/
infra/html
Escritos presentados en conferencias (sin publicar): [9] D. Ebehard and E. Voges, "Digital single sideband detection for
interferometric sensors," presentado en la 2a. Conferencia Int. de
Sensores para Fibra ptica, Stuttgart, Alemania, 1984.
[10] Process Corp., Framingham, MA. Intranets: Internet technologies deployed behind the firewall for corporate productivity. Presentado en
la reunin anual INET96. [Online]. Disponible en:
http://home.process.com/ Intranets/wp2.htp
Escritos presentados en conferencias (publicados): [11] J. L. Alqueres y J. C. Praca, "The Brazilian power system and the
challenge of the Amazon transmission," in Proc. 1991 IEEE Power Engineering Society Transmission and Distribution Conf., pp. 315-320.
Disertaciones: [12] S. Hwang, "Frequency domain system identification of helicopter rotor
dynamics incorporating models with time periodic coefficients," Ph.D. disertacin, Dept. Aerosp. Eng., Univ. Maryland, College Park, 1997.
Normas: [13] IEEE Guide for Application of Power Apparatus Bushings, IEEE
Standard C57.19.100-1995, Ago. 1995.
Patentes: [14] G. Brandli and M. Dick, "Alternating current fed power supply," U.S.
Patent 4 084 217, Nov. 4, 1978.
Recommended