• No se han encontrado resultados

Capa para la consulta de Nefrología

N/A
N/A
Protected

Academic year: 2020

Share "Capa para la consulta de Nefrología"

Copied!
68
0
0

Texto completo

(1)Ministerio de Educación Superior Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática, Física y Computación Licenciatura en Ciencias de la Computación. Trabajo de Diploma. Capa para la consulta de Nefrología Autor:. David García Infante. Tutor:. MSc. María Elena Martínez del Busto. SANTA CLARA - 2007-.

(2) Hago constar que el presente trabajo fue realizado en la Universidad Central Marta Abreu de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencias de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad. ________________ Firma del autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. ______________. ________________________. Firma del tutor. Firma del jefe del Seminario.

(3) Dedicatoria A mi familia, y a mi novia que tanto me ha ayudado, a las personas que siempre confiaron en que yo si podía, a los que nunca creyeron en mí, y en especial a DIOS que sin el nada es posible..

(4) Agradecimientos A mis amigos Rainer Lara, Alejandro Villa y Guillermo Abreu que fueron de gran ayuda; a mi familia de Remedios que me dio todo su apoyo; a Daniel Castro, Arley Vázquez y Maikel León por ser fuente de conocimientos; a mis compañeros de aula, en especial a Darianny Figuero por estar siempre ahí; a mis compañeros de cuarto; a Lester Núñez y Yoel Lorenzo que me ayudaron a llegar hasta aquí; a mi tutora Marielena Martínez del Busto y su esposo Luis Felipe y a todo el que de una forma u otra hizo posible la realización de este proyecto..

(5) Resumen Las enfermedades renales son cada vez más comunes y de complejo seguimiento; el trasplante es una alternativa decisiva para un gran número de pacientes. El manejo de la información necesaria para el control de estos receptores potenciales durante y después de una intervención quirúrgica, incluyendo donantes vivos o muertos es voluminoso teniendo en cuenta que el tiempo resulta ser un factor crítico. Se quiere contar con un sistema automatizado que permita gestionar la información de forma ágil y precisa. Por esta razón y en la ausencia de sistemas similares se comenzó el desarrollo de un software con este propósito..

(6) Abstract Renal diseases are more and more common and also complex to pursuit. Transplant is a decisive alternative for a great number of patients. The handling of the necessary information for the control of these potential receivers during and after surgery, including the information of alive or dead donors is voluminous considering that time turns out to be a critical factor. An automated system that allows managing the information in a fast and precise way is needed. For this reason, and due to the absence of a similar system, the project for the development of software was carried out..

(7) Índice INTRODUCCIÓN .................................................................................................................................... 1 HIPÓTESIS DE LA INVESTIGACIÓN ........................................................................................................... 2 OBJETIVO GENERAL ................................................................................................................................ 3 OBJETIVOS ESPECÍFICOS ......................................................................................................................... 3 CAPÍTULO 1. EMPLEO DE TECNOLOGÍAS Y HERRAMIENTAS COMPUTACIONALES EN LA GESTIÓN Y EL CONTROL DE LOS PACIENTES CON TRASPLANTE RENAL. ............... 4 1.1 MODELO CLIENTE/SERVIDOR ............................................................................................................ 5 1.1.1 Características funcionales ...................................................................................................... 6 1.1.2 Características físicas .............................................................................................................. 7 1.1.3 Características lógicas ............................................................................................................. 8 1.1.4 Ventajas e inconvenientes ........................................................................................................ 9 1.1.5 Ambientes de desarrollo en el lado del cliente ....................................................................... 11 1.2 ESTRUCTURA DE LA ARQUITECTURA MULTICAPA ........................................................................... 11 1.3 EL GESTOR DE BASES DE DATOS MICROSOFT SQL SERVER. .......................................................... 13 1.3.1 Procedimientos almacenados. ................................................................................................ 14 1.3.2 Funciones ............................................................................................................................... 15 1.3.3 Desencadenadores ................................................................................................................. 18 1.4 EL ENTORNO DE DESARROLLO DE SOFTWARE DELPHI ..................................................................... 19 1.4.1 Componentes .......................................................................................................................... 19 1.4.2 Eventos ................................................................................................................................... 20 1.4.3 Base de datos.......................................................................................................................... 20 1.4.4 Borland database engine (bde) .............................................................................................. 21 1.4.5 Desarrollo visual .................................................................................................................... 21 1.4.6 Entorno integrado de desarrollo (EID) .................................................................................. 21 1.4.7 Depurador Integrado ............................................................................................................. 22 1.5 MODELO DE ACCESO A DATOS: ADO (MICROSOFT ACTIVEX DATA OBJECTS) ............................... 22 CAPÍTULO 2. ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DEL SISTEMA PARA EL CONTROL DE PACIENTES CON TRASPLANTE RENAL. ......................................................... 24 2.1 DISEÑO Y ANÁLISIS DEL SISTEMA .................................................................................................... 25 2.2 MODELO DEL NEGOCIO .................................................................................................................. 25 2.3 ACTORES Y CASOS DE USO .............................................................................................................. 26 2.4 DISEÑO DE LA BASE DE DATOS ........................................................................................................ 31 2.5 EJEMPLOS DE PROCEDIMIENTOS ALMACENADOS ............................................................................. 34 2.6 EJEMPLO DE FUNCIONES.................................................................................................................. 35 2.7 GENERACIÓN DE REPORTES ............................................................................................................. 35 CAPÍTULO # 3: MANUAL DE USUARIO DEL DATAR ................................................................. 37 3.1 REQUERIMIENTOS PARA LA EJECUCIÓN DEL SISTEMA ..................................................................... 38 3.2 INICIO DEL SISTEMA DATAR ........................................................................................................... 38 3.3 VISTA PRINCIPAL DEL SISTEMA ...................................................................................................... 39 3.4 MENÚ PRINCIPAL DEL SISTEMA ....................................................................................................... 39 3.4.1 Vistas de datos asociada al proceso de entrada de datos pre-operatorios del paciente receptor de órgano. ......................................................................................................................... 42 3.4.2 Vistas de datos asociada al proceso de entrada de datos pre-operatorios del paciente vivo donador de órgano. ......................................................................................................................... 48 3.4.3 Vistas de datos asociadas al proceso de entrada de datos del paciente muerto donador de órgano. ............................................................................................................................................ 50 3.4.4 Vistas de datos asociadas al proceso del acto operatorio del paciente donante vivo ............ 50 3.4.5 Vista de datos asociada al proceso de visualización de reportes........................................... 52 3.4.6 Vista visor de reportes............................................................................................................ 53 CONCLUSIONES .................................................................................................................................. 55.

(8) RECOMENDACIONES ........................................................................................................................ 56 REFERENCIAS ...................................................................................................................................... 57 BIBLIOGRAFÍA .................................................................................................................................... 58.

(9)

(10) 1. Introducción Cuba realiza trasplante renal desde hace 34 años, es de hecho uno de los primeros países de nuestro continente en esta experiencia. Este tipo de trasplante es el pionero en el mundo, y nosotros hemos logrado incrementar la tasa de realización por encima de 17 /1 000 000 de habitantes en los últimos 3 años, cifra principal en Latinoamérica. (Duro, 2003) De 1970 a 1979 todos los trasplantes se efectuaron con donante cadáver y en 1979 se comenzó a emplear el donante vivo emparentado y compatible; no obstante, se ha mantenido históricamente en todos estos años más del 90 % de estos con donante cadáver. La tasa de donantes en Cuba oscila entre 15 y 19/1 000 000 de habitantes. El progreso experimentado por los trasplantes en los últimos 40 años ha sido espectacular. Las nuevas técnicas y terapias inmunosupresoras han hecho posible que esta modalidad de tratamiento sustitutivo se haya generalizado.(2006) Actualmente no existe un sistema en el Hospital Docente Provincial “Arnaldo Milián Castro” que permita el adecuado procesamiento de la información relacionada con el Trasplante Renal por lo que se propone obtener un Sistema de Bases de Datos que permita el manejo de la información antes mencionada y sirva de base para la creación de nuevos módulos capaces de ofrecer una visión a nivel Nacional mediante servicios de Web y que permitan además una ayuda en la toma de decisiones. Después de varios estudios realizados al proyecto se tomaron las decisiones pertinentes con relación a la plataforma tecnológica que iba a ser utilizada. Se decide utilizar SQL Server como servidor centralizado de la base de datos, por varias razones: •. Seguridad: dada la popularidad de los sistemas operativos Windows en nuestro entorno (país), SQL Server utiliza un esquema de seguridad integra con Windows NT, que garantiza, en gran medida la seguridad del sistema.. •. Factibilidad: SQL Server es un Sistema de Gestión de Bases de Datos, que resulta familiar para los tesiantes y tutores, además forma parte del currículo de la carrera.. •. Rendimiento: SQL Server es un eficiente Sistema de Gestión de Bases de Datos..

