Activities and tasks permormed

Activities

-Questionnaires



•What is the hardest part of the system?












•What is the easiest part of the system?











•What do you think is missing?











•What do you think has more?











•Are they understand the characteristics?















Tasks



Comments in general


•Little help
•User name
•Images

Interfaces del Prototipo












2ª Feria de Prototipos

video

Segunda Entrega

CONTENIDO
1.-Introducción
1.1.-Propósito
1.2.-Ámbito del Sistema
1.3.-Definiciones, Acrónimos y Abreviaturas
1.4.-Visión General del Documento
1.5.- Modificaciones en el documento
2.-Descripción General
2.1.- Perspectiva del Producto
2.2.- Funciones del Producto
2.3.- Características de los usuarios
2.4.- Restricciones
2.5.-Suposiciones y Dependencias
2.6.-Requisitos Futuros
3.-Requisitos Específicos
3.1.- Interfaces Internas
3.2.- Interfaces Externas
3.3.- Funciones y Tipos de Usuarios
3.4.- Requisitos de Rendimiento y Tecnológicos
3.5.-Restricciones de Diseño
3.6.-Atributos del Sistema
3.7.-Otros Requisitos
4.-Apéndices 

1. INTRODUCCIÓN
Este documento está ideado para la descripción de los requerimientos software para el sistema de ayuda práctica para médicos estudiantes; este ERS cuenta con los datos necesarios para el correcto uso del sistema basado en el estándar IEEE Recommended Practice for Software Requirements Specification y las especificaciones del Orientador del proyecto, en este caso el maestro Edgar Cambranes Martinez.Este documento es parte de la colaboración de varios estudiantes del tercer semestre de la licenciatura en Ingeniería de Software de la Facultad de Matemáticas, con el fin de lograr el correcto desarrollo de este proyecto.

1.1 PROPÓSITO
La finalidad del documento aquí presente es la de esclarecer los funcionamientos y las utilidades de nuestro proyecto así como los requisitos y las restricciones para su uso.Basándonos de las investigaciones y recopilación de datos que nos sean de utilidad para el proyecto hemos desarrollado los perfiles de usuario necesarios y los requerimientos del sistema aquí descrito.Este documento va dirigido a los desarrolladores, administradores y usuarios finales del sistema para que tengan una manera más accesible de conocerlo y entenderlo. En segunda instancia será dirigido a personas con intereses profundos por el tema de la ingeniería de Software como disciplina y/o personas con interesadas en el desarrollo de objetos de aprendizaje aplicados al campo de la medicina.Se espera con este documento redactar correctamente la manera en la que se desarrolla el sistema en cuestión así como sus limitaciones y restricciones.

1.2 ÁMBITO DEL SISTEMA
El propósito del sistema es el de aportar una manera alternativa y eficiente de realizar las prácticas médicas de los estudiantes de medicina general dado que se han descubierto ciertas limitaciones en este ámbito, las cuales posteriormente se esclarecerán en los documentos adjuntos a esta especificación.Nos hemos basado en el hecho de que hoy en día es muy difícil para los estudiantes de licenciaturas altamente prácticas, en particular los estudiantes de medicina, tener acceso a los materiales suficientes para realizar sus prácticas. En su defecto suelen haber complicaciones y limitaciones para los materiales que utilizan; esta clase de cosas se pueden ejemplificar con: la necesidad de trabajar con cadáveres los cuales no presentan las mismas reacciones que una persona viva, esto lo hace poco real. Otro ejemplo sería el hecho de que la escasez de cadáveres hace que al tratar de maximizar el material de trabajo, los estudiantes suelan practicar con cadáveres ya examinados, esto hace la práctica demasiado intuitiva y se pierde el sentido del aprendizaje mediante la práctica.Esperamos con este sistema facilitar la organización de las prácticas y manipulación de datos necesarios para mejorar las prácticas medicinales de las personas que cursan los últimos años de la carrera de medicina general.

