universidad politécnica de madrid facultad de informática trabajo

Universidad Politécnica de Madrid Facultad de Informática

Trabajo de Fin de Máster Máster Universitario en Software y Sistemas

Entornos de Colaboración e Interacciones con Artefactos Médicos

Por Albert Menezes Moreira

Madrid, Junio 2011


Por

Albert Menezes Moreira

Presentado al Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software en cumplimiento

de los requisitos para el grado de

Máster Universitario en Software y Sistemas

En la

Facultad de Informática Universidad Politécnica de Madrid

Junio, 2011

José Crespo del Arco Grupo de Informática Biomédica

Tutor de Tesis Trabajo de Fin de Máster (15 ECTS)

Agradecimientos

Para Dios, la evidencia invisible en mi vida.

En memoria de mis padres, que me acompañaron y dieron orientación en

mis primeros años de vida.

A mi hermana, el mejor ejemplo que he tenido en la vida, que me dio la

bienvenida, más allá de cumplir su función, dar amor, cariño, aliento y me hace

aprender más y más. Entre las diversas personas mencionadas aquí dedico este

trabajo, sobre todo ella.

A mi familia, especialmente mis hermanos que me dieron una sólida base

para mi formación. Cada uno tenía su importante contribución a mi crecimiento

como individuo.

A mi director de tesis José Crespo, el conocimiento compartido, la

supervisión, la confianza y la paciencia, siendo parte de este y otros proyectos.

Un fuerte abrazo a mi gran "hermano" Micael Coutinho de la Universidad

Estadual de Sureste Baiano por su ayuda y apoyo en momentos cruciales durante

esos 15 años. Tío, tu amistad vale oro.

Un agradecimiento especial también a Marcelo Ferreira, del Departamento

de Ingeniería del Software e Iván Brondino, Departamento de Sistemas Distribuidos.

Sus aportaciones fueron muy valiosas.

También agradezco a mis queridos amigos de MUSS/DSS de la Universidad

Politécnica de Madrid Carlos Mendoza, Carlos Fernández, Christoph, Daniel, Diego

Riofrío, Yucra Diego, Edison, Juan, Jesús, Mayeline, Rodrigo, Rohit, Sebastián, Sergio

y Víctor. ¡De verdad sois parte de mi vida!

No podía dejar de mencionar el espíritu de colaboración de muchos

profesores con los que he tenido mucho gusto en el intercambio de experiencias y

expresar opiniones sobre diversos temas de la informática. Los profesores Angélica

de Antonio, Javier Segovia, Natalia Juristo y Víctor Maojo, por los consejos que sin

duda influyeron en la dirección de esta tesis.

Por el profesor David Kaufman, del Departamento de Informática Biomédica de la Universidad de Columbia, que me llevó a pensar aún más sobre los aspectos relevantes de este trabajo. A los profesores Samuel Isaac Kohane y Kenneth D. Mandl de la Universidad de Harvard, la retroalimentación con respecto al uso de la información sensible a los pacientes a través de Internet.

“Boldness has genius, power, and magic in it”. Goethe

Resumen Tradicionalmente, la discusión de casos clínicos es presencial. Debido al

avance de los medios de comunicación, es posible interactuar a distancia por el uso de computadores y redes de alta velocidad. Gran parte de los entornos virtuales para la salud son desarrollados para una interacción privada, entre dos o más personas que probablemente se conocen y previamente programaron la reunión.

La propuesta de Sanar es ofrecer un entorno donde se pueda crear una discusión acerca de un caso en una sección abierta en una interacción asíncrona, como en un e-mail, un fórum o una lista de discusión. Un usuario podrá publicar un caso con una descripción, una o más imágenes y un posible diagnóstico. Con base en las informaciones, otros usuarios tendrán acceso y podrán comentar, también agregando imágenes para basar su argumento.

Esta solución promueve el crecimiento del potencial del grupo a través de contribuciones individuales, con el objetivo de la construcción de un artefacto: el caso médico. Posibilita también estudiar los diferentes mecanismos de interacción, los cuales pueden ayudar o no en una interacción con profesionales de salud en un contexto global, a través del potencial de la Web 2.0.

Palabras clave: Informática Biomédica, Trabajo Colaborativo, Web 2.0.

Abstract Traditionally, discussion of medical cases is conducted in person. Due to

advances in ways to communicate, people can interact at a distance by computers and high-speed networks. Much of virtual environments for health are developed for a private interaction between two or more health professionals who probably already know each other and have previously prescheduled a meeting.

The purpose of Sanar is to offer an environment to create a discussion about a case in an open session with asynchronous interaction, as in an email or a forum. A user can publish a case with a description, one or more images and a possible diagnosis. Based on the information, other users will be able to access and comment, also adding images to reinforce the argument.

This solution promotes the growth potential of the group and construction of medical knowledge through individual contributions to build an artifact: a medical case. It also allows to study how different mechanisms of interaction can help (or not) in an interaction with health professionals in a global context, through the potential of the Web 2.0

Keywords: Biomedical Informatics, Collaborative Work, Web 2.0.

Contenido

Albert Menezes Moreira i

Contenido

CAPÍTULO 1. INTRODUCCIÓN ..................................................................... 5

1.1. Motivación ................................................................................................. 6 1.2. Caracterización del problema ..................................................................... 6 1.3. Hipótesis y objetivos ................................................................................... 7 1.4. Enfoque de la solución ................................................................................ 8 1.5. Estructura del trabajo ................................................................................. 8

CAPÍTULO 2. MARCO TEÓRICO ................................................................ 11

2.1. Informática Biomédica .............................................................................. 11 2.1.1. Definición .......................................................................................... 12 2.1.2. Ejemplos ............................................................................................ 13 2.1.3. Historial ............................................................................................. 14 2.1.4. Sanidad e Internet ............................................................................. 17 2.1.5. Sistemas Especialistas e Inteligencia Artificial .................................... 18 2.1.6. Historia Clínica Electrónica ................................................................. 19 2.1.7. Protocolos y Frameworks ................................................................... 20 2.1.8. Informática Biomédica y La Web 2.0 .................................................. 21

2.2. Trabajo Cooperativo ................................................................................. 21 2.2.1. Groupware......................................................................................... 22 2.2.2. Aspectos relevantes en Groupware.................................................... 26 2.2.3. Memoria de Trabajo en Grupo ........................................................... 29 2.2.4. Evolución del Trabajo en Grupo ......................................................... 32

2.3. Medicalware ............................................................................................. 32

CAPÍTULO 3. SOFTWARES PARA CONSTRUCCIÓN COLABORATIVA DE CONOCIMIENTO MÉDICO 35

3.1. Recursos de los softwares para construcción colaborativa de conocimiento médico ............................................................................... 35

3.2. Proyecto e Implementación ...................................................................... 41 3.3. Productos desarrollados ........................................................................... 46 3.4. Comparativo entre herramientas desarrolladas ........................................ 49

CAPÍTULO 4. SOLUCIÓN PARA CONSTRUCCIÓN DE CONOCIMIENTO COLABORATIVO CON ARTEFACTOS MÉDICOS – SANAR............................................................ 52

4.1. Aspectos generales de la solución ............................................................. 52 4.1.1. Aspectos de la Informática Biomédica................................................ 53 4.1.2. Aspectos de Trabajo en Grupo ........................................................... 53 4.1.3. Aspectos de la Web 2.0 ...................................................................... 54

4.2. Características de la solución .................................................................... 54 4.2.1. Interfaz del usuario ............................................................................ 54 4.2.2. Facilidades de soporte a la Informática Biomédica ............................. 58 4.2.3. Facilidades de apoyo al Trabajo en Grupo .......................................... 58


ii Albert Menezes Moreira

CAPÍTULO 5. ARQUITECTURA DE LA HERRAMIENTA SANAR ............................. 60

5.1. Visión general de la arquitectura ............................................................... 60 5.2. Arquitectura Tecnológica .......................................................................... 61

5.2.1. Lenguaje Java ..................................................................................... 61 5.2.2. Lenguaje Java ..................................................................................... 62 5.2.3. Infraestructura ................................................................................... 63

5.3. Arquitectura funcional............................................................................... 63 5.3.1. Visión general de los módulos ............................................................ 63 5.3.2. Diagrama conceptual .......................................................................... 63 5.3.3. Diagrama Entidad Relación ................................................................. 66 5.3.4. Modulo arquitectural ......................................................................... 68

5.4. Visión general de la arquitectura ............................................................... 68

CAPÍTULO 6. SANAR – UN CASO DE ESTUDIO .............................................. 71

6.1. Descripción del experimento ..................................................................... 71 6.1.1. Participación de los usuarios .............................................................. 72 6.1.2. Manipulación de objetos .................................................................... 73 6.1.3. Variación de la interacción ................................................................. 73 6.1.4. Fases del experimento ........................................................................ 74 6.1.5. Discusiones ......................................................................................... 74 6.1.6. Análisis del experimento .................................................................... 75

6.2. Validación empírica ................................................................................... 75 6.2.1. Primer estudio .................................................................................... 75 6.2.2. Segundo estudio ................................................................................. 77

CAPÍTULO 7. CONCLUSIONES ................................................................... 81

7.1. Desarrollo del trabajo ................................................................................ 81 7.2. Objetivos alcanzados y contribuciones ...................................................... 82 7.3. Dificultades ............................................................................................... 83 7.4. Trabajos futuros ........................................................................................ 84

REFERENCIAS….….. ................................................................................... 87

ANEXOS….….. 93

A. Cuestionario de evaluación – Segundo estudio ............................................... 94

Contenido

Albert Menezes Moreira iii

Sumario de Figuras Fig. 1. Aspectos de la Informática Biomédica. ........................................................ 14 Fig. 2. Informática Biomédica – Línea del Tiempo. ................................................. 17 Fig. 3. Clasificación de groupware en las dimensiones tiempo y espacio. Fuente:

(CHAFFEY, 1998) ......................................................................................... 24 Fig. 4. Conocimiento Formal y Conocimiento Informal. .......................................... 30 Fig. 5. Barras de desplazamiento multiusuario. Fuente: (ROSEMAN, 1996) ............ 36 Fig. 6. Visualizador de Textos con Ojo-de-Pez. Fuente: GroupLab – Univ Calgary

(Canadá) (COCKBURN et al., 1996) .............................................................. 37 Fig. 7. Stick-Ons. Fuente: (PINO, et al., 2001) ......................................................... 38 Fig. 8. Visualizador Gráfico con Ojo-de-Pez. Fuente: GroupLab – Univ Calgary

(Canadá) (COCKBURN et al., 1996) .............................................................. 39 Fig. 9. Visión de Radar. Fuente: GroupLab – Univ Calgary (Canadá)........................ 40 Fig. 10. Conferencia con Medcast. Fuente: (MORENO, 2010) ................................. 46 Fig. 11. Datos ecográficos de un feto en diSNei. Fuente: (RODRIGUEZ et al., 2000) 48 Fig. 12. Página inicial de FamilyDoctor. .................................................................. 49 Fig. 13. Pantalla inicial de Sanar. ............................................................................ 55 Fig. 14. Nuevo caso en Sanar. ................................................................................ 56 Fig. 15. Simulación en Sanar. ................................................................................. 57 Fig. 16. Configuración de Perfil. ............................................................................. 58 Fig. 17. Procedimiento de uso de Sanar. ................................................................ 60 Fig. 18. Diagrama Conceptual de Clases de Sanar. ................................................. 64 Fig. 19. Diagrama Conceptual de Entidad Relación de Sanar. ................................. 66 Fig. 20. Patrón de arquitectura Modelo Vista Controlador. .................................... 68


iv Albert Menezes Moreira

Sumario de Tablas Tabla 1. Productos para desarrollo de groupware. ................................................. 45 Tabla 2. Herramientas médicas. ............................................................................. 50 Tabla 3. Diccionario de Datos Diagrama Conceptual - Sanar. .................................. 65 Tabla 4. Diccionario de Datos DER - Sanar. ............................................................. 67 Tabla 5. Aspectos considerados en la experimentación. ......................................... 74

Capítulo 1. Introducción

Albert Menezes Moreira 5

Capítulo 1. INTRODUCCIÓN

En la última década, grandes avances en las tecnologías de hardware y software posibilitaron la evolución de la informática. Hoy en día, ordenadores personales alcanzaron un nivel de desempeño superior, una vez comparado con lo que se tenía hace algunos años. Se puede enumerar como razones por ejemplo el aumento de la velocidad del procesador, del tamaño de las memorias y los precios más económicos.

Las redes de ordenadores han evolucionado desde las redes de área local a las redes de área amplia. Lo que se llama por World Wide Web se convirtió en un entorno accedido por una cantidad cada vez más grandes de usuarios. Lo que se empezó con el deseo de crear un mecanismo para intercambiar informaciones entre científicos resultó en una plataforma utilizada para intercambiar datos y permitir que usuarios en línea puedan acceder a los datos guardados en sitios remotos.

Como consecuencia de esta rápida evolución, se empieza a observar o surgimiento de estructuras participativas, con valores relacionados al trabajo en grupo, como por ejemplo la capacidad de cooperación y coordinación. En este contexto, surgió un área responsable por el estudio es estos fenómenos, denominada Trabajo Cooperativo o Computer Supported Cooperative Work (BANNON et al., 1988).

Una vez que el área de CSCW puede proponer mejoras en la colaboración y el acceso a la información entre personas geográficamente dispersas, ha habido un gran interés en su utilización en organizaciones sanitarias y investigadores que crearon el área que hoy se conoce por Informática Biomédica, disciplina científica


6 Albert Menezes Moreira

cuya finalidad es sistematizar datos, informaciones y en medicina y salud (HASMAN, et al., 1996).

Un ejemplo de esto es el trabajo de organizaciones de salud, desarrolladores e investigadores para crear registros electrónicos de salud y sistemas de información clínica para ofrecer una mejora en el flujo de información y coordinación entre los trabajadores, independientemente de si están distribuidos en horarios o locales diferentes (CRESPO, 2002).

1.1. Motivación Está claro que existen desafíos para el desarrollo de diversos sistemas CSCW

para organizaciones de la salud. El objetivo de las aplicaciones construidas con base en el área de CSCW es crear un resultado de trabajo en grupo más grande que las suma de la contribución de cada miembro. La estrategia es permitir al grupo desarrollar el espíritu de grupo, complementando cada integrante, compartiendo conocimientos y habilidades hacia un objetivo común y la cooperación.

La discusión de casos clínicos es esencial para el profesional de la salud, una vez que permite discutir cuestiones técnicas difíciles y controvertidas, mediante el intercambio de opiniones y experiencias con otros profesionales.

Esta actividad también es importante para el estudiante de medicina, sobre todo para simular la profesión (por ejemplo, proponer soluciones a un caso) y ofrecer la oportunidad de detectar puntos donde existe una deficiencia en el desarrollo del razonamiento diagnóstico, más exactamente la distinción de las enfermedades con síntomas similares.

1.2. Caracterización del problema Hay un esfuerzo para generar conocimiento y gestión de la información

pertinente dentro de un entorno hospitalario, sobre todo para ayudar a las zonas donde las necesidades más básicas no se han cumplido.

En los países emergentes, por ejemplo, varias enfermedades no pueden ser tratadas en el momento adecuado por no existir una infraestructura básica de sanidad. La ausencia de un apoyo adecuado para el diagnóstico puede dar lugar a una administración incorrecta de medicamentos, complicaciones graves y en algunos casos la muerte del paciente.

Esta ausencia puede atribuirse a varias razones, principalmente relacionadas con la falta de infraestructura básica para el manejo adecuado de los casos. De todas maneras, existen iniciativas que pueden ser desarrolladas, aunque fuera de



un entorno de sanidad. Es posible compartir el conocimiento médico, sobre todo aquel que ha sido desarrollado con la experiencia cotidiana, que difícilmente será encontrado en la literatura médica. En algún momento, esto puede ser útil para un diagnostico más seguro.

Con base en las necesidades identificadas y la premisa de que el uso de un entorno de colaboración para la construcción de los conocimientos médicos por medio de artefactos puede ayudar con un diagnóstico más seguro, se plantea el problema a continuación:

¿La utilización de entornos web colaborativos con artefactos médicos tendrá un impacto positivo en interacciones entre individuos geográficamente dispersos?

1.3. Hipótesis y objetivos Buscando la manera de resolver este problema, el enfoque de esta tesis es

proporcionar un entorno web de colaboración, mediante el cual es posible analizar un caso basado en texto e imágenes. El objetivo es obtener el mayor número posible de opiniones sobre el posible diagnóstico de este caso, ofreciendo un diagnóstico más preciso de sus pacientes.

De acuerdo a lo que se menciona en la sección 1.2, la existencia de la información pertinente a la discusión, así como un entorno propicio para la interacción podría ser un factor determinante para el éxito del experimento.

Por lo tanto, el presente trabajo se apoya en la hipótesis siguiente:

Mecanismos de interacción facilitan la colaboración y sobretodo la construcción de conocimiento en el área médica.

Los objetivos propuestos que se pretenden alcanzar en esta tesis son:

Revisar el estado del arte a través de referencias consolidadas en el área.

Desarrollar una aplicación para ejecutar los experimentos planificados.

Demostrar la validez de las hipótesis mencionadas.



1.4. Enfoque de la solución La propuesta de Sanar es ofrecer un entorno donde se pueda crear una

