tribunal de graduaciÓnrepositorio.ug.edu.ec/bitstream/redug/19529/1/ug-fcmf-b...ejemplos de amor y...

IV

TRIBUNAL DE GRADUACIÓN

Presidente del Tribunal 1er. Vocal

2do. Vocal Secretario

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

MANUAL DE USUARIO

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.

27

Ilustración 48. Pantalla versión del sistema

Versión del sistema.

28

MANUAL TECNICO

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.


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)


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)


PACIENTE char Código del paciente

FECHA date Fecha de consulta

SINTOMAS numeric Id del síntoma


Tabla 4: Consulta síntoma

Receta: (RECETA)


ID_RECETA numeric Id de receta

PACIENTE char Código de paciente


FECHA date Fecha de la receta

Tabla 5: Receta

Detalle de Receta: (DETALLERECETA)


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)



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)


CODIGO numeric Código del doctor por especialidades

NOMBRE varchar Especialidad del doctor

Tabla 8: Especialidad Habitación: (HABITACION)

37



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


ID_MEDICINA numeric Código de medicina

DESCRIPCION varchar Nombre del medicamento

PRESENTACION varchar Presentación del medicamento

Tabla 10: Medicina Medico


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


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


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


ID_SINTOMA Numeric Id del síntoma

39

DESCRIPCION Varchar Detalle especifico del síntoma

Tabla 14: Síntomas Tratamiento


ID_TRATAMIENTO numeric Id del tratamiento del paciente

DESCRIPCION varchar Detalle especifico del tratamiento

EVALUACION integer Evaluación del tratamiento

Tabla 15:Tratamiento Usuario


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


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


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


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


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


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


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

55

Ilustración 11. Inicio de copia de archivos

Ilustración 12. Copiando archivos

56

Ilustración 13. Proceso de copia de archivos

Ilustración 14. Seleccionar componentes

57

Ilustración 15. Copia de archivos HTML

Ilustración 16. Instalando documentación

58


Ilustración 18. Confirmación de instalación

59

Ilustración 19. Siguiendo con la instalación

Ilustración 20. Información del cliente

60

Ilustración 21. Archivos de localización

5.2.3.1 Seleccionamos los componentes que deseamos instalar.


61


Ilustración 24. Proceso de instalación

62

Ilustración 25. Instalación completa

Ilustración 26. Reiniciar después

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


65

Ilustración 31. Aceptar licencia

5.3.2 Ingreso de clave: Componentes java


66

Escogemos la ruta donde queremos que se instale



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

68

Ilustración 37. Chequeo de localización

Ilustración 38. Instalando componentes java

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 42. Comenzando a instalar

71


Ilustración 44. Finalización de instalación

72

Ilustración 45. Descripción del Anywhere


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

75


Ilustración 52. Leyendo contenido del paquete

76

Ilustración 53. Pantalla del SQL Anywhere

Ilustración 54. Escoger Idioma de instalación

77


Ilustración 56. Aceptar licencias

78

5.4.1.2 Escogemos la ruta donde grabamos el SQL Anywhere 9

Ilustración 57. Escoger destino de archivos


79


Ilustración 60. Instalando soporte del emulador

Ilustración 61. Mensaje de alerta

80


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


82

Ilustración 66. Finalizando la instalación


83

5.4.2 Parche 2

Ilustración 68. Instalando el 2 do parche

Ilustración 69. Escoger idioma

84

Ilustración 70. Aceptar licencias

5.4.2.1 Instalamos en la misma ruta del SQL Anywhere 9


85

Ilustración 72. Avanzar instalación 5.4.2.2 Seleccionamos los componentes que deseamos instalar


86

Ilustración 74. Finalizando instalación

Ilustración 75. Chequeo de localización

87

Ilustración 76. Instalando Plug-in de ASA


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

91

Aquí se presentan las Tablas de nuestro sistema Central

Ilustración 83. Tablas de 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

95

Aquí seleccionamos la base que vamos a trabajar.

Ilustración 87. Seleccionar 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

99

Aquí tomamos todos los objetos que pertenecen a la base.

Ilustración 91. Escoger objetos de DB

100

Aquí se conecta, una vez que la base ya este creada.

Ilustración 92. Seleccionar Conexión 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

107

Ilustración 104. Incluir comentarios en PUB.

Ilustración 105. Visualizar publicación

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

111

Ilustración 112. Creando nuevo articulo

Ilustración 113. Añadiendo tablas de 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

136

Ilustración 161. Componentes de Wizard

Ilustración 162. Especificar el lugar de librería

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

138

Ilustración 165. Buscar ruta de ODBC

Ilustración 166. Seleccionar el archivo DSN

139

Ilustración 167. Seleccionar la publicación

Ilustración 168. Generación de objetos y función

140

Ilustración 169. Configurar función

Ilustración 170. Escenas de registros

141

Ilustración 171. Opciones de Mobilink

Ilustración 172. Añadir cliente adicional

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



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



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


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


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


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.


Datos Paciente

Consulta Signos Vitales Regresar

Ubicación

Menú de Opciones


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.


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


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.

94

Tabla 17. Descripción medicina

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

http://www.ceis.cl/Gestacion/Gestacion.htm

http://www.microsoft.com/

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

tribunal de graduaciÓnrepositorio.ug.edu.ec/bitstream/redug/19529/1/ug-fcmf-b...ejemplos de amor y...

Documents