1.3 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS.
Administrador u Orientador.- Persona encargada de supervisar el correcto desarrollo del sistema, en este caso, el maestro Edgar Cambranes Martinez.
Desarrolladores.- Personas encargadas de interpretar la información del ERS y llevarla a cabo.
ERS.- Especificación de Requisitos Software.
HCI.- Human-Computer Interaction. Disciplina para la cual este documento se desarrolla.
KLOC.- Kilo Líneas de Código (mil líneas)
MediPráctico.- Nombre del sistema al que hace referencia este documento.
POO.- Programación orientada a objetos.
SW.-Software.
Usuario final.- Persona a la que le llegará y servirá en última instancia el sistema. En ese caso, los estudiantes de la carrera de medicina general a partir del tercer año de carrera.

1.4 VISIÓN GENERAL DEL DOCUMENTO
Este ERS consta de cuatro partes principales, la primera que es la introducción en la cual se describen las características del documento y el propósito del mismo; la segunda trata de describir el sistema de manera general de tal manera que sea entendible y cubra de manera eficiente las dudas que en un momento podrían plantearse; la tercera parte consta de la definición de los requisitos para el correcto desarrollo y funcionamiento del sistema; por último la cuarta parte consta de la descripción de los apéndices los cuales nos servirán de ayuda y/o justificación para el proyecto.

1.5 MODIFICACIONES EN EL DOCUMENTO
Se le agregó la funcionalidad de guardar el caso en las áreas correspondientes y se le agregaron imágenes correspondientes a las interfaces graficas en la parte de interfaces junto con una descripción específica de cada una.

2.0 DESCRIPCIÓN GENERAL
MediPráctico es un sistema de ayuda en línea para estudiantes de medicina general, este sistema se ayuda de una base de datos y un sistema experto en línea que genera cuestiones o un listado de síntomas para el diagnóstico de éstas, proporcionará una serie de cuestiones aleatorias para que el usuario determine la manera correcta de solucionar y/o diagnosticar la situación presentada.Al referirnos a cuestiones aleatorias no nos referimos a generar aleatoriamente los síntomas que se presentarán en pantalla sino que el sistema experto internamente selecciona una enfermedad y despliega una lista de los síntomas puntuales que representan al padecimiento.El motivo para el cual se hace este sistema es que los estudiantes de medicina tienen itinerarios muy irregulares, por lo tanto pierden mucho tiempo valioso para ejercitar sus conocimientos. Tales conocimientos vienen de una compilación muy extensa la cual resultaría estorbosa físicamente (copias, impresiones, etc.), por tanto hemos decidido que el sistema trabajaría con una base de datos en línea.El sistema será hecho para PC’s dado que las personas encuestadas preferían este tipo de SW; en este caso se presupone que todos los estudiantes que preferían esta opción poseen una computadora personal o en sus casas.