discusión acerca de un caso, sin las barreras de una sección privada y las dificultades de organizar una interacción síncrona. Un usuario podrá publicar un caso con una descripción, una o más imágenes y un posible diagnóstico. Con base en las informaciones, otros usuarios tendrán acceso y podrán comentar, agregando más imágenes para basar su argumento.

Tradicionalmente, la discusión de casos clínicos es presencial. Debido al avance de los medios de comunicación actuales, es posible que esta interacción sea realizada a distancia por el uso de computadores y redes de alta velocidad.

En un plan educacional, otra posibilidad es aplicar Sanar con estudiantes, proponiendo preguntas que podrán ser contestadas posteriormente, en una nueva reunión, donde el moderador podrá comentar el diagnóstico del paciente y el raciocinio utilizado para llegar a esta conclusión, excluyendo otras posibilidades.

A pesar de su importancia, las discusiones de casos clínicos aún son subutilizadas, sobre todo acerca de la generación masiva de contenido para resolver un problema o por lo menos presentar un avance para problemas más complicados, que exigen la interacción de varias personas con diferentes formaciones.

1.5. Estructura del trabajo En el capítulo 2 se presentan los principales conceptos relacionados con el

Trabajo Cooperativo Apoyado por Ordenador y la Informática Biomédica. A partir de esta presentación, se analizan las cuestiones derivadas de las relaciones entre estos dominios.

Capítulo 3 continúa la descripción de estos conceptos, dirigiendo la atención a los recursos presentes en los entornos de colaboración para la informática médica. También se describen sus principales características, a través de un cuadro comparativo, y menciona los principales problemas encontrados, sobre todo en el software cuya interacción es asíncrona.

El capítulo 4 describe Sanar. Su objetivo es presentar a través de una descripción en alto nivel, a través de pantallazos, las características del software que se explican de forma clara y directa.

En el capítulo 5, se presenta la arquitectura de la herramienta, detallando el medio utilizado para su desarrollo, cuáles son sus componentes y módulos de la estructura interna de estos módulos.



La demostración de la aplicabilidad de los recursos y la evaluación de sus resultados en un estudio de caso real es la cuestión que se aborda en el capítulo 6. Las etapas de la interacción, así como las conclusiones se basan en conceptos de la Ingeniería de Software Experimental.

Por último, el capítulo 7 trata de las conclusiones de este trabajo, presentando las mayores dificultades en su desarrollo, las principales aportaciones y perspectivas para el trabajo futuro.

Capítulo 2. Marco Teórico


Capítulo 2. MARCO TEÓRICO

En este capítulo se presentan los conceptos básicos acerca de Informática Biomédica y Trabajo Cooperativo. En seguida, se analizan los temas resultantes de estos dos dominios, los cuales tienen por finalidad justificar la concepción de Sanar.

2.1. Informática Biomédica Los sistemas computacionales de tecnologías se están volviendo

crecientemente esenciales para la práctica moderna de la medicina, la investigación clínica, la gestión de la salud y entrenamiento de profesionales del sector. Esto es algo que ocurre sobre todo por la gran necesidad de profesionales bien formados.

Como resultado de este trabajo, la Informática Biomédica es un dominio de los nuevos conocimientos de informática y Ciencias de la Información, la Ingeniería y la Tecnología en todos los ámbitos de la salud y la medicina, incluida la investigación, la educación y la práctica (COLLEN, 1986). Se trata de una ciencia interdisciplinar que agrega herramientas prácticas y conceptuales para comprender y generar información médica con la finalidad de resolver problemas complejos, además de prevenir y tratar enfermedades.

La investigación en este entorno posibilita la comprensión de fundamentos teóricos de ciencias de la salud y los sistemas de prestación de salud. En un ámbito más práctico, el individuo se centra en el estudio de estructuras, algoritmos y desarrollo del conocimiento en lógica necesario para manejar datos para producir nuevas soluciones, las cuales serán aplicadas en la gestión de la salud, toma de decisiones clínicas e investigación en sistemas biomédicos. Entrando en más a detalle, es posible seguir para diversas áreas de especialización entre las cuales:

• Sistemas de Biotecnología



• Análisis de Imágenes Médicas

• Sistemas de Soporte a la Toma de Decisiones

• Sistemas de Gestión de Hospitales.

2.1.1. Definición La definición de Informática Biomédica es dinámica, debido sobre todo en la

naturaleza de rápido cambio de la medicina y tecnología. A continuación algunas opiniones de investigadores en el área.

"(...) el campo de rápido avance científico que se ocupa del almacenamiento, la recuperación y el uso óptimo de la información biomédica, datos y conocimientos para la resolución de problemas y toma de decisiones" (SHORTLIFFE et al., 1990).

“campo de la ciencia que se ocupa de los recursos, dispositivos y métodos formales para la optimización del almacenamiento, recuperación y manejo de información biomédica para la solución de problemas y toma de decisiones” (RAND, 2005).

“aplicación de la informática, las comunicaciones y tecnologías de la información y sistemas para todos los campos de la medicina - la atención médica, educación médica y la investigación médica” (BOWER et al., 2005).

“conocimientos, habilidades y herramientas que permiten el intercambio y uso de la información para ofrecer atención sanitaria y promoción de la salud” (WIKIPEDIA, 2011).

De todas maneras, el consenso de que Bioinformática involucra la integración de biología y tecnología puede ser definido como:

“análisis de información biológica con computadoras y técnicas estadísticas; la ciencia de la elaboración y utilización de bases de datos informáticas y algoritmos para acelerar y mejorar la investigación biológica” (TOLEDO, 2011).

En general se adopta la nomenclatura Informática Biomédica porque incluye también características de otras ciencias de la salud, como por ejemplo odontología, enfermería, salud pública, farmacia y medicina veterinaria. Una vez que ocurra la integración de la genética humana en la práctica cotidiana de la medicina, esta definición podrá ganar más fuerza. Para la construcción de esta tesis, se ha optado por utilizar la nomenclatura Informática Biomédica.



2.1.2. Ejemplos Como ejemplos de uso de la Informática Biomédica, se incluye:

1. Minimizar incertidumbres de diagnóstico y mejora de toma de decisiones clínicas utilizando las tecnologías de la información y comunicación, como por ejemplo desarrollar herramientas que puedan determinar la probabilidad de que un paciente de urgencias con dolor torácico tenga una isquemia cardiaca aguda o más posiblemente un infarto de miocardio.

2. Diseño y desarrollo de un sistema de consulta interactivo para tratar a pacientes de modo más eficiente a través de la consulta de bases de datos con una amplia gama de experiencias clínicas.

3. Mejorar los métodos de investigación de ensayos clínicos, estudios epidemiológicos y de investigación de servicios de salud.

4. Realización de actividades de garantía de calidad y en servicio a través de un sistema de gestión adecuado.

5. Creación de sistemas para reconstrucción de una imagen, visualización en entorno 3D y análisis de datos de imágenes médicas.

6. Uso de métodos matemáticos agregados a tecnologías computacionales para diseño de medicinas o resolución de problemas clínicos más complejos.

7. Desarrollo de aplicaciones para visualizar datos médicos en 3D, de modo a mejorar el análisis, comprensión y tratamiento de anomalías en estructuras internas y en su función.

8. Diseñar un sistema que controle el tiempo, de manera que se gaste menos tempo en tareas importantes como por ejemplo el manejo adecuado de informaciones entre personas profesionales de salud, además de la delegación de tareas para equipos.

9. Concepción de bases de datos con informaciones médicas digitalizadas para teleradiología o consultas.

10. Gestión de clínicas, farmacias, radiología, laboratorio a través de Sistemas de Información Hospitalarios.



Tal y como se puede ver en la figura 1 a continuación, los diversos aspectos de la Informática Biomédica están interconectados:

Fig. 1. Aspectos de la Informática Biomédica.

Por ejemplo, a una organización de salud le preocupa que muchos de sus pacientes diabéticos no estén bien controlados y cree en los beneficios de un portal web para la diabetes. Con esta solución, los diabéticos pueden cargar muestras de sangre y presión arterial a un sitio web central, de modo que médicos puedan analizar los resultados y hacer recomendaciones.

2.1.3. Historial La Informática Biomédica ha evolucionado en los últimos 30 años como

siendo capaz de utilizar la tecnología para satisfacer sus necesidades, sobre todo en el manejo de informaciones complejas. Los primeros artículos sobre este tema aparecieron en la década de 1950, aumentando rápidamente en la década de 1960 y generando una nueva especialidad en la década de 1970.

De en la visión de Collen (1986), las primeras referencias de la aplicación de tecnología en la salud ha sido más o menos por 1950 en los temas de biofísica,



bioingeniería y publicaciones electrónicas sobre estos temas. Como consecuencia del rápido avance, surgieron diversos nombres para este campo de estudio, como por ejemplo Computación Médica, Medicina Computacional, Procesamiento de Datos Electrónicos Médicos, Procesamiento de Datos Automáticos Médicos, Procesamiento de Información Médica, Ciencias de la Información Médica, Ingeniería de Software Médica y Tecnología Computacional Médica.

A partir de la década de 1970 empezó a existir una preocupación hacia la creación de un nombre para este nuevo dominio de los conocimientos médicos, más específicamente para encontrar un término para incluir ciencia, ingeniería y tecnología de un lado, además de la medicina o salud por otro.

En la última década ha sido posible ver un aumento del papel del ordenador en la práctica médica. Anteriormente, existía un énfasis en la construcción de sistemas informáticos inteligentes, lo cuales podrían ayudar médicos a diagnosticar o generar planteamientos automáticos. Hoy en día, está claro que estos programas tienen su importancia. Existe también un análisis más relacionado en la interacción humano computador. Una gran necesidad de los profesionales de la salud, por ejemplo, es la posibilidad de acceder a los sistemas y sacar rápidamente notas clínicas, solicitudes y informes de investigación y acceso a la literatura actual (SHORTLIFFE et al., 1990).

Con más necesidades de desarrollo, el número de aplicaciones ha continuado creciendo, inclusive como software embebido. Un sistema moderno de monitorización puede tener más de un millón de líneas de código, con la finalidad de interpretar informaciones y presentarlas en pantalla. Estos avances transforman los aparatos de hardware de la misma manera que estos transformaron el área de Imágenes Médicas, cambiando por ejemplo la fuerza computacional de una máquina de Rayos X por un CT Scanner (COIERA, 2001).

Lo que no está claro para la gran parte de los médicos en ejercicio es la gran cantidad de recursos ofrecidos por las tecnologías de la información y comunicación, y cómo pueden resultar en un impacto real en la práctica clínica diaria. Mientras existe un beneficio real en utilizar un ordenador para administrar aspectos clínicos, como por ejemplo utilizando softwares para gestión de imágenes médicas para diagnósticos más precisos, algunos profesionales aún no están muy convencidos acerca del potencial y los beneficios aportados (SHORTLIFFE, 1987).

Para poder observar la evolución de las distintas áreas que conforman la Informática Biomédica, a continuación, una cronología de eventos clave (HOYT, 2007).



Ordenadores

El primer ordenador de propósito general cuyo nombre es ENIAC fue lanzado en 1946 y tenía 1.000 metros cuadrados de superficie. La empresa de tecnología IBM desarrolló la primera computadora personal en 1982 con un total de 16K de memoria. La primera vez en que los ordenadores fueron concebidos para el diagnóstico y tratamiento médico por Ledley y Lusted ha sido en los años 1950. En este momento, llegaron a la conclusión de que ordenadores podrían guardar y procesar información más rápidamente que seres humanos.

Origen del nombre Informática Médica

Además de lo que ha sido comentado en la sección anterior sobre la creación del nombre Informática Médica, se cree que el origen del término se remonta a la década de 1960 en Francia con la expresión “Informatique Médicale”.

MEDLINE

A mediados de la década de 1960 la base MEDLINE fue creada para organizar la literatura médica mundial. Para profesionales de salud más antiguos, lo cuales tenían que buscar sobre un tema en el base textual Index Medicus, esta iniciativa representó una gran mejora.

Inteligencia Artificial

Proyectos de Inteligencia Artificial como MYCIN, de la Universidad de Pittsburg y INTERNIST-1 de Stanford, aparecieron en la década de 1970.

Internet

El desarrollo de Internet empezó 1969 con la creación de la red gubernamental ARPANET. El concepto de World Wide Web fue concebido por Tim Berners-Lee en 1990 y el primer navegador ha sido lanzado en 1993. La Internet hoy es una fuente importante para librerías digitales médicas, intercambio de informaciones médicas y aplicaciones para entorno web.

Historia clínica electrónica

La historia clínica electrónica ha sido tratada desde la década de 1970 y recomendada por el Instituto de Medicina en 1991.



Tecnología handheld

En 1996, el Personal Digital Assistants PalmPilot ha sido lanzado como un dispositivo que computa verdaderamente popular de mano. PDAs cargados con aplicaciones médicas se han convirtido en equipos importantes para estudiantes en formación, e inclusive han sido introducidos en smartphones como iPhone.

Proyecto de Genoma Humano

En 2003, el proyecto de Genoma Humano ha sido completado después de trece años de de investigación colaborativa internacional. Mapear todo los genes humanos ha sido uno de los más importantes hechos de la historia científica. A pesar de que el proyecto está completo, tomará por lo menos 20 años para analizar todos los datos. Estos resultados podrán revolucionar la manera como se practica la medicina hoy.

Nationwide Health Information Network

El concepto ha sido desarrollado en 2004 con el objetivo de conectar todos los registros electrónicos médicos, redes regionales y agencias del gobierno de EEUU en un sistema. Lo que se espera es hacerlo en un periodo de una década. Proveer interoperabilidad entre todos los sistemas de sanidad será un reto importante.

Fig. 2. Informática Biomédica – Línea del Tiempo.

2.1.4. Sanidad e Internet Internet facilita el intercambio de e-mail entre profesionales de salud y

existen numerosos grupos de discusión de especialistas, lo que posibilita llevar a cabo un intercambio continuo. Es posible acceder también a una variada cantidad de información, que incluyen bases de datos clínicos y publicaciones en revistas especializadas:



• Australian National University Bioinformatics Hypermedia Service

• Geneva University Hospital Molecular Biology Server

• International Cancer Institute

• Johns Hopkins University Bioinformatics Web Server

• National Institute of Allergy and Infectious Disease

• National Institutes of Health

• National Library of Medicine

• Online Mendelian Inheritance in Man

• Pubmed

• World Health Organization

2.1.5. Sistemas Especialistas e Inteligencia Artificial Además de lo comentado sobre los aspectos humanos en el historial sobre

Informática Biomédica, otra mejora ha sido la influencia de la computadora en la toma de decisiones clínicas. Los sistemas de diagnostico artificialmente inteligentes, los Sistemas Especialistas son el ejemplo más común, una vez que recogen un conjunto de reglas obtenidas de expertos humanos, sacando conclusiones sobre la situación de un paciente (BRATKO et al., 1989).

Frecuentemente se presenta el inconveniente causado por la mala implantación de los sistemas en la práctica clínica, sea para resolver problemas no interpretados como tal, sea imponiendo cambios en la forma de trabajar de los médicos. De todas maneras, cuando son aplicados de una manera adecuada, estos softwares de hecho pueden ofrecer beneficios significativos.

Una de las más importantes tareas que se enfrentan los encargados de desarrollar los sistemas expertos es caracterizar con precisión los aspectos de la práctica médica que mejor se adapten con la utilización de sistemas de Inteligencia Artificial. De acuerdo con investigaciones realizadas por la comunidad de Informática Biomédica, fueron catalogados más de 25 softwares especialistas,



aplicados para diversas finalidades. El sistema PUFF (AIKINS et al., 1983), por ejemplo, tiene por finalidad interpretar automáticamente pruebas pulmonares.

A través del presente trabajo se han podido identificar sistemas especialistas en diversas áreas de la salud, como la educación de pacientes, asistencia a la toma de decisiones y gestión de sanidad. El panorama es muy diferente al de hace una década, cuando la mayoría de los sistemas todavía eran experimentales y había menor uso de la tecnología en la práctica clínica.

2.1.6. Historia Clínica Electrónica Otro aspecto importante identificado es que algunos funcionarios de la salud

subestiman la complejidad de introducir registros informáticos de un paciente. Hoy en día, diversos hospitales y consultorios médicos manejan sus propios sistemas locales de información clínica, capturando algunas características del área de historia clínica electrónica. También pueden ofrecer pruebas para introducción de medicamentos y recuperación de resultados de consultas. Por otro lado, existe una falta de uniformidad entre los sistemas y por esta razón el intercambio de información entre las instituciones que los tienen no es simple. En verdad, ocurre con frecuencia que los hospitales tienen diferentes sistemas por razones históricas, pudiendo resultar complicado establecer la comunicación entre ellos.

De acuerdo con Health Information Management Systems Society, la definición de los sistemas de Historia Clínica Electrónica (HIMSS, 2011) es:

“La Historia Clínica Electrónica (HCE) es un registro electrónico longitudinal de información generada acerca de la salud del paciente a través de uno o más encuentros en cualquier lugar de prestación de atención. Incluido en esta información están datos demográficos del paciente, nota de sus progresos, los problemas, los medicamentos, las señales vitales, antecedentes médicos, vacunas, datos de laboratorio e informes de radiología. La HCE automatiza y racionaliza el flujo de trabajo clínico. La HCE tiene la capacidad para generar un registro completo de un encuentro con el paciente clínico, así como el apoyo a otras actividades relacionadas con la atención directa o indirectamente a través de una interfaz, incluyendo soporte de decisiones basada en evidencias, gestión de la calidad y resultados de informes”.

