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.