Características generales del sistema
El sistema utilizará una base de datos con los temas concernientes a las prácticas medicinales, tal información nos será proporcionada por personas expertas en el tema, se espera en un futuro poder acceder a una base de datos con información de hospitales y clínicas en general. Si el usuario lo desea puede cambiar la pregunta en ese momento generada, esto es por el hecho de que algunos temas son triviales para los estudiantes y necesitan concentrarse en los temas que aún no dominan. El programa generará un listado de síntomas clave de alguna enfermedad seleccionada aleatoriamente para que el usuario determine el padecimiento. Por cada compilación de síntomas expuestos se generarán dos posibles opciones para darle una idea al usuario de qué enfermedad puede ser y así el sistema no sea incoherente. La interfaz gráfica será agradable para la vista del usuario, sin utilizar colores brillantes o perjudiciales en la práctica. El sistema tendrá la opción de guardar el caso y su resultado internamente en la computadora en un documento de texto, esta funcionalidad está pensada por la necesidad que surge de acudir varias veces al tema. El sistema no analizara porcentajes o medidas estadísticas con respecto a los resultados obtenidos por el usuario. El sistema no determinará si el practicante está listo para una práctica real. No certificará al usuario como apto para cierta clase de prácticas No delimitará las áreas en las que el usuario es mejor.
El producto requiere ser:
• Versátil.- En esta característica suponemos que el programa requerirá ciertas adaptaciones, cuestión de mantención de perfeccionamiento, ya que los usuarios (practicantes de medicina) suelen cambiar de ámbito o adquirir nuevos conocimientos por tanto habrá modificaciones futuras.
• Práctico: Nuestro programa no necesitará involucrarse con asuntos que no estén relacionados con las prácticas medicinales, debido a eso, podemos hacer que sea manejable y menos ostentoso.
• Fácil de usar: Necesitamos que la interfaz humano-producto se encuentre en condiciones favorables, dado el escaso tiempo que poseen los usuarios para aprender a manejar un sistema, para lograr esto, se necesita del uso de lenguaje poco complejo, opciones de ayuda y manual de utilización del producto.
• Desarrollo Centrado en el usuario: Considerando el tiempo que se destinará al desarrollo del producto, concluimos de acuerdo a nuestro cronograma que podremos ocupar una buena parte del tiempo investigando y haciendo pruebas para lograr un mejor entendimiento del usuario y su ambiente, de esta manera minimizaremos los errores de interacción que puedan surgir.
• Costo accesible: Dado que solamente trabajan en el proyecto cuatro personas y el tiempo es relativamente corto, basándonos en el pentagrama de Kiviat, se concluye que los costos de desarrollo son constantes y por tanto no se eleva el costo unitario en el marketing.
Las características generales de desarrollo del producto son:
• Tecnología conocida: Para mantener los costos unitarios constantes se necesitan utilizar métodos ya conocidos para no invertir recursos (tiempo, dinero) en descubrir nuevos métodos de desarrollo.
• Tiempo de desarrollo aproximado de 6 meses: Este factor está dado por el administrador del proyecto.
• Ciclo de vida en cascada: Factor determinado por las cualidades antes mencionadas.

2.1 PERSPECTIVA DEL PRODUCTO
Dado el paradigma orientado a objetos utilizaremos una metodología de enseñanza llamada objetos de aprendizaje, la cual se basa en utilizar la POO para fines académicos o didácticos.
Es importante decir que nuestro producto no deberá interactuar con otros sistemas, pero se apegará a los requerimientos de la computadora donde será usado.Se consideran futuros cambios para el mantenimiento y mejoramiento del sistema, ya que el sistema todavía está en la etapa 1.0
El usuario no tiene que entrar en contacto con la manera en la que la información se administra dentro del sistema.

2.2 FUNCIONES PUNTUALES DEL PRODUCTO
• El sistema utilizará una base de datos para la generación de preguntas y diagnósticos.
• Las preguntas se generarán de manera aleatoria.
• Las preguntas tendrán opción múltiple para su mejor interpretación.
• El sistema contará con un menú de ayuda para su mejor uso.
• El sistema dará la opción de guardar el caso en un documento de texto.
• El sistema permitirá al usuario saltarse casos.
• El sistema permitirá al usuario guardar los casos en la computadora. 

2.3 CARACTERÍSTICAS DE LOS USUARIOS.
El sistema deberá ser extremadamente sencillo y manejable de tal manera que el usuario sea capaz de entender e interactuar con él al momento de leer las instrucciones.Puede ser muy útil para usuarios como:
• Personas que cursan a partir del tercer año medicina general, este factordeterminado por las encuestas realizadas nos indica que los estudiantes de ese nivel académico son los que menos tiempo libre tienen y además su itinerario puede ser irregular.
• Personas que realizan sus prácticas médicas en consultorios y no tienen tiempo suficiente para practicar sus diagnósticos.
• No necesitan experiencia técnica en computadoras pero se requiere conocimiento básico en el manejo de una computadora.

