TRIBUNAL DE GRADUACIÓNrepositorio.ug.edu.ec/bitstream/redug/19529/1/UG-FCMF-B...ejemplos de amor y...
Transcript of TRIBUNAL DE GRADUACIÓNrepositorio.ug.edu.ec/bitstream/redug/19529/1/UG-FCMF-B...ejemplos de amor y...
V
DECLARACIÓN EXPRESA
“La autoría de la tesis de grado corresponde exclusivamente al suscrito(s),
perteneciendo a la Universidad de Guayaquil los derechos que generen la
aplicación de la misma”
(Reglamento de Graduación de la Carrera de Ingeniería en sistemas
Computacionales, Art. 26)
Luís Núñez Orozco
Christian Cordero Quinapallo
VI
RESUMEN
El sistema de revisión médica móvil NUCOR (SRMM NUCOR), fue
desarrollada para proveer ayuda a los médicos de un hospital
específicamente al área de pacientes internados. Este sistema fue
desarrollado con la herramienta de Sybase PocketBuilder 9.0, utilizando
además SQL Anywhere 9.0 como servidor de base y datos y Mobilink como
servidor de sincronización. Cabe destacar que el médico para poder acceder
al listado de los pacientes durante su jornada utilizará el Pocket PC,
dispositivo por el cual el médico deberá ingresar su usuario y contraseña
para obtener dicho listado; caso contrario no le permitirá ingresar al sistema.
Para el desarrollo de nuestro sistema, hemos tomado información del
sistema externo, sistema que lo manejarían las enfermeras en lo que son
ingresos de historias clínicas, signos vitales, síntomas. Teniendo en cuenta
que una vez tomada dicha información por parte del médico el procederá a la
revisión de los pacientes.
UNIVERSIDAD DE GUAYAQUIL
Facultad de Ciencias Matemáticas y Físicas
Carrera de Ingeniería en Sistemas Computacionales
“Desarrollo de un Software para la Revisión Médica por
dispositivos móviles que facilite el manejo de la consulta
interna para los médicos tratantes”
PROYECTO DE TESIS DE GRADO
CURSO DE GRADUACIÓN
Previo a la Obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
Autor(es):
LUIS ROBERTO NUÑEZ OROZCO
CHRISTIAN XAVIER CORDERO QUINAPALLO
GUAYAQUIL-ECUADOR
Año: 2007
II
AGRADECIMIENTO
Por derramar tus infinitas
bendiciones desde el inicio de mi
vida te doy gracias Dios nuestro
Señor, te agradezco a ti Padre
Todopoderoso porque has hecho
que culmine mi carrera con éxito.
A la Universidad de Guayaquil y
a todos sus educadores por ser
templo de enseñanza de
conocimientos y de valores que
nos han brindado desde el inicio
de nuestra carrera hasta el
desarrollo de nuestra vida
profesional.
A todas aquellas personas que
con sus concejos, paciencia y
tiempo han colaborado en el
desarrollo y pulimento de este
trabajo.
LUIS NUÑEZ OROZCO
II
AGRADECIMIENTO
A Dios nuestro Señor y a la
Virgen Santísima del Quinche,
les agradezco a ellos
principalmente por darme las
fuerzas y ganas de alcanzar que
culmine mi carrera con éxito.
A la Universidad de Guayaquil y
a todos sus educadores por
inculcarnos los buenos valores
que nos prepararon con sus
conocimientos, que nos da una
base para ser unos profesionales
exitosos. Siempre estaré muy
agradecido de sus clases y
enseñanzas.
A todas aquellas personas que
con su paciencia, sugerencias y
tiempo han colaborado en el
desarrollo y pulimento de este
trabajo.
CHRISTIAN CORDERO Q.
II
DEDICATORIA
A mis abuelos porque han sido
ejemplos de amor y sabiduría,
han sabido inculcar en mí valores
como la responsabilidad y
perseverancia, valores
indispensables para culminar con
éxito cada meta de mi vida.
A mi madre y a mis tíos, que con
sus concejos y apoyos se
convirtieron en la base sólida en
todos los momentos de mi vida.
LUIS NUÑEZ OROZCO
III
II
DEDICATORIA
A JOSE HIDALGO VALENCIA Y
MARIA ESTHER NOBLECILLA
que desde que nací me
inculcaron la perseverancia,
importancia de cumplir las metas
responsabilidad, honestidad, y
con amor y sabiduría, han
sabido inculcar valores
indispensables para culminar con
éxito cada meta de mi vida.
A mi madre, mi padre y mis
hermanos, que me brindaron su
apoyo incondicional, incansable,
ejerciendo una gran influencia
para poder terminar mi carrera
con éxito
CHRISTIAN CORDERO Q.
III
2
A continuación detallaremos en funcionamiento del Sistema de revisión
médica SRMM NUCOR
Ilustración 1. Pantalla principal del sistema
Pantalla principal del sistema SRMM NUCOR en el cual nos presenta el
siguiente menú:
• Opciones
• Ayuda
• Salir Sistema
3
Ilustración 2. Inicio Sesión
En el menú Opciones, escogemos dándole clic en Inicio Sesión, para que los
médicos puedan ingresar su usuario y clave, el cual nos mostrará la siguiente
ventana:
Ilustración 3. Ventana de ingreso clave
4
En esta pantalla el médico podrá ingresar su Usuario y Clave.
Ilustración 4. Ventana de ingreso sistema
Aquí el médico ha ingresado su Usuario: JSALAS y su Clave:****
Ilustración 5. Botón aceptar clave
Por medio de este botón Aceptar, al dar un clic el médico puede acceder a
los pacientes que tenga que atender en su jornada laboral.
5
Ilustración 6. Ventana de Bienvenida
Pantalla de Bienvenida al médico que se conectó previo a la lista de
pacientes
Ilustración 7. Botón de cancelación de usuario
Este botón Cancel, abandona o cancela la pantalla de Ingreso del Usuario.
6
Ilustración 8. Menú de Opciones
Una vez que le médico da clic en Aceptar, muestra esta pantalla, en el cual
tendrá la opción de escoger:
• Listado de Pacientes
• Sincronización
• Cerrar Sesión
7
Ilustración 9. Ventana sin citas
Esta ventana se presenta en el momento que escojamos la Opción de
listado de pacientes y no tenga el Médico ningún paciente que atender
durante ese día.
Ilustración 10. Listado de pacientes
A Continuación se muestra todos los pacientes del día, en este caso el
Médico JSALAS tiene que atender a un total de 6 pacientes.
8
Observemos que a cada paciente se le asigna una Historia Clínica
(HClínica), historia en el cual va a contener todos sus datos y signos vitales
del paciente.
Ilustración 11. Escoge paciente
Seleccionamos con el mouse al paciente que va ser atendido por el Médico.
Ilustración 12. Botón de ubicación
Damos clic en Ubicación para desplegar toda la información del paciente
que se le va a pasar visita.
9
Ilustración 13. Botón de cancelar listado
Al dar clic en Cancelar sale de la pantalla de listado de pacientes, para
volver a la pantalla principal.
Ilustración 14. Ubicación paciente
En esta pantalla de Ubicación Paciente, encontramos los datos personales
de el, como: Historia Clínica, Nombres, Apellidos, Fecha Nacimiento y el
lugar donde el paciente esta internado, en este el paciente se encuentra
internado en el piso #2 , habitación #202, cama ‘A’.
10
Ilustración 15. Botón diagnóstico
Al dar clic en este botón, nos presenta el Diagnostico que fue dado por
médico al momento que el paciente fue internado.
Ilustración 16. Botón cancelar ubicación
Al dar clic en Cancelar sale de la pantalla de Ubicación Paciente, para volver
a la pantalla de Listado de Pacientes.
11
Ilustración 17. Diagnóstico
La pantalla de Diagnostico nos presenta los datos personales del paciente
con su respectiva Historia Clínica, además encontramos el tipo de malestar
que le acontece al paciente y su localización.
La Fecha de Ingreso que el paciente fue internado y su evolución en
porcentaje de acuerdo al estado en el que se encontró al paciente.
Ilustración 18. Botón de signos vitales
Al dar clic en este botón, nos presenta los Signos Vitales del paciente, cuyos
signos fueron previamente tomados por la enfermera e ingresados en el
sistema externo.
12
Ilustración 19. Botón cancelar diagnóstico
Al dar clic en Cancelar sale de la pantalla de Diagnóstico, para volver a la
pantalla de Ubicación Paciente.
Ilustración 20. Signos vitales
En la pantalla de signos vitales encontramos igualmente los datos personales
del paciente, datos que el Médico debe tener presente al momento de hacer
su revisión medica. Observamos también la presión, pulso, respiración,
temperatura y alguna otra observación que se ha acontecido al paciente al
momento de haber sido internado.
13
Ilustración 21. Botón de Síntomas
Al dar clic en este botón, nos presenta los Síntomas del paciente que fueron
ingresados en el sistema externo.
Ilustración 22. Botón de cancelar signos
Al dar clic en Cancelar sale de la pantalla de Signos Vitales, para volver a la pantalla
de Diagnóstico.
Ilustración 23. Síntomas pacientes
14
Igualmente en la pantalla de Síntomas Paciente encontramos los datos
personales de el, mas los síntomas que se le ha presentado, una vez
observados tanto el Diagnostico como los Síntomas del paciente el Médico
emite un Tratamiento.
Ilustración 24. Botón de tratamiento
Al dar clic en Tratamiento, el Médico escoge en una serie opciones, que tipo
de tratamiento se le asigna al paciente de acuerdo a su diagnostico.
Ilustración 25. Botón de cancelar síntomas
Al dar clic en Cancelar sale de la pantalla de Síntomas Pacientes, para
volver a la pantalla de Signos Vitales.
15
Ilustración 26. Tratamientos
A continuación el Médico se presta a escoger los diferentes tipos de
tratamientos de acuerdo a su diagnostico para el paciente.
Ilustración 27. Botón grabar inactivo
Este botón de Grabar permanece inactivo hasta el momento en que el
Médico escoja los tratamientos respectivos y los mande a Grabar.
16
Ilustración 28. Escoge tratamientos
En este momento el Médico ha seleccionado con el Mouse los Tratamientos
de: Compresas Frías, Reposo, Vitaminas. Una vez seleccionados los
tratamientos se activa el botón de Grabar, para posteriormente pulsarlo en
caso de ser necesario.
Ilustración 29. Botón grabar activo
Por medio de este botón al dar clic, el Médico puede grabar los tratamientos
escogidos por el.
17
Ilustración 30. Mensaje de tratamiento exitoso
Una vez grabado los tratamientos se mostrarán a continuación una ventana
indicando que los tratamientos han sido grabados correctamente. Damos clic
en Aceptar para finalizar la grabación.
Ilustración 31. Botón consulta tratamiento
Por medio de este botón podemos Consultar el tipo de tratamiento que se le
envió al paciente.
18
Ilustración 32. Consulta tratamiento
Por medio de esta pantalla podemos observar los diferentes tipos de
tratamientos que se ha enviado al paciente.
Ilustración 33. Botón medicación
Por medio de este botón el Médico podrá consultar la medicación que fue
recetada al paciente.
19
Ilustración 34. Botón cancelar consulta tratamiento
Al dar clic en Cancelar, sale de la pantalla de Consulta Tratamiento, para
volver a la pantalla de Medicación.
Ilustración 35. Medicación paciente
Por medio de esta pantalla el Médico observará las diferentes medicinas que
le fue enviada al paciente.
Recordemos que el Médico solo va hacer consultas de la receta
anteriormente dada, por motivo que la receta es elaborada a mano por el
Médico, luego va ser ingresada al sistema externo por el médico de guardia.
20
Ilustración 36. Botón evaluación
Al dar clic en Evaluación mostrara la pantalla de evaluación, donde
encontraremos los datos del paciente y el diagnostico del mismo.
Ilustración 37. Evaluación En esta pantalla en Médico según la evolución del paciente podrá evaluarlo
en porcentaje y poder así ver si el paciente esta mejorando o no.
21
Ilustración 38. Botón cerrar visita inactivo
Como podemos observar este botón se encuentra desactivado hasta el
momento que el Médico ingrese el porcentaje de la evolución del paciente.
Ilustración 39. Botón aceptar evaluación
Al dar clic en Aceptar la evolución del paciente cambia.
Ilustración 40. Ventana evaluación exitosa Una vez Aceptada la evaluación del paciente mostrara una ventana con el
mensaje de Evaluación Ingresada.
22
Ilustración 41. Evaluación terminada
Una vez ingresado la Evaluación se inactiva el botón de Aceptar, a
continuación es Médico se presta a Cerrar Visita.
Ilustración 42. Botón cerrar visita activo
Por medio de este botón el Médico puede cerrar la visita médica que le hizo
al paciente.
23
Ilustración 43. Terminar visita
En esta pantalla se muestra los datos y ubicación del paciente para que
cuando el Médico termine la visita tenga presente que paciente el atendió
Ilustración 44. Botón aceptar inactivo
Este botón se encuentra inactivo hasta que el Médico Termine la visita.
24
Ilustración 45. Confirma término de visita
Cuando el Médico de un clic en Terminó Visita, automáticamente se activa el
botón Aceptar, luego del cual procedemos a dar un clic sobre el botón.
25
Ilustración 46. Retorno al listado paciente
Una vez terminado la visita automáticamente retorna a Listado Pacientes
para seguir atendiendo al siguiente paciente.
26
Ilustración 47. Menú Ayuda
Por medio de esta pantalla en el menú Ayuda podemos observar la versión
del sistema.
29
1. DISEÑO DE LOS DIAGRAMAS
1.1 Diagrama de caso de uso alto nivel
Figura 1: Diagrama Revisión Médica
1.2 Diagrama de casos de uso detallado sincronizar
Figura 2: Diagrama Sincronización
Interactuar
Sincronizar
MÉDICO
Revisión Médica
Introducir
contraseña
Sincronizar
Base
Actualizar
Base
Interactuar MÉDICO
Valida
Causas
30
1.3 Diagrama de casos de uso detallado: Interactuar
Figura 3: Diagrama interactuar médico
Ver listado de
pacientes
Visitar
pacientes
Consultar signos
vitales
MÉDICO
Consultar
síntomas y
diagnóstico
Evaluar
tratamiento
Prescribir
medicación
31
1.4 Diagrama de casos de uso detallado revisión médica
Figura 4: Diagrama Caso de Uso Revisión Médica
1.5 Diagrama de casos de uso detallado consulta
Figura 5: Diagrama Caso de Uso Consulta
Chequeo
Tratamiento
Consulta MÉDICO
Tomar signos
vitales
Suministra
Medicación
Atender al
paciente
Enfermeras
Actualizar
Base
32
2. DICCIONARIO DE DATOS
2.1 Estandarización de Formatos
• Métodos que devuelven referencias a objetos
xxxx.xxxxxx( )
(objeto).evento(parámetro)
ObjectName.getparent()
• Lee el valor de un archivo INI
Tipo dato Obj1
Obj1=ProfileString(filaname, section, key, el valor)
• Mensajes
MessageBox ( title, text {, icon {, button {, default } } } )
2.2 Estandarización de Operadores
Operador Descripción Ejemplo
+ Suma ld_amt = ld_in1 + ld_in2
- Resta ld_amt = ld_in1 – ld_in2
* Multiplicacion ld_total = ld_precio * ld_cantidad
/ Division ld_factor = ld_descuento / ld_precio
^ Exponenciacion ld_linea = ld_tasar ^ 2
++ Incremento en uno li_edad ++
-- Decremento en uno li_edad --
33
Operador Descripción Ejemplo
= Igual if ld_precio = 100 then ld_descuento = .05
> Mayor que if ld_precio > 100 then ld_descuento = .05
< Menor que if ld_precio < 100 then ld_ descuento = .05
<> No Igual if ld_precio <> 100 then ld_ descuento = .05
>= Mayor igual que if ld_precio >= 100 then ld_ descuento = .05
<= Menor igual que if ld_precio <= 100 then ld_ descuento = .05
AND Lógico Y if li_in1 > 5 AND li_in2 < 10 then …
OR Logico O if li_in1 > 5 OR li_in2 < 10 then …
NOT Logico de Negacion if NOT ld_precio = 100 then …
Figura 6: Estandarización de operadores
3. DISEÑO DE LAS TABLAS
Ciudad (CIUDAD): Describe el código de la ciudad más el nombre.
CAMPOS TIPO DE DATO DESCRIPCION
+= Agregue un reassign li_edad += 1 (mismo as li_edad = li_edad + 1)
-= Subtract/reassign li_edad-= 1
*= Multiplique/reassign li_edad *= 5
/= Divide/reassign li_edad /= 5
34
ID_CIUDAD integer Id de la ciudad a la cual pertenece el paciente
NOMBRE varchar Nombre de la ciudad
Tabla 1: Ciudad
Consulta Tratamiento: (CONSTRATAMIENTO) Contiene información de las
consultas de los tratamientos, hechas por los médicos.
CAMPOS TIPO DE DATO DESCRIPCION
DOCTOR numeric Id del doctor
PACIENTE char Código paciente
FECHA date Fecha de ingreso del paciente
TRATAMIENTO numeric Id del tratamiento
Tabla 2: Consulta tratamiento
Consulta: (Consulta)
CAMPOS TIPO DE DATO DESCRIPCION
ID_CONSULTA numeric Id de la consulta
FECHA date Fecha de la consulta
DOCTOR numeric Id doctor
PACIENTE char Código paciente
HORAINICIO varchar Hora de atención
HORAFIN varchar Hora de culminación
ESTADO char Estado paciente
35
ESTADO_SINTOMA char Estado del síntoma
Tabla 3: Consulta
Consulta Síntoma: (CONSULTASINTOMA)
CAMPOS TIPO DE DATO DESCRIPCION
PACIENTE char Código del paciente
FECHA date Fecha de consulta
SINTOMAS numeric Id del síntoma
DOCTOR numeric Id del doctor
Tabla 4: Consulta síntoma
Receta: (RECETA)
CAMPOS TIPO DE DATO DESCRIPCION
ID_RECETA numeric Id de receta
PACIENTE char Código de paciente
DOCTOR numeric Id del doctor
FECHA date Fecha de la receta
Tabla 5: Receta
Detalle de Receta: (DETALLERECETA)
CAMPOS TIPO DE DATO DESCRIPCION
RECETA Numeric Id de receta
36
MEDICINA Numeric Código de paciente
DOSIFICACION Varchar Id del doctor
POSOLOGIA Varchar Fecha de la receta
Tabla 6: Detalle Receta Diagnostico: (DIAGNOSTICO)
CAMPOS TIPO DE DATO DESCRIPCION
PACIENTE char Código de paciente
MALESTAR varchar Tipo de malestar del paciente
LOCALIZACION varchar Lugar del malestar
ESTADIA numeric Tiempo en quedarse para chequeo
FECHA_ING date Fecha de ingreso del paciente
FECHA_SALIDA date Fecha de salida del paciente
EVOLUCION integer Porcentaje de evolución del paciente
Tabla 7: Diagnostico Especialidad: (ESPECIALIDAD)
CAMPOS TIPO DE DATO DESCRIPCION
CODIGO numeric Código del doctor por especialidades
NOMBRE varchar Especialidad del doctor
Tabla 8: Especialidad Habitación: (HABITACION)
37
CAMPOS TIPO DE DATO DESCRIPCION
PACIENTE char Código de paciente
PISO numeric Numero del piso
HABITACION numeric Numero de la habitación
CAMA char Cama “A,B,C”
ESTADO char Estado del paciente
ID_HABITACION numeric Id habitación
Tabla 9: Habitación Medicina
CAMPOS TIPO DE DATO DESCRIPCION
ID_MEDICINA numeric Código de medicina
DESCRIPCION varchar Nombre del medicamento
PRESENTACION varchar Presentación del medicamento
Tabla 10: Medicina Medico
CAMPOS TIPO DE DATO DESCRIPCION
ID_DOCTOR numeric Id del Doctor
NOMBRE varchar Nombre del Doctor
APELLIDO varchar Apellido del Doctor
ESPECIALIDAD numeric Especialidad del Doctor
ESTADO char Estado del Doctor
NICK char Nick del Doctor
Tabla 11: Médico Paciente
CAMPOS TIPO DE DATO DESCRIPCION
HISTCLINICA char Historia clínica del
38
paciente
NOMBRES varchar Nombres del paciente
APELLIDOS varchar Apellidos del paciente
CEDULA char Cedula del paciente
SEXO char Sexo paciente
FECHA_NAC date Fecha nacimiento
CIUDAD Integer Ciudad del paciente
DIRECCION Varchar Direccion del paciente
TELEFONO varchar Fono del paciente
DIRECCION2 Varchar Direccion 2 del paciente
TELEFONO2 Varchar Fono 2 del paciente
ESTADO char Si esta internado o no
Tabla 12: Paciente Signos vitales
CAMPOS TIPO DE DATO DESCRIPCION
PACIENTE char Historia clínica del paciente
FECHA date Fecha de ingreso del paciente
MÉDICO numeric id del médico tratante
ESTADO char Estado del paciente
PRESION varchar Presión del paciente
PULSO varchar Pulso del paciente
RESPIRACION varchar Respiración del paciente
TEMPERATURA varchar Temperatura del paciente
OBSERVACION varchar Alguna observación al paciente.
Tabla 13: Signos vitales Síntomas
CAMPOS TIPO DE DATO DESCRIPCION
ID_SINTOMA Numeric Id del síntoma
39
DESCRIPCION Varchar Detalle especifico del síntoma
Tabla 14: Síntomas Tratamiento
CAMPOS TIPO DE DATO DESCRIPCION
ID_TRATAMIENTO numeric Id del tratamiento del paciente
DESCRIPCION varchar Detalle especifico del tratamiento
EVALUACION integer Evaluación del tratamiento
Tabla 15:Tratamiento Usuario
CAMPOS TIPO DE DATO DESCRIPCION
NICK Char Nick del Doctor
PASS Char Password del Doctor
NOMBRE Varchar Nombre del Doctor
APELLIDO Varchar Apellido del Doctor
Tabla 16: Usuario
40
4. CREACION DE SCRIPT
4.1 Tablas del sistema móvil
------------------------------------------------- -- Create tables -------------------------------------------------
41
Tabla 17: Script Base de datos
CREATE TABLE "DBA"."PACIENTE" ( "HISTCLINICA" char(10) NOT NULL , "NOMBRES" varchar(40) NULL , "APELLIDOS" varchar(40) NULL , "CEDULA" char(10) NOT NULL , "SEXO" char(2) NULL , "FECHA_NAC" date NULL , "CIUDAD" integer NOT NULL , "DIRECCION" varchar(40) NULL , "TELEFONO" varchar(10) NULL , "DIRECCION2" varchar(40) NULL , "TELEFONO2" varchar(10) NULL , "ESTADO" char(2) NULL , PRIMARY KEY ("HISTCLINICA"), )
42
Tabla 18: Script Base de datos
CREATE TABLE "DBA"."CIUDAD" ( "ID_CIUDAD" integer NOT NULL , "NOMBRE" varchar(40) NULL , PRIMARY KEY ("ID_CIUDAD"), ) CREATE TABLE "DBA"."MEDICO" ( "ID_DOCTOR" numeric(30,0) NOT NULL , "NOMBRE" varchar(40) NOT NULL , "APELLIDO" varchar(40) NOT NULL , "ESPECIALIDAD" numeric(30,0) NOT NULL , "ESTADO" char(2) NOT NULL , "NICK" char(10) NULL , PRIMARY KEY ("ID_DOCTOR"), )
43
Tabla 19: Script Base de datos
CREATE TABLE "DBA"."HABITACION" ( "PACIENTE" char(10) NOT NULL , "PISO" numeric(30,0) NULL , "HABITACION" numeric(30,0) NULL , "CAMA" char(2) NULL , "ESTADO" char(2) NULL , "Id_habitacion" numeric(30,0) NOT NULL , PRIMARY KEY ("PACIENTE"), ) CREATE TABLE "DBA"."SIGNOSVITALES" ( "PACIENTE" char(10) NOT NULL , "FECHA" date NOT NULL , "MEDICO" numeric(30,0) NOT NULL , "ESTADO" char(1) NOT NULL , "PRESION" varchar(20) NULL , "PULSO" varchar(20) NULL , "RESPIRACION" varchar(20) NULL , "TEMPERATURA" varchar(20) NULL , "OBSERVACION" varchar(50) NULL , PRIMARY KEY ("PACIENTE", "FECHA", "MEDICO"), )
44
Tabla 20: Script Base de datos
CREATE TABLE "DBA"."RECETA" ( "ID_RECETA" numeric(30,0) NOT NULL , "PACIENTE" char(10) NOT NULL , "DOCTOR" numeric(30,0) NOT NULL , "FECHA" date NOT NULL , PRIMARY KEY ("ID_RECETA", "PACIENTE", "DOCTOR", "FECHA"), ) CREATE TABLE "DBA"."DETALLERECETA" ( "RECETA" numeric(30,0) NOT NULL , "MEDICINA" numeric(30,0) NOT NULL , "DOSIFICACION" varchar(50) NOT NULL , "POSOLOGIA" varchar(50) NOT NULL , PRIMARY KEY ("RECETA", "MEDICINA"), ) CREATE TABLE "DBA"."MEDICINA" ( "ID_MEDICINA" numeric(30,0) NOT NULL , "DESCRIPCION" varchar(50) NULL , "PRESENTACION" varchar(50) NULL , PRIMARY KEY ("ID_MEDICINA"), )
45
Tabla 21: Script Base de datos
CREATE TABLE "DBA"."CONSULTA" ( "ID_CONSULTA" numeric(30,0) NOT NULL , "FECHA" date NOT NULL , "DOCTOR" numeric(30,0) NOT NULL , "PACIENTE" char(10) NOT NULL , "HORAINICIO" varchar(6) NULL , "HORAFIN" varchar(6) NULL , "ESTADO" char(1) NULL , "ESTADO_SINTOMA" char(1) NULL , PRIMARY KEY ("FECHA", "DOCTOR", "PACIENTE"), )
CREATE TABLE "DBA"."SINTOMAS" ( "ID_SINTOMA" numeric(30,0) NOT NULL , "DESCRIPCION" varchar(50) NULL , PRIMARY KEY ("ID_SINTOMA"), )
46
Tabla 22: Script Base de datos
CREATE TABLE "DBA"."CONSULTASINTOMA" ( "PACIENTE" char(10) NOT NULL , "FECHA" date NOT NULL , "SINTOMAS" numeric(30,0) NOT NULL , "DOCTOR" numeric(30,0) NOT NULL , PRIMARY KEY ("PACIENTE", "FECHA", "SINTOMAS", "DOCTOR"), )
CREATE TABLE "DBA"."TRATAMIENTO" ( "ID_TRATAMIENTO" numeric(30,0) NOT NULL , "DESCRIPCION" varchar(50) NOT NULL , "EVALUACION" integer NULL , PRIMARY KEY ("ID_TRATAMIENTO"), )
47
Tabla 23 Script Base de datos
CREATE TABLE "DBA"."CONSTRATAMIENTO" ( "DOCTOR" numeric(30,0) NOT NULL , "PACIENTE" char(10) NOT NULL , "FECHA" date NOT NULL , "TRATAMIENTO" numeric(30,0) NOT NULL , "HORA" time NOT NULL DEFAULT current time , PRIMARY KEY ("DOCTOR", "PACIENTE", "FECHA", "TRATAMIENTO", "HORA"), ) CREATE TABLE "DBA"."DIAGNOSTICO" ( "PACIENTE" char(10) NOT NULL , "MALESTAR" varchar(50) NULL , "LOCALIZACION" varchar(50) NULL , "ESTADIA" numeric(30,0) NULL , "FECHA_ING" date NULL , "FECHA_SALIDA" date NULL , "evolucion" integer NULL , "medico" numeric(30,0) NULL , PRIMARY KEY ("PACIENTE"), )
48
Tabla 24: Script Base de datos
CREATE TABLE "DBA"."USUARIO" ( "NICK" char(10) NOT NULL , "PASS" char(10) NULL , "NOMBRE" varchar(40) NULL , "APELLIDO" varchar(40) NULL , PRIMARY KEY ("NICK"), ) CREATE TABLE "DBA"."ESPECIALIDAD" ( "COD" numeric(30,0) NOT NULL , "NOMBRE" varchar(40) NULL , PRIMARY KEY ("COD"), )
49
5. INSTALACION DE SQL ANYWHERE
Instalación de Sql Anywhere en Servidor donde se ejecutara la sincronización
con el dispositivo móvil.
Seleccionamos la carpeta SQL Anywhere Studio 9.0.2 Windows 32 bits
Ilustración 1. Instalación SQL Anywhere
50
Dentro de esta seleccionamos Setup para empezar con la instalación.
Ilustración 2. Instalación setup
51
Ilustración 3. Pantalla de instalación
5.1 Pantalla de Bienvenida de la Instalación Anywhere
Ilustración 4. Pantalla de Bienvenida
52
5.2 Primera instalación de Anywhere Studio
:
Ilustración 5. Ingreso de clave
Ilustración 6. Destino de archivos
53
5.2.1 Escogemos la ruta donde queremos que se instale.
Ilustración 7. Ruta seleccionada
5.2.2 Escogemos los componentes que deseamos instalar
Ilustración 8. Escoger componentes
54
Ilustración 9. Escoger tipo de licencia
5.2.3 Seleccionamos programa SQL Anywhere 9
Ilustración 10. Seleccionar SQl Anywhere 9
60
Ilustración 21. Archivos de localización
5.2.3.1 Seleccionamos los componentes que deseamos instalar.
Ilustración 22. Escoger componentes
63
Ilustración 27. Páginas de internet
5.3 Segunda instalación: Componentes Java Comenzamos a instalar los componentes de Java, seleccionando la carpeta SQL Anywhere Studio 9.0.2
Ilustración 28. Segunda instalación Java
64
Seleccionamos Setup para empezar con la instalación.
Ilustración 29. Instalación setup
5.3.1 Pantalla de Bienvenida al Anywhere Studio 9
Ilustración 30. Pantalla de Bienvenida
65
Ilustración 31. Aceptar licencia
5.3.2 Ingreso de clave: Componentes java
Ilustración 32. Ingreso de clave
66
Escogemos la ruta donde queremos que se instale
Ilustración 33. Destino de archivos
Ilustración 34. Destino de archivos
67
5.3.2.1 Seleccionamos los componentes que deseamos grabar.
Ilustración 35. Selección de componentes
Ilustración 36. Selección de SQL Anywhwere
69
5.3.2.2 Escogemos el Pocket Pc 2002 Emulador(X86).
Ilustración 39. Plataforma de Pocket pc 2002
Ilustración 40. Destino del dispositivo
70
Seleccionamos los componentes que se desean instalar.
Ilustración 41. Selección de componentes
Ilustración 42. Comenzando a instalar
73
Ilustración 47. Paginas de Internet. Observemos que se instalo el SQL Anywhere 9
Ilustración 48. Visualizar instalación
74
5.4 Instalación de parches 5.4.1 Parche 1 Contiene las actualizaciones de las últimas notificaciones del Anywhere.
Ilustración 49. Instalación de 1 er parche
5.4.1.1 Seleccionamos el archivo
Ilustración 50. Escoger archivo
78
5.4.1.2 Escogemos la ruta donde grabamos el SQL Anywhere 9
Ilustración 57. Escoger destino de archivos
Ilustración 58. Selección de componentes
79
Ilustración 59. Copiando archivos
Ilustración 60. Instalando soporte del emulador
Ilustración 61. Mensaje de alerta
80
Ilustración 62. Instalación completa
5.4.1.3 Seleccionamos el Pocket PC 2002 Emulator(X86).
Ilustración 63. Selección del Pocket 2002
81
Ilustración 64. Escoger versión
5.4.1.4 Escogemos los componentes que deseamos instalar
Ilustración 65. Selección de componentes
84
Ilustración 70. Aceptar licencias
5.4.2.1 Instalamos en la misma ruta del SQL Anywhere 9
Ilustración 71. Destino de archivos
85
Ilustración 72. Avanzar instalación 5.4.2.2 Seleccionamos los componentes que deseamos instalar
Ilustración 73. Escoger componentes
88
Ilustración 78. Pagina de internet
5.4.3 Reiniciar Anywhere
Después de la instalación de los parches se reinicia la máquina procedemos
a trabajar con Sql Anywhere.
Ilustración 79. Pantalla del Anywhere
89
6. SINCRONIZACIÓN DE LA BASE REMOTA Y LA CENTRAL
Ilustración 80. Pantalla de conexión 6.1 Seleccionamos el ODBC de la base Central
Ilustración 81. Seleccionar la base local
90
Sybase Central nos permite ver las Tablas y Objetos de nuestra base Central
Ilustración 82. Base Central
92
7. CONFIGURACIÓN DE BASE REMOTA (SRMM_REM)
Primero levantamos Sybase Central, nos conectamos a Anywhere por medio
del ODBC y seleccionamos el ODBC de nuestra base Local en este caso
“NUNO”.
De hay se va a levantar la base local SRMM que es de donde vamos a tomar
los datos para nuestra base remota, en este caso solo necesitamos la
estructura de la base de datos y no la información, por que la base remota
debe estar vacía para el proceso de sincronización.
Ilustración 84. Configuración de Base Remota
93
7.1 Creación de la Base remota
De la base Local SRMM, en Sybase Central vamos a sacar nuestra base
remota.
*Para crear nuestra estructura de la base remota, damos clic derecho
en la base Central y seleccionamos Unload Database.
Ilustración 85. Creación de Base remota
94
Vamos a crear el unload de nuestra base local. A continuación se muestran
los pasos para la creación del mismo y mostramos las opciones que
debemos seguir para el correcto proceso.
Ilustración 86. unload de la base
96
Aquí tomamos la opción. Unload and reload into a new database, porque
necesitamos solo la estructura de la tabla no la información contenida en la
base.
Ilustración 88. Escoger unload and reload de DB
97
Aquí ponemos la dirección donde se va a guardar nuestra base remota.
Ilustración 89. Describir dirección base remota
98
Tomamos solo la estructura de la base: Unload structure only.
Ilustración 90. Escoger la estructura de DB
101
Proceso de creación de la base
Ilustración 93. Proceso de creación DB Se creó completamente la base.
Ilustración 94. Completada DB
102
7.2 Conectarnos a nuestro ODBC de la base remota
Ilustración 95. Conectar ODBC base remota
Esta conexión será de la base del dispositivo móvil
Ilustración 96. Seleccionar el ODBC remoto
103
Como se puede apreciar en el sybase central tenemos las dos bases la móvil
y la remota.
Ilustración 97. Visualizar DB remota
104
7.3 Creación de usuarios de base remota
En la base remota creamos los usuarios con los que nos vamos a conectar
en el dispositivo móvil.
Ilustración 98. Creación de usuarios
Ilustración 99. Crear usuario
105
Se creo un usuario Mobilink
Ilustración 100. Visualizar usuario mobilink
7.4 Crear Publicación de base remota
Ilustración 101. Crear publicación
106
Ilustración 102. Escribir publicación 7.4.1 Añadir tablas que se van a sincronizar
Ilustración 103. Añadir tablas de sincronizar
108
7.5 Suscripción del Usuario a la publicación
Ilustración 106. Suscribir usuario a publicación
Ilustración 107. Creando sincronización suscripción
109
Ilustración 108. Visualizar sincronización suscripción
7.6 Suscripción de tablas al usuario
Ilustración 109. Suscripción de tablas
110
Seleccionamos la tabla con la que vamos a trabajar.
Ilustración 110. Añadir tablas
7.7 Añadir artículos
Ilustración 111. Creando artículos
112
8. CONEXIÓN A MOBILINK Levantamos el Sybase Central
Ilustración 114. Conexión a mobilink
8.1 Conexión con MobiLink
Ilustración 115. Seleccionar mobilink
Ingresamos el User_id y el password, a continuación escogemos la Base de
Datos (nuno)
113
Ilustración 116. Escoger base central A continuación aparecemos ya conectados a Mobilink
Ilustración 117. Visualización de conexión
114
8.1.1 Creación de Usuarios de Mobilink
Comenzamos añadir los usuarios que van a sincronizar con la Base
Consolidada, en este caso vamos a ingresar dos usuarios de conexión.
Ilustración 118. Creación de usuarios de Mobilink
Comenzamos a añadir los usuarios de Mobilink
Ilustración 119. Añadir usuario mobilink
115
Observemos que aparece el primer usuario creado
Ilustración 120. Visualizar usuario creado. Continuamos creando el segundo usuario
Ilustración 121. Añadir 2 do usuario
116
Observemos que ya esta creado el segundo usuario
Ilustración 122. Visualización 2 do usuario
8.2 Creación de versión A continuación procedemos a crear la versión
Ilustración 123. Creación de versión
117
Procedemos a dar un nombre a la versión o lo podemos dejar por default
Ilustración 124. Nombre de la versión Observemos que ya esta creada la versión.
Ilustración 125. Visualización de versión creada
Una vez creada la versión procedemos a añadir las tablas de sincronización.
118
8.3 Pasos para añadir la tabla de sincronización
Ilustración 126. Añadir tablas de sincronización
Ilustración 127. Añadir tablas
119
Ilustración 128. Tablas añadidas
Una vez añadidas las tablas que van hacer sincronizadas, procedemos a
crear los strip
8.4 Pasos para añadir los Script para la sincronización.
Ilustración 129. Añadir script
120
Comenzamos a añadir los script
Ilustración 130. Script consulta download_delete_cursor
8.4.1 Script download_delete_cursor
Script de Consulta download_delete_cursor: Si en la tabla médico existe un
pk en el script pongo null, por cada pk pongo null
Ilustración 131. Script consulta
Aparece ya creado el script de consulta.
121
Ilustración 132. Visualizar script consulta Script de Médico download_delete_cursor
Ilustración 133. Script médico download_cursor
122
Ilustración 134. Script médico 8.4.2 Script download_cursor
Script de Consulta download_cursor: Saca las citas del médico por día
Ilustración 135. Script consulta download_cursor
123
Añadimos otro script
Ilustración 136. Script consulta upload_update 8.4.3 Script upload_update: Script CONSULTA upload_update: Para actualizar las citas al médico, solo
seteamos los campos que no son claves primarias, los pk van en el and.
Ilustración 137. Sript consulta
124
A continuación observemos que parecen creados los script.
Ilustración 138. Visualizar Script
Script de Médico download_cursor
Ilustración 139. Script médico
125
Añadimos otro script a la tabla médico
Ilustración 140. Script médico download_delete_cursor
Script MEDICO download_delete_cursor
Ilustración 141. Médico
126
Añadimos otros script
Ilustración 142. Añadir script Añadimos Script a la tabla Paciente
Ilustración 143. Script paciente download_cursor
127
Script de PACIENTE download_cursor: Llena los pacientes que están
pendientes y que son del día de hoy
Ilustración 144. Script paciente
128
Añadimos script a Síntomas
Ilustración 145. Añadir script a síntomas
Ilustración 146. Script síntomas download_cursor Script de SINTOMAS download_cursor
129
Ilustración 147. Script síntomas Añadimos Script a Signos vitales
Ilustración 148. Añadir script signos vitales
130
Ilustración 149. Script signo vitales download_cursor
Script de SIGNOSVITALES download_cursor
Ilustración 150. Script signos vitales
131
Script de TRATAMIENTO download_cursor
Ilustración 151. Script tratamiento download_cursor
Script de RECETA download_cursor
Ilustración 152. script receta download_cursor
132
Script de MEDICINA download_cursor
Ilustración 153. Script medicina download_cursor
Script de HABITACION download_cursor
Ilustración 154. Script habitación download_cursor
133
Script de ESPECIALIDAD download_cursor
Ilustración 155. Script especialidad download_cursor
Script de DIAGNOSTICO download_cursor
Ilustración 156. Script diagnóstico download_cursor
134
Script de DETALLERECETA download_cursor
Ilustración 157. Script Detalle receta download_cursor
Script de CIUDAD download_cursor
Ilustración 158. Script ciudad download_cursor
135
9. Creación de la sincronización en PocketBuilder
Ilustración 159. Creación de sincronización ASA
Ilustración 160. Generando objetos de aplicación
137
A continuación escogemos la base remota para la sincronización
Ilustración 163. Seleccionar perfil de DB
9.1 Test de conexión
Ilustración 164. Generando test de conexión
142
Ilustración 173. Sincronización de cliente Mobilink
Aquí ya se crearon los objetos de la sincronización
Ilustración 174. Visualización de objetos sincronización
VII
INDICE GENERAL AGRADECIMIENTO II
DEDICATORIA III
TRIBUNAL DE GRADUACIÓN IV
DECLARACIÓN EXPRESA V
RESUMEN VI
INDICE GENERAL VII
PARTE I INTRODUCCIÓN
CAPÍTULO 1
SRMMNUCOR
1.1 Antecedentes 1
1.2 Problemática 3
1.3 Solución 5
1.4 Descripción del Proyecto 6
1.5 Visión 9
1.6 Misión 9
1.7 Objetivos generales 10
1.8 Objetivos específicos 11
VIII
1.9 Alcance del proyecto 13
1.10 Restricciones del proyecto 15
1.11 Arquitectura del sistema 16
1.12 Metodología 17
1.13 Recursos del proyecto 20
1.13.1 Recurso de hardware 21
1.13.2 Recurso de software 24
1.14 Beneficiarios 27
1.15 Reestructuración 28
1.15.1 Causas 29
1.15.2 Consecuencias 29
1.16 Cronograma 30
PARTE II
IMPLEMENTACION
CAPÍTULO 2
ANALISIS
2.1 Documentación del Análisis de Dispositivos PDA 31
2.2 Especificación de requisitos 36
2.3 Descripción de los casos de usos 39
IX
2.4 Diagrama de caso de uso general 41
2.5 Descripción de actores 42
2.6 Triada de objetos 44
2.7 Composición inmutable (revisión médica) 48
2.8 Composición inmutable (general) 49
2.9 Diagrama de procesos de consultas 50
2.10 Diagrama de procesos de medicina 51
2.11 Diagramas de procesos tratamiento 52
CAPÍTULO 3
DISEÑO
3.1 Actividades del diseño 53
3.2 Modelo de Objeto relación 55
3.3 Diagrama de colaboración: Consulta 56
3.3.1 Diagrama de colaboración: Medicina 56
3.3.2 Diagrama de colaboración: Tratamiento 57
3.4 Diagrama de secuencia listado 58
3.5 Diagrama de secuencias paciente 59
3.6 Diagrama de estados paciente 60
3.7 Descripción de eventos: Revisión médica 61
3.7.1 Diagramas de eventos de revisión médica 61
X
3.8 Base de datos del sistema móvil 62
3.9 Sincronización 63
3.9.1 Pasos para la Sincronización 63
3.9.2 Programación de la base remota 64
3.9.3 Programación de la base local 64
3.10 Diccionario de Datos 67
3.10.1 Diseño de Datos 67
3.11 Diseño Arquitectónico 73
3.12 Diseño de Interfaz 74
CAPÍTULO 4
DESARROLLO Y PRUEBAS DEL SISTEMA
4.1 Desarrollo del sistema 91
4.1.1 Creación de componentes 92
4.1.2 Estudio de datos 92
4.1.2.1 Tratamientos 93
4.1.2.2 Medicación 93
4.1.2.3 Detalle Medicación 95
4.1.3 Seguridades 96
4.2 Pruebas del sistema 96
XI
4.2.1 Pruebas de unidad 97
4.2.1.1 Estándares 97
4.2.1.1.1 Librerías 98
4.2.1.1.2 Tablas 98
4.2.1.1.3 Campos 98
4.2.2 Verificación y validación 99
4.2.3 Pruebas de integración 99
4.2.4 Pruebas alfa y beta 100
4.2.5 Pruebas de seguridad 101
4.3 Calidad del sistema 102
CAPITULO 5
IMPLEMENTACION DEL SISTEMA
5.1 Implementación 103
5.2 Elementos Físicos 105
5.3 Elementos lógicos 106
5.4 Recurso Humano 107
5.5 Capacitación de usuario 107
XII
CAPITULO 6
RECOMENDACIONES Y CONCLUSIONES
6.1 Recomendaciones 108
6.1.1 Hardware 109
6.1.2 Software 109
6.2 Conclusiones 110
BIBLIOGRAFÍA 111
XIII
INDICE DE FIGURAS
Pág.
Figura 1. Análisis de los procesos involucrados 8
Figura 2. Análisis del modelo espiral 19
Figura 3. Descripción de Pocket HP 568 21
Figura 4. Descripción de Pocket HP 565 21
Figura 5. Cronograma de Actividades 30
Figura 6. Diagrama de Caso de uso General 41
Figura 7. Composición Inmutable Revisión Médica 48
Figura 8. Composición Inmutable General 49
Figura 9. Diagramas de procesos consulta 50
Figura 10. Diagramas de Procesos Medicina 51
Figura 11. Diagramas de Procesos Tratamiento 52
Figura 12. Modelo Objeto Relación 55
Figura 13. Diagrama Colaboración Consulta Médica 56
Figura 14. Diagrama Colaboración Medicación Paciente 56
Figura 15. Diagrama Colaboración Tratamiento Paciente 57
Figura 16. Diagrama Secuencia Listado de Pacientes 58
Figura 17. Diagrama Secuencia Estado del Paciente 59
Figura 18. Diagrama Estado Tratamiento Paciente 60
XIV
Figura 19. Diagrama Eventos de Revisión Médica 61
Figura 20. Base Datos del Sistema Móvil 62
Figura 21. Sincronización Base local con remota 63
INDICE DE TABLAS
XV
Pág.
Tabla 1. Pacientes 67
Tabla 2. Usuario 68
Tabla 3. Médicos 68
Tabla 4. Consulta 68
Tabla 5. Tratamiento 69
Tabla 6. Síntomas 69
Tabla 7. Diagnóstico 69
Tabla 8. Signos vitales 70
Tabla 9. Especialidad 70
Tabla 10. Consulta síntoma 71
Tabla 11. Consulta tratamiento 71
Tabla 12. Receta 71
Tabla 13. Detalle receta 72
Tabla 14. Habitación 72
Tabla 15. Medicina 73
Tabla 16. Descripción tratamientos 93
Tabla 17. Descripción medicina 94
Tabla 18. Descripción de Detalle Receta 95
Tabla 19. Costo de Operación (Implementación) 104
INDICE DE ILUSTRACIONES
XVI
Pág.
Ilustración 1. Pantalla principal SRMM NUCOR 74
Ilustración 2. Inicio Sesión 75
Ilustración 3. Ingreso de clave 76
Ilustración 4. Mensaje de Bienvenida 76
Ilustración 5. Menú de Opciones 77
Ilustración 6. Listado de pacientes 78
Ilustración 7. Mensaje de citas 79
Ilustración 8. Pantalla sin pacientes 79
Ilustración 9. Ubicación de pacientes 80
Ilustración 10. Diagnóstico 81
Ilustración 11. Signos vitales 82
Ilustración 12. Síntomas pacientes 83
Ilustración 13. Tratamientos 84
Ilustración 14. Mensaje de tratamiento exitoso 85
Ilustración 15. Consulta tratamiento 85
Ilustración 16. Medicación del paciente 86
Ilustración 17. Evaluación del paciente 87
Ilustración 18. Mensaje de evaluación exitosa 88
XVII
Ilustración 19. Terminar visita 88
Ilustración 20. Retorno listado pacientes 89
Ilustración 21. Versión del sistema 90
CAPÍTULO 2
2 ANALISIS
2.1 Documentación del Análisis de Dispositivos
PDA
Con estos dispositivos podemos almacenar nuestras
clases, publicaciones o conferencias (en formato Word
o PowerPoint), e incluso proyectarlas directamente
desde nuestra PDA.
Permiten el acceso a Internet, intranet o a correo
electrónico desde cualquier lugar mediante GPRS
32
(tarjeta Red Bluetooth dentro de hospital) o teléfono móvil (en el exterior).
Todo ello sería posible, pero sin olvidar algunas limitaciones existentes.
Limitaciones de las PDA
La memoria ROM (32 Mgb o 64 en las mas "potentes" PDA).Su ampliación
mediante tarjetas CompactFlash suponen un nuevo desembolso económico y
un aumento del volumen y peso de la PDA.
Complementos necesarios (tarjetas de memoria y PCMCIA VGA Voyager,
camisas de conexión, tarjetas Wireless, accesorios GPS), y su coste
"acumulativo". Coste de la conexión GPS, si esta la hacemos con "nuestro"
teléfono móvil. Su interfaz para escritura. Aun cuando existen teclados
externos (mas de lo mismo: coste y volumen), y distintos programas
instalables, Problemas de integración con los sistemas informáticos de
gestión utilizados en los hospitales, por lo que deben incorporarse otros
nuevos compatibles
Uso más frecuente de la PDA por el clínico hospitalario
Está claro que el uso médico de los PDA varía según el tipo de aplicación
que se utilice. El más común es almacenar y leer material bibliográfico.
Aplicaciones menos extendidas son las de prescripción electrónica, y en
ultimo extremo, como interfaces para recoger datos médicos o sistemas
globales hospitalarios.
33
El 46% de los doctores encuestados dijeron que les gustaría utilizar los PDA
para acceder a sitios Web relacionados con su actividad, un 33% opta por
escribir y transmitir prescripciones, acceder a páginas de la industria
farmacéutica fue la opción escogida por el 28% y por último un 27% dijo
almacenar datos de pruebas clínicas.
Redes Inalámbricas hospitalarias
Es indudable que el desarrollo de la informática, confía en un sector: las
aplicaciones móviles (o wireless). Estas incluyen aparatos como la nueva
generación de teléfonos móviles (tecnologías que ya funcionan como el
GPRS, o las que están por venir, como el UMTS); ordenadores portátiles
más versátiles y menos pesados; los asistentes de bolsillo: las PDA, nuevos
productos como los tablet PC, ordenadores portátiles que carecen de teclado
y permiten escribir y trabajar directamente sobre la pantalla de plasma, y o
pequeños ordenadores que con un tamaño mínimo ofrecen unas altas
prestaciones. La combinación de las dos aplicaciones: red inalámbrica y
interfaz portátil se potencian indescriptiblemente y encuentran un terreno
abonado en un medio tan multidisciplinario, a la vez que confidencial como el
medio hospitalario.
34
Ventajas que incorporan los PDA y las redes inalámbricas
El uso de PDA wireless para conectar con los servidores también redujo
potencialmente los problemas de confidencialidad de datos.
Ahora estos dispositivos actúan como intermediarios silenciosos: la
información del paciente es enviada inmediatamente al servidor para su
almacenamiento y la memoria de los PDA se limpia. De manera similar, los
registros visualizados por los médicos en sus PDA nunca se almacenan en
éste. Ello supone además un ahorro en la utilización de memoria de
almacenamiento
La Gestión Hospitalaria y PDA en nuestro entorno
Curiosamente, las aplicaciones de gestión hospitalaria (que no gestión
clínica), han encontrado una buena acogida en la rama de enfermería, y ello
tiene su explicación, ya que procesos tales como gestión de camas, dietas,
peticiones de material a almacenes, o medicación a farmacia, etc. Procesos
todos ellos mas sencillos de definir y protocolizar que los sistemas asesores
para tomar de decisiones clínicas, o los formativos que corresponderían a un
hospital docente y universitario.
Estos dispositivos son utilizables cuando el volumen de datos a introducir es
escaso y sencillo de agrupar. Sin embargo, en el ambiente que hablamos, los
datos pueden ser complejos, con una necesidad de recorrer muchas
35
pantallas si la aplicación es completa y teniendo en cuenta además que sería
necesario completar esos datos de forma obligatoria en el PC, pues sería
impensable rellenar una hoja de evolución en una PDA.
Debemos ser además realistas y tener en cuanta que el uso de las PDA no
es tan sencillo como nos gustaría, y en este caso, la aplicación exige una
fiabilidad y seguridad absoluta. No podemos permitirnos la introducción de
datos erróneos, algo que es mas fácil que suceda en una PDA que en un PC
normal. Se debiera estudiar además el impacto del uso de la PDA en un
ambiente de trabajo habitual. Y valorar ventajas e inconvenientes de la
introducción de datos en la habitación (?)
36
2.2 ESPECIFICACIÓN DE REQUISITOS
2.2.1 Requisitos generales
2.2.1.1 Los pacientes van a tener un código de historia clínica de
seis Dígitos.
2.2.1.2 Los médicos van a tener a una clave para conectarse con
el Sistema externo.
2.2.1.3 Tendremos en cuenta trabajar con fechas que codifiquen
el año con cuatro cifras.
2.2.1.3.1 La fecha dentro del sistema se manejará con el
formato dd/mm/yyyy
2.2.2 Gestión de Pacientes
2.2.2.1 Requisitos generales de los pacientes
2.2.2.1.1 Los pacientes se le asignará un número
Identificativo (historia clínica).
2.2.2.1.2 A los pacientes se definen por nº cedula,
nombres, apellidos, dirección, teléfono, ciudad.
37
2.2.2.2 Añadir pacientes
2.2.2.2.1 Solo los pacientes internados estarán en el
SRMM NUCOR.
2.2.2.3 Alta de pacientes
2.2.2.3.1 Solo los doctores darán el alta a los pacientes.
2.2.2.4 Buscar pacientes
2.2.3 Gestión de Médicos
2.2.3.1 Requisitos generales de los Médicos.
2.2.3.1.1 A los Médicos se le asigna un número identificativo.
2.2.3.1.2 A los Médicos se le definen por nº cedula,
nombres, apellidos, dirección, teléfono, ciudad, dentro
de la Base de datos.
2.2.3.2 Consulta Síntoma
2.2.3.2.1 Los doctores podrán consultar los síntomas del
38
Paciente que se encuentra internado.
2.2.3.2.2 Podrán obtener la información referente al paciente.
2.2.3.3 Consulta Diagnóstico
2.2.3.3.1 Los doctores podrán consultar el diagnóstico del
paciente que se encuentra internado.
2.2.3.3.2 Podrán revisar en el dispositivo el tipo de malestar por
el cual el paciente fue internado.
2.2.3.4 Ingresa Tratamiento
2.2.3.4.1 Solo los doctores podrán diagnosticar de acuerdo a
los síntomas del paciente.
2.2.3.5 Consulta Tratamiento
2.2.3.5.1 Los doctores podrán consultar el tratamiento de cada
paciente.
2.2.3.6 Modificar Tratamiento
2.2.3.6.1 Los doctores podrán Modificar Tratamiento, es decir
39
conforme la evolución del paciente se dará un nuevo
tratamiento.
2.3 Descripción de los casos de usos:
1.- Listado
Escenario general donde se realizan todas las operaciones de consultas de
pacientes. Todo este listado le llega al médico (ver manual técnico).
2.- Informes
Todos los informes son necesarios para el funcionamiento del sistema:
informe de los pacientes, presión arterial, temperatura, pulso, síntomas,
estado de salud del paciente, todos estos informes lo realiza la enfermera o
el doctor tratante. Estos informes son tomados del sistema externo.
40
3.- Tratamientos
Engloba todas operaciones relativas relacionadas a los tratamientos que es
realizado por los doctores, como parte de la revisión del paciente según el
estado de salud del mismo y evaluarlo si es necesario darle el alta.
4.- Prescripción
Es la ingresada por el médico de acuerdo a los síntomas que presente el
paciente, aquí se hará uso de los distintos tipos de medicamentos que debe
suministrársele.
5.- Sincronización
La información que manejamos en la base local del dispositivo móvil será
sincronizada día a día con la base central del sistema externo.
41
Figura 6. Diagrama de Caso de uso General
ENFERMERA
BASE DE DATOS
LISTADO
INFORMES
TRATANIENTOS
PRESCRIPCION
SINCRONIZACION
MEDICO
PACIENTE
SISTEMA EXTERNO
Revisión Médica
ADMINISTRADOR
2.4 Diagrama de caso de uso general
42
2.5 Descripción de actores
Nombre del actor: Administrador
DEFINICION: Es el encargado de la sincronización de la base
central con la base del dispositivo móvil. Tendrá todos los
permisos y libertad de movimientos por el sistema
NOTA: * El administrador tendrá acceso a toda la base
central del sistema.
Nombre del actor: Doctor
DEFINICION: Es el encargado de manejar el sistema
llevando un control de los pacientes con sus diferentes tipos
de tratamientos, prescripciones y medicaciones de cada uno
de los pacientes.
NOTA: * El doctor solo realiza la tarea de revisión medica.
* Por medio del sistema el doctor tiene el acceso
a cada uno de los pacientes del día.
43
Nombre del actor: Enfermera
DEFINICION: Es el encargada de manejar los ingresos de los
pacientes e informes de los pacientes.
NOTA: * Es la persona que esta en contacto con el
paciente en la toma de la historia clínica e ingreso
de los signos vitales al sistema central.
* Por medio del sistema central la enfermera podrá
consultar a pacientes (todo esto lo maneja el
sistema externo).
* No podrá modificar los tratamientos,
prescripciones ni medicación hecha por el
médico.
44
2.6 Triada de objetos
Símbolo: Paciente
Intensidad: Datos Personales del Paciente
Extensión: Carlos Alarcón, Edad 22 años, Ecuatoriano
Símbolo: Medico
Intensidad: Datos Personales de Doctor
Extensión: José Salas, Traumatólogo, A, JSALAS
Símbolo: Especialidad
Intensidad: Código de la profesión del medico
Extensión: Traumatólogo
Símbolo: Ciudad
Intensidad: Lugar donde vive el paciente
Extensión: Guayaquil
Símbolo: Habitación
Intensidad: Lugar donde esta internado el paciente
Extensión: José Luís P, piso 2, habitación 202, cama A
45
Símbolo: Usuario
Intensidad: Acceso del Médico al Sistema
Extensión: JSALAS, ****
Símbolo: Signos Vitales
Intensidad: Objeto que guarda los diferentes Signos Vitales
Extensión: Pulso, Presión, temperatura
Símbolo: Síntomas
Intensidad: Síntomas que presenta el paciente.
Extensión: dolor de cabeza, fiebre, malestar.
Símbolo: Tratamiento
Intensidad: Pasos que debe seguir el paciente para su recuperación.
Extensión: Descanso, tomar medicación en horario indicados.
Símbolo: Medicina
Intensidad: Objeto que contiene los datos de la medicación
Extensión: Diclofenaco Sodico, 50mg, Voltaren, Bayer.
46
Símbolo: Consulta
Intensidad: Unión de Paciente, doctor, Signos vitales, receta, consulta
síntomas y consulta tratamiento que nos sirve para formar un
objeto de flujo.
Extensión: 1, Juan Pérez, 120 Presión, 30 temperatura, 80 pulso, Dr. José
Merchán, Sinusitis
Símbolo: Consulta por Síntoma
Intensidad: Objeto que guarda el código de la consulta y la referencia de los
síntomas del paciente.
Extensión: Código de consulta C100, código de síntoma S120.
Símbolo: Consulta por Tratamiento
Intensidad: Objeto que guarda el código de la consulta y la referencia del
tratamiento del paciente.
Extensión: Código de consulta C100, código de tratamiento T20.
Símbolo: Diagnóstico
Intensidad: Malestar y Localización de la enfermedad
Extensión: 000004, José Merchán,04-01-1991,Fractura, Brazo izquierdo.
47
Símbolo: Receta
Intensidad: Tipo de Medicación del paciente
Extensión: ID 4, José Merchán, Dr. José Salas, 2007-03-31
Símbolo: Detalle Receta
Intensidad: Objeto que guarda el código de la receta y la referencia de la
medicina del paciente.
Extensión: Código de consulta R100, código de medicamento M50, cada 8
horas, 2 días.
48
2.7 Composición inmutable (Revisión Médica)
Figura 7. Composición Inmutable Revisión Médica
Doctor
Doctor revisa
lista pacientes
Asignan
Pacientes
Paciente
Consultas Receta Detalle receta
Medicina
Diagnostico Síntomas
Consulta Síntoma Consulta
Diagnostico
Consulta
tratamiento
Tratamientos
49
2.8 Composición inmutable (General)
Figura 8. Composición Inmutable General
Consulta
Consulta síntoma
Consulta diagnóstico
Diagnóstico
Síntomas
Paciente por
Consulta
Paciente
I
I
I I
50
2.9 Diagramas de procesos consultas
Figura 9. Diagramas de procesos consulta
Ingreso a validar medico
Base envía datos
Medico Ingresa clave
Base central: valida su password
Médico: chequea lista de pacientes en el pocket
Medico: chequea historia médica y diagnóstico
Médico: Escoge o ingresa tratamiento
Médico: Receta al paciente con su respectiva medicación y alta si es necesario
Médico: Envía los datos a la Base Central para que se actualice
Base central: actualiza el pocket enviando listado de pacientes del día.
Procesa
51
2.10 Diagrama de procesos medicina
Figura 10. Diagramas de Procesos Medicina
Ingresa su usuario y clave
Accede al paciente que se esta tratando
Médico: chequea lista de pacientes que han sido tratados y medicados
Medico: Escoge o chequea el tipo de medicación que le fue enviada.
Base central: se actualizan los datos
del paciente.
Base central: se actualizan los datos de los pacientes
Acceso
Procesan los datos
52
2.11 Diagramas de procesos tratamiento
Figura 11. Diagramas de Procesos Tratamiento
Médico: Consulta el
tratamiento que le
emitió
Médico: referencias del paciente
Médico: escoge o ingresa tratamiento si es nuevo
Médico: Dará el alta según la evolución del paciente (90%)
Médico: Según la evolución del paciente el médico evaluará o dará su diagnóstico.
Ingreso de datos
Procesa
Base Central: Se actualiza con los últimos datos de los pacientes
53
CAPÍTULO 3
3 DISEÑO
En la fase de Diseño se crea una solución a nivel
lógico para satisfacer los requisitos, basándose en el
conocimiento reunido en la fase de Análisis.
3.1 Actividades
Las actividades que se realizan en la etapa de Diseño
son las siguientes:
54
1. Definir los Casos de Uso Reales y Modelos de relación.
2. Definir Informes e Interfaz de Usuario.
3. Refinar la Arquitectura del Sistema.
4. Definir los Diagramas de Interacción.
5. Definir el Diagrama de Clases de Diseño. (en paralelo con los Diagramas
de Interacción)
6. Definir el Esquema de Base de Datos.
.
55
3.2 Modelo de Objeto relación
Figura 12. Modelo Objeto Relación
Doctor
Doctor revisa lista pacientes
Asignan Pacientes
Paciente
Consultas Receta Detalle receta
Medicina
Diagnóstico
Síntomas
Consulta Síntoma
Consulta Diagnóstico
Consulta tratamiento
Tratamientos
56
3.3 Diagrama de colaboración: Consulta
Figura 13. Diagrama Colaboración Consulta Médica
3.3.1 Diagrama de colaboración: Medicina
Figura 14. Diagrama Colaboración Medicación Paciente
Médico
Consulta
Paciente
1. Ingresa al sistema
3. Bienvenida al Paciente
4. Solicita lista de pacientes
2. Valida usuario
9. Contenido de la lista,
signos vitales, síntomas y
diagnóstico
5. Consulta lista de pacientes
6. Busca lista de pacientes
7. Envía datos de la lista
8. Muestra datos de la lista
Consulta Médico
6. Cumplimiento de los
medicamentos por parte de
las enfermeras
Médico
Medicina
Paciente
1. Ingresa al sistema
3. Bienvenida al Paciente
4. Muestra lista de pacientes
2. Valida usuario
9. Muestra lo datos
actualizados
5. Recetario de la medicación
7. Se actualizan los datos
8. Muestra datos
actualizados
Medicina Médico
57
3.3.2 Diagrama de colaboración: Tratamiento
Figura 15. Diagrama Colaboración Tratamiento Paciente
10. Consulta de
signos, síntomas y
diagnóstico del
paciente
Médico
Tratamiento
Paciente
1. Ingresa al sistema
3. Bienvenida al Paciente
4. Mostar lista de pacientes
8. Mostrar porcentaje de
mejoría
2. Valida usuario
12. Muestra lo datos
actualizados
5. Contenido de los
Tratamientos
6. Ingreso del nuevo
tratamiento
7. Muestra datos
Actualizados y alta
Tratamiento Médico
Medicación
9. Muestra datos
Actualizados
11. Contenido de la
medicación
58
3.4 Diagrama de secuencia del listado de pacientes
Figura 16. Diagrama Secuencia Listado de Pacientes
Bienvenido Medico
Un médico
Consulta
Un paciente
Médico
Medico inicia sesión Verificar usuario
Consulta Listado
Detalle Listado
Consulta Paciente
Estado Paciente
Estado Paciente
59
3.5 Diagrama de secuencia de estados del paciente
Figura 17. Diagrama Secuencia Estado del Paciente
Bienvenido Medico
Un Médico
Una consulta
Un paciente
Médico
Medico inicia sesión
Verificar usuario
Consulta Listado
Detalle Listado
Consulta Paciente
Estado Paciente
Estado Paciente
60
3.6 Diagrama de estados de tratamiento del paciente
Figura 18. Diagrama Estado Tratamiento Paciente
Bienvenido Medico
Un médico
Un
paciente
Médico
Médico inicia sesión
Verificar
usuario
Una consulta (signos, síntomas, diagnostico
Consulta Listado
Detalle Listado
Un
tratamiento
Consulta Paciente
Estado Paciente
Buscar
Paciente
Paciente
Evolución
%
61
3.7 Descripción de eventos: Revisión médica
Revisión Médica
1: Ingresar contraseña 2: Sincroniza base 3: Consulta datos (signos, síntomas, diagnóstico) 4: Atiende tratamiento 5: Medicación 6: Receta 7: Pastillas 8: Jarabe 9 : Volver al Inicio
3.7.1 Diagramas de eventos de revisión médica
Figura 19. Diagrama Eventos de Revisión Médica
Doctor
1 Sincroniza
2 Recibe listado de
pacientes
Dosificación
Prescripción
Posología 5
4
3
Guarda
r
7
8
6 9
62
consulta
PK id_consulta
fecha
doctor
paciente
hora_inicio
hora_fin
estado
estado_sintoma
paciente
PK id_paciente
nombres
apellidos
edad
sexo
fecha_nac
direccion
direccion2
telefono
telefono2
id_tipo
medico
PK id_doctor
nombres
apellidos
especialidad
estado
nick
tratamiento
PK id_tratamiento
descripcion
evolucion
sintomas
PK id_sintomas
descripcion
receta
PK id_receta
id_paciente
id_consulta
id_doctor
fecha
medicina
PK id_medicina
descripcion
distribuidor
presentacion
ConsulTrata
PK doctor
PK paciente
PK fecha
PK tratamiento
PK hora
ConsulSintoma
PK paciente
PK fecha
PK sintomas
PK doctor
DetalleReceta
PK id_receta
PK id_medicina
posologia
dosificacion
SignosVitales
PK id_signos
descripcion
Habitacion
PK id_habitacion
paciente
piso
habitacion
cama
estado
especializacion
PK cod
nombre
Diagnostico
PK Paciente
malestar
localizacion
estadia
fecha_ing
fecha_salida
evolucion
medico
ciudad
PK id_ciudad
nombre
Usuario
PK nick
pass
nombre
apellido
3.8 Base de datos del sistema móvil
Figura 20. Base Datos del Sistema Móvil
63
3.9 Sincronización Base Local con Base Remota
Figura 21. Sincronización Base local con remota
3.9.1 Pasos para la Sincronización
1.- Levantamos Sybase Central
2.- Seleccionamos conectamos a Anywhere con la base Central
3.-Nos conectamos al ODBC de la Base Local en este caso: NUNO
4.-Nos conectamos al ODBC de la Base Remota en este caso:
NUNO_REM
5.-Aquí tenemos levantada las dos bases tanto la local como la remota.
La local con los datos y la remota vacía, si es que es la primera vez
que se va a sincronizar
6.-Seleccionamos conectamos a Mobilink con la base Central.
7.-Nos conectamos al ODBC de la Base Local en este caso: NUNO
Base Local
SRMM
Dsn=NUNO
Base Remota
SRMM_REM
Dsn=NUNO_REM
Base Remota2
SRMM_REM1Dsn=NUNO_REM1
Servidor
Sincronización
Mobilink
64
8.- Aquí en Mobilink es donde vamos a programar la sincronización.
3.9.2 Programación de la base remota para sincronización (ANYWHERE)
1. En la base remota vamos a configurar cuales son los usuario con los
que vamos a trabajar.
2. En la opción mobilink user, damos clic derecho y creamos un nuevo
usuario, en este caso seria: JSALAS, si queremos trabajamos con la
clave caso contrario no es necesario.
3. Dentro de este usuario de Mobilink vamos añadir las tablas con las
que vamos a trabajar.
4. En la opción Publicación, damos clic derecho y creamos una nueva
publicación en este caso seria Pub.
5. ahora una vez que tenemos los usuarios y la publicación se procede
hacer la suscripción.
6. Damos clic derecho en el usuario Mobilink, y creamos una suscripción
y damos siguiente y le añadimos “PUB” que es nuestra publicación.
7. Ahora creamos una nueva versión. Damos clic derecho en versión y
creamos una nueva, que por defecto le vamos a poner “DEFAULT”
3.9.3 Programación de la base local para sincronización (MOBILINK)
1. En la base local vamos a configurar cuales son los usuario con los que
vamos a trabajar.
65
2. En la opción mobilink user, damos clic derecho y creamos un nuevo
usuario, en este caso seria: JSALAS, si queremos trabajamos con la
clave caso contrario no es necesario.
3. Dentro de este usuario de mobilink vamos añadir las tablas con las
que vamos a trabajar.
4. En la opción Publicación, damos clic derecho y creamos una nueva
publicación en este caso seria Pub.
5. ahora una vez que tenemos los usuarios y la publicación se procede
hacer la suscripción.
6. Damos clic derecho en el usuario mobilink, y creamos una suscripción
y damos siguiente y le añadimos “PUB” que es nuestra publicación.
7. Ahora creamos una nueva versión. Damos clic derecho en versión y
creamos una nueva, que por defecto le vamos a poner “DEFAULT”
8. En la opción Tabla Sincronizada, vamos añadir las tablas de la base
local con las cuales vamos a trabajar con la remota.
9. En la opción Tabla Sincronizada, damos clic derecho y añadimos una
por una las tablas con las que vamos a trabajar.
10. Una vez creadas las tablas en mobilink, se procede a crear los scripts
a cada tabla para el proceso de sincronizado.
11. Seleccionamos en Tabla Sincronizada, y saldrán todas las tablas que
hemos añadido, damos clic en una tabla y seleccionamos ADD scripts
66
12. los Scripts que debemos añadir en cada tabla depende de cómo se
manejen dentro del proceso, si necesitamos hacer: “insert, update,
delete”
13. En el caso para llenar las tablas remotas de la consolidada usamos el
scripts: download_cursor.
14. En este scripts escribiremos un select con todos los campos de la
tabla.
15. Cuando queramos borrar los campos que hay en la tabla podemos
usar el scripts delete_cursor.
16. En este Scripts ponemos un select seguido del numero de claves
primaria de la tabla que estemos trabajando
17. Ejemplo si la tabla tiene una clave primaria seria: select NULL; si
fueran dos seria select NULL, NULL, y así sucesivamente.
18. Después si necesitamos usar un update programamos el scripts
upload_update.
19. Dentro de este scripts irá update nombre _ tabla set campo1=?,
campo2=?,….
Where campo_pk1=? And campo_pk2=?
Si la tabla tuviera dos claves primarias.
67
3.10 Diccionario de Datos
La información que necesita el pocket es tomada del sistema central, el cual
va a contener todas las tablas necesarias para la aplicación. (ver manual
técnico)
A continuación detallamos en el Diseño de datos las tablas del sistema.
3.10.1 Diseño de Datos
Tabla Pacientes
Tabla 1. Pacientes
Tabla que contiene todos los datos del paciente incluido su historia Clínica.
68
Tabla Usuario
Tabla 2. Usuario Esta tabla contiene el nick y el password del médico para ingresar al sistema. Tabla Médico
Tabla 3. Médicos Contiene los datos personales del Médico y sui especialidad.
Tabla Consulta
Tabla 4. Consulta
69
Contiene la historia clínica del paciente relacionada con el médico tratante. Tabla Tratamiento
Tabla 5. Tratamiento Contiene el tipo de tratamiento con su respectivo id.
Tabla de Síntomas
Tabla 6. Síntomas Contiene todos los síntomas del paciente.
Tabla Diagnóstico
Tabla 7. Diagnóstico Contiene el diagnóstico hecho por médico de guardia o por el médico
tratante.
70
Tabla Signos Vitales
Tabla 8. Signos vitales
Contiene los signos vitales del paciente, estos signos son tomados por la
enfermera e ingresados al sistema central.
Tabla Especialidad
Tabla 9. Especialidad Se refiere al tipo de especialidad que tiene el Médico.
71
Tabla Consulta Síntoma
Tabla 10. Consulta síntoma
Se hace referencia al paciente con la tabla síntoma, para conocer que tipo de
complicaciones o enfermedad tiene el paciente.
Tabla Consulta Tratamiento
Tabla 11. Consulta tratamiento Consulta el tipo de tratamiento hecho por el médico.
Tabla Receta
Contiene la información del tipo de receta que se le envió al paciente, aquí
solo el médico podrá consultar la receta que anteriormente fue enviada.
72
Tabla Detalle Receta
Tabla 13. Detalle receta Contiene la información de cómo se suministra la medicación y su
dosificación.
Tabla Habitación
Tabla 14. Habitación
Esta tabla contiene el lugar donde se encuentra internado el paciente, piso,
habitación, cama.
73
Tabla Medicina
Tabla 15. Medicina
Contiene el nombre de los diferentes tipos de medicamentos con su
respectiva presentación.
3.11 Diseño Arquitectónico
Figura 21. Diseño arquitectónico
Signos Vitales
Síntomas
Medico
Listado de pacientes
Ingreso
Enfermera
Ubicación Diagnóstico Receta
Medicación
Paciente Internado
Consulta Tratamiento
74
3.12 Diseño de Interfaz Pantalla Principal
Ilustración 1. Pantalla principal SRMM NUCOR
Pantalla principal de nuestro sistema móvil Presenta el menú con tres
opciones para el manejo del mismo.
Inicio sesión
Ilustración 2. Inicio Sesión
En Opción se nos presenta el siguiente submenú con las opciones para el
medico, las cuales están deshabilitadas hasta que el medico ingrese su
usuario y clave.
75
76
Ingreso de usuario al sistema
Ilustración 3. Ingreso de clave
Aquí el médico ingresa su usuario y su respectiva clave para ingresar al
sistema.
Usuario del Sistema
Ilustración 4. Mensaje de Bienvenida
Después de haber ingresado sus datos si los hizo correctamente y el se
verifica que este en la base de datos del sistema sale el siguiente mensaje
dándole la bienvenida al usuario.
77
Opción: Listado de Pacientes
Ilustración 5. Menú de Opciones
Esta opción le permitirá al médico ver las citas de los pacientes que tiene que
atender el día que inicia sesión.
Nombre del Sistema
Menú de Opciones
SRMM NUCOR
78
Listado de pacientes
Ilustración 6. Listado de pacientes
Aquí presentamos el listado de los pacientes que tiene que atender el día
que ingreso al sistema.
Fecha de Cita
Paciente Pendientes
Ubicación Paciente
Regresar Menú Principal
Menú de Opciones
Listado Pacientes
Selección Paciente
79
Médico sin citas
Ilustración 7. Mensaje de citas
Cuando el médico ingresa al sistema y el día que inicio sesión no tiene citas
sale el mensaje que No dispone Citas.
No tiene Pacientes
Ilustración 8. Pantalla sin pacientes No se mostrará ningún paciente para el médico.
No hay pacientes a Consultar
Fecha Cita
80
Ubicación Paciente
Ilustración 9. Ubicación de pacientes
Cuando seleccionamos un Paciente del listado nos sale la ubicación del
paciente a consultar.
Datos
Paciente
Ubicación
Paciente
Regresar
Listado
Consulta
Diagnostico
Menú
Opciones Ubicación
Paciente
81
Diagnóstico Paciente
Ilustración 10. Diagnóstico
El médico podrá revisar el diagnóstico con el que fue internado el paciente,
la fecha de ingreso y la evolución del mismo.
Diagnóstico Paciente
Datos Paciente
Consulta Signos Vitales Regresar
Ubicación
Menú de Opciones
Diagnóstico Paciente
82
Signos Vitales del Paciente
Ilustración 11. Signos vitales
El médico consulta los Signos Vitales del paciente que la enfermera los tomo
antes de que el médico pase la visita respectiva.
Signos Vitales
Datos Paciente
Consulta Síntomas Regresar
Diagnóstico
Menú de Opciones
Signos Vitales Paciente
83
Síntomas Paciente
Ilustración 12. Síntomas pacientes
Se consulta los síntomas que ha presentado el paciente, con el malestar y el
efecto de la medicación suministrada.
Síntomas
Paciente
Datos
Paciente
Consulta
Tratamiento Regresar
Signos Vitales
Menú de
Opciones
Síntomas
Paciente
84
Tratamientos Pacientes
Ilustración 13. Tratamientos
Listado de Tratamientos que se le pueden asignar al paciente para su
recuperación queda a consideración del médico que tratamiento se le asigna
al paciente.
Tratamientos del
Sistema Seleccionar
Tratamiento
Graba
Tratamiento Consulta
Tratamiento
Menú de
Opciones
Tratamientos
Paciente
85
Tratamiento Exitoso
Ilustración 14. Mensaje de tratamiento exitoso
Se grabo correctamente el tratamiento del paciente.
Consulta Tratamiento
Ilustración 15. Consulta tratamiento
Tratamientos asignados al Paciente.
Datos Paciente
Consulta Medicación
Regresar Tratamientos
Menú de Opciones
Consulta Tratamientos
86
Se consulta los tratamientos asignados al paciente por el médico el día de la
consulta.
Medicación del Paciente
Ilustración 16. Medicación del paciente
Se muestra la medicación que esta tomando el paciente desde el ingreso con
su presentación y posología.
Medicamentos del Paciente
Datos Paciente
Evaluación Consulta
Regresar Consulta Tratamientos
Menú de Opciones
Medicación Paciente
87
Evaluación del Paciente
Ilustración 17. Evaluación del paciente
Se evalúa la condición del paciente en base a la perspectiva del médico y
según los síntomas, síntomas y como ha respondido el paciente a la
medicación y el tratamiento indicado.
Diagnostico Paciente
Datos Paciente
Cerrar Cita
Regresar Medicación
Menú de Opciones
Evaluación Paciente
88
Evaluación Ingresada
Ilustración 18. Mensaje de evaluación exitosa Evaluación de la enfermedad del paciente fue ingresado correctamente. Terminar Cita
Ilustración 19. Terminar visita
Después de revisar al paciente, verificamos la ubicación del internado y
procedemos a terminar la visita.
Ubicación Paciente
Datos Paciente
Terminar Cita
Acepta terminar Cita
Menú de Opciones
Terminar Cita
89
Menú Principal
Ilustración 20. Retorno listado pacientes
Después del proceso, regresamos a la revisión de los pacientes pendientes
del médico.
Paciente Pendientes
Consulta Tratamiento
Salir Sistema
Menú de Opciones
Listado Paciente
90
Versión del Sistema
Ilustración 21. Versión del sistema
VERSION
Logo SRMM NUCOR
Menú de Opciones
SRMM NUCOR
91
CAPITULO 4
4. DESARROLLO Y PRUEBAS DEL
SISTEMA
4.1- Desarrollo del Sistema
La Base da datos esta creada en SQL ANYWHERE
9.0
Nombre: SRMM
Día Creación: 05 de Febrero 2007
Tamaño: 1.85 KB
Ruta del archivo:c:\sistema\SRMM
92
4.1.1 Creación de componentes
Recordemos que el diseño de la aplicación es orientado a objetos, la
implementación del PocketBuilder y SQL Anywhere para el desarrollo del
sistema facilita la utilización de objetos que permite reutilización de código y
legibilidad de los datos.
4.1.2 Estudio de datos
En la realización del sistema se tiene que tener en cuenta que tipos de
tratamiento, medicación y receta vayan ser empleados en el paciente.
Recordemos que cada paciente se encuentra internado con diferentes
anomalías o malestares, lo que conlleva hacer al médico realice una
excelente revisión médica a sus pacientes.
Podemos citar los datos de las siguientes tablas:
• Tratamiento
• Medicación
• DetalleReceta
Estos datos encontrados en las tablas se encuentran relacionados con los
síntomas que presenta el paciente, además son datos que cumplen con la
93
veracidad del mismo, es decir se trata y medica de acuerdo a lo que presenta
el paciente.
4.1.2.1 Tratamientos
Describe todos los posibles tratamientos que un médico puede tener en
cuenta al momento de hacer su revisión médica.
Tabla # (Descripción de tratamientos)
Tabla 16. Descripción tratamientos
4.1.2.2 Medicación
Describe los diferentes tipos de medicaciones que puede sugerir un médico
al paciente que este internado.
95
4.1.2.3 Detalle Medicación
Describe todas las posibles formas de dosificación de los medicamentos con
su respectiva posología.
Tabla 18. Descripción de Detalle Receta
96
4.1.3 Seguridades
En la implementación de este sistema se ha manejado el control de acceso
de usuarios, es decir cada médico ingresará en el dispositivo móvil su
usuario y password, una vez ingresado correctamente estos datos, el sistema
valida y compara con la base de datos, lo ingresado por el médico.
Una vez que se establezca bien la conexión se dará paso al médico para que
pueda acceder al listado de los pacientes.
4.2 Pruebas del sistema
En esta etapa, realmente esta constituida por una serie pruebas diferentes
cuyo propósito general es ejercitar profundamente el sistema basado en
computadora. Aunque cada prueba tiene un propósito diferente, todas
trabajan para verificar que se han integrado adecuadamente todos los
elementos del sistema y que realizan las funciones apropiadas.
En nuestro sistema se han realizado algunas pruebas en las cuales las
detallaremos a continuación:
• Pruebas de Unidad
• Verificación y Validación
• Pruebas de Integración
• Pruebas Alfa y Beta
• Pruebas de Seguridad
97
4.2.1 Pruebas de unidad
En este tipo de prueba se analizan los módulos de forma independiente, que
forman parte del tipo de pruebas de la caja blanca, es decir analizan
procesos.
Este tipo de prueba se las realizó a cada uno de los módulos:
• Seguridades
• Listado de Pacientes
• Consultas
• General
En nuestro sistema de revisión medica, se trabajó con funciones y eventos
en las cuales comprobamos que los eventos sean los correctos cuando sean
embocadas las acciones respectivas, mientras que en las funciones se
comprobó que los parámetros que son enviados sean los respectivos tanto
en cantidades como en tipo de datos.
También se tomó en cuenta que el momento de llamar a un método,
coincidan los parámetros en cantidades y tipos de datos.
4.2.1.1 Estándares de definición:
• En Librerías
• Tablas
• Campos
98
4.2.1.1.1 En Librerías
Todas las librerías son distinguidas por el prefijo “lib” seguida del nombre de
la librería, en nuestro sistema por ejemplo tenemos las librerías:
Lib_nucor: En la cual encontramos una aplicación de objeto donde hacemos
la conexión la base de datos.
Lib_ancestros: Donde encontramos botones de acción y la pantalla padre.
Lib_datawindows: Contiene el GUI y el resultset(recupera los registros de la
base de datos cuando se ejecuta un sql select)
Lib_GUI: Contiene todas las interfaces o pantallas.
Lib_clases: Se declaran clases.
Lib_sincronizacion: Contiene los objetos de sincronización.
4.2.1.1.2 Tablas
Las tablas son nombradas con un nombre especifico es decir si deseo saber
los síntomas del paciente tengo la tabla CONSULTASINTOMA, así mismo la
tabla PACIENTE, etc.
4.2.1.1.3 Campos
Así mismo los campos guardan un tipo de dato definido en todas las tablas
para que no exista un error, por ejemplo en mi tabla PACIENTE tengo el
campo HISTCLINICA (char 10) lo mismo debo tener en mis tablas que haga
referencia a ese campo , tabla CONSULTA tengo el campo PACIENTE (char
10).
99
4.2.2 Verificación y validación
Con la verificación se analizan que no existan errores en la implementación
del software y la validación se consigue cuando el software funciona de
acuerdo con las expectativas razonables del cliente.
Este tipo de prueba se implementó en el sistema para comprobar que no
exista ningún tipo de errores y poder así satisfacer cualquier inquietud o duda
que haya quedado pendiente referente al sistema.
4.2.3 Pruebas de integración
En este caso se aplicó la prueba de integración Ascendente, debido a que
cada paciente independientemente van a tener su historial clínico, ubicación,
diagnóstico, signos vitales, síntomas, tratamiento, medicación, receta.
Un paciente va acarrear todos estos tipos de procesos uno por uno al
momento que el médico haga su revisión médica, y según la evolución o
diagnóstico el médico tratante dará su resultado.
100
EJ:
Paciente
Ubicación
Diagnóstico
Signos Vitales
Síntomas
……..
Hay que tener en cuenta que este proceso de revisión médica que el Doctor
realiza es el más óptimo para cada paciente que se encuentra internado en
el hospital.
4.2.4 Pruebas alfa y beta
Son pruebas que se realizan para que el usuario final descubra el o los
errores en el sistema.
La prueba Alfa se lleva a cabo, por un cliente, en el lugar de desarrollo. Se
usa el software de forma natural con el desarrollador como observador del
usuario y registrando los errores y problemas de uso. Las pruebas alfa se
llevan a cabo en un entorno controlado. Pero estas pruebas no son
suficientes porque la perspectiva de un desarrollador no es igual que la de un
usuario final, para esto existe las pruebas Beta.
101
La prueba Beta se lleva a cabo por los usuarios finales del software en los
lugares de trabajo de los clientes. A diferencia de la prueba alfa, el
desarrollador no esta presente normalmente. Aquí el cliente registra todos los
problemas (reales o imaginarios) que encuentra durante esta prueba e
informa a intervalos regulares al desarrollado.
En lo referente a nuestro sistema se realizaron estos dos tipos de pruebas,
las pruebas alfa y beta, teniendo en cuenta que las personas con quien
íbamos a realizar dichas pruebas sean Doctores especializados que
conozcan bien el funcionamiento de un hospital, para así poder recolectar
gran cantidad de información necesaria para el mejoramiento y calidad del
software.
4.2.5 Pruebas de seguridad
Este tipo de prueba intenta verificar que los mecanismos de protección
incorporados en el sistema lo protegerán, de hecho, de accesos impropios.
La seguridad en cualquier sistema es un tema importante, aun más si se trata
del área de internados de pacientes, motivo suficiente para que la
información que se registre sea la correcta y la mas exacta en el momento de
hacer alguna observación de un paciente.
Como seguridad en nuestro sistema cada usuario, en este caso los Doctores
inician sesión ingresando su usuario, seguido por su password. Es
importante anotar que si el usuario no ingresa correctamente la clave o su
102
nick, no podrá obtener el listado de pacientes por atender durante su jornada
laboral.
4.3 Calidad del sistema
Podemos citar que se han cumplido con todas y cada una de los alcances
planteados en el comienzo del desarrollo del sistema.
103
CAPITULO 5
5. IMPLEMENTACION DEL SISTEMA
5.1 IMPLEMENTACION
Para la implementación del Sistema de Revisión
Medica Móvil se necesita de algunos recursos entre los
cuales tenemos:
• Elementos Físicos
• Elementos Lógicos
• Recursos Humanos
• Capacitación de Usuario
104
Según estos elementos se plantea un costo de operación del sistema:
Cantidad Elemento Descripción Costo_Uni Total
1 Físico Computador
Pentium IV
$900 $900
1 Físico Pocket Pc $400 $400
2 Humano Desarrollo $300 $600
1 Capacitación Usuario $150 $150
Total Inversión $2050
Tabla 19. Costo de Operación (Implementación)
105
5.2 Elementos Físicos
A continuación mostraremos las características del computador:
• Un computador Pentium IV 2.0 Ghz.
• 512 Mb de memoria
• 60 GB de disco duro
• Monitor de 14”.
Este computador nos va ha servir para hacer el desarrollo del sistema con
sus respectivas pruebas.
Además este computador va a trabajar como servidor en el cual pondremos:
• Base de datos
• Perfil de Conexión a BD.
• Conexión por medio del ODBC
• Mobilink (sincronización)
Características del Pocket Pc:
El mínimo aconsejable de características técnicas que deberíamos exigirle a
nuestro Pocket Pc, para trabajar como médicos seria:
106
• Memoria base: 64 megas
• Microprocesador: Intel PX
• Ranuras para inserción de tarjetas de almacenamiento y dispositivos
externos
• Tarjeta de almacenamiento: Compact Flash
• Base de sincronización vía USB
• Sistema Operativo: Windows CE 3.0, Pocket PC 2002
5.3 Elementos lógicos
Para la implementación del sistema se instalará:
• Instalación del SQL Anywhere
• Instalación del PowerBuilder
• Instalación del PocketBuilder
• Perfil de Conexión a BD.
• Conexión por medio del ODBC
• Sincronización Hacia el dispositivo móvil
SQL Anywhere Studio es un exhaustivo paquete de herramientas de gestión
de datos para la empresa, con avanzadas opciones de sincronización y
administración adaptados al desarrollo de soluciones en un entorno móvil y
107
distribuido, como por ejemplo su soporte XML, servicios web, servidor de
sincronización, tecnología .NET, funcionalidades SQLX, servidor http
Sybase PocketBuilder simplifica y agiliza el proceso de creación. y
extensión de sistemas móviles. La nueva versión de la solución capacita
profesionales para desarrollar aplicaciones móviles orientadas a datos en
cuestión de horas. Y además, la tecnología es fácil de usar, exigiendo una
cantidad muy pequeña de programación”, define el ejecutivo.
5.4 Recurso Humano
Como recurso humano tenemos a los Sres. Luís Núñez Orozco y Christian
Cordero Quinapallo, personas encargadas del desarrollo del Sistema
Revisión Medico Móvil Núñez Cordero (SRMM NUCOR).
5.5 Capacitación de usuario
Se dará una capacitación a los usuarios que manejen el sistema, se le hará
saber de los procesos más importantes del sistema, además también tiene
como guía el Manual de Usuario, donde le muestra paso a paso la ejecución
del sistema.
108
CAPITULO 6
6. RECOMENDACIONES Y
CONCLUSIONES
6.1 Recomendaciones
El sistema de revisión médica por medio de
dispositivos móviles para que tenga una amplia
acogida por parte de los médicos requiere que ciertas
características tanto de:
• Hardware
• Software.
109
6.1.1 Hardware
• Computador con procesador Pentium IV , 2.4 GHz.
• Disco Duro: 80 GB o más
• Memoria: 512 MB de RAM
• Video: Super VGA o superior
• Mouse y teclado: PS/2 o USB.
• PocketPC: HP con S.O Windows Mobile 2003 Segunda Edición
• PocketPC: Memoria 64 megas
• PocketPC: Ranuras para inserción de tarjetas de almacenamiento y
dispositivos externos (Módulos GSM, GPS, WIFI, Etc..).
• PocketPC: Tarjeta de almacenamiento (Secure Digital)
• PocketPC: Base de sincronización vía USB.
• PocketPC: Puerto de Infrarrojos.
6.1.2 Software
En el computador se puede tener un Sistema Operativo con:
• Windows 2000 o Windows xp
• Adobe Reader 6.0
• El propio Sybase Anywhere Sql Studio.
110
En el Pocket :
• S.O Windows Mobile 2003 Segunda Edición, con sustanciosos
cambios recomendables sobre todo para el uso de la tecnología
inalámbrica (Wifi o Bluetooh).
6.2 Conclusiones
Los futuros médicos necesitarán aptitudes básicas en la utilización de Pocket
PC para acceder a material de referencia actualizado, para comunicarse,
para obtener una base de datos de fármacos, para recolectar y recuperar
información de sus pacientes. Por lo tanto, es aconsejable que en los
actuales momentos de la Medicina los médicos tengan la posibilidad de
adquirir habilidades en el manejo de estos dispositivos como parte de su
formación profesional.
En nuestro país esta tecnología con pocket pc en la área hospitalaria todavía
no se la ha implementado, pero sería de gran ayuda para los médicos el uso
de esta herramienta. Podemos tomar como ejemplo la Wayne State
University que decidió promover el uso de Pocket Pc tanto para los
estudiantes de medicina de pregrado como para los médicos especialistas.
Dando lugar a que las personas de sistemas, puedan ampliar sus
conocimientos en todas las áreas de la medicina moderna.
111
BIBLIOGRAFÍA
Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo
de Software, Addison Wesley 2000.
Letelier, P., Proyecto Docente e Investigador, DSIC, 2003.
Naur P., Randell B., Software Engineering: A Report on a Conference
Sponsored by the NATO Scienc, 1969.
Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill
1997.
Sommerville, I., Ingeniería de Software, Pearson Educación, 2002.
Xavier Ferré Grau, María Isabel Sánchez Segura Facultad de Informática –
UPM
http://www.ceis.cl/Gestacion/Gestacion.htm (5.3.2003)
http://www.microsoft.com/editions/sqlmobil Tecnología Microsoft
CAPITULO 1
1. INTRODUCCIÓN 1.1 Antecedentes La tecnología móvil ha tenido un crecimiento radical en
desarrollo del campo de la medicina moderna. En la
actualidad, está siendo usada tanto por el público en
general como por las instituciones especializadas, lo
que ha suscitado cuestiones de interés tales como: las
formas de acceso a la información médica y a los
historiales clínicos mediante dispositivos móviles o Pda,
la percepción del nivel de confianza de estos medios, la
acreditación de la información existente, o la seguridad
de la información, por citar sólo algunos de ellos.
2
En el área de la salud, este crecimiento se consolida como un recurso que
agiliza la difusión de información médica, la comunicación y prestación de
servicios a los pacientes, utilizando herramientas de fácil acceso y
reduciendo costos. Las dificultades que se presentan en algunos hospitales
debido al proceso de historias clínicas y su control pueden ser mejoradas en
forma automatizada, utilizando dispositivos PDA por medios de los cuales se
facilita que la información pueda estar disponible dónde y cuándo se
necesite.
El éxito probado de estos equipos radica en que son capaces de ser
organizados por funciones generales o especificas, ofreciendo sobre los
otros equipos bondades como movilidad, sincronización, organización y
planeamiento.
La educación móvil se posiciona como el futuro en tele-educación para el
desarrollo de sistemas de información en salud como área de gran potencial.
Tiene flexibilidad para desarrollos hospitalarios, sistemas de información a la
cabecera del paciente y otras fuentes de información biomédica.
Por medio de estos dispositivos, estaremos contribuyendo al desarrollo de
nuestro proyecto para automatizar la revisión del medico tratante,
otorgándole una herramienta útil para la decisión sobre conductas a tomar
en cuanto al manejo de pacientes en forma general.
En el área de la salud este crecimiento se consolida como un recurso que
agiliza la difusión de información médica, la comunicación y prestación de
3
servicios a los pacientes, utilizando herramientas de fácil acceso y
reduciendo costos.
1.2 Problemática
El problema que se presenta es que toda la documentación esta en papel y
siempre es revisada paciente por paciente cada que se realiza una visita, y el
doctor no tiene una lista de los pacientes que tiene que atender hasta que
llegue la enfermera con la carpeta de historia clínica de los pacientes y le
organiza las visitas manualmente.
Este proceso resta tiempo al medico que tiene que esperar las carpetas e ir
de sala en sala valorando la salud del paciente. El alcance de la tecnología
móvil en educación médica radica en su capacidad de estar disponible dónde
y cuándo se necesite.
En el hospital se maneja la consulta interna de los pacientes de manera
escrita por cada medico hay un determinado número de pacientes y cada
uno con sus respectivas historias clínicas.
La atención de consulta a los pacientes que están hospitalizados o
internados se la realiza de Lunes a Viernes en el horario Matutino y
Vespertino. Los pacientes son tratados de acuerdo a su enfermedad por los
especialistas de cabecera de cada área del hospital.
Cada vez que empieza la jornada en el respectivo turno, ya sea de
cualquiera de los dos horarios, los médicos reciben el listado de los pacientes
4
que deben visitar en la zona de internados ya sea por revisión o la evolución
del tratamiento de cada paciente que se esta siendo tratar.
El problema que nos enfocamos a la automatización de todo este proceso ya
que se lo hace de maneja de forma manual, sin un respetivo orden y sin
poder agilitar el momento cuando se requiere una historia clínica. A veces no
se tiene todos los datos exactos de los pacientes cuando se va a pasar
visitas.
También existe el problema que los datos con el tiempo se pierden debido al
proceso de deterioro de la historia clínica.
Este proceso quita tiempo ya que los médicos especialistas en el hospital
atienden a pacientes tanto de consulta interna como de consulta externa.
Generalmente el proceso de visitas de pacientes de consultas internas se lo
realiza primero a las 08:00 AM (horario matutino) y cuando terminan estas
revisiones el tiempo que sobra los manejan para consultas externas, he aquí
unos de los problemas importantes ya que el tiempo que queda para
consultas internas es muy corto debido al mucho tiempo que se demoran en
el proceso de listado de los pacientes que se tienen que visitar en el hospital.
Así mismo el horario vespertino que empieza las visitas de consultas
internas de 13 PM-16 PM (horario vespertino), el problema se basa en el
número de pacientes que se tiene por consultas externa ya que por estas el
hospital recibe un ingreso considerado económicamente. El número de
5
pacientes que se maneja actualmente es de 10 pacientes por la revisión que
se realiza de consulta externa.
1.3 Solución
Se va a trabajar un sistema de revisión medica de los pacientes que están
internados en el hospital HPNG, este sistema proporcionara al médico la
falibilidad y la portabilidad de la información de los pacientes que tiene que
visitar en las áreas respectivas, sirviéndole esto como una herramienta de
trabajo dentro del proceso de revisión.
La información que se tendrá del paciente va a estar ingresada en un
servidor central (sistema externo) en el cual va a constar con toda la historia
clínica del mismo. Una vez que el paciente esta Internado, ya sea por
consulta externa hecha por un médico o por emergencia., estos datos son
ingresados en el sistema externo, desde donde partimos para tomar la
información para la revisión médica del área de internados. Cuando el
médico revise su dispositivo móvil deberá tener el listado de los pacientes
que deberá pasar visitas. Para esto la información de cómo amaneció el
paciente deberá estar ingresado por el agente externo (enfermeras): signos
vitales, presión arterial, temperatura, síntomas de los pacientes. Cuando el
médico esta revisando al paciente tomara en cuenta los signos vitales,
síntomas y verificará la evolución del tratamiento si fue ingresado por
6
consulta interna o suministrar el tratamiento de dicho paciente si ingreso por
emergencia.
Según el estado del paciente el médico prescribirá la medicación que debe
seguir en dosis y durante que tiempo. Las encargadas de suministrar la dosis
al paciente serán las enfermeras, las cuales indicaran en el sistema externo
el cumplimiento del mismo. El tratamiento se lo evaluara en porcentajes de
acuerdo a la evolución del paciente y bajo la responsabilidad del médico . Si
el porcentaje es de un 90% el paciente puede ser dado de alta solo por
decisión del médico.
Con este sistema le daremos al médico una herramienta de trabajo con el
cual se le facilitara de una manera tecnológica el proceso de las consultas
internas pudiendo acceder del dispositivo móvil toda la información del
paciente que al momento de la revisión medica.
1.4 Descripción del proyecto
Aprovechando la delimitación del Área nos proponemos resolver en un 90%
la satisfacción del usuario, este proyecto nos permitirá brindar un servicio de
buena calidad en un espacio físico adecuado que otorgue comodidad y
confort para el personal que labora y para el usuario que acude a la atención.
El proceso se llevara a cabo en el área de hospitalización (internado), se
tratara de tener la información del paciente en una base central que se
llenará cuando el paciente llega al hospital a ser tratado y queda internado.
7
El proceso consta de los médicos, los pacientes, signos vitales, diagnostico,
tratamiento, medicación y un ente externo que son las enfermeras.
El medico a través del dispositivo móvil tendrá la información de dicho
paciente y podrá acceder al tratamiento y a la medicación que se debiera dar
para contrarrestar la enfermedad.
Con la información que tiene el médico con respecto a la enfermedad que
tiene el paciente y el control diario de los signos vitales, podrá ir controlando
la evaluación del tratamiento del paciente.
Dependiendo la evolución de la enfermedad del paciente se administrará la
dosis de medicación necesaria, si se aumenta o disminuye las cantidades
que se van a prescribir.
El Doctor enviará la medicación que sea necesaria para dicha tratamiento el
cual seria administrado por las enfermeras en la hora y en cantidades
indicadas por el médico tratante. Diariamente el médico tendrá el listado de
los pacientes que tiene que visitar, el piso, la habitación, la cama.
El proceso se repite cada que se visita un paciente, hasta que a este le den
el alta médica. El alta médica se le dará al paciente cuando el porcentaje del
tratamiento este en un 90% de su evolución.
8
Figura 1. Análisis de los procesos involucrados.
Inicio
Medico
visita
Paciente
Signos vitales
del Paciente
Evaluar
Tratamient
o
Suministración
de medicina
Evalúa
Paciente
%<90 Alta
Paciente
Fals
e
Fin
True Prescripción
medica
Actualiza Base
del Tratamiento
Enfermera
ingresa a base
A
A
Paciente
Doctor Enfermer
a
Sistema externo de donde tomamos la
información
Consulta
Síntoma,
Diagnostico
9
1.5 Visión
Llegar hacer un hospital que utilice la mejor infraestructura en el país,
estableciendo procesos innovadores que vaya de la mano con la tecnología.
De esta manera lograr compartir información con otros países sobre temas
relacionados a la salud y experiencias en el área de la medicina.
1.6 Misión
Brindar una buena atención a los pacientes Implementando la utilización de
herramientas tecnológicas como son las redes inalámbricas, dispositivos
móviles que nos permita la automatización de los procesos de los médicos.
Obteniendo de esta forma un buen desempeño de manera oportuna, eficaz y
eficiente con personal altamente capacitado y responsable.
10
1.7 Objetivos Generales
Teniendo como objetivo el desarrollo de soluciones de Computación Móvil,
en el presente documento se detalla la descripción funcional de la aplicación
SRMM NUCOR, resultado del levantamiento de información a cargo de los
estudiantes Luís Núñez y Christian Cordero, del curso de graduación.
Contribuir a la atención ágil en los hospitales
El Desarrollo de sistemas a través de los cuales se puede acceder a
información de pacientes desde dispositivos móviles de manera
remota en cualquier parte del hospital.
Facilitar el trabajo del Médico en la valoración de los Pacientes
bajo esta infraestructura.
La simplificación en el almacenamiento y seguridad de la información,
su fácil acceso por parte del personal médico y la fácil actualización de
la misma.
11
1.8 Objetivos específicos
Incrementar un 80 % la efectividad en la atención de cada médico
por ronda
Por medio de estos dispositivos PDA wireless (inalámbricos) podemos
conectarnos con el servidor así se reduce potencialmente los
problemas de confidencialidad de datos. Ahora estos dispositivos
actúan como intermediarios silenciosos: la información del paciente es
enviada inmediatamente al servidor para su almacenamiento y la
memoria de los PDA se limpia. De manera similar, los registros
visualizados por los médicos en sus PDA nunca se almacenan en
éste. Ello supone además un ahorro en la utilización de memoria de
almacenamiento.
Disminuir la pérdida de información clínica en un 90 %
Pasaremos visita, historiaremos y exploraremos a nuestros pacientes
y posteriormente introduciremos los datos en la base de datos
hospitalaria a través de la interfaz que nos resultara más cómoda, por
medio del micro teclado de nuestro dispositivo PDA.
12
Tener un respaldo del trabajo del medico por paciente y sus
tratamientos.
El sistema permitirá a los médicos que están tratando pacientes en el
hospital introducir sus notas en los dispositivos, lo cuales transmiten la
información en tiempo real al servidor de la aplicación. Esta información
además está disponible para otros doctores o equipos.
Proporcionar una atención de calidad a través del rediseño
estructural y funcional.
Los médicos utilizando estos dispositivos PDA pueden organizar la
atención a los pacientes que tiene que revisar y evaluar su estado de
salud.
13
1.9 Alcance del proyecto
Por medios de estos dispositivos vamos a acceder a información desde un
servidor de base de datos, en el cual vamos a tener información diaria del
paciente relacionado con:
❖ Listado de los Pacientes a consultar
- Información de los pacientes que tiene que pasar consulta
diariamente en el área interna del hospital
- Dentro del listado tendremos la habitación y el piso y los datos del
pacientes: Piso, Sala (habitación), nº cama.
❖ Descripción de la enfermedad del paciente
- En el cual va a constar la enfermedad del paciente, medidas
generales que incluyen signos vitales que serán realizados
diariamente (pulso, presión arterial, temperatura).
❖ Consulta de Síntomas y Diagnóstico
- El paciente antes de ser internado será atendido por el médico
tratante o por un médico de guardia, el cual anotara los síntomas y el
diagnóstico respectivo al sistema central. Luego estos datos el médico
del área de internado obtendrá la lista de pacientes que tiene que
atender durante su jornada y podrá constatar los síntomas y
14
diagnósticos que fueron prescrito anteriormente por el médico de
guardia.
❖ Tratamiento del paciente
- Medicación de acuerdo a la enfermedad que presenta el paciente
- Prescripción de la medicación, consiste en dar la cantidad y dosis
necesaria que deben tomarse los medicamentos.
❖ Movilidad
Dado que el trabajo del médico de internado no está ligado a una
ubicación física concreta se decide el uso de dispositivos móviles
(PDA’s).
15
1.10 Restricciones del Proyecto Nuestro sistema, necesita información de un sistema externo del cual vamos
a tomar datos que sean necesarios en el momento de la consulta, pero que
nuestro proyecto no incluye el desarrollo de este sistema externo.
La parte que manejarían las enfermeras no están contempladas en el
desarrollo de nuestro proyecto, este solo se enfoca a la revisión médica del
doctor. Unos de los puntos que haría la enfermera es el ingreso de la receta
en el sistema externo, ya que el médico receta a mano y no por medio del
dispositivo, debido a que la receta debe ser llenada a pulso para la compra
de los medicamentos. Esto da lugar al que el médico revise o consulte en el
dispositivo la receta que le fue enviada a dicho paciente.
16
1.11 Arquitectura del sistema
Se debe realizar un sistema que trabaje con una base local en el dispositivo
móvil, teniendo en cuenta que se trabajará con middlerware (el servidor de
sincronización) mediante el cual se van a enviar los datos a un servidor
central.
Además debemos tener en cuenta que el dispositivo móvil tiene una base
local con toda la información del paciente para que en el momento de la
revisión el médico obtenga los datos que necesite.
Esta base local se va ir actualizando del servidor central y la información
también será pasada desde el dispositivo móvil hacia el servidor central.
Se debe tener en cuenta:
• El sistema trabajará en un entorno Distribuido
• Se trabaja con dos bases de datos remotas, una consolidada y
mobilink.
• El dispositivo móvil a utilizar es un Pocket Pc.
• La unidad central es el ente externo.
17
1.12 Metodología
La aplicación seleccionada es el diseño orientado a objetos ya que facilita la
utilización de objetos que permiten la reutilización de código y legibilidad de
los datos.
Además también la herramienta que vamos a utilizar en O.O.
El proceso de desarrollo de software en Modelo espiral
El modelo espiral, pretende optimizar los tiempos y reducir la incertidumbre
del proyecto, así, la idea es partir produciendo una pequeña parte del
sistema (pero completamente funcional) y una vez completada, se procede a
crear una segunda parte, acoplada a la primera, de manera de que en cada
iteración, se obtiene una versión aumentada del sistema. El proceso
concluye cuando se considera que el sistema ha alcanzado un nivel de
maduración tal, que permite que el trabajo para el que fue creado, sea
realizado sin mayores inconvenientes.
El modelo de desarrollo en espiral es actualmente uno de los más conocidos.
El ciclo de desarrollo se representa como una espiral, en lugar de una serie
de actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
18
1. Definición de objetivos: Se definen los objetivos. Se definen las
restricciones del proceso y del producto. Se realiza un diseño detallado del
plan administrativo. Se identifican los riesgos y se elaboran estrategias
alternativas dependiendo de estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de
cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el
riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los
riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo después de
la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas
formales, evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se planea la
siguiente fase del proyecto.
Este modelo a diferencia de los otros toma en consideración explícitamente
el riesgo, esta es una actividad importante en la administración del proyecto.
19
Figura 2. Análisis del modelo espiral.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las
restricciones se determinan distintas alternativas. Se identifican los riesgos al
sopesar los objetivos contra las alternativas. Se evalúan los riesgos con
actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla
un poco el sistema. Se planifica la siguiente fase.
20
1.13 Recursos del proyecto
• Hardware
Equipos: Descripción:
Computador Pentium IV Memoria de 512 MB
Dispositivo PDA Pocket PC
Laptop celeron 1.3 GHz Memoria de 512 MB
• Software
Herramientas: Descripción:
Microsoft Windows XP Sistema Operativo (laptop)
PocketBuilder Herramienta de Desarrollo
SQL Anywhere Studio Base de Datos
Microsoft Proyect Cronograma
• Recurso Humano
Integrantes: Tareas:
Christian Cordero Quinapallo Programación , Diseño, Base Datos
Luís Núñez Orozco Programación, Diseño interfaz
21
1.13.1 Recursos Hardware
HP Jornada 568
Figura 1.3 Descripción de Pocket Pc
Precio orientativo $ 700
Dimensiones 132 x 76 x 17 mm.
Peso 173 gr.
Sistema operativo Windows CE
Memoria 64MB
Sincronización sí
Conectividad con móviles sí
Puerto de infrarrojos sí
Módem interno no
Conexión Puerto USB
Pantalla color
Pantalla táctil sí
Retroiluminación sí
Teclado virtual
Reconocedor de escritura sí
Batería Lithium
Figura 3. Descripción de Pocket HP 568
HP Jornada 565
Figura 1.4
Descripción de Pocket Pc
Precio orientativo $ 780
Dimensiones 132 x 76 x 17 mm.
Peso 173 gr.
Sistema operativo Windows CE
Memoria 32MB
Teclado virtual
Pantalla color
Pantalla táctil sí
Retroiluminación sí
Reconocedor de escritura sí
Conexión Puerto USB
Módem interno no
Figura 4. Descripción de Pocket HP 565
22
El mínimo aconsejable de características técnicas que deberíamos exigirle a
nuestro Pocket Pc, para trabajar como médicos seria:
Memoria base: 64 megas (los modelos anteriores disponían de 32 megas,
lo cual se queda muy escaso para la instalación de software y datos; los
modernos modelos disponen de 128 megas, lo cual hace casi innecesario
tener que adquirir una tarjeta de almacenamiento (por lo menos para el uso
medico básico)).
Microprocesador: Cualquiera de los que están en el mercado cumple los
mínimos exigibles. El más usado en todos los dispositivos anteriores era el
- Arm -, mientras Casio apostaba por - Mips -. En la actualidad los
dispositivos cuentan con microprocesadores Intel PX y XSCALE.
Ranuras para inserción de tarjetas de almacenamiento y dispositivos
externos (Módulos GSM, GPS, WIFI, Etc..): La mayoría de los dispositivos
disponen de una salida para dispositivos SD/ SDIO. Otros de ellos disponen
de ranuras tipo Compact Flash. También los hay con los dos tipos.
Tarjeta de almacenamiento. Básicamente hay de dos tipos, Compact
Flash y Secure Digital (esta ultima, Multimedia Card y SDIO son
compatibles y usan el mismo tipo de ranura de inserción). En general, con
un modulo de 256 megas es mas que suficiente para insertar gran cantidad
de libros. Las tarjetas de almacenamiento no suelen venir incluidas al
adquirir el dispositivo, y será necesario adquirirlas por separado.
23
Base de sincronización vía USB: los modelos antiguos disponían de
salida serie, que para la transmisión de datos son demasiado lentos, y
acaban con nuestra paciencia. Hoy día la mayoría disponen de puerto de
inserción USB para comunicarse con nuestros ordenadores de Sobremesa
y sincronizar e instalar nuestro software.
Puerto de Infrarrojos. Lo tienen casi todos. Es muy útil para usarlo como
puerto de impresión. No es infrecuente encontrar impresoras en nuestro
hospital que dispongan de este puerto, y a través de el imprimir listados de
pacientes o datos; igualmente podemos usarlo para transmitir datos y todo
tipo de archivos entre compañeros del hospital.
Sistema Operativo. Los antiguos llevaban el Windows CE o Pocket Pc
2000, lo cual en la actualidad supone muchos obstáculos para la
compatibilidad de los programas. Los modernos Pocket Pc 2002. Los
últimos del mercado, tienen incorporados el Windows Mobile 2003, sin
grandes diferencias con respecto al anterior. Desde el año 2005 la mayoría
de los dispositivos optan por el Windows Mobile 2003 Segunda Edición, con
sustanciosos cambios recomendables sobre todo para el uso de la
tecnología inalámbrica (Wifi o Bluetooh).
24
1.1.3.2 Recursos de Software
Herramienta Desarrollo: PocketBuilder
Se trata de una herramienta de desarrollo rápido de aplicaciones (RAD)
móviles y sin cable. Fácil de usar y con lenguaje orientado a objetos, la
solución permite la creación de aplicaciones en cuestión de horas y no de
meses, como es lo más común.
Los nuevos recursos de esa versión incluyen soporte para el sistema GPS,
scanner de código de barras, plataformas Smart Phone, cámaras y
teléfonos PocketPC.
Sybase PocketBuilder simplifica y agiliza el proceso de creación. y
extensión de sistemas móviles. La nueva versión de la solución capacita
profesionales para desarrollar aplicaciones móviles orientadas a datos en
cuestión de horas. Y además, la tecnología es fácil de usar, exigiendo una
cantidad muy pequeña de programación”, define el ejecutivo.
Sybase PocketBuilder lleva los beneficios de la programación 4GL al mundo
de la movilidad. “La solución disminuye significativamente el tiempo y los
costos asociados al desarrollo de aplicaciones. Todo desarrollador que
utiliza PocketBuilder obtiene una productividad inmediata con la facilidad de
uso de esa herramienta”.
25
Los principales recursos y beneficios de Sybase PocketBuilder incluyen:
• Integrated Development Environment (IDE) — IDE fácil de usar
con un lenguaje incorporado orientado a objetos, que permite el
desarrollo de aplicaciones en sólo algunas horas. Las cientos de
funciones incorporadas, a los distintos componentes listos para el
uso y la programación RAD drag and drop reducen aún más el
tiempo de desarrollo,
• Tecnología DataWindow patentada — Acceso a datos sin paralelo,
procesamiento y presentación dirigidos específicamente a los
dispositivos móviles; todo eso sin codificación,
• Sincronía MobiLink simplificada — Los datos almacenados
localmente que minimizan el tiempo de conexión y economizan
batería, permitiendo también la provisión de datos actualizados a los
usuarios móviles. Los abonados simplifican la sincronía y la
integración rígida con el SQL Anywhere Studio y el banco de datos
móvil de Sybase.
• Soporte adicional para aplicaciones móviles — soporte nativo
para servicios GPS, scanners de código de barras, plataformas
Smart Phone, cámaras y teléfonos PocketPC. PocketBuilder
también provee soporte al servicio de SMS (Short Message Service);
Controla llamadas específicas con el call log; Accede y modifica
informaciones de contacto con el soporte al catálogo telefónico.
26
Sybase Developer Network (SDN) ofrece soporte detallado para ayudar a
los desarrolladores a obtener lo máximo del PocketBuilder y de otras
herramientas de Sybase, por medio de software de evaluación,
informaciones técnicas y la colaboración con otros desarrolladores de
Sybase.
Base de datos: SQL Anywhere Studio
El líder en bases de datos móviles, para un acceso universal SyBase es el
editor de SQL Anywhere Studio, un gestor de datos que aporta una solución
de sincronización adaptada a las pequeñas y medianas empresas, de tal
manera que uno pueda acceder desde cualquier lugar y momento a toda la
información corporativa que necesite, con soporte para un gran número de
estándares y plataformas y, especialmente indicado en el caso de las bases
de datos móviles, embebidas y las aplicaciones basadas en web; la solución
para usuarios móviles.
SQL Anywhere Studio es un exhaustivo paquete de herramientas de gestión
de datos para la empresa, con avanzadas opciones de sincronización y
administración adaptados al desarrollo de soluciones en un entorno móvil y
distribuido, como por ejemplo su soporte XML, servicios web, servidor de
sincronización, tecnología .NET, funcionalidades SQLX, servidor http y
soporte SOAP, etc.
27
Optimizado para grandes bases de datos, ofrece un rendimiento óptimo, con
la posibilidad de realizar peticiones complejas con mayor seguridad. A nivel
de usuabilidad, ofrece un entorno de desarrollo sencillo, que facilita su
manejo y cubre las necesidades de toda clase de negocios. En definitiva,
SQL Anywhere Studio es una solución de difusión de información
empresarial a dispositivos móviles e inalámbricos de la más completa,
flexible y robusta actualmente disponible.
1.14 Beneficiarios
❖ El hospital puesto que sus procedimientos con respecto a las visitas
médicas y consulta interna van a ser optimizados y automatización de
los mismos.
❖ Los médicos que podrán verificar el listado de los pacientes vía el
dispositivo móvil podrá realizar todo el proceso de una manera
eficiente.
❖ Los departamentos encargados de llevar el proceso de consulta
interna y estadísticas donde esta las historias clínicas de los
pacientes.
28
❖ Los pacientes porque serán atendidos de manera rápida y eficaz con
toda la información del mismo desde el dispositivo móvil.
1.15 Reestructuración
❖ Cambiara de manera tecnológica el proceso de consulta interna a los
pacientes hospitalizados.
❖ Cambios y mejoras en la coordinación entre el departamento de
estadísticas y las enfermeras de control logrando la efectividad de los
procesos.
❖ Mejorar la atención a los pacientes y optimizar los procesos de visita
médica.
29
1.1.5.1 Causas
❖ Ausencia de aplicación que apoye a los médicos a controlar el
proceso de consulta interna, todo este proceso se lo realiza de manera
manual.
❖ Demoran mucho tiempo buscando las historias clínicas de los
pacientes cuando se pasa la revisión médica.
1.1.5.2 Consecuencias
❖ El médico no tiene la información necesario para valorar al paciente.
❖ Desorganización de la información.
❖ Falta de mecanismos de Control
❖ Ausencia de Reportes Reales
❖ Errores al hacerlo de manera manual
30
1.16 Cronograma
Nombre de tarea Duración Fecha inicio Fecha fin
Estudio del Área de Hospitalización 20 días 05-Oct-06 25-Oct-06
Investigación de información relevante 5 días 25-Oct-06 30-Oct-06
Entrevistas con involucrados 4 días 26-Oct-06 30-Oct-06
Investigación de tecnología a utilizar 5 días 30-Oct-06 04-Nov-06
Estudio de Requerimientos y necesidades del médico 10 días 04-Nov-06 14-Nov-06
Análisis de los involucrados en el Sistema 10 días 14-Nov-06 24-Nov-06
Estudio de procesos 5 días 24-Nov-06 29-Nov-06
Análisis de objetivos Generales 4 días 29-Nov-06 02-Dic-06
Análisis de objetivos Específicos 4 días 02-Dic-06 02-Dic-06
Alcances el proyecto 4 días 02-Dic-06 06-Dic-06
Restricciones del Proyecto 2 días 06-Dic-06 08-Dic-06
Especificación de Requisitos 4 días 08-Dic-06 12-Dic-06
Diagramas de Casos de uso 1 días 12-Dic-06 12-Dic-06
Descripciones de Objetos, Composiciones, diagramas de procesos 1 días 12-Dic-06 12-Dic-06
Estudio de la base de datos a utilizar 4 días 12-Dic-06 16-Dic-06
Información de tecnología móvil 2 días 16-Dic-06 18-Dic-06
Análisis del Sistema Externo 6 días 18-Dic-06 24-Dic-06
Estudio de tablas del sistema externo 5 días 24-Dic-06 29-Dic-06
Análisis de procesos para sistema móvil 5 días 24-Dic-06 29-Dic-06
Elaboración de las tablas de la base móvil 5 días 24-Dic-06 29-Dic-06
Creación del modelo entidad Relación Base móvil 3 días 26-Dic-06 29-Dic-06
Manejo de herramienta de desarrollo 15 días 15-Ene-07 31-Ene-07
Instalación de la herramienta de desarrollo 1 día 01-Feb-07 02-Feb-07
Instalación de Visio 2003 1 día 02-Feb-07 03-Feb-07
Diseño de plantillas y formatos en herramientas 9 días 03-Feb-07 12-Feb-07
Validaciones de la base móvil 5 días 12-Feb-07 17-Feb-07
Desarrollo del proyecto en PocketBuilder 25 días 17-Feb-07 15-Mar-07
Prototipo del sistema móvil 5 días 15-Mar-07 20-Mar-07
Conexiones con base local y móvil 5 días 20-Mar-07 25-Mar-07
Sincronización de bases pruebas 5 días 25-Mar-07 30-Mar-07
Desarrollo del proyecto en PocketBuilder 25 días 30-Mar-07 24-Abr-07
Documentación general 5 días 24-Abr-07 29-Abr-07
Documentación Técnica 4 días 29-Abr-07 04-May-07
Documentación Usuarios 5 días 04-May-07 09-May-07
Figura 5. Cronograma de Actividades