Vale señalar que HCEs son construidas e mantenidas en una institución de salud, como por ejemplo un hospital, una red de servicios médicos integrados o una clínica. En general, un HCE tampoco es un registro de toda la atención prestada al paciente a través del tiempo. Registros longitudinales más completos pueden mantenerse en un sistema de información sanitario a nivel nacional o regional.



2.1.7. Protocolos y Frameworks Como resultado de la construcción de aplicaciones para entornos de salud,

se hizo también investigaciones sobre protocolos y frameworks para agregar sobre todo más seguridad a la implementación de Sanar. A continuación son presentadas algunas de estas tecnologías.

DICOM

DICOM es un estándar aplicado en todo el mundo. Su estructura ha sido desarrollada en 1993 y tiene por finalidad facilitad la interoperabilidad entre sistemas para producir, guardar, procesar, presentar, enviar, consultar e imprimir imágenes médicas y documentos estructurados, además de gestionar este flujo.

Este estándar es extremadamente adaptable. Esto explica el hecho de que diversos vendedores de equipos de imágenes médicas están interesados en DICOM. La organización de estándares europea y el comité europeo de normalización utilizan DICOM como base para el estándar MEDICOM. En Japón, la Asociación de la Industria de Aparatos de Radiación y Sistemas de Información Médicos adoptó algunas partes de DICOM para intercambio de imágenes. En la fecha de construcción de este trabajo, este estándar sigue mantenido y extendido por un comité internacional multidisciplinar.

DICOM es utilizado como estándar predominante para comunicación con imágenes médicas. Además de eso, los fabricantes se han buscado expandirlo para soportar otros tipos de imágenes.

HL7

HL7 se formó en 2002, empezando como un consorcio fundado por la iniciativa de profesionales de salud, con el objetivo de colaborar para construir un protocolo de intercambio de información médica. La versión 1.0 ha sido considerada pragmática, sin una reflexión previa sobre la metodología de desarrollo. La versión 2.0 ha presentado mejoras, como por ejemplo, la noción de que un evento externo puede ocurrir y ser reconocido por una aplicación de salud. Una vez reconocido, esta aplicación envía un mensaje específico, que por su vez será recibido por otras aplicaciones, de manera a manejar la interacción entre los diferentes sistemas de información.

De acuerdo con informaciones del sitio oficial hl7.org, la comunidad tiene más de 1700 miembros, de los cuales 450 son representantes de organizaciones. Además de eso, existen seis organizaciones internacionales afiliadas que trabajan y crean implementaciones para aplicar en sus respectivos países.



2.1.8. Informática Biomédica y La Web 2.0 Aunque existan varias corrientes con definiciones distintas acerca de la Web

2.0, la mayoría estaría de acuerdo con lo que sería una Internet con fines direccionados a la colaboración. Se puede entender la Web 2.0 como la posibilidad de manejar aplicaciones web ricas de funcionalidades y sobre todo de interfaz. Lo que antes era una persona accediendo a un sitio web, ahora puede ser la multitud de personas, con experiencias diferentes, aprovechándose de múltiples herramientas gratuitas de la web. Algunos de los primeros ejemplos serían Wikipedia y Flickr. La llegada de este movimiento ha sido estimulada con la aparición de redes sociales, blogs y podcasts.

Por medio de algunos ejemplos, la Web 2.0 empieza a afectar a la medicina. A continuación, algunos programas médicos que manejan aplicaciones de Internet:

• El Instituto Tecnológico de Massachusetts desarrolló el concepto de "OpenCourseWare", concepto que facilita la publicación de sus materiales y resultados de investigaciones de manera libre a educadores y estudiantes.

• La adopción de Moodle, una herramienta de colaboración para enseñanza, por parte de diversas universidades.

• El Proyecto Saphire permite que se realice búsqueda de información basada en su significado, en lugar de las convencionales etiquetas. La Unión Europea está patrocinando el Proyecto Saphire, lo cual ayudará en la toma de decisiones mediante el control de datos de sensores personales médicos y sistemas de información hospitalarios.

• SugarStats es un programa para diabéticos que permite la carga de muestras de azúcar en la sangre con Twitter. Diversas páginas web como por ejemplo iHealthBeat pueden ser seguidas en Twitter.

2.2. Trabajo Cooperativo La reciente transformación en el mundo de los negocios, sobre todo después

de la ola de Reingeniería de Procesos surgida en los años 90, ha llevado a las organizaciones a abandonar sus viejas estructuras en el proceso de búsqueda sea más competitiva y orientada al cliente. El trabajador que antes era industrial, altamente especializado y dirigido a un conjunto limitado de tareas, ha sido reemplazado por equipos multidisciplinarios. Una de las herramientas más valiosas para estas nuevas estructuras organizativas son los sistemas para apoyar el trabajo de grupo. El uso de herramientas individuales, en los que el individuo interactúa sólo con la computadora y sus programas, dio lugar a productos que permiten el



intercambio de ideas, información y tareas entre los miembros del equipo para cumplir con sus procesos de negocio manera más eficiente (BRINK, 1998).

Estos productos se llaman Sistemas de Colaboración, representada por las aplicaciones como el correo electrónico, videoconferencia, chat, sistemas de comunicación, grupos de discusión, entre otras. También son estudiadas por el área de CSCW (Computer Supported Cooperative Work), que investiga la forma de trabajar en grupo usando la tecnología informática. Son también evaluadas cuestiones en la relación a desarrollo, adopción y utilización de sistemas de colaboración. A pesar de su nombre, esta área no se limita a los problemas de la cooperación y trabajo, abordando también el tema de la competencia, la socialización y la participación, involucrando gente interesada en la construcción de software y en el comportamiento social y organizacional, de diferentes especialidades, incluyendo a las personas de negocios, informática, psicología, antropología y comunicación.

De hecho, hay que tener en cuenta cuestiones culturales y personales para evaluar, desarrollar, adquirir o utilizar una herramienta de CSCW. Cuestiones tecnológicas no pueden considerarse de forma aislada y sólo son relevantes en el contexto del grupo en cuestión. Herramientas para el trabajo en grupo son más difíciles de implementar que las tradicionales. Un sistema de colaboración no alcanza el éxito a menos que la mayoría o la totalidad del grupo objetivo esté de acuerdo en su aprobación, a diferencia de los sistemas individuales, que puede tener éxito si sólo una fracción del mercado lo adopta (BRINK, 1998).

2.2.1. Groupware Groupware significa tecnología diseñada para facilitar el trabajo en grupo,

una vez que pueden ser grupos con cohesión, desarrollando un nuevo producto para un mercado, o un equipo menos formal, compuestos por personas de diferentes orígenes e intereses, con objetivos menos definidos.

La adopción creciente de estos productos se vieron impulsados por la disponibilidad de redes de bajo coste como Internet, proporcionando la infraestructura para el crecimiento en la comunicación y realización de tareas dentro y entre las empresas. Las razones para el interés en el trabajo en grupo incluyen algunas importantes ventajas de estas herramientas para los usuarios. Entre los más comunes, podemos enumerar:

• La facilidad de comunicación, más rápida, más simple y más barata

• La posibilidad de interacciones en paralelo



• La oportunidad de reunir a múltiples perspectivas y experiencias

• La posibilidad de formar grupos de interés común donde no sería posible reunir un número suficiente de gente cara a cara para ahorrar tiempo y costos en la coordinación de grupos de trabajo

• La facilidad de resolver problemas en conjunto, lo que permite nuevas formas de comunicación tales como la cooperación e interacciones estructuradas.

La herramienta de trabajo en grupo más popular es el correo electrónico, alcanzando no sólo en el mundo empresarial sino también en el uso personal. Otras herramientas como foros de discusión, chat y videoconferencia tienen un crecimiento en su uso, proporcionando mejoras en las comunicaciones a un costo razonable. La variedad de problemas comunes en las reuniones dio lugar a la creación de un espacio dedicado específicamente al estudio y desarrollo de soluciones nominada meetingware.

Herramientas Groupware normalmente se pueden clasificar por las dimensiones de tiempo y espacio. La primera indica si los usuarios del groupware están trabajando juntos en la marcha (groupware en tiempo real, sincrónico) o en diferentes momentos (groupware asincrónico). La segunda dimensión indica si los usuarios están trabajando juntos en la misma ubicación física (cara a cara) o en lugares diferentes (de forma remota).

La figura 2 divide las herramientas de trabajo en grupo en tiempo y espacio. La videoconferencia y el chat son ejemplos de trabajo sincrónico y remoto. Correo electrónico, foros y herramientas de flujo de trabajo proporcionan trabajo asincrónico para equipos que trabajan en el mismo lugar o dispersos, distribuidos dentro de la misma oficina, o en diferentes países.



Fig. 3. Clasificación de groupware en las dimensiones tiempo y espacio. Fuente: (CHAFFEY, 1998)

El desarrollo del trabajo en grupo requiere entender el comportamiento de las personas. Aspectos no relacionados con la tecnología deben ser verificados como por ejemplo la homogeneidad de los participantes, el papel desempeñado por cada uno de los del grupo de trabajo, y la influencia ejercida por los tomadores de decisiones dentro del grupo. Por ejemplo, las sospechas planteadas en los líderes de opinión de un equipo cuando un trabajo en grupo permite a los participantes para expresar sus puntos de vista y argumentos de forma anónima. Grudin pone de relieve una serie de importantes cuestiones culturales, como las convenciones sociales y las prioridades implícitas que orientan inconscientemente las acciones dentro de un grupo (GRUDIN, 1994).

Otras cuestiones deben ser consideradas, como el número de miembros en el grupo: un grupo de cientos de personas se comporta de manera diferente de otro con 5 personas. Las necesidades tecnológicas de los resultados también varían entre los dos grupos con tamaños tan diferentes. En herramientas síncronas, no solamente el tiempo de respuesta, sino también el tiempo de reacción son cuestiones muy importantes.

Un aspecto relevante en groupware es la interfaz de la aplicación. Mientras que las aplicaciones individuales para el desarrollo de la interfaz deben apegarse a los recursos de la interacción humano-computadora, aplicaciones de colaboración necesitan considerar aspectos de la interacción humana, permitiendo al usuario interactuar en parejas en determinadas situaciones. Para algunas herramientas puede haber ocasiones donde las interacciones entre tres, cuatro o más personas simultáneamente. La interfaz de la aplicación debe proporcionar recursos para la comprensión de las acciones de otros participantes, coordinar sus acciones y



determinar su disponibilidad (GREENBERG, 2001). De este modo, algunas herramientas utilizan un espacio de trabajo compartido, que es un área de trabajo manejada por los miembros del grupo desde sus estaciones, al mismo tiempo o no, dependiendo de la política de colaboración.

Otra clasificación para groupware considera el tipo de interfaz de la aplicación (DIAS, 1998), basado en cómo se da la percepción de las acciones en el área de trabajo compartida por los miembros del grupo:

• WYSIWIS (What You See Is What I See) – el espacio de trabajo compartido se presenta igual para todos los participantes.

• WYSIWID (What You See Is What I Did) – ocurre un retraso en la propagación de las acciones de un usuario para los demás, causando un retraso de la situación real del espacio compartido.

• WYSIAWIS (What You See Is Almost What I See) – el espacio de trabajo de cada usuario presenta pequeñas diferencias, no afectando la percepción de las acciones por los demás.

• WYGIWIG (What You Get Is What I Get) – Los usuarios comparten ventanas, pudiendo ocurrir inconsistencias, una vez que no comprometa la información recuperada por los otros usuarios.

En general, su uso debe estar más direccionado para las herramientas de trabajo en grupo que para uso individual, una vez que es una característica esencial para apoyar la comunicación dentro del grupo. Los problemas relacionados con el diseño de interfaces de usuario tradicionales siguen siendo pertinentes, una vez que la interacción humano-computadora sigue existiendo.

El trabajo en grupo apoya el trabajo en equipo a través de tres funciones esenciales para el grupo: las tres C de la Comunicación, Colaboración y Coordinación (CHAFFEY, 1998). La Comunicación es la característica más importante porque permite el intercambio y la transmisión de información dentro del grupo a través del correo electrónico, listas de correo u otros mecanismos. La Colaboración permite la realización conjunta de tareas, reducción de los problemas comunes que ocurren en las reuniones tradicionales, como la necesidad de un lugar físico y el tiempo necesario para encontrar una información importante, en el dominio de un individuo en la reunión. La Coordinación guía la labor del equipo hacia el objetivo común, mediante el seguimiento de tareas, liderazgo, motivación y resolución de conflictos.



El modelo para evaluar groupware propuesto en (ARAUJO et al., 1997) identifica cuatro aspectos para el apoyo eficaz de un proceso de colaboración: la comunicación, la coordinación, la memoria del grupo y la percepción, teniendo en cuenta que estos aspectos están interrelacionados y no deben considerarse por separado. A continuación, cada uno de estos aspectos.

2.2.2. Aspectos relevantes en Groupware Percepción (“Awareness”)

El concepto de percepción en los sistemas colaborativos es definido como “la comprensión de las actividades de los demás, que proporciona el contexto para sus propias actividades” (DOURISH et al., 1992). La noción de la percepción se aplica tanto a la identificación y localización de otros participantes dentro de un sistema de colaboración como las acciones que están realizando o han realizado anteriormente. Al permitir la visualización de las acciones pasadas de una manera persistente, esta característica es útil para las herramientas asíncronas.

La percepción del trabajo en grupo se puede subdividir en cuestiones básicas: como quien está trabajando, lo que está haciendo y dónde está trabajando. Obteniendo respuestas a estas preguntas, el participante está en mejores condiciones para simplificar su comunicación con los demás, organizar sus acciones y anticipar las acciones de los demás, ayudándoles. La falta de conciencia hace con que el participante esté en un estado similar al bloqueo de sus sentidos, imposibilitando que interactúe con los demás (GITWIN, et al., 1995).

La manipulación de objetos en un sistema de colaboración, especialmente en los sistemas sincrónicos en tiempo real, debe proporcionar información a las operaciones realizadas por los participantes en estos artefactos. Esta información se conoce como “feedback” cuando disponible para la persona que maneja el artefacto, y “feedthrough” cuando se informa a los que apenas están observando (GREENBERG, 2001).

Pino presenta una lista de requisitos para sistemas de memoria compartida, que ilustra las características importantes para un mecanismo de percepción: los periodos de conexión de los participantes en el sistema, una indicación de lo que ha sido leído por cada participante, indicando la informaciones y los cambios realizados, además de la notificación de los acontecimientos de acuerdo el perfil de cada participante. Mecanismos eficientes de la percepción reducen la incidencia de la incertidumbre y equivocidad en la realización de trabajos en grupo, mejorando la interacción humana mediada por la computadora (PINO et al., 2000).



Comunicación

Medios de comunicación son esenciales para un sistema de colaboración, ya que el trabajo del grupo sigue el paso de una secuencia de la conversación. En la interacción cara a cara prevalece la comunicación verbal, utilizada para describir las acciones realizadas con el fin de facilitar la comprensión de las tareas en curso. A menudo, estas conversaciones se inician a partir de una pregunta como “¿qué estás haciendo?” por un participante que intenta seguir las acciones de otro.

Sin embargo, cara a cara no es siempre posible, por ejemplo, cuando los participantes están físicamente distantes en las habitaciones o pisos diferentes de la organización, o incluso en diferentes empresas y edificios. En estas situaciones, el uso de audio (teleconferencia) puede permitir la comunicación de las personas en tiempo real. Una de las dificultades en el uso de audio es que no proporciona la percepción de las expresiones faciales y los gestos de la comunicación, realizados deliberadamente por las personas para expresar su apoyo e información a la conversación. En las llamadas de conferencia con cuatro o más personas, se hace difícil de identificar el altavoz y pasar la palabra de una persona a otra (GREENBERG, 2001).

Este problema puede ser resuelto a través de videoconferencia, lo que requiere, sin embargo, una infraestructura de telecomunicaciones razonable con suficiente ancho de banda para utilizar el vídeo con buena definición y recepción de los movimientos (número de fotogramas por segundo) (CHAFFEY, 1998).

Otra posibilidad es la interacción en el grupo de comunicación escrita a través de chat, listas de discusión, o notas. La primera ventaja de esta alternativa es la posibilidad de realizar varias conversaciones simultáneas es decir, en paralelo, mientras que en la comunicación convencional, las personas asisten a un protocolo de comunicación natural, esperando su turno para hablar. Otra ventaja en la comunicación escrita es la posibilidad de la persistencia de los mensajes o notas, lo que resulta más fácil para los desarrolladores recuperar rápidamente una secuencia de discusión que no participó.

Coordinación

La aplicación colaborativa debe apoyar la interacción en un grupo de personas que comparten algunos artefactos, y tienen objetivos comunes o complementarios en el desempeño de sus funciones. Uno de los temas del trabajo en grupo es como la gente maneja sus interacciones, negociando del uso de artefactos compartidos. Coordinación desempeña un papel esencial en la prestación de las tareas en un orden determinado en el tiempo y condiciones. Fallos de



coordinación resulta en esfuerzos duplicados y varias personas tratando de utilizar un recurso compartido al mismo tiempo.