2.4 RESTRICCIONESLimitaciones que se imponen sobre los desarrolladores del producto:
• Viabilidad y fiabilidad del sistema.
• Limitaciones en el hardware, por ejemplo, no contar con computadora o en su defecto que no sea compatible.
• Limitaciones de servidor, es decir que el sistema no se pueda conectar a internet para generar las preguntas.
• La base de datos del sistema debe contener datos verídicos y exactos. Estos, serán proporcionados por personas expertas en el diagnóstico de enfermedades, en este caso un Doctor que imparte clases en la facultad de Medicina de la UADY.
• Manipulación de datos fácilmente. Eso implica que exista una manera organizada y metódica para almacenar la información en el servidor y aprovechar tiempo en otros ámbitos.
• Lenguaje de programación: Java, debido a que es amigable con las interfaces y la compatibilidad, eso nos permite ejecutar las aplicaciones java (.jar).
• Seguridad: utilización de métodos que no afecten la manera en la que trabaje la PC, es decir, el sistema no debe acceder a la información del usuario almacenada en ella.

2.5 SUPOSICIONES Y DEPENDENCIAS
Se asume (En el mejor de los casos) que los requisitos descritos en este documento son estables, sin embargo las necesidades de los estudiantes suelen ser muy variadas, eso supone que aun es muy pronto para determinar que los requisitos para el desarrollo del producto sean invariables.Para el desarrollo del producto se recomienda un ciclo de vida en cascada ya que es un sistema simple y utiliza tecnología conocida para su funcionamiento.Dado que el sistema está en primera versión no interactuará con ningún otro sistema informático, no tiene dependencias y por supuesto, no debe acceder a la información almacenada en el dispositivo móvil donde interactuará. Factores que, si cambian, pueden afectar los requisitos del sistema:
*Sistema operativo incompatible.
*Clases de archivos soportados por el sistema.

2.6 REQUISITOS FUTUROS
Futuras mejoras al sistema, que podrán analizarse e implementarse en un futuro.• Actualización del software: Pueden presentarse problemas en la compatibilidad del dispositivo según la antigüedad del sistema.• Agregar funcionalidades: En dado caso que el sistema necesite cosas para mejorar, podremos incluirle funcionalidades adicionales, sin embargo, esto sólo podrá ser determinado después del estímulo aplicado con el prototipo o en su defecto con el paso del tiempo cuando la curva s de aprendizaje llegue a su límite.• Quitar funcionalidades: Al igual que el punto anterior, podremos suprimir funcionalidades que no sean necesarias basándonos en el estímulo o el paso del tiempo, sin embargo se espera que eso no sea necesario ya que entraría en contradicción con el paradigma de la ingeniería de SW de no hacer más funcionalidades de las necesarias.
*Se espera con este software facilitar la manipulación de datos y darles una mejor perspectiva de cómo y en qué situaciones especificas aplicar los conocimientos adquiridos. En segunda instancia sugerir una idea de cómo aprovechar el escaso tiempo libre que los usuarios tienen.


3.- REQUISITOS ESPECÍFICOS

3.1 Interfaces internas
El sistema funcionará con una base de datos simple, la cual será administrada por los integrantes del equipo. Esta base de datos será llenada con la información proporcionada por la persona que nos ayudará al desarrollo del proyecto. La información se organizará por medio de un listado de enfermedades, con sus respectivos padecimientos puntuales, esto último nos permitirá generar las opciones múltiples con mayor cohesión y coherencia.La base de datos será desarrollada en MySQL dado que es uno de los más versátiles y comunes de los sistemas para programación en bases de datos.La manera en la que se presente gráficamente o visualmente la información aún no está definida pero por el momento eso no es relevante para el desarrollo.

3.2 Interfaces externas
El proyecto a pesar de tener un funcionamiento sencillo no se recomienda ser manejado por personas no visualizadas como usuarios tales como, niños o personas ajenas a la disciplina, ya que esto implicaría confusión hacia estas personas, este SW sólo puede ser utilizado como un generador de preguntas aleatorias no como un medio de agresión a la moral de las personas, como suele suceder en el ámbito de la medicina; el sistema emplea un lenguaje de nivel medio para interactuar con los usuarios, conformado por palabras sencillas, como “inicio”, “salir”, “ayuda”, etc. También emplea un menú de ayuda donde se generalizan los aspectos más básicos con respecto a la funcionalidad del programa.Sin embargo aún así el programa será entregado con un manual detallado para su correcto y más conveniente uso. Eso facilitará su interacción con las personas.
El lenguaje que el programa utiliza es Java; ya que es compatible con varios tipos de sistemas operativos.En dado caso de operar con otro sistema, primero hay que confirmar que sea compatible.
- La interfaz de usuario debe ser orientada a ventanas, y el manejo del programa se realizará a través de teclado.
- El hardware debe ser simplemente una computadora con un sistema operativo compatible.
- El software al igual que el hardware debe ser sencillo y comprensible.
- Por el momento no debe tener acceso a otros sistemas pero debe ser capaz de imprimir en pantalla los resultados de las preguntas realizadas y la cantidad de respuestas acertadas.

