Declaración de Autor
Página 1 de 169
Agradecimientos
Página 2 de 169
Tabla de contenido
Declaración de Autor..................................................................................................................... 1
Agradecimientos ........................................................................................................................... 2
Glosario ......................................................................................................................................... 5
Resumen........................................................................................................................................ 6
INTRODUCCIÓN ............................................................................................................................. 8
DESCRIPCIÓN DEL SISTEMA........................................................................................................... 9
PLANTEAMIENTO DEL PROBLEMA .............................................................................................. 11
JUSTIFICACIÓN ............................................................................................................................ 12
OBJETIVOS ................................................................................................................................... 18
CONTEXTO ................................................................................................................................... 19
Redes centralizadas .................................................................................................................... 30
Redes en Arbol ........................................................................................................................... 30
Graficos ....................................................................................................................................... 31
Ejemplos ...................................................................................................................................... 31
ARQUITECTURA 3G ...................................................................................................................... 31
METODOLOGIAS DE DESARROLLO DE SOFTWARE:..................................................................... 50
DESARROLLO DEL PROYECTO: ..................................................................................................... 58
Requisitos funcionales................................................................................................................. 79
Resultados y Discusión .............................................................................................................. 169
Conclusiones ............................................................................................................................. 170
Referencias Bibliográficas (Existe hay que arreglar) ................................................................. 171
Anexos ....................................................................................................................................... 172
Página 3 de 169
Glosario
Resumen
En este documento se pretende mostrar el análisis, diseño y desarrollo, del prototipo
de telemedicina móvil para asistencia médica domiciliaria y remota, planteado como
proyecto de grado.
El prototipo de telemedicina desarrollado DoC busca la implementación del estándar
HL7 message el cual permite el intercambio de información médica entre diferentes
aplicaciones. En este proyecto se contemplaron dos aplicaciones, un servidor web el
cual se identificará como DoCWeb y una aplicación para teléfonos móviles que se
identificará como DoCMobile. DoCWeb permite la administración de entidades
relacionadas con la salud, manejo de personal médico, afiliación de pacientes y
asignación de citas. Por otra parte DoCMobile una aplicación para celulares con
soporte Java permite el acceso y la actualización de información médica de los
pacientes que se encuentran registrados en el servidor web.
DoCWeb es un sistema que permite la administración de las entidades que se
involucran en el manejo de la información médica (EPS e IPS), a su vez DoCWeb
permite la creación de usuarios que administran dichas entidades, de tal manera que
se pueden generar vínculos entre las EPS y las IPS, contratación de personal médico
y afiliación de pacientes a las diferentes EPS, también se permite la asignación de
citas para los pacientes por parte de las diferentes IPS que tengan contratos con la
EPS a la cual el paciente está afiliado. DoCWeb además almacena la Historia clínica
del paciente, el documento único para el almacenamiento de la información médica de
una persona, permite el acceso de las historias clínicas únicamente a las entidades
que tengan relación con el paciente, cuando un paciente cambia o se retira de una
EPS el sistema cambia los permisos de consulta sobre la historia clínica, garantizando
así un acceso restringido a la misma por parte de terceros.
DoCMobile permite realizar atención de consulta médica básica, procedimientos
médicos generales y clasificaciones de emergencia (TRIAGE) a los pacientes que se
encuentren registrados en el DoCWeb. Por ser una aplicación para un teléfono móvil
permite realizar consultas de información médica (como alergias y antecedentes
familiares) en cualquier momento y desde cualquier ubicación con cobertura de la red
celular. DoCMobile también hace uso de los periféricos del celular: el micrófono y la
cámara, para adjuntar archivos multimedia como soporte a los procedimientos
realizados a un paciente. Se permite además la solicitud de ordenes de servicio para
los pacientes: exámenes médicos, remisiones a especialistas, incapacidades y
formulas medicas. Por último los médicos que usan DoCMobile pueden consultar las
diferentes citas que tienen asignadas, con el nombre del paciente, y la dirección del
mismo si la consulta es del tipo domiciliaria.
El sistema en general hace uso de diferentes estándares médicos implementados en
el país: CIE-10 para la clasificación de diferentes patologías, CUPS para la
clasificación de procedimientos médicos y el listado de medicamentos que cubre el
plan obligatorio de salud POS. Se implementa conjuntamente el estándar de
mensajería internacional HL7 para el intercambio de información médica, este
intercambio se realiza entre DoCWeb y DocMobile.
Como elemento adicional DoCWeb contiene un portal médico en el cual los médicos
que se encuentran dentro del sistema pueden publicar y consultar casos clínicos de
interés, dentro de este marco se implementa adicionalmente el estándar para la
presentación de documentos clínicos de HL7 CDA (Clinical Document Architecture),
este estándar permite el traspaso de información médica entre entidades que se
encuentren fuera del sistema. En particular se presenta una aplicación sencilla que
permite consultar de manera fácil y legible mediante un navegador web la información
clínica de un paciente anónimo.
El prototipo DoC pretende mostrar las diversas ventajas que tiene el uso de distintas
tecnologías en la telemedicina: SOAP, Python, servicios web, apache, Django, Java
ME, Postgres, XML, Https, Linux y redes 3G. Estas tecnologías integradas de manera
adecuada permiten la creación de sistemas robustos, confiables y seguros.
Para finalizar, el prototipo se diseño y se desarrolló siguiendo una metodología ágil
conocida como FDD (feature driven development) que consiste en un desarrollo
basado por características del software, enfocado en las fases de diseño y
construcción en pro de la calidad, este metodología implica un monitoreo constante del
proyecto durante sus diferentes fases.
INTRODUCCIÓN
En Colombia, para Junio de 2007, existían 28 millones de usuarios de
tecnología móvil, lo que indica una cobertura cerca del 60% de la población. "El
hecho de que en menos de tres años haya crecido de 10 millones a 28 millones
el número de usuarios es un logro que ubicó a nuestro país entre los de más
rápida adopción de esta tecnología en el mundo".
No es raro el hecho que la tecnología móvil haya tenido gran acogida dentro de
la población Colombiana, debido a que se encuentra al alcance económico de
casi cualquier persona y a que los dispositivos móviles que existen actualmente
superan a los computadores portátiles y de escritorio de hace 10 años en todos
sus aspectos, además de brindar ventajas como la movilidad, la
georeferenciacion, e integración de dispositivos como la cámara, reloj, agenda
y reproductores de audio y video.
Teniendo en cuenta las ventajas de la tecnología móvil, se pretenden
aprovechar a favor de la telemedicina, acortando distancias y reduciendo
tiempos para beneficio de la población, ya que actualmente no existe cobertura
total en el servicio de la salud, especialmente en zonas rurales. Los centros
médicos se encuentran en las grandes ciudades y algunas cabeceras
municipales, por tanto no toda la población tiene acceso a la medicina
especializada, y muchos usuarios que si tienen acceso no logran acceder a
estos centros médicos por la naturaleza de su enfermedad.
En vista de la problemática planteada se pretende crear un prototipo de
telemedicina móvil para asistencia médica domiciliaria y remota a través de
web services y tecnologías móviles, que abarque desde un acceso a historias
clínicas y antecedentes vía web y móvil hasta la prestación de una asesoría
remota entre médicos.
DESCRIPCIÓN DEL SISTEMA
DoC es un prototipo de Sistema de información para el manejo de información
médica a nivel de consultas, citas, alarmas, remisiones, valoraciones Triage e
historias clínicas, desde dispositivos móviles (Celulares / PDAs) haciendo uso
de los estándares internacionales para el intercambio de información médica
(HL7), además de servir para el manejo de pacientes, personal medico y los
usuarios administradores del sistema.
Arquitectura
El software está construido con una arquitectura de tres capas y dos niveles, es
decir; presentación, lógica del negocio, datos que residen en dos ordenadores
presentación+lógica, lógica+datos.
Fuente: http://pabloacastillo.files.wordpress.com/2008/02/022208-1757-
creandounaa25.png
Parte de la lógica y toda la interfaz gráfica es efectuada por la maquina cliente
que en este caso es de dos tipos, web y móvil, a nivel web se efectúan algunos
servicios como la administración de citas, la administración de pacientes, y la
administración de casos anónimos, mientras que en la parte móvil se trabajan
los servicios de manejo de consultas, historia clínica y eventos.
En el backend o capa de datos, se trabaja otra parte de la lógica y todo la
administración de datos y repositorios (aunque se maneja un "cache") en los
dispositivos móviles debido a la naturaleza de estos, para garantizar la
sincronía y la valides de los datos, a continuación explicaremos cada una de
las 3 partes que conforman esta arquitectura de dos niveles.
Nivel Superior Móvil - Presentación y Lógica
Esta capa está desarrollada en Java ME, para ser usada en dispositivos
móviles, utiliza las librerías LWUIT, Perst, floggy, JSR 172.
Tiene los servicios de:
Consultar la agenda medica
Consultar la información básica del paciente
Consultar y insertar información pertinente a la historia clínica de un
paciente, esta información es desde texto plano hasta fotografías y
archivos de audio.
Dar una evaluación TRIAGE in situ, para emergencias.
Enviar toda la información medica a través de mensajes HL7,
pudiéndose comunicar con otros sistemas que soporten este estándar.
Nivel Superior Web - Presentación y Lógica
Esta capa está desarrollada en XHTML + JavaScript para la parte de
presentación y en python / Django para la parte de la lógica, gracias a la
interfaz administrativa de Django permite un fácil manejo de toda la información
de datos.
Tiene los servicios de:
Administrar usuarios (creación / eliminación /cambio de datos)
Administrar pacientes (Afiliar/desactivar)
Administrar Agendas ( Horarios de citas para el Personal Medico)
Consultar Casos Anónimos
Crear entidades Administradoras y entidades prestadoras además de
sus respectivas sedes.
Nivel Inferior - Lógica y Datos
Esta parte está desarrollada en Python / Django para la parte de la lógica y
Postgresql para la parte de los datos.
En esta capa no hay funciones a nivel de interacción con el usuario, sin
embargo es la encargada de la consistencia de los datos, según los modelos
planteados.
Comunicación
La comunicación entre el nivel superior tanto Móvil como Web y el nivel inferior
se hace a través de servicios web SOAP, para algunos de los servicios en
especial desde el dispositivo móvil, que es el que interactúa directamente con
la información medica se usa el estándar de intercambio de mensajes HL7.
PLANTEAMIENTO DEL PROBLEMA
Teniendo en cuenta la incursión que la tecnología ha realizado en áreas como
la salud, y la aplicación de la telemedicina como herramienta tecnológica en
favor del bienestar humano a nivel mundial; se hace necesario expandir este
tipo de tecnologías y servicios para la comunidad.
El uso de teléfonos móviles en particular está creciendo de gran forma
alrededor del mundo, ofreciendo la oportunidad a servicios y aplicaciones en el
área de los servicios y la salud, de saltar a estos frentes tecnológicos. Como
enfatiza el presidente de las Naciones Unidas Timothy E. Wirth, el poder de
estas tecnologías para mejorar la condición humana no puede ser
desestimado: “Modern telecommunications, and the creative use of it, has the
power to change lives and help…. solve some of the world’s biggest
challenges.”1
Sin embargo en Colombia la telemedicina no es muy difundida por su
desconocimiento, aun conociendo los beneficios que presta a la comunidad.
¿De qué manera se puede aportar desde el punto de vista de la ingeniería de
sistemas, para que estas tecnologías sean más difundidas en el país?
En Colombia la atención médica especializada y la mayoría de centros
hospitalarios se concentran en las zonas urbanas, generando falta de
cobertura en servicios de salud y dificultando el acceso de las personas
residentes en áreas rurales y cabeceras municipales. Teniendo en cuenta que
el 25% de la población se encuentra ubicada en dichas áreas, se cuestiona
¿se podría utilizar la telemedicina como herramienta para permitir el acceso de
servicios de salud a este porcentaje de la población?
De igual manera, en muchas ocasiones los procesos de salud que implican
atención inmediata, se ven limitados por la falta de eficiencia, información y
comunicación entre el personal médico. Ejemplos claros de esta problemática
se evidencian en situaciones como emergencias que implican el uso de
ambulancias, en casos de personas cuya enfermedad impide su traslado físico
al centro de atención, o cuando se imposibilita el acceso por parte de un
especialista al paciente. ¿Cómo se podría hacer más eficiente la atención en
estos procesos?
1
http://ehealth-connection.org/content/mhealth-and-mobile-telemedicine-overview [12 Feb
2009]
JUSTIFICACIÓN
El termino telemedicina(telemedicine) está siendo reemplazado por el termino
telesalud(eHealth) pues dejo de ser una herramienta para proveer directamente
los servicios medicos para tambien convertirse en un garantizador del correcto
uso de la informacion electronica y el manejo de las TICs, para proveer,
soportar y, por supuesto, garantizar, el adecuado cuidado de la salud cuando
hay distancia entre el paciente y el servicio, ademas tambien de servir de
herramienta de capacitacion para todos los involucrados en este ambito
(Pacientes, Profesionales, Administradores, etc).
A raiz de la explosion de las tecnologias móviles hace unos pocos años se
acuño un nuevo termino mHealth o m-Health que refiere a la medicina basada
en la ubicuidad, en usar las movilidad a favor de la medicina y llevarla a donde
esta es requerida.
Un pionero notable en la aceptación amplia de la telemedicina se encuentra en
el Centro de telemedicina de la Universidad de Carolina del Este
(http://www.telemed.med.ecu.edu). Su programa de telemedicina emplea un
arreglo de tecnologías interactivas de audio y video para proporcionar servicios
de cuidado de la saluda poblaciones rurales en el este de Carolina del Norte.
Desde 1992 el Centro ha participado en 7,500 consultas a distancia en más de
35 especialidades médicas, así como más de 10,000 actividades en educación
continua a médicos y educación a distancia. El Centro incluye un núcleo de
comunicaciones que realiza las conexiones entre los puntos necesarios y otros
recursos médicos globales usando POTS, ISDN, T-1, Microondas, Satélites y
tecnologías sobre IP"1
Aceptación
Casos
2
En Trujillo-España, una zona rural del país se instalo un sistema de
telemedicina en el cual el paciente habla por videoconferencia con el
especialista y le comenta sus síntomas, mientras que este pregunta al
paciente, además se envía la información recogida por el personal de la salud
de la institución. Este sistema ha tenido gran acogida entre los usuarios.
Citas Año
450 2005
576 2006
700 2007
Esta gran aceptación ya ha generado listas de espera entre los pacientes,
siendo las áreas mas solicitadas las de neumología, dermatología y
endicronologia, mientras que las menos solicitada es la de gerontología. Juan
2
http://www.hoy.es/20071213/trujillo/aceptacion-consultas-telemedicina-provoca-
20071213.html [25 de Agosto 2008]
Jose Gimenez, Responsable del área de telemedicina del hospital de trujillo
afirma que un 95% de los usuarios aceptan con satisfaccion este servicio. Para
poder acceder a este servicio se debe ser remitido por el medico de familia o el
medico general, quien puede escoger el servicio de telemedicina o desplazarse
hasta la capital del estado, lo que provoca un acercamiento de los especialistas
a las zonas rurales sin desplazar a los enfermos; mediante este servicio el
hospital beneficia alrededor de 20.000 personas entre los pobladores de trujillo
y los pobladores de las poblaciones cercanas.
La disponibilidad de una infraestructura eficiente y moderna de
telecomunicaciones acentua el crecimiento real de las aplicaciones de
telemedicina, como la tele-educacion entre otros. Debido a los limites de
infraestructura, los paises en desarrollo optan por almacenar el concepto de
telemedicina. Sin embargo, algunos programas de telemedicina en paises en
desarrollo con conectividad son bastante comparables con algunos del mundo
desarrollado. La telemedicina esta ganando campo en los paises en desarrollo
e incluso muchas clínicas en estos paises han empezado a practicar la
telemedicina fuera de sus necesidades profesionales. En una forma muy simple
se estan logrando los objetivos de la telemedicina al intercambiar informacion
clinica y comentarios a traves de emails. Algunos paises en desarrollo como
India, Nepal y Bangladesh, etc se han abierto a la telemedicina para lograr
algunos objetivos propuestos por sus sistemas de salud.3
En Julio de 1999, el Swinfen Charitable Trust en el Reino Unido establecio un
link de Telemedicina en Bangladesh, entre el Centro para la rehabilitacion de
los paralisados (CRP) en Dhaka y los consultantes medicos del Lugar. Este
sistema de Telemedicina de Bajo Costo usaba una camara digital para capturar
fotografias, que eran transmitidas por email. Durante los primeros 12 meses
fueron efectuadas 27 consultas de telemedicina. Las siguientes especializades
fueron las consultadas neurologia (44%), ortopedia (40%), rheumatologia(8%),
nefrologia(4%) y pediatria (4%). Las respuestas iniciales por email fueron
recibidas en el CRP con un dia de tardanza en el 70% de los casos y en tres
dias en el resto. Lo que demuestra que la telemedicina de almacenar y enviar
puede ser tanto agil con confiable. Las consultas de Telemedicina estuvieron
completas luego de tres dias en 14 casos (52%) y en tres semanas en 24
casos (89%), de los cuales se juszgo que fue util en el 89% de los casos, los
beneficios incluyeron el establecimiento del diagnostico, el reaseguramiento del
paciente y la remision a especialista y el cambio de procedimientos. Cuatro
pacientes (15% del total) y sus familias se ahorraron los considerablemente
altos costos y el stress innecesario de viajar a otro lugar por una segunda
3
Sood SP, Bhatia JS. Development of telemedicine technology in India: ''Sanjeevani''-An
integrated telemedicine application. J Postgrad Med 2005;51:308-11(
http://www.jpgmonline.com/text.asp?2005/51/4/308/19245 [26 de Agosto 2008])
opinion, y los ahorros de solo estas familias superaron los costos de
implementacion y ejecucion el Bangladesh. Este ultimo esta limitado a una
cuenta de correo con un ISP(Internet Service Provider) y el costo de las
llamadas locales del CRP. Este sistema exitoso de Telemedicina es un modelo
para futuros proyectos en los paises en desarrollo.4
En otro estudio hecho en 1999 en Australia, cuatro centros medicos escogieron
un grupo de 31 pacientes a quienes les fue preguntado que midieran su presion
sanguinea dos veces por semana y que enviaran el resultado de sus
mediciones, tambien si efectuaban algun cambien en la medicacion y los
posibles efectos secundarios. La informacion recopilada fue transferida a un
computador clinico, y los reportes fueron generados para cada medico de cada
paciente. Aquellos que no enviaban la mediciones a tiempo eran contactados
telefonicamente para que efectuaran el procedimiento. los 31 pacientes
tuvieron en promedio 1.5 visitas al medico durante el año de estudio lo que
significa una reduccion de lo usual en el tipo de pacientes escogidos (2.7 visitas
al año). De acuerdo con este estudio la prescripcion de los doctores pueden
tambien ser influenciada por la evidencia de la toma de presion por cada
paciente.5
4
D J Vassallo, F Hoque, M F Roberts, V Patterson, P Swinfen, R Swinfen , An evaluation of the
first year's experience with a low-cost telemedicine link in Bangladesh. J Telemed Telecare. 2001 ;7
(3):125-38 11346472 (http://lib.bioinfo.pl/pmid:11346472 [27 de Agosto 2008])
5
E Andrew Balas, Ilias Iakovidis. Distance technologies for patient monitoring. BMJ. 1999
November 13; 319(7220): 1309.
(http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=1129085#B21 [27 de Agosto de 2008])
HIPÓTESIS
Alcances
A partir de un estudio previo de ingenieria donde se pretende crear un modelo
general del prototipo de sistema de informacion, un modelo de datos para la
administracion y persistencia de la informacion, y una interfaz entendible para
las usuarios finales, el desarrollo de este proyecto pretende brindar un apoyo al
servicio medico en lo concerniente a la atencion domiciliaria y la asistencia
medica remota y orientado a:
Medicos generales: Sirviendoles de apoyo y soporte para la consulta y
modificacion de la informacion de un paciente, sus datos basicos, su
historia, sus antecedentes; ademas de servirles de plataforma para
remitir casos que estan fuera de su alcanze a medicos especilistas,
ordenar formulas medicas, dar incapacidades, y solicitar examenes
paraclinicos, tambien se les aportara al permitirles el uso de
herramientas mediaticas en la recoleccion de la informacion (Audio,
Fotografias).
Estudiantes y practicantes de medicina: podran realizar consultas de
casos complicados con otros colegas. tambien podran realizar analisis
medicos y dar sus comentarios a los casos publicados por otros
medicos.
paramedicos y enfermeros: podran obtener informacion de un paciente
en tiempo real al momento de atender una emergencia, y hacer un
diagnostico previo del estado en el que se encuentra el paciente
mientras es trasladado, de forma que al arribar al centro de salud, el
personal que atendiera la emergencia, se encuentre preparado
adecuadamente para recibirlo.
Ademas, se pretende servir como modelo de referencia para la creacion de
nuevos desarrollos orientados al area de la telemedicina, brindando a la
comunidad una base documental acerca de el manejo de la informacion medica
para la construccion de proyectos de software. Esta base documental tendra
informacion acerca de sistemas medicos, manejo de informacion del paciente
(basica, historia, antecedentes), estandarizacion internacional para la
intercomunicacion de sistemas medicos, entre otros.
El proyecto consiste en la construccion de un prototipo de sistema de
informacion medica que abarca el manejo de:
Interconsulta entre medicos, permitiendo que se puedan compartir casos
para recibir apoyo de una comunidad completa de medicos.
Acceso a historias clínicas, antecedentes, y procedimientos medicos
para escritura y/o lectura
Manejo de visitas medicas, horarios y disponibilades de los medicos
ademas de permitirles manejar sus agendas creando unicamente las
horas donde estos podran atender y el lugar donde se efectuara si es
una institucion o la direccion donde hara la visita
Solicitud de servicios tales como examenes medicos, remision a
especialistas, peticion de un medicamentos disponibles en el POS y el
registro de dicha informacion en la historia clinica del paciente.
Atención domiciliaria medico general dandole soporte a la forma
tradicional de llevar historias clinicas, respetando la informacion basica
que debe contener toda historia clinica, y soportada por el uso del
estandar HL7
creacion de procedimientos medicos y evaluacion TRIAGE, para
atencion de emergencia.
El desarrollo web se realizara mediante el framework django que permite una
integracion facil a base de datos y la creacion de formularios web dinamicos
con una facil integracion de JavaScript, ademas de ser uno de los frameworks
de desarrollo web de menor curva de aprendizaje y de mas facil uso, todo el
prototipo a nivel de servidor ira montado sobre la base de datos Postgres. A
nivel de programacion movil se utilizara J2ME con CLDC 1.1 y MIDP 2.0 que es
la herramienta mas popular y con mayor documentacion en el mercado para el
area de dispositivos moviles ademas de tener librerias especiales muy utiles en
este caso como son JSR75 para el manejo de archivos, JSR 172 para el
acceso a web services y JSR 234 para el manejo de las herramientas
multimedia, tambien se usara LWUIT para garantizar la mayor covertura
posible en dispositivos moviles a través, la conexion sera mediante HTTP,
HTTPS, SOAP y usando el estandar HL7 message.
Limitaciones
Para el desarrollo de este proyecto, se han encontrado diversas dificultades,
tanto tecnologicas como academicas; entre las cuales podemos identificar la
falta de información en el área de medicina y la falta de recursos fisicos, como
equipos moviles para desarrollo y pruebas.
El proyecto se desarrollará bajo herramientas de libre distribución, y
versiones académicas que faciliten el desarrollo del sistema.
el uso de contenido multimedia solo abarca audio y fotografias, la
grabacion de videos se preeve implementar en una futuras versiones.
en la implementacion del estandar HL7 solo se tendran encuenta los
apartados referentes a CDA, y HL7 message
el proyecto no dispone de un cliente fijo y estable encargado de revisar y
retroalimentar cada una de las iteraciones hechas durante las fase de
desarrollo.
no se preveen cambios en el diseño y la codificacion de cada una de las
iteraciones, puesto que no contamos con el cliente encargado de
retroalimentar las mismas.
el prototipo se desarrollara para un correcto funcionamiento en los
siguientes telefonos celulares: nokia 5310, y nokia E71, debido a la falta
de recursos economicos del proyecto
el prototipo solo contempla el formulario para el llenado de la historia
clinica en consulta general.
el prototipo en sus alcances solo sera capaz de generar la informacion
necesaria para asignar un servicio a un determinado paciente, el
seguimiento y el control de cada uno de los diferentes tipos de servicios
no se implementara en el prototipo.
solo sera posible usar versiones reducidas de los estandares CIE-10 ,
CUPS (cups nivel II unicamente), y POS (solo medicamentos estandar,
no se incluiran los medicamentos de los programas especiales) debido a
limitaciones fisicas y de procesamiento en los telefonos celulares.
OBJETIVOS
Analizar, diseñar e implementar un prototipo de sistema de informacion en
telemedicina con tecnologias moviles para la asistencia medica domiciliaria y
remota, implementando el estandar hl7, servicios web.
Objetivos específicos
Establecer los requerimientos de información médicos necesarios en el
ámbito del desarrollo del prototipo de sistema de información.
Generar una base documental concerniente al área de la salud, la
telemedicina, el estándar HL7, la ingenieria de software, y acerca de
herramientas tecnicas útiles para el desarrollo del proyecto planteado.
Establecer los requerimientos funcionales y no funcionales para el
desarrollo del prototipo de sistema de información.
Analizar la utilidad de la tecnología móvil en otros campos con el fin de
comprobar la aplicabilidad en la telemedicina.
Analizar el impacto positivo que puede tener la tecnología móvil en la
telemedicina para atención prioritaria, inmediata y de buena calidad. con
base a países que ya han implementado esta tecnología.
Analizar las aplicaciones existentes de telemedicina para observar su
aceptación por parte del usuario.
Diseñar la arquitectura del prototipo con base a los requerimientos
anteriormente establecidos.
Diseñar el modelo de base de datos y el modelo de persistencia de la
información.
Diseñar la arquitectura de la red de comunicación del prototipo.
Diseñar la interfaz de la aplicación acorde al análisis previo.
Diseñar e implementar la base de datos del sistema prototipo.
Generar una base documental que contenta la informacion concerniente
a la investigacion hecha durante el desarrollo del prototipo.
Desarrollar los módulos web y móvil del prototipo de sistema de
información.
Integrar los módulos desarrollados y efectuar pruebas de software.
CONTEXTO
MANEJO DE LA INFORMACION CLINICA EN TELEMEDICINA :
1. Historia Clínica
Es un documento privado con características: legales, éticas, docentes,
estadísticas, médicas o clínicas. Los datos deben ser consignados en términos
adecuados y en forma lógica y ordenada o secuencial.
Es una narración escrita, clara, precisa, detallada y ordenada de todos los
datos y conocimientos, remotas y actuales, personales y familiares, relativos al
paciente, que sirven como base para el conocimiento de la enfermedad.
Está compuesta por dos partes fundamentales:
I. ANAMNESIS
Anamnesis próxima: Es el conjunto de datos o la información que aporta el
interrogatorio. Es la forma en que se inicia la relación profesional – enfermo.
Consta de tres partes:
Identificación del paciente:
En esta parte se identifica al paciente en cuanto a su nombre y edad.
Cabe la posibilidad de agregar más información como teléfono de su
casa, a quién contactar en caso de necesidad, qué previsión tiene, o qué
actividad desarrolla.
Más adelante, en la sección de Antecedentes, existe una subdivisión de
Antecedentes Sociales y Personales, en la que es posible extenderse
sobre aspectos que permiten conocer mejor al paciente como persona.
De acuerdo a lo anterior, al momento de comenzar a escribir la historia
clínica, se anota:
1. Fecha y hora.
2. Nombre completo del paciente.
3. Edad.
4. Eventualmente, se agrega:
5. Teléfono o dirección.
6. A quién avisar en caso de necesidad.
7. Actividad que desempeña.
En pacientes que no son capaces de aportar su historia, conviene
señalar la fuente de dónde provino la información (p.ej.: la mamá, algún
familiar con el que vive, un testigo).
Problema principal o motivo de consulta:
Esta sección es sólo una mención muy corta del motivo por el que
consulta el paciente.
Enfermedad actual:
Es en esta sección dónde se precisa la enfermedad que está cursando el
paciente al momento de consultar.
II. ANAMNESIS REMOTA
Se preguntan los aspectos individuales y familiares pasados del paciente.
Se divide en tres antecedentes personales, antecedentes familiares y revisión
por sistemas.
Antecedentes.
En esta parte se mencionan distintos antecedentes ordenados según su
naturalea.
Estas secciones son:
Antecedentes personales (médicos, quirúrgicos, traumatismos).
Antecedentes ginecoobstétricos.
Hábitos.
Antecedentes sobre uso de medicamentos.
Alergias.
Antecedentes sociales y personales.
Antecedentes familiares.
Inmunizaciones.
Revisión por sistemas.
Una breve revisión por los sistemas que todavía no se han explorado da
más seguridad que la información está completa. Una forma de ordenar
esta revisión es ordenándola por sistemas y en cada uno de ellos se
investigan manifestaciones que podrían darse: sentidos, respiratorio,
cardiovascular, gastrointestinal o digestivo, sistema endocrino, neurológico.
Además de revisar estos sistemas, es conveniente investigar
manifestaciones en otras partes o de otro tipo: en la piel, sangramientos,
dolores en otros sitios, compromiso de la visión o de la audición, etcétera.
EXAMEN FÍSICO
Conciencia y estado mental:
Genitourinario
Pulso arterial.
Respiración.
Temperatura.
Presión arterial.
III. IMPRESIONES DIAGNÓSTICAS
Se dará una o varios diagnósticos basados en los hallazgos encontrados en el
examen físico y sustentados por la anamnesis. Se anotan los nombres de las
enfermedades sistémicas y orales.
IV. EXAMENES COMPLEMENTARIOS
Son aquellas pruebas que solicitamos para confirmar un diagnóstico (biopsias,
fotografías, modelos de estudio, interconsultas y exámenes de laboratorio).
V. DIAGNÓSTICOS DEFINITIVOS
Es el nombre de las posibles enfermedades o patologías del paciente.
VI. PLAN DE TRATAMIENTO
Se consignarán todas las etapas del tratamiento. Se realizará de forma
ordenada y lógica. Se debe contemplar el tratamiento ideal y el tratamiento real
para que el paciente escoja de acuerdo a sus condiciones socio-económicas el
plan que más se acomode a sus necesidades y capacidades.
VII. EVOLUCIÓN
Se debe anotar paso a paso cada uno de los procedimientos efectuados y sus
posibles complicaciones, la medicación ordenada, los materiales utilizados, la
técnica anestésica utilizada, la hora de la atención, duración del procedimiento,
el estado en que se recibe el paciente y como se va el paciente.
VIII. EPICRISIS
Es el resumen de los aspectos más relevantes de la atención que se ha
brindado al paciente. Se debe anotar: identificación, motivo de consulta, historia
de la enfermedad actual y aspectos más sobresalientes de la evolución de la
enfermedad. Se utiliza para realizar interconsultas o remitir al paciente.
2. HL7
El Health Level 7 (HL7) es una especificación para un estándar de intercambio
de datos electrónicos en el sector de los cuidados de la salud, especialmente
enfocado hacia las comunicaciones intrahospitalarias.
En terminos generales, HL7 es un estandar de envio de mensajes que le
permite a las aplicaciones clinicas intercambiar informacion. En el mundo actual
del e-mail, FTP, Bluetooth, y descargas de alta velocidad, puede parecer
passe, si no innecesario. En el cuidado de la salud "cada usuario y
configuracion es un mundo unico", sin embargo, ese tipo de intercambio de
informacion puede ser un reto.
Historia
En 1987, en un intento por empezar a resolver este problema, una comunidad
internacional de expertos en el area de salud y cientificos de informacion
colaboraron para crear el estandar HL7 para el intercambio, administracion e
integracion de la informacion electronica acerca de la salud, de acuerdo al Web
site del HL7 (www.hl7.org/about).
Significado
HL7 es la sigla de Health Level Seven Inc. La palabra “Health” (Salud) hace
relación al área de trabajo de la organización y las palabras “Level Seven”
(Nivel Siete) hacen referencia al último nivel del modelo de comunicaciones
para interconexión de sistemas abiertos (OSI Open Systems Interconnection)
de la Organización Internacional de Estandarización (ISO Internacional
Organization for Standarization).
El “Nivel Siete” dentro del modelo es el nivel aplicación, que se ocupa de la
definición y la estructura de los datos que van a ser intercambiados.
Estándares
Mensajería HL7 Versión 2: Estándar de mensajería para el intercambio
electrónico de datos de salud.
Mensajería HL7 Versión 3: Estándar de mensajería para el intercambio
electrónico de datos de salud basada en el RIM (Reference Information
Model).
CDA HL7: (Clinical Document Architecture) Estándar de arquitectura de
documentos clínicos electrónicos.
SPL HL7: (Structured Product Labeling) Estándar electrónico de
etiquetado de medicamentos.
HL7 Medical Records: Estándar de administración de Registros Médicos.
GELLO: Estándar para la expresión de reglas de soporte de decisiones
clínicas.
Arden Sintax: Es estándar sintáctico (if then) para compartir reglas de
conocimiento clínico.
CCOW: Es un estándar framework para compartir contexto entre
aplicaciones.
3. CDA
El CDA (arquitectura de documentos clinicos) es un estadar de marcas basado
en XML que pretende especificar, la codificacion, semantica y estructura de los
documentos clinicos para el intercambio.
CDA es parte de la version 3 del estandar HL7. Similar a otras partes de la
version 3 del estandar hl7 fue desarrollado usando el framework de desarrollo
de hl7 (HDF) y esta basado en el modelo de referencia de informacion del HL7,
y los tipos de dato de la version 3 del HL7. Los documentos CDA son
persistentes por naturaleza.
El CDA especifica que el contenido del documento consisten de una parte
textual obligatoria (que asegura la interpretacion humana de los contenidos del
documento) y de partes estructuradas opcionales (para el procesamiento del
software). Las partes estructuradas dependen de sistemas de codificacion para
representar conceptos
Requerimientos
Un documento clínico contiene observaciones y servicios, y tiene las siguientes
caracteristicas:
Persistencia: Un documento clinico continua existiendo inalterado por
una cantidad de tiempo definida por los requerimientos y regulaciones
locales.
Direccion: Un documento clinico es mantenido por una organizacion
encargada de su cuidado
Potencial de Autenticacion: Un documento clinico es un ensamblaje de
informacion que esta destinada para ser legalmente autenticada
Contexto: Un documento clinico establece un contexto por defecto para
sus contenidos
Plenitud: La autenticacion de un documento clinico aplica en su
totalidad y no aplica a porciones de este sin el contexto completo del
documento
Legibilidad humana: Un documento clinico es leido por personas
Un documento CDA es un objeto completo de información que puede incluir
textos, imagenes, sonidos y otros contenidos multimedia.
Objetivos
Dar prioridad a la atencion del paciente
Permitir implementaciones efectivas en costo sobre el mayor espectro
de sistemas posible
Soportar el intercambio de documentos legibles, incluyendo aquellos con
diferentes niveles tecnicos o de sofisticacion
Promover la longevidad de toda la informacion codificada de acuerdo
con esta arquitectura
Habilitar un amplio rango de aplicaciones de procesamiento post-
intercambio
Ser compatible con un amplio rango de aplicaciones de creacion de
documentos
Promover el intercambio independiente de los mecanismos de
almacenamiento o de transporte
Preparar el diseño razonablemente rapido
Permitir la creacion de politicas para el control de sus propios
requerimientos de informacion sin extenderse a esta especificacion
Principios
Esta arquitectura debe ser compatible con XML y con el HL7 RIM
La barreras tecnicas para el uso de la arquitectura deben ser las
minimas
La arquitectura define los esquemas requeridos para el intercambio
La arquitectura debe imponer la menor cantidad de restricciones o
requerimientos en la estructura del documento y el contenido requerido
para el intercambio
La arquitectura debe ser escalable para acomodarse marcas granulares
tales como el texto altamente estructurado y la informacion codificada
Especificaciones de documentos basadas en esta arquitectura deben
acomodar tantas restricciones o requerimientos como son suplidos por el
profesional apropiado, y las agencias comerciales o reguladoras.
Especificaciones de documentos para la creacion y procesamiento de
documentos, si pretenden el intercambio, deben mapearse a esta
arquitectura.
Los documentos CDA deben ser legibles usando browsers que permitan
XML, e impresion de controladores y una hoja generida de estilos CDA
escrita en un lenguaje de hojas de estilo estandar.
Usar estandares abiertos
Estructura
Header - Esto contiene la informacion descriptiva clave acerca del documento
(metadata) como quien lo escribio, a quien va dirijido y que tipo de documento
es
Body - Esto contiene el texto del documento que puede estar estructurado al
menos bajo cabezeras claves o seciones. Es posible para el texto contener
valores codificados. Tambien es posible no tener informacion en texto como
una imagen de rayos x (usando la representacion DICOM estandar).
4. RESOLUCION NÚMERO 1995 DE 1999 6
En esta resolución se describen las normas correspondientes al
diligenciamiento, administración, conservación, custodia y confidencialidad de
las historias clínicas. Dada su importancia en la prestación de los servicios de
atención en salud y para el desarrollo científico y cultural del sector.
Esta norma es de obligatorio cumplimiento para todos los prestadores de
servicios de salud incluyendo personas naturales o jurídicas que se relacionen
también con la atención en salud.
Normas relevantes:
Se resumen los aspectos más relevantes para el proyecto
Todo procedimiento realizado deberá quedar debidamente diligenciado y
registrado.
Todo prestador de servicios de salud que atiende por primera vez a un usuario
debe realizar el proceso de apertura de historia clínica.
Es obligatorio para los prestadores de servicio de salud tener un archivo único
de historias clínicas, el prestador de servicio de salud también puede otorgarle
una copia al usuario o a su representante legal cuando el paciente lo solicite.
Los traslados de historias clínicas entre prestadores de servicios de salud
deben quedar registrados en actas.
Podrán acceder a la información contenida en la historia clínica: el usuario, el
equipo de salud, las autoridades judiciales y de salud en los casos previstos en
la ley y las demás personas determinadas en la ley.
Las instituciones prestadoras de servicios de salud y en general los
prestadores encargados de la custodia de la historia clínica, deben velar por la
conservación de la misma y responder por su adecuado cuidado.
Los programas automatizados que se diseñen y utilicen para el manejo de las
Historias Clínicas, así como sus equipos y soportes documentales, deben estar
provistos de mecanismos de seguridad, que imposibiliten la incorporación de
modificaciones a la Historia Clínica una vez se registren y guarden los datos.
En todo caso debe protegerse la reserva de la historia clínica mediante
mecanismos que impidan el acceso de personal no autorizado para conocerla y
6
http://www.comvezcol.org/archivos/pdf/resolucion_1995_1999.pdf
adoptar las medidas tendientes a evitar la destrucción de los registros en forma
accidental o provocada.
Los prestadores de servicios de salud deben permitir la identificación del
personal responsable de los datos consignados, mediante códigos, indicadores
u otros medios que reemplacen la firma y sello de las historias en medios
físicos, de forma que se establezca con exactitud quien realizó los registros, la
hora y fecha del registro.
5. CIE10
La lista de códigos CIE-10 es la décima versión de la Clasificación Estadística
Internacional de Enfermedades y otros Problemas de Salud; del inglés ICD
(International Statistical Classification of Diseases and Related Health
Problems), provee los códigos para clasificar las enfermedades y una amplia
variedad de signos, síntomas, hallazgos anormales, denuncias, circunstancias
sociales y causas externas de daños y/o enfermedad.
Antecedentes
La Organización Mundial de la Salud (OMS) viene coordinando la revisión
periódica de la Clasificación Internacional de Enfermedades (CIE) desde 1948.
Como resultado de un proceso iniciado en 1983, los tres volúmenes de las
versiones en inglés y francés de la Décima y más reciente Revisión de la CIE
se publicaron entre en 1992 y 1994. La traducción a otros idiomas fue
preparada por centros colaboradores de la OMS y otras instituciones en todo
el mundo. En particular, la versión en español fue publicada por la
Organización Panamericana de la Salud (OPS) en 1995.
Antes de la 10ª Revisión, no se publicaban actualizaciones entre las revisiones,
que ocurrían en ciclos de diez años. Es así que en 1900, se introdujo la CIE-1,
la primera revisión de la clasificación original de 1893 de Bertillon, en 1910 la
CIE-2, y así sucesivamente hasta la CIE-9, publicada en 1979. Por solicitud de
varios países, la introducción de la CIE-10 se retrasó hasta 1994, cuando
empezó a usarse en unos países de Europa. Desde 1995 está
implementándose gradualmente en el resto del mundo.
Debe observarse que no se esperan muchos otros cambios en la revisión
actual de la CIE-10 en los próximos años, según van disminuyendo la
detección de errores e inexactitudes con el uso regular de la Clasificación, la
organización panamericana de la salud (OPS) ya ha publicado la Edición 2003
(actual) de la CIE-10 en español.
Estructura básica del CIE. 10ª Revisión
El CIE es un sistema de clasificación de ejes variables cuyo esquema debe
servir a todos los propósitos prácticos y epidemiológicos. Este patrón puede ser
identificado en los capítulos del CIE y hasta el momento es considerado como
la estructura más útil que cualquiera de las alternativas que se han probado.
El CIE utiliza un código alfanumérico, con una letra en la 1° posición y
números en la 2°,3°, y 4° posición; el cuarto carácter sigue a un punto decimal,
los códigos posibles van por lo tanto de A00.0 a Z99.9., y esta compuesta por
cerca de once mil registros.
Implementación en el dispositivo móvil del CIE-10
Para efectos de implementación en del estándar CIE-10 en teléfonos celulares
se usara una versión general del CIE-10 la cual solo maneja los tres primeros
caracteres del código, y va de A00 a Z99. Esta versión tiene un aproximado de
dos mil registros.
Esto con el fin de ahorrar costos de procesamiento y de almacenamiento en el
teléfono celular.
6. CUPS
La CLASIFICACIÓN ÚNICA DE PROCEDIMIENTOS EN SALUD (C.U.P.S.)
corresponde a un ordenamiento lógico y detallado de los procedimientos e
intervenciones que se realizan en Colombia, identificados por un código y
descritos por una nomenclatura validada por los expertos del país,
independientemente de la profesión o disciplina del sector salud que los realice
así como del ámbito de realización de los mismos.
La utilización adecuada de ésta clasificación será de gran ayuda para
estandarizar los datos que consolidan el Sistema Integral de Información,
proveer un lenguaje homogéneo entre los diferentes integrantes del Sistema
General de Seguridad Social en Salud -SGSSS-, facilitando tanto la definición
de Planes de Beneficios y sus alcances como el monitoreo del desempeño del
sector bajo parámetros de comparabilidad. La Clasificación Única de
Procedimientos en Salud adaptación para Colombia, se adopta por resolución
365 de 1999. Su primera publicación se presenta en un solo volumen que
contiene la Lista Tabular y el Índice Alfabético. A partir de dicha resolución se
realizó la primera actualización de la CUPS (1°A-CUPS) adoptada mediante la
resolución 2333 de 2000.
Estructura del código
Los niveles jerárquicos que constituyen la estructura del código, de seis
caracteres, para cada procedimiento o intervención, permiten ubicar con
exactitud un procedimiento según el nivel jerárquico, tanto en forma general
como detallada de manera sistemática y concatenada. Estos niveles se
aprecian en el siguiente esquema:
XX
X
X
XX
GRUPO
SUBGRUPO
CATEGORIA
SUBCATEGORIA
GRUPO: representado por los dos primeros caracteres; según el capítulo en el
cual se encuentra ubicado señala:
1. El sitio o región anatómica específico(a), para los Capítulos 01 al 14
2. La unidad de producción específica, para los Capítulos 15 al 24
3. El proceso en la colectividad, para el Capítulo 25
4. El área en del conocimiento, para el Capítulo 26
5. El tipo de proceso, para el Capítulo 27
SUBGRUPO: definido por el tercer carácter; según el grupo en el cual se
encuentra ubicado, indica:
1. Tipo de procedimiento, para los Grupos 01 al 86
2. Tipo de imagen, para los Grupos 87 y 88
3. Tipo de área técnica, para los Grupos 90 y 91
4. Tipo de acción para los Grupos 89, 92 al 99
5. Tipo de estrategia para los Grupos A1 al A5
6. Tipo de fase en la atención para los grupos T1 Y T2
7. Tipo de nivel institucional o territorial para el grupo T9
CATEGORIA: identificado por el cuarto carácter; indica en forma genérica o
global la nomenclatura del procedimiento o intervención. Se exceptúan los
subgrupos T10 al T21 donde el nivel de categoría identifica el tipo de riesgo.
SUBCATEGORÍA: señalado por los dos últimos caracteres; define con mayor
precisión y detalle el procedimiento genérico de acuerdo a variables como:
especificidad de la región operatoria o diagnóstica, técnica, tecnología,
extensión, disciplina del conocimiento, agente etiopatogénico, tipo de muestra
entre otras.
Esta lista tabular presenta un ANEXO que organiza los Servicios en la Atención
de Salud [Hospitalarios] en forma análoga a la descrita. Contiene cinco grupos
con sus correspondientes niveles jerárquicos (subgrupos, categorías y
subcategorías) identificados por caracteres alfanuméricos:
• S0: Ambulatoria
• S1: Internación [Hospitalización]
• S2: Tipos de Sala
• S3: Traslado de Pacientes (ambulancia)
• S4: Servicios de apoyo en la atención de salud
Con este anexo es posible identificar los procedimientos en el correspondiente
servicio donde se realicen, articulando de ésta manera el proceso de atención
en salud, funcional y operativamente.
7. TRIAGE 7
El TRIAGE es el proceso mediante el cual un paciente es valorado a su llegada
para determinar la urgencia del problema y asignar el recurso de salud
apropiado para el cuidado del problema identificado; el paciente es clasificado
de acuerdo con prioridades.
Ofrece una valoración del paciente desde su llegada a urgencias para
determinar, en forma objetiva, el manejo inmediato o la espera de un turno para
la consulta médica; la tranquilidad que ofrece al paciente y la familia entrar en
contacto con un representante del equipo de salud que le explique sobre su
condición clínica es un gran beneficio de este proceso.
Para el equipo de salud, el sistema de TRIAGE representa la organización del
trabajo diario de manera confiable, siempre y cuando ofrezca consistencia
entre el resultado del TRIAGE y el diagnóstico final; así mismo, permite la
utilización racional del recurso humano y técnico.
Tipos de TRIAGE
Existen cinco tipos de TRIAGE según la persona que lo realiza:
TRIAGE no profesional: es realizado por una recepcionista o técnico quien
registra el paciente y lo envía a la sala de espera.
TRIAGE básico: es realizado por una enfermera profesional quien valora el
paciente, determina las necesidades prioritarias y le asigna un área de
tratamiento.
TRIAGE avanzado: es realizado por una enfermera profesional e incluye la
valoración inicial del paciente, la solicitud de algunos procedimientos
diagnósticos, un examen físico limitado en caso necesario, documentación y
referencia a la valoración médica.
TRIAGE médico: es realizado por un médico; esta función algunas veces se
mezcla con el tratamiento definitivo.
TRIAGE en equipo: la enfermera y el médico funcionan como un equipo.
Valoración del Paciente
La clase de prioridad o calificación de la urgencia puede ser hecha mediante la
combinación de los elementos de la valoración: la interpretación subjetiva o
motivo de consulta del paciente y el examen clínico objetivo.
Escala de prioridad
Existen varias formas de clasificar a un paciente según su emergencia, la
utilizada por la Fundación Santafé consta de 3 valores:
7
http://encolombia.com/medicina/enfermeria/enfermeria5102-triage.htm
Prioridad I: paciente que presenta una situación que amenaza la vida o riesgo
de pérdida de una extremidad u órgano, si no recibe una atención médica
inmediata; también se incluye en esta categoría el dolor intenso.
Prioridad II: paciente con estabilidad ventilatoria, hemodinámica y neurológica
cuyo problema representa un riesgo de inestabilidad o complicación.
Prioridad III: paciente con estabilidad ventilatoria, hemodinámica y neurológica
sin riesgo evidente de inestabilidad o complicación.
MODELO DE COMUNICACION Y CONECTIVIDAD:
1. Arquitectura de red
La topología de red o forma lógica de red se define como la cadena de
comunicación que los nodos que conforman una red usan para comunicarse.
Un ejemplo claro de esto es la topología de árbol, la cual es llamada así por su
apariencia estética, la cual puede comenzar con la inserción del servicio de
internet desde el proveedor, pasando por el router, luego por un switch y este
deriva a otro switch u otro router o sencillamente a los hosts (estaciones de
trabajo, pc o como quieran llamarle), el resultado de esto es una red con
apariencia de árbol porque desde el primer router que se tiene se ramifica la
distribución de internet dando lugar a la creación de nuevas redes y/o subredes
tanto internas como externas. Además de la topología estética, se puede dar
una topología lógica a la red y eso dependerá de lo que se necesite en el
momento.
En algunos casos se puede usar la palabra arquitectura en un sentido relajado
para hablar a la vez de la disposición física del cableado y de cómo el protocolo
considera dicho cableado. Así, en un anillo con una MAU podemos decir que
tenemos una topología en anillo, o de que se trata de un anillo con topología en
estrella.
Redes centralizadas
La topología en estrella reduce la posibilidad de fallo de red conectando todos
los nodos a un nodo central. Cuando se aplica a una red basada en la
topología estrella este concentrador central reenvía todas las transmisiones
recibidas de cualquier nodo periférico a todos los nodos periféricos de la red,
algunas veces incluso al nodo que lo envió. Todos los nodos periféricos se
pueden comunicar con los demás transmitiendo o recibiendo del nodo central
solamente. Un fallo en la línea de conexión de cualquier nodo con el nodo
central provocaría el aislamiento de ese nodo respecto a los demás, pero el
resto de sistemas permanecería intacto. El tipo de concentrador hub se utiliza
en esta topología.
La desventaja radica en la carga que recae sobre el nodo central. La cantidad
de tráfico que deberá soportar es grande y aumentará conforme vayamos
agregando más nodos periféricos, lo que la hace poco recomendable para
redes de gran tamaño. Además, un fallo en el nodo central puede dejar
inoperante a toda la red. Esto último conlleva también una mayor vulnerabilidad
de la red, en su conjunto, ante ataques.
Si el nodo central es pasivo, el nodo origen debe ser capaz de tolerar un eco de
su transmisión. Una red en estrella activa tiene un nodo central activo que
normalmente tiene los medios para prevenir problemas relacionados con el
eco.
Redes en Arbol
Una topología en árbol (también conocida como topología jerárquica) puede ser
vista como una colección de redes en estrella ordenadas en una jerarquía. Éste
árbol tiene nodos periféricos individuales (por ejemplo hojas) que requieren
transmitir a y recibir de otro nodo solamente y no necesitan actuar como
repetidores o regeneradores. Al contrario que en las redes en estrella, la
función del nodo central se puede distribuir.
Como en las redes en estrella convencionales, los nodos individuales pueden
quedar aislados de la red por un fallo puntual en la ruta de conexión del nodo.
Si falla un enlace que conecta con un nodo hoja, ese nodo hoja queda aislado;
si falla un enlace con un nodo que no sea hoja, la sección entera queda aislada
del resto.
Para aliviar la cantidad de tráfico de red que se necesita para retransmitir todo
a todos los nodos, se desarrollaron nodos centrales más avanzados que
permiten mantener un listado de las identidades de los diferentes sistemas
conectados a la red. Éstos switches de red “aprenderían” cómo es la estructura
de la red transmitiendo paquetes de datos a todos los nodos y luego
observando de dónde vienen los paquetes respuesta.
Graficos
Los diagramas de red ilustran las relaciones entre los computadores, los
dispositivos periferiqos y los sistemas de computacion.
Ejemplos
ARQUITECTURA 3G
Fuente: http://www.umtsworld.com/technology/images/UMTSnetwork.jpg
Arquitectura de e-Health
Fuente: http://2.bp.blogspot.com/_mAJDMuyu_WI/R-V9mhw0mhI/AAAAAAAAAZw/pq85fSaGOAY/s1600-h/TelemedicineBWA.jpg
2. HL7 messages
HL7 ha definido varios estándares, entre ellos los estándares de Mensajería (ej.
HL7 v2.x y v3.0). Los estándares de mensajería son particularmente
importantes porque definen como va a ser la información empaquetada y
comunicada de un lugar a otro. Estos estándares definen el lenguaje,
estructura y tipos de datos requeridos para una integracion sin fisuras de un
sistema a otro.8
Mensajeria V2.x
La version 2 del HL7 define una serie de mensajes electronicos como soporte
administrativo, logistico, financiero como tambien para los procesos clinicos.
Desde 1987 el estandar ha sido actualizado regularmente, resultando en las
versiones 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, y 2.6. Las que en conjunto son
conocidas como la version 2.x. Los estandares de la v2.x son compatibles con
las versiones anteriores.9
HL7 v2.x usa principalmente un sistema propietario de codificacion basado en
delimitadores; HL7 v2.x ha permitido la interoperabilidad entre sistemas de
administracion de pacientes (PAS), Sistemas de Administracion Electronico de
Pacientes(EPM), sistemas de Informacion de Laboratorio (LIS), sistemas de
Farmacia, Nutricion, como tambien sistemas de Historia Clinica Electronica
(EMR). Actualmente, HL7 v2.x es soportado por todos los grandes sistemas de
informacion medicos en Estados Unidos10
8
http://www.hl7.com.au/FAQ.htm [27 de Agosto 2008]
9
http://aspe.hhs.gov/sp/nhii/standards.html#HL7 [27 de Agosto de 2008]
10
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_ad
Elementos de informacion de un Mensaje HL7
Tipo del Mensaje
El tipo en un mensaje HL7 es un identificador único para el propósito de
negocio de un mensaje. Cada mensaje debe contener un identificador de tipo
de mensaje como una forma de anunciar el propósito del mensaje. Por
ejemplo, ADT es un identificador único de mensaje para Administración de
Paciente. Sin embargo, en vez de ser una clasificación única en la estructura
de un mensaje, un tipo de mensaje puede tener mas de una estructura de
mensaje. El tipo de mensaje es anunciado en el segmento de cabecera del
mensaje.
Evento del Mensaje
El evento del mensaje, algunas veces también llamado disparador, es un
identificador único al contexto en el cual el mensaje es generado. El evento del
mensaje consiste de una letra en mayúscula y dos dígitos. Por ejemplo, A01 es
para notificación de admisión/visita y A61 es para cambio de doctor de
consulta. Ambos A01 y A61 son usados con mensajes ADT. El evento del
mensaje es anunciado en el segmento de cabecera del mensaje.
Estructura del Mensaje
La estructura del mensaje es una estructura de datos usada para expresar una
asociación de un tipo de mensaje con un evento para una clase de mensajes.
Cada estructura del mensaje contiene también un identificador único.
Estructuralmente consiste de una bien definida lista de segmentos HL7. Los
segmentos pueden ser opcionales, y pueden repetirse. No hay limite en
cuantas veces un segmento puede repetirse. Los segmentos pueden ser
agregados juntos para formar un grupo de segmento, el cual puede repetirse
también. En la especificación del estándar, el grupo de segmentos es indicado
por {} o por [], donde {} significa repeticion y [] significa opcional.[4]
Segmento
Un segmento es un agrupamiento lógico de campos de datos. Los segmentos
de un mensaje pueden ser requeridos o opcionales. Ellos pueden existir
únicamente una vez en un mensaje o pueden estar repetidos. Un nombre y un
código único de tres caracteres conocido como Identificador de segmento
identifican cada segmento. Los segmentos son enviados dentro de los
mensajes, a la vez que el identificador de segmento es seguido por una
secuencia de campos de datos. El ultimo campo termina con el carácter de fin
de segmento, un cambio de linea.
apters.doc/doc/healthcare/hl7mst73.htm [27 de Agosto]
Campos de Datos
Los campos de datos son transmitidos como cadenas de caracteres separadas
por caracteres que son los separadores de campos (el carácter '|' por ejemplo).
Cada campo de datos tiene asignado un tipo de datos.
Componentes
Muchos de los tipos de datos son compuestos - hechos de componentes.(Los
caracteres '^' son los separadores de componentes usuales).
3. SOAP
SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que
define cómo dos objetos en diferentes procesos pueden comunicarse por
medio de intercambio de datos XML. Este protocolo deriva de un protocolo
creado por David Winer en 1998, llamado XML-RPC. SOAP fue creado por
Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno
de los protocolos utilizados en los servicios Web.
SOAP es importante para el desarrollo de aplicaciones por permitir la
comunicación a través de internet de diversos programas.
Las aplicaciones de hoy se comunican usando llamadas remotas de
procedimientos (RPC) entre objetos como DCOM y CORBA, pero HTTP no fue
diseñado para esto. Ademas RPC representa un problema de compatibilidad y
de seguridad; los servidores firewall y proxy normalmente bloquean este tipo de
trafico
Una mejor forma de comunicarse entre aplicaciones es atraves de HTTP, por
que HTTP esta soportada por todos los browsers y servidores de Internet.
SOAP fue creado para esto.
SOAP provee una forma de comunicacion entre aplicaciones corriendo en
diferentes sistemas operativos con diferentes tecnologias y diferentes lenguajes
de programacion.
Partes de un Mensaje SOAP
Un mensaje SOAP es un documento XML comun y corriente que contiene los
siguientes elementos:
Una envoltura () que identifica el documento XML
como un mensaje SOAP
Una cabecera () que contiene informacion de cabecera
Una cuerpo () que contiene informacion de llamada y
respuesta
Una infraccion () que contiene los errores y la informacion
de estado
4. Web Services
Un servicio web (en inglés Web service) es un conjunto de protocolos y
estándares que sirven para intercambiar datos entre aplicaciones. Distintas
aplicaciones de software desarrolladas en lenguajes de programación
diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los
servicios web para intercambiar datos en redes de ordenadores como Internet.
La interoperabilidad se consigue mediante la adopción de estándares abiertos.
Las organizaciones OASIS y W3C son los comités responsables de la
arquitectura y reglamentación de los servicios Web. Para mejorar la
interoperabilidad entre distintas implementaciones de servicios Web se ha
creado el organismo WS-I, encargado de desarrollar diversos perfiles para
definir de manera más exhaustiva estos estándares.
Arquitectura
Ejemplo de Arquitectura de WebServices
Fuente: http://en.wikipedia.org/wiki/File:Webservices.png
Pila de protocolos para Servicios Web
La Pila de protocolos para Servicios Web es una colección de protocolos para
redes de Computadores que son utilizados para definir, localizar, implementar y
hacer que un Servicio Web interactúe con otro. La Pila de Protocolos para
servicios esta comprendida principalmente por cuatro áreas:
1. Servicio de Transporte: responsable del transporte de mensajes entre
las Aplicaciones de red y los protocolos en los cuales se incluyen
protocolos tales como HTTP, SMTP, FTP, así como también el más
reciente Blocks Extensible Exchange Protocol (BEEP).
2. Mensajeria XML: responsable por la codificación de mensajes en un
formato común XML así que ellos puedan ser entendidos en cualquier
extremo de una conexión de red. Actualmente, esta área incluye
protocolos tales como XML-RPC, SOAP y REST.
3. Descripción del Servicio: usado para describir la interfaz pública de un
Servicio Web especifico. El formato de interfaz Web Services Description
Language - WSDL es típicamente usado para este propósito.
4. Descubrimiento de servicios: centraliza servicios en un registro común
tal que los servicios Web de la red puedan publicar su localización y
descripción, y hace que sea fácil descubrir que servicios están
disponibles en la red.
Actualmente, la API Universal Description Discovery and Integration - UDDI se
utiliza normalmente para el descubrimiento de servicios.
Ventajas
Aportan interoperabilidad entre aplicaciones de software
independientemente de sus propiedades o de las plataformas sobre las
que se instalen.
Los servicios Web fomentan los estándares y protocolos basados en
texto, que hacen más fácil acceder a su contenido y entender su
funcionamiento.
Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los
sistemas de seguridad firewall sin necesidad de cambiar las reglas de
filtrado.
Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan ser combinados fácilmente para
proveer servicios integrados.
Permiten la interoperabilidad entre plataformas de distintos fabricantes
por medio de protocolos estándar y abiertos. Las especificaciones son
gestionadas por una organización abierta, la W3C, por tanto no hay
secretismos por intereses particulares de fabricantes concretos y se
garantiza la plena interoperabilidad entre aplicaciones.
CONTEXTO TECNOLOGICO:
1. Java ME
Java ME (Java Platform, Micro Edition) es una versión de Java que está
enfocada a los dispositivos de bajo procesamiento y baja capacidad de
memoria, como los teléfonos celulares, PDAs o electrométricos inteligentes.
Java ME incluye interfaces de usuario flexibles, seguridad robusta, protocolos
de conexión internos y soporte para aplicaciones on/off-line que puedan ser
descargadas dinámicamente, además de que estas sean portables entre una
gran gama de dispositivos.
Componentes
Java Me tiene unos componentes básicos que la diferencian de las otras
versiones:
Maquinas virtuales
Es el software encargado de interpretar los bytecodes, efectúa las
llamadas necesarias a los servicios del S.O del dispositivo, gestiona el
cumplimiento de las reglas de seguridad y corrección de código del
lenguaje Java, es independencia del S.O. y hardware del dispositivo.
Con diferentes requisitos, para cada uno de los diferentes tipos de
dispositivos. (CVM. KVM)
Configuraciones
Son un conjunto de clases básicas orientadas a conformar el core de las
implementaciones para dispositivos de características especificas. Como
tal existen 2 configuraciones definidas en Java Me:
Connected Limited Device Configuration (CLDC)
Orientada a dispositivos dotados de conexión y con limitaciones en
cuanto a capacidad gráfica, cómputo y memoria. Por ejemplo: teléfonos
móviles, buscapersonas (pagers), PDAs, organizadores personales.
Para dispositivos con procesador de 16 ó 32 bits (al menos, 25 MHz),
entre 160 Kb y 512 Kb de memoria total disponible mínimo, 128 KB de
memoria no volátil para VM y bibliotecas CLDC y 32 KB de memoria
volátil para VM en tiempo de ejecución, de bajo consumo, conexión a
red, normalmente sin cable, con conexión intermitente y ancho de banda
limitado (unos 9600 bps). Usa la configuración KVM.
Connected Device Configuration (CDC)
Orientada a dispositivos con cierta capacidad computacional y de
memoria como decodificadores de TV digital, set-top boxes, sistemas de
navegación en automóviles y algunos electrodomésticos.
Para dispositivos con un procesador de 32 bits, 2 MB o más de memoria
total (incluyendo RAM y ROM), funcionalidad completa de la VM de
Java2, conectividad a algún tipo de red. Esta configuración usa la CVM.
Perfiles
El perfil es un grupo más específico de APIs, desde el punto de vista del
dispositivo. Es decir, la configuración se ajusta a una familia de
dispositivos, y el perfil se orienta hacia un grupo determinado de
dispositivos dentro de dicha familia. El perfil, añade funcionalidades
adicionales a las proporcionadas por la configuración.
La especificación MIDP (Mobile Information Device Profile), describe un
dispositivo MIDP como un dispositivo, pequeño, de recursos limitados,
móvil y con una conexión “inalámbrica”.
Paquetes opcionales
Son bibliotecas que están enfocadas a una tecnología especifica, por
ejemplo: Bluetooth, LBS, GPS, Accelerometer, Multimedia.
En general un entorno de ejecución para Java Me se compone de estos
elementos
Java ME se ha convertido en la opción más popular para crear aplicaciones
para dispositivos móviles ya que estas pueden ser emuladas fácilmente en un
PC durante la etapa de desarrollo y fácilmente instaladas en los teléfonos
celulares contrastando con el resto de plataformas que requieren de hardware
o kits especiales.
Es la única opción real de código abierto para el desarrollo de aplicaciones
móviles en la industria, lo que asegura un crecimiento continuo a través de la
comunidad de desarrolladores, como también las empresas de celulares que
van creando cada vez mejores dispositivos y las compañías prestadoras de
servicio que cada vez adoptan mas las tecnologías java.
1.1. LWUIT 11
Lightweight UI Toolkit for Java ME
LWUIT es una librería grafica para Java Me basada en Swing que soluciona los
inconvenientes del desarrollo de una interfaz de usuario en Java Me. Esta
librería proporciona un nuevo conjunto de componentes visuales, y ofrece la
11
https://lwuit.dev.java.net/files/documents/8797/95067/file_95067.dat/LWUIT%20Developer_
Guide.pdf
posibilidad de incorporar animaciones, temas y transiciones en los programas
Java ME. Es una interfaz gráfica basada en componentes y MVC, muy similar a
Swing. Los controles son dibujados aprovechando las posibilidades que ofrece
cada móvil, incluyendo efectos 2D y 3D, con soporte propio de temas visuales.
Características:
Manejo de temas personalizados.
Efectos de transiciones entre pantallas
Manejo de Layouts.
Compresión de archivos.
Registros del Sistema.
Ventajas
Esta librería permite crear aplicaciones modernas, agradables, con mayor
usabilidad, al mismo tiempo que las hace fáciles de adaptarse a las
particularidades de cada dispositivo móvil, casi automáticamente.
Los temas son fáciles de intercambiar, y se incluye un editor de temas para
personalizarlos y poder crear temas propios.
Es portable ya que resulta muy fácil crear interfaces modernas y
sorprendentes, y al mismo tiempo unificarlas entre distintos móviles. LWUIT se
encarga de todos los detalles del dibujado y en el camino brinda muchas
herramientas y soluciones a problemas comunes.
Desventajas
La documentación formal es muy poca, aunque existe un tutorial de uso en la
pagina del proyecto no es suficiente.
Diseñada específicamente para MIDP 2.0 CLDC. Aun se está trabajando en
soporte CDC.
1.2. Perst Lite (BD móvil)
Esta es la solución que más se acerca a lo que se necesita (y puede soportar)
un teléfono móvil. Esta es una implementación en Código Abierto para J2ME
de una base de datos orientada a objetos.
Ventajas
Persistencia transparente y heredada.
Carga recursiva de objetos.
Relaciones uno a uno, uno a muchos, muchos a uno y muchos a
muchos.
Acceso secuencial y aleatorio mediante índices.
Implementación de algoritmos eficientes para estructuras, B+Tree, T-
Tree, R-Tree para búsquedas geoespaciales.
Posibilidad de búsquedas por valores exactos o rangos inclusivos o
exclusivos.
Implementación de índices espaciales para búsquedas en objetos
geoespaciales.
es open Source.
Desventajas
Open Source. Si antes era una ventaja, hay que tener en cuenta que es
una herramienta muy compleja, que no se tiene soporte técnico, y sobre
todo, que no se dispone de documentación técnica.
Su tamaño no es pequeño, así que habrá que sumergirse en el código
en busca de material y funcionalidades que no nos sea imprescindible.
Rendimiento
Para comprobar la efiencia en cuanto a tiempo de ejecución, fueron realizados
distintos test de prueba en las siguientes soluciones de persistencia movil:
PointBase Micro, SimpleOODBMS, Perst Lite. Las pruebas fueron iguales y se
busco probar las funciones más básicas de la forma más simple posible.
La siguiente figura muestra los tiempos que las tres implementaciones han
necesitado para insertar 100 registros en la base de datos. Todos los tiempos
son en milisegundos.
http://bertiente.files.wordpress.com/2007/09/db1.jpg
En cuanto a memoria consumida, los resultados son similares, como se
muestra en la siguiente figura.
http://bertiente.files.wordpress.com/2007/09/db2.jpg
2. DJANGO/Python
Django es un framework de desarrollo web de código abierto escrito en Python.
Inicialmente Django fue desarrollado para gestionar aplicaciones web de
páginas orientadas a noticias de World Online, más tarde se liberó bajo licencia
BSD. Django se centra en automatizar todo lo posible y se adhiere al principio
DRY (Don't Repeat Yourself).
Ventajas
Mapeador objeto-relacional: Definicion de modelos de datos
completamente en Python y accede a los datos mediante una potente
API de acceso dinámico a la base de datos.
Interfaz de administración automático: Ahórro de el tedioso trabajo de
crear interfaces para añadir o actualizar contenido. Django genera un
sistema de administración automáticamente listo para ser usado en
producción.
Diseño de URLs elegantes: Django permite diseñar bellas URLs sin
limitaciones específicas del framework. Sé tan flexible como quieras.
Sistema de plantillas: Utilizando el potente y extensible lenguaje de
plantillas de Django para separar diseño, contenido y código Python de
una forma amigable para diseñadores.
Sistema de cache: Utilizando memcached u otro framework de cache
para obtener un super-rendimiento - El cacheo es tan granular como se
necesite.
Internacionalización: Django soporta aplicaciones multilenguaje
permitiéndo especificar strings de traducción y proporciando
herramientas para funcionalidad específica del lenguaje.
Arquitectura
Aunque Django está fuertemente inspirado en la filosofía de desarrollo Modelo
Vista Controlador, sus desarrolladores declaran públicamente que no se
sienten especialmente atados a observar estrictamente ningún paradigma
particular, y en cambio prefieren hacer "lo que les parece correcto". Como
resultado, por ejemplo, lo que se llamaría "controlador" en un "verdadero"
framework MVC se llama en Django "vista", y lo que se llamaría "vista" se llama
"plantilla".
Si bien es cierto que se asemeja mucho a la implementación del patrón MVC,
para Django la Vista describe “qué” datos serán presentados y no “cómo” se
verán los mismos. Aquí es donde entran en juego los templates, que describen
“cómo los datos son presentados”.
Se dice que el “controller” de un MVC clásico está representado por el propio
framework. Es decir, el sistema que envía un request a la vista
correspondiente, de acuerdo a la configuración de URL de Django (archivo de
configuración).
En el caso de querer hacer una correspondencia, entonces diríamos que éste
es un framework “MTV”: modelo, template, vista.
Python
Python es considerado como la "oposición leal" a Perl, lenguaje con el cual
mantiene una rivalidad amistosa. Los usuarios de Python consideran a éste
mucho más limpio y elegante para programar.
Python permite dividir el programa en módulos reutilizables desde otros
programas Python. Viene con una gran colección de módulos estándar que se
pueden utilizar como base de los programas (o como ejemplos para empezar a
aprender Python). También hay módulos incluidos que proporcionan E/S de
ficheros, llamadas al sistema, sockets y hasta interfaces a GUI (interfaz gráfica
con el usuario) como Tk, GTK, Qt entre otros...
Python es un lenguaje de programación interpretado, lo que ahorra un tiempo
considerable en el desarrollo del programa, pues no es necesario compilar ni
enlazar. El intérprete se puede utilizar de modo interactivo, lo que facilita
experimentar con características del lenguaje, escribir programas desechables
o probar funciones durante el desarrollo del programa.
3. POSTGRES
PostgreSQL es un motor de bases de datos avanzado y de código abierto,
soporta querys complejos, incluyendo subselects, Integridad referencial
(Foreign Keys), Triggers, Vistas (Views), Integridad Transaccional (ACID),
Control de versionado concurrente (MVCC), y su licencia es de tipo BSD12.
Como muchos otros proyectos open source, el desarrollo de PostgreSQL no es
manejado por una sola compañía sino que es dirigido por una comunidad de
desarrolladores y organizaciones comerciales las cuales trabajan en su
desarrollo. Dicha comunidad es denominada el PGDG (PostgreSQL Global
Development Group).
Historia
PostgreSQL ha tenido una larga evolución, comenzando con el proyecto Ingres
en la Universidad de Berkeley. Este proyecto, liderado por Michael
Stonebraker, fue uno de los primeros intentos en implementar un motor de
base de datos relacional. Después de haber trabajado un largo tiempo en
Ingres y de haber tenido una experiencia comercial con el mismo, Michael
decidió volver a la Universidad para trabajar en un nuevo proyecto sobre la
experiencia de Ingres, dicho proyecto fue llamado post-ingres o simplemente
POSTGRES.
El proyecto post-ingres pretendía resolver los problemas con el modelo de base
de datos relacional que habían sido aclarados a comienzos de los años 1980.
El principal de estos problemas era la incapacidad del modelo relacional de
comprender "tipos", es decir, combinaciones de datos simples que conforman
una única unidad. Actualmente estos son llamados objetos. Se esforzaron en
12
http://es.wikipedia.org/wiki/BSD_license
introducir la menor cantidad posible de funcionalidades para completar el
soporte de tipos. Estas funcionalidades incluían la habilidad de definir tipos,
pero también la habilidad de describir relaciones - las cuales hasta ese
momento eran ampliamente utilizadas pero mantenidas completamente por el
usuario. En POSTGRES la base de datos «comprendía» las relaciones y podía
obtener información de tablas relacionadas utilizando reglas.
Ventajas13
Instalación ilimitada
Es frecuente que las bases de datos comerciales sean instaladas en más
servidores de lo que permite la licencia. Algunos proveedores comerciales
consideran a esto la principal fuente de incumplimiento de licencia. Con
PostgreSQL, nadie puede demandarlo por violar acuerdos de licencia, puesto
que no hay costo asociado a la licencia del software.
Esto tiene varias ventajas adicionales:
* Modelos de negocios más rentables con instalaciones a gran escala.
* No existe la posibilidad de ser auditado para verificar cumplimiento de
licencia en ningún momento.
* Flexibilidad para hacer investigación y desarrollo sin necesidad de
incurrir en costos adicionales de licenciamiento.
Ahorros considerables en costos de operación
Fue diseñada y creada para tener un mantenimiento y ajuste mucho menor
que los productos de los proveedores comerciales, conservando todas las
características, estabilidad y rendimiento.
Estabilidad y confiabilidad legendarias
En contraste a muchos sistemas de bases de datos comerciales, es
extremadamente común que compañías reporten que PostgreSQL nunca ha
presentado caídas en varios años de operación de alta actividad.
Extensible
El código fuente está disponible para todos sin costo. Si su equipo necesita
extender o personalizar PostgreSQL de alguna manera, pueden hacerlo con un
mínimo esfuerzo, sin costos adicionales. Esto es complementado por la
comunidad de profesionales y entusiastas de PostgreSQL alrededor del mundo
que también extienden PostgreSQL todos los días.
Multiplataforma
PostgreSQL está disponible en casi cualquier Unix (34 plataformas en la
última versión estable), y una versión nativa de Windows está actualmente en
estado beta de pruebas.
Diseñado para ambientes de alto volumen
PostgreSQL usa una estrategia de almacenamiento de filas llamada MVCC
para conseguir una mejor respuesta en ambientes de grandes volúmenes. Los
13
http://soporte.tiendalinux.com/portal/Portfolio/postgresql_ventajas_html
principales proveedores de sistemas de bases de datos comerciales usan
también esta tecnología, por las mismas razones.
Desventajas
Es el DBMS menos usado hoy en día, en comparación de Mysql Server o SQL
server de Microsoft
Si se utiliza el soporte local la velocidad se ve afectada sustancialmente, es
mejor solo utilizarlo si verdaderamente necesario.
4. HTTPS 14
Hypertext Transfer Protocol Secure
El protocolo seguro de transferencia de hipertexto es una combinación del
protocolo http y del protocolo de redes seguras. Ambos trabajan en la capa
más alta de TCP/IP, la capa de aplicación, el protocolo de seguridad opera en
una subcapa más baja, encriptando el mensaje http antes de trasmitirlo,
también se encarga de desencriptar cuando el mensaje llega.
El sistema HTTPS utiliza un cifrado basado en las Secure Socket Layers (SSL)
para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y
del navegador utilizado por el cliente) más apropiado para el tráfico de
información sensible que el protocolo http.
Las conexiones que usan HTTPS se utilizan comúnmente en el manejo de
transacciones bancarias, pagos web y sistemas que manejan información
importante.
Funcionamiento
Para crear un servidor web que acepte conexiones HTTPS, el administrador del
sitio debe crear un certificado de clave pública para el servidor. Este certificado
puede ser creado para servidores basados en Unix, con herramientas como
OpenSSL o SuSE. Este certificado debe estar firmado por una autoridad
certificadora. Esta autoridad certifica que el certificado es de quien dice que es.
El sistema puede ser usado para autenticar clientes y limitar el acceso al
servidor a usuarios autorizados. Para esto, el administrador del sitio crea un
certificado por cada usuario, un certificado que es cargado en su navegador.
Normalmente, este contiene el nombre y el correo electrónico del usuario
autorizado y es automáticamente verificado por el servidor en cada reconección
del usuario.
Desventajas
El nivel de protección depende de la correcta implementación por el navegador,
del software del servidor y de los algoritmos actuales de criptografía aceptados.
14
http://msdn2.microsoft.com/en-us/library/aa767735(VS.85).aspx
5. XML
Extensible Markup Language
XML es un metalenguaje muy sencillo en su diseño que permite estructurar y
realizar el intercambio de datos entre distintas aplicaciones. Se convirtió en un
estándar, ya que es extensible y puede ser utilizado por cualquier aplicación
independientemente de la plataforma.
XML es una versión reducida y adaptada de SGML cuya función es la de definir
la estructura de lenguajes específicos, es decir XML no es un lenguaje como
tal, XML ayuda a definir lenguajes para distintas aplicaciones, ejemplos de
estos son XHTML y SVG. XML es muy sencillo y simple lo que le da fortaleza
es la forma en que se complementa con otras tecnologías lo que la hace más
grande y con más posibilidades.
Estructura de un documento XML
Un documento XML está formado por el prólogo y por el cuerpo del documento.
Cabecera
Los documentos XML pueden empezar con unas líneas que describen la
versión XML, el tipo de documento y otras cosas. En general una cabecera
está compuesta por: Una declaración XML, una declaración de tipo de
documento, uno o más comentarios e instrucciones de procesamiento.
Cuerpo
El cuerpo no es opcional en un documento XML, el cuerpo debe contener un y
solo un elemento raíz:
Elementos: Los elementos XML pueden tener contenido (más
elementos, caracteres o ambos), o bien ser elementos vacíos.
Atributos: Los elementos pueden tener atributos, que son una manera
de incorporar características o propiedades a los elementos de un
documento. Deben ir entre comillas.
Entidades predefinidas: Entidades para representar caracteres
especiales para que, de esta forma, no sean interpretados como
marcado en el procesador XML.
Secciones CDATA: Es una construcción en XML para especificar datos
utilizando cualquier carácter sin que se interprete como marcado XML.
Solo se utiliza en los atributos.
Comentarios: Comentarios a modo informativo para el programador que
han de ser ignorados por el procesador.
Ventajas
Es extensible: Después de diseñado y puesto en producción, es posible
extender XML con la adición de nuevas etiquetas, de modo que se
pueda continuar utilizando sin complicación alguna.
El analizador es un componente estándar, no es necesario crear un
analizador específico para cada versión de lenguaje XML. Esto
posibilita el empleo de cualquiera de los analizadores disponibles.
Es gratuito: al elegir XML como base para algún proyecto se tiene
disposición una gran y creciente comunidad de herramientas e
ingenieros experimentados en la tecnología.
Si un tercero decide usar un documento creado en XML, es sencillo
entender su estructura y procesarla. Mejora la compatibilidad entre
aplicaciones.
Desventajas
Al ser un lenguaje de etiquetado XML y de texto, los documentos XML
son mucho mayores en tamaño que un archivo binario común, aunque
esto no represente un problema para los grandes niveles de
almacenamiento que se manejan hoy en día por los computadores y
servidores, si es un inconveniente para los dispositivos móviles y la
transmisión de los mismos por redes celulares.
Ejemplo de XML
Este XML describe un objeto “Libro”, que contiene un titulo y un capitulo, el
capitulo a su vez está compuesto por otro título y una sección, y en esta última
también existe otro título. Para archivos pequeños como este es fácil para una
persona comprender el contenido del XML, y también es fácil ver como se
podrían añadir más atributos a este libro, como la cantidad de páginas por
capitulo y el nombre del autor en el titulo.
6. Subversion-SVN
Es un sistema de control de versiones de código abierto, maneja archivos y
directorios a través del tiempo, usa un árbol de archivos en un repositorio
central. El repositorio es como un servidor de archivos normal, excepto porque
almacena todos los cambios hechos a sus archivos y directorios. Esto permite
recuperar versiones antiguas de los datos, o examinar el historial de cambios
de los mismos.
SVN puede acceder al repositorio a través de redes, lo que le permite ser
usado por personas que se encuentran en distintos equipos.
Características de Subversion
Versionado de directorios
Subversion implementa un sistema de archivos versionado “virtual ” que sigue
los cambios sobre árboles de directorios completos a través del tiempo. Ambos,
archivos y directorios, se encuentran bajo el control de versiones.
Verdadero historial de versiones
En subversión se puede crear, eliminar, copiar y renombrar archivos y
directorios, y cada archivo nuevo añadido comienza con un historial nuevo,
limpio y propio.
Envíos atómicos
Un conjunto cualquiera de modificaciones o bien entra por completo al
repositorio, o bien no lo hace en absoluto. Esto permite a los desarrolladores
construir y enviar los cambios como fragmentos lógicos e impide que ocurran
problemas cuando sólo una parte de los cambios enviados lo hace con éxito.
Versionado de metadatos
Cada archivo y directorio tiene un conjunto de propiedades (claves y sus
valores) asociado a él. Se puede crear y almacenar cualquier par arbitrario de
clave/valor que se desee. Las propiedades son versionadas a través del
tiempo, al igual que el contenido de los archivos.
Elección de las capas de red
Subversion puede ser servido mediante Apache, sobre WebDAV/DeltaV. Esto
permite que clientes WebDAV lo utilicen en forma transparente.
Cuando se usa integrado a Apache permite utilizar todas las opciones que este
servidor provee a la hora de autentificar archivos (SQL, LDAP, PAM, etc.).
Manipulación consistente de datos
Subversion expresa las diferencias del archivo usando un algoritmo de
diferenciación binario, que funciona idénticamente con ficheros de texto
(legibles para humanos) y ficheros binarios (ilegibles para humanos). Ambos
tipos de ficheros son almacenados igualmente comprimidos en el repositorio, y
las diferencias son transmitidas en ambas direcciones a través de la red.
Ramificación y etiquetado eficientes
La creación de ramas y etiquetas es una operación más eficiente; Tiene costo
de complejidad constante (O(1)).
Herramientas
Existen varias herramientas para usar Subversion, tanto programas
individuales como interfaces que lo integran en IDES.
TortoiseSVN. Provee integración con el explorador de Windows.
Subclipse. "Plugin" que integra Subversion al entorno Eclipse.
Subversive. "Plugin" alternativo para Eclipse.
Cervisia, RapidSVN son programas para interacción para linux
ViewVC. Interfaz web.
Para Mac, pueden emplearse SvnX, RapidSVN y Zigversion
KDESvn. Provee integración con el escritorio KDE, muy parecido en
aparencia/funcionamiento/características a TortoiseSVN
Easyeclipse, es un paquete basado en eclipse es una plataforma de
desarrollo, con algunos plugins de código abierto.
sventon Interfaz web
Versions Interfaz de escritorio para Mac OS X
7. Google code
Google Code es un sitio de Google para desarrolladores interesado en
desarrollo open source. El sitio contiene codigo open source y una lista de
servicios que soportan APIs publicos.
Es el espacio donde Google comparte con todos los usuarios parte del código
de programación que se utiliza dentro de la compañía. Este código se ofrece
con licencia libre, para que cualquier desarrollador pueda utilizarlo en sus
proyectos, o incluso modificarlo.
No se trata del código que clasifica las páginas web del potente buscador, sino
de parte de lo utilizado para crear las numerosas herramientas que ofrece
Google.
Por ejemplo, 'Google mMaim' es una herramienta que permite monitorizar y
analizar el funcionamiento de nuestro servidor de Base de Datos MySQL, y
'Google Goopy' es una colección de funciones de Python que suelen utilizar
frecuentemente los programadores de la compañía.
Partes
Noticias: Tiene ultimas noticias interesantes para desarrolladores.
Recursos: Herramientas y Recursos para desarrolladores.
Productos: Lista de Productos en los que se puede colaborar como
desarrollador o que pueden se pueden usar completamente.
Recursos
Alojamiento de proyectos, permitiendo el uso de SVN, seguimiento de Tareas y
documentos, Wiki, Descargas y otras herramientas utiles.
APIs de mas de 100 proyectos de google, snippets de codigo libres para ser
usadas.
Apoyo a estudiantes universitarios mediante el programa de summer of code, y
recientemente con el lanzamiento de google code university que pretende ser
un conjunto de herramientas que ayuden a los estudiantes con sus proyectos
de programacion
METODOLOGIAS DE DESARROLLO DE SOFTWARE :
1. FDD.
Feature Driven Development (Desarrollo Basado en Funcionalidades) es un
proceso ágil para el desarrollo de sistemas. Fue diseñado por Peter Coad, Eric
Lefebvre y Jeff DeLuca. En FDD no se hace énfasis en la obtención de los
requerimientos sino en como se realizan las fases de diseño y construcción
preocupándose por la calidad, por lo que incluye un monitoreo constante del
proyecto.
FDD Se basa en un proceso iterativo, con iteraciones cortas que producen un
software funcional que el cliente y la dirección de la empresa pueden ver y
monitorear. Define claramente entregas tangibles y formas de evaluación del
progreso del proyecto.
Etapas
El proceso FDD consiste de cinco pasos secuénciales durante los cuales se
diseña y se construye el sistema:
Desarrollo de un modelo global.
Construcción de una lista de funcionalidades.
Planeación por funcionalidad.
Diseño por funcionalidad.
Construcción por funcionalidad.
http://www.step-10.com/SoftwareProcess/FeatureDrivenDevelopment/images/fdd.jpg
Desarrollo de un modelo global
Como entrada a este proceso el cliente debe estar listo para comenzar con la
construcción del sistema. Además se debe tener una lista de requerimientos
especificada en alguna forma, hecha por los expertos del dominio.
Cuando comienza el proceso, los expertos del dominio están al tanto de la
visión, el contexto y los requerimientos del sistema a construir. Se divide el
dominio global en áreas que son analizadas detalladamente y los
desarrolladores construyen un diagrama de clases o de objetos por cada área.
A su vez se construye un modelo global del sistema.
Esta etapa termina con el desarrollo del diagrama de clases global del sistema,
una lista de funcionalidades o características, y un modelo global del sistema a
construir.
Construcción de una lista de funcionalidades
Una funcionalidad se define como un ítem útil a los ojos del cliente. Basado en
el modelo global obtenido en la etapa anterior, y en la lista de funcionalidades
informal, se procede a elabora una lista de funcionalidades que resuma la
funcionalidad general del sistema. Dicha lista debe ser elaborada por los
desarrolladores y es evaluada por el cliente. Se divide la lista en subconjuntos
según la afinidad y la dependencia de las funcionalidades. Luego la lista es
finalmente revisada por los usuarios y los responsables para su validación y
aprobación.
Planeación por funcionalidad
En este punto se procede a ordenar los conjuntos de funcionalidades conforme
a su prioridad y dependencia, y se asigna a los programadores jefes. También
se debe generar un cronograma donde se especifique la duración del diseño y
la construcción de cada una de las características.
Diseño por funcionalidades y Construcción por funcionalidades
En esta etapa se selecciona un conjunto de funcionalidades de la lista y se
procede a diseñar y construir la funcionalidad mediante un proceso iterativo.
Una iteración puede tomar de unos pocos días a un máximo de dos semanas.
El proceso iterativo incluye inspección de diseño, codificación, pruebas
unitarias, integración e inspección de código.
Para cada una de estas iteraciones en la fase de diseño se debe generar:
Diagrama de secuencia detallado
Diagrama de clases actualizado
Descripción de clases y métodos
Notas adicionales
En la fase de construcción:
Implementacion e inspeccion de metodos
Testing unitarios para cada metodo
Check in de las clases
Main Build del sistema y testing de integración.
Roles
Gerente de proyecto
Arquitecto en jefe
Gerente de desarrollo
Programador en Jefe
Experto del dominio
Gerente del dominio
Administrador de release
Language Guru
Ingeniero de construcción
Administrador del sistema
Tester
Deployer
Escritor Técnico
Diferencias entre RUP, FDD, y XP
Tamaño de los equipos:
RUP esta pensado para proyectos y equipos grandes, en cuanto a tamaño y
duración. FDD y XP se implementan mejor para proyectos cortos y equipos
más pequeños, siendo quizás FDD más escalable que XP.
Obtención de requisitos:
RUP y XP crean como base UseCases y UserStories, por lo contrario FDD no
define explícitamente esa parte del proyecto sobre la adquisición de requisitos.
Evaluación del estado del proyecto:
FDD es posiblemente el proceso más adecuado para definir métricas que
definan el estado del proyecto, puesto que al dividirlos en unidades pequeñas
es bastante sencillo hacer un seguimiento de las mismas. XP también define
esos componentes pequeños. RUP por su parte, es tan grande y complejo en
este sentido como en el resto, por lo que manejar el volumen de información
que puede generar requiere mucho tiempo.
Carga de trabajo:
XP es un proceso ligero, esto es, que los creadores del proceso han tenido
cuidado de no poner demasiadas tareas organizativas sobre los
desarrolladores. RUP es un proceso pesado, basado mucho en la
documentación, en la que no son deseables todos esos cambios volátiles. FDD
es por su parte un proceso intermedio, en el sentido de que genera más
documentación que XP pero menos que RUP.
Relación con el cliente:
Con RUP se presentarán al cliente los artefactos del final de una fase, en
contrapartida, la aseguración de la calidad en XP y FDD no se basa en
formalismos en la documentación, si no en controles propios y una
comunicación fluida con el cliente.
Conocimiento sobre la arquitectura:
En RUP se intentará reducir la complejidad del software a producir a través de
una planificación intensiva. En XP se conseguirá a través de la programación a
pares que ya en la creación del código se puedan evitar errores y malos
diseños. En FDD sin embargo se usan las sesiones de trabajo conjuntas en
fase de diseño para conseguir una arquitectura sencilla y sin errores.
Puntos debiles:
FDD presenta su talón de Aquiles en la necesidad de tener en el equipo
miembros con experiencia que marquen el camino a seguir desde el principio,
con la elaboración del modelo global, puesto que no es tan ágil como podría
serlo XP.
Para el desarrollo de software por medio de equipos pequeños (hasta unas
diez personas) es RUP definitivamente muy grande y prácticamente
inalcanzable. Se deben repartir 31 roles y generar más de 100 artefactos
distintos.
XP es un proceso muy orientado a la implementación. Lo que es muy poco
deseable en XP es el hecho de evitar cualquier tipo de documentación fuera del
código fuente (UML juega un papel prácticamente nulo, por ejemplo).
2. Metodología para la obtención de req.
El objetivo de la metodología es la definición de las tareas a realizar, los
productos a obtener y las técnicas a emplear durante la actividad de
recolección de requisitos de la fase de ingeniería de requisitos del desarrollo de
software.
En esta metodología se distinguen dos tipos de productos: los productos
entregables y los productos no entregables o internos. Los productos
entregables son aquellos que se entregan oficialmente al cliente como parte del
desarrollo en fechas previamente acordadas, mientras que los no entregables
son productos internos al desarrollo que no se entregan al cliente.
El único producto entregable definido en esta metodología es el Documento de
Requisitos del Sistema (DRS).
Tareas recomendadas
Las tareas recomendadas para obtener los productos descritos en esta
metodología son las siguientes
Tarea 1: Obtener información sobre el dominio del problema y el sistema
actual.
Antes de mantener las reuniones con los clientes y usuarios e identificar los
requisitos es fundamental conocer el dominio del problema y los contextos
organizacional y operacional, es decir, la situación actual.
Enfrentarse a un desarrollo sin conocer las características principales ni el
vocabulario propio de su dominio suele provocar que el producto final no sea el
esperado por clientes ni usuarios.
Tarea 2: Preparar y realizar las reuniones de elicitación/negociación.
Teniendo en cuenta la información recopilada en la tarea anterior, en esta tarea
se deben preparar y realizar las reuniones con los clientes y usuarios
participantes con objeto de obtener sus necesidades y resolver posibles
conflictos que se hayan detectado en iteraciones previas del proceso.
Esta tarea es especialmente crítica y ha de realizarse con especial cuidado, ya
que generalmente el equipo de desarrollo no conoce los detalles específicos de
la organización para la que se va a desarrollar el sistema y, por otra parte, los
clientes y posibles usuarios no saben qué necesita saber el equipo de
desarrollo para llevar a cabo su labor.
Tarea 3: Identificar/revisar los objetivos del sistema.
A partir de la información obtenida en la tarea anterior, en esta tarea se deben
identificar qué objetivos se esperan alcanzar una vez que el sistema software a
desarrollar se encuentre en explotación o revisarlos en función de los conflictos
identificados.
Tarea 4: Identificar/revisar los requisitos de información.
A partir de la información obtenida en la tareas 1 y 2, y teniendo en cuenta los
objetivos identificados en la tarea 3 y el resto de los requisitos, en esta tarea se
debe identificar, o revisar si existen conflictos, qué información relevante para
el cliente deberá gestionar y almacenar el sistema software a desarrollar así
como qué restricciones o reglas de negocio debe cumplir dicha información.
Tarea 5: Identificar/revisar los requisitos funcionales.
A partir de la información obtenida en las tareas 1 y 2, y teniendo en cuenta los
objetivos identificados en la tarea 3 y el resto de los requisitos, en esta tarea se
debe identificar, o revisar si existen conflictos, qué debe hacer el sistema a
desarrollar con la información identificada en la tarea anterior.
Inicialmente se identificarán los actores que interactuarán con el sistema, es
decir aquellas personas u otros sistemas que serán los orígenes o destinos de
la información que consumirá o producirá el sistema a desarrollar y que forman
su entorno. A continuación se identificarán los requerimientos asociados a los
actores.
Tarea 6: Identificar/revisar los requisitos no funcionales.
A partir de la información obtenida en las tareas 1 y 2, y teniendo en cuenta los
objetivos identificados en la tarea 3 y el resto de los requisitos, en esta tarea se
deben identificar, o revisar si existen conflictos, los requisitos no funcionales,
normalmente de carácter técnico o legal.
3. Metodología para BD.
Diseño de Base de datos es el proceso de producir un modelo de datos
detallado para una base de datos. Este modelo logico de base de datos
contiene todas las opciones de diseño fisicas y logicas, y los parametros fisicos
requeridos para generar un diseño en un lenguaje de definicion de datos, el
cual puede luego ser usado para crear una base de datos. Un modelo de datos
con atributos completos contiene atributos detallados para cada entidad.
Analisis
Proposito: Analizar documentos y tareas; determinar los requerimientos del
sistema.
Entrada: Descripcion de documentos y tareas; Escenarios; Estadisticas de uso;
Planes para el futuro del sistema; Leyes relevantes, restricciones y politicas.
Salida: Diagrama de flujo de informacion, modelamiento de documentos de
entrada y salida, documentos internos de entrada y salida, tareas y limites del
sistema
Tecnicas:
Entrevistas con las personas involucradas
Analisis de los documentos, escenarios y tareas
Revision de planes a corto y largo plazo, manuales, archivos y
formularios
Abstraccion
Trabajo de afuera hacia adentro
Herramientas: Diagramas de flujo de informacion
Especificacion
Proposito: Crear una especificacion detallada de los documentos internos y
tareas del diagrama de flujo de informacion.
Entrada: Diagrama de flujo de informacion, estadisticas de uso, y otra
informacion adquirida durante el analisis.
Salida: Diagrama ER, Representacion de los datos (diccionario), restricciones,
Descomposicion de tareas, Formularios y Estadisitcas
Tecnicas:
Modelamiento de datos
Descomposicion de tareas de arriba hacia abajo hasta que la
especificacion es lo suficientemente detallada para permitirle a un
programador implementarla
Descomposicion de tareas que puede resultar en unas tareas
reemplazando las originales o en subtareas controladas por la tarea
original
Herramientas: Modelo ER, Formularios de Tareas
Diseño
Proposito:
Crear diseños detallados del esquema normalizado de la base relacional
Crear diseños detallados de las tareas usando codigo abstracto con SQL
embebido
Identificar la necesidad de Vistas
Entrada: Formularios de Tareas, Diagramas ER, Diseño de Entidades
Salida: Esquema relacion con llaves primarias y foraneas, definicion de
restricciones en SQL, codigo abstracto con SQL, definicion de vistas
Tecnicas: Normalizacion de base de datos, Codigo abstracto.
Herramientas:
Mapeo: Modelo ER, Modelo Relacional
Desencadenadores Graficos
Codigo Abstracto
SQL
Vistas
Implementacion
Proposito:
Crear un esquema conceptual
Crear un esquema interno
Implementar el codigo abstracto
Entrada: Esquema relacional con llaves primarias y foraneas, Representacion
de datos, restricciones en SQL, codigo abstracto con SQL, Descomposicion de
Tareas, Definicion de vistas
Salida: Esquema conceptual, esquema interno, codigo "real" con sql embebido
Herramientas:
SQL
Lenguaje de programacion
LAPs
Sistema DBMS relacional
Precompilador
Compilador de lenguaje de programacion
4. Metodología para diseño de pruebas.
La importancia de realizar las pruebas al sistema que se construye es
demasiado alta, ya que gracias a este procedimiento se lograra identificar fallos
y errores del sistema que suelen pasar inadvertidos durante la etapa de
codificación, con esto se obtiene una mayor calidad en el software y se genera
una mayor confiabilidad en el cliente.
Modelo en V
Un modelo interesante para aplicar pruebas es el V, que consiste en realizar
pruebas en varios instantes de vida del desarrollo del proyecto. El modelo en V
deriva directamente de la aplicación de pruebas de verificación y validación a
un ciclo de vida de desarrollo en cascada.
Procedimiento
Se realiza un plan de pruebas desde que se obtienen los requerimientos y se
realizan las primeras pruebas una vez terminada la fase de codificación.
Durante la fase de obtención de requisitos del negocio se va generando un plan
de pruebas de aceptación por parte del usuario.
En la fase de especificación formal se genera un plan de pruebas del sistema.
En el diseño de la arquitectura se realiza un plan de pruebas por cada
subsistema.
Los planes de prueba son el nexo entre el desarrollo y la verificación, se realiza
la etapa de diseño detallado y codificación, una vez terminados se realizan las
pruebas de la siguiente manera:
Pruebas unitarias: se verifica la menor unidad del diseño del software:
el componente software o modulo.
Pruebas de integración: es una técnica para construir la estructura del
programa mientras que al mismo tiempo, se llevan a cabo pruebas para
detectar errores asociados con la integración.
Pruebas del sistema: se utilizan para verificar el correcto
funcionamiento del sistema completo incluyendo casos de prueba que
busquen los fallos del sistema. Verifican requisitos funcionales y no
funcionales. Son pruebas destructivas y persiguen demostrar la robustez
del sistema aun en condiciones adversas.
Pruebas de aceptación del usuario: Similares a las de sistema, pero
no destructivas. Permiten demostrar que el sistema funciona en
condiciones normales.
Ventajas del modelo en V
Se puede implementar fácilmente a modelos iterativos como en el caso
de FDD.
Un plan de pruebas inmerso en el desarrollo iterativo ira evolucionando
conforme el proyecto va avanzando por distintas iteraciones.
Este modelo involucra chequeos de cada una de las etapas del modelo
de cascada.
Desventajas del modelo en V:
El riesgo es mayor que el de otros modelos, pues en lugar de hacer
pruebas de aceptación al final de cada etapa, las pruebas comienzan a
efectuarse luego de haber terminado la implementación, lo que puede
traer como consecuencia un “roll-back” de todo un proceso que costó
tiempo y dinero.
El modelo no contempla la posibilidad de retornar a etapas
inmediatamente anteriores, cosa que en la realidad puede ocurrir.
Se toma toda la complejidad del problema de una vez y no en
iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.
DESARROLLO DEL PROYECTO:
1. Introducción:
2. Analisis de las herramientas a usar
Las herramientas usadas fueron:
Django Framework: Esta herramienta fue escogida por que da la ventaja
de tener una interfaz administrativa “out-of-the-box” lo que reduce en
gran parte el trabajo de la interfaz web, ademas que reduce tambien los
tiempos de desarrollo al tener un descriptor del modelo de datos que
genera formularios y codigo para manejar la informacion de la base de
datos de forma eficiente y sencilla.
Google Code Host: Al vernos con la necesidad de tener un lugar donde
hospedar el codigo y la informacion que se va generando buscamos
varias alternativas, sin embargo por confiabilidad y por ventajas como
rss y manejo de usuarios escogimos esta.
Java ME (version??)
LTWUI
Postgresql 8.3: Este DBMS es bastante poderoso y es usado para
aplicaciones en produccion con mucho acceso a datos, siendo en
muchas ocasiones comparado con el mejor DBMS del mercado (Oracle)
pero con una licencia accequible.
Floggy
python-HL7: Librería libre desarrollada por jhon paulett, esta en una
etapa muy inicial de desarrollo sin embargo es la unica existente y sirve
para parsear mensajes HL7 en arreglos de datos que son mas
manejables.
soaplib / soappy: Librerias “open-source” para el manejo de mensajes
SOAP en Python, ademas sirven para generar WSDL de forma
automatica.
Wireless ToolKit
3. Análisis del dominio del sistema
La metodología FDD no hace mención, ni considera una recolección de
requerimientos del sistema antes de comenzar con el modelo global del
sistema, esto es porque dentro del equipo en FDD debe haber al menos un
experto en el dominio del sistema, que será el que participe en la elaboración
de los modelos y estará siempre supervisando el correcto enfoque del sistema.
Sin embargo en este proyecto ninguno de los participantes dominaba el tema,
por eso fue necesario hacer una recolección de información y seguido de una
recolección de requerimientos que se considero pertinente para el desarrollo
del sistema, este documento de requerimientos es el resultado del análisis del
dominio del sistema realizado por el equipo para comprenderlo y conocerlo.
Objetivos del Sistema
Obj-1 Permitir el acceso a la información del paciente en tiempo real.
Versión 1.0 (16/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
David Roncancio (Universidad Distrital)
Descripción La información del paciente debe estar disponible todo el tiempo para ser
consultada y cualquier modificación que se haga debe ser reflejada en el
sistema de información en el menor tiempo posible.
Importancia Vital
Estado Validado.
Estabilidad 100%
Obj- 2 Facilitar el registro de la información medica.
Versión 1.0 (16/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
David Roncancio (Universidad Distrital)
Descripción El sistema de información servirá de herramienta para llevar un registro
de la información más accesible y más organizada.
Importancia Vital
Estado Validado
Estabilidad 100%
Obj-3 Volver mas agiles los procesos médicos.
Versión 1.0 (16/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
David Roncancio (Universidad Distrital)
Descripción El sistema reducirá los tiempos de búsqueda, de consulta y de
actualización de la información médica.
Importancia Vital
Estado Validado
Estabilidad 100%
Obj-4 Facilitar el acceso a la información medica
Versión 1.0 (16/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
David Roncancio (Universidad Distrital)
Descripción La información del sistema estará disponible en un servidor dedicado con
acceso seguro a internet.
Importancia Importante.
Estado Validado
Estabilidad 100%
Obj-5 Garantizar la confiabilidad de la información.
Versión 1.0 (16/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
David Roncancio (Universidad Distrital)
Descripción Se usaran estándares para tratamiento de la información médica, y
protocolos seguros de conectividad y accesos seguro a la información,
para garantizar la integridad de la información en el sistema.
Importancia Vital.
Estado Validado
Estabilidad 100%
Obj-6 Permitir el acceso a la información del paciente desde cualquier lugar.
Versión 1.0 (16/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
David Roncancio (Universidad Distrital)
Descripción La información del paciente debe estar disponible desde cualquier lugar
donde haya cobertura de red celular, para ser consultada y actualizada.
Importancia Importante.
Estado Validado
Estabilidad 100%
Obj-7 Mejorar la atención al paciente
Versión 1.0 (20/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
Giovanny Beltrán (Universidad Distrital)
Descripción El sistema permitirá brindar al paciente información de seguimiento
sobre todos sus procesos médicos.
Importancia Importante.
Estado Validado
Estabilidad 100%
Obj-8 Proveer un soporte académico a estudiantes y médicos profesional en el
área de la medicina
Versión 1.0 (20/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
Giovanny Beltrán (Universidad Distrital)
Descripción El sistema servirá de guía de referencia para estudiantes y practicantes
mediante una plataforma web.
Importancia Quedaría bien.
Estado Validado
Estabilidad 100%
Obj-9 Crear una comunidad virtual medica
Versión 1.0 (20/12/2008)
Autor Yamit Cárdenas (Universidad Distrital)
Giovanny Beltrán (Universidad Distrital)
Descripción El sistema permitirá crear una red de social para generar relaciones entre
profesionales del área de la salud.
Importancia Quedaría bien.
Estado Validado
Estabilidad 100%
Reglas de negocio
Identificador Descripción
Únicamente el administrador general podrá crear usuario del tipo
RN.1 administrativo (usuario de entidad prestadora, usuario de la entidad
administradora)
Todos los usuarios del sistema deberán acceder al mismo a través de su
RN.2
numero de identificación y su contraseña
Únicamente el administrador de entidad prestadora estará en la capacidad de
RN.3 afiliar nuevo personal medico asociado a la entidad para la cual trabaja
(auxiliar, medico)
Solamente el administrador de la entidad administradora puede estar en
RN.4
capacidad de registrar y modificar pacientes nuevos
Solamente el administrador de la entidad administradora podrá registrar
RN.5
nuevos empleados administrativos (operador de citas)
Las entidades administradoras pueden tener contratos con mas de una entidad
RN.6
prestadora
Una entidad prestadora puede ser contratada por mas de una entidad
RN.7
administradora
RN.8 Las entidades prestadoras tienen varias sedes de atención.
RN.9 Únicamente los médicos podrán asignar servicios a sus pacientes
Los servicios que se le prestan a un paciente son del tipo:
formula medica
RN.10 incapacidad
examen
remisión a especialista
RN.11 Un paciente solo puede estar afiliado a una entidad prestadora.
El administrador de citas es el único que puede asignar o modificar las citas
RN.12
medicas
La historia clínica podrá ser accedida en su totalidad únicamente un medico
RN.13
que este atendiendo a ese paciente
Solo si el paciente es mujer, la historia clínica tendrá el componente
RN.14
ginecobstetrico
Toda entidad administradora y prestadora debe tener al menos un
RN.15
administrador asociado
RN.16 Solo se pueden publicar casos anónimos desde el sistema web
RN.17 Una Historia clínica no puede ser modificada, solo actualizada
Requisitos de información
IRQ-01 Información sobre el administrador general
Versión 1.0
Autor Yamit Cárdenas
Objetivos Obj-4
asociados Obj-5
Obj-9
Requerimientos FRQ-31
asociados FRQ-32
FRQ-33
FRQ-34
Descripción El sistema debe guardar la información necesaria con respecto a el
administrador general del sistema
Datos específicos Cédula
Nombre
Apellido
Contraseña
Teléfonos
Dirección
Entidad para la cual trabaja
Rol desempeñado
Estabilidad alta
Comentarios
IRQ-02 Información sobre el administrador de la entidad prestadora
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-4
Obj-5
Requerimientos FRQ-14
asociados FRQ-32
Descripción El sistema debe guardar la información necesaria con respecto a el
administrador de la entidad prestadora
Datos Cédula
específicos nombre
apellido
contraseña
teléfonos
Dirección
entidad a la cual representa
rol desempeñado
Estabilidad 100%
Comentarios Pendiente si puede existir mas de un empleado administrador por
entidad administradora
IRQ-03 Información sobre el administrador de la entidad administradora
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-4
Obj-5
Requerimientos
FRQ-33
asociados
Descripción El sistema debe guardar la información necesaria con respecto a el
administrador de la entidad administradora
Datos específicos Cédula
nombre
apellido
contraseña
teléfonos
Dirección
entidad a la cual representa
rol desempeñado
Estabilidad 100%
Comentarios Pendiente si puede existir mas de un empleado administrador por
entidad administradora
IRQ-04 Información sobre el personal medico
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-4
Obj-5
Obj-8
Obj-9
Requerimientos FRQ-01
asociados FRQ-02
FRQ-03
FRQ-04
FRQ-05
FRQ-06
FRQ-07
FRQ-08
FRQ-09
FRQ-10
FRQ-11
FRQ-16
FRQ-21
FRQ-22
FRQ-30
Descripción El sistema debe guardar la información necesaria con respecto a el
personal medico de una entidad prestadora
Datos específicos Cédula
nombre
apellido
contraseña
teléfonos
Dirección
entidad a la cual representa
tipo de sangre
especialidades
rol desempeñado
hora de inicio
hora de fin
Estabilidad 100%
Comentarios
IRQ-05 Información sobre pacientes
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-2
Obj-4
Obj-5
Obj-6
Obj-7
Requerimientos FRQ-01
asociados FRQ-02
FRQ-03
FRQ-04
FRQ-05
FRQ-06
FRQ-07
FRQ-08
FRQ-09
FRQ-10
FRQ-11
FRQ-16
FRQ-17
FRQ-21
FRQ-22
FRQ-23
FRQ-24
FRQ-25
FRQ-30
Descripción El sistema debe guardar la información necesaria con respecto a los
pacientes del sistema
Datos específicos Cédula
nombre
apellido
contraseña
teléfonos
Dirección
tipo de sangre
rol desempeñado
historia clínica
fecha de nacimiento
tipo de identificación
sexo
profesión
ciudad
estado (activo, bloqueado, etc.)
entidad administradora a la cual esta afiliado
alarmas
Estabilidad 100%
Comentarios
IRQ-06 Información sobre acudientes de los pacientes
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-3
Obj-5
Obj-7
Requerimientos
FRQ-23
asociados
Descripción El sistema debe guardar la información necesaria con respecto a los
acudientes que pueda tener un paciente
Datos específicos Cédula
nombre
apellido
teléfonos
dirección
parentesco
Estabilidad 100%
Comentarios
IRQ-07 Información sobre los empleados administrativos
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-4
Obj-5
Requerimientos FRQ-14
asociados FRQ-32
FRQ-33
Descripción El sistema debe guardar la información necesaria con respecto a
empleados administrativos (administrador de servicios,
administrador de citas)
Datos específicos Cédula
nombre
apellido
contraseña
teléfonos
Dirección
entidad a la cual representa
rol desempeñado
Estabilidad 100%
Comentarios
IRQ-08 Información sobre las remisiones a especialistas
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-3
Obj-4
Obj-5
Obj-7
Requerimientos FRQ-17
asociados FRQ-25
FRQ-29
Descripción El sistema debe guardar la información necesaria con respecto a las
remisiones a especialistas que realizan los médicos a sus pacientes
Datos específicos fecha de solicitud
tipo de especialista
descripción
medico que la creo
paciente a la cual va dirigida
origen de la remisión (enfermedad, maternidad, atep, soat,
otros)
comentario
Estabilidad 100%
Comentarios
IRQ-09 Información sobre las peticiones de exámenes
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-3
Obj-4
Obj-5
Obj-7
Requerimientos FRQ-08
asociados FRQ-17
FRQ-29
Descripción El sistema debe guardar la información necesaria con respecto a las
peticiones de exámenes que pueden realizar los médicos a sus
pacientes
Datos específicos fecha de solicitud
tipo de examen
descripción
resultados
medico que lo creo
paciente a la cual va dirigida
comentario
Estabilidad 100%
Comentarios
IRQ-10 Información sobre las incapacidades de los pacientes
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-3
Obj-4
Obj-5
Obj-7
Requerimientos FRQ-17
asociados FRQ-23
FRQ-29
Descripción
El sistema debe guardar la información necesaria con respecto a las
incapacidades que otorgue un medico a un paciente
Datos específicos fecha de solicitud
tipo de incapacidad
descripción
numero de días
medico que lo creo
paciente a la cual va dirigida
comentario
Estabilidad 100%
Comentarios
IRQ-11 Información sobre las formulas medicas asignadas a los pacientes
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-3
Obj-4
Obj-5
Obj-7
Requerimientos FRQ-17
asociados FRQ-24
FRQ-29
Descripción
El sistema debe guardar la información necesaria con respecto a las
formulaciones que recibe un paciente por parte de su medico
Datos específicos fecha de solicitud
medicamentos (cantidad y dosis)
medico que lo creo
paciente al cual va dirigido
comentario
Estabilidad 100%
Comentarios
IRQ-12 Información sobre los medicamentos registrados en el sistema (POS)
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-2
Obj-3
Obj-4
Obj-5
Obj-6
Requerimientos FRQ-17
asociados FRQ-24
FRQ-29
Descripción
El sistema debe guardar la información necesaria con respecto a los
medicamentos contemplados dentro del POS
Datos específicos Presentación
Posología
Nombre
Descripción
Estabilidad 100%
Comentarios
IRQ-13 Información sobre las entidades administradoras
Versión 2.0
Autor Yamit Cárdenas
Objetivos asociados Obj-4
Obj-5
Requerimientos
FRQ-33
asociados
Descripción El sistema debe guardar la información necesaria con respecto las
entidades administradoras de servicios de salud.
Datos específicos Nombre
NIT
descripción
Estabilidad 100%
Comentarios
IRQ-14 Información sobre las entidades prestadoras
Versión 2.0
Autor Yamit Cárdenas
Objetivos asociados Obj-4
Obj-5
Requerimientos
FRQ-34
asociados
Descripción El sistema debe guardar la información necesaria con respecto las
entidades prestadoras de servicios de salud.
Datos específicos Nombre
NIT
Descripción
Teléfonos
Direcciones de atención ( con descripción)
Estabilidad 100%
Comentarios
Información sobre las citas medicas
IRQ-15
Versión 2.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-4
Obj-5
Obj-6
Obj-7
Requerimientos FRQ-01
asociados FRQ-02
FRQ-03
FRQ-04
FRQ-05
FRQ-07
Descripción El sistema debe guardar la información necesaria con a las citas
medicas asignadas a los pacientes.
Datos específicos Fecha
dirección
consultorio
médico
paciente
Estabilidad 100%
Comentarios
IRQ-16 Información sobre las alarmas
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-5
Obj-6
Obj-7
Requerimientos FRQ-17
asociados FRQ-29
Descripción El sistema debe guardar la información necesaria con respecto a las
alarmas que tiene un paciente pendiente
Datos específicos Descripción
fechas
paciente
método de notificación
Estabilidad media
Comentarios Pendiente definir métodos de envío( de ser así, estudiar posibles
restricciones de Información )
IRQ-17 Información sobre la historia clínica
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-2
Obj-3
Obj-4
Obj-5
Obj-6
Obj-8
Requerimientos FRQ-06
asociados FRQ-07
FRQ-08
FRQ-09
FRQ-10
FRQ-11
FRQ-20
FRQ-21
FRQ-22
FRQ-23
FRQ-24
FRQ-25
FRQ-26
FRQ-27
FRQ-28
FRQ-29
FRQ-30
Descripción El sistema debe guardar la información necesaria con respecto a la
historia clínica de cada paciente
Datos específicos Fecha de Apertura
medico que la abrió
fecha de actualización
medico que la actualizó
formula GPCAVE
o gestas
o partos
o cesáreas
o abortos
o hijos vivos
o embarazos ectópicos
o método Anticonceptivo
o ultima Citología
o ciclos
o fecha PP
o fecha UP
Examen físico
Estado General físico
frecuencia cardiaca frecuencia respiratoria
tensión arterial
temperatura
Glasgow
cabeza y cuello
cardio pulmonar
abdomen
genitourinario
extremidades
neurológicos
osteomuscular
Revisión por Sistemas
sentidos
cardiovascular
gastrointestinal
neurológico
endocrinológico
respiratorio
datos Básicos
motivo Visita
Enfermedad Actual
manejo
diagnostico
Estabilidad 100%
Comentarios
IRQ-18 Información sobre los antecedentes del paciente
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-2
Obj-4
Obj-5
Obj-6
Requerimientos
FRQ-30
asociados
Descripción El sistema debe guardar la información necesaria con respecto a los
antecedentes de los pacientes
Datos tipo
específicos descripción
fecha de registro
Estabilidad 100%
Comentarios Pendiente definir tipos de antecedentes
IRQ-19 Información sobre los eventos generados en la historia clínica
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-2
Obj-4
Obj-5
Obj-6
Requerimientos FRQ-28
asociados FRQ-29
Descripción
Una historia clínica contiene eventos que se generan en cualquier
instante de tiempo. El sistema debe estar en capacidad de almacenar y
clasificar estos eventos
Datos específicos nombre
descripción
fecha de registro
personal medico que lo registro
adjuntos (multimedia)
paciente
Estabilidad 100%
Comentarios
Restricciones de información.
CRQ-1 Unicidad de usuarios
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-5
Requerimientos IRQ-01 Información sobre el administrador general.
asociados IRQ-02 Información sobre el administrador de la entidad prestadora.
IRQ-03 Información sobre el administrador de la entidad
administradora.
IRQ-04 Información sobre el personal medico.
IRQ-07 Información sobre el personal administrativo.
Descripción Los números identificación de usuarios (cédula) deberán ser únicos para
cada usuario en conjunto con el rol que desempeñan y la entidad para
la cual trabaja, es decir, no puede haber dos usuarios distintos con el
mismo número y el mismo rol.
Estabilidad 100%
Comentarios
CRQ-2 Alarmas en los pacientes
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-1
Obj-5
Obj-7
Requerimientos IRQ-04 Información sobre el personal medico
asociados
Descripción Las alarmas en los pacientes deberán tener como campos obligatorios la
fecha en la cual debe sonar, y una descripción detallada, donde se
brinde información sobre la necesidad de la alarma
Estabilidad 100%
Comentarios
CRQ-3 Unicidad de las entidades administradoras
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-5
Requerimientos IRQ -13 Información sobre las entidades administradoras
asociados
Descripción El numero NIT de una entidad administradora debe ser único, tampoco
debe existir mas de una entidad administradora con el mismo nombre.
Estabilidad 100%
Comentarios
CRQ-4 Unicidad de las entidades prestadoras
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-5
Requerimientos IRQ-14 Información sobre las entidades prestadoras.
asociados
Descripción El numero NIT de una entidad prestadora debe ser único, tampoco debe
existir mas de una entidad prestadora con el mismo nombre.
Estabilidad 100%
Comentarios
CRQ-5 Unicidad de las citas
Versión 1.0
Autor Yamit Cárdenas
Objetivos asociados Obj-5
Obj-7
Requerimientos IRQ-15 Información sobre las citas medicas
asociados
Descripción No pueden existir varias citas asignadas al mismo paciente en una
misma fecha
Estabilidad 100%
Comentarios
Actores del sistema
ACT-1 Administrador General
Versión 1.0
Autor Giovanny Beltrán
Descripción El administrador general simula al Estado, es el encargado de administrar el
sistema, administra lo relacionado con las entidades prestadoras de salud y
las entidades administradoras.
Comentarios
ACT-2 Administrador Entidad Administradora
Versión 1.0
Autor Giovanny Beltrán
Descripción El administrador relacionado con la entidad administradora, se encarga de
realizar las conexiones con las entidades prestadoras de salud. Afilia
pacientes al sistema y les garantiza la prestación de servicios de salud.
Comentarios
ACT-3 Administrador Entidad Prestadora de salud
Versión 1.0
Autor Giovanny Beltrán
Descripción Administrador de IPS (hospitales, clínicas, centros médicos o profesionales
de la salud), se encarga de administrar el personal medico.
Comentarios
ACT-4 Administrador de citas
Versión 1.0
Autor Giovanny Beltrán
Descripción Las entidades administradoras de salud, organizan las citas de sus afiliados
con el personal medico de una de las entidades prestadoras con quienes
trabajan. Se encarga de de gestionar todo el proceso de administración de
citas medicas.
Comentarios
ACT-5 Personal Medico
Versión 1.0
Autor Giovanny Beltrán
Descripción El personal medico hace referencia a cualquier empleado en el área de la
salud de la entidad prestadora. Médicos, enfermeras, paramédicos o
especialistas. Su función es la de atender las necesidades de sus pacientes
mediante el registro y seguimiento de eventos en las historias clínicas de
estos.
Comentarios
ACT-6 Médico General
Versión 1.0
Autor Giovanny Beltrán
Descripción Se encarga de evaluar, revisar y atender a los pacientes dentro del sistema
de salud, en un contexto de una consulta general. Es el único actor con
acceso total a la historia clínica de un paciente, además de poder anexar
información en ella.
Comentarios
ACT-7 Paciente
Versión 1.0
Autor Giovanny Beltrán
Descripción El paciente es cualquier persona natural afiliada al sistema de salud, esta en
capacidad de ser atendido por un personal medico en caso de recurrir a
algún servicio de salud. Puede revisar sus citas pendientes con una entidad
prestadora, y también puede recibir notificaciones de eventos relacionados
con su salud.
Comentarios
Requisitos funcionales
FRQ-01 Consultar agenda medico desde el móvil
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj-1
Obj-3
Obj-6
Obj-7
Requerimientos asociados FRQ-02
FRQ-03
Descripción El medico podrá consultar su agenda de citas desde el dispositivo
móvil.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 02 Sincronizar Agenda con el servidor
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 3
Obj 6
Obj 7
Requerimientos asociados FRQ-01
FRQ-03
FRQ-19
Descripción La agenda del medico en el móvil, debe estar actualizada en todo
momento, se debe realizar una sincronización de la aplicación
móvil con el servidor que es donde se encuentra la información
actualizada de la agenda medica en particular.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 03 Ver detalles de cita en la agenda Medica móvil
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 3
Obj 6
Obj 7
Requerimientos asociados FRQ-01
FRQ-02
Descripción Se pueden ver los detalles de una cita: nombre del paciente,
número de identificación, dirección ó consultorio, fecha y hora de
la cita, numero de contacto del paciente. Desde la aplicación móvil
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 04 Ver detalles de cita en la agenda Medica Web
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 3
Obj 6
Obj 7
Requerimientos asociados FRQ-19
Descripción Se pueden ver los detalles de una cita: nombre del paciente,
número de identificación, dirección ó consultorio, fecha y hora de
la cita, numero de contacto del paciente. Desde un navegador
web, en el portal.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 05 Consultar agenda desde Web
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 3
Obj 7
Requerimientos asociados FRQ-19
Descripción El medico podrá consultar su agenda de citas desde el portal web.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 06 Realizar evaluaciones TRIAGE desde móvil
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 2
Obj 3
Obj 5
Obj 6
Obj 7
Requerimientos asociados FRQ-13
FRQ-16
FRQ-27
FRQ-28
FRQ-30
Descripción La aplicación móvil debe permitir al personal medico realizar
evaluaciones TRIAGE, guardando un registro de dicha evaluación.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 07 Realizar consulta Medica General desde el móvil
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 2
Obj 3
Obj 4
Obj 5
Obj 6
Obj 7
Requerimientos asociados FRQ-09
FRQ-13
FRQ-16
FRQ-26
FRQ-27
FRQ-30
Descripción El medico podrá realizar consultas medicas generales.
La aplicación mostrara al medico una interfaz donde podrá añadir
los detalles de la consulta.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 08 Realizar petición de exámenes paraclínicos desde el móvil.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 2
Obj 3
Obj 5
Obj 6
Obj 7
Requerimientos asociados FRQ-13
FRQ-17
FRQ-30
Descripción El medico podrá solicitar paraclínicos para un paciente desde el
móvil, esta solicitud será guardada en el servidor y dará un
numero de orden para que el paciente pueda reclamar dicho
servicio.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 09 Realizar consulta de Historia clínica de un paciente desde el
móvil.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 3
Obj 4
Obj 6
Requerimientos asociados
Descripción El personal medico puede consultar la historia clínica de un
paciente desde la aplicación móvil, ingresando el documento del
paciente y solo si el personal medico esta autorizado para atender
a ese paciente.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 10 Publicar Caso anónimo en el Portal web.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 8
Obj 9
Requerimientos asociados
Descripción Un medico puede publicar un caso clínico en la comunidad web,
bien sea para obtener ayuda sobre el tratamiento de dicho
paciente, o recibir otras apreciaciones sobre el paciente. Los datos
personales del paciente permanecerán anónimos (nombre,
dirección, familiares, y fotos del rostro).
Esta información será de dominio de la comunidad web.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 11 Comentar caso anónimo
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 8
Obj 9
Requerimientos asociados
Descripción Los usuarios del portal medico podrán realizar comentarios sobre
un caso anónimo publicado.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 12 Autenticar usuarios
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 4
Obj 5
Requerimientos asociados
Descripción La aplicación móvil y el portal medico solicitaran y validaran un
nombre de usuario y contraseña para acceder al sistema.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 13 Guardar Información en el Móvil.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 4
Obj 5
Requerimientos asociados
Descripción Cuando por motivos de problemas en la red, la información
resultante de una consulta o un evento medico no se puede enviar
al servidor, esta debe persistir en el móvil para una posterior
sincronización y actualización en el servidor.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 14 Registrar personal medico en el sistema.
Versión 2.0
Autores Giovanny Beltrán
Objetivos asociados Obj 5
Requerimientos asociados FRQ-32
Descripción Únicamente los funcionarios administrativos pueden registrar
nuevos usuarios de personal medico en el sistema, se deben
describir los datos referentes a: nombres completos, edad, cargo,
número de identificación.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 15 Cambiar contraseña
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 4
Obj 5
Requerimientos asociados FRQ-12
Descripción Un usuario puede cambiar su contraseña desde el móvil y desde el
portal web, la nueva contraseña no puede ser igual al número de
identificación.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 16 Anexar multimedia
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 2
Obj 3
Requerimientos asociados
Descripción El personal medico puede agregar contenido multimedia a los
eventos registrados sobre un paciente y a las historias clínicas en
caso de una consulta medica general.
La multimedia que se puede anexar son fotos, y audio.
importancia media
Estado En construcción
Estabilidad 80%
Comentarios
FRQ- 17 Notificar eventos al paciente en el móvil.
Versión 2.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 6
Obj 7.
Requerimientos asociados
Descripción El Paciente debe ser informado de las citas, exámenes y
medicaciones, por medio de una alerta en su teléfono móvil. El
paciente puede configurar estas alarmas para que le avisen con
cierto anterioridad.
importancia media
Estado En construcción
Estabilidad 70%
Comentarios
FRQ- 19 Administrar citas médicas.
Versión 2.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 2
Obj 5
Obj 7
Requerimientos asociados
Descripción El administrador de citas, podrá asignar, reasignar y/o eliminar
citas, verificando la disponibilidad del medico y del paciente.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios colocar asignación, cancelación
FRQ- 20 Conversión de historias clínicas tradicionales al formato CDA.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 4
Obj 5
Requerimientos asociados FRQ-21
FRQ-22
FRQ-35
Descripción Para el manejo correcto del estándar HL7 es necesario realizar una
migración de las historias clínicas tradicionales al formato CDA.
importancia media
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 21 Guardar historias clínicas en formato CDA.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 4
Obj 5
Requerimientos asociados FRQ-20
FRQ-22
FRQ-35
Descripción Se debe garantizar la persistencia de los datos de las historias
clínicas en CDA.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 22 Consultar historias clínicas en formato CDA.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 4
Obj 5
Requerimientos asociados FRQ-20
FRQ-21
FRQ-35
Descripción En el portal web las historias clínicas deben ser desplegadas
usando CDA.
importancia media
Estado En construcción
Estabilidad 70%
Comentarios
FRQ- 23 Realizar orden de incapacidad laboral desde el móvil.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 2
Obj 3
Obj 5
Obj 6
Obj 7
Requerimientos asociados FRQ-13
FRQ-17
FRQ-20
Descripción El medico podrá realizar la orden de incapacidad de un paciente
desde el móvil, esta solicitud será guardada en el servidor y dará
un numero de orden para que el paciente pueda reclamar dicha
orden.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 24 Generar formula médica desde el móvil.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 2
Obj 3
Obj 5
Obj 6
Obj 7
Requerimientos asociados FRQ-13
FRQ-17
FRQ-20
Descripción El medico podrá recetar medicina y enviar una orden de
medicamentos desde la aplicación móvil, esta solicitud será
guardada en el servidor y dará un numero de orden para que el
paciente pueda reclamar la medicación correspondiente.
importancia alta
Estado En construcción
Estabilidad 100%
FRQ- 25 Generar orden de remisión a especialista desde el móvil.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 2
Obj 3
Obj 5
Obj 6
Obj 7
Requerimientos asociados FRQ-13
FRQ-17
FRQ-20
Descripción El medico podrá remitir al paciente a un especialista para hacer
una inspección mas detallada, esta remisión será guardada en el
servidor y dará un numero de orden para que el paciente pueda
solicitar la cita con el especialista.
importancia alta
Estado En construcción
Estabilidad 100%
FRQ- 26 Consultar la clasificación CIE-10 (reducida) desde el móvil.
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 2
Obj 3
Obj 5
Requerimientos asociados FRQ-13
Descripción Por medio de la aplicación móvil el medico podrá acceder a una
sección donde encontrara el listado CIE-10.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 27 Consultar la clasificación de procedimientos médicos CUPS
(reducida) en el móvil
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 2
Obj 3
Obj 5
Requerimientos asociados FRQ-13
Descripción Por medio de la aplicación móvil el medico podrá acceder a una
sección donde encontrara el listado CUPS.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 28 Registrar Evento medico desde el móvil
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 2
Obj 3
Obj 5
Obj 6
Obj 7
Requerimientos asociados FRQ-35
Descripción El personal medico autorizado podrá registrar eventos médicos en
las historias clínicas de los pacientes, estos eventos están
compuestos por: descripción, fecha, lugar, procedimiento.
Adicionalmente pueden anexarse evaluaciones TRIAGE,
multimedia, y clasificaciones CUPS y CIE-10.
Este registro debe quedar listado en el servidor.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 29 Generar Log de cada suceso en el servidor
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 5
Requerimientos asociados
Descripción En el servidor se debe registrar en un log, cada evento generado
por cualquier usuario, y por las comunicaciones realizadas por el
servidor. Este log será accesible para el administrador general.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 30 Actualizar Historia clínica del paciente desde el móvil
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 1
Obj 4
Obj 5
Obj 6
Requerimientos asociados FRQ-35
Descripción La aplicación móvil, actualizara la información concerniente a la
historia clínica del paciente en el servidor cada vez que el personal
medico realice un evento o una consulta medica.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 31 Administrar entidades administradoras
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 5
Requerimientos asociados
Descripción El administrador general podrá agregar nuevas entidades
administradoras, de igual manera podrá modificarlas y/o
eliminarlas.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 32 Administrar entidades prestadoras de salud
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 5
Requerimientos asociados
Descripción El administrador general podrá agregar nuevas entidades
prestadoras de salud, de igual manera también podrá modificarlas
y/o eliminarlas.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 33 Administrar Entidad Administradora
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 5
Obj 7
Requerimientos asociados
Descripción El administrador de la Entidad administradora esta en capacidad
de afiliar nuevos pacientes al sistema de salud.
También esta en capacidad de anexar entidades prestadoras de
salud para atender a sus afiliados.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 34 Administrar Entidad prestadora de salud
Versión 1.0
Autores Giovanny Beltrán
Objetivos asociados Obj 4
Obj 5
Obj 7
Requerimientos asociados
Descripción El administrador de la entidad prestadora puede: contratar
personal medico, también puede modificar la información de este
personal y/o despedirlos.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
FRQ- 35 El sistema debe usar HL7 messaging como protocolo de
intercambio de mensajes
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj 5
Requerimientos asociados
Descripción El sistema debe hacer uso de protocolos y estándares que
garanticen la portabilidad de la información, en este caso el
estándar HL7 que garantiza la intercomunicación con otros
sistemas que también lo usen.
importancia alta
Estado En construcción
Estabilidad 100%
Comentarios
Requisitos no funcionales
NFR-1 El sistema se debe comunicar con el servidor haciendo uso de HTTPS
Versión 1.0
Autores David Roncancio
Objetivos Obj-1
asociados Obj-5
Obj-6
Requerimientos
asociados
Descripción El sistema debe hacer uso de protocolos que garanticen la seguridad de la
información, en este caso que mantengan la sesión del cliente que esta
accediendo al servidor.
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-2 El sistema debe usar SOAP como protocolo para comunicación
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Obj-5
Obj-6
Requerimientos
asociados
Descripción El sistema debe hacer uso de protocolos que garanticen la
portabilidad de la información, en este caso que sean compatibles con
otros sistemas que usen servicios web
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-4 El sistema debe usar HL7 - CDA
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Requerimientos
asociados
Descripción El sistema debe hacer uso de protocolos y estándares que garanticen
la portabilidad de la información, en este caso el estándar HL7 - CDA
que garantiza la portabilidad de los documentos con otros sistemas
que también lo usen.
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios Convertir a Funcional
NFR-5 El sistema debe usar Java ME
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Obj-2
Obj-3
Obj-6
Requerimientos
asociados
Descripción El sistema debe hacer uso de un framework y/o un lenguaje que este
disponible en la mayoría de dispositivos móviles, que además ofrece
una gran portabilidad y facilidad en las interfaces
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-6 la interfaz grafica debe ser hecha en LWUIT
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-2
Requerimientos
asociados
Descripción El sistema debe hacer uso de un framework y que garantice la
facilidad y el reconocimiento de la UI para los médicos
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-7 El sistema debe usar JSR172
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Obj-5
Obj-6
Requerimientos
asociados
Descripción El sistema debe hacer uso de un framework que de confiabilidad y
portabilidad al momento de usar web services desde un dispositivo
móvil
Importancia Alta
Estado En construcción
Estabilidad 100%
NFR-8 El sistema debe usar MMAPI(JSR135)
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-2
Obj-3
Obj-5
Obj-7
Requerimientos
asociados
Descripción El sistema debe hacer uso de un framework que de facilidad y
portabilidad al momento de usar y manejar multimedia desde un
dispositivo móvil
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-9 La información del sistema se debe mantener en un servidor
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Obj-4
Obj-5
Obj-6
Obj-8
Obj-9
Requerimientos
asociados
Descripción El sistema debe conectarse a un servidor que mantiene segura y
centralizada toda la información del sistema(paciente, citas, servicios,
etc.), debido a lo importante y critico de esta
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-10 La información del sistema se debe manejar con el DBMS Postgres
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-3
Obj-4
Obj-5
Requerimientos
asociados
Descripción Toda la información del sistema debe estar registrara en una base de
datos relacional, orientada a objetos, que además de garantizar la
confiabilidad y la portabilidad da una gran ventaja de tiempo al
momento de desarrollar.
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-11 La comunicación debe hacerse por medio de web services
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Obj-4
Obj-5
Obj-6
Obj-9
Requerimientos
asociados
Descripción El sistema web y el sistema móvil deben comunicarse a través de web
services lo que garantiza la portabilidad y la integrabilidad del sistema.
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-12 El sistema web se debe hacer usando el framework Django
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-3
Obj-8
Obj-9
Requerimientos
asociados
Descripción El sistema web se hará usando un framework web reconocido por su
agilidad al momento de desarrollo y la calidad de los productos que se
crean además de usar un lenguaje de programación que tiene una
curva de aprendizaje mucho mas corta que otros en el mercado,
funciona todo OS y con soporte para web services (soaplib.py)
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-13 El sistema deberá ser probado sobre equipos reales
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Obj-2
Obj-3
Obj-4
Obj-6
Requerimientos
asociados
Descripción El sistema se probara sobre equipos reales (celulares), que tengan los
JSRs mencionados, y que tengan en lo posible un teclado QWERTY,
además de conexión a internet, para demostrar su versatilidad.
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
NFR-14 El sistema deberá ser sometido a pruebas
Versión 1.0
Autores David Roncancio
Objetivos asociados Obj-1
Obj-2
Obj-3
Obj-4
Obj-5
Obj-6
Obj-7
Obj-8
Obj-9
Requerimientos
asociados
Descripción El sistema será probado mediante una metodología de pruebas que
permita al desarrollador usar las pruebas para generar el código y
además permita al usuario final hacer las pruebas de usabilidad
metodología por definir
Importancia Alta
Estado En construcción
Estabilidad 100%
Comentarios
Matriz de rastreabilidad objetivos/requisitos funcionales
Obj-1 Obj-2 Obj-3 Obj-4 Obj-5 Obj-6 Obj-7 Obj-8 Obj-9
IRQ-01 X X X
IRQ-02 X X
IRQ-03 X X
IRQ-04 X X X X
IRQ-05 X X X X X X
IRQ-06 X X X
IRQ-07 X X
IRQ-08 X X X X X
IRQ-09 X X X X X
IRQ-10 X X X X X
IRQ-11 X X X X X
IRQ-12 X X X X X
IRQ-13 X X
IRQ-14 X X
IRQ-15 X X X X X
IRQ-16 X X X X
IRQ-17 X X X X X X X
IRQ-18 X X X X X
IRQ-19 X X X X X
FRQ-01 X X X X
FRQ-02 X X X X
FRQ-03 X X X X
FRQ-04 X X X X
FRQ-05 X X X
FRQ-06 X X X X X X
FRQ-07 X X X X X X
FRQ-08 X X X X X X
FRQ-09 X X X X
FRQ-10 X X
FRQ-11 X X
FRQ-12 X X
FRQ-13 X X
FRQ-14 X
FRQ-15 X X
FRQ-16 X X
FRQ-17 X X X
FRQ-19 X X X X
FRQ-20 X X
FRQ-21 X X
FRQ-22 X X X
FRQ-23 X X X X X X
FRQ-24 X X X X X X
FRQ-25 X X X X X X
FRQ-26 X X X
FRQ-27 X X X
FRQ-28 X X X X X X
FRQ-29 X
FRQ-30 X X X X
FRQ-31 X
FRQ-32 X
FRQ-33 X X
FRQ-34 X X X
FRQ-35 X
NFR-01 X X X
NFR-02 X X X
NFR-04 X
NFR-05 X X X X
NFR-06 X
NFR-07 X X X
NFR-08 X X X X
NFR-09 X X X X X X
NFR-10 X X X
NFR-11 X X X X X
NFR-12 X X X
NFR-13 X X X X X
NFR-14 X X X X X X X X X
35 21 29 32 51 29 26 7 9
Tabla 1 matriz de rastreabilidad.
4. Desarrollo del modelo general
Con una lista de requerimientos como resultado de la fase anterior se inició el proceso
con la metodología FDD, en principio se desarrolló un modelo general del sistema que
describe las diferentes áreas y procesos implicados en el sistema. En este capítulo se
muestran los resultados del análisis del dominio global en sus diferentes áreas
soportado en el levantamiento de requerimientos del capitulo anterior.
4.1. Modelo global FDD
(Aquí iría una versión ploteada del mind map)
4.2. Diagrama de clases
Sistema web
Sistema móvil
Figura 1 edu.logica
Figura 2 edu.persistencia
Figura 3 edu.conexion
4.3. Diagramas de navegación
Sistema web
Página 106 de 169
Sistema móvil
Página 107 de 169
4.4. Listado informal de características
Caracteristica Aprobado Sistema req asociados
consultar historia clinica de un paciente Si Movil/Web FRQ-07
realizar log de consulta Si Web FRQ-07, FRQ-29
Actualizar historia clinica Si Movil/Web FRQ-07, FRQ-30
actualizar eventos si movil/web FRQ-07
Realizar Consulta medico General Si Movil FRQ-07
Restringir Acceso a historia Clinica Si Movil/Web RN.2, FRQ-12, FRQ-14
Realizar evaluacion TRIAGE Si Movil/Web FRQ-06, FRQ-28
Generar Mensaje HL7 Si Movil FRQ-35, NFR-4
Generar Mensaje HL7 Si Web FRQ-35, NFR-4
Leer Mensaje HL7 Si Movil FRQ-35, NFR-4
Leer Mensaje HL7 Si Web FRQ-35, NFR-4
Generar Mensaje SOAP Si Movil FRQ-35, NFR-2
Generar Mensaje SOAP Si Web FRQ-35, NFR-2
Leer Mensaje SOAP Si Movil FRQ-35, NFR-2
Leer Mensaje SOAP Si Web FRQ-35, NFR-2
Generar WSDL si Web NFR-2
Consultar WSDL si Movil/Web NFR-2
usar la clasificacion internacional de
enfermedades (cie 10) si Movil FRQ-26
usar el estandar internacional para la
clasificacipn unica de procedimientos
(cups) si Movil FRQ-27
Cargar historia clinica si Movil/Web
Generar Documento CDA si Web NFR-4
Interpretar Documento CDA si Web NFR-4
Consultar agenda medica si Movil/Web FRQ-3, FRQ-4
Consultar agenda medica si Web FRQ-5
Ver detalles Cita si Movil FRQ-3, FRQ-4
Administrar Citas si Web FRQ-5, FRQ-19
compartir casos clinicos con otros medicos
(portal) si Web FRQ-10
Agregar elementos multimedia a eventos
(fotos, audio) si Movil FRQ-16
notificar al paciente los horarios de sus
medicamentos y las fechas de los
examenes, citas (servicios en general) con
sms si Movil/Web FRQ-17
ver casos clinicos anonimos con acceso
restringido si Web FRQ-10
Solicitar Paraclinicos si Movil/web FRQ-8
Solicitar Remision Especialista si Movil/web FRQ-25
Solicitar Incapacidad si Movil/web FRQ-23
Generar Formulas Medicas si Movil/web FRQ-24
Autenticar usuarios si Web FRQ-12
Autenticar usuarios si Movil/Web FRQ-12
Guardar historia clinica en el movil si Movil FRQ-13
Guardar evento en el movil si Movil FRQ-13
Guardar agenda en el movil si Movil FRQ-13
Guardar peticion de formulamedica si Movil FRQ-13
Página 108 de 169
Guardar peticion de incapacidad si Movil FRQ-13
Guardar peticion de paraclinicos si Movil FRQ-13
Guardar peticion de examenes si Movil FRQ-13
Hacer conexion HTTPS si Movil/Web NFR-1
Enviar peticion Websevice si Movil NFR-2
Interpretar respuesta Webservice si Movil NFR-2
Crear evento medico si Movil FRQ-28
programar alarmas si web FRQ-17
FRQ-2, (No existe requerimiento
sincronizar informacion guardada si Movil/Web de Sincronizacion?)
FRQ-34, (Falta requerimiento de
Administracion de Usuarios de
Gestionar usuarios si Web EPs y EAs??)
Formatear Password si Web
Cambiar Password si Web
Formatear Password si Web/movil
Cambiar Password si Web/movil
mostrar HC CDA si Web FRQ-20, FRQ-22
Generar Logs si Web FRQ-29
Desplegar Multimedia si Movil FRQ-16, NFR-8
Agregar Comentario "analisis medico"
Caso anonimo si Web FRQ-11
Página 109 de 169
5. Construcción y planeación de lista de características
Después de realizar una evaluación de los grupos de características se ordenaron
según su prioridad, esta prioridad fue asignada dependiendo de su importancia dentro
del proyecto y de lo necesarias que fueran para otras características.
Para cada característica se clasifico un grado de dificultad (en la metodología dice
complejidad), esta dificultad hace referencia a que tan complicado es desarrollar dicha
característica. El grado de dificultad va de 1 a 5, siendo 1 algo sencillo y 5 algo muy
complicado.
Para decidir este grado de dificultad en cada característica, se evaluó el grado de
conocimiento de las herramientas necesarias para desarrollarlo y la cantidad de
algoritmia necesaria, la cantidad de "trabajo" que implica el desarrollo de cada
característica es un factor menos relevante al momento de decidir la dificultad, es decir
algo puede ser muy sencillo pero puede tomar una semana de desarrollo debido a la
cantidad de codificación que necesita, y otro puede ser en extremo difícil pero toma 2
días de desarrollo, estos tiempos serán usados en el cronograma, cada grupo de
características asociado toma un valor también de dificultad que es el resultado de las
características asociados a él, algunas características similares también tienen
dificultades distintas, esto se debe a que en algunos al resolver una característica se
resuelve un problema que será utilizado en la siguiente característica similar.
La asignación de los jefes de grupos de características se realizo con base a las
habilidades de cada uno de los integrantes del equipo de trabajo, de igual manera se
realizo una carga equitativa de estos grupos de características a los jefes, estos jefes
están encargados de realizar todo el diseño correspondiente a cada grupo de
características dentro del proceso de FDD, también son responsables por este grupo
de características y deben estar pendientes de que se desarrolle correctamente.
La asignación de las características se realizo de igual manera de forma equitativa
según el grado de dificultad respectivo, los propietarios de cada característica son
responsables del desarrollo de dicha característica y seguir el diseño planteado por el
jefe del grupo de características correspondiente, realizar las pruebas unitarias y
notificar al jefe del grupo de características de cualquier modificación o apreciación
que surja.
Página 110 de 169
5.1. Listado formal de características
Características Grupo de Jefe de grupo P Características Propietarios de
Principales características de característica
características
Autenticar usuarios Giovanny 5
Beltrán
validar login de David
usuario Roncancio
validar contraseña David
de usuario Roncancio
validar login de Yamit Cárdenas
usuario móvil
validar contraseña Yamit Cárdenas
Administración
de usuario móvil
de Usuarios
Gestionar usuarios Giovanny 4
Beltrán
crear un nuevo David
usuario Roncancio
modificar usuario David
existente Roncancio
asignar permiso a David
usuario Roncancio
Gestionar entidades David 3
Roncancio
crear una nueva David
entidad Roncancio
Administración crear una nueva Giovanny
de Entidades sede Beltrán
crear un nuevo Giovanny
contrato Beltrán
modificar entidad David
existente Roncancio
Consultar agenda David 7
medica web Roncancio
desplegar agenda Giovanny
medica Beltrán
desplegar calendario Giovanny
Beltrán
Administración Administrar citas David 8
de Agenda medicas Roncancio
buscar paciente Giovanny
Beltrán
buscar medico Giovanny
Beltrán
crear nueva cita Giovanny
Beltrán
Página 111 de 169
eliminar cita Giovanny
Beltrán
Consultar agenda Giovanny 9
medica móvil Beltrán
desplegar agenda Giovanny
medica Beltrán
ver detalles de cita Yamit Cárdenas
medica
Administrar alarmas David 16
Roncancio
crear alarma David
Roncancio
notificar alarma David
Administración Roncancio
de Pacientes Afiliar Paciente David 6
Roncancio
agregar paciente David
Roncancio
editar paciente David
Roncancio
Gestionar Mensaje Giovanny 10
HL7 Beltrán
crear mensaje HL7 Giovanny
móvil Beltrán
Interpretar mensaje David
HL7 web Roncancio
crear mensaje HL7 David
web Roncancio
interpretar mensaje Giovanny
HL7 móvil Beltrán
Gestionar Mensaje David 2
SOAP Roncancio
Administrar crear mensaje SOAP Giovanny
Conexión móvil Beltrán
Interpretar mensaje David
SOAP web Roncancio
crear mensaje SOAP David
web Roncancio
interpretar mensaje Giovanny
SOAP móvil Beltrán
enviar mensaje SOAP Giovanny
móvil Beltrán
enviar mensaje SOAP David
web Roncancio
Gestionar servicios David 1
Web Roncancio
Página 112 de 169
generar WSDL David
Roncancio
interpretar WSDL Giovanny
móvil Beltrán
interpretar WSDL David
web Roncancio
Sincronizar Yamit Cárdenas 15
Información guardada
sincronizar HC Yamit Cárdenas
sincronizar servicios Yamit Cárdenas
sincronizar Eventos Yamit Cárdenas
Administración de Giovanny 18
Log Beltrán
escribir log Giovanny
Beltrán
generar listado de David
logs Roncancio
Gestionar caso clínico Giovanny 17
Beltrán
listar pacientes David
Roncancio
generar documento Giovanny
CDA Beltrán
desplegar HC CDA Giovanny
Beltrán
agregar descripción Giovanny
Beltrán
publicar paciente David
Roncancio
agregar comentarios David
Roncancio
Gestión de
Gestionar consulta Yamit Cárdenas 11
Historia Clínica
general
solicitar Historia Yamit Cárdenas
clínica
registrar consulta Yamit Cárdenas
medico general
agregar Yamit Cárdenas
antecedentes
cerrar consulta Yamit Cárdenas
medico
Solicitar Servicios Yamit Cárdenas 12
solicitar exámenes Yamit Cárdenas
Página 113 de 169
solicitar incapacidad Yamit Cárdenas
solicitar formulas Yamit Cárdenas
medicas
solicitar remisiones Yamit Cárdenas
Gestionar eventos Yamit Cárdenas 13
registrar evento Yamit Cárdenas
registrar evaluación Giovanny
TRIAGE Beltrán
agregar foto Giovanny
Beltrán
agregar audio Yamit Cárdenas
cerrar evento Yamit Cárdenas
Desplegar Yamit Cárdenas 1a
información de
estándares
desplegar CIE10 Yamit Cárdenas
desplegar CUPS Yamit Cárdenas
desplegar POS Yamit Cárdenas
Crear copia de Yamit Cárdenas 14
seguridad móvil
Gestión de guardar consulta Yamit Cárdenas
repositorio móvil general
guardar Yamit Cárdenas
antecedentes
guardar eventos Yamit Cárdenas
guardar medicación Yamit Cárdenas
guardar examen Yamit Cárdenas
guardar remisión Yamit Cárdenas
guardar incapacidad Yamit Cárdenas
Página 114 de 169
6. DISEÑO DE LA BASE DE DATOS
Los diseños realizados en cada una de las iteraciones se encuentras disponibles en
los anexos digitales del proyecto.
Basados en la información recogida durante la fase de análisis del dominio, y en los
requerimientos de información levantados, se diseño la primera versión del modelo
Relacional y el modelo físico de la base de datos del proyecto.
DISEÑO CONCEPTUAL
Usuarios del sistema
Administrador general: Es el Super-Usuario solo tiene acceso al modulo Web
y está encargado de crear y modificar entidades prestadoras, y entidades
administradoras de salud, también se encarga de la crearon o modificación de
los usuario de tipo “usuario entidad administradora” y de tipo “usuario entidad
prestadora”, mantener la aplicación y mirar los logs del sistema.
Usuario entidad administradora: es la persona encargada de gestionar la
información de las entidades administradoras de salud (eps, ars, etc), crear o
modificar pacientes en el sistema y tiene acceso a las historias clínicas de los
mismos, también se encarga de asociar las entidades prestadoras de salud con
la entidad administradora.
Usuario entidad prestadora: es la persona encargada de gestionar la
información concerniente a las entidades prestadoras de salud, agregar o quitar
sedes de atención, y registrar en el sistema el personal medico.
Personal medico: estas personas pueden ser médicos, paramédicos,
enfermeras, o auxiliares en general, se encargan de actualizar la información
de las historias clínicas de los pacientes, los médicos pueden realizar
publicaciones de casos anónimos.
Empleado citas: Las entidades administradoras de salud, organizan las citas
de sus afiliados con el personal medico de una de las entidades prestadoras
con quienes trabajan. Se encarga de de gestionar todo el proceso de
administración de citas medicas.
Página 115 de 169
ENTIDADES
Acudiente: la entidad acudiente representa a una o varias personas que se
hacen responsables por un paciente.
Adjunto: la entidad adjunto representa el contenido multimedia agregado a las
historias clínicas, a través de los eventos médicos generados sobre la misma.
AdministradorGeneral: en esta entidad se modelan los datos referentes al
usuario llamado administrador general.
Alarma: la entidad alarma es usada para guardar la información referente a las
citas medicas, y exámenes asignados a los pacientes.
Análisis medico: describe los comentarios hechos por otros médicos a los
casos anónimos publicados en el portal.
Antecedentes: esta entidad es usada para almacenar la información
concerniente a los antecedentes relativos a un paciente.
Caso anónimo: la entidad caso anónimo guarda la información referente a los
casos clínicos compartidos por los médicos a la comunidad.
Cita: la entidad cita representa la información acerca de las visitas que realiza
un medico a un paciente, se compone de una hora, y un lugar especifico.
documentoCDA: en la entidad documento CDA se guarda la ruta del
documento CDA asociado a la historia clínica de un paciente, en conjunto con
la fecha en la que fue agregado el documento.
empleadoCitas: en esta entidad se modela la información referente a los datos
de usuario del empleado que se encarga de asignar y modificar las visitas
medicas.
Entidad: esta entidad se encarga de generalizar a las entidades prestadoras y
a las entidades administradoras, puesto que ambas comparten información en
común con respecto a las sedes de atención.
entidad_administradora: esta entidad representa a las empresas dedicadas a
la administración en salud (EPS, ARS, ESS, ARP, régimen especial, SOAT).
Página 116 de 169
entidad_prestadora: esta entidad representa a todas las empresas que
brindar el servicio de atención médica (IPS, ESE).
Evento: la entidad evento describe la información Relacionada con cualquier
acción ejecutada por el personal medico a un paciente, como por ejemplo
(suturas, administración de medicamentos, evaluaciones triage, entre otros).
Examen: en la entidad examen se almacena toda la información referente a los
exámenes para clínicos asignados a los pacientes, fecha, tipo de examen y
resultados del mismo.
FechaAlarma: en esta entidad se guardan todas las fechas programadas para
una alarma específica asignada a un paciente, la información contenida aquí se
usara para poder avisar a un paciente acerca de sus visitas o los resultados de
sus exámenes.
Formula: la entidad formula representa el conjunto de medicamentos que
asigna un medico a un paciente luego de realizar una visita medica.
GPCAVE: esta entidad es usada para guardar toda la información referente a
la revisión ginecobstetrica hecha a las mujeres en cada cita médica.
Hc: la entidad Hc modela la información básica contenida en la historia clínica,
esta entidad es usada para poder asociar los documentos CDA, los eventos y
los pacientes a su historial medico.
Incapacidad: representa la información concerniente a todas las
incapacidades que se asignaran a los pacientes.
Log: entidad creada con el fin de llevar un control de todas las actividades que
realiza un usuario dentro del sistema, aquí se guardara información con
respecto a los cambios hechos, el usuario q los hizo, y la fecha en que los hizo.
Medicamento: esta entidad modela la información necesaria acerca de los
medicamentos que se encuentran dentro del POS (plan obligatorio de salud),
así como la posología del mismo y la formula medica a la cual se encuentra
asociado.
Motivo y diagnostico: la entidad motivo y diagnostico, como su nombre lo
indica, es usada para almacenar información concerniente a los motivos que
tiene un paciente para ir a una cita medica, y al diagnostico dado por el medico,
luego de los exámenes de rigor.
Página 117 de 169
Paciente: la entidad paciente modela la información necesaria para llevar
acabo una buena gestión de los datos de las personas registradas en el
sistema, y garantizar la confidencialidad y unicidad de los mismos.
persoMedico: esta entidad modela la información de usuario Relacionada con
todo el personal medico (médicos, paramédicos, enfermeras, auxiliares).
Remisión: describe la información necesaria para las remisiones a
especialistas ordenadas por los médicos a los pacientes.
RevisionFisica: en esta entidad se almacena información referente a la
revisión física hecha a un paciente durante una cita médica.
RevisionSistemas: en esta entidad se almacena información referente a la
revisión hecha por un medico, a todos los sistemas de un paciente durante una
cita médica.
sede: la entidad sede contiene la el numero de teléfonos, la dirección, la
ciudad, y la descripción de cada uno de los centros de atención de las
entidades prestadoras.
Servicio: esta entidad es una generalización de todas las prestaciones que
brinda una entidad administradora a sus pacientes (remisiones, exámenes,
formulaciones, incapacidades).
UserEntidadAdmin: en esta entidad se modela la información referente a los
datos de usuario del empleado encargado de gestionar la entidad
administradora en el sistema.
UserEntidadPrestadora: en esta entidad se modela la información referente a
los datos de usuario del empleado encargado de administrar la entidad
prestadora en el sistema.
Usuario: esta entidad es la generalización de todos los usuarios en el sistema,
contiene la información primaria para todos los usuarios (documento de
identificación, password, nombre, tipo de sangre, rol, etc).
Página 118 de 169
Relaciones
Afilia: el usuario de la entidad administradora afilia pacientes en el sistema.
Esta relación es usada para llevar el control de las afiliaciones de usuarios en
el sistema, para saber a que entidad administradora pertenece y quien fue la
persona responsable del registro de cada uno de los usuarios.
Afiliado en: el paciente esta afiliado en una entidad administradora. Dado que
un paciente solo puede pertenecer a una única entidad prestadora, Esta
relación nos permite saber a que entidad administradora se encuentra afiliado
el paciente.
Asigna: el empleado de citas asigna citas. Esta relación es para representar la
función que tiene el empleado de citas en el sistema, y para saber quien fue la
persona que asigno determinada cita a un paciente.
Asignado a: los servicios son asignados a pacientes. Esta relación es usada
para poder determinar a que usuario esta asignado un servicio y así mismo
poder enviarle las alarmas necesarias.
Asiste: el paciente asiste a la cita. Esta relación es usada para identificar a que
paciente esta asignada determinada cita en la agenda medica.
Atiende: el personal medico atiende una cita. Mas específicamente solo los
usuarios cuyo rol sea medico y se encuentren en la tabla personal medico,
están en capacidad de atender una cita, esta relación es usada para identificar
el mecido que va a atender a un determinado paciente en una cita.
Contiene: los eventos contienen adjuntos. Esta relación fue creada para
identificar los eventos que tienen asociados adjuntos (contenido multimedia).
Contrata: el usuario de la entidad prestadora contrata personal medico. Dicha
relación hace referencia al registro de todo el personal medico, que debe hacer
la entidad prestadora de servicios de salud en el sistema.
Crea: el usuario de la entidad administradora crea empleados de citas. Esta
relación permite saber para qué entidad administradora de salud trabaja un
empleado de citas.
Esta asociado: los análisis médicos están asociados a los casos anónimos.
Gracias a esta relación podemos identificar a que caso anónimo pertenece
Página 119 de 169
cada uno de los análisis médicos realizados por el personal medico dentro del
portal.
Forma parte: los antecedentes del paciente forman parte de la historia clínica
del mismo, la relación es usada para mantener asociados cada uno de los
antecedentes de un paciente a la historia clínica.
Genera: el usuario genera logs, esta relación existe para poder asociar a un
usuario a todos los cambios que el realice dentro del sistema.
Hace parte: los eventos hacen parte de la historia clínica. En conjunto con los
antecedentes, los eventos médicos determinan una parte importante en la
composición de una historia clínica.
Inscribe: el personal medico inscribe eventos. Únicamente el personal medico
registrado en el sistema esta en capacidad de agregar eventos médicos a la
historia clínica del paciente. La relación proporciona los mecanismos para que
se cumpla esta premisa.
Labora para: el empleado de citas laboral para una entidad administradora.
Cuando el usuario de la entidad administradora registra empleados de citas,
dichos empleados deben quedar asociados directamente con la entidad
administradora para la cual trabajan.
Posee: la entidad prestadora posee sedes. Todas las sedes en las cuales la
entidad prestadora brinda servicios a los pacientes, deben estar registradas en
el sistema y asociadas a la entidad a la que pertenecen.
Publica: el personal medico pública casos anónimos. Específicamente los
usuarios cuyo rol se medico podrán realizar la publicación de casos anónimos
en los cuales él requiera la opinión de otros expertos en el tema.
Realiza: el personal medico realiza análisis médicos. Cada medico registrado
en el sistema podrá agregar análisis médicos a cualquier caso anónimo, estos
análisis médicos aparecerán en el sistema asociados al medico que lo realizó.
Recibe: el paciente recibe alarmas. Esta relación nos permite asociar las
alarmas a un paciente determinado con el fin de enviar mensajes recordatorios
al teléfono celular del mismo.
Registra EA: el administrador general registra usuarios de la entidad
administradora. Al realizar este registro dicho empleado quedara asociado a la
Página 120 de 169
entidad administradora deseada, en caso de que la entidad administradora no
exista deberá crearse.
Registra EP: el administrador general registra usuarios de la entidad
prestadora. Al realizar este registro dicho empleado quedara asociado a la
entidad prestadora deseada, en caso de que la entidad prestadora no exista
deberá crearse.
Relacionado con: un caso anónimos esta Relacionado con una historia
clínica. Los casos anónimos son derivados de las historias clínicas, solo que en
ellos no podrá aparecer ningún tipo de información que comprometa la
integridad de un paciente.
Se_compone_1: la historia clínica se compone de motivo y diagnostico, esta
relación es usada para asociar los motivos y diagnósticos dados por el medico,
a la historia clínica de un paciente.
Se_compone_2: la historia clínica se compone de revisiones por sistemas,
esta relación es usada para asociar la revisión por sistemas dada por el
medico, a la historia clínica de un paciente.
Se_compone_3: la historia clínica se compone de revisiones físicas, esta
relación es usada para asociar la revisión física dada por el medico, a la
historia clínica de un paciente.
Se_compone_4: la historia clínica se compone de revisiones ginecobstetricas
(GPCAVE), esta relación es usada para asociar los datos de la revisión
ginecobstetrica de una mujer, su historia clínica..
Suena el: las alarmas suenan en varias fechas. Dentro del sistema se
contempla que las alarmas tenga varias horas de llegada al paciente, (3 días
antes, 1 día antes, 1 hora antes, para la citas)
Sugiere: el personal medico sugiere servicios a sus pacientes. Cada servicio
sugerido por el medico debe ser asociado directamente a la historia clínica del
paciente.
Tiene asignada: el paciente tiene asignada una historia clínica. Esta relación
hace referencia a que todos los pacientes registrados dentro del sistema deben
tener una historia clínica electrónica, para ser alimentada por el personal
medico.
Página 121 de 169
Tiene relación: el acudiente tiene relación con el paciente. Esta relación existe
para poder asegurar que hay un persona responsable por cada uno de los
pacientes, que pueda ser capaz de brindar información sobre el mismo, y
pueda ser notificada de cualquier tipo de eventualidad.
Trabajan en: el usuario de la entidad administradora trabaja en una entidad
administradora. Esta relación nos permite identificar para cual entidad
administradora trabaja cierto tipo de usuario.
Trabaja en EP: el usuario de la entidad prestadora trabaja en una entidad
prestadora. Esta relación nos permite identificar para cual entidad prestadora
trabaja cierto tipo de usuario.
Trabaja para: el personal medico trabaja para una entidad prestadora. El
personal medico registrado dentro del sistema debe estar asociado a la entidad
para la cual presta el servicio, esto con el fin de brindar mecanismos de
seguridad con respecto a las consultas de la historia clínica de un paciente.
Página 122 de 169
DIAGRAMAS ENTIDAD-RELACIÓN
Vista de usuarios
Página 123 de 169
Vista de entidades
Página 124 de 169
Vista de agenda medica
Página 125 de 169
Vista de paciente
Página 126 de 169
Vista de historia clínica
Página 127 de 169
DISEÑO LÓGICO
Vista usuario (Relacional)
Página 128 de 169
Vista de entidades (Relacional)
Página 129 de 169
Vista agenda (Relacional)
Página 130 de 169
Vista paciente (Relacional)
Página 131 de 169
Vista historia clínica (Relacional)
Página 132 de 169
7. DISEÑO Y CONSTRUCCIÓN POR CARACTERÍSTICAS
Una vez terminada la planeación de las características del sistema se procede a
diseñar y construir cada característica mediante un proceso iterativo. Cada iteración
toma unos pocos días y un máximo de una semana, para cada iteración de la fase de
diseño y construcción se debe generar la siguiente información:
Diseño por grupo de características:
1. Revisión del dominio (de ser necesario)
a. Comentarios acerca del dominio y como se refleja en el desarrollo de la
característica. (Esta puede ser parte introductoria al diseño, por decir
esta característica es parte del componente de administración de
usuario que sirve para identificar cuando un usuario se logea
correctamente, etc.; también abarca detalles como especificaciones o
limitaciones del dominio, EJ: CIE10 contiene 10000 registros en su
versión normal, archivos de tal tamaño pueden provocar inconvenientes
en la velocidad de lectura, se usara entonces una versión de 1000
registros, los más comunes con los cuales se puede trabajar.)
2. Diseño (diagramación)
a. Diagrama de secuencia.
b. Diagrama de clases actualizado. (nuevas clases que se utilizaran
dependiendo del dominio, para la parte web puede ser necesario
describir que nuevas aplicaciones o módulos deben ser creados)
c. Descripción de clases y métodos (que se usaran, funcionalidad, que
reciben y que devuelven).
d. Plan de pruebas (en base a lo anterior es “sencillo” generar pruebas
unitarias, entre estas se destacan las de caja blanca y las de caja
negra, hay distintos estilos, la idea es describir que tipo de pruebas se
usaran para evaluar el funcionamiento correcto).
3. Inspección de Diseño
Página 133 de 169
a. Notas del equipo que consideren significativas para el diseño. (apuntes
finales, como: revisar el diseño del modulo anterior para observar cómo
se resolvieron distintos problemas, o no usar tal clase)
Construcción por grupo de características:
1. Codificación
a. Implementación de clases y métodos.
2. Inspección del código(el código está “bien” escrito)
a. Pruebas unitarias.(según el plan de pruebas elaborado en la fase de
diseño, si alguna prueba sale mal, se deberá corregir de inmediato y
escribirlo en un log)
b. Validación del modulo.(el modulo hace las cosas de manera correcta)
3. Integración
a. Pruebas de integración. (al finalizar las pruebas se debe integrar el
modulo con el resto del proyecto, una vez realizado y resueltas con
satisfacción, se cierra el modulo)
b. Verificación. (el modulo satisface los requerimientos de manera
correcta)
En este documento se muestra la última iteración por cada planeación diseñada, los
contenidos de cada diseño pueden variar, ya que no es indispensable tener toda la
información completa en algunos diseños de características. Los diseños están
agrupados en características mayores del sistema según la tabla ¡!!Q@asda!!.
Página 134 de 169
Administración de Usuarios
AUTENTICAR USUARIOS
La autenticación de usuarios está enfocada a la verificación de que el usuario
es quien dice ser, para este sistema se decidió que la autenticación seria por
medio de una contraseña que solo el usuario conoce y su identificación (en
este caso Cedula de Ciudadanía en la república de Colombia) RN.2, de esta
manera podrá acceder al sistema y podrá realizar tareas concernientes a su rol.
La autenticación se realizara desde el web y el cliente móvil.
Descripción de clases y métodos
Subsistema web
Usuario-clase Vistas-métodos Descripción
Usuario Login de usuario El usuario no identificado hasta ahora puede
anónimo iniciar sesión ingresando su nombre de usuario
y contraseña.
Recordar contraseña El usuario no recuerda su contraseña, puede
recibir una recordación de su contraseña con
escribir su número de identificación. El sistema
deberá enviar la contraseña por SMS o correo
electrónico.
Views autenticar Recibe un número de identificación y una
contraseña, debe retornar un true y cookie en
caso de que el usuario sea válido en el sistema,
en caso contrario deberá retornar un false un
valor NONE.
(web service)
LoginForm login Captura los datos del formulario de login
(identificación y contraseña), verifica que no
sean nulos, que no contengan tipos distintos a
los validos, y llama a autenticar por medio del
webservice.
Subsistema móvil
Clase Métodos Descripción
Login show() Se despliega un formulario donde el
usuario puede agregar su nombre de
usuario y contraseña.
actionPerformed() Se debe capturar el evento de la
acción de iniciar sesión, se validaran
que los campos no se encuentren
vacios, y se setearan en la central de
datos.
AdministradorConexiones invocarServicio(id) Dentro de la invocación al servicio se
creara e iniciara la conexión por via
webservice mediante la clase
manejadorWSDL.
Página 135 de 169
ManejadorWSDL iniciarConexion() Se debe verificar el tipo de conexión,
en este caso de login de usuario y se
enviara la consulta respectiva al
servidor.
manejarRespuesta() Cuando el servidor retorne la
respuesta de la consulta al servicio, se
debe manejar a través de este
método, ke deberá capturar True o
False dependiendo de si la
autenticación fue exitosa o no, en caso
de ser exitosa (True) se debe recibir
también el nombre del usuario, la
cookie de la sesión, y el rol
desempeñado por el usuario (médico
general o personal médico)
CentralDatos setCookie(cookie) Se debe almacenar en la central de
datos la cookie activa si la
autenticación tuvo éxito. Esta cookie
será usada en cada conexión mientras
el usuario este activo dentro de la
aplicación.
setID(id) Se almacena el id del usuario que
desea iniciar sesión, para su consulta
por parte del manejadorWSDL.
setPassword(password) Se almacena la contraseña del usuario
que desea iniciar sesión, para su
consulta por parte del
manejadorWSDL.
setusuarioActivo Se crea y almacena una referencia del
(personalmedico) usuario activo en el sistema una vez se
autentica exitosamente.
PersonalMedico setInfoBasica(nombre, se añade la información restante del
ips) personal médico activo en la
aplicación móvil.
MenuPrincipal show() Cuando la autenticación es exitosa se
debe desplegar el menú de la
aplicación dependiendo del rol que
este activo. (diagrama de navegación
móvil)
cerrarSesion() Se termina la sesión con el servidor y
se regresa a la pantalla del login.
Carga show() Mientras se establece la conexión con
el servidor y se obtiene su respuesta,
la aplicación despliega una interfaz de
carga que le informa al usuario que la
aplicación está en espera mientras
logra la conexión con el servidor.
Página 136 de 169
Plan de pruebas
Pruebas unitarias
Es necesario diseñar pruebas unitarias para el subsistema web y el subsistema
móvil de forma independiente.
Subsistema web
1. Pruebas de interfaz:
Se verificaran los flujos de navegación desde la ventana de login a cada tipo de
usuario que puede ser validado dentro del sistema.
2. Pruebas de la estructura de datos locales:
Los usuarios activos en el sistema deben corresponder a usuarios que han
hecho login valido.
3. Condiciones limite:
Se verificaran casos donde un mismo usuario ingrese al sistema desde
distintas terminales.
4. Caminos independientes:
Se validara de igual manera que en la prueba de interfaz. Adicional de las
alertas necesarias cuando el usuario no se autentica de forma correcta dentro
del sistema.
5. Camino de manejos de errores:
Se corregirán todos los errores encontrados durante la evaluación de los casos
de prueba, ya que esta es una característica crítica dentro del sistema que
garantiza la confiabilidad y seguridad de la información dentro del sistema.
Casos de prueba:
Prueba Éxito
No se ingresan datos en los campos y El usuario entra al sistema.
se hace login.
Se debe ingresar una identificación La aplicación permite el login del
válida y contraseña errónea usuario con la identificación descrita.
Se debe ingresar una identificación La aplicación permite el login de
errónea y una contraseña de usuario usuario.
valida.
Se debe ingresar datos de La aplicación permite el login de
identificación y contraseña erróneas usuario.
Pruebas de integración
Este modulo se integrara por completo con el modulo anterior de creación de
usuarios, de la misma manera que el anterior en forma ascendente.
Casos de prueba:
Prueba Éxito
Se ingresara un usuario valido dentro Se puede navegar dentro del sistema
del sistema desde distintas terminales como usuario autenticado desde cada
web. una de las terminales web.
Se hará login por cada tipo de usuario La información no corresponde al tipo
y se verificara la información personal y rol del usuario autenticado.
Página 137 de 169
de cada uno.
Se modificara la contraseña de un El usuario entra al sistema de forma
usuario, se terminara la sesión, y se exitosa.
conectara con el mismo usuario y la
antigua contraseña en otra terminal.
Se modificara la contraseña de un El usuario no logra acceder al sistema.
usuario, se terminara la sesión, y se
conectara con el mismo usuario y la
nueva contraseña en otra terminal.
Subsistema móvil
1. Pruebas de interfaz:
Se verificaran los flujos de navegación desde la ventana de login al menú
principal respectivo de auxiliar médico y medico general.
2. Pruebas de la estructura de datos locales:
Los usuarios activos en el sistema deben corresponder a usuarios que han
hecho login valido, se puede hacer esta verificación dentro de la base de datos
en tiempo de ejecución.
3. Condiciones limite:
Realizar login desde la misma terminal móvil, varias veces, saliendo y entrando
al sistema sin cerrar la aplicación para verificar memoria en el dispositivo.
4. Caminos independientes:
Se validara de igual manera que en la prueba de interfaz. Adicional de las
alertas necesarias cuando el usuario no se autentica de forma correcta dentro
del sistema.
5. Camino de manejos de errores:
Se corregirán todos los errores encontrados durante la evaluación de los casos
de prueba, ya que esta es una característica crítica dentro del sistema que
garantiza la confiabilidad y seguridad de la información dentro del sistema.
Casos de prueba:
Prueba Éxito
Se debe ingresar ambos campos La aplicación entra al menú principal.
nulos en el formulario de login.
Se debe ingresar una identificación La aplicación permite el login del
válida y contraseña errónea usuario con la identificación descrita.
Se debe ingresar una identificación La aplicación permite el login de
errónea y una contraseña de usuario usuario.
valida.
Se debe ingresar datos de La aplicación permite el login de
identificación y contraseña erróneas usuario.
Se iniciara sesión y se cerrara sesión La aplicación se torna lenta, el estado
varias veces en el sistema sin cerrar la de la memoria en uso aumenta. (Para
aplicación. esta prueba se puede usar el memory
manager del WTK).
Pruebas de integración.
Página 138 de 169
El modulo de autenticación se debe integrar en forma ascendente con los
módulos completos anteriormente desarrollados. La parte crítica se centraliza
en el manejo de las ventanas que sucederá en el paquete de edu.vista.
Se repetirá las pruebas de interfaz descritas anteriormente.
Inspección del diseño
Se puede revisar si Django cuenta ya con un sistema de autenticación de
usuarios que se puede utilizar fácilmente, también se debe evaluar este para la
compatibilidad con el móvil.
La autenticación deberá ser un servicio web registrado.
La autenticación también debería devolver la cookie de una vez, solo se tendría
una cookie activa por usuario, los tiempos de validez de la cookie no se han
definido, sin embargo deberían ser suficientes para que el médico desde el
móvil pueda realizar una consulta y enviarla sin hacer mas conexiones que
estas, (promedio de 20 mins).
GESTIONAR USUARIOS
Este modulo tiene la función de manejar las cuentas de usuario establecidas en
el sistema, su creación y modificación, también de verificar que cada usuario
posea sus funciones respectivas.
Según el análisis del dominio existen 7 actores del sistema, sin embargo no
todos estos actores son usuarios del sistema, para cada uno de los usuarios
validos dentro del sistema existen unas reglas y ciertos permisos de
información respectivos dentro de esta característica que se describen a
continuación:
Administrador General:
o Acceder y modificar información de la cuenta.
o Acceder a información de entidades administradoras.
o Acceder a información de entidades prestadoras de salud.
Administrador Entidad Administradora:
o Acceder y modificar información personal.
o Crear nuevo administrador de citas.
o Acceder a información de contratos con entidades prestadoras de
salud.
Administrador Entidad Prestadora de salud:
o Acceder y modificar información personal.
o Crear nuevo personal médico.
o Crear nuevo médico general.
o Acceder a información del personal médico.
o Acceder a información del médico general.
o Contratar personal médico.
o Contratar médico general.
o Terminar contrato personal médico.
o Terminar contrato médico.
Administrador de citas:
o Acceder y modificar información personal.
Personal Medico:
Página 139 de 169
o Acceder y modificar información personal.
Medico General:
o Acceder y modificar información personal.
Los pacientes no se incluyen porque no acceden directamente al sistema y por
tanto no son usuarios.
Se puede revisar el modelo general donde se puede observar esta jerarquía de
usuarios en el sistema web.
Diagramas de secuencia:
En el repositorio (pendiente a subirlos a este apartado al finalizar la revisión)
Descripción de clases y métodos
Según los usuarios descritos anteriormente se deberán implementar las
siguientes operaciones:
Usuario-clase Vistas-métodos Descripción
Administrador Ingresar datos de nuevo El administrador general debe ingresar los
General Administrador de datos de un administrador de entidad
entidad administradora administradora al momento de crear una
asociado. entidad administradora, como parte de la
creación de la misma, se desplegara un
formulario donde se ingresaran los datos del
nuevo administrador asociado según IRQ-03.
Ingresar datos de nuevo El administrador general debe ingresar los
administrador de entidad datos de un administrador de entidad
prestadora de salud prestadora de salud al momento de crear una
asociado. entidad prestadora de salud, como parte de la
creación de la misma, se desplegara un
formulario donde se ingresaran los datos del
nuevo administrador asociado según IRQ-02.
Modificar información El administrador general puede cambiar su
Personal. información personal, IRQ-01.
Acceder a información El administrador general puede ver su propia
personal. información personal. IRQ-01.
Cambiar contraseña. El administrador general puede cambiar su
contraseña.
FRQ-15
Página 140 de 169
Administrador Crear nuevo El administrador de la entidad administradora
Entidad administrador de citas. puede crear nuevos usuarios de tipo
Administradora administrador de citas, esta información será
añadida mediante un formulario de creación de
administrador de citas que contiene la
información respectiva según IRQ-07.
Modificar información El administrador de Entidad Administradora
Personal. puede cambiar su información personal, IRQ-
03.
Acceder a información El administrador de Entidad Administradora
personal. puede ver su propia información personal. IRQ-
03.
Cambiar contraseña. El administrador de Entidad Administradora
puede cambiar su contraseña.
FRQ-15
Administrador Crear nuevo Personal El administrador de entidad prestadora de
Entidad medico salud puede crear nuevos usuarios de tipo
Prestadora de personal médico, la información se ingresara
salud mediante un formulario de registro que
contiene la información según el IRQ-04.
Crear nuevo Medico El administrador de entidad prestadora de
General salud puede crear nuevos usuarios de tipo
médico general, la información se ingresara
mediante un formulario de registro que
contiene la información según el IRQ-04.
Modificar información El administrador de Entidad prestadora de
Personal. salud puede cambiar su información personal,
IRQ-02.
Acceder a información El administrador de Entidad prestadora de
personal. salud puede ver su propia información
personal. IRQ-02.
Cambiar contraseña. El administrador de Entidad prestadora de
salud puede cambiar su contraseña.FRQ-15
Administrador Modificar información El administrador de citas puede cambiar su
de citas Personal. información personal, IRQ-07.
Acceder a información El administrador de citas puede ver su propia
personal. información personal. IRQ-07.
Cambiar contraseña. El administrador de citas puede cambiar su
contraseña.FRQ-15
Personal Medico Modificar información El personal médico puede cambiar su
Personal. información personal, IRQ-04.
Página 141 de 169
Acceder a información El personal médico puede ver su propia
personal. información personal. IRQ-04.
Cambiar contraseña. El personal médico puede cambiar su
contraseña.FRQ-15
Medico General Modificar información El personal médico puede cambiar su
Personal. información personal, IRQ-04.
Acceder a información El administrador de citas puede ver su propia
personal. información personal. IRQ-04.
Cambiar contraseña. El administrador de citas puede cambiar su
contraseña.FRQ-15
Permisos de usuario
Para este modulo en especial se definen los permisos de cada uno de los
usuarios sobre la información de los demás usuarios y sobre la información del
paciente.
Usuario información Permisos
consulta modificación inserción
Administrador Administrador general X X -
General Administrador Entidad X - X
Administradora
Administrador Entidad X - X
Prestadora de salud
Administrador de citas - - -
Personal Medico - - -
Medico General - - -
Paciente - - -
Administrador Administrador general - - -
entidad Administrador Entidad X X X
Administradora Administradora
Administrador Entidad - - -
Prestadora de salud
Administrador de citas X X X
Personal Medico - - -
Medico General - - -
Paciente X X -
Administrador Entidad Administrador general - - -
Prestadora de salud Administrador Entidad - - -
Administradora
Administrador Entidad X X X
Prestadora de salud
Administrador de citas - - -
Personal Medico X X X
Medico General X X X
Paciente - - -
Administrador de citas Administrador general - - -
Página 142 de 169
Administrador Entidad - - -
Administradora
Administrador Entidad - - -
Prestadora de salud
Administrador de citas X X X
Personal Medico - - -
Medico General X - X
Paciente X - X
Personal Medico Administrador general - - -
Administrador Entidad - - -
Administradora
Administrador Entidad - - -
Prestadora de salud
Administrador de citas - - -
Personal Medico X X X
Medico General - - -
Paciente X - X
Medico General Administrador general - - -
Administrador Entidad - - -
Administradora
Administrador Entidad - - -
Prestadora de salud
Administrador de citas - - -
Personal Medico - - -
Medico General X X X
Paciente X X X
Plan de pruebas
Pruebas unitarias
1. Pruebas de interfaz:
En los formularios de creación de usuarios se deben verificar la
obligatoriedad de los datos según los casos correspondientes, y que
cada ventana se conecte con la descrita según el flujo de información en
los diagramas de navegación.
2. Pruebas de la estructura de datos locales:
Se debe verificar mediante inspección que los datos agregados durante
cada una de las funciones del modulo son correctamente agregados a la
base de datos.
3. Condiciones limite:
Se deben ingresar datos de usuarios con nombres similares, nombres
iguales, identificaciones similares e identificaciones iguales en distintos
roles.
4. Caminos independientes:
Se deben ejecutar todos los caminos posibles por donde se ha
planteado la ejecución normal del modulo desde cada uno de los
usuarios planteados.
5. Camino de manejos de errores:
Página 143 de 169
Se verifican que se traten los errores en cada una de las interfaces y
agregación de datos, como contraseñas nulas, valores nulos, tipos de
datos incorrectos y errores de conexión a la base datos.
Casos de prueba:
Prueba Éxito
Se deben crear dos usuarios del La aplicación permite la creación del
mismo tipo con la misma identificación segundo usuario.
y el mismo rol. CRQ-01
Se deben modificar la información La aplicación permite los cambios.
personal de cada usuario y dejar
campos obligatorios nulos.
Se debe modificar la contraseña de un La aplicación cambia la contraseña.
usuario con una contraseña nula.
Se debe modificar la contraseña de un La aplicación cambia la contraseña.
usuario con una contraseña igual al
número de identificación del usuario.
Se verifica la navegación de la ruta deExiste al menos un link roto. O se
cada usuario. presenta un mensaje 404 desde el
navegador.
Se debe crear un nuevo usuario con La aplicación crea el usuario.
información obligatoria nula.
Posterior a la creación de un usuario La base de datos no contiene uno o
se debe consultar directamente la más datos ingresados durante la
base de datos donde cada dato debe creación del usuario.
estar correctamente referenciado.
Se deben crear usuarios con La aplicación no permite la creación
identificación similares, Ej: 410005 y de alguno de los dos usuarios.
410050
Se deben crear usuarios con La aplicación no permite la creación
identificaciones aleatorias que no de alguno de los usuarios.
existan ya.
Se deben ingresar valores en los La interfaz permite el ingreso de los
campos de los formularios más datos.
extensos de lo que se permite en la
base de datos.
Pruebas de integración:
La integración de este modulo se seguirá trabajando de forma ascendente.
Este modulo se integrara con el modulo de gestión de entidades en la parte de
la creación de nuevas entidades tanto administradoras como prestadoras de
salud, donde se debe posterior registro de la entidad crear un nuevo
administrador asociado.
Luego se realizara una integración con el modulo principal donde se podrán
hacer los ingresos de cada uno de los usuarios al sistema.
Casos de prueba:
Prueba Éxito
Se debe crear una nueva entidad La aplicación no muestra el formulario
Página 144 de 169
administradora. de nuevo administrador de entidad
administradora.
Se debe crear una nueva entidad La aplicación no muestra el formulario
prestadora de salud. de nuevo administrador de entidad
prestadora de salud.
Inspección del dominio:
El usuario administrador general es solo uno y ya existe, no se puede eliminar
ni crear.
Los usuarios administrador entidad administradora y administrador entidad
prestadora de salud, son creados automáticamente cuando se crea una entidad
administradora y una entidad prestadora de salud respectivamente, para esto
cuando se cree una nueva entidad se deberá lanzar el formulario de creación
de nuevo administrador respectivo, para completar la correcta creación de
estas entidades.
Como este modulo no contiene autenticación solo se deberá escribir el ID del
usuario dentro del sistema para accederlo.
Los requerimientos FRQ-14 (Registrar información personal médico en el
sistema), FRQ-15 (Cambiar Contraseña) y FRQ-34 (Administrar Entidad
prestadora de salud), pueden servir como referencia.
Los requerimientos de información ya se encuentran contemplados en la base
de datos.
Revisar reglas del negocio: RN.1, RN.2, RN.3, RN.5 y RN.15.
Administración de entidades
GESTIONAR ENTIDADES
Administración de Agenda
CONSULTAR AGENDA MEDICA WEB
ADMINISTRAR CITAS MÉDICAS
CONSULTAR AGENDA MEDICA MÓVIL
Para realizar una consulta médica se debe tener en cuenta la información
contemplada en el IRQ-15 donde se describe la información de las citas
medicas, también es necesario consultar el CRQ-5, es claro que un médico no
puede tener más de una cita médica por vez (o cada cierto intervalo de tiempo),
la información será solicitada al servidor y se desplegara en una lista de pares
(horas y paciente) donde se describe que paciente será atendido a que hora.
Diseño
Diagramas de secuencia
Página 145 de 169
Clases y métodos
Clase Método Descripción
edu.presentacion.Agenda show() Despliega una lista de pares, hora-paciente,
por día.
cargarInformacion() Genera la lista correspondiente del día
obteniendo la información de la clase
Agenda del médico.
actionPerformed() Depende del comando se pueden presentar
los siguientes comportamientos:
1. Ver detalles: llama al método
mostrarInfoCita() de Dialog.
2. Día Anterior: carga la lista de citas del día
anterior en la agenda.
3. Día Siguiente: carga la lista de citas del
día siguiente en la agenda.
4. volver: llama al método
cambiarFormulario() del ControladorVistas
con parámetro el menú principal.
edu.presentacion.Dialog mostrarInfoCita() Despliega al usuario un Dialog donde se
muestra la información respectiva de la
cita.
edu.presentacion.Menu- consultarAgenda() Invoca una conexión para obtener los datos
Principal de las citas del médico, si no existe una
agenda asociada al médico.
actionPerformed() Captura el evento que dispara el método
consultarAgenda().
destruir() Se liberan recursos consumidos por esta
clase.
edu.presentacion.Contro- cambiarFormulario() Se debe agregar el cambio de formulario
ladorVistas para desplegar la agenda médica.
edu.presentacion.Carga show() Se presenta una pantalla al usuario donde
se le informa que se está realizando una
conexión.
edu.conexion.Administra- invocarServicion(id) Dentro de la invocación al servicio se creara
dorConexiones e iniciara la conexión por vía webservice
mediante la clase manejadorWSDL.
edu.conexion.Manejador- iniciarConexion() Se debe verificar el tipo de conexión, en
WSDL este caso de agenda medica y se enviara la
consulta respectiva al servidor.
edu.logica.Medico setAgenda(agenda) Una vez se logran cargar los datos se deben
guardar estos en la agenda del médico
activo en el sistema.
edu.logica.Agenda Agenda(citas[]) La agenda se crea con un arreglo de citas,
para ser consultada luego por la agenda del
paquete presentación.
getCitas() Se devuelve el arreglo de citas de la clase.
edu.logica.Cita setInfoCita(info) Se inserta la información respectiva de la
cita según IRQ-15.
getInfoCita() Se devuelve la información de la cita como
Página 146 de 169
un String.
Plan de pruebas:
1. Pruebas de interfaz:
Se verificaran los flujos de navegación desde la ventana de menú
principal del médico general, ventana de la agenda, dialogo de carga y
los detalles de la cita.
2. Pruebas de la estructura de datos locales:
La información de las citas médicas que se guardan durante la consulta
de la agenda debe coincidir con la información que se encuentra
almacenada en la base de datos.
3. Condiciones limite:
Se debe realizar una consulta exhaustiva de días, de manera que se
evalué la capacidad de almacenamiento del móvil antes de colapsar por
falta de recurso.
4. Caminos independientes:
Se validara de igual manera que en la prueba de interfaz. Realizando
más que todo en la clase de edu.presentacion.Agenda navegaciones
entre distintos días, verificando que la información de las citas sea la
correspondiente a la que se pide en consulta.
5. Camino de manejos de errores:
Se corregirán y evaluaran todos los errores encontrados durante la
evaluación de los casos de prueba, se deberán además crear
excepciones para los eventos que no puedan ser corregidos y tengan
que ver más que todo con problemas de conexión, procesamiento y
memoria.
Casos de prueba
Prueba Éxito
Se solicita la agenda de un día en el La agenda despliega citas que el
que el médico no labora. médico tiene asignadas para ese día.
Se solicita la agenda de un día en el La agenda despliega citas que el
que el médico labora pero no tiene médico tiene asignadas para ese día.
citas asignadas.
Se solicita que se cargue la La agenda no despliega información
información del día siguiente en ladel día siguiente, o despliega
agenda. información que no es la correcta.
Se solicita que se cargue la La agenda no despliega información
información del día anterior en la del día anterior, o despliega
agenda. información que no es la correcta.
No se despliega ninguna información
Se solicitan los detalles de una cita
programada. al respecto, o se despliega
información que no es la correcta.
Se debe navegar varias veces entre La aplicación colapsa o muestra error
distintas fechas. de memoria.
Inspección de diseño:
Página 147 de 169
El intervalo de citas que se trae debe estar definido en el Web Service, lo
recomendable es traer las citas del día actual en el teléfono mas dos días antes
y tres días después de esta fecha, sin embargo aun está pendiente de saber
cuanta información es el equivalente a estos días, en caso tal de que sea
mucha se medirá por kilobytes transferidos, no sobrepasando los 5kb por
transacción.
Para evitar una posible saturación de la información se pueden eliminar citas
de la agenda medica cada vez que se realiza una consulta, esto también
depende de la implementación y los resultados que arrojen las pruebas.
Como un requerimiento adicional es posible que el médico seleccione una
fecha en la cual desea ver su agenda, no existe en el dominio algo que limite
esta consulta, pero tampoco que la haga necesaria, si se encuentra la
oportunidad de implementarla sin mucho esfuerzo se debe implementar.
Para mayor información se pueden consultar los requerimientos FRQ-01, FRQ-
02 y FRQ-03.
Administración de pacientes
ADMINISTRAR ALARMAS
AFILIAR PACIENTES
Administrar conexión
GESTIONAR MENSAJE HL7
GESTIONAR MENSAJE SOAP
SOAP (Simple Object Access Protocol) es un protocolo estándar que define
cómo dos objetos en diferentes procesos pueden comunicarse por medio de
intercambio de datos XML.
HL7 messaging es un protocolo de mensajería estándar para el intercambio de
información médica, el cual usaremos a través de servicios web, usando el
protocolo SOAP, que es el más usado comúnmente para estas
implementaciones.
Descripción de Librerías y Herramientas
Web:
SOAPLIB: Es una librería desarrollada en python para la generación y
reconocimiento de mensajes SOAP, mediante el uso de un decorador simple
para métodos normales de python.
Móvil:
Página 148 de 169
Stub Generator: Es una herramienta incluida en el WTK de Sun MicroSystems
que genera métodos stub para el uso de cada servicio descrito en un WSDL de
entrada, generando la interoperabilidad con servicios web.
JSR172: Librería para el manejo de web services en la que se basa el Stub
Generator para crear los métodos stub.
Descripción de Clases
DjangoSoapAPP: Hereda de la clase SimpleWSGISoapApp, y de la cual
hereda la clase GeneradorWSDL, esta clase es la que genera y parsea los
mensajes SOAP para ser trabajados
Descripción de Métodos
El decorador @soapmethod es usado para declarar los métodos de servicio, y
para declarar los serializadores usados para automáticamente manejar la
petición de los serializadores y la generación del WSDL para el servicio.
Los serializadores deben ser de alguno de estos tipos: Primitivos, Collecciones,
Clase, Adjunto.
Plan de Pruebas
Cada metodo que lleve el decorador @soapmethod debe tener al menos 1
atributo _results el cual se describe de la siguiente forma
_results=soap_types.Array(soap_types.String)
Donde lo que se encuentra dentro del arreglo es los tipos de dato que seran
enviados como respuesta, todas las respuestas se haran por medio de un
arreglo, los otros datos del decorador son los tipos de dato de entrada que se
daran, en el mismo orden del metodo.
Para probar esto se debe generar el servicio, generar la pruebas para el
servicio, y probarlo como se mostro en la administracion de conexión.
Ademas se deben generar los stubs mediante el stub generator para los
servicios que corresponda y mostrar resultados similares a las pruebas
anteriores.
El stub generator, crea cada uno de los servicios descritos en el WSDL, como
un stub para java me, donde pueden ingresar todos los datos descritos en el
metodo.
Tambien se debe probar que el tipo de dato descrito en el decorador coincida
con los datos de entrada al metodo, pues python no usa tipos de dato y se
debe comprobar que el dato enviado es del mismo tipo que se va a utilizar en el
metodo.
GESTIONAR SERVICIOS WEB
La comunicación e interacción entre la interfaz grafica en el dispositivo móvil o
la interfaz web, y el backend donde se maneja la información médica como tal,
se efectúa a través de servicios web, puesto que además para poder hacer uso
del estándar HL7 el cual usa el protocolo SOAP se deben hacer uso de estos.
Página 149 de 169
Este modulo se encarga de generar el WSDL o Lenguaje de Descripción de
Servicios Web, que se encarga de servir de guía para aquellos sistemas que
deseen consumir los servicios web generados.
El WSDL es generado automáticamente por la librería soaplib, además de
agregar un decorador para definir los web services, al momento de
consumirlos, a nivel web se usa la librería SOAPPy o la el cliente de la librería
soaplib para hacer pruebas, ya que esta trae un proxy para el uso de servicios
web.
Clases
Se usa una clase GeneradorWSDL que herede de la clase DjangoSoapApp,
que se encuentra en el directorio raíz en el archivo generador_wsdl.py, la cual
a su vez hereda de la clase SimpleWSGISoapApp, que está en la librería
soaplib.wsgi_soap.
Esta clase tiene el método __call__ que retorna los valores modificados como
servicio web.
En el archivo de control urls.py se agregan las siguientes líneas para
especificar tanto el wsdl como la forma de llamar estos servicios.
(r'^conexion/', 'generador_wsdl.wsdl'),
(r'^conexion/service.wsdl', 'generador_wsdl.wsdl'),
Métodos
Los servicios que van dentro del WSDL, son funciones normales dentro de las
vistas o dentro de clases auxiliares que tienen de especial usar el decorador
@soapmethod(…, que a su vez sirve para definir los tipos de datos que
maneja el servicio.
Estos métodos funcionan tal cual como cualquier otro dentro de los views,
únicamente diferenciado por el decorador.
Para poder acceder al WSDL, se debe importar la librería soaplib.client
make_service_client, la cual se instancia como cliente y el método
server.wsdl(´´) de esta genera el WSDL de los métodos registrados
Listado de Web Services
Nombre Entrada Salida
Listar Citas Cedula medico, timestamp Horario medico en XML
inicio, timestamp fin
Crear Cita Cedula medico, fecha, hora, Error en caso de no poder, de
cedula paciente, sede? lo contrario “True”
Eliminar Cita Cedula medico, fecha, hora, Error en caso de no poder, de
cedula paciente, sede? lo contrario “True”
Información Cita ID Cita Informacion Cita en XML
Historia Clínica Cedula Paciente, Cedula Información de la HC en XML,
Personal (Para el log), podría ser incluso CDA ..
Modificación HC HC en XML modificada (hl7) Error en caso de no poder, de
lo contrario “True”
Compartir Caso ID HC, Cedula Medico Error en caso de no poder, de
lo contrario “True”
Casos Anónimos Palabras de Búsqueda Casos Anónimos en XML
(opcional), cedula Medico
Página 150 de 169
Agregar Evento Mensaje HL7 Error en caso de no poder, de
lo contrario “True”
Autenticar Usuario Identificación de usuario y Un valor True y una cookie del
contraseña usuario respectivo en caso de
que sea válido, de lo contrario
un False y un valor NONE.
Procedimiento de Inclusión
Para incluir un servicio web nuevo se debe además de agregar el decorador al
método, independientemente de donde este se encuentre, agregar la
importación del método dentro de la clase GeneradorWSDL, que se encuentra
en la raíz del proyecto en generador_wsdl.py, el cual se encarga de generar el
WSDL general para el proyecto.
Plan de Pruebas
Pruebas Unitarias
Pruebas de sintaxis: Se debe probar que el servicio web este escrito
adecuadamente para ser incluido dentro del wsdl, es decir no debe generar
errores al crear el WSDL, esto se debe probar primero desde web, viendo
que el WSDL generado en el url /conexion/service.wsdl debe estar
correctamente estructurado, ademas se debe generar los stubs con el stub
generator el cual no debe generar errores.
Pruebas de afiliación: Se debe afiliar correctamente los servicios al WSDL y
estos se deben ver reflejados en el.
Pruebas por servicio: A cada servicio se le deben hacer 2 pruebas una para
el método dependiendo de lo que se requiera que haga, y otra mediante el
siguiente código en la consola de Python:
Se importan las librerías y se crea el cliente de prueba
>>> from soaplib.client import make_service_client
>>> from generador_wsdl import GeneradorWSDL
>>> client =
make_service_client('http://localhost:8000/conexion/',
GeneradorWSDL())
Se procede a probar el servicio como tal
>>> client.miMetodo('datos de prueba')
El cual nos debe devolver los datos de acuerdo a las pruebas diseñadas.
Pruebas por servicio móvil, para aquellos servicios que lo requieran se deben
generar las pruebas unitarias usando el stub generator.
SINCRONIZAR INFORMACIÓN GUARDADA
Página 151 de 169
ADMINISTRACIÓN DE LOG
Administración de Historia Clínica
GESTIONAR CASO CLÍNICO
GESTIONAR CONSULTA GENERAL
Este conjunto abarca características primordiales para el núcleo central del
prototipo, puesto que se encarga de todo lo que tiene que ver con el
tratamiento de la consulta médica en el dispositivo móvil, la visualización de la
historia clínica de un paciente, y la actualización de la misma.
Respecto a la información del dominio y el tratamiento de historias clínicas se
puede observar la sección de tratamiento de historias clínicas en la sección de
historia clínica del contexto en telemedicina. Allí se especifica la forma en la
que estará estructurado el proceso para la realización de la consulta general, y
las secciones en que se dividirán los formularios (Anamnesis, información
básica de la consulta, formula GPCAVE, revisión por sistemas, examen físico,
diagnostico y tratamiento).
Las características involucradas en este conjunto son:
solicitar Historia clínica.
registrar consulta medico general
agregar antecedentes
cerrar consulta medico
Diseño
Diagrama de secuencia En el repositorio
Diagrama de clases:
agregada una nueva clase, llamada InicioConsulta, en el paquete
edu.presentacion, esta clase hereda de Dialog, y se usara para solicitar al
medico la información del paciente al cual va a atender.
Se agrego un nuevo método a la clase padre Formulario, llamado
validarInformacion(), q se encargar de validar los datos ingresados en un
formulario por el usuario.
Página 152 de 169
Se creo el método enviarConsulta(), en el formulario de consulta general,
será usado para enviar una consulta general al servidor.
Se agrego la variable listadoHistorial en la central de datos, sera un array de
string que contiene información acerca del historial del paciente.
Se agregaron los método actionCommand(), y validarInformacion, al dialogo
de nuevoAntecedente.
Descripción de clases y métodos:
Caracteristica: solicitar historia clínica
Clase Métodos Descripción
administradorCo- InvocarServicio() Este método debe realizar una conexión al
nexiones servidor usando web service para poder
Con id, para listado traer la información de la historia clínica de
de todo el historial un paciente.
clínico de un
paciente. Debe recibir una constante de tipo byte que
indica el tipo de servicio o conexión que
debe hacerse. En este método se asignaran
los parámetros necesarios para que la
conexión al web service funcione,
(idPaciente).
Deberá devolver la información básica
(fecha y diagnostico, idHC) de todas las
entradas que haya tenido un paciente en el
sistema.
El listado debe guardarse en la variable
listadoHistorial, de la central de datos
Página 153 de 169
InvocarServicio() Este método debe realizar una conexión al
servidor usando web service para poder
Con id, para detalles traer los detalles de un apartado de la
de un historial historia clínica de un paciente. Debe recibir
clínico determinado. una constante de tipo byte que indica el
tipo de servicio o conexión que debe
hacerse. En este método se asignaran los
parámetros necesarios para que la
conexión al web service funcione,
(idPaciente, idHC).
También debe verificar que no se haya
hecho la conexión antes, para hacerla, de lo
contrario no se conectara y usara el objeto
instanciado por una conexión previa
Deberá devolver la información de la última
consulta realizada al paciente a través del
sistema para guardarla en la central de
datos, en el objeto de paciente activo.
Paciente setHistoriaClinica() Aquí deberá guardarse la información que
se transfirió como resultado de la petición
de la historia clínica de un paciente
especifico.
El método recibe como parámetro un
objeto de tipo HistoriaClinica
getHistoriaClinica() Este método será usado por todas las
interfaces graficas para obtener algún tipo
de información concerniente a la historia
clínica
Debe retornar un objeto de tipo
HistoriaClinica
FormularioCon- actionPerformed () Desde cualquiera de las clases mencionadas
sultaGeneral podrá realizarse una petición de la consulta
de la historia clínica.
FormularioGPCA-
VE El evento deberá ejecutar una conexión
para traer los detalles de todo el historial
FormularioRevi- clínico de un paciente, y abrir el listado de
sionSistemas selección del formularioHistorialMedico.
FormularioExa-
menFisico
Página 154 de 169
FormularioHisto- FormularioHistorial Este método cargara el listado de datos
rialMedico Medico() básicos de todo el historial medico de un
paciente en el formulario.
Los datos los consultara de la central de
datos.
actionPerformed () Este método se encargara de realizar la
conexión para traer los detalles de un
historial clínico determinado.
FormularioHisto- actionPerformed () Este método encargara desplegar los
riaClinica formularios necesarios para mostrar las
información concerniente al apartado de la
historia clínica que el usuario selecciono
(GPCAVE, SISTEMAS, FÍSICO, etc).
Característica: registrar consulta medico general
Clase Métodos Descripción
administradorCo- InvocarServicio() Este método realizar una conexión al servidor
nexiones usando web service para poder traer la
Con id, para validar información de la autenticidad de un paciente.
que el paciente se
encuentre registrado Debe recibir una constante de tipo byte que
en el sistema. indica el tipo de servicio o conexión que debe
hacerse. En este método se asignaran los
parámetros necesarios para que la conexión al
web service funcione, (idPaciente).
Deberá devolver el listado de antecedentes si el
paciente se encuentra en el sistema, o false, si
no esta registrado.
Los antecedentes se guardan en la historia
clínica del paciente actual.
CentralDatos setConsultaActiva() Aquí deberá guardarse la información
correspondiente a la consulta activa que se este
antendiendo.
getConsultaActiva() Este método será usado por todas las interfaces
graficas para obtener algún tipo de información
concerniente a la consulta activa.
Página 155 de 169
FormularioAnam- cargarInformacion () Este método se encarga de precargar los datos
nesis correspondientes a la consulta actual, deberá
usar el objeto consulta actual de la central de
FormularioInfo- datos, y precargar los datos concernientes a
Basica cada tipo de interfaz.
FormularioGP- Para el caso de información básica, los datos
CAVE deben tomarse del paciente actual.
FormularioRevi-
sionSistemas validarInformacion() Este método deberá validar la integridad de la
información que se encuentra en un
FormularioExa- determinado formulario, y alojarla en el objeto
menFisico consulta actual de la clase central de datos.
FormularioDiag- Para el caso de información básica, los datos
nostico deben ponerse en paciente actual.
FormularioCon- checkProcedimiento() Este método sirve para validar que el medico
sultaGeneral haya pasado por todos los pasos que son
necesarios para la consulta, y así permitir la
asignación del diagnostico y el tratamiento.
Recibe un valor booleano, y un id para verificar
q accion realizo
actionPerformed () Este método se encargara de realizar la
administración de vistas de la consulta general.
Caracteristica: agregar antecedentes
Clase Métodos Descripción
administradorCone InvocarServicio() Este método realizar una conexión al servidor
xiones usando web service para poder guardar un
Con id, para guardar nuevo antecedente.
un nuevo antecedente
Debe recibir una constante de tipo byte que
indica el tipo de servicio o conexión que debe
hacerse. En este método se asignaran los
parámetros necesarios para que la conexión al
web service funcione, (tipo antecedente, id
paciente, descripción del antecedente).
Devolverá 1 si la inserción fue correcta, o 0 de
lo contrario.
FormularioAnteced cargarInformacion () Aquí se traerá toda la información de los
entes antecedentes del paciente, a través de la
historia clínica del paciente actual, ubicado en
la central de datos.
Página 156 de 169
actionPerformed () Con este método y el comando de nuevo
antecedente, se abriara el
dialogNuevoAntecedente.
También es usado para ver los detalles de un
antecedente.
NuevoAntecedente validarInformacion() Este método deberá validar la integridad de la
información dada por el medico, acerca del
nuevo antecedente.
actionPerformed () En este método debe hacerse una llamado a
validar información, si el resultado es positivo,
se hara la petición de conexión al administrador
de conexiones para registrar el nuevo
antecedente.
Página 157 de 169
Caracteristica: cerrar consulta medico
Clase Métodos Descripción
administradorCone InvocarServicio() Este método realizar una conexión al servidor
xiones usando web service para poder enviar el
Con id, para envío de registro de una nueva consulta.
nueva consulta
Debe recibir una constante de tipo byte que
indica el tipo de servicio o conexión que debe
hacerse. En este método se asignaran los
parámetros necesarios para que la conexión al
web service funcione, (consulta actual, medico,
paciente).
Devolverá 1 si la inserción fue correcta, o 0 de
lo contrario.
formularioConsulta actionPerformed () Con este método y el comando de terminar
General consulta se abrirá un dialogo de confirmación
de fin de consulta, y si se obtiene un resultado
positivo se hara la petición de envío de la
consulta al administrador de conexiones,
usando la consulta actual, de la central de
datos.
1. Plan de pruebas:
Pruebas unitarias:
Pruebas de interfaz, se deben realizar pruebas unitarias a las clases
FormularioGPCAVE, FormularioRevisionSistemas, FormularioExamen-
Fisico, FormularioAnamnesis, FormularioInfoBasica, FormularioDiag-
nostico, FormularioHistoriaClinica, NuevoAntecedente, que permitan
asegurar el flujo correcto de la información introducida por el usuario
hacia la lógica de la aplicación. (datos no nulos, caracteres especiales, y
mayúsculas).
Pruebas a las estructuras de datos resultantes, se debe verificar que las
variables consultaActual, PacienteActual, ubicadas en la central de datos
contengan la información correcta, y se mantenga durante el flujo
definido en el diagrama de secuencia, para esto, se deberá validar dicha
información en los test de cada uno de los métodos llamados en el
diagrama de secuencia.
Pruebas de límite, y procesamiento, se Deberá comprobar que la carga
de información en el dispositivo móvil durante las conexiones a los web
services sea la adecuada con respecto al tiempo de transmisión de
información, y memoria en el móvil, para eso ninguna conexión deberá
sobre pasar los 10 segundos.
Prueba de caminos básicos, se deberá verificar el modelo plateando en
el diagrama de secuencia, y asegurar que cada uno de los métodos allí
descritos es llamado por lo menos una vez.
Prueba de caminos de manejos de errores, se deberá forzar un
lanzamiento de todas las excepciones descritas en un los bloques try
Página 158 de 169
catch en los métodos validadotes de información, y realizar un
tratamiento conveniente a cada uno de ellos.
Pruebas de integración:
Al integrar este conjunto de características con el conjunto de características
“desplegar información de estándares” deberá tenerse en cuenta:
Que el funcionamiento de los dos módulos por separados sea el
adecuado. (hayan superado todos los test unitarios)
El acoplamiento debe realizarse entre el estándar CIE10 y la sección de
diagnostico en la consulta general.
El resultado deberá permitir al usuario realizar una búsqueda en el
estándar CIE10 y agregar la información encontrada a un campo
especial en el diagnostico dedicado al a información del CIE10.
Luego del acoplamiento deberá rectificarse que el sistema funcione de
manera óptima.
Notas
La historia clínica deberá guardarse en el objeto paciente que se
encuentra disponible en la central de datos.
La formula GPCAVE solo será visible únicamente si el paciente es
mujer.
Para el despliegue de la información de la historia clínica, y para el
llenado de una nueva consulta se rehusaran los formularios.
SOLICITAR SERVICIOS
GESTIONAR EVENTOS
Administración de repositorio móvil
DESPLEGAR INFORMACIÓN DE ESTÁNDARES
Este conjunto abarca características que permitirán al usuario una interacción
con la aplicación mucho mas fácil, amigable e intuitiva, permitirá realizar
búsquedas y usar Información en el dispositivo móvil referente a los estándares
CIE-10, CUPS, y POS; sin embargo dadas las limitaciones físicas y técnicas de
los dispositivos móviles, se usaran versiones reducidas de los estándares CIE-
10(maneja cerca de 13.000 registros, con la versión reducida se usaran cerca
de 2000 registros) , y CUPS (con algo mas de 16000 registros). Estas
versiones reducidas si bien no son completas, involucran los registros mas
usados habitualmente.
CIE-10: el estándar CIE-10 estará disponible dentro de la aplicación cuando el
medico quiera realizar un diagnostico a un paciente, tendrá la opción de
Página 159 de 169
realizar una búsqueda por código, filtrar y agregar al diagnostico la información
relevante para el paciente en un determinado caso.
CUPS: la información de el estándar cups estará disponible para los
paramédicos y auxiliares siempre que estén realizando un procedimiento a un
paciente determinado, se permitirá realizar búsquedas de procedimientos de
acuerdo al código, y filtrar y usar la información relevante para el paciente en
una determinada situación.
POS: existirá un almacén de datos con información referente a los
medicamentos básicos contenidos dentro del POS disponible para que el
medico pueda realizar consultas por nombre, o por código del medicamento,
esta información podrá ser usada para facilitar la realización de formulas
medicas a los pacientes.
Diseño
Diagrama de secuencia:
En el repositorio
Descripción de clases y métodos
Feature: desplegar CIE 10
Clase Métodos Descripción
Diagnostico show() Este método permitirá mostrar el formulario de
diagnostico, junto con la opción de insertar
CIE10.
También mostrara información referente a la
búsqueda de CIE10, en caso de que existan
datos que mostrar en la central de datos
actionPerformed() Con este método capturamos el evento de
inserción de CIE10, y abrimos el dialogo llamado
ListaCIE10.
ListaCIE10 show() Despliega el dialogo, con un campo de texto y la
opción de búsqueda.
actionPerformed() Este método será usado para capturar el evento
de “buscar” generador por el usuario, luego de
la inserción de texto, desde aquí se realizara el
proceso de búsqueda ayudado por el manejador
de BD
mostrarResultados() Este método se encarga de mostrar los
resultados de la búsqueda realizada en la base
de datos móvil del estándar CIE10.
ManejadorDB buscarInfoEstandar() Este método debera recibir como parámetro el
Esta clase actuara criterio de búsqueda, y el nombre del estándar
Página 160 de 169
como una en el que debe realizarse la búsqueda.
fachada para los Desde acá debemos abrir el almacén CIE10,
administradores realizar la búsqueda, y cerrar el almacén.
de la base de Deberá devolver como parámetro, un objeto
datos, y debe con todos los datos encontrados por el criterio
implementar un de búsqueda.
patrón Singleton.
AdministradorCIE abrirAlmacen() Este método se encargara de abrir el Storage,
10 donde se encontrara la información del estándar
CIE10
buscarInfo() Este método recibe el criterio dado por el
usuario.
Debe encargarse de realizar la búsqueda en la
base de datos de CIE10, y de entregar
organizada la información filtrada.
cerrarAlmacen() Este método deberá cerrar el Storage de la base
de datos del estándar CIE10
AlmacenCIE10 readObject() Este método debe des-serializar la raíz del árbol
de objetos CIE10 guardados en la base de datos,
esto con el fin de poder realizar el proceso de
búsqueda.
Feature: desplegar CUPS
Clase Métodos Descripción
Evento show() Este método permitirá mostrar el formulario de
eventos, junto con la opción de insertar
procedimientos CUPS.
También mostrara información referente a la
búsqueda de CUPS, en caso de que existan datos
que mostrar en la central de datos
actionPerformed() Con este método capturamos el evento de
inserción de CUPS, y abrimos el dialogo llamado
ListaCUPS.
ListaCUPS show() Despliega el dialogo, con un campo de texto y la
opción de búsqueda.
actionPerformed() Este método será usado para capturar el evento
de “buscar” generador por el usuario, luego de
la inserción de texto, desde aquí se realizara el
proceso de búsqueda ayudado por el manejador
de BD
mostrarResultados() Este método se encarga de mostrar los
resultados de la búsqueda realizada en la base
de datos móvil del estándar CUPS.
Página 161 de 169
ManejadorDB buscarInfoEstandar() Este método deberá recibir como parámetro el
Esta clase actuara criterio de búsqueda, y el nombre del estándar
como una en el que debe realizarse la búsqueda.
fachada para los Desde acá debemos abrir el almacén CUPS,
administradores realizar la búsqueda, y cerrar el almacén.
de la base de Deberá devolver como parámetro, un objeto
datos, y debe con todos los datos encontrados por el criterio
implementar un de búsqueda.
patrón Singleton.
AdministradorCU abrirAlmacen() Este método se encargara de abrir el Storage,
PS donde se encontrara la información del estándar
CUPS
buscarInfo() Este método recibe el criterio dado por el
usuario.
Debe encargarse de realizar la búsqueda en la
base de datos de CUPS, y de entregar organizada
la información filtrada.
cerrarAlmacen() Este método deberá cerrar el Storage de la base
de datos del estándar CUPS
AlmacenCUPS readObject() Este método debe des-serializar la raíz del árbol
de objetos CUPS guardados en la base de datos,
esto con el fin de poder realizar el proceso de
búsqueda.
Feature: desplegar POS
Clase Métodos Descripción
Formula show() Este método permitirá mostrar el formulario de
pedido de medicamentos, junto con la opción de
insertar medicamentos contemplados en el POS.
También mostrara información referente a los
medicamentos que ya estén previamente
seleccionados por el medico.
actionPerformed() Con este método capturamos el evento de
inserción de medicamentos, y abrimos el dialogo
llamado ListaPOS.
ListaPOS show() Despliega el dialogo, con un campo de texto y la
opción de búsqueda por código, o por nombre.
actionPerformed() Este método será usado para capturar el evento
de “buscar” generador por el usuario, luego de
la inserción de texto, desde aquí se realizara el
proceso de búsqueda ayudado por el manejador
de BD
Página 162 de 169
mostrarResultados() Este método se encarga de mostrar los
resultados de la búsqueda realizada en la base
de datos móvil del estándar POS para
medicamentos.
ManejadorDB buscarInfoEstandar() Este método deberá recibir como parámetro el
Esta clase actuara criterio de búsqueda, el tipo de busqueda, y el
como una nombre del estándar en el que debe realizarse la
fachada para los búsqueda.
administradores Desde acá debemos abrir el almacén POS,
de la base de realizar la búsqueda, y cerrar el almacén.
datos, y debe Deberá devolver como parámetro, un objeto
implementar un con todos los datos encontrados por el criterio
patrón Singleton. de búsqueda.
Administrador- abrirAlmacen() Este método se encargara de abrir el Storage,
POS donde se encontrara la información del estándar
POS
buscarInfo() Este método recibe el criterio dado por el
usuario.
Debe encargarse de realizar la búsqueda en la
base de datos de medicamentos, y de entregar
organizada la información filtrada.
cerrarAlmacen() Este método deberá cerrar el Storage de la base
de datos del estándar POS
AlmacenCUPS readObject() Este método debe des-serializar la raíz del árbol
de objetos POS guardados en la base de datos,
esto con el fin de poder realizar el proceso de
búsqueda.
Plan de pruebas:
Pruebas unitarias:
Pruebas de interfaz, se deben realizar pruebas unitarias a las clases
ListCUPS, ListCIE10,ListPOS, que permitan asegurar el flujo correcto de la
información introducida por el usuario hacia la lógica de la aplicación. (datos
no nulos, caracteres especiales, mayúsculas).
Pruebas a las estructuras de datos resultantes, se debe verificar que las
variables resultCIE10, resultCUPS, resultaPOS, ubicadas en la central de
datos contengan la información correcta, y se mantenga durante el flujo
definido en el diagrama de secuencia, para esto, se deberá validar dicha
información en los test de cada uno de los métodos llamados en el
diagrama de secuencia.
Pruebas de limite, y procesamiento, se deberán probar los tres métodos de
búsqueda (POS, CIE10, CUPS) con el numero de registros máximo, y
verificar que el tiempo de respuesta sea mínimo, deberá considerarse un
limite de registros de búsqueda en caso de no tener resultados óptimos.
Prueba de caminos básicos, se deberá verificar el modelo plateando en el
diagrama de secuencia, y asegurar que cada uno de los métodos allí
descritos es llamado por lo menos una vez.
Página 163 de 169
Prueba de caminos de manejos de errores, se deberá forzar un lanzamiento
de todas las excepciones descritas en un los bloques try catch de
búsquedas, y validaciones de textos, y realizar un tratamiento conveniente a
cada uno de ellos.
Pruebas de integración:
Dado que este es el primer modulo desarrollado para el sistema móvil, no se
tiene planeado realizar pruebas de integración.
Notas:
Las búsquedas deben ser flexibles, por lo cual no se podrá filtrar con el
criterio exacto dado por el usuario, deben mostrarse todos los resultados
acordes al criterio dado.
El programador debe tener conocimiento previo de PERTS (motor de bases
de datos móvil), para poder realizar de forma adecuada esta
implementación.
Comentarios de desarrollo:
Al realizar pruebas de interfaz, se encontraron inconvenientes con el
estándar CUPS, por algunos caracteres especiales usados en la
descripción, para solucionarlo se hizo una supresión de dichos caracteres
en el documento usado para la precarga de los datos, también se
presentaros inconvenientes menores con el uso de las mayúsculas y el
texto predictivo de algunos celulares, la solución fue aplicar el método
toLowerCase() de la clase String, al momento de indexar y al momento de
buscar.
Los resultados de los demás casos de pruebas fueron los esperados.
CREAR COPIA DE SEGURIDAD EN EL MÓVIL
Página 164 de 169
8. Prototipo Final
Página 165 de 169
Resultados y Discusión
Resultados del diseño y de la construc ción del prototipo
Página 166 de 169
Conclusiones
Página 167 de 169
Referencias Bibliográficas (Existe hay que arreglar)
Página 168 de 169
Anexos
Página 169 de 169