En las sesiones de trabajo en grupo, el establecimiento de un participante como el coordinador del equipo toma a este responsable por la buena realización del trabajo y el cumplimiento de las tareas. Borges y Pino presentan algunas actividades a realizar por la coordinación del grupo para lograr sus objetivos: motivar al grupo a nuevas ideas, impulsar la moral estimulando la interacción, cobrar el comprometimiento de las tareas, identificar cuellos de botella, alinear ideas generadas con los objetivos, mantener la armonía del trabajo, requerir un nivel razonable de discusión antes de tomar una decisión y verificar la calidad del trabajo.

Algunas modalidades de groupware ayudan la coordinar del trabajo a través de la división de tareas y el seguimiento de su ejecución por parte de los miembros del grupo. Actualmente, las herramientas más conocidas y empleadas son las de flujo de trabajo. Ampliamente utilizado por las organizaciones para automatizar las tareas y actividades con el apoyo de ordenadores con el fin de optimizar sus procesos de negocio, estos sistemas se utilizan ampliamente en las zonas de misión crítica, tales como los servicios financieros. El Workflow Management Coalition (WfMC) describe el término workflow como “una facilidad computacional o automatización de un proceso de negocio en su totalidad o en parte” y un Sistema de Gestión de Workflow como “un sistema que define, crea y administra la ejecución de flujo de trabajo mediante el uso de software, ejecutando en una máquina de workflow, que tiene la capacidad de interpretar la definición del proceso, interactuar con los participantes y, si es necesario, activar el uso de herramientas y aplicaciones de las Tecnologías de la Información” (CHAFFEY, 1998).

Productos para Calendarios, por ejemplo, permiten la creación de un calendario personal con compromisos, integrando con las agendas de otros involucrados y organizando el tiempo conveniente para la reunión. Grudin señala, sin embargo, que el uso eficiente requiere una actualización frecuente de la agenda de todos los participantes, o de lo contrario el sistema permitirá a las reuniones en momentos en que no todos llegan a estar disponibles (GRUDIN, 1994).

Colaboración

En groupware, las funcionalidades de colaboración permiten la manipulación y control de artefactos compartidos. Los participantes en una sesión de colaboración realizan operaciones en los artefactos, lo que permite a otros a observar las adiciones y los cambios realizados al instante o con cierto retraso,



según el uso ser sincrónico o asincrónico, y la estrategia utilizada para compartir información.

Algunas herramientas aplican el concepto de Token: el único participante que tenga el token puede realizar cambios en el artefacto, mientras que los otros simplemente ven. Otras herramientas permiten la modificación simultánea de un artefacto en más de un participante. En groupware sincrónicos, las situaciones de conflicto pueden surgir durante una reunión asistida por ordenador, cuando dos partes tratan de manipular el mismo dispositivo al mismo tiempo. Aplicaciones de colaboración síncrona debe prever la ocurrencia de conflictos y garantizar la coherencia de los datos compartidos, pero las estrategias adoptadas deben considerar el conflicto como una oportunidad para la interacción, evitando el bloqueo del artefacto (PINO et al., 2000).

En general, las adiciones y modificaciones de cada participante se agregan de forma aditiva, la creación de un historial de contribuciones. La eliminación de los objetos se hace lógicamente (indicando el objeto como eliminado en lugar de eliminarlo físicamente), evitando la pérdida de contexto para las contribuciones que hacen referencia a este objeto. Esta política le permite construir una memoria de grupo, con la capacidad de seguir la marcha de los trabajos a través de las versiones de los artefactos.

La indicación de cada contribución del autor permite evaluar el nivel de participación de cada individuo. Sin embargo, si se hace explícita en el grupo, el autor puede intimidar a algunos participantes en relación a la presencia de su superior, formadores de opinión o personas en el grupo. En estas situaciones, el anonimato de las contribuciones puede ser un factor estimulante de la creación de ideas.

Entre los servicios ofrecidos por las tres C, mientras que la Coordinación se ve reforzada por las herramientas de workflow, y la Comunicación está más presente en los productos multimedia, el intercambio de objetos proporcionados por la Cooperación ha recibido menos atención (BENDOUKHA, 2001).

2.2.3. Memoria de Trabajo en Grupo Por memoria de trabajo, podemos entender todos los documentos y

registros preparados o referenciados durante el proceso de desarrollo de una actividad o proyecto. La memoria producida por los equipos de trabajo es objeto de estudio en el área de la memoria organizacional, cuyos conceptos se describen a continuación.



El conocimiento formal se expresa en los libros, manuales, instrucciones y documentos producidos a diario en las empresas. Están representados por objetos comunes, tangibles, tales como informes, planos, especificaciones, hojas de cálculo, notas, diagramas, etc. Las organizaciones generan decenas de documentos diariamente, reconociendo por error como su Memoria Organizacional.

Además de esto, hay otro tipo de conocimiento tan importante como el primero, pero básicamente existe en la mente de las personas, y difícilmente se formaliza o se documentada por ser menos notable. Esto está representado por el razonamiento desarrollado en la creación de conocimiento formal - son los temas, ideas, hechos, argumentos, puntos de vista, significados, sugerencias que apoyan los procesos de la organización. Es el Conocimiento Informal (o tácito), transitorio, rara vez capturado y mantenido.

Fig. 4. Conocimiento Formal y Conocimiento Informal.

El conocimiento tácito, por no estar explícito en los documentos formales, a menudo vuelve a los temas de discusión en las reuniones, obligando los profesionales a examinar todo el contexto y discutir de nuevo sobre temas ya discutidos y decididos antes, dando lugar a la reanudación y baja productividad.

Ninguna de las herramientas utilizadas para registrar el conocimiento considera el pensamiento y el aprendizaje detrás del producto formal. Los editores de texto, por ejemplo, la herramienta más utilizada en el registro de los conocimientos formales, no tienen recursos eficientes para capturar el conocimiento informal, expresado en las notas e ideas generadas durante la revisión de los documentos - manuscritas en los márgenes de los documentos revisados y perdidos cuando se actualiza la copia. Difícilmente estas notas - estas ideas - se mantienen en el documento final.



Los esfuerzos en el área de la Memoria Organizacional tratan de aprovechar la tecnología para capturar y hacer útil el conocimiento informal en las organizaciones.

El termino Memoria Organizacional no es definido de manera clara y única (ACKERMAN et al., 1999). Mientras que algunos lo describen de manera explícita en términos de conocimientos recogidos y almacenados en una perspectiva de gestión del conocimiento, otros aplican un enfoque más general, refiriéndose a la colección completa de organización de la información.

Destacamos a continuación algunos términos utilizados por autores en el área:

“La Memoria Organizacional se refiere a las informaciones almacenadas en la historia de una organización que se puede utilizar para apoyar las decisiones” (WALSH et al., 1991).

“La Memoria Organizacional es vista como el registro de una organización que se materializa en un conjunto de documentos y artefactos. Ella se dedica a extender y ampliar el conocimiento a través de su captura, organización, difusión, intercambio y reutilización de los empleados” (CONKLIN, 1996).

“Memoria Organizacional puede ser definida como el camino que una organización aplica el conocimiento pasado para las actividades presentes” (MORRISON et al., 2001).

“Memoria Organizacional es un término general usado para describir la adquisición, absorción, mantenimiento y búsqueda del conocimiento dentro de una organización” (CORBETT, 2000).

Un sistema de memoria organizacional debe proveer los mecanismos para implementar un ciclo continuo de elaboración del conocimiento, según lo propuesto por Allweyer (ALLWEYER, 2000) para describir las etapas de captura, almacenamiento, difusión, reutilización y eliminación de los conocimientos generados dentro de la organización. El modelo propuesto por el autor presenta las herramientas que apoyarán la transformación de los conocimientos dentro de la organización.

Son notorias las dificultades de las organizaciones en realizar de manera efectiva el tratamiento de su conocimiento. Es común que las empresas “olviden” lo que hicieron en el pasado y porque se hizo, lo que demuestra su incapacidad de aprender con la experiencia previa (CONKLIN, 1996).



Los equipos de trabajo evitarían el esfuerzo de retrabajo y repetición si estos volviesen explicito su conocimiento, durante los procesos de solución de problemas. Las reuniones serían más eficientes. Algunos autores se centran en el tratamiento de los conocimientos de la organización específicamente en las actividades realizadas conjuntamente por los individuos, teniendo en cuenta que el trabajo realizado en una reunión no es sólo en la retórica y la argumentación, pero el trabajo en equipo de un artefacto (MATSON, 1996).

Este enfoque condujo al desarrollo de investigaciones y de herramientas específicas para el área de meetingware, buscando apoyo tecnológico para las interacciones entre los participantes en una reunión de trabajo. Esto destaca más una vez la importancia del factor cultural y humano.

2.2.4. Evolución del Trabajo en Grupo Supongamos un sistema colaborativo con recursos para versiones. Este

sistema crea una memoria de grupo, en que cada manipulación de objetos compartidos se representa como una contribución, añadiendo a todas las contribuciones agregadas por los miembros del grupo. Esta estrategia produce un historial de acciones realizadas dentro de una o varias sesiones de trabajo, representando versiones de objetos creados y modificados. Posteriormente, un miembro del grupo podría localizar a este conjunto de versiones y examinar detalladamente cómo se llevó a cabo la evolución de los trabajos.

A pesar de que un recurso de versión como este pueda ser visto como una forma de representar el razonamiento subyacente, esto no es suficiente. También es necesario almacenar también el razonamiento asociado con cada versión (conocimiento informal), de modo a facilitar más la comprensión de cómo ha evolucionado el trabajo en equipo.

2.3. Medicalware Informática Biomédica se refiere a los recursos, dispositivos y métodos

necesarios para optimizar la adquisición, almacenamiento, recuperación y uso de información en la asistencia sanitaria. CSCW como una disciplina de investigación se formó exactamente como una reacción a la falta de atención a la colaboración y la coordinación en la investigación. Y por lo tanto, desde una perspectiva de CSCW, los sistemas de Informática Biomédica a menudo consideran poco la naturaleza colaborativa del trabajo médico.

Por ejemplo, uno de los principales retos en Informática Biomédica ha sido la transformación de los registros médicos basados en papel a los electrónicos. Historia Clínica Electrónica (HCE) se define como una colección longitudinal de



información de salud electrónica de los pacientes individuales o poblaciones. Sin embargo, desde una perspectiva de CSCW la historia clínica es una herramienta de gran colaboración que media la colaboración entre los clínicos diferentes, los roles, los lugares, los cambios de tiempo de especialidades, etc. Visto desde esta perspectiva, el registro no es más que un "registro" de los datos médicos, pero es un mediador en lugar sofisticado en un entorno de trabajo complejo. Por otra parte, la historia clínica está profundamente entrelazada con una compleja red de otros objetos dentro de un hospital.

El principal argumento es que si los sistemas de salud no están diseñados con este punto de vista de colaboración, existe el peligro de que los sistemas como el HCE sólo serán buenos para el almacenamiento de datos, pero realmente no es útil para la labor de estrecha colaboración que tienen lugar todos los días dentro de los hospitales. Se incluye el suministro de la conciencia social acerca de los médicos y los pacientes, dónde están, qué están haciendo, y cuáles son sus planes, una conciencia espacial sobre lo que está pasando en lugares específicos; una conciencia temporal sobre lo que ha sucedido, lo que está sucediendo ahora, y qué va a pasar, y una toma de conciencia de la situación de la actividad de una actividad quirúrgica en particular. Estas son algunas características de los Medicalware:

• Proporcionar apoyo a la comunicación entre los clínicos, pacientes, y los lugares.

• Proporcionar información sobre la ubicación en tiempo real sobre los médicos, pacientes y equipos.

• Distribuye en todo el hospital a los departamentos, lugares y personas que están involucradas en la ejecución

El punto de este éxito es el cambio de perspectiva de manejo de la información médica para apoyar el trabajo de colaboración contingente, es decir, agregar a la Informática Biomédica una perspectiva de CSCW. Esto es un buen ejemplo de cómo los sistemas informáticos para la salud pueden ser diseñados de manera diferente, centrándose en los aspectos científicos de lo que constituye una estrecha colaboración en un lugar de trabajo.

Capítulo 3. Softwares para Construcción Colaborativa de Conocimiento Médico


Capítulo 3. SOFTWARES PARA CONSTRUCCIÓN COLABORATIVA

DE CONOCIMIENTO MÉDICO

En este capítulo se describen las características proporcionadas por la Informática Biomédica y el Trabajo en Grupo con el fin de crear aplicaciones de forma rápida, con buen rendimiento y sobre todo con aspectos de seguridad. Para cada uno de los tipos de elementos identificados están relacionados atributos y ejemplos de software en los que ya se ejecuta, aunque parcialmente.

3.1. Recursos de los softwares para construcción colaborativa de conocimiento médico

Este estudio evalúa el apoyo ofrecido por los sistemas colaborativos para la evolución del trabajo en grupo. Aunque nuestro enfoque esté dirigido a las herramientas asíncronas, nos encontramos con los recursos disponibles en los diferentes tipos de herramientas, ya que estas características proporcionan los aspectos de coordinación, comunicación, colaboración, percepción y memoria de grupo.

Uno de los softwares más populares en las oficinas, los editores de texto, permiten llevar a cabo comunicaciones de forma síncrona y asíncrona. En algunos de estos editores, como Microsoft Word, instalaciones para los documentos de coautoría permiten que las modificaciones se destaquen el uso de colores diferentes para cada individuo y representen de forma diferente dependiendo del tipo de revisión. Por ejemplo, el texto eliminado se muestra como tachado, mientras que el texto nuevo está subrayado incluido. Las notas pueden ser incluidas



en una palabra, línea o párrafo completo, lo que indica también el autor de la nota. Como los cambios se realizan sólo por un usuario a la vez, es necesario controlar un proceso para obtener el documento, la revisión y presentación de copia revisada.

En las herramientas síncronas para la escritura colaborativa, una característica de adaptación de los editores de texto individuales indica que los demás participantes se colocan en el texto editado en conjunto: las barras de desplazamiento de varios usuarios. En lugar de la tradicional barra de desplazamiento, varias barras con diferentes colores indican la posición de cada usuario trabajar simultáneamente en el mismo texto, como en la Figura 3.1.

Fig. 5. Barras de desplazamiento multiusuario.

Fuente: (ROSEMAN, 1996)

Otra característica que le permite localizar a cada participante en el texto es el Word Viewer o Fish-Eye (Visor de Texto Ojo de Pez), desarrollado en la investigación de GroupLab (COCKBURN et al., 1996). En esta característica se presenta el texto completo en la ventana de edición, en muy pequeña escala, expandiendo sólo las partes en que cada participante esté trabajando. Destaca las partes del texto con el color seleccionado para cada participante, como el ejemplo de la Figura 4.



Fig. 6. Visualizador de Textos con Ojo-de-Pez. Fuente: GroupLab – Univ Calgary (Canadá) (COCKBURN et al., 1996)

Pino propone un recurso para la coautoría y edición, los “Stick-Ons”, basado en la metáfora de una cinta adhesiva (PINO et al., 2001). Para volver a colocar un trozo de texto, un revisor agrega un nuevo stick-on sobre él y escribe un nuevo texto. Posteriormente, si el lector desea revisar las palabras del texto original, se podrá retirar el adhesivo, volviendo a ver el contenido subyacente. De este modo, el texto original aparece con un signo de la sombra, como los restos de pegatina se mantuviesen en él después de quitar la cinta - de nuevo referencia a la metáfora. Así, los stick-on son un recurso muy útil para las versiones en editores de texto.



Fig. 7. Stick-Ons. Fuente: (PINO, et al., 2001)

La ventana en la Figura 7 muestra un texto a ser revisado por un grupo de personas. Varias partes del texto marcado con fondo en tonos representan diferentes partes sustituidas por los revisores, poniendo el texto original con stick-on y escribiendo un nuevo texto sobre el área marcada.

Algunos editores gráficos aplican el concepto de un espacio de trabajo compartido por el cual los empleados que manejan el mismo diagrama desde sus estaciones, y los cambios realizados por cada uno se reflejan a los otros. Además, varias alternativas se pueden utilizar en la aplicación de una herramienta como el tipo de interfaz que se utiliza (WYSIWIS, por ejemplo), la estrategia para la replicación de las colaboraciones, características de la percepción (“awareness”), manejo de conflictos (acceso simultáneo el mismo objeto), entre otros.

Otra característica de la percepción desarrollado en GroupLab, el Visualizador Gráfico con Ojo de Pez (“Graphical Fisheye View”), utiliza el mismo concepto del Editor de Texto con Ojo de Pez, ampliando la zona del diagrama en el que cada usuario se centra con un efecto similar al de una lupa para representar los detalles de los objetos en esta área, al igual que en los próximos cuadrados para el puntero del ratón en la Figura 8.



Fig. 8. Visualizador Gráfico con Ojo-de-Pez. Fuente: GroupLab – Univ Calgary (Canadá) (COCKBURN et al., 1996)

Telepointers son una facilidad importante para percepción en los softwares de groupware: la posición del puntero del ratón se dibuja para cada usuario en un espacio compartido con su nombre o con un color diferente para cada persona. El telepointer se mueve como el usuario mueve el ratón. Un telepointer le permite ver los movimientos del ratón de un participante, proporcionando una sugerencia de donde se busca o se trabaja, aunque esto no sea garantizado de manera efectiva (COCKBURN et al., 1996).

La visión de Radar (“Radar Overview”) presenta una visión reducida de un diagrama completo en una esquina de la pantalla. En este punto de vista, el área visible del diagrama para cada usuario está limitada por un rectángulo etiquetado con su foto. Así, cada participante ve donde otros están trabajando en el alineamiento de sus visiones (GUTWIN, 1999). Se utiliza Telepointers también para indicar la posición del escritorio de cada participante. La visión de radar también fue elaborada en las investigaciones de GroupLab.