A continuación presentamos las interfaces más importantes de los prototipos, la primera es la de entrada, la cual pide el nombre o el pseudónimo por el cual el sistema se referirá al usuario y un botón entrar:

Después tenemos la interfaz del caso medico la cual expone el caso con toda la información necesaria para el diagnóstico, tres posibles respuestas, un botón para saltarse la pregunta y otro para confirmar la respuesta, en la parte superior tenemos un botón de ayuda y un menú para opciones como, guardar caso el cual despliega una ventana para examinar la ruta en la que se guardará el archivo de texto que contendrá al caso. 
Otra de las más importantes interfaces es la de la respuesta correcta, ya que indica el porqué es correcta, en esta parte, la interfaz sigue conservando el menú y el botón de ayuda el cual despliega un texto con información necesaria para utilizar correctamente el sistema.
Existen otras interfaces como la de cargando caso, la cual tiene el logotipo de medi-práctico y una barra de estado además de un dato curioso como ayuda a la cultura general del usuario.
La interfaz de ayuda que consta de un archivo de texto con información distribuida por temas importantes y preguntas frecuentes, estas últimas estarán dadas por las pruebas del prototipo a estudiantes de la licenciatura correspondiente y personas que aspiran entrar a esa licenciatura.

3.3 Funciones y Tipos de Usuario
Será necesario dar de alta en el sistema un dato básico de los usuarios:
- Pseudónimo de Usuario: Esto es solo para que el sistema no se involucre con información personal del usuario pero pueda referirse a él de alguna manera.

Algunos requisitos básicos para gestionar la información de usuarios en el dispositivo son:
- Será posible modificar el pseudónimo del usuario.

Las funciones son universales y no las clasificaremos por tipos de usuario ya que es destinada a un único tipo de usuario. El nivel de experiencia está dado por la familiarización del usuario con la computadora.

*Para usuarios a partir del tercer año en medicina general o una carrera afín: esta clase de usuarios estará definida en la parte de perfiles y personas de esta misma entrega.

3.4 Requisitos de rendimiento y tecnológicos
Con respecto a la compatibilidad de hardware se supone trabajar con los que soporten ejecutables de java .jar.El hardware de entrada necesario mínimo es el teclado del dispositivo y el de salida la pantalla.Se espera que el sistema pueda trabajar fácilmente y de manera rápida, sin que le afecte la cantidad de información que lleve en la base de datos, ya que no necesita descargar toda la base de datos para trabajar, solamente trabajará con una situación a la vez.

3.5 Restricciones de diseño
La versatilidad y el tamaño del diseño no deberían variar ya que no siempre podría aplicarse con hardware sofisticado. Habrá que determinar también el lugar donde se ubicará el dispositivo que trabajará con este SW ya que no es recomendable colocar en sitios húmedos, sitos con niveles altos de electromagnetismo, o simplemente sitios propensos a accidentes o golpes.

3.6 Atributos del sistema
La fiabilidad del producto determina que es completamente confiable y fácil de utilizar para los usuarios al que está destinado ya que viene programado para trabajar en un solo nivel de comprensión.La portabilidad del programa hace que sea muy fácil de usar y cada vez se hará más común su uso.
Una de las mejores cualidades del programa es que solo usuarios calificados tendrán la capacidad de contestar de manera correcta, en su defecto les ayudará a comprender mejor algunas cosas, estos usuarios deberán escribir o elegir (en caso de que ya exista) su pseudónimo antes de comenzar. Solamente para poder referirse al usuario.