(11) 2. También se decide utilizar Delphi como lenguaje de programación de alto nivel. Existen múltiples experiencias satisfactorias acerca de la utilización combinada del SQL Server y aplicaciones desarrolladas en Delphi.(Addison-Wesley) La decisión de utilizar una base de datos centralizada, en vez de recurrir a la estrategia de utilizar una base de datos distribuida, se debió, en lo fundamental, al criterio de la seguridad del sistema. Entendiendo la seguridad, no solo como la limitación del acceso a los datos, sino además como la disponibilidad y la integridad de los mismos, es un hecho innegable que es más fácil invertir recursos necesarios (ejemplos: UPS, memorias, arreglos de discos duros en espejo, etc.) en un solo sitio que en varios. De la misma manera, es más cómodo establecer y revisar políticas adecuadas para el acceso a un solo sitio que a varios. Este trabajo se presenta en tres capítulos: el primero se centra en la discusión y el análisis de una serie de herramientas computacionales que nos han servido para la resolución del problema planteado como son: Microsoft SQL Server 2000, las Aplicaciones Win32 usando el entorno Delphi. Haremos referencia además a la arquitectura multicapa y a la arquitectura Cliente Servidor analizando sus beneficios y los soportes físicos de dichos esquemas, es decir, las redes y los dispositivos de hardware que ellas necesitan. En el capítulo dos se aborda todo lo relacionado con el proceso de análisis e implementación del sistema, describiendo el proceso del negocio, así como los diferentes diagramas de actividades, actores y casos de uso. Finalmente en el último capítulo se expone una guía de cómo usar el sistema lo que se considera un manual de usuario del mismo.. HIPÓTESIS DE LA INVESTIGACIÓN Las herramientas anteriormente mencionadas permiten construir una base de datos lo suficientemente robusta para soportar los requerimientos del sistema y en particular llevar el control total de los pacientes sometidos a un trasplante renal en el Hospital “Arnaldo Milián Castro” de Villa Clara, garantizando la adecuada seguridad del mismo. Los módulos a realizar permiten la actualización de la base de datos, con nuevos pacientes y su seguimiento, así como el control de flujo de generación de documentos del sistema..

(12) 3. OBJETIVO GENERAL Desarrollar un sistema computacional para el control de la información de los pacientes con trasplante renal realizados en el Hospital universitario “Arnaldo Milián Castro” de Villa Clara, utilizando tecnología Cliente/Servidor y un lenguaje de programación de alto nivel, con la asesoría de especialistas en trasplante renal, con diversas funcionalidades para mejorar la gestión de dicho hospital, sentando las bases para la creación de un posterior sistema de toma de decisiones. Implementar una solución basada en una arquitectura de tres capa, centrándose básicamente en las capas de datos y presentación.. OBJETIVOS ESPECÍFICOS 1. Construir una base de datos lo suficientemente robusta para soportar los requerimientos de sistema. 2. Desarrollar el sistema encargado de manipular toda la información almacenada en la base de datos. 3. Desarrollar el módulo del control del flujo de generación de documentos del sistema. 4. Implementar el módulo responsable de brindar las informaciones requeridas..

(13) 4. Capítulo 1. Empleo de tecnologías y herramientas computacionales en la Gestión y el Control de los Pacientes con Trasplante Renal..

(14) 5. En el presente capítulo se abordan los conceptos y las herramientas utilizadas para el desarrollo del sistema DataR. Se presenta el modelo Cliente/Servidor y su arquitectura, así como el modelo de acceso a datos ADO, y la estructura de la arquitectura multicapa.. 1.1 MODELO CLIENTE/SERVIDOR La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes.(Straub, 1996) En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada usuario. Los clientes realizan generalmente funciones como: •. Manejo de la interfaz de usuario.. •. Captura y validación de los datos de entrada.. •. Generación de consultas e informes sobre las bases de datos.. Por su parte los servidores realizan, entre otras, las siguientes funciones: •. Gestión de periféricos compartidos.. •. Control de accesos concurrentes a bases de datos compartidas.. •. Enlaces de comunicaciones con otras redes de área local o extensa.. Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y éste le responde proporcionándolo. Normalmente, pero no necesariamente, el cliente y el servidor están ubicados en distintos procesadores. Los clientes se suelen situar en ordenadores personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de grupo.(Morgenstern, 1983).

(15) 6. 1.1.1 CARACTERÍSTICAS FUNCIONALES Esta arquitectura se puede clasificar en cinco niveles, según las funciones que asumen el cliente y el servidor, tal y como se puede ver en el siguiente diagrama:. Figura 1.1.1.1 Niveles de la arquitectura cliente/servidor.. En el primer nivel el cliente asume parte de las funciones de presentación de la aplicación, ya que siguen existiendo programas en el servidor dedicados a esta tarea. Dicha distribución se realiza mediante el uso de productos para el "maquillaje" de las pantallas del mainframe. Esta técnica no exige el cambio en las aplicaciones orientadas a terminales, pero dificulta su mantenimiento. Además, el servidor ejecuta todos los procesos y almacena la totalidad de los datos. En este caso se dice que hay una presentación distribuida o embellecimiento. En el segundo nivel la aplicación está soportada directamente por el servidor, excepto la presentación que es totalmente remota y reside en el cliente. Los terminales del cliente soportan la captura de datos, incluyendo una validación parcial de los mismos y una presentación de las consultas. En este caso se dice que hay una presentación remota. En el tercer nivel la lógica de los procesos se divide entre los distintos componentes del cliente y del servidor. El diseñador de la aplicación debe definir los servicios y las interfaces del sistema de información de forma que los papeles de cliente y servidor sean.

(16) 7. intercambiables, excepto en el control de los datos que es responsabilidad exclusiva del servidor. En este tipo de situaciones se dice que hay un proceso distribuido o cooperativo. En el cuarto nivel el cliente realiza tanto las funciones de presentación como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. En esta situación se dice que hay una gestión de datos remota. En el quinto y último nivel, el reparto de tareas es como en el anterior y además el gestor de base de datos divide sus componentes entre el cliente y el servidor. Las interfaces entre ambos están dentro de las funciones del gestor de datos y, por lo tanto, no tienen impacto en el desarrollo de las aplicaciones. En este nivel se da lo que se conoce como bases de datos distribuidas.. 1.1.2 CARACTERÍSTICAS FÍSICAS El diagrama del punto anterior da una idea de la estructura física de conexión entre las distintas partes que componen una arquitectura cliente / servidor. La idea principal consiste en aprovechar la potencia de los ordenadores personales para realizar sobre todo los servicios de presentación y, según el nivel, algunos procesos o incluso algún acceso a datos locales. De esta forma se descarga al servidor de ciertas tareas para que pueda realizar otras más rápidamente. También existe una plataforma de servidores que sustituye al ordenador central tradicional y que da servicio a los clientes autorizados. Incluso a veces el antiguo ordenador central se integra en dicha plataforma como un servidor más. Estos servidores suelen estar especializados por funciones (seguridad, cálculo, bases de datos, comunicaciones, etc.), aunque, dependiendo de las dimensiones de la instalación se pueden reunir en un servidor una o varias de estas funciones.(Schlesinger, 1987).