Fig. 9. Visión de Radar. Fuente: GroupLab – Univ Calgary (Canadá)

La mayoría de los editores utilizan un recurso creado originalmente en herramientas de comunicación: una lista de usuarios que participan en una sesión de trabajo. Algunas listas también indican el estado de cada participante, para informarles sobre su disponibilidad.

Recursos de percepción en las herramientas de groupware permiten la colaboración entre los participantes en tiempo real, cambiando el estado de los objetos compartidos. Greenberg propone que el área de trabajo debe reflejar las acciones del usuario del sitio remoto, proporcionando “feedthrough” de su acción. Al realizar el movimiento de un objeto en el espacio de trabajo, los demás usuarios deben comprender no sólo la posición final del objeto, sino también su selección y los pasos intermedios de circulación (GREENBERG et al., 2000). Sin embargo, la manipulación simultánea de los objetos compartidos puede conducir a un conflicto. Se discuten en mayor detalle el tratamiento de los conflictos en la sección que se ocupa de los problemas de los editores de colaboración.

En algunas herramientas de colaboración asíncrona, otras características de la percepción se pueden aplicar como una indicación de la contribución de un autor, como por ejemplo sus acciones y la memoria histórica de la construcción de un artefacto. Sin embargo, cuando se le informa de la labor de sus miembros, algunas situaciones deben ser consideradas como la percepción selectiva, que se basa en



recibir solo la información de interés. Con el fin de permitir el uso asíncrono, estos softwares deben realizar algún tipo de artefacto persistente.

El principal objetivo de algunos groupwares es colectar conocimiento informal, lo que permite almacenar las preguntas, ideas y argumentos en un debate (el razonamiento) en porciones de texto organizados cronológicamente o por tema. Algunos le permiten hacer esta representación en forma gráfica, como QuestMap basado en el modelo Issue Based Information System, desarrollado por Kunz y Rittel en 1970. Este modelo, también conocido como modelo de conversación, la estructura de memoria está de acuerdo a su contenido, independientemente de la cronología. Es un método que proporciona un marco para la discusión de problemas complejos, la organización de los diálogos de planificación, los aspectos que ofrecen posibles soluciones y argumentos para apoyarlas o rechazarlas (CONKLIN, 1996).

Otros hacen uso de anotaciones y comentarios como un recurso adicional a la funcionalidad básica: procesadores de texto y editores de gráficos permiten a los usuarios escribir notas y comentarios relacionados con fragmentos de texto o símbolos de diagramas, enriqueciendo los artefactos a su contexto. Algunas herramientas incorporan facilidades para el intercambio de mensajes entre los participantes de la reunión, como un chat, lo que le permite seguir la evolución del trabajo en grupo de una manera natural, aunque la secuencia de mensajes no indica necesariamente que las medidas adoptadas y los objetos afectados por estas acciones.

3.2. Proyecto e Implementación El desarrollo de los entornos de colaboración, así como otros tipos de

software, frecuentemente aprovechan las soluciones disponibles previamente construidas con el fin de obtener una buena productividad y la evolución adecuada del producto. Productos de software de entorno genérico, tales como librerías de componentes, toolkits, frameworks y patrones de diseño son reutilizados a través de sus interfaces de programación de aplicaciones (API), reduciendo el esfuerzo de desarrollo.

Según la definición de Gamma y otros investigadores, un toolkit es un conjunto de clases relacionadas entre sí, reutilizables, diseñadas para proporcionar la funcionalidad de propósito general. Un framework, a su vez, es un conjunto de clases que cooperan y componen un diseño reutilizable para una clase específica de software. Mediante el uso de un toolkit, es posible desarrollar la parte principal de la aplicación, llamando subrutinas del código que desea volver a utilizar. Por el contrario, cuando se utiliza un framework, la parte principal de la aplicación está disponible para su reutilización, y las llamadas a subrutinas se va a desarrollar (GAMMA et al., 1995).



GroupKit

El GroupKit es un toolkit desarrollado por GroupLab en la Universidad de Calgary, Canadá, centrado en el desarrollo de aplicaciones para la conferencia distribuida de forma síncrona, tales como herramientas básicas de dibujo y herramientas para reuniones. Fue creado con la intención de servir en prototipos de trabajo en grupo, a experimentar con arquitecturas, interfaces multiusuario y como herramienta de enseñanza en CSCW.

Tiene una infraestructura que gestiona la ejecución de las operaciones principales de la creación, la interconexión y los procesos de comunicación distribuida en las conferencias. Utiliza un conjunto de abstracciones de programación de trabajo en grupo para controlar estos procesos, verifica el cambio de estados de los objetos y comparte datos. La interfaz se realiza utilizando componentes (widgets de trabajo en grupo). También permite el uso de gestores de sesión para el control de las sesiones (ROSEMAN et al., 1996).

JSDT

El Java Shared Data Toolkit es un toolkit desarrollado por Sun Microsystems, Inc. destinado a apoyar las aplicaciones de colaboración, escrito en el lenguaje de programación Java (ORACLE, 2011). Su mecanismo de comunicación permite el intercambio de datos entre los participantes de una sesión, utilizando diversos métodos de envío de múltiples puntos.

El protocolo de comunicación en la que las funcionalidades del toolkit fueron implementadas y la negociación para seleccionar uno de estos protocolos son completamente transparentes para el desarrollador. A través de la API, varias clases de objeto de dominio de un sistema de colaboración pueden ser fácilmente instanciadas: sesión, cliente, canal (para envío de mensajes), Token, Gerente, Evento y las operaciones de conexión y desconexión de una sesión, el envío de datos, recepción de datos, entre otros (ORACLE, 2011).

Permite el desarrollo de sistemas de colaboración de varios tipos, tales como conferencia, presentaciones distribuidas, recursos de percepción, salas virtuales, workflows, entre otros.

MUG

El toolkit MUG (Multi User GUI) consiste en una serie de componentes de interfaz de usuario con características de percepción, basada en el lenguaje Java. Contiene extensiones de componentes estándar de Swing, por lo general no



utilizadas por otros conjuntos de herramientas, así como los componentes específicos de groupware como Telepointers y Lista de Usuarios, con funciones de colección, distribución y visualización de la información en la percepción del trabajo en equipo.

Además, proporciona el “feedthrough” de eventos con los demás participantes, como por ejemplo enfoque en uno de los componentes, pulsar un botón y la navegación por los menús. Permite la personalización sobre este mecanismo de percepción, inhabilitando algunos eventos para evitar la sobrecarga de información y la injerencia en las acciones locales (GUTWIN, 1999). Fue construido en el HCI Lab, en la Universidad de Saskatchewan, Canadá.

COPSE

El framework COPSE (Collaborative Project Support Environment) fue diseñado como una infraestructura para el desarrollo de aplicaciones de colaboración, tratando de proporcionar apoyo a la coordinación de las actividades a nivel de proyecto y actividad. Permite la realización de las interacciones síncrona y asíncrona, ofreciendo apoyo a aspectos de colaboración que requieren las aplicaciones de trabajo en grupo - la comunicación, la coordinación, la percepción y la memoria de grupo (ARAUJO et al., 1997).

Los servicios están disponibles a través de los paquetes de “Document” para la gestión de documentos y datos, “Product” para la gestión de configuración, “Agent” para la gestión de personas y equipos participantes, “Tool” para el registro de herramientas y “Process” para la gestión proceso de trabajo. El framework se llevó a cabo en la arquitectura cliente/servidor, donde un proyecto de servidor principal de proyectos (“COPSE Project Server”) gestiona los servidores restantes - proceso, producto, agentes y herramientas. Por el lado del cliente, un administrador de sesión permite al usuario conectarse a Project Server y otros servidores, proporcionando información sobre el estado del proyecto, la gestión de información personal, activación de herramientas, entre otros (DIAS, 1999).

Como parte de la validación del framework, se construyeron algunas herramientas de colaboración: editor de diagramas de clases (CUTE - Cooperative UML Technique Editor), una herramienta para la definición de procesos (COPE – Cooperative Process Editor) y una herramienta para recopilación de conocimientos con casos de uso.



Flexible JAMM

Flexible JAMM (Java Applets Made Multiuser) es un sistema de uso compartido de aplicaciones, lo que permite el trabajo simultáneo de varios usuarios en una herramienta de uso individual. Utiliza una implementación basada en la arquitectura orientada a objetos, sustituyendo dinámicamente componentes de interfaces de usuario individuales por extensiones multi-usuario. Por lo tanto, permite a varias estaciones de trabajo editar al mismo tiempo un campo de entrada de texto (BEGOLE, 1997).

Flexible JAMM es una alternativa a otras herramientas que realizan el intercambio de aplicaciones de usuario único a través de la colaboración transparente, utilizando el concepto de token - sólo un usuario a la vez puede hacer cambios en los datos.

En la Tabla 1, hay una lista de las principales ventajas y desventajas de cada una de estas herramientas, utilizada como base conceptual para la construcción de Sanar. Una descripción más detallada de los requisitos de la solución desarrollada, su arquitectura y su aplicación se lleva a cabo en los capítulos 4 y 5 de esta tesis.



Producto Ventajas Desventajas

GroupKit (toolkit) Facilidad de uso (implementación) Poca flexibilidad para personalizaciones, debido a la

disponibilidad solamente de recursos básicos de groupware

JSDT (toolkit) Facilidad para transformar una aplicación Java individual en

multiusuario, reutilizando funcionalidades de groupware Lenguaje de programación Java

Las funcionalidades principales de la aplicación (la estructura central) necesitan ser desarrolladas – aspecto común a todos los toolkits presentados.

MUG (toolkit)

Presenta una extensa librería de componentes gráficos para groupware, extendiendo algunas funcionalidades de la librería Swing de Java y creando componentes específicos de groupware Lenguaje de programación Java

No disponible completamente, aunque en fase de desarrollo

COPSE (framework)

Presenta una infra-estructura para construcción de una aplicación cooperativa Algunas funcionalidades genéricas para groupware, como

listas de usuarios, gestores de documentos, de configuración, de procesos y de equipos

Basado en la librería JDK versión 1.1.8, relativamente obsoleta, exigiendo esfuerzo considerable para migrar el framework para una versión más recién.

Flexible JAMM (sistema para compartir aplicaciones)

Facilidades para utilización de una aplicación individual de forma compartida No exige desarrollo adicional o personalización en la

aplicación individual

Poca flexibilidad Utiliza el concepto de token (no permite colaboración

simultanea)

Tabla 1. Productos para desarrollo de groupware.



3.3. Productos desarrollados Medcast

Creada por la Universidad de São Paulo – Brasil, Medcast (MORENO, 2010) es resultado de una evaluación de tendencias de aplicaciones para discusión de casos clínicos utilizando elementos multimedia. Después del proceso de análisis, se ha optado por el desarrollo de la aplicación con la tecnología Flex, que tiene código abierto y es basado en la plataforma Flash. La arquitectura de información tiene un servidor de aplicaciones y un sistema de información hospitalaria, de donde vienen las informaciones.

Fig. 10. Conferencia con Medcast. Fuente: (MORENO, 2010)

Cada cliente representa un usuario del sistema, con los papeles a continuación:

• Moderador: médico responsable por crear y organizar el contenido, moderar y controlar la reunión;

• Participante: médicos y/o estudiantes de Medicina que participan de la reunión e interactúan entre ellos y con el moderador.



Es responsabilidad del moderador garantizar que los participantes sean personas debidamente autorizadas, para no comprometer la seguridad de los datos.

Tal y como ha sido comentado, los archivos para discusión son obtenidos a través del Sistema de Información del Hospital con la asistencia de un broker, cuya finalidad es garantizar la seguridad de la información y convertir en un formato compatible para el entorno web.

De acuerdo con los investigadores, aún no se está ocultando totalmente los datos del paciente. Para eso, será aplicado un algoritmo para extraer textos de imágenes, a fin de garantizar más confidencialidad.

diSNei

El Desarrollo Integrado de Segmentador y Navegador de Estructuras Internas (RODRIGUEZ et al. 2000) es un trabajo de las universidades de Las Palmas de Gran Canaria y Valladolid. El objetivo es ofrecer una aplicación que analiza imágenes, sobre todo médicas, permitiendo segmentar los modelos y navegar entre ellos.

Para la construcción de diSNei se ha pensado en un proyecto multiplataforma de manera modular, lo que permite la inclusión de nuevas funcionalidades sin necesidad de manejar el código existente. Para esto, se ha utilizado librerías en C++ contenidas en el paquete VTk (Visualization Toolkit) y del lenguaje interpretado Tcl/Tk, ambos de libre distribución. Además de eso, VTk es de código abierto y permite agregar otras funcionalidades.

A continuación un pantallazo de diSNei:



Fig. 11. Datos ecográficos de un feto en diSNei. Fuente: (RODRIGUEZ et al., 2000)

diSNei dispone también de la funcionalidad de colaboración, de manera síncrona. Con esto, se puede visualizar las mismas estructuras y gestionar la segmentación, proporcionando además tener un chat para comunicación. Esto facilita el trabajo entre especialistas, una vez que les permite diagnóstico de una patología, así como la planificación de una intervención quirúrgica.

Family Doctor

El objetivo de Family Doctor (FAMILYDOCTOR, 2011) es ofrecer una aplicación que analiza imágenes, sobre todo médicas, permitiendo segmentar los modelos y navegar entre ellos.

A continuación un pantallazo de Family Doctor:



Fig. 12. Página inicial de FamilyDoctor.

La aplicación cuenta con un motor de búsqueda a través del cual se puede seleccionar varios síntomas básicos. A continuación, el usuario accede a una especie de flujo con otros síntomas, con el fin de llegar a un diagnóstico.

3.4. Comparativo entre herramientas desarrolladas La información presentada en este capítulo permite una mejor comprensión

del estado de la técnica en el área de aplicaciones para la construcción del conocimiento médico. Debajo de la tabla 2, comparando las tres tecnologías presentadas.



Tabla Comparativa

Medcast diSNei familydoctor.org

Concepto Discusión médica con interacción multimedia

Discusión de casos con segmentación de

imágenes

Discusión abierta de síntomas con base en puntos de vista del

grupo

Finalidad

Uso de recursos de audio y video para facilitar la

discusión de casos médicos en sección

privada

Uso de recursos para segmentar imágenes por área y color a fin

de facilitar diagnostico

Ofrecer diagnosis rápidos, basados sobre todo en

experiencias prácticas de usuarios no profesionales de

salud

Universidad proveniente USP ULPGC -

Entorno Desktop Desktop Web

Aspectos médicos Si Si Si

Aspectos de colaboración Si Si Si

Aspectos educacionales No No No

Aspectos de la Web 2.0 No No Si

Tabla 2. Herramientas médicas.

Tres soluciones se presentan, ordenadas por relevancia. La primera herramienta es un software de escritorio desarrollado en Adobe Flash que facilita la construcción de conocimiento médico en una sección privada utilizando recursos multimedia de videoconferencia, como por ejemplo soporte a audio y webcam. El segundo caso ofrece una interacción que se asemeja al primer caso, pero el enfoque está en la posibilidad de manejar la imagen, aplicando algoritmos de procesamiento de imágenes que segmentan por color. La tercera aplicación es resultado de la característica orgánica de internet. Una vez que los usuarios comunes sintieron la necesidad de compartir sus experiencias en la aplicación de la medicina para determinados casos, se creó el familydoctor.org.



Capítulo 4. SOLUCIÓN PARA CONSTRUCCIÓN DE

CONOCIMIENTO COLABORATIVO CON ARTEFACTOS MÉDICOS –

SANAR

Este capítulo presenta algunos aspectos fundamentales para entender el propósito de Sanar. Cada sección presenta características importantes para comprender el programa propuesto, utilizado en casos reales y posiblemente también en el ámbito educativo.

4.1. Aspectos generales de la solución La solución implementada permite la construcción de conocimientos para la

detección de diagnósticos de casos médicos, con comentarios de los usuarios con un perfil de los profesionales sanitarios como médicos, enfermeras, fisioterapeutas, dentistas, farmacéuticos, investigadores académicos, entre otros.

Para utilizar la herramienta, el usuario debe tener acceso al sitio y seguir las instrucciones necesarias. En general, la primera interacción se produce a través de la apertura de la página principal de la aplicación. Por ahora, se puede consultar la información con un alto potencial de relevancia, tales como nuevos casos de comentar, que más se habla de los casos, las especialidades médicas consideran las tendencias, ranking con información sobre los líderes de opinión en sus respectivos

Capítulo 4. Solución para Construcción de Conocimiento Colaborativo con Artefactos Médicos – Sanar


campos, entre otros. Además de estas opciones, vistas de manera anónima, es posible registrarse para empezar a colaborar.

Las características presentes en la herramienta se describen a continuación, de acuerdo con la Informática Biomédica, el Trabajo en Grupo y la Web 2.0.

4.1.1. Aspectos de la Informática Biomédica Como se ha explicado en capítulos anteriores, el objetivo principal de Sanar

es apoyar los debates para la creación de diagnóstico médico. A pesar de que la Informática Biomédica tiene varios hilos, la historia clínica es un ejemplo de asunto abordado directamente en la aplicación.

Para garantizar la seguridad en la manipulación de imágenes médicas, Sanar también contempla el uso de protocolos y procedimientos de seguridad. Independientemente de la tecnología utilizada, esta es una premisa para el funcionamiento del proyecto.