3.7 Otros Requisitos
El SW deberá trabajar correctamente sin necesidad de conectarse a otro dispositivos cuya función no sea cuantificar, sin embargo es conveniente colocar un regulador de energía ya que las bajas de corriente pueden dañar la información o dejarlo fuera de servicio temporal o hasta permanentemente.En versiones futuras se piensa agregarle funcionalidades dependiendo de los requisitos que pudieran surgir.Solo deberán utilizarse mouse y teclado como dispositivos de entrada. 

4.-APÉNDICES
Para mejor desarrollo consultar los archivos adjuntos que contienen información específica sobre los temas.Estos son:*Descripción y bases del sistema.*Funcionalidad y Justificación.*Análisis de las encuestas aplicadas.*Perfiles y personas.

DOCUMENTACIÓN DEL PROYECTO

DESCRIPCIÓN: Se desarrollara un sistema portátil para la simulación de problemas médicos para los pasantes de las carreras médicas a partir del tercer año. Con este sistema se pretende mejorar el proceso de aprendizaje de los alumnos de estas carreras ya que existen ciertas dificultades para la realización de actividades que impliquen materiales de disección o el tratamiento de malestares particulares de enfermedades específicas.

FUNCIONALIDAD: Por medio de objetos de aprendizaje y siguiendo el paradigma orientado a objetos el sistema simulará situaciones especificas de malestares que puede presentar una persona para que el alumno determine la mejor manera de tratar con el problema. El sistema tendrá como funcionalidad principal presentar los síntomas y darle la opción al usuario de dar un diagnóstico y la mejor manera de tratarlo. Debe tener una interfaz gráfica que simule partes del cuerpo humano para orientar y mejorar la relación médico-paciente.

TRABAJOS RELACIONADOS:

Universidad de Colima. Centro Universitario de Producción de Medios Didácticos: Para que exista un buen aprendizaje se requiere:

-Motivación del autoaprendizaje.

-Información eficaz.

-Desarrollo de análisis y reflexión.

-Aclaración de dudas.

La definición de Objeto de Aprendizaje que da la IEEE, (Institute of Electrical and Electronics Engineers, Inc.) es:

“Un objeto es cualquier entidad digital o no digital que puede ser usada, re-usada o referenciada para el aprendizaje soportado en tecnología”.

El maestro Jorge Rafael Martinez Peniche señaló:

A los maestros nos cuesta trabajo intercambiar material educativo, ya que, en muchas ocasiones, la enseñanza de un mismo tema no tiene el mismo enfoque en asignaturas o cursos distintos, o simplemente porque enseñamos de distinta forma, en diferente orden. Entonces, en vez de intercambiar temas, materias o cursos completos hay que atomizar el conocimiento, o sea, llegar a la unidad que sea mi moneda de cambio sin problemas.

Metodología de Construcción de Objetos de Aprendizaje para la Enseñanza de Anatomía Humana en Cursos Integrados:

El desarrollo y uso de un objeto de aprendizaje para la comprensión de partes especificas del cuerpo, es más eficiente que en la forma de un clásico curso lineal, porque es compatible con los nuevos paradigmas educacionales, donde el aprendiz construye su propio conocimiento.

La relación de los estudiantes con el cadáver en el estudio práctico de anatomía: la relación e influencia en el aprendizaje.

Los estudiantes al principio tienen aversión hacia los cadáveres, lo cual les ocasiona un limitante en el aprendizaje.

Vygotsky y teorías sobre el aprendizaje

La experiencia de Aprendizaje Mediado es la manera en la que los estímulos remitidos por el ambiente son transformados por un agente mediador. Este agente mediador guiado por sus intenciones, su cultura y su inversión emocional, selecciona y organiza el mundo de los estímulos.

Aprender medicina a través de los videojuegos

La atracción de la medicina ha sido detectada por el mundo del ocio electrónico, ya hace algún tiempo que los médicos y la enfermeras protagonizan los juegos de video […]esta clase de juegos reconocen el movimiento y permiten suturar, vendar , etc.