(17) 8. Las unidades de almacenamiento masivo en esta arquitectura se caracterizan por incorporar elementos de protección que evitan la pérdida de datos y permiten multitud de accesos simultáneos (alta velocidad, niveles RAID, etc.). Para la comunicación de todos estos elementos se emplea un sistema de red que se encarga de transmitir la información entre clientes y servidores. Físicamente consiste en un cableado (coaxial, par trenzado, fibra óptica, etc.) o en conexiones mediante señales de radio o infrarrojas, dependiendo de que la red sea local (RAL), metropolitana (MAN) o de área extensa (WAN). Para la comunicación de los procesos con la red se emplea un tipo de equipo lógico denominado middleware que controla las conversaciones. Su función es independizar ambos procesos (cliente y servidor). La interfaz que presenta es la estándar de los servicios de red que hace que los procesos "piensen" en todo momento que se están comunicando con una red.. 1.1.3 CARACTERÍSTICAS LÓGICAS Una de las principales aportaciones de esta arquitectura a los sistemas de información es la interfaz gráfica de usuario. Gracias a ella se dispone de un manejo más fácil e intuitivo de las aplicaciones mediante el uso de un dispositivo tipo ratón. En esta arquitectura los datos se presentan, editan y validan en la parte de la aplicación cliente. En cuanto a los datos, cabe señalar que en la arquitectura cliente/servidor se evitan las duplicidades (copias y comparaciones de datos), teniendo siempre una imagen única y correcta de los mismos disponible en línea para su uso inmediato. Todo esto tiene como fin que el usuario de un sistema de información soportado por una arquitectura cliente/servidor. trabaje desde su estación de trabajo con distintos datos y. aplicaciones, sin importarle dónde están o dónde se ejecuta cada uno de ellos..

(18) 9. 1.1.4 VENTAJAS E INCONVENIENTES. Ventajas •. Aumento de la productividad:. •. Los usuarios pueden utilizar herramientas que le son familiares, como hojas de cálculo y herramientas de acceso a bases de datos.. •. Mediante la integración de las aplicaciones cliente/servidor con las aplicaciones personales de uso habitual, los usuarios pueden construir soluciones particularizadas que se ajusten a sus necesidades cambiantes.. •. Una interfaz gráfica de usuario consistente reduce el tiempo de aprendizaje de las aplicaciones.. •. Menores costos de operación.. •. Permiten un mejor aprovechamiento de los sistemas existentes, protegiendo la inversión. Por ejemplo, la compartición de servidores (habitualmente caros) y dispositivos periféricos (como impresoras) entre máquinas clientes permite un mejor rendimiento del conjunto.. •. Proporcionan un mejor acceso a los datos. La interfaz de usuario ofrece una forma homogénea de ver el sistema, independientemente de los cambios o actualizaciones que se produzcan en él y de la ubicación de la información.. •. El movimiento de funciones desde un ordenador central hacia servidores o clientes locales origina el desplazamiento de los costes de ese proceso hacia máquinas más pequeñas y por tanto, más baratas.. •. Mejora en el rendimiento de la red.. •. Las arquitecturas cliente/servidor eliminan la necesidad de mover grandes bloques de información por la red hacia los ordenadores personales o estaciones de trabajo para su proceso. Los servidores controlan los datos, procesan peticiones y después transfieren sólo los datos requeridos a la máquina cliente. Entonces, la máquina.

(19) 10. cliente presenta los datos al usuario mediante interfaces amigables. Todo esto reduce el tráfico de la red, lo que facilita que pueda soportar un mayor número de usuarios. •. Tanto el cliente como el servidor pueden escalarse para ajustarse a las necesidades de las aplicaciones. Las UCPs utilizadas en los respectivos equipos pueden dimensionarse a partir de las aplicaciones y el tiempo de respuesta que se requiera.. •. La existencia de varias UCPs proporciona una red más fiable: un fallo en uno de los equipos no significa necesariamente que el sistema deje de funcionar.. •. En una arquitectura como ésta, los clientes y los servidores son independientes los unos de los otros con lo que pueden renovarse para aumentar sus funciones y capacidad de forma independiente, sin afectar al resto del sistema.. •. La arquitectura modular de los sistemas cliente/servidor permite el uso de ordenadores especializados (servidores de base de datos, servidores de ficheros, estaciones de trabajo para CAD, etc.).. •. Permite centralizar el control de sistemas que estaban descentralizados, como por ejemplo la gestión de los ordenadores personales que antes estuvieran aislados.. Inconvenientes •. Hay una alta complejidad tecnológica al tener que integrar una gran variedad de productos.. •. Requiere un fuerte rediseño de todos los elementos involucrados en los sistemas de información. (modelos. de. datos,. procesos,. interfaces,. comunicaciones,. almacenamiento de datos, etc.). Además, en la actualidad existen pocas herramientas que ayuden a determinar la mejor forma de dividir las aplicaciones entre la parte cliente y la parte servidor. •. Es más difícil asegurar un elevado grado de seguridad en una red de clientes y servidores que en un sistema con un único ordenador centralizado.. •. A veces, los problemas de congestión de la red pueden degradar el rendimiento del sistema por debajo de lo que se obtendría con una única máquina (arquitectura centralizada). También la interfaz gráfica de usuario puede a veces ralentizar el funcionamiento de la aplicación..

(20) 11. •. El quinto nivel de esta arquitectura (bases de datos distribuidas) es técnicamente muy complejo y en la actualidad hay muy pocas implantaciones que garanticen un funcionamiento totalmente eficiente.. •. Existen multitud de costes ocultos (formación en nuevas tecnologías, licencias, cambios organizativos, etc.) que encarecen su implantación.. 1.1.5 AMBIENTES DE DESARROLLO EN EL LADO DEL CLIENTE Son muchas las herramientas que existen en la actualidad para el desarrollo de aplicaciones en la plataforma Windows. Entre las más conocidas están aquellas que son distribuidas por Microsoft aunque también existen muchas otras compañías productoras de este tipo de software como la Borland. que distribuye Delphi, CBuilder, etc. Cada una de las. herramientas antes mencionadas tiene sus especificidades por lo que el programador tiene que ser capaz de de construir una interfaz de forma adecuada que cumpla con los requisitos de la aplicación, brindando las mayores facilidades posibles a los usuarios.(Do Prado Leite, 1998). 1.2 ESTRUCTURA DE LA ARQUITECTURA MULTICAPA El rápido crecimiento de la popularidad de Internet ha ocasionado el cambio en la forma de encarar el desarrollo de aplicaciones trayendo consigo nuevas tecnologías que hacen que las redes existentes tengan que adaptarse a esta exitosa forma de comunicación. Implementar soluciones basadas en una arquitectura multi-capa significa crear aplicaciones divididas en capas funcionales que se comunican entre sí. Este modelo implica definir esquemas de comunicación, protocolos y estándares entre cada componente de este nuevo esquema. La Error! Reference source not found. muestra una arquitectura de tres capas..

(21) 12. Figura 0.1 Modelo de tres capas. 1. Capa de Base de Datos: Contiene clases que interactúan con la base de datos, estas clases altamente especializadas se encuentran en la arquitectura y permiten, utilizando los procedimientos almacenados generados, realizar todas las operaciones con la base de datos de forma transparente para la capa de negocio.. 2. Capa de negocio: Esta capa esta formada por las entidades empresariales, que representan objetos que van a ser manejados o consumidos por toda la aplicación.. 3. Capa de presentación o interface de usuario: En este caso, esta formada por los formularios y los controles que se encuentran en los formularios. Capa con la que interactúa el usuario.. Ventajas •. Disponibilidad: La disponibilidad se refiere a la cantidad de tiempo que una aplicación es capaz de dar servicio confiable a las peticiones del cliente. Es importante debido a que una aplicación solamente es útil cuando está disponible para dar servicio a las peticiones de los clientes. A su vez, depende de elementos que están más allá del control del desarrollador, como por ejemplo: disponibilidad de hardware, (controlador de disco, tarjetas de red, controladores, etc.), disponibilidad de software (servidores de web, sistemas de espera, etc.) y disponibilidad de red.. •. Escalabilidad: La escalabilidad es la meta utópica del crecimiento lineal del rendimiento al agregar recursos adicionales, y es lo que le permite a una aplicación.