Otro factor importante es el uso de las clasificaciones especiales para clasificar y organizar toda la información incorporada en Sanar. A través de una investigación de las principales áreas de la medicina, la lista se construyó teniendo en cuenta los más relevantes y orientadas principalmente a los efectos de la aplicación.

4.1.2. Aspectos de Trabajo en Grupo El objetivo de un trabajo en grupo es, según Dias (1998), promover el

potencial de crecimiento del grupo a través de contribuciones individuales. La estrategia es permitir que el grupo para desarrollar el espíritu de equipo, de modo que los miembros se complementan entre sí, compartiendo sus conocimientos y habilidades en la búsqueda de un objetivo común, logrando así el aprendizaje a través de la cooperación.

Acerca de Grupo de Trabajo, esta solución promueve la construcción de conocimiento a través de contribuciones individuales. También permite estudiar cómo los diferentes mecanismos de interacción puede ayudar o no en una interacción con profesionales de la salud en un contexto global.



4.1.3. Aspectos de la Web 2.0 El primer aspecto no se detecta al principio, pero que es esencial para la

construcción de Sanar es la capacidad de acceder a la aplicación a través del navegador, ofreciendo un entorno Web.

Debido al hecho de que Sanar es como una especie de red social donde los usuarios interactúan con múltiples tipos de media, es posible detectar sus características de aplicaciones de la Web 2.0. Los objetivos se centran más en cuestiones de salud y en especial el estudio del comportamiento del usuario a través de discusiones en grupo, sin embargo, continúa los factores antes mencionados.

4.2. Características de la solución Se presentan en esta sección las características de las interfaces gráficas y las

instalaciones basadas en los componentes gráficos, elementos de software de colaboración y aplicación de conceptos en el ámbito de la Informática Biomédica.

4.2.1. Interfaz del usuario A través de un estudio comparativo de varios diseños, hemos tratado de

crear una interfaz gráfica atractiva e innovadora, que incentiva a su uso, similar a las últimas herramientas de gráficos. El encabezado de la pantalla principal de la aplicación, que se ilustra en la Figura 4, muestra el nombre de la herramienta y su logotipo. Está disponible también la funcionalidad para conexión con el usuario, debiendo introducir los datos de e-mail y contraseña para acceder a la cuenta.



Fig. 13. Pantalla inicial de Sanar.

En el menú central, están disponibles algunos ejemplos de contenido de alta relevancia, cuya descripción es la siguiente:

Cases not solved: los casos que aún no tuvieron respuesta en cuanto a su posible diagnóstico. A menudo se producen en los casos más complejos o con poca información proporcionada.

New cases: los casos con la fecha de la última creación.

Most commented cases: los casos que tuvieron mayor impacto, resultando en un mayor número de comentarios de los usuarios.

Trending subjects: los temas más discutidos en la aplicación de la medida correctiva, resultante de la suma de opiniones de los casos, agrupados por especialidad.

Opinion leaders: los usuarios que más opinaron, con independencia del área en que opera.



Fig. 14. Nuevo caso en Sanar.

Después de entrar en Sanar como usuario y acceder a la acción para crear los nuevos casos con el botón Create new case, son necesarias las informaciones a continuación:

Especialidad: todo caso necesita una especialidad, cuyo propósito es catalogar y distribuir el contenido dinámico en la pantalla principal y en los informes utilizados por la administración del proyecto.

Descripción: texto sobre el caso publicado. Hay que ser claro y objetivo, teniendo en cuenta que los usuarios tienen poco tiempo para leer, analizar y opinar.

Fotos y textos: material visual para apoyar un argumento basado en la descripción.

Una vez creado el caso médico, los usuarios expresan su opinión al respecto, como se muestra en la Figura 15.



Fig. 15. Simulación en Sanar.

Al seleccionar un caso en la página web o en una de las pestañas bajo la cabecera, el usuario tiene la posibilidad de escribir una revisión, similar a un comentario a un post de blog.

Si el usuario desea realizar cambios en tu perfil o completarlo con información no divulgada en el registro inicial, existe la opción configuraciones de perfil, como se muestra en la Figura 7.



Fig. 16. Configuración de Perfil.

Además de lo que ha sido rellenado en la inscripción inicial, es necesario agregar las informaciones complementares del perfil, resultando en más credibilidad en las opiniones sostenidas.

4.2.2. Facilidades de soporte a la Informática Biomédica Imágenes médicas - con el fin de fortalecer los argumentos y facilitar la

comprensión por el usuario, es posible agregar imágenes a los casos médicos. Una vez que el usuario lo hace, miniaturas están disponibles para el acceso posterior. Al hacer clic, la imagen se expande a su tamaño original.

4.2.3. Facilidades de apoyo al Trabajo en Grupo Comentarios - En este punto, la facilidad más visible son los comentarios. Un

grupo puede interactuar en un caso como en un foro. A pesar de ser una estructura simple se puede identificar para determinar el curso de una discusión, el perfil de usuario, entre otra información pertinente. Entre las implementaciones futuras de Sanar, se planean otros recursos para apoyar el trabajo en grupo, como la clasificación de casos y opinión de otros usuarios, en una escala de 1 a 5.



Capítulo 5. ARQUITECTURA DE LA HERRAMIENTA SANAR

Este capítulo describe los aspectos de diseño e implementación de Sanar. En primer lugar, se presenta un panorama general de la arquitectura y cuestiones de la tecnología de software utilizada en su construcción, instalación y uso. En seguida, se describe la herramienta en una visión lógica y funcional, que detalla los componentes y cómo se cumplen los requisitos descritos en el capítulo anterior.

5.1. Visión general de la arquitectura Sanar fue diseñado para apoyar la construcción del conocimiento médico

entre los profesionales de la salud en un contexto global. Cada miembro del grupo accede al software a través del navegador y realiza operaciones de creación y comentarios sobre los casos. La idea principal es el apoyo de la herramienta que todo profesional tiene una experiencia única acerca da la historia clínica, resultando en opiniones más fundamentadas y diagnósticos más fiables. Figura 17 ilustra el procedimiento que se realiza durante su utilización.

Fig. 17. Procedimiento de uso de Sanar.

Entrada inicial de datos y Diagnóstico Preliminar

Procesamiento de informaciones a través de

opiniones de usuarios

Discusión y diagnostico final

Capítulo 5. Arquitectura de la Herramienta Sanar


El procedimiento consta de tres partes. El médico accede a Sanar, escribe el caso médico, los síntomas detectados y añade las imágenes para facilitar la comprensión. Es conveniente dar a conocer también un diagnóstico preliminar, reforzando su punto de vista.

Entonces, toda la información escrita será catalogada y almacenada para su posterior manipulación por los usuarios.

Por último, otros usuarios publicarán sus opiniones sobre el caso. La generación de una larga discusión con el objetivo de eliminar la duda dio lugar a una visión común con respecto a la mayoría.

Sanar no requiere pre-requisitos de software. Además del navegador, el usuario puede utilizar en cualquier sistema operativo. Esto es posible debido al código de construcción para la interfaz con los estándares web, tales como extensible HyperText Markup Language - XHTML, una reformulación del lenguaje de marcado HTML basado en XML, y Cascading Style Sheets - CSS, un lenguaje de hoja de estilos para definir la presentación documentos escritos en un lenguaje de marcado como HTML o XML.

5.2. Arquitectura Tecnológica En esta sección se presentarán a las tecnologías de evaluación para la

construcción del Sanar, incluyendo el lenguaje de programación utilizado, las bibliotecas, los framework, las herramientas de gestión de contenidos, y la infraestructura utilizada para su aplicación en un entorno web.

5.2.1. Lenguaje Java Comenzando con el desarrollo de la herramienta Sanar, la primera cuestión

a resolver fue la elección de la plataforma tecnológica a utilizar. Más concretamente, en relación a la elección del lenguaje de programación. Se identificó que el lenguaje Java cumple los requisitos necesarios.

Este es un lenguaje de programación no interpretado, libre y usado para el desarrollo de aplicaciones Web.

A continuación se presentan algunas características clave necesarias para la aplicación Sanar, que fueron suministrados por el lenguaje elegido.

Orientada a objetos - apoya paradigma orientado a objetos, lo que permite la aplicación de conceptos importantes para el proyecto, tales como la encapsulación, la reutilización de código, herencia y polimorfismo.



Curva de aprendizaje - Java es un lenguaje de programación robusto y que automatiza algunas tareas, tales como punteros y la memoria de recolección de basura. Debido a estas características, la curva de aprendizaje para los desarrolladores es corta, lo que permite un rápido aumento de competencia si la persona tiene cierta familiaridad con el lenguaje de programación C.

Funciones nativas - Java tiene una considerable cantidad de funciones integradas para crear aplicaciones de Internet. Entre estos, se pueden mencionar:

• Soporte para protocolos de comunicación IMAP, POP3, SNMP, FTP y NNTP

• Soporte para XML (SAX, DOM, XSLT)

• Soporte para objetos distribuidos CORBA

Portabilidad - Aunque en general se utiliza junto con el Linux y FreeBSD, el lenguaje Java también se puede utilizar con Microsoft Windows y con los servidores web Apache o Microsoft IIS. El pre-compilación de Java Server Pages - JSP - se logra a través del uso de un módulo acelerador.

Base de datos - Una de las características más relevantes de Java es su soporte para una amplia variedad de bases de datos, entre ellas IBM DB2, Informix, Interbase, MS-SQL, MySQL, ODBC, Oracle (OCI8 y OCI7), PostgreSQL, SQLite y Sybase.

5.2.2. Lenguaje Java Para la construcción de Sanar, se evaluaron bibliotecas y frameworks que

apoyan la inclusión de aspectos de colaboración, tal y como los mencionados en el Capítulo 3.

Aunque no existía una evaluación en este sentido, una de las decisiones más importantes que se tomaron antes del desarrollo de Sanar ha sido no utilizar bibliotecas o frameworks. En su lugar, una estructura ha sido diseñada siguiendo el patrón Model-View-Controller. Este modelo de arquitectura permite a cada parte del sistema para ejecutarse de manera desacoplada, optimizando los recursos de red y proporcionando la integración entre sus características. Así, el equilibrio de carga de red se puede hacer a un nivel óptimo.

Una razón importante para esta decisión fue la intención de ser lo menos dependiente posible de otras tecnologías. Esto es fundamental, especialmente para la posible migración y sobre todo la evolución en el software. Otro aspecto que



también se ve afectado es el mantenimiento por otros usuarios. Cuanto más puro sea el código Java, más fácil será de entender.

A continuación se presentan las clases detalladas construidas para garantizar la organización del proyecto Sanar.

5.2.3. Infraestructura La infraestructura de hardware necesaria para ejecutar Sanar se limita a la

utilización de un navegador para acceder al servidor de hospedaje. No es necesario instalar bibliotecas u otros complementos en el cliente para que se pueda ejecutar.

5.3. Arquitectura funcional En las secciones siguientes vamos a considerar la arquitectura funcional,

sub-dividida en módulos, esquemas y estándares adoptados. Al final, se presentará la visión integrada del sistema.

5.3.1. Visión general de los módulos La construcción de Sanar se llevó a cabo de forma incremental, basada en el

paradigma de orientación a objetos.

En esta sección hay una descripción general de cada módulo. A continuación, se detallan en términos de sus clases, relaciones e interacciones entre ellos, componiendo una visión detallada del sistema.

Módulo de Autenticación y Administración - Facilita, a través de las herramientas disponibles, el mantenimiento del tráfico de datos, como usuarios, casos, diagnósticos y todo tipo de media utilizada.

Módulo de Colaboración - Incluye clases que realizan las operaciones de asociación de los casos a los usuarios, comentarios y contenido multimedia.

5.3.2. Diagrama conceptual El propósito del diagrama conceptual es presentar una idea básica sobre el

negocio del sistema que se está desarrollando. La figura 8 muestra el diagrama de clase conceptual de Sanar, que tiene características de desacoplamiento, contribuyendo a la escalabilidad del software.



Fig. 18. Diagrama Conceptual de Clases de Sanar.

Para facilitar la comprensión del diagrama presentado anteriormente, a continuación está el diccionario de datos, más bien una colección de metadatos que contiene las definiciones y las representaciones de elementos de datos.



Diccionario de datos – Diagrama Conceptual

Clase Atributo Significado

User

about Texto corto sobre el perfil de usuario, incluyendo la formación, experiencia, preferencias sobre la práctica de la profesión, etc.

firstName Nombre.

institution Institución, pública o privada, a la que pertenece. Puede ser un hospital, clínica o una universidad.

lastName Apellido.

location Ciudad, provincia y país.

occupation Profesión. Puede ser un médico, farmacéutico, enfermero, profesor investigador, entre otras opciones.

password Contraseña del usuario.

sex Sexo.

Case description Texto breve sobre el caso a publicar.

speciality Especialidad del caso, como por ejemplo neurología, pediatría, oncología, etc.

Diagnosis description Opinión acerca del caso. La unión de diversas opiniones llevará a un posible diagnóstico sobre el caso.

Media filePath Camino en el servidor para la media subida.

subtitle Subtitulo descriptivo para la media subida.

Contact

email E-mail del usuario que contactó

message Mensaje que justifica el contacto

subject Tema a ser discutido

userName Nombre de usuario

Tabla 3. Diccionario de Datos Diagrama Conceptual - Sanar.

Cabe señalar que las clases presentadas anteriormente se relacionan con el diagrama de clases conceptuales, con exclusión de toda estructura diseñada para ajustar Sanar al patrón MVC.



5.3.3. Diagrama Entidad Relación El Diagrama Entidad Relación se destina a describir el modelo de datos de un

sistema con un alto nivel de abstracción. La figura 9 muestra el diagrama de Sanar.

Fig. 19. Diagrama Conceptual de Entidad Relación de Sanar.

Al igual que en el caso del diagrama de clases conceptual, el DER también tiene su diccionario de datos, como puede verse en la tabla 4.



Diccionario de datos – Diagrama Entidad Relación

Tabla Atributo Significado

USER

USER_PK Clave primaria de la tabla de usuario.

FIRST_NAME Nombre.

LAST_NAME Apellido.

EMAIL Correo electrónico.

AGE Edad.

SEX Sexo.

LOCATION Localidad.

OCCUPATION Profesión.

INSTITUTION Institución a la cual pertenece.

ABOUT Texto breve sobre el usuario.

PASSWORD Contraseña de la cuenta de usuario.

USER_CASE

USER_CASE_PK Clave primaria de la tabla intermedia usuario y caso.

USER_FK Clase extranjera de la tabla de usuario.

CASE_FK Clase extranjera de la tabla de caso.

CASE

CASE_PK Clave primaria de la tabla de casos médicos.

SPECIALTY Especialidad del caso.

DESCRIPTION Texto que describe el caso publicado.

DIAGNOSIS

DIAGNOSIS_PK Clave primaria de la tabla de diagnóstico.

CASE_FK Clase extranjera de la tabla de caso.

DESCRIPTION Texto que describe la opinión de los usuarios.

MEDIA

MEDIA_PK Clave primaria de la tabla de media.

DIAGNOSIS_FK Clase extranjera de la tabla de diagnostico.

FULL_PATH Camino de la imagen para el servidor.

SUBTITLE Subtítulo con descripción sobre el caso.

CONTACT

CONTACT_PK Clave primaria de la tabla de contacto.

USER_NAME Nombre de usuario.

SUBJECT Tema a ser discutido.

MESSAGE Mensaje de contacto.

Tabla 4. Diccionario de Datos DER - Sanar.



5.3.4. Modulo arquitectural En esta sección se informa de las decisiones más técnicas que llevaron a la

elección de la plataforma Java y el patrón de arquitectura de desarrollo adoptado anteriormente mencionado, denominado Modelo Vista Controlador - MVC.

Fig. 20. Patrón de arquitectura Modelo Vista Controlador.

En aplicaciones complejas, puede ser necesario dividir la interfaz (vista) de los datos (modelo). En este caso, sería necesario un puente (controlador) para procesar y responder a las acciones del usuario provocado por la vista, e invocar a los cambios en el modelo.

Considerando que, por ejemplo, una situación que se produce en uno de los registros de casos, Sanar recibe los datos por la vista, que son transferidos por el control a través de un objeto de transferencia de datos - DTO - para una instancia vacía de la clase Caso (modelo). Esta instancia se rellena con estos datos y luego se transfiere a través de un objeto de acceso a datos - DAO - en la tabla de casos, que se encuentra en la base de datos.

Además de la elección de lenguaje de programación y otros elementos relevantes, un factor importante fue el tema de alojamiento en un servidor web.

5.4. Visión general de la arquitectura La visión general de la arquitectura permite ver la integración entre los

módulos de administración y colaboración. En un flujo completo de acciones, a través de estas dos partes, una persona puede visualizar informaciones en un modo "anónimo". Después de realizar la inscripción mediante la introducción de datos básicos para la cuenta, ya se puede acceder al sistema. Entonces, cuando el usuario ingresa con su email y contraseña para rellenar el perfil con más informaciones de perfil, tales como su ubicación y la institución a la que pertenece. Hasta este punto, las acciones se centran en la gestión de la información del usuario.