Paciente Virtual


El "Paciente Virtual" es un simulador desarrollado por el equipo técnico de "EL Medico Interactivo" y al que han aportado casos reales destacados expertos de distintas especialidades.
Constituye una herramienta práctica de actualización y formación continuada permitiendo desarrollar con un paciente electrónico todo el proceso diagnóstico y terapéutico que normalmente se sigue con un paciente normal.

Nucleus: Medical Art

Nucleus es una empresa dedica a realizar animaciones anatómicas y celulares en 3D con motivos principalmente ilustrativos. Cuentan con un catálogo de trabajo increíble y tienen mucho material a disposición de quien lo quiera pagar. Este sistema sirve para describir con precisión las enfermedades a los pacientes de un consultorio.

Diario HOY

La Facultad de Medicina de la Universidad Nacional de La Plata (UNLP) adquirió modernos modelos de simulación para la puesta en marcha de dos “laboratorios de habilidades y destrezas”. Se trata de muñecos con apariencia humana que ayudarán a mejorar el nivel de enseñanza.
“Es una nueva técnica pedagógica que facilita el acercamiento de los alumnos al hospital. El objetivo es que puedan realizar prácticas invasivas, en forma repetitiva, sin que sufran los pacientes”

Exquisite Bodies

In the 19th century, despite the best efforts of body snatchers, the demand from medical schools for fresh cadavers far outstripped the supply. One solution to this gruesome problem came in the form of lifelike wax models. These models often took the form of alluring female figures that could be stripped and split into different sections. Other models were more macabre, showing the body ravaged by 'social diseases' such as venereal disease, tuberculosis and alcohol and drug addiction.

Educar. Aprender medicina en los tiempos del videojuego

Un estudiante de medicina de Tucumán creó un programa de computación para compensar una de las deficiencias más importantes de la formación académica: la falta de entrenamiento de los alumnos para resolver problemas concretos y enfrentarse a situaciones reales. Para ello, Luis Ortiz Atienza pensó en una dinámica interactiva, como la de un videojuego, en la que el alumno tiene que interactuar con un paciente virtual y contrastar sus hipótesis con una realidad simulada.


SimMan 3G es el robot para practicar medicina

La empresa noruega Laerdal Medical ha creado un robot llamado SimMan 3Gcapaz de llorar, sangrar, convulsionar y hasta sufrir un paro cardíaco. Las reacciones del robot se controlan con un Tablet PC y sus signos vitales se pueden visualizar en un monitor para una completa simulación. La apariencia que le han dado al robot es lo más cercano a lo que un humano puede reflejar en su cara.

Biblioteca Axarquia.Webicina: Practicar la medicina con las Herramientas 2.0
Bertalan Mesko, autor del blog ScienceRoll, ha creado Webicina.com un portal que pretende ser una guía online de información médica. El principal objetivo es el de ayudar a médicos y a pacientes a encontrar información poniendo a su alcance herramientas 2.0.

Webicina ofrece servicios de consultoría, formación, etc., y ha recibido la acreditación HONCode que concede la Health On the Net Foundation, una organización no gubernamental establecida en 1995 bajo los auspicios del Ministerio de Salud en Ginebra y destinada a guiar a los usuarios de Internet hacia fuentes de información médica fiables y relevantes

APS, Medicina General

"El médico general presta atención medica primaria, personal y continua a individuos y familias. Puede atender a los pacientes en sus domicilios, en la consulta y, ocasionalmente, en el hospital. El médico general acepta la responsabilidad de tomar las decisiones iniciales en todos los problemas que se le presenten, requiriendo la opinion de los especialistas cuando lo juzge conveniente. Habitualmente trabaja con otros médicos generales en lugares apropiados y específicos, con la ayuda de personal auxiliar y del equipamiento necesario. Incluso si trabaja en solitario organizará un pequeño equipo, para poder delegar funciones. El médico general tiene en cuenta los aspectos psiquicos, psicológicos y sociales en los diagnósticos y establece planes educativos, preventivos y terapeuticos para mejorar la salud de sus pacientes." New Leeuwenhorst Group.