(22) 13. soportar desde 10 usuarios, hasta decenas de miles de usuarios, simplemente agregando o quitando recursos como sea necesario para "escalar". Para incrementar la escalabilidad, los desarrolladores de aplicaciones deben concentrarse en mantener los tiempos de adquisición de recursos y de uso de recursos tan bajos como sean posibles. Los monitores transaccionales permiten compartir recursos entre usuarios reutilizando los ya existentes. •. Interoperabilidad: La interoperabilidad se refiere a la habilidad de una aplicación para acceder a aplicaciones, los datos o los recursos en otras plataformas. Muchos ambientes institucionales soportan diferentes tipos de hardware y sistemas de software que deben trabajar juntos, por lo cual es importante que las aplicaciones tengan la capacidad de interoperar. Para maximizar la interoperabilidad, las aplicaciones deben utilizar estándares que permitan la conectividad entre diferentes productos y/o aplicaciones. 1.3 EL GESTOR DE BASES DE DATOS MICROSOFT SQL SERVER. En la actualidad una de las aplicaciones de mayor aceptación en el mundo del las bases de datos es Microsoft SQL Server con su distribución Microsoft® SQL Server™ 2000, y su distribución más reciente de Microsoft® SQL Server™ 2005. Microsoft SQL Server constituye la alternativa de Microsoft a otros potentes sistemas gestores de bases de datos como son Oracle, MySQL, etc. Este producto ha incorporado un conjunto de funcionalidades que le proporcionan al desarrollador un cómodo ambiente de trabajo para la implementación de una base de datos, posibilitándole realizar operaciones de inserción, actualización, eliminación y recuperación de información una vez realizado el diseño: esquema conceptual de la base de datos en cuestión.(Dayal, 1988) Entre las características de Microsoft SQL Server figuran: 1. Soporte de transacciones. 2. Escalabilidad, estabilidad y seguridad. 3. Soporta procedimientos almacenados. 4. Incluye también un potente entorno gráfico de administración, que permite el uso de comandos DDL y DML gráficamente..

(23) 14. 5. Permite trabajar en modo cliente/servidor donde la información y datos se alojan en el servidor y las terminales o clientes de la red sólo acceden a la información. 6. Además permite administrar información de otros servidores de datos. Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de datos pero orientado a proyectos más pequeños, que en su versión 2005 pasa a ser el SQL Express Edition.. 1.3.1 PROCEDIMIENTOS ALMACENADOS. Los procedimientos almacenados son unas de las funcionalidades más útiles y mas utilizadas de SQL Server, incluso para una aplicación diseñada con N capas todas las consultas a la base de datos se suelen hacer con procedimientos almacenados. Una vez se halla creado un procedimiento almacenado este se puede invocar directamente desde una aplicación ya sea para obtener datos desde la base de datos o para modificar o insertar nuevos datos en ella. Los procedimientos almacenados permiten que se les pueda pasar parámetros de entrada y ellos pueden retornar también ciertos valores como parámetros de salida. Usar los procedimientos almacenados en lugar de códigos Transact-SQL en el lado del cliente tiene las siguientes ventajas: •. Permite una programación más modular.. •. Reduce el tamaño de las aplicaciones.. •. Se logra que el código sea reutilizable.. •. Es más fácil el mantenimiento de la aplicación.. •. Los procedimientos almacenados al ser ejecutados por el servidor: •. reducen el tráfico en la red logrando un mejor desempeño esencialmente por parte del cliente remoto.. •. Contribuyen con la seguridad del sistema..

(24) 15. 1.3.2 FUNCIONES Microsoft incorporó el uso de funciones a partir de su producto Microsoft SQL Server 2000, lo que le permitió a los programadores crear sus propias funciones, y eliminó el problema que existía de reutilización de código. SQL Server utiliza 3 tipos de funciones: funciones fijas de servidor, funciones fijas de Base de Datos, y funciones definidas por el usuario. Funciones fijas de servidor: Permiten al administrador de la base de datos asignar determinados grupos de permisos administrativos. Esto posibilita que cada usuario de la base de datos tenga acceso solo a la parte de la información que a él le compete. Tabla 1.1 Funciones fijas de servidor de SQL Server Función fija de servidor. Descripción. sysadmin. Realiza cualquier actividad en SQL Server.. serveradmin. Configura opciones de configuración válidas en todo el servidor y apaga el servidor.. setupadmin. Administra los servidores conectados y los procedimientos de inicio.. securityadmin. Administra las cuentas de inicio de sesión, CREA permisos a BASES DE DATOS, lee los registros de errores y cambia las contraseñas..

(25) 16. processadmin. Administra los procesos que se ejecutan en SQL Server.. dbcreator. Crea, modifica y elimina bases de datos.. diskadmin. Administra los archivos de disco.. Funciones fijas de Base de Datos Las funciones fijas de base de datos permiten al administrador de base de datos y al propietario asignar determinados grupos de permisos administrativos. En lugar de conceder al usuario todos los privilegios de propietario de la base de datos, las funciones fijas de base de datos permiten al administrador asignar sólo los permisos que él desee concederle al usuario. Tabla 1.2 Funciones fijas de base de datos de SQL Server Función fija de base de datos. Descripción. db_owner. Tiene todos los permisos de la base de datos.. db_accessadmin. Puede agregar o eliminar Id. de usuarios.. db_securityadmin. Puede administrar todos los permisos, todas las propiedades de objetos, las funciones y las.

(26) 17. pertenencias a funciones.. db_ddladmin. Puede emitir instrucciones ALL DDL, pero no GRANT, REVOKE ni DENY.. db_backupoperator. Puede emitir instrucciones DBCC, CHECKPOINT y BACKUP.. db_datareader. Puede seleccionar todos los datos de cualquier tabla de usuario de la base de datos.. db_datawriter. Puede modificar todos los datos de cualquier tabla de usuario de la base de datos.. db_denydatareader. No puede seleccionar ningún dato de ninguna tabla de usuario de la base de datos.. db_denydatawriter. No puede modificar ningún dato de ninguna tabla de usuario de la base de datos..

(27) 18. Funciones de base de datos definidas por el usuario Las funciones fijas de base de datos definidas por el usuario permiten al administrador y al propietario de la base de datos administrar más fácilmente grupos de permisos, modularizar la programación en TRANSACT-SQL y por ende lograr mayor claridad en el código en el lado del servidor. Las funciones definidas por el usuario pueden anidarse, pero esta característica debe utilizarse con moderación para evitar conflictos de seguridad y otros problemas. SQL Server 2000 admite tres tipos de funciones definidas por el usuario: •. Funciones escalares.. •. Funciones de valores de tabla en línea.. •. Funciones de valores de tabla de múltiples instrucciones.. Las funciones escalares devuelven un tipo de los datos tal como int, money, varchar, real, etc. Pueden ser utilizadas en cualquier lugar incluso incorporado dentro de sentencias SQL. Las funciones de tabla en línea son las funciones que devuelven la salida de una simple declaración SELECT. La salida se puede utilizar adentro de joins o querys como si fuera una tabla de estándar. Las funciones de tabla de multi sentencias son similares a los procedimientos almacenados excepto que vuelven un tabla. Este tipo de función se usa en situaciones donde se requiere más lógica y proceso.(2005). 1.3.3 DESENCADENADORES Los desencadenadores no son más que un tipo especial de procedimiento almacenado que se activa de manera automática cuando el usuario activa uno de sus estados de modificación, que puede originarse producto a la acción de actualización en la base de datos, u otra operación como inserción o eliminación, en determinadas tablas..