A continuación, puede optar por hacer su primera publicación del caso o si más familiarizarse con Sanar, haciendo su primer comentario sobre un caso existente. Estas acciones pueden ser realizadas por la elección de un nuevo caso o mediante el acceso a las vistas que ofrece la aplicación, respecto de los casos (nuevos casos, más comentados, los líderes de opinión, etc.), con el fin de participar en una discusión. Esto ya es una parte inherente del módulo de colaboración.

Tras la presentación del marco teórico, la herramienta desarrollada y la arquitectura que se utilizó, se presentan los experimentos y sus resultados.

Capítulo 6. Sanar – Un Caso de Estudio


Capítulo 6. SANAR – UN CASO DE ESTUDIO

Esta sección tiene por objetivo mostrar los resultados de utilizar el recurso de colaboración para la construcción de los conocimientos médicos sobre la base de discusiones desarrollada en un caso de estudio. Todas las medidas y recomendaciones fueron implementadas en un proyecto que tuvo como objetivo proporcionar los conocimientos pertinentes a la atención de la salud a través de la herramienta de colaboración Sanar.

6.1. Descripción del experimento La evaluación de resultados se llevó a cabo a través de un estudio basado en

las impresiones de un grupo que utilizó Sanar.

El propósito de estos experimentos es analizar el uso de mecanismos de interacción para el desarrollo de los debates de colaboración en casos médicos, que tiene como objetivo llegar a un diagnóstico común a través de varios puntos de vista con el apoyo de los medios de comunicación tales como imágenes.

Además, el experimento es importante para identificar lo que ayuda y dificulta el desarrollo de una discusión, que sirve como base para la búsqueda de una interacción más eficiente.

A continuación se presentan algunas variables consideradas en el experimento.



6.1.1. Participación de los usuarios Esta característica está presente en entornos colaborativos. La participación

de los usuarios, en comunicación textual o implementaciones sobre un artefacto se pueden recoger sin variaciones derivadas del medio ambiente o el dominio, y sin requisitos de hardware especiales. El texto escrito, por ejemplo, es una forma de obtener información de un medio ambiente. Este es un aspecto importante para saber el nivel de actuación del individuo en la construcción de un artefacto, en este caso, el diagnóstico.

En la experimentación de Sanar, el nivel de participación del usuario es medido hasta el momento en que para de hablar o es interrumpido por otra persona, como en un sistema de turnos.

Si el propósito es establecer que los individuos participen en los períodos de discusión y un poco la proporción de participación, la medida podría ser menos minuciosa.

En este sentido, un turno comienza cuando una persona empieza a hablar solo. En resumen, la manera más adecuada de medir es por el número de mensajes, es decir, cada mensaje enviado puede ser considerado una vez hablando. Contar el número de palabras puede ser también una opción para obtener la cantidad de participación, ya que las palabras están separadas por espacios.

Por lo tanto:

Cuota de participación = número de palabras o mensajes enviados.

Estos indicadores hacen referencia a la cuantía individual de la charla. La conversación de grupo es la suma de todas las participaciones individuales. Si el objetivo es obtener la cantidad de cada estudiante, se puede calcular un promedio.

Participación del grupo = Σ Cantidad de participación de cada usuario

Tasa de participación individual = Participación individual / Participación del grupo

En el contexto de Sanar, este aspecto se refleja directamente a través de los comentarios sobre cada caso. Obviamente, la influencia del usuario en el caso A no daría lugar a una mayor participación en el caso B.



6.1.2. Manipulación de objetos La cantidad de trabajo de un usuario dentro de la aplicación es, en sí mismo,

un buen indicador de su interés en la participación de la tarea. Al igual que para la participación, mencionada anteriormente, esta medida permite establecer si los usuarios la están llevando a cabo y en qué forma. Esta es la manera más adecuada de calcular la manipulación de objetos:

Cantidad de manipulación = frecuencia de objetos tocados

Cantidad de manipulación del grupo = Σ Cantidad de manipulación

En términos prácticos con Sanar, esta manipulación de los objetos se da, por ejemplo, a través del uso de las imágenes.

En un experimento más amplio, sería posible medir también el nivel de interacción del usuario con otros elementos de la aplicación, que no se refiere exclusivamente a los casos de creación o revisión. Por ejemplo, los cambios en el perfil de usuario, la documentación y la consulta en los casos sin ni siquiera necesariamente comentar.

6.1.3. Variación de la interacción Otro aspecto que muestra la riqueza de la discusión es la variación de la

interacción. Un usuario puede participar activamente en una discusión de concreto, aunque nunca ha opinado sobre las demás.

Variación de la interacción = Número de casos opinados / Número de casos

Esto puede ocurrir debido a los muchos aspectos, como por ejemplo el número de casos relacionados a la especialidad del profesional. Por otra parte, puede ser una advertencia acerca de la calidad de los casos restantes. Si están más completos, pueden intimidar que otros usuarios participen.

Una variación de este aspecto sería la de calcular la participación del usuario durante un período determinado. Esto podría ser un indicador del nivel de fidelidad a Sanar.

A continuación se presenta la tabla 5 con las variables consideradas en los experimentos.



Aspectos considerados en la experimentación Aspecto Contribución Significado

Participación de los usuarios

Individual Comentarios enviados y participación en turnos de discusión

Grupo Cantidad y tiempo de cada turno de discusión en un caso

Manipulación de objetos

Individual Cantidad de manipulación de objetos

Grupo Suma de la cantidad de manipulación de objetos

Variación de la interacción Individual Cantidad de participación en casos médicos variados

Tabla 5. Aspectos considerados en la experimentación.

Después de presentar los principales aspectos tenidos en cuenta en el caso de los Sanar, a continuación están otros factores importantes para garantizar la calidad del experimento.

6.1.4. Fases del experimento Los miembros del grupo tendrán un período para familiarizarse con el medio

ambiente. En el caso de Sanar, este tiempo no es contabilizado. Entonces, el grupo va directamente a la visualización del caso médico con el objetivo de empezar los comentarios ya publicados. Esto será una base, una "directriz oculta" que servirá para establecer los parámetros para sus primeras opiniones.

En la tercera parte, los usuarios podrán opinar y manipular objetos del caso, como por ejemplo las imágenes.

La última fase consiste en la última evaluación por el coordinador y el diagnóstico final.

6.1.5. Discusiones Acerca de las discusiones, se llevará a cabo un análisis para estudiar el

tiempo de interacción y la cantidad de personas involucradas. En una situación donde se va por un camino que el coordinador no está seguro de que tiene que ver con el posible diagnóstico, él podría interactuar, sugiriendo que el razonamiento fuese trasladado a otro camino.

Esto podría ser una posibilidad en un punto muerto en que hubiera varias personas divididas en cuanto a dos o tres argumentos.



Aunque exista la preocupación mencionada, el objetivo de Sanar es incentivar la discusión de manera natural, sin intervenciones.

6.1.6. Análisis del experimento En el caso del experimento propuesto en este trabajo, habrá un tiempo de

respuesta. De todos modos, las normas de tiempo en un caso real son limitadas, sobre todo porque es una aplicación con la interacción asíncrona.

Desde el momento en que puso el caso médico sobre la medida correctiva, la interacción puede ser iniciada. Los profesionales sanitarios pueden interactuar con la aplicación y con otros usuarios, publicando sus puntos de vista. De alguna manera, la discusión tendrá fin en el momento que el administrador esté satisfecho con el razonamiento. De todos modos, esto no impide que otro usuario pueda enviar su opinión después de días, semanas o meses. De manera general, no existe un control estricto del tiempo.

El análisis de la colaboración en Sanar es aparente a través del análisis de cada usuario participante. Esto se ve facilitado por las herramientas que recogen las opiniones de cada individuo y las cambia en informaciones relevantes, como en el análisis realizado sobre las tres condiciones que se señalan en los apartados pasados.

6.2. Validación empírica Para probar la eficacia del Sanar en lo que se propone y en la calidad de los

informes presentados, algunos estudios se llevaron a cabo.

6.2.1. Primer estudio El primer estudio se llevó a cabo en la situación de la vida real con el

propósito de corroborar:

1) que Sanar cumple con los requisitos mínimos para garantizar una adecuada interacción entre los usuarios y;

2) que los aspectos Participación de los usuarios, Variación de la interacción y sobre todo Manipulación de objetos son relevantes para comprobar la contribución de los usuarios en la construcción del conocimiento médico;

Las hipótesis son las siguientes:



Hipótesis

H1: Es posible detectar la fluidez de una conversación entre profesionales de la salud, mediante un entorno de aplicaciones web.

H2: El uso de estructuras tal como el visor de imágenes, además de una respuesta completa demuestra el compromiso del usuario en ofrecer una opinión de calidad.

Sujetos

Una invitación para la participación se dio a algunos profesionales de la salud, con especialización en la odontología, de instituciones ubicadas en Brasil. Para esta primera iteración, se seleccionaron tres personas.

Grupos

Aunque lo ideal sería repetir el experimento con varios grupos homogéneos, el principal objetivo en este momento es garantizar la utilización mínima de Sanar en el entorno médico.

Materiales y Tarea

Teniendo en cuenta la claridad y la objetividad del experimento, los materiales para la interacción son las computadoras de los propios usuarios, que están muy dispersos geográficamente, como se mencionó anteriormente. Para acceder a la aplicación, sólo es necesario tener acceso a Internet y un navegador instalado.

Además de los conocimientos relacionados con la salud, esta actividad no requiere conocimientos previos en un área en particular.

Procedimiento

Los participantes podrán acceder a toda la aplicación, incluyendo la sección de ayuda. Esto facilitará que estén más familiarizados con el entorno, proporcionando información importante para análisis posterior.

A continuación, el usuario tendrá acceso a un caso médico, específicamente el área de la odontología. Este es un caso que ya ha sido examinado y



diagnosticado. Esto será utilizado para evaluar la calidad de la discusión sobre lo produjo. Durante un día, el usuario podrá opinar cuantas veces quiera.

Datos recopilados

En primer lugar, hemos creado un caso de prueba para la primera opinión de los usuarios. Luego se utilizó el caso de una imagen real de médicos, cuyo propósito era llevar a cabo el experimento. Los datos primarios extraídos de los experimentos fueron las conversaciones, que pueden incluir o no el uso de imágenes médicas.

Evaluación de participación de los sujetos

Los sujetos participaron activamente en el experimento. La edad de los usuarios, entre 23 y 38 años, no ha sido un punto de influencia en posibles diferencias en los resultados analizados.

Resultados H1

La conversación tuvo un total de 10 mensajes durante el día del experimento. Al final, se encontró que este tiempo fue bien gastado, ya que las participaciones estaban adecuadamente distribuidas.

Aunque hubiese el cuidado en publicar, las opiniones se defendieron y discutieron sin problemas. Al final, se detectó una fluidez de los resultados, aunque se supone la necesidad de conocimiento previo en temas de ordenadores e internet para el uso de aplicaciones en un entorno web.

Resultados H2

Una de las principales observaciones en el experimento fue el comportamiento de las respuestas. Aunque el argumento de los investigadores ha sido de forma completa, los primeros comentarios han sido publicar para sostener el diagnóstico sugerido por el usuario. A continuación, otras respuestas se caracterizan como complementos o contestaciones a las opiniones que están de acuerdo o en desacuerdo.

6.2.2. Segundo estudio Tras el primer estudio, se realizó un segundo estudio, utilizando un

cuestionario en línea. El objetivo fue:



3) la captura de comentarios de los participantes con respecto al uso de Sanar, y también comprobar con respecto a la calidad de la interacción que proporciona la aplicación;

La hipótesis es la siguiente:

Hipótesis

H3: El profesional de la salud, especialmente uno que tiene el perfil más joven, parece ser más abierto para el uso de Sanar.

Sujetos

Los mismos que para el experimento anterior. Un cuestionario electrónico fue enviado a las direcciones de correo electrónico de los participantes que tenían un período de aproximadamente una semana para responder. Después de recibir todas las respuestas, los pesos eran más razonables.

Grupos

Teniendo en cuenta las características del experimento, el objetivo era considerar a todos los participantes como parte de un grupo en un contexto global.

Materiales y Tarea

Los mismos utilizados para el experimento anterior.

Procedimiento

El cuestionario en línea sigue un modelo de declaración con la que se puede responder en una escala de 1 (totalmente en desacuerdo) a 5 (totalmente de acuerdo). El modelo utilizado se encuentra en el Apéndice al final de esta tesis.

Datos recopilados

Los datos recogidos para este experimento son las respuestas a los cuestionarios en el formato de afirmación.



Evaluación de participación de los sujetos

Al igual que en el experimento anterior, los usuarios realizan la interacción con la herramienta de acuerdo con las expectativas.

Resultados H3

De acuerdo a las respuestas de los usuarios, la iniciativa propuesta por el Sanar es interesante y relevante. Por otra parte, a pesar de tener una preocupación por la facilidad de uso, la herramienta aún necesita mejoras a esta dirección, proporcionando una interfaz más intuitiva.

De acuerdo con el feedback más informal de los usuarios, la comunicación ofrecida por Sanar se asemeja, de hecho, una mezcla entre un blog y una red social.

En el próximo capítulo están conclusiones de la tesis, con comentarios más específicos acerca de las contribuciones, los problemas encontrados y los posibles retos para trabajos futuros.

Capítulo 7. Conclusiones


Capítulo 7. CONCLUSIONES

Esta sección tiene por objetivo mostrar los resultados de utilizar el recurso de colaboración para compartir conocimiento médico sobre la base de discusiones desarrollada en un caso de estudio. Todas las medidas y recomendaciones fueron implementadas en un proyecto que tuvo como objetivo proporcionar los conocimientos pertinentes a la atención de la salud a través de la herramienta de colaboración Sanar.

7.1. Desarrollo del trabajo Inicialmente, se han descrito los conceptos de la Informática Biomédica,

siguiendo que un análisis histórico, comentando también las razones que llevaron a la adopción del nombre para la disciplina. Luego se han explicado de forma resumida las distintas líneas que componen el área, así como los frameworks y patrones para garantizar la calidad y la seguridad de la aplicación.

Seguidamente, se ha tratado el área de trabajo colaborativo soportado por ordenador (CSCW). Se ha abordado el concepto de trabajo en grupo y los principales aspectos de este tipo de herramientas tales como la coordinación, la colaboración, la comunicación, la percepción y la memoria del grupo.

A continuación, se detallaron algunos de los mecanismos utilizados por las herramientas cuya finalidad es el desarrollo de actividades de grupo. Se han descrito algunos entornos de desarrollo de software colaborativo, que ilustran algunas herramientas asíncronas, destacando sus principales puntos positivos y negativos. El capítulo 3 terminó con un cuadro comparativo sobre las solicitudes presentadas.



El Capítulo 4 ha presentado la herramienta desarrollada para la experimentación. Se ha propuesto el entorno Sanar, donde se puede crear un debate sobre un caso en una sesión abierta con la interacción asíncrona, como en un correo electrónico o un foro. Un usuario publica un caso con una descripción, una o más imágenes y un posible diagnóstico. Sus características se describen en términos de los aspectos de la informática biomédica, trabajo en grupo y la Web 2.0.

La arquitectura de la herramienta ha sido expuesta en el capítulo 5, que cubre la infraestructura de software necesaria, y descomponiendo su estructura interna en distintos módulos que implementan las funciones descritas en el capítulo anterior. Cada módulo se detalla, que describe las clases que la componen y la forma en que llevan a cabo las principales funciones del Sanar.

Por último, el capítulo 6 ha descrito el experimento controlado con la herramienta, en los que tratamos de demostrar la eficacia de sus recursos, en particular la creación y dinámica de discusión a través de los comentarios de los casos médicos. El plan del experimento se presenta, con su método de evaluación, entorno de ejecución y participantes, y la forma de realización. Cada resultado de esta evaluación es analizado y comentado.

7.2. Objetivos alcanzados y contribuciones Se recapitulan y se comentan en lo que sigue los objetivos propuestos en

este trabajo.

Estado del arte

La revisión de la literatura es el resultado de un análisis de casi 50 títulos, entre ellos, libros, tesis y artículos de revistas. Se ha prestado atención a la calidad de las fuentes, con el énfasis en las obras de autores conocidos en el área. Además de los temas más tratados, tales como Informática Biomédica y Trabajo Colaborativo, la revisión de la literatura se ha extendido también a temas como la Web 2.0 y también los patrones para el desarrollo de aplicaciones médicas.

Desarrollo de aplicación

Después de una investigación de las principales herramientas para la manipulación de imágenes médicas en un entorno de colaboración, se han detectado los aspectos positivos y negativos. En base a este análisis, se optó por desarrollar Sanar desde cero. Se ha utilizado conocimiento de muchas disciplinas,



tales como los métodos ágiles, desarrollo web, patrones de diseño, seguridad con imágenes médicas, etc.

Estudio de la validez de las hipótesis

Se ha tenido disponible un tiempo relativamente corto para aplicar experimentos más completos, pero estos apoyan la validez de las hipótesis. Posteriormente, en la sección sobre trabajos y líneas futuras, varios retos se discuten a fin de que la herramienta sea cada vez más amplia y fácil de usar.

Las características de la interacción del grupo contribuyen para flujo de discusión y la reanudación de información para los informes, con el objetivo de tener una visión holística de la interacción.

Se han cuidado que la aplicación desarrollada fuese fácil de usar y que los participantes hubieran emplearla en poco tiempo, aunque no sean personas del área de la tecnología. Se podrán llevar a cabo estudios adicionales en líneas futuras.