(28) 19. 1.4 EL ENTORNO DE DESARROLLO DE SOFTWARE DELPHI Delphi es un entorno de desarrollo de software diseñado para la programación de propósito general con mayor énfasis en la programación visual. El Delphi utiliza como lenguaje de programación el Object Pascal. Un uso habitual de Delphi (aunque no es el único) es el desarrollo de aplicaciones visuales y de bases de datos cliente/servidor y multicapas. Debido a que es una herramienta de propósito múltiple, se usa también para proyectos de casi cualquier tipo, incluyendo aplicaciones de consola, aplicaciones de web (por ejemplo servicios web, CGI, ISAPI, NSAPI, módulos para Apache), servicios COM y DCOM, y servicios del sistema operativo.. 1.4.1 COMPONENTES Delphi dio una implementación muy buena a la idea del uso de componentes, que son piezas reutilizables de código (clases) que pueden interactuar con el EID en tiempo de diseño y desempeñar una función específica en tiempo de ejecución. Desde un enfoque más específico de la herramienta, se catalogan como componentes todos aquellos objetos que heredan de la clase TComponent, donde se implementa la funcionalidad necesaria para interactuar con el entorno de desarrollo, la carga dinámica desde streams y la liberación de memoria mediante una jerarquía. Una gran parte de los componentes disponibles para Delphi son controles (derivados de TControl), que encapsulan los elementos de interacción con el usuario como botones, menús, barras de desplazamiento, etcétera. Delphi incluye una biblioteca de clases bien diseñada denominada VCL (Visual Component Library, Biblioteca de Componentes Visuales) y, en sus versiones 6 y 7, una jerarquía multiplataforma paralela denominada CLX. Ésta también se incluye en Kylix (versión de Delphi para Linux). Estas jerarquías de objetos incluyen componentes visuales y no visuales, tales como los pertenecientes a la categoría de acceso a datos, con los que puede establecerse conexiones de forma nativa o mediante capas intermedias (como ADO, BDE u ODBC) a la mayoría de las bases de datos relacionales existentes en el mercado. La VCL también está disponible para el desarrollo en .NET..

(29) 20. Además de poder utilizar en un programa estos componentes estándar (botones, grillas, conjuntos de datos, etc.), es posible crear nuevos componentes o mejorar los ya existentes, extendiendo la funcionalidad de la herramienta. En Internet existe un gran número de componentes, tanto gratuitos como comerciales, disponibles para los proyectos a los que no les basten los que vienen ya con la herramienta.. 1.4.2 EVENTOS Delphi permite de manera sencilla ejecutar trozos de código en respuesta a acciones o eventos (sucesos) que ocurren durante el tiempo que un programa se ejecuta. Por ejemplo, cuando se presiona un botón, la VCL captura la notificación estándar de windows, y detecta si hay algún método asociado al evento OnClick del botón. Si lo hay, manda ejecutar dicho método. Los eventos pueden generarse debido a la recepción de señales desde elementos de hardware como el ratón o el teclado, o pueden producirse al realizar alguna operación sobre un elemento de la propia aplicación (como abrir un conjunto de datos, que genera los eventos BeforeOpen/AfterOpen). La VCL ha demostrado estar bien diseñada y el control que se tiene a través de los eventos de la misma es suficiente para la gran mayoría de las aplicaciones.. 1.4.3 BASE DE DATOS Una de las principales características y ventajas de Delphi es su capacidad para desarrollar aplicaciones con conectividad a bases de datos de diferentes fabricantes. El programador de Delphi cuenta con una gran cantidad de componentes para realizar la conexión, manipulación, presentación y captura de los datos, algunos de ellos liberados bajo licencias de código abierto o gratuito. Estos componentes de acceso a datos pueden enlazarse a una gran variedad de controles visuales, aprovechando las características del lenguaje orientado a objeto, gracias al polimorfismo. En la paleta de componentes pueden encontrarse varias pestañas para realizar una conexión a bases de datos usando diferentes capas o motores de conexión..

(30) 21. Hay motores que permiten conectarse a bases de datos de diferentes fabricantes tales como BDE o ADO, que cuentan con manejadores para los formatos más extendidos.. 1.4.4 BORLAND DATABASE ENGINE (BDE) Es un motor de conexión a bases de datos de uso bastante amplio y que permite manejar bases de datos de escritorio como dBase, FoxPro y Paradox, además de ofrecer la capacidad para conectarse a servidores SQL locales y remotos. Su uso, va siendo cada vez menor, debido a la pobre gestión de memoria que realiza, sustituyéndolo por componentes más actualizados y especializados como DOAC (Direct Oracle Access Components) o DBExpress, esto sumado a la fiabilidad que están presentando los nuevos gestores de Datos en especial tecnologías como RDO y ADO; los cuales son mantenidos por sus fabricantes, forzando la compatibilidad con las versiones preliminares; liberando al programador de actualizaciones en cuanto a gestión de datos.. 1.4.5 DESARROLLO VISUAL Como entorno visual, la programación en Delphi consiste en diseñar los formularios que componen al programa colocando todos sus controles (botones, etiquetas, campos de texto, etc.) en las posiciones deseadas, normalmente usando un ratón. Luego se asocia código a los eventos de dichos controles y también se pueden crear módulos de datos, que regularmente contienen los componentes de acceso a datos y las reglas de negocio de una aplicación.. 1.4.6 ENTORNO INTEGRADO DE DESARROLLO (EID) EID es el ambiente de desarrollo de programas de Delphi. Se trata de un editor de formularios (que permite el desarrollo visual), un potente editor de textos que resalta la sintaxis del código fuente, la paleta de componentes y el depurador integrado, además de una barra de botones y un menú que nos permite la configuración de la herramienta y la gestión de proyectos. En las ediciones Client/Server y Enterprise el EID también ofrece integración con una herramienta de control de versiones (PVCS)..

(31) 22. 1.4.7 DEPURADOR INTEGRADO Es una potente característica que nos permite establecer puntos de ruptura (breakpoints), la ejecución paso a paso de un programa, el seguimiento de los valores de las variables y de la pila de ejecución, así como la evaluación de expresiones con datos de la ejecución del programa. Con su uso, un programador experimentado puede detectar y resolver errores lógicos en el funcionamiento de un aplicativo desarrollado con Delphi. En las ediciones Client/Server y Enterprise se añade la opción de depuración a programas corriendo en equipos remotos (remote debugging), lo que posibilita el uso de todas las características del depurador con un programa ejecutándose en su entorno normal de trabajo y no en el ordenador del programador (en donde muchas veces no ocurren los errores).. 1.5 MODELO DE ACCESO A DATOS: ADO (MICROSOFT ACTIVEX DATA OBJECTS) ADO (ActiveX Data Objects) es uno de los mecanismos que usan los programas de computadoras para comunicarse con las bases de datos, darles órdenes y obtener resultados de ellas. Con ADO, un programa puede leer, insertar, editar, o borrar, la información contenida en diferentes áreas de almacenamiento dentro de la base de datos llamadas tablas. Además, se puede manipular la propia base de datos para crear nuevas áreas para el almacenamiento de información (tablas), como también alterar o eliminar las ya existentes, entre otras cosas. Fue desarrollado por. Microsoft y es usado en ambientes Windows por lenguajes de. programación como Visual Basic, C++, Delphi entre otros, también puede ser usado en la web. ADO es un intermediario entre el programa y la base de datos. El programa no ve la base de datos directamente, sino que hace todo el trabajo a través de ADO. Usando ADO, el programa se comunica con la base de datos, consulta, edita, inserta, borra, registros, añade tablas, etc. ADO a su vez se comunica con la base de datos a través de un "proveedor de datos". En la dirección contraria, la base de datos responde, comunicándose con el proveedor de datos, éste con ADO, y al final, la información llega al programa. Una vez que el.

(32) 23. programa tiene la información proveniente de la base de datos, puede hacer con ella lo que considere..

(33) 24. Capítulo 2. Análisis, diseño e implementación del Sistema para el control de pacientes con trasplante renal..

(34) 25. 2.1 Diseño y análisis del sistema El software que se implementa tiene como objetivo principal monitorear la evolución del paciente con falla renal. El mismo recoge los datos del individuo desde su entrada al salón de operaciones, para realizársele un trasplante renal, y su posterior evolución que será evaluada regularmente hasta el fallecimiento del paciente, sea o no por falla renal. Durante la realización de este proyecto se realizaron varias entrevistas de trabajo con el experto en el área médica de nefrología, en el que se realizó un análisis detallado del proceso de captura de datos de los pacientes con trasplante renal realizado. Como resultado se obtienen los casos de usos del negocio así como los del sistema. Además, en esta fase se identifican las interfaces externas, se hace una valoración inicial de los riesgos y se evalúa el conjunto de requisitos del sistema.. 2.2 MODELO DEL NEGOCIO Producto a las distintas secciones de trabajo realizadas con el experto en el área médica de nefrología en que se hizo un análisis pormenorizado de la captura de datos de los pacientes con trasplante renal realizado, se confeccionó un diagrama de actividad en el que se visualiza el flujo de dicho proceso, describiendo así el funcionamiento del negocio..

(35) 26. Figura 2.2.1 Diagrama de Actividad del Negocio. 2.3 ACTORES Y CASOS DE USO Después de un largo análisis del modelo del negocio pasamos a identificar los diferentes casos de usos del negocio. Entrada de los datos en “La historia clínica del paciente receptor de órgano”. • Datos generales. • Interrogatorios por aparatos. • Examen físico. • Hoja de laboratorio..

(36) 27. • Estudios inmunológicos. • Estudios radiológicos. • Otros estudios. • Validación de los datos. Entrada de los datos del “Paciente vivo donador de órgano”. • Datos generales. • Interrogatorios por aparatos. • Examen físico. • Hoja de laboratorio. • Estudios inmunológicos. • Estudios radiológicos. • Otros estudios. • Validación de los datos. Entrada de los datos del paciente muerto donador de órgano. •. Datos generales.. Entrada del acto operatorio de paciente vivo donador de órgano. •. Datos generales.. •. Complicaciones.. •. Transfusiones.. •. Perfusión, características y solución.. •. Características del riñón.. •. Equipo de trabajo.. Entrada del acto operatorio del donante muerto. •. Datos Generales.. Entrada de datos del pareja donante - receptor. •. Donante. •. Receptor. Evolución..

(37) 28. •. Seguir con la evolución tanto del paciente como del receptor del órgano.. Los casos de uso del negocio son equivalentes a los siguientes casos de uso del sistema para DataR: •. Recolección de datos del paciente receptor de órgano.. •. Recolección de datos del paciente vivo donador de órgano.. •. Recolección de datos de paciente muerto donador de órgano.. •. Recolección de datos del par donante - receptor.. •. Evolución.. •. Generación de Reportes. Los actores del sistema son: el especialista en nefrología. En el sistema se controlan todas las acciones que puede realizar el único actor que presenta nuestro sistema. El especialista es en encargado de mantener actualizado todo el sistema. Para esto se han creado varias opciones dentro del mismo software. Los casos de uso del sistema para la administración se exponen a continuación: •. Actualización de hospitales.. •. Actualización del equipo de trabajo médico que participa en los actos operatorios.. A continuación se muestra el diagrama de casos de uso de DataR:. Figura 2.3.1 Casos de uso de DataR.

(38) 29. A continuación algunos de nuestros casos de usos refinados:. Figura 2.3.2 Refinamiento del caso de uso: Captura de Datos de los pacientes. Figura 2.3.3 Refinamiento del caso de uso: Detalles del acto operatorio.

(39) 30. Figura 2.3.4 Refinamiento del caso de uso: Generar reportes. Figura 2.3.2 Refinamiento del caso de uso: Adicionar datos de los pacientes receptores de órgano..

(40) 31. 2.4 DISEÑO DE LA BASE DE DATOS La base de datos fue implementada en SQL Server 2000 y consta de 47 tablas, una función y varios procedimientos almacenados. Gran parte de las iteraciones de la interfaz con la base de datos se realiza a través de esta función y de los procedimientos almacenados. El diseño de la base de datos está dividido en tres partes fundamentales: una donde se almacena todo lo referente al equipo médico que labora en el área de nefrología, otra donde se guardan los datos generales referentes a los pacientes receptores de órgano, donantes vivos y donantes muertos y una donde se guardan los tipos de estudios que se le realizaron a estos pacientes mencionados anteriormente. Debido al gran tamaño que presenta el modelo lógico de la base de datos, se optó por dividirlo en tres partes, (A, B, C), para lograr una mejor comprensión.. Figura 2.4.1 Modelo lógico de la base de datos parte A.

(41) 32. Figura 2.4.2 Modelo lógico de la base de datos parte B.

(42) 33. Figura 2.4.3 Modelo lógico de la base de datos parte C.

(43) 34. 2.5 EJEMPLOS DE PROCEDIMIENTOS ALMACENADOS Los estudios médicos realizados a los pacientes con falla renal constituyen uno de los fundamentos principales de DataR. Para poder obtener la información de cada uno de estos estudios se han tenido que implementar varios procedimientos almacenados. El procedimiento almacenado que nos permite obtener los datos de los estudios inmunológicos del paciente receptor de órganos es: CREATE PROCEDURE EInmunologico @CI varchar(11), @ID integer AS SELECT. dbo.Paciente.CiPaciente,. dbo.EstudiosInmunologicos.FechaEstudioInmunologico, dbo.EstudiosInmunologicos.Resultados, dbo.TipoEstudioInmunologico.IdEstudio FROM. dbo.Paciente INNER JOIN dbo.EstudiosInmunologicos ON dbo.Paciente.CiPaciente =. dbo.EstudiosInmunologicos.CI INNER JOIN dbo.TipoEstudioInmunologico ON dbo.EstudiosInmunologicos.IdEstudio = dbo.TipoEstudioInmunologico.IdEstudio WHERE. (dbo.Paciente.CiPaciente = @CI) AND. (dbo.TipoEstudioInmunologico.IdEstudio = @ID) Se le entran como parámetros el carnet de identidad del paciente que este siendo analizado así como un id que representa el tipo de estudio inmunológico que se desee analizar, ya sea uno para pruebas cruzadas o dos para HLA. Otro ejemplo de procedimiento almacenado es el que nos permite obtener los datos de los interrogatorios por aparatos del paciente receptor de órganos: CREATE PROCEDURE [interrogatorioPaciente] @CI varchar(11), @ID int AS.

(44) 35. SELECT. dbo.InterrogatorioAparatos.FechaInterregatorioAparatos,. dbo.InterrogatorioAparatos.Resultados, dbo.InterrogatorioAparatos.idaparato, dbo.Paciente.CiPaciente FROM. dbo.InterrogatorioAparatos INNER JOIN dbo.Paciente ON dbo.InterrogatorioAparatos.idCI = dbo.Paciente.CiPaciente. INNER JOIN dbo.TipoAparato ON dbo.InterrogatorioAparatos.idaparato = dbo.TipoAparato.IdTipoaparato WHERE. (dbo.InterrogatorioAparatos.idaparato = @id) AND (dbo.Paciente.CiPaciente =. @CI). 2.6 EJEMPLO DE FUNCIONES En la obtención de los datos generales de los pacientes receptores y donadores de órganos, fue de gran utilidad la creación de dos funciones. A continuación mostramos una de ellas. CREATE FUNCTION [DatosPacientes] ( @CI nvarchar(11) ) RETURNS Table AS RETURN ( SELECT * FROM dbo.Paciente WHERE CiPaciente = @CI). 2.7 GENERACIÓN DE REPORTES El sistema cuenta con un generador de reportes, con reportes ya predefinidos que nos da la posibilidad de visualizar un grupo de datos agrupados por un campo determinado, el cual puede ser guardado o impreso según desee el usuario..