Los comentarios realizados en la herramienta también son una base para el análisis. A pesar de que existan dudas o incluso un desacuerdo sobre un hecho, los usuarios intentaron ser cuidadosos en sus opiniones, una vez que ellas representan sus competencias profesionales.

Se utiliza en este estudio una herramienta web que combina los conceptos utilizados en blogs y redes sociales. El espacio compartido es común para los usuarios trabajan en el mismo caso, y luego ellos se dan cuenta de las contribuciones hechas por otras personas.

Por último, la aplicación creada como parte de este trabajo también constituye una contribución útil a otros experimentos en el trabajo en grupo, como se propone en la labor futura, al final de este capítulo.

7.3. Dificultades Se presenta en esta sección algunas de las dificultades experimentadas

durante este estudio. El primer factor se refiere a la dificultad de evaluación de groupwares, generalmente subestimada por la investigación en esta área, tal y como se cita en (GRUDIN, 1994). Si bien la evaluación de las herramientas individuales depende principalmente de la facilidad de uso que ofrece y la experiencia del usuario, la evaluación de multiusuario se ve afectada por la diferencia de personalidades, las preferencias sociales, y la interacción cultural.



Además de eso, las evaluaciones cuantitativas no permiten un control adecuado de los aspectos culturales y las interacciones de grupo. Estas cuestiones son mejor evaluadas de forma cualitativa, a través de cuestionarios u observaciones, tal y como nos dedicamos a realizar en este trabajo.

El desarrollo y prueba de una aplicación multiusuario asíncrona es también más compleja. En primer lugar, estas características multiusuario requieren la participación de al menos dos personas que interactúan, aunque en momentos diferentes. Los participantes en la prueba deben ser advertidos para probar las características de la comunicación, la percepción y la colaboración asíncrona, pero el usuario medio, acostumbrado a las solicitudes de uso individual, no tiene experiencia con estos recursos.

Acerca del desarrollo de la herramienta, el modelo de Sanar, representado internamente por la gestión de casos y media asociada al caso, fue una de las características de mayor complejidad para su implementación.

Problemas de infraestructura y la configuración pueden afectar al rendimiento del groupware, dificultando su uso por las personas.

También se encontró que el número de participantes influye en el resultado de las evaluaciones: cuanto mayor sea el grupo, mayor es el número de interacciones, y la evaluación es más compleja.

7.4. Trabajos futuros Esperamos que este estudio haya creado un camino para la investigación

acerca de la construcción de conocimiento a través de casos médicos con archivos adjuntos, en este caso, imágenes médicas. Algunas sugerencias que se presentan a continuación se derivan de este trabajo, aprovechando la disponibilidad de la herramienta desarrollada, y la planificación de nuevos experimentos en condiciones que no se consideran aquí.

Por ejemplo, la aplicación se puede llevar a cabo experimentos a largo plazo, en varias sesiones de trabajo separadas. Otras posibilidades para la experimentación que se pueden considerar son: sesiones con un mayor número de participantes; experimentación de la herramienta de forma síncrona; sesiones con participantes con diferentes niveles de experiencia. Esta última posibilidad permite examinar si el tiempo de ejercicio de la profesión resulta en seguridad para establecer la comunicación en un entorno abierto.



Sanar es un proyecto con un carácter multidisciplinario, lo que justifica el uso en los estudios de diferentes áreas:

-Procesamiento y Análisis de Imágenes: aplicación de algoritmos morfológicos en imágenes de radiología para ayudar a los diagnósticos médicos.

-Ingeniería de Software: ver cómo la usabilidad puede contribuir para una interacción más completa entre los usuarios. Otra posibilidad sería estudiar también si la accesibilidad sería un tema pertinente para implementación.

-Experimentación en Ingeniería de Software: desarrollo de experimentos controlados para medir las diferentes variables que existen en una interacción. Replicación de los experimentos hechos en esta tesis, pero con la herramienta en un período avanzado de desarrollo.

-Entornos Virtuales Inteligentes: comparar las particularidades de interacciones entre usuarios de Sanar con otros entornos de colaboración, orientados a la salud o no. Otra posibilidad sería estudiar maneras de integrar Sanar con entornos 3D.

-Minería de datos: manipulación de datos y la aplicación de algoritmos de clasificación y asociación para la detección de patrones.

Además de estas, hay varias otras cuestiones relacionadas con la salud y las cuestiones jurídicas para hacer frente a los conocimientos compartidos.

Dado el potencial de Sanar para los aspectos educativos, una posible evolución es la construcción de un módulo que apoya de manera más adecuada los casos de estudio en un ambiente académico. En este caso, habría un modulo de evaluación interna con cuestionarios sobre acerca de un caso. Por último, el profesor (coordinador de la sesión) dispondrá de un informe con los resultados de cada estudiante.

Otra alternativa sería la evolución de Sanar para un mayor apoyo a la proyección de imagen médica, facilitando diagnósticos más complejos utilizando varios algoritmos, tales como la segmentación de regiones de interés.

A fin de promover una mayor difusión de Sanar, una serie de otros desarrollos y experimentos podrían ser dirigidos al área social. Esto podría ocurrir a través de la integración de la cuenta de usuario en redes sociales como Facebook. A través de la adhesión, sería posible desarrollar un recurso que facilita la difusión del concepto. Lo mismo podría aplicarse en Twitter.



Sin embargo, los avances más importantes serían la incorporación de otros mecanismos de interacción como el chat, el recurso de respuesta direccionada a un determinado usuario y la inclusión de efectos sobre el texto (negrita, cursiva, subrayado, etc.). Como complemento, se puede enriquecer la herramienta con otras funcionalidades de trabajo en grupo, proporcionando otros aspectos de coordinación, colaboración y comunicación dentro del área de colaboración de los casos.

Referencias


REFERENCIAS….…..



(ACKERMAN et al., 1999) ACKERMAN, M. S., HALVERSON, C. Organizational Memory: Processes, Boundary Objects, and Trajectories. Anais do 32nd Hawaii International Conference on System Sciences – Janeiro/1999, pp. 203-224.

(AIKINS et al., 1983) Aikins JS, Kunz JC, Shortliffe EH, Fallat RJ. PUFF: an expert system for interpretation of pulmonary function data. Comput Biomed Res. 1983 Jun;16(3):199–208.

(ALLWEYER, 2000) ALLWEYER, T. A Framework for Re-designing and Managing Knowledge Processes. IDS Prof. Scheer GmbH, 1997. www.processworld.com.

Acceso en: 20/05/2000.

(ARAUJO et al., 1997) ARAUJO, R.M.; DIAS, M.S.; BORGES, M.R.S., A Framework for the Classification of Computer Supported Collaborative Design Approaches, 3th International Workshop on Groupware (CRIWG’97), pp. 91-100, Espanha, 1997.

(BANNON et al., 1988) BANNON, L., BJØRN-ANDERSEN, N., & DUE-THOMSEN, B. “Computer Support for Cooperative Work: An appraisal and critique” in H. J. Bullinger et al. (eds.): EURINFO ‘88. Information Systems for Organizational Effectiveness, North-Holland, Amsterdam, 1988.

(BENDOUKHA, 2001) BENDOUKHA, L. Version-Based Description of Cooperation Aspects: Motivations and Objectives. International Workshop on Open Enterprise Solutions: Systems, Experiences, and Organizations (OES-SEO), Rome, Itália, September/2001, pp. 93-94.

(BEGOLE et al., 1997) Begole, J., Struble, C.A., Shaffer, C.A., Smith, R.B., Transparent Sharing of Java Applets: A Replicated Approach. Symposium on User Interface Software and Technology (UIST'97), ACM Press, NY, Octubre/1997.

(BOWER et al., 2005) Bower JL, Christensen CM. Disruptive Technologies: Catching the Wave Harvard Business Review Jan-Feb 2005 pp 43-53

(BRATKO et al., 1989) Bratko, 1. Mozetic, N.Lavrac, KARDIO: A study in Deep and Qualitative

Knowledge for Expert Systems, MIT Press, Cambridge Ma., 1989.

(BRINK, 1998) BRINK, T. Usability First – Groupware: Introduction. Usability

Referencias


First, 1998.

http://www.usabilityfirst.com/groupware/intro.txl.

Acceso en: 07/03/11

(CHAFFEY, 1998) CHAFFEY, D. Groupware, Workflow and Intranets: Reengineering the Enterprise with Collaborative Software. Ed. Digital Press, 1998.

(COCKBURN et al., 1996) COCKBURN, A., GREENBERG, S. and GUTWIN, C. Awareness Through Fisheye Views in Relaxed-WYSIWIS Groupware. Graphics Interface, Toronto, Canadá, Mayo/1996.

(COIERA, 2001) E. Coiera, Automated Signal Interpretation, in P. Hutton, Prys-Roberts (eds). 2001.

(COLLEN, 1986) COLLEN, M.F. Origins of medical informatics, West. J. Med. 145. (1986) 778–785.

(CONKLIN, 1996) CONKLIN, E.J. Designing Organizational Memory: Preserving Intellectual Assets in a Knowledge Economy. GDSS, 1996.

(CORBETT, 2000) CORBETT, M. On being an elephant in the age of oblivion: computer-based information systems and organisational memory. Information Technology and People 13 (2000).

(CRESPO, 2002) MAOJO, V., MARTIN, F., CRESPO, J., BILLHARDT, H. "Theory, Abstraction and Design in Medical Informatics: Application to Data Mining". Ref. X revista libro Methods of Information in Medicine. Stuttgart, Alemania. Volumen: 41. 44-50. 2002.

(DIAS, 1998) DIAS, M.S. COPSE: Um ambiente de suporte ao projeto cooperativo de software. Dissertação de mestrado, COPPE/ Universidade Federal do Rio de Janeiro, Brasil, 1998.

(DIAS, 1999) DIAS, M.S. Development of Groupware Systems with the COPSE Infrastructure. International Workshop on Groupware (CRIWG’99), Cancún, México, Septiembre/1999, pp. 278-285.

(DOURISH et al., 1992) DOURISH, P.; BELLOTI, V., Awareness and Coordination in Shared Workspaces. ACM Conference on Computer-Supported Cooperative Work (CSCW’92), Canadá, ACM Press, pp. 107-114, New York, 1992.

(FAMILYDOCTOR, 2011) Family Doctor

http://familydoctor.org

Acceso en: 17/04/11.



(GAMMA et al., 1995) GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Ed. Addison-Wesley, 1995.

(GRUDIN, 1994) GRUDIN, J. Groupware and social dynamics: eight challenges for developers. Communications of the ACM, 37(1), ACM Press, pp. 92-105, 1994.

(GREENBERG, 2001) GREENBERG, S, Context as a Dynamic Construct. Human-Computer Interaction, Volume 16, pp. 257-268, Lawrence Erlbaum Associates Inc, 2001.

(GREENBERG et al., 2000) GREENBERG, S., BAKER, K., GUTWIN, C. Heuristic Evaluation of Groupware Based on the Mechanics of Collaboration. Report 2000-669-21, Department of Computer Science, University of Calgary, Alberta, Canadá, Octubre/2000.

(GUTWIN et al., 1995) GUTWIN,. C.; STARK, G; GREENBERG, S. Support for Workspace Awareness in Educational Groupware, ACM Conference on Computer Supported Collaborative Learning, pp 147-156, Lawrence Erlbaum Associates, USA, 1995.

(GUTWIN et al., 1999) GUTWIN, C. and GREENBERG, S. The Effects of Workspace Awareness Support on the Usability of Real-Time Distributed Groupware. ACM Transactions on Computer-Human Interaction (TOCHI) 6 (3), 243-281, Setembro/1999.

(HASTMAN et al., 1996) HASMAN, A. et al., A systematic view on medical informatics, Comput. Methods Programs Biomed. 51. 131–139. 1996.

(HIMSS, 2011) HIMSS Web Page

http://www.himss.org/ASP/topics_ehr.asp.

Acceso en: 03/03/11

(HOYT, 2007) Hoyt, Robert. Médical Informatics: practical guide for the healthcare professional 2007. Pensacola, FL: School of Allied Health and Life Sciences, 2007.

(IÑESTA, 2003) IÑESTA, J. CRESPO, J. "Principios Básicos del Análisis de Imágenes Médicas". Manual de Informática Médica. Editorial Menarini. 299-333. 2003.

(MAOJO, 1998) MAOJO, V., CRESPO, J. MUÑOZ, A., ESPARZA, J., SAEZ, L. “Aplicaciones Médicas de Trabajo Colaborativo en Internet”. Congreso I Jornadas Nacionales de Internet en Salud -

Referencias


Inforsaludnet 98. Madrid. 1998.

(MATSON, 1996) MATSON, E., The seven sins of deadly meetings. Fast Company, issue 2, pp. 122, Abril/1996.

(MORENO et al., 2010) MORENO, R. Sistema Colaborativo Para Discussão De Casos Clínicos. XII Congresso Brasileiro de Informática em Saúde. 2010.

(MORRISON et al., 2001) MORRISON, J, OLFMAN, L: Knowledge Management, Organizational Memory, and Organizational Learning - Minitrack Introduction. HICSS 2001

(ORACLE, 2011) Java Shared Data Toolkit User Guide, Version 2.0. Sun Microsystems Inc., Palo Alto, California, EUA, Outubro/1999. http://java.sun.com/products/java-media/jsdt/

Acceso en: 15/04/11.

(PINO et al., 2000) PINO, J.A.; BORGES, M.R.S.; SALGADO, A.C., Requirements for Shared Memory in CSCW applications. 10th Annual Workshop On Information Technologies and Systems (WITS'2000), pp.211-216, Austrália, 2000.

(PINO et al., 2001) PINO, J.A., PINEDA, E. Stick-Ons Revisited. Seventh International Workshop on Groupware (CRIWG'01), Septiembre/2001, Darmstadt, Alemanha.

(RAND, 2005) Rand. The Diffusion and Value of Healthcare Information Technology. 2005.

http://www.rand.org/pubs/monographs/2006/RAND_MG272-1.pdf Acceso en: 21/02/11

(RODRIGUEZ et al., 2000) M. A. Rodríguez. E. Suárez, J. Ruiz, C. Alberola, "Una herramienta de clasificación estadística para el entorno diSNei", Actas del XV Symposium de la Unión Científica Internacional de Radio, URSI-99, Zaragoza, Septiembre 2000.

(ROSEMAN, 1996) ROSEMAN, M., GREENBERG, S. Groupware Toolkits for Synchronous Work. In M. Beaudouin-Lafon, editor, Computer-Supported Cooperative Work (Trends in Software 7), Chapter 6, pp. 135-168, John Wiley & Sons Ltd, 1996.

(ROSEMAN et al., 1996) ROSEMAN, M. and GREENBERG, S. Building Real Time Groupware with GroupKit, A Groupware Toolkit. ACM Transactions on Computer Human Interaction, 3(1), p. 66-106,



ACM Press, Marzo/1996.

(SERRANO, 2003) SERRANO, M., SIMON, O., MAOJO, V., MAHIQUES, J., CARRERAS, F. Principios Básicos del Análisis de Imágenes Médicas. Editorial Menarini. Barcelona. 2003.

(SHORTLIFFE, 1987) Shortliffe E. H., Computer Programs to Support Clinical Decision Making, JAMA, 258, (1987), 61-66.

(SHORTLIFFE et al. 1990) E. H. Shortliffe, L.E. Perreault, G. Wiederhold, L. M. Fagan, Medical informatics: Computer applications in health care, Addison-Wesley, Reading, MA, 1990.

(TOLEDO, 2011) University of Toledo http://homepages.utoledo.edu/akunnat/chap10pt2.ppt Acceso en: 21/02/11.

(WALSH et al., 1991) WALSH, James P.; UNGSON, Gerardo Rivera. Organizational memory. The Academy of Management Review, Briarcliff Manor, NY, v.16, n.1, p.57-91, Jan. 1991.

(WIKIPEDIA, 2011) Disruptive Technology www.wikipedia.com

Acceso en: 20/02/11

Anexos


ANEXOS….…..



A. Cuestionario de evaluación – Segundo estudio Universidad Politécnica de Madrid - Biomedical Informatics Group Collaboration Environments and Interactions with Medical Artifacts Experimentation with Sanar collaborative tool - Evaluation questionnaire Date: ___ / ___ / ______ Participant identification (optional): Research area: Each statement presented below refers to an issue of controlled experiment conducted with Sanar, a collaborative environment for medical knowledge co creation. For each one, check one of the options indicating your opinion on the issue. Feel free to add comments about the question.

(01) The format of ideas in the use of Sanar allied to the comments ensures the existence of the discussion, although participants are geographically dispersed. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(02) The interface of Sanar is attractive enough and simplified to the point of not compromising the productivity of the interaction. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(03) The image preview feature facilitates the understanding of medical cases. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(04) The possibility of the user to view messages from other users is a feature that can facilitate the construction of opinion. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(05) The layout of the messages in blog format facilitates understanding the structure of the discussion. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(06) The process of registering in Sanar is intuitive, though there are other attributes to be filled later. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

Anexos


(07) The information on the Home allows Sanar identify with clarity the goal of each of these features, such as New Case, Profile Settings, etc. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(08) The additional information (help and about) have relevant content to answer questions. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(09) Discussion resources of Sanar are characterized as a positive point for the improvement of group interaction. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

(10) The availability of software for building medical knowledge on the web supports knowledge construction among health professionals in a global context. ( ) I totally disagree ( ) I disagree ( ) I prefer not to opine ( ) I agree ( ) I totally agree

universidad politécnica de madrid facultad de informática trabajo

Documents