(45) 36. Figura 2.7.1 Reporte de pacientes receptores.

(46) 37. Capítulo # 3: Manual de usuario del DataR..

(47) 38. En este capítulo pretendemos describir las principales acciones a desarrollar por el usuario con el propósito de que el mismo sirva como una guía en el uso del sistema.. 3.1 REQUERIMIENTOS. PARA LA EJECUCIÓN DEL SISTEMA. Para su ejecución, el sistema DataR necesita los siguientes requerimientos: En la parte del cliente ▪ Una PC IBM compatible con procesador Pentium o superior. ▪ Al menos 32 MB de memoria RAM. ▪ Al menos 4 MB de espacio en disco duro. ▪ Sistema operativo Windows 95 o superior. En la parte del servidor ▪ Una PC IBM compatible con procesador Pentium o superior. ▪ Al menos 128 MB de memoria RAM. ▪ Alrededor de 200 MB de espacio en disco duro para la instalación de Microsoft SQL Server 2000. ▪ Sistema operativo Windows 2000 o superior.. 3.2 INICIO DEL SISTEMA DATAR Para comenzar a trabajar con el sistema lo primero que hay que hacer es ejecutarlo, para esto diríjase a la carpeta donde tiene almacenado el software y haga doble clic en DataR.exe e inmediatamente el sistema mostrará su pantalla de bienvenida, al mismo tiempo que inicializa todas las conexiones a la base de datos.. Figura 3.2.1 Pantalla de bienvenida de DataR.

(48) 39. 3.3 VISTA PRINCIPAL DEL SISTEMA En la figura 3.3.1 se muestra la pantalla principal del sistema, en la parte superior de la misma podremos encontrar en menú de opciones, debajo de dicho menú, en la parte izquierda de la pantalla se encuentra un árbol de directorios semejante al explorador de Windows con dos directorios, donde el usuario puede elegir entre receptores y donadores. En la parte derecha de la pantalla se visualizan los datos más generales del paciente que este seleccionado en el árbol de directorio.. Figura 3.3.1 Ventana Principal de DataR. 3.4 MENÚ PRINCIPAL DEL SISTEMA El menú principal del sistema, figura 3.4.1, esta compuesto por 3 elementos: 1. Equipo médico 2. Centros Hospitalarios 3. Datos Donante-Receptor 4. Reportes 5. Herramientas.

(49) 40. Figura 3.4.1 Menú de DataR Mediante el submenú Equipo Médico se pueden adicionar los miembros del equipo médico que participa en un trasplante renal:. Figura 3.4.2 Submenú Inicialización •. Enfermeras: Posibilita la entrada de nuevas enfermeras al sistema.. •. Cirujanos: Posibilita la entrada de nuevos cirujanos al sistema.. •. Nefrólogos: Posibilita la entrada de nuevos nefrólogos al sistema.. •. Anestesistas: Posibilita la entrada de nuevos anestesistas al sistema.. •. Técnico Anestesista: Posibilita la entrada de nuevos técnicos anestesistas al sistema.. El submenú Centros Hospitalarios: •. Hospitales: Posibilita la entrada de nuevos hospitales al sistema.. El submenú Datos Donante-Receptor:. Figura 3.4.3 Submenú Datos Donante – Receptor •. Receptor: Permite la entrada al sistema de los datos de los pacientes receptores de órganos.. •. Donante Vivo: Permite la entrada al sistema de los datos de los pacientes vivos donadores de órganos..

(50) 41. •. Donante Muerto: Permite la entrada al sistema de los datos de los pacientes muertos donadores de órganos.. •. Acto operatorio del donador: Permite la entrada al sistema de datos específicos referentes al acto operatorio donde se le extrae el riñón al donante vivo.. •. Evolución: Está compuesto a su vez por dos opciones más, que son: ™ Receptor: Este submenú nos permite la entrada al sistema de las distintas consultas médicas realizadas al paciente que recibió el riñón para seguir la evolución médica del mismo. ™ Donador: Este submenú nos permite la entrada al sistema de las distintas consultas médicas realizadas al paciente que donó el riñón para seguir la evolución médica del mismo.. •. Asociar Donante – Receptor: Este submenú nos permite asignarle a cada paciente receptor su donador correspondiente.. El submenú Reportes:. Figura 3.4.4 submenú Reportes •. Receptores: Permite visualizar e imprimir los datos generales de los pacientes receptores de órganos.. •. Donante vivo: Permite visualizar e imprimir los datos generales de los pacientes donadores vivos de órganos.. •. Donante Vivo – Receptor: Permite visualizar e imprimir cada receptor con su donante.. El submenú Herramientas:. Figura 3.4.4 submenú Herramientas •. Visualizador de reportes: A través de este submenú podemos visualizar reportes guardados con anterioridad con el fin de consultarlos o realizarles una copia impresa..

(51) 42. 3.4.1 VISTAS DE DATOS ASOCIADA AL PROCESO DE ENTRADA DE DATOS PREOPERATORIOS DEL PACIENTE RECEPTOR DE ÓRGANO.. Existen varias vistas para un receptor seleccionado, a continuación mostraremos gran parte de ellas. En la vista Generales, figura 3.4.1.1 se muestran los datos generales de un receptor de órgano, como son nombre y apellidos, carnet de identidad, edad, domicilio, etc.. Figura 3.4.1.1 Entrada de datos de los datos del paciente receptor de órganos. Como podemos observar esta vista contiene un botón llamado Ver por el cual podemos acceder a una vista llamada Antecedentes patológicos personales que contiene los siguientes datos separados en paletas, Enfermedades de la infancia, Vacunación, Transfusiones, Alergia medicamentosa, entre otras..

(52) 43. La vista de Interrogatorio por aparatos figura 3.4.1.2, muestra las distintas pruebas por aparatos hechas al paciente Receptor de órgano recogidas por fecha de realización, como son Cardiovascular, Digestivo, Genito-Urinario, Respiratorio, Ginecológico, HLP, Endocrino y Neurológico. Con opciones para agregar nuevas pruebas. Estas pruebas están ubicadas en paletas con los nombres de los respectivos aparatos.. Figura 3.4.1.2 Interrogatorio por aparatos La vista Examen Físico figura 3.4.1.3, muestra el examen físico realizado a los pacientes receptores separados por la fecha de realización, también permite inserción de nuevos exámenes. Un ejemplo de los datos que aquí se recogen son: peso, talla, piel y mucosa, respiratorio, etc..

(53) 44. Figura 3.4.1.3 Examen Físico La vista Hoja de Laboratorio figura 3.4.1.4, muestra y permite agregar diversos estudios complementarios de los pacientes receptores como son: Hemoglobina, TGP, Colesterol, etc. Cada hoja de laboratorio es identificada por la fecha de su realización..

(54) 45. Figura 3.4.1.4 Hoja de laboratorio La vista Estudios Inmunológicos figura 3.4.1.5 recoge todos los datos de este tipo de estudio ubicados en dos pruebas permitiéndonos ubicarlos por fecha de realización así como la inserción de nuevas pruebas. Las pruebas que se recogen aquí son: Prueba cruzada y HLA..

(55) 46. Figura 3.4.1.5 Estudio inmunológico La vista Estudios Radiológicos figura 3.4.1.6 recoge todos los datos de este tipo de estudio ubicados en siete pruebas permitiéndonos ubicarlos por fecha de realización así como la inserción de nuevas pruebas. Las pruebas que se recogen aquí son: Rx de tórax, Rx abdomen simple, Senos perinasales, Ultrasonido renal y abdominal, Uretrocistografía miccional, Rx de esófago, estomago y duodeno y Doppler vascular de la región Ileo Femoral..

(56) 47. Figura 3.4.1.6 Estudios radiológicos La vista Otros figura 3.4.1.7 recoge otra pruebas más generales como son los EGC, Ecocardiograma, Pruebas funcionales respiratorias, Prueba citológica o antígeno prostático. Al igual que las vistas anteriores nos da la posibilidad de agregar nuevos resultados a las pruebas mencionadas, separadas por fecha..

(57) 48. Figura 3.4.1.7 Otros. 3.4.2 VISTAS DE DATOS ASOCIADA AL PROCESO DE ENTRADA DE DATOS PREOPERATORIOS DEL PACIENTE VIVO DONADOR DE ÓRGANO.. En estas vistas se manejan los mismos datos que en las vistas analizada en el epígrafe anterior pero referente al paciente vivo donador de órganos, solo existen pocos cambios en algunos datos que en esta vista no se recogen como podemos ver en la figura 3.4.2.1..

(58) 49. Figura 3.4.2.1 Entrada de datos de los datos del paciente vivo donador de órganos. La vista mostrada en la figura anterior también presenta el botón Ver para pasas a la vista Antecedentes patológicos personales que debido a su importancia pasamos a mostrársela en la figura 3.4.2.2.. Figura 3.4.2.2 Vista Antecedentes patológicos personales. Como se puede apreciar esta vista es semitransparente con el objetivo de que se puedan observar los datos que hay detrás de ella que corresponden a la misma categoría “Datos Generales”..

(59) 50. 3.4.3 VISTAS DE DATOS ASOCIADAS AL PROCESO DE ENTRADA DE DATOS DEL PACIENTE MUERTO DONADOR DE ÓRGANO.. Solamente existe una vista en el proceso de captura de datos del paciente muerto donador de órganos, figura 3.4.3.1, debido que ha este paciente no se le realiza un seguimiento evolutivo, ni un posterior acto quirúrgico, solo nos interesa conocer algunos datos importantes como son: Grupo sanguíneo, fecha y hora de recibido, los órganos que se le extrajeron, etc.. Figura 3.4.3.1 Vista Donante Muerto. 3.4.4 VISTAS DE DATOS ASOCIADAS AL PROCESO DEL ACTO OPERATORIO DEL PACIENTE DONANTE VIVO. Existen varias vistas para el proceso del acto operatorio del donante vivo, a continuación mostraremos gran parte de ellas. En la primera vista que observamos, figura 3.4.4.1, nos permite la entrada y modificación de diferentes datos como son: tipo de riñón, técnica anestésica, peridural, etc., la vista complicaciones nos permite ver las complicaciones anestésicas y quirúrgicas y modificarlas..

(60) 51. Figura 3.4.4.1 Vista inicial del acto operatorio del donante vivo La vista Trasfusiones, figura 3.4.4.2, nos permite ver la cantidad de glóbulos y plasma que se le suministró al paciente, también permite poner otros datos de interés referentes a este proceso.. Figura 3.4.4.2 Vista Transfusiones La vista Perfusión, características y solución, figura 3.4.4.3, es la encardada de mostrar los datos específicos de la perfusión, como son el inicio, fin y tiempo total de esta..

(61) 52. Figura 3.4.4.3 Vista Perfusión, características y solución La vista Características del riñón, figura 3.4.4.4, no permite añadir una caracterización del riñón extraído al paciente donante vivo.. Figura 3.4.4.4 Vista Características del riñón Cada vista aquí mostrada cuenta con una barra de herramientas ubicada en la parte superior de la vista, dicha barra contiene las operaciones que se pueden realizar con los datos que se muestran.. 3.4.5 VISTA DE DATOS ASOCIADA AL PROCESO DE VISUALIZACIÓN DE REPORTES Existen dos vistas para el proceso de visualización de reportes, a continuación pasamos a mostrarles una de ellas..

(62) 53. Figura 3.4.5.1 Vista Receptores Esta vista nos da la posibilidad de ver un resumen de los datos generales más específicos de los pacientes receptores de órganos, cada paciente tiene sus datos en hojas independientes, las cuales se pueden guardar, o imprimir según desee el usuario.. 3.4.6 VISTA VISOR DE REPORTES La vista visor de reportes, figura 3.4.6.1, es de una gran importancia debido a que esta permite la visualización de reportes que hayan sido almacenados por el usuario con un propósito especifico, ya sea su posterior impresión o para conocer en una fecha determinada cuantos pacientes habían incluidos en el sistema..

(63) 54. Figura 3.4.6.1 Vista Visor de reportes.

(64) 55. Conclusiones El presente trabajo pone a disposición del personal médico del Hospital Universitario “Arnaldo Milián Castro” de Villa Clara una interfaz cómoda que permite manejar la información almacenada en una base de datos referente a pacientes con trasplantes renales. Se ha logrado obtener un diseño óptimo de la Base de Datos que sirve de apoyo para el adecuado manejo de toda la información necesaria. Se posibilita de esta forma disponer de información referente al seguimiento de diferentes casos para que los médicos puedan emitir criterios que ayuden a la solución de problemáticas sin estar físicamente al lado del paciente. Se pretende además que con sus posteriores actualizaciones llegue a constituir una importante y útil herramienta de ayuda a la toma de decisiones para el personal médico relacionado..

(65) 56. Recomendaciones 1. Trabajar en la Capa de Negocios que permita establecer las reglas que rigen el negocio. 2. Crear módulos capaces de ofrecer una visión a nivel Nacional mediante servicios de Web. 3. Ofrecer la posibilidad de ayuda en la toma de decisiones en el proceso de trasplante renal..

(66) 57. Referencias Microsoft SQL Server. Wikipedia. URL: http://en.wikipedia.org/wiki/ADO (2001) Microsoft Corporation, “Libros en pantalla de MS SQL Server 2000”. Robayna, I. ADO y Delphi. Grupo Albor. 2001. p-4. URL: http://www.grupoalbor.com/descarga/articulos/ado/ado.pdf.

(67) 58. Bibliografía (2005) Funciones en SQL Server 2000. (2006) Trasplante renal en Cuba. ADDISON-WESLEY Booch, Grady. Análisis y Diseño Orientado a objetos, con aplicaciones. DAYAL, U. B., A. P.; MCCHARTY, D. R. (1988) “Rules are Objects too: A Knowledge Model for an Active, Object-Oriented Database Management System”. Advances in ObjectOriented Database Systems. Berlin, K. R. Dittrich. DO PRADO LEITE, J. L., M. C.; TEOREY,T. J. (1998) “Business rules as organizational policies”. in Proc. of Ninth International Workshop on Software Specification and Design,. DURO, V. (2003) Latín América Transplantation Report, The Transplantation Society of Latin America and the Caribbean, 2003. MORGENSTERN, M. (1983) “Active Databases as a Paradigm for Enhanced Computing Environments”. 9th International conference on Very Large Databases. Florence, Italy. SCHLESINGER, M. H. H., C. (1987) “The Design of the POSTGRES Rules System”. IEEE Inter¬national Conference on Data Engineering. STRAUB, P. (1996) Charla sobre arquitecturas Cliente/Servidor [En línea]..

(68) 59. Anexos Anexo 1: Diagrama lógico de la base de datos.

(69)

Figure

Figura 1.1.1.1 Niveles de la arquitectura cliente/servidor.
Figura 0.1 Modelo de tres capas.
Tabla 1.1 Funciones fijas de servidor de SQL Server   Función fija de servidor  Descripción
Tabla 1.2 Funciones fijas de base de datos de SQL Server   Función fija de base de
+7

Referencias

Documento similar

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de

You may wish to take a note of your Organisation ID, which, in addition to the organisation name, can be used to search for an organisation you will need to affiliate with when you

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)