PROYECTO FIN DE CARRERA DISEÑO Y...

UNIVERSIDAD DE SEVILLA ESCUELA SUPERIOR DE INGENIEROS

PROYECTO FIN DE CARRERA

DISEÑO Y DESARROLLO DE UNSISTEMA DE GESTIÓN DE

LABORATORIOS BASADO EN ELSISTEMA DE TÉRMINOS LOINC

Área de Ingeniería Telemática

Departamento de Ingeniería de Sistemas y Automática

Autor: Ramón García Luengo

Tutora: Isabel Román Martínez

Sevilla, a 21 de Junio del 2005

Diseño y Desarrollo de un Sistema de Gestión deLaboratorios basado en el Sistema de Términos LOINC

Diseño y Desarrollo de un Sistema de Gestión de Laboratorios basado en el Sistema de Términos LOINC

- 2 -

ÁREA DE INGENIERÍA TELEMÁTICA. Escuela Superior de Ingenieros



Agradecimientos:

A mi maravillosa familia,

a Isabel, mi tutora

y en especial a Sandrita.

- 3 -




- 4 -




ÍndiceDISEÑO Y DESARROLLO DE UN SISTEMA DE GESTIÓN DE LABORATORIOS BASADO ENEL SISTEMA DE TÉRMINOS LOINC...................................................................................................... 1

1. INTRODUCCIÓN ................................................................................................................... 7

1.1. Estado de la cuestión.............................................................................................................................................. 71.2. Solución Adoptada y Objetivos............................................................................................................................. 81.3. Fases del Proyecto................................................................................................................................................ 101.4. Estructura del documento.................................................................................................................................... 10

2. CONCEPTOS TEÓRICOS .................................................................................................... 12

2.1. Estándares de pruebas de laboratorio................................................................................................................. 122.1.1. LOINC.................................................................................................................................................................................. 12

2.1.1.1. Componente / Analito........................................................................................................................... 132.1.1.2. Clase de propiedad o medición............................................................................................................. 142.1.1.3. Aspecto Temporal................................................................................................................................... 152.1.1.4. Sistema (muestra).................................................................................................................................... 152.1.1.5. Escala........................................................................................................................................................ 162.1.1.6. Tipo de método....................................................................................................................................... 16

2.2. Arquitectura del Sistema..................................................................................................................................... 182.2.1. Tecnologías en la parte del cliente..................................................................................................................................... 19

2.2.1.1. Html.......................................................................................................................................................... 192.2.1.2. CSS............................................................................................................................................................ 192.2.1.3. Javascript.................................................................................................................................................. 19

2.2.2. Tecnologías en la parte del servidor.................................................................................................................................. 202.2.2.1. JSP............................................................................................................................................................. 202.2.2.2. Struts......................................................................................................................................................... 202.2.2.3. JDBC......................................................................................................................................................... 20

2.2.3. Servidor de aplicación.......................................................................................................................................................... 212.2.3.1. Tomcat...................................................................................................................................................... 21

2.2.4. Base de Datos....................................................................................................................................................................... 222.2.4.1. Postgresql................................................................................................................................................. 22

2.3. Struts..................................................................................................................................................................... 242.3.1. Introducción......................................................................................................................................................................... 242.3.2. MVC: Modelo Vista Controlador...................................................................................................................................... 24

2.3.2.1. MVC-2...................................................................................................................................................... 252.3.3. Diseño de Struts................................................................................................................................................................... 26

2.3.3.1. ActionServlet............................................................................................................................................ 282.3.3.2. ActionForm.............................................................................................................................................. 292.3.3.3. Action........................................................................................................................................................ 292.3.3.4. struts-config.xml...................................................................................................................................... 29

2.3.4. Internacionalización............................................................................................................................................................. 322.3.5. Vista....................................................................................................................................................................................... 32

3. REALIZACIÓN PRÁCTICA .................................................................................................. 34

3.1. Estudio del Negocio.............................................................................................................................................. 343.1.1. Casos de uso......................................................................................................................................................................... 35

3.2. Desarrollando en Struts....................................................................................................................................... 403.2.1. Introducción......................................................................................................................................................................... 403.2.2. Ejemplo: Validación de Usuario......................................................................................................................................... 403.2.3. Implementación en el resto de la aplicación..................................................................................................................... 53

3.3. Organización de los Elementos en el Servidor de Aplicación............................................................................ 543.3.1. Introducción......................................................................................................................................................................... 543.3.2. Diseño de los Objetos de Negocio.................................................................................................................................... 553.3.3. Organización de los paquetes............................................................................................................................................. 58

- 5 -




3.3.4. JAVADOC........................................................................................................................................................................... 593.4. Diseño de la Base de Datos................................................................................................................................... 60

3.4.1. Introducción......................................................................................................................................................................... 603.4.2. Diagramas y descripción de tablas..................................................................................................................................... 60

3.4.2.1. Notas sobre los diagramas..................................................................................................................... 613.4.2.2. Diagrama de Solicitudes......................................................................................................................... 623.4.2.3. Diagrama de Parámetros........................................................................................................................ 893.4.2.4. Diagrama de Acceso al Sistema............................................................................................................ 93

3.5. Diseño del flujo de la aplicación.......................................................................................................................... 953.5.1. Acceso al sistema: caso de uso “Validación en el sistema”............................................................................................. 963.5.2. Tratamiento de las Excepciones......................................................................................................................................... 97

3.5.2.1. Excepción al validar un formulario...................................................................................................... 973.5.2.2. Excepción en la lógica de negocio........................................................................................................ 98

3.5.3. Actor Médico........................................................................................................................................................................ 993.5.3.1. Caso de Uso “Elegir Paciente”:............................................................................................................. 993.5.3.2. Caso de Uso “Enviar Solicitud de Prueba de Laboratorio”........................................................... 1013.5.3.3. Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio”................................................ 1023.5.3.4. Caso de Uso “Consultar Solicitudes Consolidadas del Laboratorio”............................................ 1043.5.3.5. Caso de Uso “Ver resultados de Solicitud”....................................................................................... 104

3.5.4. Actor Enfermero................................................................................................................................................................ 1063.5.4.1. Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio”:............................................... 1063.5.4.2. Caso de Uso “Introducir Número de Muestra”............................................................................... 108

3.5.5. Actor Laboratorio.............................................................................................................................................................. 1093.5.5.1. Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio”................................................ 1093.5.5.2. Caso de Uso “Introducir Número de Muestra”............................................................................... 1113.5.5.3. Caso de Uso “Introducir Resultados de Laboratorio”.................................................................... 1113.5.5.4. Caso de Uso “Consolidar Resultado”................................................................................................ 1123.5.5.5. Caso de Uso “Ver Información Prueba”........................................................................................... 1123.5.5.6. Caso de Uso “Añadir Prueba”............................................................................................................ 113

3.5.6. Actor Administrador......................................................................................................................................................... 1153.5.6.1. Caso de Uso “Mantenimiento de Parámetros”................................................................................. 1153.5.6.2. Caso de Uso “Mantenimiento de Médicos”...................................................................................... 117

3.6. Diseño y realización de las páginas................................................................................................................... 119

4. CONCLUSIONES Y LÍNEAS FUTURAS ........................................................................... 123

5. BIBLIOGRAFÍA ................................................................................................................... 125

6. ANEXOS ............................................................................................................................... 127

6.1. Estructura de la Base de Datos LOINC............................................................................................................ 1276.2. strust-config.xml................................................................................................................................................. 1316.3. JAVADOC.......................................................................................................................................................... 140

- 6 -



INTRODUCCIÓN

1. INTRODUCCIÓN

El desarrollo tecnológico ha permitido evolucionar del concepto tradicional de la historia clínica enpapel, hacia una nueva denominación capaz de integrar toda la información referida al estado de saludde una persona, acumulada a lo largo de su vida.

Este nuevo concepto, se puede denominar historia clínica electrónica (EHCR, Electronic HealthcareRecord) y tiene como objetivo final la utilización de las tecnologías de la información y lascomunicaciones para mejorar la atención sanitaria a los ciudadanos.

El presente trabajo “Diseño y Desarrollo de un Sistema de Gestión de Laboratorios basado en elSistema de Términos LOINC” se enmarca dentro del problema de conseguir una historia clínicaelectrónica (EHCR, Electronic Healthcare Record) única para cada individuo.

La historia clínica abarca muchos aspectos, nosotros nos vamos a centrar en recoger la informaciónrelativa a las pruebas de laboratorio que se les hace a los pacientes, ejemplos de las cuales podríanser: hemoglobina de la sangre, potasio del suero, muestras vitales, etc.

Veamos cuales son los motivos que nos mueven a querer sustituir una historia clínica tradicional, ensoporte papel, por una historia clínica informatizada:

1. El crecimiento continuo del volumen almacenado de historiales clínicos, que llega a crear gravesproblemas de espacio físico.

2. Evitar el continuo trasiego de documentos originales que pueden provocar su pérdida o deterioro.

3. Permitir una rápida transmisión de los historiales clínicos con independencia de la ubicación. Estopresenta dos ventajas: una, no importa donde se encuentre el paciente o si está viajando, toda suhistoria clínica será accesible; dos, cada vez es más frecuente que en la atención a los pacientesactúen distintos profesionales que se encuentran en emplazamientos diferentes, por lo tanto sehace necesario que la información relativa al enfermo sea intercambiada de una manera rápida yfiable con independencia de la ubicación.

4. Agilizar el acceso a esta información de una manera tratable a investigadores y a planificadoressanitarios.

5. Bajar los costes asistenciales al permitir compartir observaciones clínicas

1.1. Estado de la cuestiónEl trabajo presente intenta ser un eslabón más en el desarrollo de una historia clínica electrónica

(EHCR). Nos planteamos el objetivo de conseguir un producto real, interoperable, escalable yreutilizable por lo que tendremos que hacer un análisis del estado actual del problema que nos ayude aenfocar y dirigir el trabajo entre las distintas soluciones posibles.

Se puede decir que la historia clínica electrónica (EHCR) es una recopilación única de la informaciónmédica de un individuo. El problema es que esta información se encuentra diseminada en distintossistemas de información federados y geográficamente dispersos. Estos sistemas de informaciónfederados son autónomos y heterogéneos, ya que fueron desarrollados con fines diferentes, utilizandodistintas plataformas, siguiendo diversos modelos de datos, estándares, sistemas de codificación yterminologías e incluso puede haber inconsistencias semántica entre ellos.

El objetivo será facilitar una vista homogénea de esta información, lo que podríamos llamar una vista“virtual” (VEHCR).

Las tres soluciones que tradicionalmente se han aportado son:

1. Centralizar la información del paciente en un único sistema o Data Warehouse. Con estasolución conseguimos un fácil acceso a los datos del paciente. Esta solución presenta, sinembargo, una serie de inconvenientes que creemos desaconsejan su uso si tiene que dar cabida aun elevado conjunto de sistemas:

- 7 -



INTRODUCCIÓN

• Hay que transmitir al nodo central la información cada vez que se haga un procesoasistencial.

• La fiabilidad del sistema depende del nodo central, si éste cae, caen todos los sistemas.

• Lo costoso que puede ser pasar a esta topología centralizada.

Son por estas razones por lo que esta solución no suele ser aceptada.

2. Utilizar una comunicación basada en mensajes. En este caso no se produce un cambio en lamanera que tiene cada sistema federado de almacenar la información. El cambio está en la manerade comunicarse con los demás. Para ello se utilizará un “idioma” común, esto es, la utilización deunos mensajes formalmente definidos.

Esta solución aporta una gran robustez ya que no hay dependencia con un nodo central. Existeorganismos de normalización que están aportando mucho en este campo como son:

HL7, Health level 7

CEN/TC251

3. Uso de una plataforma de integración o middleware que sirva de punto común a todos losagentes implicados. Esto es conseguir la integración de los sistemas de información federadoscomo la composición de servicios elementales. De esta manera cada sistema de la federaciónpublica sus prestaciones como servicios y para conseguir una vista de todos los datos relativos a unpaciente habrá que utilizar servicios de los distintos sistemas implicados. La mayor complejidad deeste sistema es lograr que el descubrimiento, uso y composición de servicios sea una tareatotalmente automatizada y transparente al usuario.

Actualmente, de estas tres soluciones se prefieren las dos últimas opciones. La segunda solución,comunicaciones basadas en mensajes, está muy desarrollada hoy en día gracias a la estandarizaciónde importantes organismos, sin embargo, a medida que el número de sistemas implicados crece lainfraestructura necesaria para el intercambio de mensajes se hace demasiado compleja y por tanto noes una solución suficientemente escalable. Es por esto por lo que se piensa que la solución en unfuturo será usando una plataforma de integración ayudándonos de tecnologías middleware como losllamados Web Services.

En resumen, podemos decir que en términos generales es mejor optar por una solución distribuida(las soluciones 2 y 3) frente a una centralizada.

Veamos las ventajas de la distribución frente a la centralización:

• Naturalidad, la información se genera de forma distribuida.

• Disminución del tráfico de la red.

• Control y responsabilidad en manos de cada sistema.

• La fiabilidad no depende de un sistema central y facilita la redundancia de la información.

Como inconvenientes:

• Dificultad de localización.

• Complejidad en la seguridad de acceso.

1.2. Solución Adoptada y ObjetivosAhora vamos a ver como afecta todo este contexto al desarrollo de un Sistema de Gestión de

Laboratorios.

Nuestro proyecto va a consistir en el diseño y desarrollo de un Sistema de Información de Gestiónde Laboratorios que pueda ser integrado en una federación.

- 8 -



INTRODUCCIÓN

Partimos de la base de que nuestro sistema tendrá su propia terminología y sistema de codificaciónpara almacenar los resultados de laboratorio. Se puede pensar que esto no es problema a la hora deinteroperar con otros sistemas ya que se podría usar por ejemplo HL7 para la comunicación. Esto noes del todo cierto ya que cada sistema tiene sus propios códigos por lo existirán problemas deinteroperabilidad a nivel semántico.

La solución más sencilla para resolver conflictos semánticos es el uso de unos identificadores ycódigos normalizados para pruebas de laboratorio, como son los códigos LOINC. LOINC (LogicalObservation Identifiers Names and Codes) es un conjunto de nombres y código universales para laidentificación de resultados de laboratorio y otras observaciones clínicas y actualmente es el estándarmás aceptado en América y Europa.

Para que nuestra solución fuera aceptada queda claro que cada sistema podrá seguir usando supropia codificación, eso sí, nuestro sistema internamente debe ser capaz de mapear dicha informaciónal código LOINC correspondiente. Esto se puede hacer con la herramienta gratuita RELMA,proporcionada por el organismo Rentrefgief.

La gestión de laboratorios generará una gran cantidad de información que iremos almacenando enuna base de datos. Esta información debe poder ser accesible desde distintas máquinas por lo quetendremos que adoptar como solución un modelo cliente servidor.

Entre las distintas opciones que se nos plantean, la mejor opción para conseguir los objetivos delproyecto es la realización de una aplicación web basada en un modelo cliente/servidor de 3 capas.Con una aplicación web lograremos grandes ventajas como es que podremos acceder a la aplicacióndesde cualquier terminal que forme parte de la red con un simple navegador ( también llamado clienteligero), y la facilidad para actualizar y mantener la aplicación ya que futuras modificaciones se haríanen el mismo servidor evitando así el gran coste que supondría distribuir e instalar las nuevas versionesdel software en todos los clientes.

La arquitectura que usaremos para nuestra aplicación web la podemos ver en la figura 1 y como yahemos dicho será un modelo cliente/servidor de 3 capas que es una configuración muy habitual paraaplicaciones accesibles desde Internet con acceso a bases de datos.

Figura 1: Modelo cliente/servidor de 3 capas

La tecnologías que usaremos son:

➢ para la parte del cliente: HTML, CSS y javascript.

➢ para la parte del servidor: JSP, Struts y jdbc.

➢ para la Base de Datos usaremos postgresql.

Este proyecto también presenta como novedad el uso del framework de Struts, lo cual permitirádesarrollar una aplicación totalmente estructurada, en la que se separará perfectamente la lógica denegocio (Modelo), la presentación (Vista) y el control de flujo de aplicaciones (Controlador).

Con el uso de Struts buscamos que nuestra aplicación sea fácilmente reutilizable, mantenible yescalable, lo cual es uno de los objetivos principales que nos planteamos a la hora de desarrollar laaplicación.

Todas las aplicaciones sufren modificaciones a lo largo de su vida, al menos todas aquellas quetienen éxito, para que estas modificaciones no se conviertan en una misión imposible es necesario que

- 9 -



INTRODUCCIÓN

la aplicación este muy bien estructurada, así tanto el programador original como uno que lo sustituyapodrá localizar de una manera mucho más rápida y segura que parte del código hay que modificar.

Un paso importante que daremos en el proyecto será trabajar con el Hospital Virgen Macarena, deesta manera nuestra aplicación podrá ser utilizada en un hospital real, aunque hay que recalcar que elestudio del negocio que realizaremos tendrá que ser, en general, válido para cualquier hospital.

El hecho de trabajar con el Hospital Virgen Macarena va a marcar nuestra aplicación en cuanto aque la presentación de las páginas va a estar adaptada a sus necesidades y a que al usar laterminología propia del hospital, se tienen que mapear los códigos de laboratorios a los términosLOINC correspondientes. También, y buscando una una mayor aceptación de nuestro sistema porparte de los usuarios del hospital Virgen Macarena, se va a tener especial cuidado en la presentaciónde la aplicación, el objetivo será que todos los informes que aparezcan por pantalla sean idénticos alos papeles que los usuarios rellenan a diario. De esta manera, la única diferencia que notarán seráque los papeles que antes tenían que rellenar a mano ahora los van a rellenar por ordenador, con laventaja añadida de que muchos datos, como por ejemplo los datos personales de la persona, secargarán automáticamente en los informes (con el ahorro de esfuerzo y tiempo que ello conlleva).

1.3. Fases del ProyectoEl proyecto se puede dividir en tres fases que son :

➢ Adquisición de conocimientos

➢ Fase de diseño

➢ Fase de desarrollo

A su vez, cada fase se ha dividido en actividades, cuyas fechas de comienzo y final podemos ver enel siguiente diagrama de Gantt.

Figura 2: Diagrama de Gantt

Aunque hayamos divido el trabajo en distintas actividades, lo cierto es que se realimentan unas conotras, así, ninguna actividad se ha podido dar por completamente terminada hasta el final del proyecto.

1.4. Estructura del documentoA continuación describiremos la estructura del documento. Dado que los contenidos del proyecto

son de diversa índole es fácil perderse, por ello trataremos de dar una visión general de lo quepretendemos comunicar y el criterio que hemos seguido para agrupar los contenidos.

- 10 -



INTRODUCCIÓN

(1) Introducción

En este bloque se hace una introducción al proyecto explicando cuál es el problema a resolver y lasolución que se ha adoptado teniendo en cuenta el estado actual del problema. También se hace unrepaso de las principales motivaciones y objetivos del proyecto.

(2) Conceptos teóricos

En este bloque se agruparán todos los conceptos teóricos usados en el proyecto. Encontraremos lossiguientes apartados:

➢ Estándares de pruebas de laboratorio:Hacemos un estudio del estándar LOINC.

➢ Arquitectura del Sistema: Explicamos la arquitectura del Sistema utilizada. Luego haremos unrepaso de las principales tecnologías que se han usado para el desarrollo de la aplicación

➢ Struts: Dada la importancia que ha tenido el uso del framework de struts para el diseño de laaplicación se le ha dedicado un apartado a explicar su funcionamiento.

(3) Realización práctica.

Este bloque tratará sobre la parte práctica realizada e incluirá los siguientes apartados:

➢ Estudio del Negocio: Haremos un estudio del negocio con el objeto de clarificar cuál es elproblema y su ámbito. Luego usaremos los diagramas de casos de uso para describir elcomportamiento del sistema y cómo interacciona con los distintos elementos del sistema.

➢ Desarrollando en Struts: Vemos mediante un ejemplo de la aplicación cual es el proceso a seguirpara desarrollar una aplicación usando Struts.

➢ Organización de los elementos en el servidor de aplicación: Vista general de cómo seorganizan los elementos en el servidor de aplicación. También se terminan de explicar distintosaspectos que no cubre struts en el diseño de los objetos de negocio.

➢ Diseño de la Base de Datos: Explicamos el diseño de la base de datos mediante distintosdiagramas a la vez que describimos las tablas que intervienen.

➢ Diseño del flujo de la aplicación: estudio de la navegabilidad del sistema.

➢ Diseño y realización de las páginas: Se mostrará cuál es el criterio seguido para diseñar laspáginas y qué tecnologías se han utilizado para escribir el código de las mismas.

(4) Conclusiones y Líneas Futuras

Terminamos haciendo un repaso de los principales aspectos del proyecto viendo si hemos cumplidolos objetivos propuestos. También enumeraremos las posibles líneas de continuación.

(5) Bibliografía

Fuentes de información que hemos tomado como referente para construcción del proyecto.

(6) Anexos

Documentación adicional. Destacar el apartado javadoc, donde podremos encontrar toda ladocumentación del código fuente java, esto es los comentarios de las clases y componentes de lasclases (variables y métodos).

- 11 -



CONCEPTOS TEÓRICOS

2. CONCEPTOS TEÓRICOS

2.1. Estándares de pruebas de laboratorio

2.1.1. LOINC

El sistema de términos LOINC (Logical Observation Identifier Names and Codes) es un conjunto denombres y códigos universales para la identificación de resultados de laboratorio y otras observacionesclínicas.

El propósito es facilitar el intercambio y la elaboración de un fondo común de resultados, tales como,hemoglobina en sangre, potasio en suero o constantes vitales, para la atención clínica, el tratamientode los resultados y la investigación.

Actualmente, la mayoría de los laboratorios y otros servicios de diagnóstico utilizan HL7 para enviarsus resultados electrónicamente desde sus sistemas de recogida de información hacia sus sistemasde atención clínica. Sin embargo, la mayoría de los laboratorios y otros servicios de diagnósticoidentifican las pruebas en estos mensajes por medio de sus valores de códigos propios. Así, el sistemade atención clínica no puede "entender completamente" y archivar correctamente los resultados quereciben a menos que o bien adopten los códigos del laboratorio (lo que es imposible si reciberesultados de fuentes múltiples), o bien inviertan en el trabajo de traducir los códigos del sistema delproductor de resultados a los códigos de su sistema interno. Los códigos de LOINC son identificadoresuniversales para el laboratorio y otras observaciones clínicas, de forma que solucionan este problema.

LOINC es un proyecto colaborativo, mantenido por el Regenstrief Institute. Es de distribución gratuitapudiéndose descargar la base de datos desde la página http://www.loinc.org [5]. La versión actual, esla 3.14 (de Diciembre del 2004) y contienen más de 34000 pruebas de laboratorios y observacionesclínicas.

Hay que citar que entre las fuentes de LOINC se incluyen el Silver Book de la IUPAC (InternationalUnion of Pure and Applied Chemistry), IFFC (International Federation of Clinical Chemistry) yEUCLIDES (European Clinical Laboratory Information Data Exchange Standard). También se habasado en ficheros de datos de 7 fuentes: Indiana University/Regenstrief, University of Utah,Association of Regional and University Pathologists (ARUP), Mayo Medical Laboratories, LDS Hospitalin Salt Lake City, the Department of Veterans Affairs, Quest Diagnostics, and University of Washington.

Podríamos resumir los objetivos de LOINC en los siguientes puntos:

• Facilitar la organización e intercambio de resultados.• Unificar la identificación de resultados.• Organización para el intercambio de mensajes por HL7, ASTM.• Sólo identificar el resultado.• Relacionarlo con Vocabularios: SNOMED (LOINC y SNOMED colaboran para conseguir una

terminología clínica consistente en la que no se produzcan ambiguedades).

De la Base de Datos que soporta LOINC, y que está disponible en su portal, la tabla que nosinteresa es la tabla LOINC, la cual está compuesta por más de 34000 registros, donde cada registroidentifica un único resultado de laboratorio u observación clínica y tiene asociado un númeroLOINC.

También se puede especificar un registro LOINC a partir de los siguientes seis campos:

1. Componente ( analito). Ejemplos: potasio, hemoglobina, creatinina.2. Propiedad medida. Ejemplos: concentración de masa, masa por gramo.3. Aspecto temporal. Muestra aislada o intervalo de tiempo.4. Tipo de muestra. Ejemplos: orina, sangre.

- 12 -



CONCEPTOS TEÓRICOS

5. Tipo de escala. Ejemplos: Cuantitativa, ordinal, nominal, etc6. Método usado para producir el resultado u otra observación ( si fuera relevante)

Con estos campos podemos formar un Nombre que detalle completamente un resultado delaboratorio u observación clínica. Este Nombre puede ser descrito formalmente siguiendo la siguientesintaxis:

<Analito/componente>:<tipo de propiedad de la observación o medición>:<aspectotemporal>:<sistema (muestra)>:<escala>:<metodo>

El carácter “:” es parte del Nombre y es usado para separar las principales partes del Nombre.

Un ejemplo de Nombre podría ser:

GLUCOSE:SCNC:PT:SER/PLAS:QN

donde GLUCOSE (glucosa) es el analito/componente que se va a medir, SCNC (concentración desubstancia) es la propiedad observada, PT (punto en el tiempo) es el aspecto temporal, SER/PLAS(suero/plasma) es la muestra sobre la que se realiza la medida y QN (cuantitativo) es el tipo de escalausada en la medida. Vemos también que al no existir el método no hará falta indicarlo.

Hay que tener en cuenta que el propósito de los códigos LOINC no es el de transmitir la máximainformación posible de un resultado u observación, sino que tiene como propósito el identificar demanera unívoca un código LOINC con un resultado u observación clínica. Así LOINC no abarca lossiguientes aspectos:

• Instrumental utilizado para la medición.

• Tipo de estudio: screening, rutina, aislado

• Quién verificó el resultado.

• El tamaño de la muestra recolectada.

• Lugar físico de toma de la muestra (habitación, guardia, laboratorio).

• Detalle fino del sitio de recolección (región antecubital).

Si se quiere comunicar esta información se deberá hacer en otros campos de los mensajesintercambiados.

A continuación vamos a describir más en profundidad cada una de las partes que compone unNombre LOINC.

2.1.1.1. Componente / Analito El componente o analito es la primera parte del Nombre:

<Analito/componente>:<propiedad observada>:<tiempo>:<sistema>:<escala>:<metodo>

Ejemplos de analitos/componentes pueden ser: glucosa, creatinina, sodio, etc.

Este campo se puede dividir a su vez en tres subpartes separados por el carácter “^”.

nombrePrincipal^challenge^ajustes

Las tres subpartes se desarrollan a su vez en la siguiente sintaxis (en cada línea mostramos unasubparte):

- 13 -



CONCEPTOS TEÓRICOS

<[analito].[subclase].[sub-subclase]> ^

<[tiempo retrasado] post [cantidad] [sustancia] [via de administración])> ^

<ajustes o corrección>

Veamos cada una de las subpartes:

(1) Nombre principal

Es el nombre del analito o de la medida y puede incluir sub-clasificaciones. Estas sub-clasificacinesestarán separadas del nombre del analito principal por el caracter punto “.”.

<[analito].[subclase].[sub-subclase]> ^

Por ejemplo el CALCIUM (calcio) es un componente en si mismo , y el nombre CALCIUM.IONIZEDes otro resultado que mide una subclase de CALCIUM.

(2) Challenge – sobrecarga o tolerancia

Da información del tiempo retrasado, sustancia utilizada, cantidad y vía de administración. Lasintaxis es la siguiente:

<[tiempo retrasado] post [cantidad] [sustancia] [via de administración])> ^

Ejemplo : GLUCOSE^1.5H POST 100 G GLUCOSE PO

En esta prueba se mediría el nivel de glucosa una hora y media después de haberse tomado unapastilla de 100 gramos de glucosa por vía oral.

(3) Ajuste

Contiene cálculos que ajustan o corrigen algún valor medido. Tiene la siguiente sintaxis:

<ajustes o corrección>

En los siguientes ejemplos podemos ver los ajustes hechos a los resultados:

CALCIUM.IONIZED^^ ADJUSTED TO PH 7.4:SCNC:PT:SER/PLAS:QN

CREATININE RENAL CLEARANCE^^NORMALIZED TO 1.72 BODY SURFACE:VRAT:24H:UR:QN

LEUKOCYTES^^CORRECTED FOR NUCLEATED ERYTHROCYTES:NCNC:PT:BLD:QN

2.1.1.2. Clase de propiedad o medición La clase de propiedad es 2ª parte del Nombre:

<Analito/componente>:<propiedad observada>:<tiempo>:<sistema>:<escala>:<metodo>

Este campo sirve para especificar la propiedad observada en la muestra, es decir, distingue entre lasdistintas clases de mediciones asociadas a una misma sustancia. Por ejemplo distinguir entre laconcentración en masa (ej. miligramos/decilitro) y la concentración de substancia (moles omiliequivalentes) de sodio en una muestra de orina.

- 14 -



CONCEPTOS TEÓRICOS

Ejemplo:

SODIUM:MCNC:24H:UR:QN

SODIUM:SCNC:24H:UR:QN

En el primer ejemplo estamos midiendo la concentración de masa (MCNC) y en el segundo medimos laconcentración de substancia (SCNC).

El tipo de propiedad es un concepto de la IUPAC y esta descrito en el “Silver Book”.

Las principales categorías de propiedades son:

• MASA (mg – g)

• SUBSTANCIA (moles – mEq)

• NÚMERO

• ACTIVIDAD CATALÍTICA (actividad enzimatica)

Subcategorias:

• CONCENTRACIÓN (mg/dl)

• CONTENIDO (mg/g)

• RAZÓN

• RANGO (mg/dia)

• FRACCIÓN (porcentajes)

En la siguiente tabla podemos ver algunas propiedades:

MCNC Mass ConcentrationSUB Substance AmountSCNC Substance ConcentrationVOL Volume

2.1.1.3. Aspecto Temporal El aspecto temporal es la 3ª parte del Nombre:

<Analito/componente>:<propiedad observada>:<tiempo>:<sistema>:<escala>:<método>

Puede ser o un punto en el tiempo o un intervalo de tiempo. Ejemplos:

ALPHA 1 ANTITRYPSIN CLEARANCE:VRAT:24H:SER/PLAS+STL:QN

HEMATOCRIT:VFR:PT:CSF:QN

2.1.1.4. Sistema (muestra) El sistema o muestra es la 4ª parte del Nombre:


Es la muestra que vamos a utilizar para la medición, por ejemplo si es sangre, orina,etc. El tipo demuestra (o Sistema) consiste en dos partes separadas por “^”:

- 15 -



CONCEPTOS TEÓRICOS

• la primera parte es el nombre del sistema,

• la segunda parte, opcional, indica el supersistema

La sintaxis es la siguiente:

muestra^supersistema

Se definen diferentes tests combinando analito y muestra. En la práctica, los laboratorios incluyenrelativamente un pequeño rango de tipos de muestra en sus pruebas. Las pruebas químicas distinguennormalmente entre suero, orina, sangre y fluido cerebroespinal. En cambio, los cultivos demicrobiología tienden a distinguir entre un mayor número de fuentes.

Ejemplos:

GLUCOSE:MCNC:PT:SER/PLAS:QN

GLUCOSE:MCNC:PT:UR:QN

En el primer ejemplo medimos el nivel de glucosa de una muestra de suero (SER/PLAS), mientrasque en el segundo ejemplo indicamos que estamos midiendo la glucosa a partir de una muestra deorina (UR).

2.1.1.5. Escala La escala es la 5ª parte del Nombre:


Especifica la escala utilizada para la medición. Las principales son:

• Cuantitativa (QN): El resultado de la prueba es un valor numérico que pertenece a una escalanumérica continua. El valor devuelto puede ser un entero, un porcentaje, un número real o unrango. Ej “+3”, “-2.4”, “>12000”.

• Ordinal (ORD): categorías fijas. Ej: 1+,2+,3+, positivo/negativo, reactivo,indeterminado,noreactivo.

• Nominal (NOM): sin ordenamiento natural :color de la orina.

• Narrativo (NAR): texto descriptivo: informe microscópico.

• Múltiples (MULTI)

Ejemplos:

• MAGNESIUM:SCNC:PT:SER/PLAS:QN:

• CANNABINOIDS:ACNC:PT:UR:ORD:SCREEN

• ESCHERICHIA COLI O157:H7 IDENTIFIED:PT:STL:NOM:ORGANISM SPECIFIC CULTURE

• HISTORY OF CHILDHOOD DISEASES: PT: ^PATIENT: NAR: REPORTED

2.1.1.6. Tipo de método El método es la 6ª parte del Nombre:

- 16 -



CONCEPTOS TEÓRICOS


Es el método en particular por el cual fue realizado el test.

Sólo es necesario indicar el método como parte del nombre cuando permite distinguir entre pruebasque miden el mismo componente (analito) pero que tienen distinto significado clínico o distintos rangosde referencia.

Ejemplos:

TREPONEMA PALLIDUM AB:ACNC:PT:SER:ORD:EIA TREPONEMA PALLIDUM AB:ACNC:PT:SER:ORD:AGGL

- 17 -



CONCEPTOS TEÓRICOS

2.2. Arquitectura del SistemaLa arquitectura que usaremos para nuestro sistema será la de una aplicación web basada en un

modelo cliente/servidor de 3 capas.

La configuración habitual para aplicaciones accesibles desde Internet con acceso a bases de datos,es la que se muestra en la figura 3. Se le denomina modelo de tres capas [18] debido a que entre elcliente, capa uno, que constituye el elemento solicitante de información y el Sistema de Gestión deBases de Datos (SGBD), capa tres, que es el elemento que contiene la información solicitada, seinserta una nueva capa que hace de interface entre las dos anteriores. Esta capa intermedia, es unservidor de aplicaciones y es quien soporta la lógica de negocio para el intercambio de informaciónentre el cliente y el SGBD.


A un lado de la red, se encuentran los clientes, que se conectan a la aplicación servidora a través delservidor web. Al otro lado del servidor web, se encuentra el Servidor de Aplicaciones que accederá alSGBD, extrayendo los datos necesarios y acordes con la consulta realizada con el cliente.

El Servidor de Aplicaciones, genera con estos datos una página HTML dinámica, que es devuelta alcliente, con la información qué éste solicitó.

En la figura 4, se muestra un esquema del proceso de intercambio de información entre losdiferentes elementos que intervienen.

Figura 4: Intercambio de información en modelo de 3 capas

- 18 -



CONCEPTOS TEÓRICOS

Con esta arquitectura conseguimos aislar la base de datos de los clientes, aumentandoconsiderablemente la seguridad de las aplicaciones, así como liberar al usuario de tener que descargare instalar los drivers de acceso al SGBD en su máquina.

Al tratarse de una aplicación web la capa intermedia puede escribirse de una manera cómoda yeficiente usando servlets.

Para la comunicación entre la aplicación servidora y la base de datos usaremos JDBC (JavaDatabase Connectivity), que es una API de Java.

A continuación daremos una pequeña introducción a las distintas tecnologías que usaremos paraaclarar la funcionalidad de cada una.

2.2.1. Tecnologías en la parte del cliente

2.2.1.1. Html HTML ( Hypertext Markup Language) es el lenguaje estándar utilizado en la Web para representar la

información intercambiada por sus usuarios en forma de documentos de hipertexto [1].

Podríamos definir este lenguaje como un documento ASCII con una serie de etiquetas que indican alnavegador cómo interpretar y dar formato al texto que las acompaña.

En teoría podríamos crear documentos en cualquier formato, y utilizar tanto el protocolo HTTP paramoverlo por la red como los URL para localizarlos. ¿Por qué utilizar entonces documentosformateados en lenguaje HTML? La razón es simple: HTML es un estándar y otros formatos no. Estoquiere decir que cualquier navegador o browser que use las normas estándar de visualización dedocumentos Web podrá leer e interpretar perfectamente el HTML, pero no tendrá por qué interpretar,por poner algún ejemplo, documentos en formato Word Perfect, Word, Excel...

Algunos de los navegadores más extendidos del mercado son Internet Explorer, Netscape, Mozilla,Opera, Konqueror, etc.

2.2.1.2. CSS Una hoja de estilo es un conjunto de reglas que se aplican a una o más etiquetas HTML y definen

qué apariencia tendrá el contenido de esa hoja al enviarla a pantalla, al imprimirla, o con cualquierdispositivo que se use para ver una página web. El lenguaje y reglas de CSS (Cascading Style Sheet.Hojas de Estilo en Cascada.) hacen este trabajo de forma muy simple y clara, facilitando (y mucho) latarea de diseñar páginas web atractivas y vistosas.

Normalmente en una aplicación Web muchas páginas tienen el mismo aspecto. Si hacemos queestas páginas recojan sus estilos de un mismo fichero, podremos cambiar el aspecto de todas ellas ala vez sin más que modificar el fichero que contiene estos estilos.

Una misma página puede tener varias hojas de estilo, si los diseñadores así lo consideran oportuno.

2.2.1.3. Javascript JavaScript es un lenguaje de programación desarrollado por Netscape Corporation para su

navegador Netscape Navigator 2.0, y que permite la ejecución de código dentro de las páginas enHTML. Microsoft posee su propia versión para su navegador Internet Explorer, llamada JScript, peroque, salvo en algunos detalles que generalmente no son demasiado importantes, resulta compatiblecon los navegadores de Netscape. Gracias a estos programas (llamados guiones) escritos enJavascript y que son añadidos en las páginas HTML, se pueden conseguir interesantes efectos en laspáginas web, comprobar la validez de las entradas de los formularios, abrir y cerrar ventanas, cambiardinámicamente el aspecto y los contenidos de una página, realizar cálculos matemáticos sencillos, etc.

Se trata de un lenguaje interpretado por el navegador del usuario que carga la página web (nocompilado). Es un lenguaje orientado a objetos pero con una serie de limitaciones para prevenir que sealtere el sistema ficheros del cliente ( no puede leer, escribir, crear, borrar o listar ficheros a no ser que

- 19 -



CONCEPTOS TEÓRICOS

sean cookies). Carece además de primitivas de red, de manera que no puede establecer conexióndirecta con otras máquinas (excepto enviar correo).

2.2.2. Tecnologías en la parte del servidor

2.2.2.1. JSP

JSP (Java Server Page) es una tecnología de la parte del servidor para crear páginas Webdinámicas.

En una página JSP podemos encontrar partes estáticas escritas en HTML intercaladas con partesdinámicas generadas con programas escritos en java. El código java está encerrado entre unasetiquetas especiales por lo que conseguimos separar claramente la parte de presentación de la partede procesamiento de información, por lo que nos resultará más fácil de crear y mantener.

Cuando una página JSP es invocada, el servidor de aplicaciones se encargará de compilarla ytransformarla a un Servlet, así, mientras la página JSP no cambie, el servidor de aplicaciones seguiráusando la última versión ya compilada.

JSP se puede ver como una capa que se coloca encima de JavaServlet que nos facilita el trabajocon los Servlets.

La gran innovación de las páginas JPS es la codificación dentro de la propia página, así cuando unapágina es invocada, se ejecutará el código contenido, y la información devuelta al cliente es HTMLpuro generado en el momento de la consulta.

JSP es fácilmente extensible a través de Taglibs. Los Taglibs son una serie etiquetas queencapsulan una cierta funcionalidad (implementadas mediante una clase java) lo que nos ahorrarátiempo a la vez que se consigue un código más legible.

En nuestro proyecto nos hemos aprovechado de esta característica de JSP y trabajaremos con unaserie de librería Taglibs proporcionadas por Struts.

2.2.2.2. Struts Struts es un framework para el desarrollo de aplicaciones web basadas en java que implementa el

modelo MVC-2. Dada la importancia de uso en el diseño y desarrollo de la aplicación web se le hadedicado su propio apartado (capitulo 2.3) donde se detallará en profundidad su funcionamiento.

2.2.2.3. JDBC Prácticamente todas las aplicaciones almacenan, recuperan y manipulan información almacenada

en una base de datos.

Existen en el mercado muchos gestores de bases de datos (DBMS) comerciales. Éstos incluyen aOracle, DB2, SyBase, PostgreSQL, MySql y muchas otras marcas populares. El desafío queenfrentaba Sun Microsystems a finales de la década de los noventa era desarrollar alguna forma deque los desarrolladores Java pudieran escribir código de alto nivel que pudiera tener acceso a todoslos DBMS populares.

Uno de los obstáculos principales que tuvo que vencer Sun Microsystems fue la barrera del lenguaje.Cada DBMS utilizaba su propia forma de bajo nivel de interactuar con los programas para obteneracceso a los datos almacenados en sus base de datos. Esto significaba, por ejemplo, queprobablemente sería necesario reescribir el código de bajo nivel escrito para comunicarse con unabase de datos Oracle si se necesitara tener acceso a una base de datos DB2.

La forma en que Sun Microsystems enfrentó el reto en 1996 fue con la creación de los controladoresdel JDK y la API JDBC. Ambos se crearon por necesidad, ya que hasta entonces no se consideraba aJava como un lenguaje para aplicaciones de negocios, debido a que no podía tener acceso a DBMS.

- 20 -



CONCEPTOS TEÓRICOS

El controlador JDBC que desarrolló Sun Microsystems no era de hecho un controlador. En vez deello era una especificación que indicaba en detalle la funcionalidad de un controlador JDBC. Se animóa los fabricantes de DBMS y a terceros a crear controladores JDBC que se ajustaran a lasespecificaciones de Sun Microsystems. Aquellas empresas que construyeran controladores JDBC parasus productos podrían aprovechar el creciente mercado de aplicaciones Java.

La especificación indica que un controlador JDBC es un traductor que convierte los mensajespropietarios de bajo nivel del DBMS a mensajes de bajo nivel compresibles a la API JDBC y viceversa.

El significado de esto es que los programadores Java pueden utilizar objetos Java de alto niveldefinidos en la API JDBC para escribir código que interactúa con el DBMS. Los objetos Javaconvierten el código en mensajes de bajo nivel que se ajustan a la especificación del controlador JDBCy los envían a este último. El controlador JDBC traduce los mensaje en mensajes de bajo nivel que elDBMS comprende y procesa.

2.2.3. Servidor de aplicación

2.2.3.1. Tomcat El proyecto Jakarta, patrocinado por la Apache Software Foundation, crea y mantiene soluciones de

código abierto basadas en Java, uno de sus desarrollos es Tomcat [14][15].

Tomcat funciona como un contenedor de servlets siendo la implementación oficial de referencia delas especificaciones Servlet 2.3 y JavaServer Pages 1.2. (JSP) de Sun Microsystems. Tomcat seconsidera por tanto un servidor de aplicaciones.

El concepto de Aplicación Web fue introducido en la versión 2.2 de la especificación servlet, y vienea decir que una aplicación web es una colección de servlets, páginas JSP, clases Java, archivos dedescripción de la aplicación, documentos estáticos: HTML, XHTML, imágenes, etc. y otros recursosque pueden ser empaquetados y ejecutados en distintos servidores de diferentes proveedores. Esdecir, una aplicación web se podría definir como la capa web de cualquier aplicación.

Una aplicación Web está definida como una organización de archivos y directorios en un ordenpreestablecido. Esta organización de archivos puede ser accedida en su forma "natural" donde cadadirectorio y archivo existe en forma separada, o en su forma "comprimida" (WAR) donde toda laorganización está comprimida en un solo archivo. La forma "natural" es preferida durante el desarrollode una aplicación, mientras que la forma comprimida se prefiere para distribuir una versión final a losdistintos servidores.

La especificación Servlet 2.2 define la estructura de directorios para los ficheros de una aplicaciónWeb. El directorio superior -- o directorio raíz -- debería tener el nombre de la aplicación y definirá laraíz de documentos para nuestra aplicación Web. Todos los ficheros debajo de esta raíz puedenservirse al cliente excepto aquellos ficheros que están bajo los directorios especiales META-INF yWEB-INF en el directorio raíz. Todos los ficheros privados – como las clases que se corresponden conlos servlets -- deberían almacenarse bajo el directorio WEB-INF.

Veamos donde se alojan los distintos ficheros en la estructura de directorios de una aplicación web:

• *html, *jsp, etc: Van en el directorio raíz de la aplicación. Se pueden crear directorios quecontengan más de estos archivos.

• /WEB-INF/web.xml: Es el "Web Application Deployment Descriptor". Es un archivo XML quedescribe los servlets y otros componentes que componen la aplicación, además de parámetrosde inicialización y de ámbito que se requieran.

• /WEB-INF/classes/: Este directorio contiene los archivos *class de java de las clases que seanrequeridas por la aplicación, incluyendo los servlets.

• /WEB-INF/lib/: En este directorio están los archivos JAR (Java Archive) que contienen lasclases comprimidas que podrán ser utilizadas por la aplicación. Como por ejemplo bibliotecasde desarrolladores externos o drivers de conexión a bases de datos.

La versión de Tomcat que vamos a usar para nuestro proyecto es la 5.5. y se podrá descargar sincoste alguno desde la página http://jakarta.apache.org/tomcat/ [14]. Una vez descomprimida ladistribución binaria de Tomcat tendremos la siguiente estructura de directorios:

- 21 -



CONCEPTOS TEÓRICOS

Nombre deDirectorio Descripción

bin Contiene los scripts de arrancar/parar el servidor Tomcat

confContiene varios ficheros de configuración incluyendo server.xml (el

fichero de configuración principal de Tomcat) y web.xml que configura losvalores por defecto para las distintas aplicaciones desplegadas en Tomcat.

doc Contiene documentación sobre Tomcat

lib Contiene varios ficheros jar que son utilizados por Tomcat. Sobre UNIX,cualquier fichero de este directorio se añade al classpath de Tomcat.

logs Aquí es donde Tomcat sitúa los ficheros de diario.src Los ficheros fuentes del API Servlet.

webapps Contiene aplicaciones Web de Ejemplo. Aquí se meten los wars quedesplegará tomcat

Adicionalmente podemos, o Tomcat creará, los siguientes directorios:

Nombre deDirectorio Descripción

workGenerado automáticamente por Tomcat, éste es el sitio donde Tomcat sitúa

los ficheros intermedios (como las páginas JSP compiladas) durante sutrabajo. Si borramos este directorio mientras se está ejecutando Tomcat nopodremos ejecutar páginas JSP.

classesPodemos crear este directorio para añadir clases adicionales al classpath.

Cualquier clase que añadamos a este directorio encontrará un lugar en elclasspath de Tomcat.

Los pasos a seguir para desplegar el war de nuestra aplicación son muy sencillos, basta con copiarel war al directorio webapps y arrancar tomcat.

2.2.4. Base de Datos

2.2.4.1. Postgresql El Sistema Gestor de Bases de Datos Relacionales Orientadas a Objetos conocido como

PostgreSQL está derivado del paquete Postgres escrito en Berkeley [16]. Se podría decir quePostgreSQL es el gestor de bases de datos de código abierto más avanzado hoy en día, ofreciendocontrol de concurrencia multi-versión, soportando casi toda la sintaxis SQL (incluyendo subconsulta,transacciones, y tipos y funciones definidas por el usuario), contando también con un amplio conjuntode enlaces con lenguajes de programación (incluyendo C, C++, Java, perl, tcl y python).

Para el actual proyecto usaremos la versión 8.0 de PostgreSql. PostgreSQL proporciona un grannúmero de características que normalmente sólo se encontraban en las bases de datos comercialestales como DB2 u Oracle. La siguiente es una breve lista de algunas de esas características, a partirde PostgreSQL 7.1.x [17]:

➢ DBMS Objeto-Relacional

PostgreSQL aproxima los datos a un modelo objeto-relacional, y es capaz de manejar complejasrutinas y reglas. Ejemplos de su avanzada funcionalidad son consultas SQL declarativas, control deconcurrencia multi-versión, soporte multi-usuario, transactions, optimización de consultas, herencia, yarrays.

➢ Altamente_Extensible

PostgreSQL soporta operadores, funcionales métodos de acceso y tipos de datos definidos por elusuario.

➢ Soporte_SQL_Comprensivo

- 22 -



CONCEPTOS TEÓRICOS

PostgreSQL soporta la especificación SQL99 e incluye características avanzadas tales como lasuniones (joins) SQL92.

➢ Integridad Referencial

PostgreSQL soporta integridad referencial, la cual es utilizada para garantizar la validez de los datosde la base de datos.

➢ API Flexible

La flexibilidad del API de PostgreSQL ha permitido a los vendedores proporcionar soporte aldesarrollo para el RDBMS PostgreSQL. Estas interfacaes incluyen Object Pascal, Python, Perl, PHP,ODBC, Java/JDBC, Ruby, TCL, C/C++, y Pike.

➢ Lenguajes de Procedimientos

PostgreSQL tiene soporte para lenguajes de procedimientos, incluyendo un lenguaje nativodenominado PL/pgSQL. Este lenguaje es comparable al lenguaje de procedimientos de Oracle,PL/SQL. PostgreSQL también puede usar Perl, Python, o TCL como lenguajes de procedimientos.

➢ MVCC

MVCC, o Control de Concurrencia Multi-Versión (Multi-Version Concurrency Control), es latecnología que PostgreSQL usa para evitar bloqueos innecesarios. Si alguna vez ha usado algúnDBMS con capacidades SQL, tal como MySQL o Access, probablemente habrá notado que hayocasiones en las que una lectura tiene que esperar para acceder a información de la base de datos. Laespera está provocada por usuarios que están escribiendo en la base de datos. Resumiendo, el lectorestá bloqueado por los escritores que están actualizando registros.

Mediante el uso de MVCC, PostgreSQL evita este problema por completo. MVCC está consideradomejor que el bloqueo a nivel de fila porque un lector nunca es bloqueado por un escritor. En su lugar,PostgreSQL mantiene una ruta a todas las transacciones realizadas por los usuarios de la base dedatos. PostgreSQL es capaz entonces de manejar los registros sin necesidad de que los usuariostengan que esperar a que los registros estén disponibles.

➢ Cliente/Servidor

PostgreSQL usa una arquitectura proceso-por-usuario cliente/servidor. Esta es similar al método delApache 1.3.x para manejar procesos. Hay un proceso maestro que se ramifica para proporcionarconexiones adicionales para cada cliente que intente conectar a PostgreSQL.

➢ Write Ahead Logging (WAL)

La característica de PostgreSQL conocida como Write Ahead Logging incrementa la dependencia dela base de datos al registro de cambios antes de que éstos sean escritos en la base de datos. Estogarantiza que en el hipotético caso de que la base de datos se caiga, existirá un registro de lastransacciones a partir del cual podremos restaurar la base de datos. Esto puede ser enormementebeneficioso en el caso de caída, ya que cualesquiera cambios que no fueron escritos en la base dedatos pueden ser recuperados usando el dato que fue previamente registrado. Una vez el sistema haquedado restaurado, un usuario puede continuar trabajando desde el punto en que lo dejó cuandocayó la base de datos.

- 23 -



CONCEPTOS TEÓRICOS

2.3. Struts

2.3.1. Introducción Struts es un subproyecto de Jakarta [9] (http://struts.apache.org/). El propósito de Struts es crear un

framework OpenSource para desarrollar aplicaciones web basadas en java según el patrónarquitectónico MVC-2 (una variación del clásico modelo de diseño Modelo-Vista-Controlador).

Framework es un término usado en programación orientada a objetos para definir un conjunto declases que definen un diseño abstracto para solucionar un conjunto de problemas relacionados.

El núcleo del Framework de Struts es una flexible capa de control basada en tecnologías estandarscomo Java Servlets, jsp, javaBeans, ResourceBundles y XML así como varios paquetes “commons” deJakarta.

En el ámbito del desarrollo web se siguen unas pautas que tratan más o menos de conseguir undesarrollo estructurado de las aplicaciones, donde la verificación de sesión se centraliza y cada casode uso se distingue claramente. Utilizando Struts ese “más o menos” se convierte en una arquitecturacompletamente estructurada que divide perfectamente lógica de negocio (Modelo), presentación(Vista) y control de flujo de aplicaciones(Controlador). En muchos desarrollos web se diseñaconsciente o inconscientemente siguiendo este patrón, por tanto la adopción del modelo Struts nodebería suponer un quebradero de cabeza.

Además hay que tener en cuenta que Struts nos da parte del trabajo hecho, funciona correctamente,y nos da ciertos extras. Teniendo en cuenta además las aportaciones de grupos de desarrollo (taglibsnuevos, etc..), la adopción de esta plataforma puede resultar muy interesante.

Parte del éxito de Struts se debe a que evita un hecho que se repite con bastante frecuencia y esque el desarrollo de las aplicaciones web resulta ser un caos y que además cada grupo de desarrollolo hace a su manera. Struts le está comiendo terreno a los EJB y está consiguiendo que los desarrollossigan unas pautas estándar, lo que facilita que, en el cambiante mundo de la ingeniería informáticadonde impera el movimiento de recursos humanos, el mantenimiento y mejora de una aplicación websea más llevadero.

2.3.2. MVC: Modelo Vista Controlador MVC o Modelo Vista Controlador es un patrón de diseño aportado originariamente por el lenguaje

SmallTalk a la Ingeniería del Software. El paradigma MVC consiste en dividir las aplicaciones en trespartes:

• Controlador.

• Modelo.

• Vistas.

El controlador es el encargado de redirigir o asignar una aplicación (un modelo) a cada petición; elcontrolador debe poseer de algún modo, un "mapa" de correspondencias entre peticiones y respuestas(aplicaciones o modelo) que se les asignan.

El modelo sería la aplicación que responde a una petición, es la lógica de negocio a fin de cuentas.

Una vez realizadas las operaciones necesarias el flujo vuelve al controlador y este devuelve losresultados a una vista asignada.

Yéndonos al esquema más básico de programa, tenemos una entrada o parámetros que llegan(INPUT), se procesan y se muestra el resultado (OUTPUT).

- 24 -



CONCEPTOS TEÓRICOS

figura 5: MVC, Modelo Vista Controlador

En el caso del patrón MVC el procesamiento se lleva a cabo entre sus tres componentes. Elcontrolador recibe una orden y decide quién la lleva a cabo en el modelo. Una vez que el modelo (lalógica de negocio) termina sus operaciones devuelve el flujo vuelve al controlador y éste envía elresultado a la capa de presentación.

El Controlador en cierta forma debe tener un registro de la relación entre órdenes que le puedenllegar y la lógica de negocio que le corresponde (Es como una operadora de teléfono que recibe unapetición y une dos lineas). En el siguiente gráfico se representa ese funcionamiento:

figura 6: Mapa de Direcciones del Controlador

¿Que ventajas obtenemos de este modelo? Obviamente una separación total entre lógica denegocio y presentación. A esto se le pueden aplicar opciones como el multilenguaje, distintos diseñosde presentación,... etc, sin alterar la lógica de negocio. La separación de capas como presentación,lógica de negocio y acceso a datos, es fundamental para el desarrollo de arquitecturas consistentes,reutilizables y más fácilmente mantenibles, lo que al final resulta en un ahorro de tiempo en desarrollode posteriores proyectos.

2.3.2.1. MVC-2 Struts utiliza el patrón de diseño MVC-2 que es una variante del Modelo-Vista Controlador.

En MVC-2. se combinan el uso de servlets y JSP para servir el contenido dinámico de las páginas:

➢ Utiliza JSP para generar el nivel de presentación y los servlets para realizar tareas intensivas deprocesamiento.

- 25 -



CONCEPTOS TEÓRICOS

➢ El sevlet actúa como controlador y se encarga de procesar la petición y la creación de cualquierBean u objeto utilizado por JSP, al igual que decidir, dependiendo de las acciones del usuario, aqué página JSP enviar la petición.

Otra característica es que no hay lógica de procesamiento en la página JSP en sí misma; éstasimplemente es responsable de recuperar cualquier objeto o beans que pueda haber sido creadopreviamente por el servlet, y extraer el contenido dinámico desde el sevlet para su inserción enplantillas estáticas.

Este enfoque resulta en una separación más limpia de la presentación y el contenido, llevando a unaclara separación de responsabilidades de los desarrolladores y diseñadores de páginas.

figura 7: Arquitectura para aplicación Web Modelo 2

2.3.3. Diseño de Struts Vamos a ver ahora como nos ayuda el framework de Struts a implementar este patrón de diseño

MVC-2. En concreto, el framework de Struts nos dará soporte para implementar las capas controladory vista de una aplicación web.

En la figura 8 se representan el conjunto de clases que nos ofrece el framework de Struts así comosus dependencias:

- 26 -



CONCEPTOS TEÓRICOS

figura 8: Framework de Struts

Pero ¿cómo encajan estas clases en el patrón de diseño Modelo-Vista-Controlador?:

➢ Controlador central:

• El controlador central es la clase ActionServlet, todos los caminos pasan por él.

• Tienen un registro con las peticiones que le pueden llegar y la lógica de negocio que lecorresponde.

• Es configurable mediante el fichero XML struts-config.xml

➢ Modelo:

➢ Modelo = ActionForm + Actions + Objetos de negocio

➢ ActionForms: Mantienen los datos de los formulario para cada página JSP. También poseeun método para validar los datos del formulario cuando éstos son enviados.

➢ Objetos de Negocio: Entidades que representan los conceptos del negocio, suscaracterísticas y comportamiento.

➢ Vista:

• JSP , etiquetas TagLib, plantillas Velocity, XSL o cualquier otra tecnología que pueda serutilizada vía Java servlet

- 27 -



CONCEPTOS TEÓRICOS

figura 9: MVC-2 en Struts

Con lo visto hasta ahora nos podemos hacer una idea de cómo va a funcionar struts y qué ventajasnos va a aportar en el desarrollo y posterior mantenimiento de nuestra aplicación.

A continuación vamos a adentrarnos un poco más al mundo de struts viendo más en detalle laprincipales clases de las que está compuesta [10] ( http://struts.apache.org/api/ ). Estas son:

• ActionServlet

• ActionForm

• Action

También veremos como se implementa el fichero de configuración de struts, llamado strus-config.xml.

2.3.3.1. ActionServlet El ActionServlet es el controlador que determina a qué acción llamar en función del evento HTTP

que ocurra. Se encarga de:

➢ Procesar la peticiones del usuario, transformando los parámetro de la petición (request) enActionForm

➢ determinar lo que el usuario está intentando conseguir de acuerdo a la petición,

➢ sacar los datos del modelo (si es necesario) para entregárselos a la vista adecuada, y

➢ seleccionar la vista adecuada para responder al usuario

Esta clase ya se encuentra implementada en el framework de Struts y extiende a la clasejavax.servlet.http.HttpServlet.

En web.xml se especifica que todas la URLs que impliquen procesamiento (por GET o POST) vayana este servlet. También es muy típico configurar el fichero web.xml para aceptar un patrón de URL talcomo *.do

El ActionServlet consulta un fichero de gran importancia en Struts al que le dedicaremos un apartadomás adelante, este fichero es struts-config.xml y en él se determinan la relaciones entre todos loscomponentes del framework.

- 28 -



CONCEPTOS TEÓRICOS

2.3.3.2. ActionForm Dado que en una aplicación web existirán una serie de formularios, Struts nos ofrecerá una clase

que nos facilitará la recuperación e inserción de los valores en los formularios. Esta clase se llamaActionForm y es un javaBean. Un ActionForm está compuesto por:

➢ Un conjunto de parámetros de tipo String. Por cada campo de entrada que tengamos en elformulario tendremos un parámetro con el mismo nombre en el ActionForm.

➢ Métodos get/set públicos para cada campo de entrada del formulario.

➢ Un método validate() para validar los datos de entrada del usuario en el formulario. Este métodopuede devolver una lista de errores.

➢ Un método reset() opcional para reinicializar todas las propiedades a sus valores por defecto.

Cuando rellenamos un formulario y enviamos una petición al servidor ,esta petición es procesadapor el ActionServlet el cual se encargará de instanciar el ActionForm asociado al formulario antes deinvocar al método Action.execute().

La relación entre un formulario, su ActionForm asociado, y la clase Action que ejecutará la lógica denegocio viene detallado en el archivo de configuración struts-config.xml.

2.3.3.3. Action Las acciones se representan mediante una clase que extiende a la clase

org.apache.struts.action.Action.

Será el encargado de llamar a la lógica de negocio. Para ello tendremos que reescribir el métodoexecute(ActionMapping mapping, ActionForm form, javax.servlet.ServletRequest request,javax.servlet.ServletResponse response)

➢ ActionMapping indica el mapeo de esta instancia, es decir, los posibles valores de retorno delActionFoward según esté definido en struts-config.xml.

➢ ActionForm es el bean asociado al formulario (es nulo si no se ha definido un ActionForm en struts-config.xml).

➢ Procesa la petición HTTP especificada y genera su correspondiente respuesta HTTP.

➢ El método devuelve una instancia ActionFoward que describe a dónde y cómo se redirige el control.

Para redirigir a otra página se utiliza el método :

return mapping.findFoward(“nombreLogico”);

El enlace físico asociado al URI lógico se encuentra mapeado en el fichero struts-config.xml.

2.3.3.4. struts- config.xml struts-config.xml es el fichero XML de configuración de Struts y se coloca dentro de la carpeta WEB-

INF.

En él se especifican todas las relaciones entre acciones y clases, formularios y clases, acciones yJSPs de presentación, que globalmente conforman el “mapa” de la aplicación.

Veamos el esquema general que sigue el fichero struts-config.xml:

- 29 -



CONCEPTOS TEÓRICOS

<?xml version = '1.0' encoding = 'windows-1252'?>

<!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration1.1//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>

<form-beans> ... </form-beans>

<global-forwards> ... </global-forwards>

<action-mappings> .. </action-mappings>

<message-resources .../>

</struts-config>

El fichero de configuración, struts-config.xml, usado en nuestra aplicación de Sistema de Gestión deLaboratorios se puede consultar en el capítulo de anexos (en la página 131).

A continuación veremos para qué sirven y qué contienen cada una de las etiquetas que forman elarchivo struts-config.xml.

I struts-config.xml: Form Beans

Sirve para indicar al ActionServlet cuáles son los nombres de los form beans y las clases Javaasociadas (que extienden la clase ActionForm).

<form-beans><form-bean name=”nombre del form bean” type=”nombre de la clase Java”/><form-bean ... />...

</form-beans>

Para acceder a alguna propiedad del formulario en alguna clase se utiliza el método form.get(“nombrePropiedad”)

II struts-config.xml: Fowards

Asocia a cada enlace físico (pagina JSP) una URI lógica. Se define con el elemento <foward>

<forward name="nombreLogico" path="/enlaceFisico"/>

• El atributo name indicará el nombre lógico, que será invocado por el método findForward().

• El atributo path indicará el nombre del fichero que se debe mostrar

Los fowards pueden ser de dos tipos:

➢ Globales: con ámbito en toda la aplicación, si el recurso se puede invocar desde diferentes puntos.Se especifica en <global-forwards>

- 30 -



CONCEPTOS TEÓRICOS

<global-forwards>

<forward name="nombreLogico" path="/enlaceFisico"/>

...

</global-forwards>

➢ Locales: con ámbito en una acción. Se especifica con <action-mappings>

<action-mappings >

<action ...>

<forward name="nombreLogico" path="/usuarioPassword.jsp"/>

...

</action ...>

</action-mappings >

Esta relación entre el nombre lógico y el recurso (pagina JSP) correspondiente nos facilitará elmantenimiento de la aplicación web ya que :

➢ se puede cambiar el nombre del recurso sin cambiar las referencias en la aplicación

➢ En el código java no tendremos que indicar el nombre del fichero cuando redirija a otra página,utilizaremos el método mapping.findForward(“nombreLogico”);

III struts-config.xml: Action Mappings

Los action mappings se utilizan para ligar un nombre de formulario a un Action. Se definen elelemento <action-mappings>

Cada formulario tiene asociado un ActionForm.

Todo esto se configura en struts-config.xml con la etiqueta <action ...>

<action path="/saveUsuarioPassword"

type="PruebasDeLaboratorio.struts.action.SaveUsuarioPasswordAction"

name="usuarioPasswordForm"

scope="request">

input="/usuarioPassword.jsp"

validate="false"

<forward ... />

</action>

Veamos para que sirve cada atributo:

- 31 -



CONCEPTOS TEÓRICOS

• path: nombre que debe especificarse en la url para acceder. Normalmente se debe llamarseguido de .do, así para nuestro ejemplo accederíamos por la url”/saveUsuarioPassword.do")

• type: la clase asociada a la acción, con la ruta del paquete si la tiene. Es la clase Action a laque el ActionServlet llama Cuando recibe el evento HTTP.

• name: nombre del form bean asociado a la acción ( si lo hay)

• scope: ámbito de validez de ese formulario (del form bean), puede ser request o session ysolo se pone si se ha especificado el atributo name.

• input: página que se mostrará si hay errores de validación.

• validate: si se va a validar el formulario o no. Por defecto es true e invocará al métodovalidate() del form bean.

Podemos ver también que los action pueden tener elementos <forward ...> para indicar cuales sonlas páginas de resultados (forward locales).

2.3.4. Internacionalización La explosión del desarrollo de aplicaciones basadas en tecnologías Web, así como el despliegue de

dichas aplicaciones sobre Internet y otras redes accesibles, han hecho que los límites nacionales seaninvisibles en muchos casos. Esto se ha traducido en la necesidad de que las aplicaciones soporten lainternacionalización.

En Struts, todos los mensajes o textos estáticos se deberían de especificar en un fichero de texto.Este fichero de texto, al que en nuestra aplicación hemos llamado ApplicationResources.properties ,debe estar en el directorio donde se encuentren las clases de la aplicación. El formato para definirmensajes en el fichero es:

• clave.subclave=texto

Por ejemplo:

error.usuarioPassword.usuario.vacio= Por favor, rellene el campo usuario.

Para cada idioma alternativo se creará un archivo nuevo que se llame igual pero que termine en“_xx.properties”, siendo xx el código ISO del idioma (Ej: ApplicationResources_en.properties).

Con esto conseguimos separar el código de la información, lo que facilita el mantenimiento y latraducción a otros idiomas.

El nombre de este fichero de texto se configura en struts-config.xml de la siguiente manera:

<message-resources parameter="PruebasDeLaboratorio.struts.ApplicationResources"/>

2.3.5. Vista La presentación en Struts se hace utilizando páginas JSP o HTML (aunque se pueden usar otras

tecnologías).

Para facilitarnos la tarea de insertar formularios y otros elementos en las páginas, Struts proporcionauna serie de librerías de tags de Struts [11](http://struts.apache.org/userGuide/struts-html.html).

Los Taglibs son una serie etiquetas que encapsulan una cierta funcionalidad (implementadasmediante una clase java) lo que nos ahorrará tiempo a la vez que se consigue un código más legible.

Los taglibs definidos por Struts son los siguientes :

- 32 -



CONCEPTOS TEÓRICOS

➢ Struts HTML: Este taglib contiene etiquetas útiles en la creación de interfaces de usuarios basadaen HTML.

➢ Struts Bean: Este taglib contiene etiquetas útiles para acceder a los bean y sus propiedades.También permite acceder a los mensajes definidos en el fichero de mensajes.

➢ Struts Logic: Este taglib contiene etiquetas que son útiles en la gestión de la generacióncondicional de texto de salida y bucles sobre colecciones de objetos para la generación repetitivade texto de salida.

➢ Struts Nested: Este taglib permite trabajar con contexto anidados (por ejemplo, un bean quecontiene una referencia a otro bean).

➢ Struts Tiles: Este taglib proporciona etiquetas tiles. Los tiles permiten crear páginas compuestaspor diferentes partes (similar a los includes de JSP, pero más potente)

- 33 -



REALIZACIÓN PRÁCTICA

3. REALIZACIÓN PRÁCTICA

3.1. Estudio del NegocioLa motivación para el desarrollo de cualquier sistema de información es la de dar una solución a un

problema. El estudio del negocio tienen por objeto clarificar cuál es el problema y su ámbito.

Es impensable comenzar a desarrollar software sin tener antes claro qué es lo que se quiere hacer;la calidad y el coste del desarrollo del sistema de información se resentirá si no están apoyados sobreun buen estudio del negocio.

Nuestro proyecto va a consistir en realizar un Sistema de Gestión de Laboratorios para ser utilizadoen el ámbito de un hospital.

El hospital tendrá su propia codificación y terminología. Se puede pensar que esto no es problema ala hora de interoperar con otros sistemas ya que se podría usar por ejemplo HL7 para la comunicación.Esto no es del todo cierto ya que cada sistema tendrá sus propios códigos, por lo que no pueden"entenderse completamente" ,pueden existir problemas de interoperabilidad a nivel semántico.

La solución más sencilla para resolver conflictos semánticos es el uso de unos identificadores ycódigos normalizados para la pruebas de laboratorio, como son los códigos de LOINC (LogicalObservation Identifiers Names and Codes). Por ello nuestro sistema será capaz de mapear dichainformación al código LOINC correspondiente

Un primer problema a la hora de realizar un Sistema de Gestión de Laboratorios es la gran cantidadde pruebas de laboratorios que existen, así, el sistema de términos LOINC tiene hasta más de 34000resultados de laboratorios distintos.

En un principio ideamos para nuestra aplicación un sistema de organización jerárquico quepermitiera al usuario acceder a la totalidad de las pruebas de laboratorio. Un estudio más realista hizoque desecháramos esta idea ya que un laboratorio debe realizar una gran cantidad de pruebasdiariamente y supondría una gran pérdida de tiempo, a la vez que un esfuerzo mental constante porparte de los usuarios, el tener que buscar los resultados en un sistema jerárquico por muy bienorganizado que éste estuviera.

La realidad es que, a pesar de la gran cantidad de pruebas que realizan los laboratorios, éstas casisiempre son las mismas, de hecho sólo suelen realizar entre entre 200 y 300 pruebas distintas. Por ellopensamos que lo útil sería que nuestra aplicación permitiera acceder a éstas pruebas de manerainmediata y no desbordar la aplicación con la posibilidad de poder elegir entre más de 34000 términos.

Luego se empezó a estudiar el funcionamiento del hospital distinguiendo tres actores principales:médicos, enfermeros y técnicos de laboratorio. Cada actor tiene su propio papel e interactúa demanera distinta en el sistema. Su estudio se ha realizado en el apartado 3.1.1 mediante los diagramasde Casos de Uso y aquí es donde se centra el estudio del negocio.

Otro paso importante que se dio fue empezar a trabajar con el hospital Virgen Macarena, ya quequeríamos que la aplicación pudiera ser utilizada en un hospital real, aunque hay que recalcar que elestudio del negocio realizado en el apartado 3.1.1 es válido para cualquier hospital.

El hecho de trabajar con el hospital Virgen Macarena va a marcar nuestra aplicación en cuanto a quela presentación de las páginas va a estar adaptada a las necesidades del hospital y que al usar laterminología propia del hospital, se tienen que mapear los códigos de laboratorios a los términosLOINC correspondientes.

Buscando como objetivo una mayor aceptación del sistema por parte de los usuarios, se ha tenidoun especial cuidado en la presentación de la aplicación, así todos los informes que aparecen porpantalla serán idénticos a los papeles que los usuarios rellenan a diario.

Por último, se decidió usar el framework de Struts para el desarrollo de la aplicación. Con strutsconseguimos una aplicación perfectamente estructurada basada en el patrón de diseño Modelo-Vista-Controlador.

- 34 -




Las ventajas de Struts no sólo se centran en el desarrollo de la aplicación sino que también juega unpapel muy importante en el futuro de la aplicación, facilitándonos en gran medida las operaciones demantenimiento y futuras modificaciones y ampliaciones.

3.1.1. Casos de uso Los casos de uso son una técnica que propone UML para la captura de los requisitos funcionales del

sistema. Así, los casos de uso deben describir el comportamiento del sistema (qué hace el sistema) ycómo interacciona con los distintos elementos del sistema.

Para representar los casos de uso, UML propone una notación gráfica que incluye los siguienteelementos básicos:

– Actores: Representan el papel de usuarios genéricos del sistema. Se representan mediante undibujo esquematizado de una persona con un nombre que indica el tipo de rol que juega en elsistema.

– Casos de uso: Es una descripción de la interacción entre un actor y el sistema (o entre dos casosde uso). Los casos de uso describen qué hace el sistema ante los requisitos de los distintosactores.

– Relaciones entre actores y casos de uso: Se representan con luna linea continua que indica queel actor ha invocado a un caso de uso, o bien que caso de uso y actor interactúan entre si.

– Relaciones entre casos de uso: Pueden ser de dos tipos. La relación del tipo <<include>>especifica que la invocación de un caso de uso implica necesariamente que éste invoca al menosun vez a los demás casos de uso con los que tenga una relación de tipo <<include>>. Por elcontrario, la relación de tipo <<extend>> especifica que la invocación de un caso de uso puedeimplicar que éste invoque a los demás casos de uso con los que tenga una relación del tipo<<extend>>

En el funcionamiento normal de un hospital hay tres actores que intervienen en la gestión de laspruebas de laboratorio. Estos actores son: Médico, Enfermero y Técnico de Laboratorio. Para elmantenimiento de la aplicación crearemos un nuevo actor que será el Administrador.

(1) Actor Médico

Figura 10: Casos de uso del actor Médico

– Caso de Uso “Validación en el sistema”: El actor deberá ser validado por el sistema antes depoder acceder al mismo. A continuación, y si la validación es correcta, el sistema comprobará que

- 35 -




permisos posee. El usuario podrá acceder a los casos de uso que describimos en este aparatado siposee permiso de acceso al módulo de médicos.

– Caso de Uso “Elegir Paciente”: Lo primero que hace un médico cuando le llega un paciente esbuscar la ficha del paciente en el sistema, esta búsqueda la puede realizar por el dni, el número dela seguridad social, o cualquier otro campo o combinación de ellos. Una vez encontrado al pacienteel médico podrá interactuar con el sistema para obtener distintos servicios. Éstos vendrán indicadosen los siguientes casos de uso.

También se le ofrece al médico la posibilidad de realizar un mantenimiento de la tabla“PERSONAS” para ello podrá realizar las siguientes acciones:

• consultas: para poder elegir pacientes

• Dar de alta a un paciente.

• Actualizar los datos de un paciente.

• Dar de baja un paciente.

– Caso de Uso “Enviar Solicitud de Prueba de Laboratorio”: El médico podrá rellenar unasolicitud con las pruebas de laboratorio que quiere que se le hagan al paciente. Una vez rellenada lasolicitud pasará a un estado de “Solicitud Pendiente” y estará disponible para los enfermeros y paralos laboratorios.

A la hora de rellenar la solicitud el médico podrá elegir entre tres tipos de solicitudes:

• Solicitud de bioquímica

• Solicitud de Hematología y Hemoterapia

• Solicitud de Microbiología y Epidemiología infecciosa

– Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio”: El médico puede consultarlas “Solicitudes Pendientes” que tiene su paciente actualmente. Las “Solicitudes Pendientes” sonaquellas solicitudes que el médico ha enviado al laboratorio pero cuyos resultados o parte de susresultados están aún sin completar, es decir, el laboratorio aún no ha terminado de rellenar la hojade resultados.

– Caso de Uso “Consultar Solicitudes Consolidadas del Laboratorio”: El médico puede consultarlas “Solicitudes Consolidadas” del paciente que son aquellas cuya hojas de resultados estáncompletas, es decir, el laboratorio ya ha terminado de rellenar la solicitud completamente y losdatos son definitivos.

– Caso de Uso “Ver resultados de Solicitud”: Extiende a los dos casos de uso anteriores y permiteal médico ver los resultados de cada solicitud. Lo que le saldrá por cada solicitud será una hoja deresultados donde podrá ver para cada prueba el resultado medido por el laboratorio y si este estádentro o fuera del rango normal.

– Caso de Uso “Ver Información Prueba”: Extiende al caso de uso anterior. Un médico podrá verinformación adicional de una prueba de la hoja de resultados con solo pulsar sobre ella.

(2) Actor Enfermero

- 36 -




Figura 11: Casos de uso del actor Enfermero

– Caso de Uso “Validación en el sistema”: El actor deberá ser validado por el sistema antes depoder acceder al mismo. A continuación, y si la validación es correcta, el sistema comprobará quepermisos posee. El usuario podrá acceder a los casos de uso que describimos en este aparatado siposee permiso de acceso al módulo de enfermeros.

– Caso de Uso “Consultar Solicitudes Pendientes”: El enfermero podrá consultar las “SolicitudesPendientes” que hay en el sistema, así, viendo las pruebas que hay que realizar al paciente, sabráque muestras deberá coger del paciente (por ejemplo, una muestra de sangre, una muestra deorina, etc).

– Caso de Uso “Introducir Número de Muestra”: Una vez que se ha recogido la muestra delpaciente, ésta se guardará en un tarro o tubo que luego se enviará al laboratorio.

En un hospital lo que se suele hacer es pegar, tanto al tarro como a la solicitud, un código de barrascon el mismo número así el laboratorio puede saber a quien pertenece cada muestra.

En nuestra aplicación esto se ha solucionado permitiendo al enfermero rellenar el campo “Nº deMuestra” en la solicitud, el cual contendrá el número del código de barras que se haya pegado a lamuestra.

(3) Actor Laboratorio

Figura 12: Casos de uso del actor Laboratorio

– Caso de Uso “Validación en el sistema”: El actor deberá ser validado por el sistema antes depoder acceder al mismo. A continuación, y si la validación es correcta, el sistema comprobará quepermisos posee. El usuario podrá acceder a los casos de uso que describimos en este aparatado siposee permiso de acceso al módulo de laboratorios.

– Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio”: El laboratorio puedeconsultar las “Solicitudes Pendientes” que han recibido y que les queda por rellenar.

- 37 -




– Caso de Uso “Introducir Número de Muestra”: Aunque lo normal es que la muestra la recoja elenfermero también se puede dar el caso que lo haga el laboratorio por lo que se le debe permitir laposibilidad de rellenar el el campo “Nº de Muestra” de la solicitud, el cual contendrá el número delcódigo de barras que se haya pegado a la muestra.

– Caso de Uso “Introducir Resultados de Laboratorio”: Para cada solicitud se desplegará enlaboratorio una “Hoja de Resultados”, en la que sólo aparecerán aquellas pruebas de laboratorioque debe rellenar el laboratorio. Una “Hoja de Resultado” consistirá, pues, en un formulario dondeel laboratorio introducirá para cada prueba el resultado medido.

– Caso de Uso “Consolidar Resultado”: Una vez que se haya terminado de rellenar la “Hoja deResultados” el laboratorio podrá proceder a consolidarla, esto es, hacer definitivos todos los datosrellenados. El estado de la solicitud pasará de ser “Solicitud Pendiente” a “Solicitud Consolidada”.

También hay otros dos casos de uso que extienden al caso de uso “Introducir Resultados deLaboratorio”:

– Caso de Uso “Ver Información Prueba”: Hemos dicho que en la “Hoja de Resultados” aparecenlas pruebas a rellenar. El laboratorio podrá ver también información adicional de la prueba con solopulsar sobre ella.

– Caso de Uso “Añadir Prueba”: Permite al laboratorio añadir una prueba a la “Hoja de Resultados”.Lo más normal es que un médico rellene en la solicitud las casillas correspondientes a las pruebasque quiera realizar al paciente, así luego la “Hoja de Resultados” creará un formulario a partir de lascasillas que han sido rellenadas. No obstante, también se puede dar el caso que el médico quierarealizar una prueba que no tiene su correspondiente casilla en la solicitud por lo que la pedirá através del campo observaciones. Por eso se hace necesario que el laboratorio pueda añadirpruebas a la Hoja de Resultados.

(4) Actor Administrador

Figura 13: Casos de uso del actor Administrador

– Caso de Uso “Validación en el sistema”: El actor deberá ser validado por el sistema antes depoder acceder al mismo. A continuación, y si la validación es correcta, el sistema comprobará quepermisos posee. El usuario podrá acceder a los casos de uso que describimos en este aparatado siposee permiso de acceso al módulo de Administradores.

– Caso de Uso “Mantenimiento de Parámetros”: La tabla “PARÁMETROS” es de vital importanciaen la aplicación ya que en él se recogen todas los resultados de laboratorios y observacionesclínicas que podrán seleccionar los laboratorios. Para el mantenimiento de esta tabla elAdministrador podrá realizar las siguientes acciones:

• Realizar consultas: la búsqueda se podrá realizar a partir cualquier campo de tabla“PARAMETROS” o mediante una combinación de los mismos, ejemplos de estos campos son elnúmero LOINC, el componente, el sistema, la propiedad, etc.

• Dar de alta un parámetro: Una vez dado de alta un nuevo parámetro, éste estará disponible paralos laboratorios.

- 38 -




• Actualizar los valores de un parámetro: Entre los distintos valores que se pueden actualizartambién se encuentra el número LOINC. Así el administrador tiene la posibilidad de asociar acada prueba el número LOINC que le corresponde

• Dar de baja un parámetro: Dado que el mantenimiento de esta tabla es muy delicado sedesaconseja el dar de baja parámetros, por eso actualmente se encuentra deshabilitado estaacción en la aplicación, no obstante se ha implementado y se podría añadir en cualquiermomento.

– Caso de Uso “Mantenimiento de Médicos”: Para el mantenimiento la tabla “MEDICOS” elAdministrador podrá realizar las siguientes acciones:

• Realizar consultas: la búsqueda se podrá realizar a partir cualquier campo de tabla “MEDICOS”o mediante una combinación de los mismos, ejemplos de estos campos son el nombre,apellidos, DNI, etc.

• Dar de alta un médico.

• Actualizar los datos de un médicos.

• Dar de baja un médico.

- 39 -




3.2. Desarrollando en StrutsEn este apartado veremos mediante un ejemplo de nuestra aplicación cuáles son los pasos a seguir

para desarrollar una aplicación usando Struts.

3.2.1. Introducción Supongamos que tenemos una aplicación Web que consiste en un formulario que recoge datos y los

manda al servidor para su procesado. Si quisiéramos hacer este ejemplo tan simple utilizando Strutsnecesitaríamos implementar unos 6 ficheros (2 de ellos jsp). ¿Por qué tantos ficheros? UtilizandoStruts nunca se llega a una página de la capa de presentación directamente.

Esto es, en la url nunca se llega a una pagina jsp o html a través de su nombre. De eso se trata elMVC, la presentación está separada en otra capa.

Por lo general, en cualquier aplicación web siempre se sigue un mismo esquema:

1. se muestra un formulario2. se rellena3. se valida4. se manda a una página que realiza la lógica de negocio5. se muestra el resultado.

Todo esto se podría hacer con dos JSPs o dos ASPs, o dos CFM, o dos PHP o con un CGI, etc…

En Struts necesitaríamos lo siguiente:

1. -Una clase Action (su nombre podría empezar por Edit) encargada de cargar la página quecontiene el formulario.

2. Un Bean tipo ActionForm cuyos campos o atributos de instancia coinciden con los campos delformulario (al ser tipo JavaBean tendrá los correspondientes métodos set y get para los atributos). EsteActionForm y sus atributos son un requisito imprescindible. También puede contener un métodovalidate() para validar los campos de entrada del formulario.

3. Una JSP que contiene el formulario citado. Los campos deben coincidir con los definidos en elBean de formulario.

4. Una clase Action (su nombre podría empezar por Save) encargada de pasar la instancia delformulario al Bean de Lógica de Negocio, esperar su resultado y redirigir el flujo a una JSP de error ode éxito.

5. Un Bean de lógica de negocio (El que hace algo con los datos del formulario).

6. Una JSP para mostrar un mensaje en caso de éxito (o puede ser la misma del principio).

7. Una JSP para mostrar los errores en caso de error (o puede usarse una genérica).

Es importante recordar que el “mapa” de la aplicación se configura en el fichero struts-config.xml yes en este fichero donde se especifican las relaciones entre acciones y clases, entre formularios yclases y entre acciones y jsps de presentación.

Struts permite cierta flexibilidad en cuanto a nombres, pero conviene especificar cuál es Action,cuál es Form, cuál es Bean de negocio, etc.. así como meterlos en subpaquetes con ese nombre.

3.2.2. Ejemplo: Validación de Usuario Veamos mediante un ejemplo, cómo implementamos el esquema anterior en nuestra aplicación.

Vamos a resolver un caso muy común en las aplicaciones. Se trata de una pantalla de validación en laque se debe de introducir en un formulario el usuario y password para poder acceder a la aplicación.

- 40 -




I Diagrama de clases

Este sería el conjunto de clases utilizadas y sus relaciones.

Figura 14: Diagrama de clases

La clase edit también podría usar el formulario, pero en principio no tiene porqué.

II Diagrama de colaboración

En la siguiente figura podemos observar la interacción entre las clases y Struts:

Figura 15: Diagrama de colaboración

- 41 -




III Funcionamiento

➢ Tenemos una clase EditUsuarioPasswordAction a la que accedemos a través de la url“/editUsuarioPassword.do” tal como se especifica en struts-config.xml. Esta clase se encarga asu vez de cargar la JSP usuarioPassword.jsp

➢ El formulario mostrado en usuarioPassword.jsp está asociado al bean UsuarioPasswordForm.Los campos definidos en el formulario deben de existir en el bean UsuarioPasswordForm comoatributos tipo String con el mismo nombre que en el formulario. Estos atributos son:

• usuario :Usuario que quiere acceder al Sistema de Gestión de Laboratorios.

• password : Password del usuario que quiere acceder al Sistema de Gestión de Laboratorios.

• action :Mantenimiento de la acción que estamos procesando, en nuestro ejemplo puede tomar dosvalores “VALIDAR” O “LIMPIAR”. Este valor será utilizado por la clase Action que llamará a la lógicade negocio que procese la acción elegida.

Figura 16: Pantalla de Validación

➢ Una vez rellenado el formulario el usuario le daría al botón “enviar”, lo cual genera una petición quese dirigirá al controlador(ActionServlet).

➢ La clase ActionServlet cargaría los valores introducidos por el usuario en el ActionFormUsuarioPasswordForm y a continuación ejecutaría el método validate para validar estos camposde entrada.

En el ejemplo actual el método validate lo único que haría sería comprobar que se han rellenado loscampos Usuario y Password ya que los dos son obligatorios.

a) Si la validación de los campos de entrada no es correcta, por ejemplo no se ha introducido elcampo Password, el método validate devolvería un mensaje de error encapsulado en un objetoActionErrors. El controlador al comprobar que se ha producido un error redirigirá a la página originalque viene especificada en struts-config.xml mediante el atributo input.

- 42 -


<action path="/saveUsuarioPassword" type="PruebasDeLaboratorio.struts.action.SaveUsuarioPasswordAction" name="usuarioPasswordForm" scope="request" input="/usuarioPassword.jsp" validate="true"> <forward name="success" path="/controladorInicio.do?action=Create"/> <forward name="usuarioPassword" path="/usuarioPassword.jsp"/> </action>

Figura 17: Error en el método validate de UsuarioPasswordForm

b) Si los campos se hubieran introducido correctamente el método validate no lanzaría ningún errory el controlador enviaría el formulario a la url “/SaveUsuarioPassword.do” que según el “mapa” deacciones de struts especificado en struts-config.xml, provocaría la carga deSaveUsuarioPasswordAction.java.

➢ En SaveUsuarioPasswordAction.java se miraría el valor del atributo “action”, y ejecutaría laLógica de negocio correspondiente.

Si lo que se ha pulsado es el botón enviar, el atributo “action” tomaría el valor “VALIDAR” y enconsecuencia se llamaría al método validar de la clase LogicaDeNegocioUsuarioPassword.

a) En caso de que se produzca algún error en en la lógica de Negocio, se lanzaría una excepciónque sería recogida por la clase SaveUsuarioPasswordAction quien se encargaría a su vez deredirigir el mensaje de error (una instancia ActionErrors) a la página de error.

- 43 -



Figura 18: Error en la lógica de negocio al validar al usuario

b) Si todo hubiera ido bien y la lógica de negocio no hubiera lanzado ninguna excepción la siguientepágina sería “success” que mirando el “mapa” en struts-config.xml se corresponde con“/controladorInicio.do?action=Create”, que a su vez cargaría la página de inicio que lecorresponde al usuario:

Figura 19: Página de Pacientes

IV El código

EditUsuarioPasswordAction.java/** * EditUsuarioPasswordAction.java * @autor Ramón García Luengo */package PruebasDeLaboratorio.struts.action;

import java.io.IOException;

import java.util.Locale;

import javax.servlet.ServletException;

- 44 -




import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import javax.servlet.http.HttpSession;

import org.apache.struts.action.Action;import org.apache.struts.action.ActionError;import org.apache.struts.action.ActionErrors;import org.apache.struts.action.ActionForm;import org.apache.struts.action.ActionForward;import org.apache.struts.action.ActionMapping;import org.apache.struts.action.ActionMessages;import org.apache.struts.util.MessageResources;

/** * Implementación de la clase <strong>Action</strong> encargada de llamar * a la lógica de negocio que procesa la petición HTTP que llega. <br> * Es utilizada para cargar la página que valida al usuario. * <br><br> * La lógica de negocio a realizar viene indicada en el parámetro <strong>action</strong><br> * <li> Si action=null o action="Create": Carga la página jsp que contiene el formulario de * usuario password </li> * @autor Ramón García Luengo */public class EditUsuarioPasswordAction extends Action {

/** * Procesa la petición HTTP (request) especificada y genera su correspondiente * respuesta HTTP (response) (o lo redirige a otro componente web que podría crear). * Devuelve una instancia <code>ActionForward</code> que describe a DONDE y COMO * se redirige el control. * @param mapping El mapeo utilizado para seleccionar esta instancia * @param form La instancia ActionForm que estamos utilizando (si la hay) * @param request El HTTP request que estamos procesando * @param response La respuesta HTTP que estamos creando. * @return * @throws java.io.IOException en caso de error de entrada/salida (i/o) * @throws javax.servlet.ServletException en caso de error de servlet */ public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse

response) throws IOException, ServletException { // Extrae los atributos que se necesitan

Locale locale = getLocale(request);MessageResources messages = getResources(request);HttpSession session = request.getSession();String action = request.getParameter("action");

//Usado para los mensajes de error ActionErrors errors = null; //Usado para los mensajes de estado ActionMessages actionMessages = new ActionMessages();

String siguientePagina = "failure";

if (action == null) {

action = "Create"; }

try { if (action.compareTo("Create") == 0) { // nombre lógico de la pagina jsp que carga el formulario de usuario y password siguientePagina = "success"; } // Redirige a la página especificada en struts-config.xml return mapping.findForward(siguientePagina); }catch (Exception e) { errors = new ActionErrors(); errors.add("error",new ActionError("error.aplicacion")); saveErrors(request,errors); //Escribe en el fichero de log del servidor de aplicaciones los errores producidos. e.printStackTrace(System.out); // Mensaje detallado de la excepcion lanzada y su traza.

return (mapping.findForward("failure")); } }}

- 45 -


usuarioPassword.jsp

<%@ page language="java"%><%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%><%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%><%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%><html:html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>Página de Validación</title> <link href="principal.css" rel="stylesheet" type="text/css"/> <SCRIPT language="javascript1.2">//FUNCIONES AL PULSAR UN BOTÓNfunction enviar(){ document.forms[0].action.value = "VALIDAR";}function limpiar(){ document.forms[0].action.value = "LIMPIAR";} </SCRIPT> </head> <body bgcolor="#FFFFEE"> <html:form action="/saveUsuarioPassword.do" focus="usuario"> <html:hidden property="action"/> <table> <tr>  <td style="height:1024px; width:4cm; vertical-align:top; background-color:#99CCFF"> <table width="100%" style="width:4cm; cellpadding=" 0 cellspacing="1"> <tr> <td bgcolor="#99CCFF"> <table width="100%" align="right" border="0" cellpadding="0" cellspacing="0"> <tr> <td class="FilaVacia0"/> </tr> <tr> <td> <div align="center"> <img src="./img/logotipo.jpg" width="80" height="68"/> </div> </td> </tr> <tr> <td> <div align="center" style="font-size:9px; letter-spacing: 0px; font-family:Arial, Helvetica, sans-serif "> <br/>Servicio Andaluz de Salud <br/>Area Hospitalaria Virgen Macarena <br/>Sevilla </div> </td> </tr> </table> </td> </tr> <tr> <td bgcolor="#FFFFFF" style="height:1px "/> </tr> </table> </td>  <td valign="top"> <table style=" width:21cm ">  <tr> <td> <html:messages id="mensaje" name="org.apache.struts.action.ACTION_MESSAGE" property="mensajeEstado"> <li> <bean:write name="mensaje"/> </li> </html:messages> <logic:present name="org.apache.struts.action.ERROR"> <span class="letraRojo">Operación no completada, se ha producido el siguiente error: <br/>

- 46 -

</span> </logic:present> <span class="letraRojo"> <html:errors property="errorValidacion"/> </span> </td> </tr>  <tr> <td style="height:5cm"/> </tr> <tr> <td style="vertical-align:middle " align="center">  <table style="width:10cm " class="fichaDelPaciente" cellspacing="1" cellpadding="1"> <tr> <td colspan="2" class="EncabezadoTabla">INTRODUZCA SU USARIO Y PASSWORD</td> </tr> <tr> <td width="50%"> <table style="width:10cm " cellspacing="0" cellpadding="2"> <tr> <td width="45%" class="campoDatosPersonales">USUARIO</td> <td align="left"> <html:text property="usuario" size="20" maxlength="20"/> </td> </tr> <tr> <td class="campoDatosPersonales">PASSWORD</td> <td align="left"> <html:text property="password" size="20" maxlength="20"/> </td> </tr> </table> </td> </tr> <tr> <td class="FilaVacia2"/> </tr> <tr> <td colspan="2" style="text-indent:20px " align="center"> <html:image src="img/botones/enviar.gif" onclick="javascript:enviar()"/> <html:image src="img/botones/limpiar.gif" onclick="javascript:limpiar()"/> </td> </tr> <tr> <td class="FilaVacia2"/> </tr> </table>  </td> </tr> </table> </td> </tr> </table> </html:form> </body></html:html>

UsuarioPasswordForm.java/** * UsuarioPasswordForm.java * Form Bean que implementa el formulario de Usuario y Password * @autor Ramón García Luengo */package PruebasDeLaboratorio.struts.form;import PruebasDeLaboratorio.struts.util.Validaciones;

import javax.servlet.http.HttpServletRequest;

import org.apache.struts.action.ActionError;import org.apache.struts.action.ActionErrors;import org.apache.struts.action.ActionForm;

- 47 -



import org.apache.struts.action.ActionMapping;

/** * Form Bean que implementa el formulario de "Usuario y Password". * <br><br> * Este formulario tiene los siguientes campos:<br> * <li><b>action</b> - Mantenimiento de la accion que estamos procesando: "Create", "VALIDAR" o "LIMPIAR".</li> * <li><b>usuario</b> - Usuario que quiere acceder al sistema de Pruebas de Laboratorios.</li> * <li><b>password</b> - Password del usuario que quiere acceder al sistema de Pruebas de Laboratorios.</li> * @autor Ramón García Luengo */public class UsuarioPasswordForm extends ActionForm { /** * Usuario que quiere acceder al sistema de Pruebas de Laboratorios */ private String usuario = null; /** * Password del usuario que quiere acceder al sistema de Pruebas de Laboratorios */ private String password =null; /** * Mantenimiento de la accion que estamos procesando. * Utilizado por la clase Action que llamará a la lógica de negocio * que procese la accion elegida. */ private String action = "Create";

public UsuarioPasswordForm() { } public String getUsuario() { return usuario; } public void setUsuario(String usuario) { this.usuario = usuario; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } public String getAction() { return action; } public void setAction(String action) { this.action = action; }

/** * Valida las propiedades asignadas desde el HTTP request * y devuelve un objeto <code>ActionErrors</code> que encapsula cualquier * validación de error que haya sido encontrada. Si no se han encontrado errores * , devuelve <code>null</code> o un objeto <code>ActionErrors</code> sin mensajes * de error grabados. * * @param mapping El mapping utilizado por la instancia. * @param request El servlet request que estamos procesando. * @return */

public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {

ActionErrors errors = new ActionErrors(); // La clase validaciones implementa métodos para la validación de los campos de entrada de formularios Validaciones validacion = new Validaciones();

if ( this.action.compareTo("VALIDAR") == 0 ) { // Validamos campo usuario if (validacion.validaCampoTexto(this.usuario,true,false,"error.usuarioPassword.usuario",40,1) == false ) { errors.add("errorValidacion",new ActionError(validacion.getMensajeError()));

- 48 -




return errors; } // Validamos campo password if (validacion.validaCampoTexto(this.password,true,false,"error.usuarioPassword.password",40,1) == false ) { errors.add("errorValidacion",new ActionError(validacion.getMensajeError())); return errors; } } return errors; }

}

SaveUsuarioPasswordAction.java/** * SaveUsuarioPasswordAction.java * @autor Ramón García Luengo */package PruebasDeLaboratorio.struts.action;import PruebasDeLaboratorio.struts.bean.Usuario;import PruebasDeLaboratorio.struts.form.UsuarioPasswordForm;import PruebasDeLaboratorio.struts.service.GestorDeErrores;import PruebasDeLaboratorio.struts.service.LogicaNegocioUsuarioPassword;import PruebasDeLaboratorio.struts.service.PruebasDeLaboratorioException;import PruebasDeLaboratorio.struts.sql.BaseDeDatos;

import java.io.IOException;

import java.sql.Connection;

import java.util.Locale;

import javax.servlet.ServletException;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import javax.servlet.http.HttpSession;

import org.apache.struts.action.Action;import org.apache.struts.action.ActionError;import org.apache.struts.action.ActionErrors;import org.apache.struts.action.ActionForm;import org.apache.struts.action.ActionForward;import org.apache.struts.action.ActionMapping;import org.apache.struts.action.ActionMessages;import org.apache.struts.util.MessageResources;

/** * Implementación de la clase <strong>Action</strong> encargada de llamar * a la lógica de negocio que procesa la petición que llega del formulario de Usuario y password. * <br> * Es utilizado para validar al usuario antes de permitirle el acceso al sistema. * <br><br> * La lógica de negocio a realizar viene indicada en el parámetro <strong>action</strong><br> * <li> Si action="VALIDAR": valida al usuario </li> * <li> Si action="LIMPIAR": limpia los datos que aparecen por pantalla */public class SaveUsuarioPasswordAction extends Action {

/** * Procesa la petición HTTP (request) especificada y genera su correspondiente * respuesta HTTP (response) (o lo redirige a otro componente web que podría crear). * Devuelve una instancia <code>ActionForward</code> que describe a DONDE y COMO * se redirige el control. * @param mapping El mapeo utilizado para seleccionar esta instancia * @param form La instancia ActionForm que estamos utilizando (si la hay) * @param request El HTTP request que estamos procesando * @param response La respuesta HTTP que estamos creando. * @return * @throws java.io.IOException en caso de error de entrada/salida (i/o) * @throws javax.servlet.ServletException en caso de error de servlet */

- 49 -




public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponseresponse) throws IOException, ServletException

{ // Extrae los atributos que se necesitan

Locale locale = getLocale(request);MessageResources messages = getResources(request);HttpSession session = request.getSession();String action = request.getParameter("action");

//Usado para los mensajes de error ActionErrors errors = null; //Usado para los mensajes de estado ActionMessages actionMessages = new ActionMessages();

String siguientePagina = "failure";

// Atributos del request UsuarioPasswordForm usuarioPasswordForm = (UsuarioPasswordForm) form;

if (action == null) {

action = "Create"; }

// Obtenemos la instancia del objeto BaseDeDatos. BaseDeDatos baseDeDatos = BaseDeDatos.getInstancia(); Connection connection = null;

try { // Abrimos la conexion con la base de datos connection = baseDeDatos.getConnection(); // Instanciamos el objeto que implementa la lógica de negocio. Le pasamos al constructor la conexión con la base de datos. LogicaNegocioUsuarioPassword logicaNegocioUsuarioPassword = new LogicaNegocioUsuarioPassword(connection); if (action.compareTo("Create") == 0) { siguientePagina = "usuarioPassword";

}else if (action.compareTo("VALIDAR") == 0) { // Llamamos a la lógica de negocio que valida al usuario. Devuelve true si el usuario es válido y lanza // una excepción PruebasDeLaboratorioException en caso contrario. boolean valido = logicaNegocioUsuarioPassword.validar(usuarioPasswordForm); if (valido) { // El usuario es valido // Obtenemos al usuario con todos sus datos y con su tipo de usuario Usuario usuario = logicaNegocioUsuarioPassword.getUsuario(usuarioPasswordForm); // Añadimos a la sesón el objeto usuario necesario para saber si ha sido validado session.setAttribute("usuario",usuario); // Añadimos a la sesón la lista de permisos a subsistemas session.setAttribute("listaPermisosSubsistemas",usuario.getTipoUsuario().getListaPermisosSubsistemas()); } siguientePagina = "success";

} else if (action.compareTo("LIMPIAR") == 0) { usuarioPasswordForm = new UsuarioPasswordForm(); //añadimos al request el bean de usuarioPasswordForm request.setAttribute("usuarioPasswordForm",usuarioPasswordForm); siguientePagina = "usuarioPassword"; }

// Cerramos la conexion con la base de datos baseDeDatos.closeConnection(); // Redirige a la página especificada en struts-config.xml

return mapping.findForward(siguientePagina);

}catch ( PruebasDeLaboratorioException e) { // Este catch captura el error que se haya producido en la aplicación. // Gestionamos el error: Deshacemos los cambios, finalizamos la transaccion, cerramos la conexión y escribimos los errores en

el fichero de log GestorDeErrores.gestionDeError(e,baseDeDatos,messages);

- 50 -


// Añadimos el error que se ha producido a la propiedad "error" errors = new ActionErrors(); errors.add("error",new ActionError(e.getKey())); saveErrors(request,errors); // Redirigimos a la página de error donde se mostrarán los errores de la propiedad "error"

return (mapping.findForward("failure"));

}catch (Exception e) { // En este catch capturamos cualquier error que no haya sido controlado por la aplicación. // Gestionamos el error: Deshacemos los cambios, finalizamos la transaccion, cerramos la conexión y escribimos los errores en

el fichero de log GestorDeErrores.gestionDeError(e,baseDeDatos); // Añadimos el error que se ha producido a la propiedad "error" errors = new ActionErrors(); errors.add("error",new ActionError("error.aplicacion")); saveErrors(request,errors);

// Redirigimos a la página de error donde se mostrarán los errores de la propiedad "error" return (mapping.findForward("failure")); } }}

error.jsp<%@ page language="java"%><%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%><%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%><%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%><html:html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>Página de Error</title> <link href="principal.css" rel="stylesheet" type="text/css"/> </head> <body bgcolor="#FFFFEE"> <table style=" width:21cm"> <tr> <td>  <table width="100%" cellpadding="0" cellspacing="0"> <tr> <td class="columnaCabecera">Gestión de Errores</td> </tr> </table>  </td> </tr> <tr> <td style="height:4px;"/> </tr> <tr> <td> <table style="width:19cm " class="fichaDelPaciente" cellspacing="0" cellpadding="2"> <tr> <td class="EncabezadoTabla">PAGINA DE ERROR</td> </tr> <tr> <td style="height:8px "/> </tr> <tr> <td style="FilaVacia0"> </td> </tr> <tr> <td class="error">Se ha producido el siguiente error:</td> </tr> <tr> <td style="FilaVacia0"> </td> </tr> <tr> <td class="error"> <span class="letraRojo"> <html:errors property="error"/> </span>

- 51 -

</td> </tr> <tr> <td style="FilaVacia0"> </td> </tr> <tr> <td style="FilaVacia0"> </td> </tr> <tr> <td align="center"> <html:image src="img/botones/volver.gif" onclick="javascript:history.back()"/> </td> </tr> <tr> <td style="FilaVacia0"> </td> </tr> <tr> <td style="FilaVacia0"> </td> </tr> </table> </td> </tr> </table> </body></html:html>

struts-config.xml<?xml version = '1.0' encoding = 'windows-1252'?><!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"

"http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">



<struts-config>  <form-beans> <form-bean name="usuarioPasswordForm" type="PruebasDeLaboratorio.struts.form.UsuarioPasswordForm"/>

...

 <global-forwards> <forward name="failure" path="/error.jsp"/> </global-forwards>  <action-mappings>

  

 <action path="/editUsuarioPassword" type="PruebasDeLaboratorio.struts.action.EditUsuarioPasswordAction">  <forward name="success" path="/inicioUsuarioPassword.html" /> </action>


 <action path="/controladorInicio"

- 52 -

type="PruebasDeLaboratorio.struts.action.ControladorInicioAction"> <forward name="success" path="/inicio.jsp"/> </action>

...

</action-mappings>  <message-resources parameter="PruebasDeLaboratorio.struts.ApplicationResources"/> </struts-config>

3.2.3. Implementación en el resto de la aplicación Puede que el camino seguido para solucionar un problema tan simple como de la validación de

Usuario haya parecido algo compleja y larga. Por contra podemos decir que la gran ventaja de haberutilizado Struts es que tenemos una aplicación totalmente estructurada, muy fácil de mantener yampliar.

El resto de ejemplos de la aplicación, aunque parezcan más complicados, se solucionaríanexactamente de la misma manera, sólo hay que cumplir con el patrón de diseño de Struts que hemosexplicado.

No obstante hay que indicar que para el resto de la aplicación se ha hecho un pequeño cambio en laestructura. Esto es, que en lugar de haber dos clases Action:

• una que empieza por Edit encargada de cargar el formulario,

• otra que empieza por Save encargada de pasar la instancia del formulario a la Lógica de negocio,

se han incluido en una única clase action que empieza por Controlador ( como por ejemploControladorPersonaAction ). Esta clase hará la función del Edit si el parámetro action que recibevale null o “Create” y hará la función de Save en cualquier otro caso.

A priori no hay ninguna ventaja en unir las dos clases en una pero en el ejemplo se ha preferido usardos clases Edit y Save para ver mejor el flujo que sigue nuestra aplicación.

Ahora, cuando queramos cargar por primera vez una página en lugar de llamar a la clase Editllamaremos a la clase Action pasándole el parámetro action con valor “action=Create”. Se puedeobservar que en el ejemplo de validación, nada más terminar de validar al usuario se llama a la url“/controladorInicio.do?action=Create”. para que cargue la página de inicio.

- 53 -



3.3. Organización de los Elementos en el Servidor de AplicaciónEn este apartado tendremos una vista general de cómo se organizan los elementos en el servidor de

aplicación. También se terminan de explicar distintos aspectos que no cubre struts en el diseño de losobjetos de negocio. También aprovecharemos este apartado para describir el funcionamiento dealgunas clases importantes para la aplicación que aún no hemos explicado. Por último mostraremos laorganización de los paquetes de nuestra apliación.

3.3.1. Introducción Vamos a recordar brevemente el diseño de nuestra aplicación. En el apartado 2.2 vimos que la

arquitectura elegida para nuestro sistema de información es un modelo cliente/servidor de 3 capas, locual es una configuración muy habitual para aplicaciones accesibles desde internet con acceso a basede datos.


La capa intermedia, es el servidor de aplicaciones y es quien soporta la lógica de negocio para elintercambio de información entre el cliente y el SGBD. Para su desarrollo usaremos el framework deStruts ya explicado en los apartados 2.3 y 3.2:

figura 21: MVC-2 en Struts

- 54 -




El propósito de Struts es crear un framework OpenSource para desarrollar aplicaciones webbasadas en java según el patrón arquitectónico MVC-2 (variante del modelo-vista-controlador).

En la figura 21 se puede ver que:

➢ el controlador central es la clase ActionServlet

➢ el modelo = ActionForm + Actions + Objetos de Negocio

➢ para la Vista usamos JSP y taglibs (librerías de tag proporcionadas por Struts)

Cada una de estas partes fue ampliamente detallada en el apartado 2.3, lo único que nos queda porexplicar es el diseño de los Objetos de Negocio. Struts da soporte para implementar las capascontrolador y vista de una aplicación web, pero no dice nada de cómo se deben de diseñar la lógica denegocio.

3.3.2. Diseño de los Objetos de Negocio Los objetos de negocio son entidades que representan los conceptos de negocio, sus

características y su comportamiento.

Como podemos ver en la figura 21, las clases Action acceden a los Objetos de Negocio. El diseñoque hemos utilizado para implementar los objetos de negocio es el siguiente.

figura 22: Diseño de los Objetos de Negocio

I Clases Action

Las clases Action, se encargan de llamar a la lógica de negocio que procesa la petición del usuario.

El funcionamiento de esta clase es el siguiente:

1. Abre una conexión con la base de datos a través de la clase BaseDeDatos.java

- 55 -




2. Basándose en el parámetro action que le llegue, llama a la lógica de negocio que procesa lapetición del usuario. Para ello le pasará a la lógica de negocio la conexión que acaba de abrir con labase de datos, así como los ActionForm con la información de los formularios que ha rellenado elusuario.

3. Si todo ha ido bien recibirá el resultado de la lógica de negocio.

4. Si ha habido algún fallo capturará la excepción lanzada y ejecutará un rollback() para deshacer loscambios de la última transacción en la base de datos. Redirigirá a la página de error que mostraráel mensaje de error.

5. Por último, cierra la conexión y mete en la sesión los beans que necesite la vista.

II Beans Lógica de Negocio

Las clases LogicaDeNegocioXXX.java Implementan la lógica de negocio que procesa la petición delusuario. Existirán distintas clases según la lógica de negocio que implementa. Veamos algunosejemplos:

– LogicaNegocioPersona.java: implementa la lógica de negocio correspondiente a las distintasacciones sobre las personas.

– LogicaNegocioSolicitudBioquimica.java: Clase que implementa la lógica de negociocorrespondiente a las distintas acciones sobre las solicitudes de bioquímica.

– ...

Si estas clases tienen que acceder a la base de datos lo harán a través de los beansSql queexplicamos a continuación. Para ello le pasará a los beansSql la conexión ya abierta con la base dedatos.

III BeansSQL

Estas clases hacen de intermediarias entre la lógica de negocio y la base de datos. Los BeansSQLcontienen todos los métodos de acceso a Base de Datos. Estos métodos están implementados enJDBC.

A igual que ocurría con los beans de la lógica de negocio, aquí también existirán distintas clasessegún a qué tablas accedan y para qué acciones. Veamos algunos ejemplos.

– PersonaSql.java: contiene todos los accesos a la base de datos que necesita la lógica de negocioque implementa las distintas acciones sobre las personas.

– SolicitudBioquimicaSql.java: contiene todos los accesos a la base de datos que necesita la lógicade negocio que implementa las distintas acciones que hay sobre las Solicitudes de Bioquímica.

– ...

Para poder acceder a la base de datos se le pasará al constructor la conexión que estéactualmente abierta.

IV BaseDeDatos.java

La clase BaseDeDatos.java es la representación en java de la Base de Datos. Se utilizabásicamente para abrir y cerrar las conexiones a la Base de Datos, así como para realizar el commit yel rollback.

Esta clase sigue un patrón singleton por lo que sólo existirá una instancia de la clase

Para implementar el patrón singleton hemos creado un método getInstancia() que crea una instanciadel objeto sólo si todavía no existe alguna. Para asegurarnos de que la clase no puede ser instanciadanuevamente se regula el alcance del constructor con atributo private.

- 56 -




Lo que buscamos con el patrón singleton es reutilizar la conexión abierta con la base de datos, esdecir, sólo abrá una conexión abierta a la vez por sesion. Con esto conseguimos un mayor controlsobre la conexión así, en caso de error, sabremos que le estamos aplicando el rollback() a la conexiónadecuada. También ganaremos en tiempo ya que al reutilizar la misma conexión no se perderá eltiempo abriendo conexiones de más.

La clase BaseDeDatos.java contiene también los atributos necesarios para conectarse a la Base deDatos, éstos son:

private String Driver = "org.postgresql.Driver";

private String usuario = "nombreUsuario";

private String password = "passwordUsuario";

private String url = "jdbc:postgresql://localhost:5432/PruebasDeLaboratorio12";

➢ driver: nombre de la clase de Java que implementa el driver.

➢ usuario: define el usuario con el que se conectará la aplicación a la base de datos.

➢ password: define la clave con la que se conectará la aplicación a la base de datos.

➢ url: url para acceder a la base de datos

Vamos a explicar cómo es el acceso a la Base de Datos a través de java.

Para que un programa Java pueda acceder a una base de datos es necesario contar con un driveradecuado. Ese driver no es otra cosa que un conjunto de clases de Java, por lo que deberemosconocer cuál es el nombre de la clase de Java que implementa el driver. En nuestro caso

private String Driver = "org.postgresql.Driver";

A fin de que estas clases puedan ser usadas deberían cargarse en la máquina virtual de java. Paraello usamos el método Class.forName().

Class.forName(this.Driver);

El siguiente paso para acceder a una base de datos es pedirle a la clase DriverManager que creeuna conexión con la base de datos en cuestión. Para indicar cuál es la base de datos a la cuálqueremos conectarnos debemos utilizar una URL que posea un formato determinado. El métodoutilizado para crear la conexión es DriverManager.getConnection(). Este método devuelve unainstancia de una clase que implementa la interface java.sql.Connection,

Connection connection = DriverManager.getConnection(“url”,”usuario”,”password”);

Para conectarse a una base de datos postgreSQL la sintaxis de la url es la siguiente:

"jdbc:postgresql://<nombre del host>:<puerto>/<nombre de la base de datos>"

El objeto connection devuelto representará nuestra conexión con la Base de Datos.

V PruebasDeLaboratorioException.java La clase PruebasDeLaboratorioException almacena los errores que se producen en la aplicación en

tiempo de ejecución.

- 57 -




Todos los mensajes de error se guardarán en el fichero ApplicationResources.properties siguiendoel siguiente formato: claveDelError = TextoDelError , luego se accederá a ellos desde la páginageneral error.jsp mediante resource bundles.

La gestión de los errores en la aplicación consiste en que si se produce una excepción dentro de unmétodo, éste lo capturará y a continuación lanzará una excepción PruebasDeLaboratorioException.Esta excepción será capturada a su vez por la clase Actión que estuviera procesando la petición y seencargará de redirigir el mensaje de error (una instancia ActionErrors) a la página de error.

3.3.3. Organización de los paquetes Los paquetes son contenedores de clases que se utilizan para mantener el espacio de nombres de

clase dividido en compartimentos y para restringir la visibilidad.

En la figura podemos ver los paquetes que se han definido en la aplicación:

figura 23: Paquetes de la aplicación

Esta estructura de paquetes se ha hecho con vista a conseguir una mejor organización. Acontinuación vamos a describir qué conjunto de clases almacena cada paquete:

I PruebasDeLaboratorio.stuts.form

Este paquete contiene clases que extienden a la clase org.apache.struts.action.ActionForm delframework de struts. Una clase ActionForm es un bean que almacenará los datos del formulario quetenga asociado y por tanto sus atributos tendrán los mismos nombres que los campos de entradas delformulario. También posee un método validate() para validar dichos datos.

II PruebasDeLaboratorio.stuts.action

Este paquete contiene clases que extienden a la clase org.apache.struts.action.Action delframework de Struts. Son las encargadas de llamar a la lógica de negocio que procesa la petición delusuario y luego se encarga de redirigir a la página correcta.

III PruebasDeLaboratorio.stuts.service

Este paquete contiene clases que implementan la lógica de negocio.

IV PruebasDeLaboratorio.stuts.sql

Este paquete contiene las clases que hacen de intermediarias entre la lógica de negocio y la base dedatos. Los métodos de acceso a la base de datos están implementados usando la API JDBC.

V PruebasDeLaboratorio.stuts.bean

Almacena los beans utilizados por la aplicación que no extiendan a la clase ActionForm.

En algunos casos estos beans almacenan la misma información que los ActionForm pero de unamanera más cómoda para trabajar con ellos.

- 58 -




Por ejemplo, debido al formato de la solicitud, hay 3 atributos en el ActionForm para guardar elnúmero de la cama (uno guarda las centenas, otro las decenas y otro las unidades). Lo que se intentacon los beans de este paquete es facilitar el acceso a la información, así por ejemplo, el número decama se almacenará en un único atributo tipo String. Para conseguir esto se le pasará al constructorde esta clase el ActionForm que le corresponda.

VI PruebasDeLaboratorio.stuts.util

Contienen clases de distinto tipo pero que nos serán útiles a lo largo de la aplicación.

Por ejemplo tienen las siguientes clases:

• Fecha: Clase que contiene una serie de métodos útiles para el procesamiento de la Fecha.

• Validaciones: Implementa métodos para la validación de los campos de entrada de formularios.

• Utilidades: Contiene un conjunto de métodos estáticos que nos van a dar soluciones a algunosproblemas comunes en la aplicación, como por ejemplo rellenar de ceros una cadena por laizquierda.

3.3.4. JAVADOC Mediante la herramienta java JAVADOC podremos generar una serie de páginas web donde

podremos encontrar toda la documentación del código fuente java, esto es, los comentarios de lasclases y componentes de las clases (variables y métodos).

Esta información está disponible en el apartado javadoc de los ANEXOS (página 140).

- 59 -




3.4. Diseño de la Base de Datos

3.4.1. Introducción El diseño de la base de datos es un proceso complejo que normalmente se divide en tres fases:

➢ Diseño conceptual: Determinación del tipo de datos a almacenar y las relaciones entre losmismos.

El modelo más utilizado es el modelo de entidad-relación. Los elementos básicos del modelo E/Rson:

• Entidades

• Interrelaciones

• Atributos

➢ Diseño lógico: Determinación a partir del diseño conceptual, de los metadatos requeridos para undeterminado modelo de almacenamiento de datos.

Los modelos hacen referencia a la forma física (estructura) en la que se organizan los datos que seintroducen en la base de datos.

Existen cuatro modelos de bases de datos:

• Modelo jerárquico.

• Modelo en red

• Modelo orientado a objetos

• Modelo relacional (es el que vamos a usar)

El modelo relacional tiene básicamente dos tipos de elementos:

• estáticos : tablas o relaciones

• dinámicos: lenguajes para la manipulación de las tablas

Un punto muy importante es la normalización de las tablas, que consiste en forzar a un esquema aque cumpla un conjunto de restricciones o formas normales. En el diseño de las tablas de nuestrosistema nos hemos preocupado en que se cumplan hasta la 3ª forma normal.

➢ Diseño físico: Introducción de los metadatos en el SGBD.

3.4.2. Diagramas y descripción de tablas Para facilitar la comprensión y explicación del modelo de nuestro sistema vamos a dividirlo en una

serie de diagramas:

➢ Diagrama de Solicitudes:

• Subdiagrama Solicitud de Hematología y Hemoterapia

• Subdiagrama Solicitud de Bioquímica

• Subdiagrama Solicitud de Microbiología y Epidemiologia infecciosa

➢ Diagrama de Parámetros

➢ Diagrama de Acceso al Sistema

- 60 -




3.4.2.1. Notas sobre los diagramas Aunque en la introducción explicamos que el diseño de una base de datos consta de tres fases:

diseño conceptual, diseño lógico y diseño físico, nosotros vamos a explicar el diseño de nuestra basede datos de una manera más ágil usando unos diagramas muy completos en los que se pueden verreflejados aspectos de cada una de estas tres fases:

Si observamos por ejemplo el diagrama de la figura 25 vemos que contiene de cada fase:

➢ Diseño conceptual: Se puede observa que entre las tablas existe una notación que expresa lacardinalidad entre las entidades. En la siguiente figura vemos la notación utilizada para lacardinalidad:

figura 24:Notación de la cardinalidad

➢ Diseño lógico: en la figura 25 podemos ver que lo que se representan en todos los casos son lastablas. En la cabecera de cada una aparece el nombre de la tabla y a continuación aparecen losnombres de las columnas. Las columnas pueden aparecer acompañadas de unas siglas a suizquierda, éstas son:

• PK (Primary Key): indica que el atributo es clave primaria

• FK (Foreign key): indica que el atributo es una clave externa

• PF (Primary Foreign Key): indica que el atributo es una clave externa que pertenecen a la claveprimaria.

➢ Diseño físico: Junto con cada atributo aparece el tipo de dato físico como por ejemplo INT4 oVARCHAR(100) (suponemos que estamos usando una base de datos Postgresql).

Otras notaciones que hemos usado en los diagramas son:

➢ Si un atributo está acompañado del carácter “*” significa que es un campo not null (no puedendejarse con valor nulo)

➢ Las tablas de color gris son tablas que se han creado debido a la interrelación que existe entre dostablas. Por ejemplo la relación:

• 1 solicitud tiene “cero o más” determinaciones y

• 1 determinación está en “0 o más” solicitudes

como la relación existente entre estas dos entidades crearía una tabla, la hemos puesto de colorgris para que sea más fácil de identificar (ver figura 25).

- 61 -




figura 25:Ejemplo de convención de colores y notaciones en los diagramas

3.4.2.2. Diagrama de Solicitudes Con estos diagramas nuestro Sistema de Información será capaz de almacenar el historial de

pruebas de laboratorio de un conjunto de pacientes.

El historial de pruebas de laboratorio de un paciente está compuesto por :

• Los informes de solicitud de prueba de laboratorio que rellenan los médicos.

• La hoja de resultados asociada a cada solicitud que rellenan los laboratorios.

Es decir, por cada solicitud que tenga un paciente deberemos de poder recuperar tanto el informede solicitud que rellena el médico, como la hoja de resultados que rellena el laboratorio.

Hay tres tipos de solicitudes:


• Solicitud de Bioquímica

• Solicitud de Microbiología y Epidemiologia infecciosa

Esta división es arbitraria y se ha obtenido tras un estudio del negocio con el Hospital Macarena.

Estas tres solicitudes guardan una cierta similitud, por lo que una vez que se haya estudiado unoserá más fácil entender los siguientes.

- 62 -




I Subdiagrama: Solicitud de Hematología y Hemoterapia

En el diagrama de la figura 26 se encuentran las entidades y relaciones necesarias para almacenarlas solicitudes de pruebas de laboratorio y los resultados de laboratorio generados por el Servicio deHematología y Hemoterapia. Se aconseja que se consulte este diagrama a medida que se vanexplicando las entidades y las relaciones. No obstante, y para que sea más cómodo seguir lasexplicaciones, se irán poniendo pequeños diagramas donde se verán reflejadas las entidades yrelaciones que se expliquen en cada momento.

figura 26: Diagrama de Hematología y Hemoterapia

Para empezar podemos ver en el diagrama de la figura 26 que una persona tendrá cero o mássolicitudes de Hematología y Hemoterapia asociadas, mientras que una solicitud de Hematología yHemoterapia sólo podrá pertenecer a una persona. También podemos ver esta relación en la siguientefigura.

- 63 -




figura 27:Relación entre las entidades PERSONAS y SOLICITUDES_HEMATOLOGIA

Por cada una de estas solicitudes se tendrá que guardar tanto el informe de solicitud (figura 28)que rellena el médico como la hoja de resultados que se rellena en el laboratorio.

(1) Almacenamiento del informe de Solicitud

Para comprender mejor cual es la información que se debe guardar de una solicitud de Hematologíay Hemoterapia vamos a ver el informe que debe rellenar el médico (figura 28), así como las entidadesy relaciones que modelan este proceso (figura 29 ):

figura 28: Informe de Solicitud del Servicio de Hematología y Hemoterapia

- 64 -




figura 29: Diagrama para el almacenamiento del Informe de Solicitud del Servicio de Hematología y Hemoterapia

Vamos a explicar de manera general donde se almacena cada parte de la solicitud:

En la parte superior de la solicitud (figura 28) , debajo del cuadro de “recomendaciones generales”,podemos ver una serie de campos donde se deben representar los datos personales del paciente.Estos datos son: nombre y apellidos, fecha de nacimiento, NIF, número de la seguridad social, tarjetasanitaria y sexo. Toda esta información se presentará automáticamente por pantalla y se obtendrá dela tabla PERSONAS.

En la tabla SOLICITUDES_HEMATOLOGIA vamos a guardar:

• Si se trata de una “Hospitalización” o una “Consulta Externa”, esto se puede ver en la cabecera dela solicitud.

• Código médico, centro y número de consulta que se pueden ver en el lateral izquierdo de la solicitud( Código médico, número de habitación y número de cama si se trata de una “Hospitalización”).

• Los campos “otros” donde el médico puede hacer comentarios, éstos se pueden observar en loscuadros de “orientación diagnóstica” y de “determinaciones”.

• Si es una revisión o un diagnóstico (cuadro de arriba a la izquierda).

• La fecha de la solicitud, el número de la muestra y el identificador de solicitud (arriba a la derecha)

Para que el médico termine de rellenar la solicitud le faltaría por marcar las casillas quecorrespondan en los cuadros de “Orientación Diagnóstica” y “Determinaciones”.

Esto se modela con la siguiente relaciones:

– una solicitud tendrá cero o más orientaciones diagnósticas: para esto se han añadido las tablasSOL_HEMA_ORIENTACION_DIAG y ORIENTACION_DIAGNOSTICA

– una solicitud tendrá cero o más determinaciones: para esto se han añadido las tablasSOL_HEMA_DET_HEMA y DETERMINACIONES_HEMATOLOGIA.

Ahora vamos a describir detalladamente cada una de las tablas que intervienen:

TABLA I: SOLICITUDES_HEMATOLOGIA

Esta tabla almacenará todas las solicitudes de Hematología y Hemoterapia emitidas por los médicos.Está relacionada con la tabla persona mediante la clave externa ID_PERSONA, de tal manera que unapersona pueda tener 0 o más solicitudes de Hematología y Hemoterapia.

ID_SOLICITUD : Es la clave primaria. Identifica una solicitud de Hematología y Hemoterapia.

ID_PERSONA :Clave externa, con ella expresamos la siguiente relación con la tabla PERSONAS:

- 65 -




– una persona puede tener 0 o más solicitudes de Hematología y Hemoterapia.

– una solicitud de Hematología y Hemoterapia sólo puede ser de una persona.

ID_CLASE_CONSULTA : Clave externa. Identifica la clase de consulta: 1 si es una "consulta externa"y 2 si es una "hospitalización". Según del caso que se trate se deberán guardar distintos campos en latabla de SOLICITUDES_HEMATOLOGIA:

– En el caso de que se trate de una "Consulta Externa" se deberán almacenar los campos "centro" yel "número de la consulta" donde se realiza la cita.

– Si por el contrario se trata de una "hospitalización" se deberá almacenar el "Número de Habitación"y el "Número de la Cama".

ID_MEDICO : Clave externa. Identifica al médico que rellena la solicitud.

ID_CENTRO :Clave externa. Indica el código del centro donde se ha realizado la cita con el paciente.Sólo se rellena en el caso de que sea una “Consulta Externa” (ID_CLASE_CONSULTA=1) y no en unahospitalización.

FECHA_DE_SOLICITUD : Guarda la fecha en la que el médico envía la solicitud de Hematología yHemoterapia.

REVISION_DIAGNOSTICO : Puede tomar dos valores o "REVISION" o "DIAGNOSTICO" según dequé caso se trate.

CONSULTA : Guarda el número de la consulta donde se ha producido una cita. Solo se rellena en elcaso de que sea una consulta externa (ID_CLASE_CONSULTA=1) y no una hospitalización.

NUMERO_HABITACION : Guarda el número de habitación donde está hospitalizado el paciente. Sólose rellena cuando es una hospitalización (ID_CLASE_CONSULTA=2).

NUMERO_CAMA : Guarda el número de cama donde está el paciente. Sólo se rellena cuando es unahospitalización (ID_CLASE_CONSULTA=2).

RESULTADO_CONSOLIDADO : Valor booleano.

– Valdrá true cuando sea una "Solicitud Consolidada", esto es, cuando el laboratorio haya rellenadotodos los resultados y éstos sean definitivos.

– Valdrá false mientras que sea una "Solicitud Pendiente", es decir, el médico ha enviado la solicituda los laboratorios pero aún no se ha terminado de rellenar los resultados o incluso no se haempezado.

OR_DIAG_OTROS : Guarda el valor del campo "Otros" del apartado de Orientación Diagnostica. Elmédico lo puede rellenar para indicar alguna información complementaria relacionada con dichoapartado.

DET_COMENTARIO_DET : Guarda el valor del campo "determinaciones" donde el médico podrácomentar alguna información adicional sobre el apartado determinaciones.

DET_JUSTIFICACION : Guarda el valor del campo "Justificación" donde el médico podrá justificarcomentarios del apartado determinaciones.

NUMERO_MUESTRA : Guarda el número de la muestra. El número de la muestra es igual al númerodel código de barras con que se etiqueta el tarro donde se guarda la muestra del paciente.

Si volvemos a ver la solicitud de Hematología y Hemoterapia (figura 28), observamos que para queel médico termine de rellenar la solicitud le falta por marcar las casillas que correspondan en loscuadros de “Orientación Diagnóstica” y “Determinaciones”.

Esto se modela con las siguientes relaciones:

– una solicitud tendrá una o más orientaciones diagnósticas:

- 66 -




– una solicitud tendrá una o más determinaciones

Para ello usamos las siguientes tablas:

TABLA II: ORIENTACION_DIAGNOSTICA

Tabla que almacena las distintas Orientaciones Diagnósticas, como pueden ser: diabetes, insuficienciarespiratoria, neumonía, etc.

Está formada por dos columnas: el identificador y el nombre de la Orientación Diagnóstica.

ID_ORIENTACION_DIAGNOSTICA : Es la clave primaria. Identifica a la Orientación Diagnóstica. Alser de tipo SERIAL su valor se autoincrementará en uno por cada registro nuevo que se inserte.

D_ORIENTACION_DIAGNOSTICA : La descripción de la Orientación Diagnóstica

TABLA III: SOL_HEMA_ORIENTACION_DIAG

Tabla que almacena las casillas de Orientación Diagnóstica que han sido seleccionadas en unasolicitud de Hematología y Hemoterapia.

Esta tabla modela la relación:

- una solicitud de Hematología y Hemoterapia puede tener 0 o más Orientaciones Diagnósticas y

- una Orientación Diagnóstica puede estar en 0 o más solicitudes de Hematología y Hemoterapia.

ID_SOLICITUD: Clave externa que forma parte de la clave primaria de la tabla. Identifica la solicitud deHematología y Hemoterapia

ID_ORIENTACION_DIAGNOSTICA : Clave externa que forma parte de la clave primaria de la tabla.Identifica una Orientación Diagnóstica que ha sido seleccionada en la solicitud de Hematología yHemoterapia.

TABLA IV: DETERMINACIONES_HEMATOLOGIA

Tabla que almacena las Determinaciones de Hematología y Hemoterapia, como pueden ser :Hemograma, Fibrinógeno, etc.

Una determinación puede estar asociada a 1 o más pruebas de laboratorios (esto es, uno o másregistros de la tabla Parámetros).

Está formada por dos columnas: el identificador y el nombre de la determinación.

ID_DETERMINACION_HEMATOLOGIA : Es la clave primaria. Identifica a una Determinación. Al serde tipo SERIAL su valor se autoincrementará en uno por cada registro nuevo que se inserte.

D_DETERMINACION : La descripción de la Determinación.

TABLA V: SOL_HEMA_DET_HEMA

Tabla que almacena las casillas de Determinaciones que han sido seleccionadas en una solicitud deHematología y Hemoterapia.


- una solicitud de Hematología y Hemoterapia puede tener 0 o más determinaciones y

- una determinación puede estar en 0 o más solicitudes de Hematología y Hemoterapia.

ID_SOLICITUD: Clave externa que forma parte de la clave primaria de la tabla. Identifica la solicitud deHematología y Hemoterapia

- 67 -




ID_DETERMINACION_HEMATOLOGIA : Clave externa que forma parte de la clave primaria de latabla. Identifica una Determinación que ha sido seleccionada en la solicitud de Hematología yHemoterapia.

Con las tablas que hemos visto hasta aquí seríamos capaces de almacenar toda la información deuna solicitud de Hematología y Hemoterapia. Ahora queda ver cómo está organizada la parte que seencarga de almacenar los resultados de una solicitud dados por los laboratorios.

(2) Almacenamiento de los resultados

Una solicitud tendrá uno o más resultados u observaciones clínicas (éstos son registros de la tablaPARAMETROS).

figura 30: Diagrama para el almacenamiento de los resultados de Laboratorio del Servicio de Hematología y Hemoterapia

Para ello se usan las siguientes tablas:

TABLA I: RESULTADOS_HEMATOLOGIA

En esta tabla se almacenan los resultados de una solicitud de Hematología y Hemoterapia. Sealmacena el valor, la fecha de medida y el código de laboratorio de cada resultado de la solicitud.


- una solicitud de Hematología y Hemoterapia puede tener 0 o más parámetros (pruebas delaboratorio) y

- un parámetro puede estar en 0 o más solicitudes de Hematología y Hemoterapia.

ID_SOLICITUD : Clave externa que forma parte de la clave primaria de la tabla. Identifica la solicitudde Hematología y Hemoterapia.

ID_PARAMETRO : Clave externa que forma parte de la clave primaria de la tabla. Identifica elparámetro (la prueba de laboratorio) del que el laboratorio dará un resultado.

FECHA_MEDIDA : La fecha en la que se hizo la prueba de laboratorio.

VALOR : Valor o resultado de la prueba de laboratorio.

ID_LABORATORIO : Código que identifica el laboratorio que ha hecho la prueba de laboratorio.

TABLA II: PARAMETROS

Tabla que almacena las distintas Pruebas de laboratorio que se pueden hacer en el laboratorio.

- 68 -




Para identificar las pruebas de laboratorio se usa la propia codificación del laboratorio, esto es, la claveprimaria ID_PARAMETRO. Por cada prueba se guarda también el número LOINC asociado (soncódigos universales).

Dada la importancia y complejidad de esta tabla se analizará aparte en el apartado 3.4.2.3 (página 89).

Por último, hemos añadido una relación más en el diagrama de Hematología y Hemoterapia para lacreación automática de la hojas de resultados que tiene que rellenar el laboratorio. La idea es crearuna relación tal que a partir de las determinaciones que ha rellenado el médico podamos saber quepruebas de laboratorio deben rellenar los laboratorios.

figura 31: Diagrama que relaciona las Determinaciones con los Resultados de laboratorio.

En resumen, una determinación puede estar asociada a 1 o más pruebas de laboratorios (esto es,uno o más registros de la tabla Parámetros). Para ello disponemos de las siguientes tablas:

TABLA III: DETERMINACIONES_HEMA_PARAMETROS

En esta tabla almacenamos la correspondencia que existe entre una "Determinación" y los distintos"parámetros" que tiene asociado ( Nota: un parámetro es una prueba de laboratorio o, en terminologíaLOINC, un resultado u observación clínica).


- una determinación puede tener 0 o más parámetros y

- un parámetro puede estar en 0 o más determinaciones

ID_DETERMINACION_HEMATOLOGIA: Clave externa que forma parte de la clave primaria de latabla. Identifica una Determinación de Hematología y Hemoterapia.

ID_PARAMETRO : Clave externa que forma parte de la clave primaria de la tabla. Identifica unParámetro.

TABLA IV: PARAMETROS


Se analizará aparte en el apartado 3.4.2.3 (página 89).

- 69 -




II Subdiagrama: Solicitud de Bioquímica

El subdiagrama de Solicitud de Bioquímica es bastante parecido a la solicitud de Hematología yHemoterapia. La principal diferencia radica en el nuevo cuadro “Petición por perfiles” (ver figura 34)

En una solicitud de bioquímica muchas pruebas de laboratorio están agrupadas bajo un mismoperfil. De esta manera el médico puede solicitar todo un conjunto de pruebas con sólo marcar unacasilla de "Petición por Perfiles" de la Solicitud de Bioquímica.

En el diagrama de la figura 32 se encuentran las entidades y relaciones necesarias para almacenarlas solicitudes de pruebas de laboratorio y los resultados de laboratorio generados por elDepartamento de Bioquímica. Se aconseja que se consulte este diagrama a medida que se vanexplicando las entidades y las relaciones. No obstante, y para que sea más cómodo seguir lasexplicaciones, se irán poniendo pequeños diagramas donde se verán reflejadas las entidades yrelaciones que se expliquen en cada momento.

figura 32: Diagrama de Bioquímica

Para empezar podemos ver en el diagrama de la figura 32 que una persona tendrá cero o mássolicitudes de Bioquímica asociadas, mientras que una solicitud de Bioquímica solo podrá pertenecer auna persona. También podemos ver esta relación en la siguiente figura.

- 70 -




figura 33:Relación entre las entidades PERSONAS y SOLICITUDES_BIOQUIMICA

Por cada una de estas solicitudes se tendrá que guardar tanto el informe de solicitud (figura 34)que rellena el médico como la hoja de resultados que se rellena en el laboratorio.


Para comprender mejor cual es la la información que se debe guardar de una solicitud deBioquímica vamos a ver el informe que debe rellenar el médico (figura 34), así como las entidades yrelaciones que modelan este proceso (figura 35 ):

figura 34: Informe de Solicitud del Servicio de Bioquímica

- 71 -




figura 35: Diagrama para el almacenamiento del Informe del Departamento de Bioquímica



En la tabla SOLICITUDES_BIOQUIMICA vamos a guardar:


• Código médico, centro y número de consulta que se pueden ver en el lateral izquierdo de la solicitud( Código médico, número de habitación y número de cama si se trata de una “Hospitalización”).

• Los campos “otros” donde el médico puede hacer comentarios, éstos se pueden observar en loscuadros de “orientación diagnóstica” y de “determinaciones”.

• Si es una revisión o un diagnóstico (cuadro de arriba a la izquierda).


Para que el médico termine de rellenar la solicitud le faltaría por marcar las casillas quecorrespondan en los cuadros de “Petición por Perfiles”, “Orientación Diagnóstica” y “Determinaciones”.

Esto se modela con la siguiente relaciones:

– una solicitud tendrá cero o más perfiles: para esto se han añadido las tablasSOL_BIOQUIMICA_PERFILES y SOL_BIOQUIMICA_PERFILES.

– una solicitud tendrá cero o más orientaciones diagnosticas: para esto se han añadido las tablasSOL_BIOQUIMICA_ORIENTACION_DIAG y ORIENTACION_DIAGNOSTICA

– una solicitud tendrá cero o más determinaciones: para esto se han añadido las tablasSOL_BIOQUIMICA_DET_BIOQUIMICA y DETERMINACIONES_BIOQUIMICA.


TABLA I: SOLICITUDES_BIOQUIMICA

Esta tabla almacenará todas las solicitudes de bioquímica emitidas por los médicos. Está relacionadacon la tabla persona mediante la clave externa ID_PERSONA, de tal manera que una persona puedatener 0 o más solicitudes de bioquímica.

- 72 -




ID_SOLICITUD : Es la clave primaria. Identifica una solicitud de bioquímica

ID_PERSONA : Clave externa, con ella expresamos la siguiente relación con la tabla PERSONAS:

- una persona puede tener 0 o más solicitudes de bioquímica

- una solicitud de bioquímica sólo puede ser de una persona

ID_CLASE_CONSULTA : Clave externa. Identifica la clase de consulta: 1 si es una "consulta externa"y 2 si es una "hospitalización". Según del caso que se trate se deberán guardar distintos campos en latabla de SOLICITUDES_BIOQUIMICA:

– En el caso de que se trate de una "Consulta Externa" se deberán de almacenar los campos"centro" y el "número de la consulta" donde se realiza la cita.

– Si por el contrario se trata de una "hospitalización" se deberá almacenar el "Número de Habitación"y el "Número de la Cama".


ID_CENTRO : Clave externa. Indica el código del centro donde se ha realizado la cita con el paciente.Sólo se rellena en el caso de que sea una “Consulta Externa” (ID_CLASE_CONSULTA=1) y no en unahospitalización.

FECHA_DE_SOLICITUD : Guarda la fecha en la que el médico envía la solicitud de bioquímica.

REVISION_DIAGNOSTICO : Puede tomar dos valores o "REVISION" o "DIAGNOSTICO" según dequé caso se trate.

CONSULTA : Guarda el número de la consulta donde se ha producido una cita. Sólo se rellena en elcaso de que sea una consulta externa (ID_CLASE_CONSULTA=1) y no una hospitalización.





– Valdrá false mientras que sea una "Solicitud Pendiente", es decir, el médico ha enviado la solicituda los laboratorios pero aún no se ha terminado de rellenar los resultados o incluso no se haempezado.

DET_OTROS_INMUNO : Guarda el valor del campo "Otros: Solo Inmuno" que el médico puederellenar para indicar alguna información complementaria relacionada con dicho apartado.

DET_OTROS_SANGRE_ORINA : Guarda el valor del campo "Otros: Sangre / Orina " que el médicopuede rellenar para indicar alguna información complementaria relacionada con dicho apartado.

OR_DIAG_OTROS : Guarda el valor del campo "Otros" del apartado de Orientación Diagnóstica. Elmédico lo puede rellenar para indicar alguna información complementaria relacionada con dichoapartado.

DIURESIS_HORA : Guarda el valor del campo diuresis en horas de una solicitud de bioquímica.

DIURESIS_ML : Guarda el valor del campo Diuresis en mililitros de una solicitud de bioquímica.


- 73 -




Si volvemos a ver la solicitud de Bioquímica (figura 34), observamos que para que el médico terminede rellenar la solicitud le falta por marcar las casillas que correspondan en los cuadros de “Petición porPerfiles”, “Orientación Diagnóstica” y “Determinaciones”.


– una solicitud tendrá uno o más perfiles:

– una solicitud tendrá una o más orientaciones diagnósticas:



TABLA II: PERFILES

Tabla que almacena las distintas "Peticiones por Perfiles" que existen.

En una solicitud de bioquímica muchas pruebas de laboratorio están agrupadas bajo un mismo perfil.De esta manera el médico puede solicitar todo un conjunto de pruebas con sólo marcar una casilla de"Petición por Perfiles" de la Solicitud de Bioquímica.

Por ejemplo: el perfil "cardíaco" incluye: glucosa, urea, creatinina, GOT, GPT, Na, k, LDH y CPK.

Está formada por dos columnas: el identificador y el nombre del Perfil.

ID_PERFIL : Es la clave primaria. Identifica a un Perfil.. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

D_PERFIL : La descripción del Perfil.

TABLA III: SOL_BIOQUIMICA_PERFILES

Tabla que almacena las casillas de "Petición por Perfil" que han sido seleccionadas en una solicitud debioquímica.


- una solicitud de bioquímica puede tener 0 o más perfiles y

- un perfil puede estar en 0 o más solicitudes de bioquímica

ID_SOLICITUD: Clave externa que forma parte de la clave primaria de la tabla. Identifica la solicitud debioquímica.

ID_PERFIL : Clave externa que forma parte de la clave primaria de la tabla. Identifica un perfil que hasido seleccionado en la solicitud de bioquímica.

TABLA IV: ORIENTACION_DIAGNOSTICA

Tabla que almacena las distintas Orientaciones Diagnósticas, como pueden ser: diabetes, insuficienciarespiratoria, neumonía, etc.

Está formada por dos columnas: el identificador y el nombre de la Orientación Diagnóstica.

ID_ORIENTACION_DIAGNOSTICA : Es la clave primaria. Identifica a la Orientación Diagnóstica. Alser de tipo SERIAL su valor se autoincrementará en uno por cada registro nuevo que se inserte.

D_ORIENTACION_DIAGNOSTICA : La descripción de la Orientación Diagnóstica

TABLA V: SOL_BIOQUIMICA_ORIENTACION_DIAG

Tabla que almacena las casillas de Orientación Diagnóstica que han sido seleccionadas en unasolicitud de bioquímica.

- 74 -





- una solicitud de bioquímica puede tener 0 o más Orientaciones Diagnósticas y

- una Orientación Diagnóstica puede estar en 0 o más solicitudes de bioquímica.


ID_ORIENTACION_DIAGNOSTICA : Orientación Diagnóstica que ha sido seleccionada en la solicitudde bioquímica.

TABLA VI: DETERMINACIONES_BIOQUIMICA

Tabla que almacena las Determinaciones de Bioquímica. Una determinación de bioquímica puedeestar asociada a 1 o más pruebas de laboratorios (esto es, uno o más registros de la tablaParámetros).

Está formada por dos columnas: el identificador y el nombre de la determinación.

Ejemplos de determinaciones: Glucosa, Creatinina, urea, etc.

ID_DETERMINACION_BIOQUIMICA : Es la clave primaria. Identifica a una Determinación. Al ser detipo SERIAL su valor se autoincrementará en uno por cada registro nuevo que se inserte.

D_DETERMINACION : La descripción de la determinación de bioquímica.

TABLA VII: SOL_BIOQUIMICA_DET_BIOQUIMICA

Tabla que almacena las casillas de Determinaciones que han sido seleccionadas en una solicitud debioquímica.


- una solicitud de bioquímica puede tener 0 o más determinaciones y

- una determinación puede estar en 0 o más solicitudes de bioquímica.


ID_DETERMINACION_BIOQUIMICA : Clave externa que forma parte de la clave primaria de la tabla.Identifica una Determinación que ha sido seleccionada en la solicitud de bioquímica.

Con las tablas que hemos visto hasta aquí seríamos capaces de almacenar toda la información deuna solicitud de Bioquímica. Ahora queda ver cómo está organizada la parte que se encarga dealmacenar los resultados de una solicitud dados por los laboratorios.



- 75 -




figura 36: Diagrama para el almacenamiento de los resultados de Laboratorio del Departamento de Bioquímica


TABLA I: RESULTADOS_BIOQUIMICAS

En esta tabla se almacenan los resultados de una solicitud de bioquímica. Se almacena el valor, lafecha de medida y el código de laboratorio de cada resultado de la solicitud.


- una solicitud de bioquímica puede tener 0 o más parámetros (pruebas de laboratorio) y

- un parámetro puede estar en 0 o más solicitudes de bioquímica.

ID_SOLICITUD : Clave externa que forma parte de la clave primaria de la tabla. Identifica la solicitudde bioquímica.







Para identificar las pruebas de laboratorio se usa la propia codificación del laboratorio, esto es la claveprimaria ID_PARAMETRO. Por cada prueba se guarda también el número LOINC asociado (soncódigos universales).

Dada la importancia y complejidad de esta tabla se analizará aparte en el apartado 3.4.2.3

Por último, hemos añadido unas relaciones más en el diagrama de Bioquímica para la creaciónautomática de la hojas de resultados que tiene que rellenar el laboratorio. La idea es crear una relacióntal que a partir de los perfiles y determinaciones que ha rellenado el médico podamos saber quepruebas de laboratorios deben rellenar los laboratorios.

- 76 -




figura 37: Diagrama para que relaciona los Perfiles y las Determinaciones con los Resultadosde laboratorio.

En resumen:

– un perfil puede estar asociado a 1 o más pruebas de laboratorios (esto es, uno o más registros dela tabla Parámetros).

– una determinación puede estar asociada a 1 o más pruebas de laboratorios (esto es uno o másregistros de la tabla Parámetros).

Para modelar estas relaciones disponemos de las siguientes tablas:

TABLA III: PERFILES_PARAMETROS

En esta tabla almacenamos la correspondencia que existe entre una "Petición por Perfil" y los distintos"parámetros" que tiene asociado. ( Nota: un parámetro es una prueba de laboratorio o, en terminologíaLOINC, un resultado u observación clínica).


- un perfil puede tener 0 o más parámetros y

- un parámetro puede estar en 0 o más perfiles

ID_PERFIL: Clave externa que forma parte de la clave primaria de la tabla. Identifica un Perfil.


TABLA IV: DET_BIOQUIMICA_PARAMETROS

En esta tabla almacenamos la correspondencia que existe entre una "Determinación" y los distintos"parámetros" que tiene asociado.( Nota: un parámetro es una prueba de laboratorio o, en terminologíaLOINC, un resultado u observación clínica).


- una determinación puede tener 0 o más parámetros y

- un parámetro puede estar en 0 o más determinaciones

- 77 -




ID_DETERMINACION_BIOQUIMICA: Clave externa que forma parte de la clave primaria de la tabla.Identifica una Determinación de Bioquímica.


TABLA V: PARAMETROS



- 78 -




III Subdiagrama: Solicitud de Microbiología y Epidemiología infecciosa

En el diagrama de la figura 38 se encuentran las entidades y relaciones necesarias para almacenarlas solicitudes de pruebas de laboratorio y los resultados de laboratorio generados por elDepartamento de Microbiología y Epidemiología Infecciosa. Se aconseja que se consulte estediagrama a medida que se van explicando las entidades y las relaciones. No obstante, y para que seamás cómodo seguir las explicaciones, se irán poniendo pequeños diagramas donde se veránreflejadas las entidades y relaciones que se expliquen en cada momento.

figura 38: Diagrama de Microbiología y Epidemiología Infecciosa

Para empezar podemos ver en el diagrama de la figura 38 que una persona tendrá cero o mássolicitudes de Microbiología y Epidemiología Infecciosa asociadas, mientras que una solicitud deMicrobiología y Epidemiología Infecciosa sólo podrá pertenecer a una persona. También podemos veresta relación en la siguiente figura.

- 79 -




figura 39:Relación entre las entidades PERSONAS y SOLICITUDES_MICROBIOLOGIA

Por cada una de estás solicitudes se tendrá que guardar tanto el informe de solicitud (figura 40)que rellena el médico como la hoja de resultados que se rellena en el laboratorio.


Para comprender mejor cual es la información que se debe guardar de una solicitud de Microbiologíay Epidemiología Infecciosa vamos a ver el informe que debe rellenar el médico(figura 40) así como lasentidades y relaciones que modelan este proceso (figura 41 ):

figura 40: Informe de Solicitud del Servicio de Microbiología y Epidemiología Infecciosa

- 80 -




figura 41: Diagrama para el almacenamiento del Informe de Solicitud del Departamento de Microbiología y Epidemiología Infecciosa



En la tabla SOLICITUDES_MICROBIOLOGIA vamos a guardar:


• Código médico, centro y número de consulta que se pueden ver en el lateral izquierdo de lasolicitud (Código médico, número de habitación y número de cama si se trata de una“Hospitalización”).

• Los campos “otros” donde el médico puede hacer comentarios, éstos se pueden observar en loscuadros de “Tipos de Muestra” y de “Determinaciones”.

• Fecha y hora de toma y si es intrahospitalario o extrahospitalario (cuadro de arriba a la izquierda).


Para que el médico termine de rellenar la solicitud le faltaría por marcar las casillas quecorrespondan en los cuadros de “Tipos de Muestra” y “Determinaciones”.

Esto se modela con la siguientes relaciones:

– Una solicitud tendrá un Tipo de Muestra: para esto se han añadido la tabla TIPOS_DE_MUESTRA

– una solicitud tendrá cero o más determinaciones: para esto se han añadido las tablasSOL_MICRO_DET_MICRO y DETERMINACIONES_MICRO.


TABLA I: SOLICITUDES_MICROBIOLOGIA

Esta tabla almacenará todas las solicitudes de Microbiología y Epidemiología Infecciosa emitidas porlos médicos. Está relacionada con la tabla persona mediante la clave externa ID_PERSONA, de talmanera que una persona pueda tener 0 o más solicitudes de bioquímica.

- 81 -




ID_SOLICITUD : Es la clave primaria. Identifica una solicitud de Microbiología y EpidemiologíaInfecciosa.

ID_PERSONA : Clave externa, con ella expresamos la siguiente relación con la tabla Personas:

– una persona puede tener 0 o más solicitudes de Microbiología y Epidemiología Infecciosa

– una solicitud de Microbiología y Epidemiología Infecciosa sólo puede ser de una persona

ID_CLASE_CONSULTA : Clave externa. Identifica la clase de consulta: 1 si es una "consulta externa"y 2 si es una "hospitalización". Según del caso de que se trate se deberán guardar distintos campos enla tabla de SOLICITUDES_MICROBIOLOGIA:

– En el caso de que se trate de una "Consulta Externa" se deberán de almacenar los campos"centro" y el "número de la consulta" donde se realiza la cita.

– Si por el contrario se trata de una "hospitalización" se deberán almacenar el "Número deHabitación" y el "Número de la Cama".


ID_CENTRO : Clave externa. Indica el código del centro donde se ha realizado la cita con el paciente.Sólo se rellena en el caso de que sea una “Consulta Externa” (ID_CLASE_CONSULTA=1) y no unahospitalización.

FECHA_DE_SOLICITUD : Guarda la fecha en la que el médico envía la solicitud de Microbiología yEpidemiología Infecciosa.

INTRAHOSP_EXTRAHOSP : Puede tomar dos valores: "INTRAHOSPITALARIO" o"EXTRAHOSPITALARIO" según del caso que se trate.

CONSULTA : Guarda el número de la consulta donde se ha producido una cita. Sólo se rellena en elcaso de que sea una consulta externa (ID_CLASE_CONSULTA=1) y no una hospitalización.





– Valdrá false mientras que sea una "Solicitud Pendiente", es decir, el médico ha enviado la solicituda los laboratorios pero aún no se han terminado de rellenar los resultados o incluso no se haempezado.

FECHA_TOMA : Es un tipo Date. Almacena la fecha de la toma.

HORA_TOMA : Hora de la toma.

MINUTOS_TOMA : Minutos de la toma.

NUMERO_HISTORIA_CLINICA : Almacena el número de la historia clínica.

OTROS_TIPO_MUESTRA : Campo "otros" donde el médico puede guardar alguna observación delapartado "Tipos de Muestra" de la solicitud de Microbiología y Epidemiología Infecciosa.

OTROS_SEROLOGIA : Campo "otros" donde el médico puede guardar alguna observación sobre elgrupo de serología del apartado determinaciones de una solicitud de Microbiología y EpidemiologíaInfecciosa.

OTROS_VIRUS : Campo "otros" donde el médico puede guardar alguna observación sobre el grupo devirus del apartado determinaciones de una solicitud de Microbiología y Epidemiología Infecciosa.

- 82 -




OTROS_DIAG_MOLECULAR : Campo "otros" donde el médico puede guardar alguna observaciónsobre el grupo de Diagnóstico Molecular del apartado determinaciones de una solicitud deMicrobiología y Epidemiología Infecciosa.

OTROS_EPIDEMIOLOGIA : Campo "otros" donde el médico puede guardar alguna observación sobreel grupo de epidemiología del apartado determinaciones de una solicitud de Microbiología yEpidemiología Infecciosa.

CHECK_OR_DIAGNOSTICA : Valor booleano. Guarda si se ha marcado la casilla de "ORIENTACIONDIAGNÓSTICA / COMENTARIOS MUESTRA" de una solicitud de Microbiología y EpidemiologíaInfecciosa.


ID_TIPO_MUESTRA : Clave externa que almacena el tipo de muestra que se ha seleccionado en lasolicitud de Microbiología y Epidemiología infecciosa.

Modela la siguiente relación:

- Una solicitud tendrá un tipo de muestra.

- Un tipo de muestra puede estar en una o más solicitudes.

Si volvemos a ver la solicitud de Microbiología y Epidemiología Infecciosa (figura 39), observamosque para que el médico termine de rellenar la solicitud le falta por marcar las casillas que correspondanen los cuadros de “Tipos de Muestra” y “Determinaciones”.


– Una solicitud tendrá un Tipo de Muestra ( se almacena en el campo ID_TIPO_MUESTRA queacabamos de ver en la tabla SOLICITUDES_MICROBIOLOGIA).



TABLA II: TIPOS_DE_MUESTRA

Tabla que almacena los distintos Tipos de Muestra, como pueden ser: orina,plasma,sangre, etc.

ID_TIPO_MUESTRA : Es la clave primaria. Identifica a los Tipos de Muestra. Al ser de tipo SERIAL suvalor se autoincrementará en uno por cada registro nuevo que se inserte.

D_MUESTRA : La descripción del Tipo de Muestra.

TABLA III: DETERMINACIONES_MICROBIOLOGIA

Tabla que almacena las Determinaciones de Microbiología y Epidemiología Infecciosa. como puedenser : Tinción Gram,Cultivo, etc.

ID_DETERMINCACION_MICROBIOLOGIA : Es la clave primaria. Identifica a una Determinación. Alser de tipo SERIAL su valor se autoincrementará en uno por cada registro nuevo que se inserte.

D_DETERMINCACION_MICROBIOLOGIA : La descripción de la Determinación.

TABLA IV: SOL_MICRO_DET_MICRO

Tabla que almacena las casillas de Determinaciones que han sido seleccionadas en una solicitud deMicrobiología y Epidemiología Infecciosa.

- 83 -




ID_SOLICITUD: Clave externa que forma parte de la clave primaria de la tabla. Identifica la solicitud deMicrobiología y Epidemiología Infecciosa.

ID_DETERMINCACION_MICROBIOLOGIA : Clave externa que forma parte de la clave primaria de latabla. Identifica una Determinación que ha sido seleccionada en la solicitud de Microbiología yEpidemiología Infecciosa.

Con las tablas que hemos visto hasta aquí seriamos capaces de almacenar toda la información deuna solicitud de Microbiología y Epidemiología Infecciosa. Ahora queda ver cómo está organizada laparte que se encarga de almacenar los resultados de una solicitud dados por los laboratorios.



figura 42: Diagrama para el almacenamiento de los resultados de Laboratorio del Departamento de Microbiología y Epidemiología Infecciosa


TABLA I: RESULTADOS_MICROBIOLOGIA

En esta tabla se almacenan los resultados de una solicitud de Microbiología y EpidemiologíaInfecciosa. Se almacena el valor, la fecha de medida y el código de laboratorio de cada resultado de lasolicitud.


- una solicitud de Microbiología y Epidemiología Infecciosa puede tener 0 o más parámetros (pruebasde laboratorio) y

- un parámetro puede estar en 0 o más solicitudes de Microbiología y Epidemiología Infecciosa.

ID_SOLICITUD : Clave externa que forma parte de la clave primaria de la tabla. Identifica la solicitudde Microbiología y Epidemiología Infecciosa.




- 84 -







Para identificar las pruebas de laboratorio se usa la propia codificación del laboratorio, esto es la claveprimaria ID_PARAMETRO. Por cada prueba se guarda también el número LOINC asociado (soncódigos universales).

Dada la importancia y complejidad de esta tabla se analizará aparte en el apartado 3.4.2.3 (página 89).

Por último, hemos añadido una relación más en el diagrama de Microbiología y EpidemiologíaInfecciosa para la creación automática de la hojas de resultados que tiene que rellenar el laboratorio.La idea es crear una relación tal que a partir del tipo de muestra y las determinaciones que harellenado el médico podamos saber que pruebas de laboratorios deben rellenar los laboratorios.

figura 43: Diagrama para que relaciona el Tipo de Muestra y las Determinaciones con losResultados de laboratorio.

TABLA III: MUESTRADET_PARAMETROS

En esta tabla almacenamos la correspondencia que existe entre un "Tipo de Muestra" y"Determinación" con los distintos "parámetros" que tiene asociado. ( Nota: un parámetro es una pruebade laboratorio o, en terminología LOINC, un resultado u observación clínica).

En el formulario de Microbiología y Epidemiología infecciosa el médico podrá marcar:

- 1 tipo de muestra

- 1 o más determinaciones.

- 85 -




Un "Tipo de Muestra" y una "Determinación" podrán tener 0 o más parámetros

ID_TIPO_MUESTRA: Identifica al tipo de muestra. Es una clave externa que pertenece a la claveprimaria.

ID_DETERMINCACION_MICROBIOLOGIA : Identifica a la determinación. Es una clave externa quepertenece a la clave primaria.

ID_PARAMETRO : Identifica al parámetro (resultado o prueba de laboratorio). Es una clave externaque pertenece a la clave primaria.

TABLA IV: PARAMETROS



- 86 -




IV Tablas comunes de los diagramas de solicitudes

Vamos a explicar una serie de tablas que son comunes a los tres tipos de solicitudes, y aunque sehan ido viendo en los distintos diagramas aún no se han explicado. Estas tablas se pueden ver en lasiguiente figura:

figura 44: Tablas comunes a todas las solicitudesHemos cogido como ejemplo una solicitud de hematología y hemoterapia pero se podría haber

escogido cualquier otra. Las tablas que son comunes se han puesto con un color de fondo blanco.

Pasamos a detallar ahora las distintas tablas:

TABLA I: PERSONAS

Esta tabla almacena todos los datos relativos a una persona.

ID_PERSONA : Es la clave primaria. Identifica a la persona. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

NOMBRE : Nombre de la persona

APELL1 : Primer Apellido de la persona.

APELL2 : Segundo Apellido de la persona

FECHA_NACIMIENTO : Fecha de nacimiento de la persona.

NIF : Guarda el NIF (Número de Identificación Fiscal) de la personas. Estará compuesto por 8números y una letra.

NUMERO_SEGURIDAD_SOCIAL : Guarda el número de la seguridad social.

TARJETA_SANITARIA : Guarda el número de la tarjeta sanitaria.

SEXO : Guarda el sexo de la persona. Puede tomar 2 valores: "HOMBRE" o "MUJER"

TABLA II: CLASES_DE_CONSULTAS

Tabla que contiene las dos clases de consultas que modela la aplicación. Puede tomar dos valores:

- 87 -




- "CONSULTA EXTERNAS ESPECIALIDADES" si id_clase_consulta=1

- "HOSPITALIZACION" si id_clase_consulta=2

ID_CLASE_CONSULTA : Clave primaria. Identifica a la clase de consulta.

D_CLASE_DE_CONSULTA : Descripción de la consulta. Existirán dos clases de consultas.

– CONSULTA EXTERNAS ESPECIALIDADES

– HOSPITALIZACION

TABLA III: MEDICOS

Esta tabla almacena todos los datos relativos a un médico.

ID_MEDICO : Es la clave primaria. Identifica a un médico. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

NOMBRE : Nombre del médico

APELL1 : Primer Apellido del médico

APELL2 : Segundo Apellido del médico

FECHA_NACIMIENTO :Fecha de nacimiento del médico

NIF : Guarda el NIF (Número de Identificación Fiscal) del médico. Estará compuesto por 8 números yuna letra.

SEXO : Guarda el sexo del médico. Pude tomar 2 valores: "HOMBRE" o "MUJER"

CODIGO_MEDICO : Guarda el código que se le ha asignado al médico.

TABLA IV: CODIGO_CENTROS

Tabla que guarda los códigos de los centros y los nombres de los centros.

ID_CENTRO : Clave primaria. Es el código del centro.

D_CENTRO : Almacena el nombre del centro.

TABLA V: LABORATORIOS

Almacena los códigos de los laboratorios que realizan las pruebas y sus respectivos nombres.

ID_LABORATORIO : Es la clave primaria. Identifica a los laboratorios. Al ser de tipo SERIAL su valorse autoincrementará en uno por cada registro nuevo que se inserte.

D_LABORATORIO : El nombre del laboratorio.

- 88 -




3.4.2.3. Diagrama de Parámetros La tabla de Parámetros también es común a los tres tipos de solicitudes, pero dada su “relativa

complejidad” se ha preferido explicar en un diagrama aparte.

figura 45: Diagrama de PARAMETROS

La tabla principal es la tabla “PARAMETROS”, esta tabla almacena toda la información relativa a lasdistintas pruebas de laboratorios que existen en el sistema de información.

La estructura de esta tabla está en base a la propia estructura LOINC, así por ejemplo, una prueba delaboratorio podrá ser identificada a partir de seis campos: componente,propiedad,aspecto temporal,sistema, tipo de escala y tipo de método. Para guardar toda esta información se han tenido que creauna nueva tabla para cada campo para así poder cumplir hasta la 3ª forma normal en el diseño de labase de datos.

Lo mismo ocurre con los campos: class, grupo y unidades de medida, en las que también se hancreado las correspondientes tablas para poder cumplir hasta la 3ª forma normal.

Es importante recalcar que, aunque la clave primaria, ID_PARAMETRO, es quién identifica la pruebade laboratorio, también existe otro campo LOINC_NUM donde se guardará el número LOINC quecorresponde a dicha prueba y por lo tanto éste campo también será único y sería una clave candidataa clave primaria.

TABLA I: PARAMETROS

Tabla que almacena las distintas Pruebas de laboratorio que se pueden hacer en el laboratorio. Dondeuna prueba de laboratorio será un resultado de laboratorio u observación clínica.

Para identificar las pruebas de laboratorio se usa la propia codificación del laboratorio, esto es, la claveprimaria ID_PARAMETRO. Por cada prueba se guarda también el número LOINC que le corresponda(son códigos universales).

La tabla está pensada en base a la estructura LOINC, por eso también se puede especificar unaprueba de laboratorio a partir de los siguientes seis campos:

- COMPONENTE (componente)

- ID_PROPIEDAD (Propiedad medida)

- 89 -




- ID_ASPECTO_TEMPORAL (Aspecto temporal)

- ID_SISTEMA (Tipo de muestra)

- ID_ESCALA (Tipo de escala)

- ID_TIPO_METODO (Método usado para producir el resultado u otra observación)

Aunque estos campos cumplen la misma función que en LOINC, se da llibertad al Laboratorio pararellenarlo siguiendo sus propias notaciones o reglas internas. Lo importante es que de cada prueba delaboratorio se guarde correctamente el número LOINC que le corresponde.

También se han añadido otros campos importantes muy utilizados por los laboratorios, entre los quese encuentran la unidad de medida (ID_UNIDAD) y el límite superior e inferior (HI_BOUND yLO_BOUND) que marcan los rangos normales de un resultado de laboratorio.

ID_PARAMETRO :Es la clave primaria. Identifica a los Parámetros. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

LOINC_NUM : El número LOINC del resultado u observación clínica.

COMPONENTE : Componente de la Prueba de Laboratorio.

ID_PROPIEDAD : Clave externa. Identifica la Propiedad.

ID_ASPECTO_TEMPORAL : Clave externa. Identifica el Aspecto Temporal.

ID_SISTEMA : Clave externa. Identifica el Sistema.

ID_ESCALA : Clave externa. Identifica la Escala.

ID_TIPO_METODO : Clave externa. Identifica el Tipo de Método.

ID_CLASS : Clave externa. Identifica la Clase.

ID_GRUPO : Clave externa. Identifica el Grupo.

MEDIA : Valor medio de los resultados.

HI_BOUND : Limite superior. Si el valor del resultado es mayor que este límite se considera que estafuera del rango normal de valores.

LO_BOUND : Limite inferior. Si el valor del resultado es menor que este límite se considera que estafuera del rango normal de valores.

ID_UNIDAD : Indican la unidad de medida del parámetro utilizada por el laboratorio.

TABLA II: PROPIEDADES

Tabla que almacena las propiedades que se pueden observar en una muestra, por ejemplo:concentración de masa (MCNC) , concentración de substancia (SCNC)

ID_PROPIEDAD : Es la clave primaria. Identifica una Propiedad. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

D_PROPIEDAD : La descripción de la Propiedad, la notación utilizada se ha obtenido de LOINC

DISPLAY_PROPIEDAD : Traducción al español de la descripción de la Propiedad.

TABLA III: ASPECTO_TEMPORAL

Tabla que almacena los distintos aspectos temporales que se pueden tener en un resultado uobservación clínica. Puede ser un punto en el tiempo (PT) o intervalo de tiempo (7h, 2h, etc).

ID_ASPECTO_TEMPORAL : Es la clave primaria. Identifica a un Aspecto Temporal. Al ser de tipoSERIAL su valor se autoincrementará en uno por cada registro nuevo que se inserte.

- 90 -




D_ASPECTO_TEMPORAL : La descripción del Aspecto Temporal, la notación utilizada se ha obtenidode LOINC.

TABLA IV: SISTEMAS

Tabla que almacena los distintos sistemas que se pueden tener en un resultado u observación clínica.Es la muestra que vamos a utilizar para la medición, por ejemplo si es sangre,orina,etc.

ID_SISTEMA : Es la clave primaria. Identifica a un Sistema. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

D_SISTEMA : La descripción del Sistema, la notación utilizada se ha obtenido de LOINC.

DISPLAY_SISTEMA : Traducción al español de la descripción del Sistema.

TABLA V: TIPO_ESCALAS

Tabla que almacena los distintos tipos de escalas que se pueden tener en un resultado u observaciónclínica. Ejemplos de escalas usadas para la medición son: cuantitativa (QN), Ordinal (ORD) Nominal(NOM), etc.

ID_ESCALA : Es la clave primaria. Identifica a un Tipo de Escala. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

D_ESCALA : La descripción del Tipo de Escala, la notación utilizada se ha obtenido de LOINC.

DISPLAY_ESCALA : Traducción al español de la descripción de la propiedad.

D_LARGA_ESCALA : Explicación detallada del Tipo de Escala.

TABLA VI: TIPO_METODOS

Tabla que almacena los distintos métodos usados para producir un resultado u observación clínica. Esel método en particular por el cual fue realizado el test.

ID_TIPO_METODO : Es la clave primaria. Identifica a un Tipo de Método. Al ser de tipo SERIAL suvalor se autoincrementará en uno por cada registro nuevo que se inserte.

D_TIPO_METODO : La descripción del Tipo de Método, la notación utilizada se ha obtenido de LOINC

DISPLAY_TIPO_METODO : Traducción al español de la descripción del Tipo de Método.

D_LARGA_TIPO_METODO : Explicación detallada del Tipo de Método.

TABLA VII: CLASS

Tabla que almacena distintos grupos en los que se pueden clasificar las pruebas de laboratorios. Esuna clasificación arbitraria, se podría haber elegido otra.

ID_CLASS : Es la clave primaria. Identifica a una Clase. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

D_CLASS : La descripción de la Clase

DISPLAY_CLASS : Traducción al español de la descripción del tipo de clase.

TABLA VIII: GRUPO

Tabla que almacena distintos grupos en los que se pueden clasificar las pruebas de laboratorios. Esuna clasificación arbitraria, se podría haber elegido otra.

Puede haber tres grupos distintos:

- bioquímica (id_grupo = 1).

- microbiología y epidemiología infecciosa (id_grupo = 2).

- 91 -




- hematología y hemoterapia(id_grupo = 3).

ID_GRUPO : Es la clave primaria. Identifica a un Grupo. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

D_GRUPO : La descripción del Grupo.

TABLA IX: UNIDADES_MEDIDA

Tabla que almacena las distintas unidades de medida en que se pueden medir un resultado delaboratorio. Ejemplos: mg (miligramos), mg/dl (miligramos por decilitros).

ID_UNIDAD : Es la clave primaria. Identifica a una Unidad de Medida. Al ser de tipo SERIAL su valorse autoincrementará en uno por cada registro nuevo que se inserte.

D_UNIDAD : La descripción de la Unidad.

- 92 -




3.4.2.4. Diagrama de Acceso al Sistema Mostramos ahora los diagramas que modela el acceso al sistema:

figura 46: Diagramas de Acceso al Sistema

TABLA I: USUARIOS

Tabla que almacena los distintos usuarios que pueden acceder al sistema.

ID_USUARIO : Es la clave primaria. Identifica al usuario. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

USUARIO : Nombre del usuario. Este campo es de tipo UNIQUE por lo que no se podrá repetir.

PASSWORD : Contraseña del usuario.

ID_TIPO_USUARIO : Clave externa. Identifica cual es el Tipo de Usuario del usuario que accede alsistema.

TABLA II: TIPOS_USUARIO

Tabla que almacena a los distintos Tipos de Usuarios que acceden al sistema.

Un usuario tendrá asociado un tipo de usuario.

Cada tipo de usuario tendrá una serie de permisos que le permitirán acceder a los distintossubsistemas del sistema de gestión.

ID_TIPO_USUARIO : Es la clave primaria. Identifica al tipo de usuario. Al ser de tipo SERIAL su valorse autoincrementará en uno por cada registro nuevo que se inserte.

D_TIPO_USUARIO : Nombre que describe al tipo de usuario.

TABLA III: TIPOS_USUARIO_SUBSISTEMAS

En esta tabla almacenamos la correspondencia que existe entre una "Tipo de Usuario" y los distintos"subsistemas" a los que puede acceder.


- un Tipo de Usuario puede acceder a 0 o más subsistemas y

- un subsistema puede estar en 0 o más Tipos de Usuarios.

- 93 -




ID_TIPO_USUARIO : Clave externa que forma parte de la clave primaria de la tabla. Identifica un Tipode Usuario.

ID_SUBSISTEMA : Clave externa que forma parte de la clave primaria de la tabla. Identifica unsubsistema

TABLA IV: SUBSISTEMAS

Tabla que almacena a los distintos subsistemas a los que se pueden acceder en el sistema de gestiónde laboratorios.

Cada tipo de usuario tendrá una serie de permisos que le permitirán acceder a los distintossubsistemas del sistema de gestión.

El sistema se va a dividir en cuatro módulos, éstos son:

– módulo de médicos

– módulo de laboratorios

– módulo de enfermeros

– módulo de administrador.

La idea es que cada módulo esté compuesto por subsistemas, aunque actualmente sólo existe unsubsistema por cada módulo por lo que módulo y subsistema son coincidentes.

ID_SUBSISTEMA : Es la clave primaria. Identifica al subsistema. Al ser de tipo SERIAL su valor seautoincrementará en uno por cada registro nuevo que se inserte.

D_SUBSISTEMA : Descripción del subsistema.

- 94 -




3.5. Diseño del flujo de la aplicaciónEs muy importante hacer un buen estudio de la navegabilidad del sistema. Hay que dejar bien claro

desde qué páginas podremos acceder a otras.

Uno de los objetivos principales de nuestro proyecto es lograr que la adaptación de los usuarios anuestro sistema no suponga ningún trauma. Hemos de recordar que los usuarios están acostumbradosa realizar las tareas en formato papel y es poco probable que acepten un cambio brusco en su manerade trabajar.

La manera más lógica de cumplir este objetivo es haciendo que el flujo de la aplicación permitasolucionar los problemas tal y como se hacían en papel. Para ello se ha estudiado con gran interés lamanera de actuar de cada uno de los usuarios, es decir, que pasos y en que orden van realizando sustareas.

Otro objetivo a cumplir es que la aplicación sea cómoda y fácilmente navegable, permitiendo alusuario ir de un lado a otro rápidamente y sin perderse.

Los usuarios principales de nuestra aplicación son:

– médicos

– enfermeros

– laboratorios

– administradores

Las tareas que debe realizar cada usuario son distintas, por ello cada uno tendrá su propia vistasobre el sistema. Para saber como interactúa el sistema con cada uno de los actores nos ayudaremosde los diagramas de casos de uso (página 35) que explicamos en el estudio del negocio.

- 95 -




3.5.1. Acceso al sistema: caso de uso “Validación en el sistema” Todos los actores tendrán que validarse para poder acceder al sistema. Por ello, la página de

validación siempre será la primera página a la que se accederá cuando nos conectemos con elSistema de Gestión de Laboratorios.

En esta página aparecerá un formulario donde el usuario deberá introducir su “usuario” y su“password”.

Figura 47: Pantalla de Validación

Se podrán realizar dos acciones:

• "Enviar": valida al usuario • "Limpiar": limpia los datos que aparecen por pantalla

Una vez enviado el formulario se comprobará si existe dicho usuario en el sistema.

Si la validación es correcta, el siguiente paso es comprobar qué permisos tiene el usuario sobre elsistema, estos permisos vendrán dados por el “tipo de usuario” que tenga asociado.

Dicho de otra manera, un usuario tendrá asociado un “tipo de usuario” y cada “tipo de usuario”tendrá una serie de permisos que le permitirán acceder a los distintos subsistemas del sistema degestión.

Una vez validado,el usuario dispondrá de un menú con enlaces a cada uno de los subsistemas a losque tenga permiso. Este menú estará siempre accesible desde la banda vertical azul que aparece a laizquierda de la pantalla (ver por ejemplo la figura 49)

El sistema se va a dividir en cuatro módulos, éstos son:

– módulo de médicos

– módulo de laboratorios

– módulo de enfermeros

– módulo de administrador.

La idea es que cada módulo esté compuesto por subsistemas, aunque actualmente sólo existe unsubsistema por cada módulo por lo que módulo y subsistema son coincidentes.

- 96 -




3.5.2. Tratamiento de las Excepciones El tratamiento de las excepciones siempre es el mismo en toda la aplicación, por lo que sólo lo

explicaremos en este apartado, aunque será aplicable a todos los procesos que vayamos explicandoen adelante.

Distinguiremos entre dos tipos de excepciones.

➢ Excepción al validar un formulario

➢ Excepción en la lógica de negocio

3.5.2.1. Excepción al validar un formulario Cuando se rellena un formulario y se solicita una acción, lo primero que hace el sistema es validar si

se han introducido los datos correctamente de acuerdo con la acción solicitada.

Si el usuario no ha rellenado bien el formulario, aparecerá otra vez la misma página del formulariopero con un mensaje en color rojo explicando cual ha sido el motivo del error.

En la siguiente figura el usuario ha querido enviar el formulario sin haber rellenado el campoobligatorio “password”:

Figura 48: Error al validar un formulario

Veamos otro ejemplo en el que al buscar un paciente por el DNI se introduce mal dicho campo:

Figura 49: Error al validar un formulario

- 97 -




3.5.2.2. Excepción en la lógica de negocio Si el formulario se rellenó correctamente pero se produce un error en la lógica de negocio se

redirigirá a la página de error.

En la página de error aparecerá un mensaje descriptivo del error que se ha producido:

Figura 50: Página de errorComo se puede ver, en la pantalla de error siempre existe la posibilidad de volver a la página

anterior.

- 98 -




3.5.3. Actor Médico Los casos de uso para el actor Médico son:

Figura 51: Casos de uso del actor Médico

Vamos a ir explicando el flujo de la aplicación a la vez que lo relacionamos con los casos de uso queva implementando.

3.5.3.1. Caso de Uso “Elegir Paciente”: A esta página (página de pacientes figura 52) se podrá acceder desde el enlace “Pacientes” que

aparece en el menú de la izquierda.

Figura 52: Página de Pacientes

Las posibles acciones que puede realizar son:

• "ALTA": Da de alta a una persona. • "CONSULTA": Muestra una lista de las personas que cumplen con los requisitos de la búsqueda,

es decir, buscará a las personas cuyos datos coinciden con los datos rellenados en el formulario de"Ficha del Paciente".

• "NUEVO PACIENTE": Limpia los datos de la pantalla para permitir la búsqueda de un nuevopaciente

• "ACTUALIZAR": Actualiza los datos del paciente (Este botón aparecerá una vez encontrado elpaciente).

- 99 -




• "BAJA": Borra el registro del paciente del sistema (Este botón aparecerá una vez encontrado elpaciente)

I Acción ALTA

El usuario rellenará correctamente todos los campos y pulsará el botón alta. Si no hay ningún falloaparecerá otra vez la página de pacientes pero con un mensaje de estado indicando que se le ha dadode alta a la persona.

II Acción CONSULTA

Lo más normal es que lo primero que haga un médico cuando le llega un paciente sea buscar laficha del paciente en el sistema, esta búsqueda la puede realizar por el dni, el número de la seguridadsocial, o cualquier otro campo. Luego se mostrará la lista de las personas (figura 53) que cumplen conlos requisitos de la búsqueda:

Figura 53: Página lista de PacientesSi en la lista de pacientes de la figura 53 aparece la persona buscada, el médico sólo tendrá que

pulsar sobre ella e inmediatamente se volverá a la página pacientes pero con todos los datos delpaciente rellenos y con un nuevo menú dentro del cuadro “Historial de Laboratorio del Paciente” (figura54).

Figura 54: Página Pacientes una vez encontrado al pacienteVemos que el cuadro “Historial de Laboratorio del Paciente” está divido en los tres departamentos de

laboratorios que hay:

- 100 -




• Bioquímica

• Hematología y Hemoterapia

• Microbiología y Epidemiología infecciosa

Para cada uno de ellos tendremos un menú que nos dará acceso a distintos servicios. Estosservicios son:

– Enviar Solicitud (tanto para “Consultas Externas” como para “Hospitalización”).

– Consultar Solicitudes Pendientes.

– Consultar Solicitudes consolidadas.

Cada uno de estos tres servicios los describiremos en los siguientes casos de uso.

3.5.3.2. Caso de Uso “Enviar Solicitud de Prueba de Laboratorio” El médico podrá rellenar una solicitud con las pruebas de laboratorio que quiere que se le hagan al

paciente. Una vez rellenada la solicitud pasará a un estado de “Solicitud Pendiente” y estará disponiblepara los enfermeros y para el laboratorio.

A la hora de rellenar la solicitud el médico podrá elegir entre tres tipos de solicitudes:

• Solicitud de Bioquímica


• Solicitud de Microbiología y Epidemiología infecciosa

Veamos por ejemplo el caso de enviar una solic54tud de bioquímica (el enlace a esta página seencuentra en el menú “Historial de Pruebas de Laboratorio”, figura 54, sería pulsando sobre el enlace“Consulta Externas” de la parte de bioquímica):

Figura 55: Pagina solicitud de bioquímica

Se podrán realizar tres acciones:

• "ENVIAR": Guarda en la base de datos la solicitud actual como solicitud pendiente.

- 101 -




• "NUEVA SOLICITUD": Carga una nueva solicitud en pantalla.• "VOLVER": Vuelve a la página inicial del paciente.

I Acción ENVIAR

Una vez que el médico haya rellenado el formulario y le de al botón “Enviar” la solicitud quedarágrabada en la base de datos como solicitud pendiente pudiendo ser accedida desde ese momento porlos enfermeros y los laboratorios.

A igual que en todas las páginas que contienen un formulario, si el médico no rellena correctamentealguno de los campos, le aparecerá un mensaje de error indicando el motivo del error en la validación.

Si la solicitud se “Envía” y se graba correctamente se volverá otra vez a la página de la solicitud conun mensaje indicando “La solicitud ha sido enviada”. Esta página, como es lógico, ya no tendrá laopción “Enviar”, sólo “Volver” a la página paciente o rellenar una “Nueva Solicitud”.

Figura 56: Pagina solicitud de bioquímica (una vez enviada la solicitud)

3.5.3.3. Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio” El médico puede consultar las “Solicitudes Pendientes” que tiene su paciente actualmente. Las

“Solicitudes Pendientes” son aquellas solicitudes que el médico ha enviado al laboratorio pero cuyosresultados o parte de sus resultados están aún sin completar, es decir, el laboratorio aún no haterminado de rellenar la hoja de resultados.

Veamos por ejemplo el caso que se consulten las “Solicitudes Pendientes” de Bioquímica (el enlacese puede ver en la figura 54).

Para mostrar la solicitud pendiente el usuario debe dar una serie de pasos:

- 102 -




➢ PASO 1: El usuario indicará el rango de fechas en la que se encuentran las solicitudes pendientesque busca ( si no se introduce algún campo se supone que este campo no restringe la consulta) y ledará al botón “Consultar”.

➢ PASO 2: Saldrá por pantalla una lista con todas las solicitudes pendientes que se encuentren en elrango de fechas. Ahora el usuario deberá de pinchar sobre la solicitud que esté buscando.

➢ PASO 3: Aparecerá por pantalla la “Solicitud “Pendiente” seleccionada. Ahora le aparecerá unnuevo botón “Ver Datos” que permite al médico ver los datos introducidos en la hoja de resultados(se verá su funcionamiento en el punto 3.5.3.5)

Figura 57: Página Solicitud Pendiente Paso1 Figura 58: Pagina Solicitud Pendiente Paso2

Figura 59: Página Solicitud Pendiente Paso 3

- 103 -




En cualquier momento se podrá pulsar el botón “Volver Menú” que regresará a la página depacientes.

3.5.3.4. Caso de Uso “Consultar Solicitudes Consolidadas del Laboratorio”

El médico puede consultar las “Solicitudes Consolidadas” del paciente que son aquellas cuya hojasde resultados están completas, es decir, el laboratorio ya ha terminado de rellenar la solicitudcompletamente y los datos son definitivos.

Las páginas son exactamente igual a las descritas para “Solicitudes Pendientes”, con la diferenciaque ahora se mostrarán las “Solicitudes Consolidadas” en lugar de las “Solicitudes Pendientes”.

Si comparamos el código de las dos páginas jsp para los casos de “Solicitudes Pendientes” y“Solicitudes Consolidadas”, comprobaríamos que la única diferencia que hay en el código es que cadapágina jsp llama a un objeto Action distinto, así siguiendo el mismo ejemplo de solicitudes debioquímica:

– en “paginaSolicitudesPendientesBioquimica.jsp” se llama a la clase action“/controladorSolicitudesPendientesBioquimica.do” que se ocupará de llamar a la lógica de negocioque se encargue de buscar las solicitudes pendientes

– en “paginaSolicitudesConsolidadasBioquimica.jsp” se llama a la clase action“/controladorSolicitudesConsolidadasBioquimica.do” que se ocupará de llamar a la lógica denegocio que se encargue de buscar las solicitudes consolidadas.

3.5.3.5. Caso de Uso “Ver resultados de Solicitud” Extiende los dos casos de uso anteriores y permite al médico ver para cada solicitud los resultados

que estén rellenos. A esta página se llega pulsando el botón “Ver Datos” de la figura 59.

Figura 60: Página Resultados de una Solicitud

Para ayudar al médico a localizar los parámetros que no se encuentran dentro de los rangosnormales, éstos se han puesto de color rojo y seguidos del carácter asterisco “*”.

En esta página se podrán realizar dos acciones:

- 104 -




• Si el usuario presiona el botón “Aceptar” le devolverá a la página anterior, es decir, a la deSolicitudes Pendientes o Solicitudes Consolidadas, según desde donde se haya llamado.

• Si el médico pincha sobre algún parámetro, se abrirá una página donde le aparecerá informaciónadicional sobre la prueba que ha seleccionado. Esto implementa el caso de uso “Ver InformaciónPrueba”.

Figura 61: Página Ver Información de Prueba

Pulsando el botón “Volver” o el enlace “Volver a Resultados” se volverá a la página de resultadosde laboratorio.

- 105 -




3.5.4. Actor Enfermero Los casos de uso para el actor Enfermero son:

Figura 62: Casos de uso del actor Enfermero


3.5.4.1. Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio”: A esta página (página de enfermeros figura ) se podrá acceder desde el enlace “Enfermero” que


Figura 63: Página de Enfermeros

El enfermero podrá consultar las “Solicitudes Pendientes” que hay en el sistema, así, viendo laspruebas que hay que realizar al paciente, sabrá que muestras deberá coger del paciente (por ejemplo,una muestra de sangre, una muestra de orina, etc).

Se podrá consultar las solicitudes pendientes de los tres departamentos de laboratorios que hay:

• Bioquímica



Veamos por ejemplo el caso que se consulten las “Solicitudes Pendientes” de Microbiología yEpidemiología infecciosa (el enlace se puede ver en la figura 63).


- 106 -






➢ PASO 3: Aparecerá por pantalla la “Solicitud “Pendiente” seleccionada. También aparecerá unnuevo botón “Enviar Nº Muestra”, su uso se explicará en el Caso de Uso “Introducir Número deMuestra” (apartado 3.5.4.2).



- 107 -




En cualquier momento se podrá pulsar el botón “Volver” o el enlace “Volver Menú” para regresará ala página de enfermeros.

3.5.4.2. Caso de Uso “Introducir Número de Muestra” Una vez que se ha recogido la muestra del paciente, ésta se guardará en un tarro o tubo que luego

se enviará al laboratorio.

En un hospital lo que se suele hacer es pegar tanto al tubo como a la solicitud un código de barrascon el mismo número así el laboratorio puede saber a quien pertenece cada muestra.

En nuestra aplicación esto se ha solucionado permitiendo al enfermero rellenar el campo “Nº deMuestra” en la solicitud (en la parte superior derecha), el cual contendrá el número del código debarras que se haya pegado a la muestra.

Una vez que el enfermero haya rellenado el “Nº de muestra” la dará al botón “Enviar Nº Muestra”para que éste quede almacenado en la base de datos. Si todo ha ido bien aparecerá el siguientemensaje de estado: “Se ha actualizado el número de muestra”.

Figura 67: Actualización del número de muestra

- 108 -




3.5.5. Actor Laboratorio Los casos de uso para el actor Laboratorio son:

Figura 68: Casos de uso del actor Laboratorio


3.5.5.1. Caso de Uso “Consultar Solicitudes Pendientes del Laboratorio” A la página de Laboratorios (figura 69 se podrá acceder desde el enlace “Laboratorios” que


Figura 69: Página de Laboratorios

El Laboratorio podrá consultar las “Solicitudes Pendientes” que han recibido y que les queda porrellenar. Las “Solicitudes Pendientes” son aquellas solicitudes que el médico ha enviado al laboratoriopero cuyos resultados o parte de sus resultados están aún sin completar, es decir, el laboratorio aúnno ha terminado de rellenar la hoja de resultados.

Se podrá consultar las solicitudes pendientes de los tres departamentos de laboratorios que hay:

- 109 -




• Bioquímica



Veamos por ejemplo el caso que se consulten las “Solicitudes Pendientes” de Bioquímica (el enlacese puede ver en la figura 69).




➢ PASO 3: Se cargará en la pantalla la “Solicitud “Pendiente” seleccionada, a la vez que aparecerándos nuevos botones que nos permitirán realizar las siguientes acciones:

➢ “Ver Datos” que redirigirá a la página de resultados (se verá su funcionamiento en el punto 3.5.5.3)

➢ “Enviar Nº Muestra”, su uso se explicará en el Caso de Uso “Introducir Número de Muestra”(apartado 3.5.5.2).


- 110 -





En cualquier momento se podrá pulsar el botón “Volver” que regresará a la página de Laboratorios.

3.5.5.2. Caso de Uso “Introducir Número de Muestra” Aunque lo normal es que la muestra la recoja el enfermero también se puede dar el caso que lo

haga el laboratorio por lo que se le debe permitir la posibilidad de rellenar el campo “Nº de Muestra” dela solicitud, el cual contendrá el número del código de barras que se haya pegado a la muestra.

3.5.5.3. Caso de Uso “Introducir Resultados de Laboratorio” Para cada solicitud se le desplegará en laboratorio una “Hoja de Resultados”, en la que sólo

aparecerán aquellas pruebas de laboratorio que debe rellenar el laboratorio. Una “Hoja de Resultado”consistirá pues en un formulario donde el laboratorio introducirá para cada prueba el resultado medido.

A esta página se llegará tras pulsar el botón “Ver Datos” de la página de solicitudes pendientes(figura 72)

- 111 -




Figura 73: Página Resultados de LaboratorioEn esta página se pueden realizar las siguientes acciones:

• "VER SOLICITUD": Vuelve a la página de la solicitud pendiente seleccionada.

• "ENVIAR": Guarda en la base de datos los resultados que han sido rellenados. • "CONSOLIDAR": Guarda en la base de datos los resultados que han sido rellenados y consolida los

resultados de la solicitud. Se corresponde con el caso de uso “Consolidar Resultado” (verapartado 3.5.5.4).

• Otra acción se consigue pulsando sobre cualquier parámetro, se mostrará una página con lainformación de la prueba que se haya seleccionado. Ver apartado 3.5.5.5

• "AÑADIR PARAMETROS": Muestra página con una lista de todas las posibles pruebas. Es utilizadopor el laboratorio para añadir una prueba más a la lista de resultados de la solicitud. Ver apartado3.5.5.6

3.5.5.4. Caso de Uso “Consolidar Resultado” Una vez se haya terminado de rellenar la “Hoja de Resultados” el laboratorio podrá proceder a

consolidarla.

Una vez consolidados los resultados, éstos se harán definitivos y no se podrán volver a modificar, deesta manera hacemos que el estado de la solicitud pase de ser "Solicitud pendiente" a "SolicitudConsolidada". Esta acción sólo debe ser llamada una vez que tengamos introducidos todos los datosya que luego no podrán volver a ser modificados.

3.5.5.5. Caso de Uso “Ver Información Prueba” El laboratorio podrá ver también información adicional sobre una prueba con sólo pulsar sobre

cualquier parámetro de la “Hoja de Resultados” (figura 73) . Al pulsar aparecerá la siguiente página:

- 112 -




Figura 74: Página Ver Información de Prueba

Pulsando el botón “Volver” se volverá a la página de resultados de laboratorio.

3.5.5.6. Caso de Uso “Añadir Prueba” Permite al laboratorio añadir una prueba a la “Hoja de Resultados”.

Lo mas normal es que un médico rellene en la solicitud las casillas correspondientes a las pruebasque quiera realizar al paciente, así luego la “Hoja de Resultados” creará un formulario a partir de lascasillas que han sido rellenadas. No obstante, también se puede dar el caso que el médico quierarealizar una prueba que no tiene su correspondiente casilla por lo que la pedirá a través del campoobservaciones. Por eso se hace necesario que el laboratorio puede añadir pruebas a la Hoja deResultados.

Figura 75: Página Añadir Prueba

- 113 -




Se pueden realizar dos acciones:

• Si se pulsa sobre un parámetro éste se añadirá a la lista de resultados. A continuación volveremosa la página de resultados pero con nuestra prueba ya añadida.

• “Volver”: se volverá a la página de resultados de laboratorio.

- 114 -




3.5.6. Actor Administrador Los casos de uso para el actor Laboratorio son:

Figura 76: Casos de uso del actor Administrador


A la página de Administradores (figura 77) se podrá acceder desde el enlace “Administrador” queaparece en el menú de la izquierda.

Figura 77: Página de Administradores

3.5.6.1. Caso de Uso “Mantenimiento de Parámetros”

El enlace a esta página “Mantenimiento de Parámetros” aparece en el menú de administradores dela figura 77.

- 115 -




Figura 78: Página de Mantenimiento de Parámetros


• "ALTA": Da de alta a un parámetro. • "CONSULTA": Muestra una lista de los parámetros que cumplen con los requisitos de la búsqueda,

es decir, busca a los parámetro cuyos datos coinciden con los datos rellenados en el formulario de"Mantenimiento de Parámetros".

• "NUEVO PARAMETRO": Limpia los datos de la pantalla para permitir la búsqueda de un nuevoparámetro.

• "ACTUALIZAR": Actualiza los datos de un parámetro (Este botón aparecerá una vez encontrado elparámetro). Entre los distintos valores que se pueden actualizar también se encuentra el númeroLOINC. Así el administrador tiene la posibilidad de asociar a cada prueba el número LOINC que lecorresponde

I Acción ALTA

El usuario rellenará correctamente todos los campos y pulsará el botón alta. Si no hay ningún falloaparecerá otra vez la página de parámetro pero con un mensaje de estado indicando que se le hadado de alta al parámetro.

Una vez dado de alta un nuevo parámetro, éste estará disponible para los laboratorios.

II Acción CONSULTA

la búsqueda se podrá realizar a partir cualquier campo de tabla “PARAMETROS” o mediante unacombinación de los mismos, ejemplos de estos campos son el número LOINC, el componente, elsistema, la propiedad, etc.

Se puede observar que la mayoría de los campos del formulario son listas desplegables.

Para facilitar la búsqueda se podrá indicar en el campo componente las primeras letras delcomponente buscado y devolverá una lista de todos los componente que empiecen por esas letras

Luego se mostrará la lista de las parámetros (figura 79) que cumplen con los requisitos de labúsqueda. En la siguiente pantalla vemos el resultado de una búsqueda en el que el sistema es“URINE” y el grupo es “Bioquímica”.

- 116 -




Figura 79: Página lista de ParámetrosSi en la lista de parámetro de la figura 79 aparece el parámetro buscado, el administrador sólo

tendrá que pulsar sobre él e inmediatamente se volverá a la página de mantenimiento de parámetrospero con todos los datos del parámetro rellenos y con la posibilidad de actualizar sus datos.

3.5.6.2. Caso de Uso “Mantenimiento de Médicos” El enlace a esta página “Mantenimiento de Médicos” aparece en el menú de administradores de la

figura 77.

Figura 80: Página de Mantenimiento de Médicos


• "ALTA": Da de alta a un médico.

- 117 -




• "CONSULTA": Muestra una lista de los médicos que cumplen con los requisitos de la búsqueda, esdecir, buscará a las personas cuyos datos coinciden con los datos rellenados en el formulario de"Ficha del Médico".

• "NUEVO MEDICO": Limpia los datos de la pantalla para permitir la búsqueda de un nuevo médico.

• "ACTUALIZAR": Actualiza los datos del médico (Este botón aparecerá una vez encontrado almédico).

• "BAJA": Borra el registro del médico del sistema (Este botón aparecerá una vez encontrado almédico)

I Acción ALTA

El usuario rellenará correctamente todos los campos y pulsará el botón alta. Si no hay ningún falloaparecerá otra vez la página de médicos pero con un mensaje de estado indicando que se le ha dadode alta al médico.

II Acción CONSULTA

La búsqueda la puede realizar por el dni, apellidos, fecha de nacimiento, o cualquier otro campo ocombinación de ellos. Luego se mostrará la lista de las médicos (figura 81) que cumplen con losrequisitos de la búsqueda:

Figura 81: Página lista de MédicosSi en la lista de médicos de la figura 81 aparece el médico buscado, el administrador sólo tendrá que

pulsar sobre ella e inmediatamente se volverá a la página de mantenimiento de médicos pero contodos los datos del médico rellenos y con la posibilidad de actualizar sus datos o darlo de baja.

- 118 -




3.6. Diseño y realización de las páginasEl diseño de las páginas se ha hecho buscando que éstas tengan un aspecto simple pero que a la

vez el usuario pueda disponer de toda la información que necesita.

En la siguiente figura podemos ver un ejemplo del diseño que siguen las páginas de la aplicación:

Figura 82: Página Pacientes una vez encontrado al pacienteLas distintas partes de la que consta el diseño de una página son:

➢ El menú de la izquierda: aparecen distintos enlaces que permiten al usuario acceder de unamanera rápida y cómoda a los distintos subsistemas de la aplicación. Sólo aparecerán aquellosenlaces de los subsistemas que el usuario tenga permiso. En la figura 82 podemos ver que elusuario tiene acceso a los subsistemas de “Médicos” , “Enfermeros”, ”Laboratorios” y“Administrador”. No es normal que un usuario tenga tanto permisos pero para el desarrollo de laaplicación hemos creado este usuario por mayor comodidad.

➢ Pantalla principal: es la parte derecha de la página y aparecerá la pantalla del subsistema elegido.Normalmente está compuesta por:

• La cabecera: Es la banda azul horizontal que aparece en la parte superior de la pantalla. Es degran utilidad ya que indica al usuario su situación actual en la aplicación y ofrece un enlace paravolver a la página anterior. En la figura 82 no se puede apreciar todas sus características ya queal ser la página inicial del módulo de médico no se puede volver a ningún lado. En cambio, sinos fijamos en la figura 83 vemos que en la cabecera nos aporta gran información: nos indicaque estamos en el “Módulo de Médicos”, que dentro de este nos encontramos en la página de“Solicitudes Pendientes de Bioquímica” y se nos ofrece la posibilidad de volver al menú demédicos con solo pulsar sobre el enlace “Volver a Menú”. Este enlace se ha puesto aquí paraque el usuario pueda acceder rápidamente al mismo. También el nombre del enlace indica hacíaque sección te dirige, así según la página donde nos encontremos puede poner: “Volver aMenú”, “Volver a Solicitud”, “Volver a Resultados”,etc.

- 119 -




• Otro detalle es que en la parte superior de la página podrá aparecer un mensaje describiendo elestado de la aplicación o explicando algún error en la validación del formulario. Con estosmensajes conseguimos que el usuario tenga un mayor control sobre lo que sucede en laaplicación. Por ejemplo en la figura 82 vemos como aparece el mensaje de estado “PersonaEncontrada”, por lo que el usuario sabrá que se ha encontrado a la persona que buscaba.

• Por último tendremos el “cuerpo” de la página, normalmente estará formado por un formulario ypor un conjunto de botones y links que permiten al usuario realizar distintas acciones. Tambiénes normal agrupar partes comunes dentro de un mismo cuadro o tabla para separar mejor loscontenidos de la página. Estos cuadros tienen en su cabecera un título que los describe, porejemplo en la figura 82 vemos que hay dos cuadros “Ficha del Paciente” e “Historial deLaboratorio del Paciente”.

Otro aspecto importante muy a tener en cuenta es que se ha hecho un gran trabajo en conseguirque todos los informes que aparezcan por pantalla sean idénticos a los papeles que los usuariosrellenan a diario (ver por ejemplo la figura 83). Así la única diferencia que van a notar es que lospapeles que antes tenían que rellenar a mano ahora los van a rellenar por ordenador. Esto es unamanera de ganarnos la confianza del usuario ya que se sentirá más cómodo al reconocer el formato delos informes.

Figura 83: Página solicitudes Pendientes de bioquímica

- 120 -




Otros aspectos que hemos tenido en cuenta son los siguientes:

➢ Todas las páginas se cargarán en una ventana flotante (popup) a la cual se le ha desprovisto demenú, de barra de herramientas, barra de direcciones y barra de estado. De esta forma el usuariodel sitio está obligado a navegar tan sólo por donde nosotros le permitamos. Esto facilita ademásen gran medida el control del flujo, pues al quitar el botón de atrás no tenemos por quépreocuparnos del gran problema que supone el ir hacia atrás varias páginas y repetir la petición.

En cualquier sitio web el quitarle el control al usuario repercutiría muy negativamente en el númerode visitas del mismo, pero como esto pretende ser una herramienta de trabajo es más importantesu buen funcionamiento y su robustez ante usuarios inexpertos o mal intencionados.

➢ Los botones se han hecho grandes y que contrasten con el fondo para que los usuarios loslocalicen rápidamente.

➢ Se dan dimensiones fijas a las tablas para que no cambien de aspecto en función del tamaño de laventana abierta. De esta manera evitamos que se descuadren los elementos de la pantalla.

En cuanto a la realización de las páginas, éstas se han hecho buscando que funcionencorrectamente en los principales navegadores del mercado.

Uno de los principales problemas consiste en las incompatibilidades que crea el código javascript,por ello se ha reducido su uso al mínimo necesario. Básicamente el código javascript se ha usado parados cometidos en la aplicación:

1. Cuando se pulsa un botón se llama a una función javascript que pone el parámetro “action” al valorque le corresponda según la acción asociada a dicho botón. De esta manera, cuando le llegue lapetición del usuario a la clase action podrá saber que acción requiere el usuario y así llamar a lalógica de negocio que implemente dicha acción.

2. También, gracias al uso de javascript se ha conseguido el efecto de “marcar” las casillas en losinformes de laboratorio, que en lugar de hacerlos con botones checkbox o radios normales, lohemos hecho con imágenes para mantener la misma apariencia que los informes en formato papel.

Hay que hacer notar que al usar el framework de Struts, la validación de los formularios no la hemoshecho vía javascript sino a través del método validate() del actionForm que le corresponde alformulario. Esto es que la validación se hace desde el servidor, logrando así un mayor nivel deseguridad. El problema de validar en el servidor es que se puede cargar más la red y el propio servidorya que se tendrían que "dar más vueltas" en caso de error en la validación. También se podría añadirla validación mediante javascript pero lo hemos evitado para no tener problemas de incompatibilidadescon navegadores.

Hemos de decir que se ha conseguido que la aplicación funcione correctamente para los principalesnavegadores del mercado, como son Internet Explorer, Netscape, Mozilla y el Konqueror. El úniconavegador que hemos probado y no ha funcionado correctamente es el Opera, el cual tiene problemasen reconocer el código javascript que realiza el efecto de marcar las casillas.

Otras tecnologías que se han usado para la realización de las páginas son:

➢ Hojas de estilo (CSS). Dado que muchas páginas de la aplicación tienen el mismo aspecto, se hanrecogido todos los estilos en un mismo fichero. Así podremos cambiar el aspecto de todas ellas a lavez sin más que modificar el fichero que contiene estos estilos.

En nuestra aplicación se han creado varios archivos de estilos: - principal.css que contienen los estilos generales de la aplicación - solBioquímica.css, solMicrobiologia.css y solHematología.css: que contienen los estilos

particulares de cada uno de los tipos de solicitud que existen.

➢ taglibs definidos por Struts: Los Taglibs son una serie etiquetas que encapsulan una ciertafuncionalidad (implementadas mediante una clase java) lo que nos ahorrará tiempo a la vez que seconsigue un código más legible. Los taglibs que hemos usado son [11]:

- 121 -




➢ Struts HTML: Este taglib contiene etiquetas útiles en la creación de interfaces de usuariosbasada en HTML

➢ Struts Bean: Este taglib contiene etiquetas útiles para acceder a los bean y sus propiedades.También permite acceder a los mensajes definidos en el fichero de mensajes.

➢ Struts Logic: Este taglib contiene etiquetas que son útiles en la gestión de la generacióncondicional de texto de salida y bucles sobre colecciones de objetos para la generaciónrepetitiva de texto de salida.

➢ Dada la complejidad, en cuanto a la gran cantidad de código html, que contenían las principalespáginas de la aplicación, se ha decidido organizar o dividir en distintos fragmentos usando ladirectiva:

<jsp:include page=”URL relativa” flush=”true” />

Con esta directiva podemos incluir parte de un fichero en el momento en que es solicitada unapágina. Es decir, una página principal estará formada por un conjunto de fragmentos de páginas quese incluirán cuando se solicite dicha página principal.

Otro motivo por el que se ha utilizado esta técnica es porque hay muchas páginas muy parecidasentre sí por lo que es posible reutilizar fragmentos de las mismas sin que haga falta reescribirlas otravez en todas ellas. También ganamos en cuanto a que la páginas serán más fáciles de mantener ygestionar.

En la aplicación se han nombrado las páginas utilizando la regla de que las páginas principales de laaplicación, que se forman a partir de fragmentos de otras, se nombren de la siguiente manera:“paginaXXX.jsp”

Por ejemplo la página de la figura 83 se llama paginaSolicitudBioquimica.jsp he irá incluyendodistintos fragmentos como son el logotipo, el cuadro de información, la cabecera, etc.

- 122 -



CONCLUSIONES Y LÍNEAS FUTURAS

4. CONCLUSIONES Y LÍNEAS FUTURAS

Cuando surgió la idea de realizar este proyecto, el primer planteamiento consistía en realizar unSistema de Información que fuera capaz de encargarse de las Gestión de las Pruebas de Laboratoriode un hospital.

Un estudio de la cuestión reveló que el principal problema al que nos enfrentamos consistía en quela codificación de las pruebas de laboratorio se ha realizado hasta el momento de forma anárquica,definiendo cada centro sus propias normas y formatos. Esto dificulta en gran medida la transferenciade información desde los sistemas de laboratorios a los grandes sistemas hospitalarios, a la historiaclínica electrónica u otros sistemas informáticos de salud.

Para solucionar este problema nuestro Sistema de Gestión mapeará la terminología y codificaciónpropia a un sistema de codificación internacional, organizada y construida bajo pautas consensuadaspor grupos de expertos, como es LOINC (Logical Observation Identifier Names and Codes).Actualmente LOINC es ampliamente aceptado como el principal estándar para intercambio deresultados de laboratorio tanto en América como en Europa.

La arquitectura del sistema es una aplicación web basada en un modelo cliente/servidor de trescapas. Con esto conseguimos que el cliente pueda acceder al sistema con un simple navegador, dehecho nuestro sistema funciona para los navegadores más importantes del mercado como sonInternet Explorer, Netscape, Mozilla y el Konqueror.

Otro aspecto importante es que la aplicación web se ha desarrollado usando el framework de Struts,lo que ha permitido la construcción de una aplicación web perfectamente estructurada, basado en elpatrón de diseño MVC (Modelo Vista Controlador). Con esto hemos conseguido una aplicaciónfácilmente mantenible y escalable. De esta manera nos aseguramos alargar la vida de nuestraaplicación.

Como queríamos conseguir un producto que pudiera servir para un hospital real se ha trabajadojunto con el Hospital Macarena. El proyecto siempre se ha hecho pensando en que el sistema iba a serutilizado por una serie de usuarios: médicos, enfermeros, técnicos de laboratorios, que tienen unalabor muy importante en nuestra sociedad y que no pueden dedicar mucho tiempo en aprender autilizar un nuevo Sistema de Gestión. Por ello se ha buscado que sea el propio Sistema de Gestión elque se adapte a sus necesidades. Esta adaptación ha consistido en tres aspectos:

➢ El diseño del flujo de la aplicación se ha adaptado a la forma de actuar de los usuarios, por lo quelos pasos que tienen que seguir los usuarios en la Gestión del Laboratorio seguirá siendo la misma.

➢ La presentación de las páginas: todos los informes que aparecen por pantalla serán idénticos a lospapeles que los usuarios rellenan a diario. La única diferencia que van a notar es que los papelesque antes tenían que rellenar a mano ahora los van a rellenar por ordenador, con la ventaja añadidade que muchos datos, como por ejemplo los datos personales de la persona, se cargaránautomáticamente en los informes (con el ahorro de esfuerzo y tiempo que ello conlleva).

➢ El sistema mapeará internamente a LOINC pero los usuarios podrán seguir usando su propiaterminología y sistema de codificación.

Cuando se fué desarrollando el proyecto fueron surgiendo una serie de ideas que nos gustaría dejarcomo posibles líneas de continuación. Estas ideas van encaminadas a facilitar y agilizar las tareas delos distintos usuarios de la aplicación. Vamos a enumerar algunas de ellas:

➢ Se ha pensado que se podría realizar una nueva vista adaptada a la pantalla de una PDA para quelos enfermeros pudieran ver desde cualquier sitio que muestras deben tomar a los pacientes.

➢ Los enfermeros deben etiquetar los tarros que contienen las muestras con un código de barras.Para que dicha muestra pueda ser identificada en los laboratorios el enfermero debe de introduciren la solicitud de laboratorio dicho número del código de barras. Esto puede suponer un engorro ala vez que una fuente de errores, por ello se propone la utilización de un lector de código de barrasque introduzca directamente en la aplicación el número del código de barras.

➢ Otra línea de continuación consiste en estudiar la posibilidad de que se introduzcan directamente enla aplicación los resultados que dan las máquinas de laboratorio. Esta sería otra manera de ahorrar

- 123 -



CONCLUSIONES Y LÍNEAS FUTURAS

tiempo y esfuerzo, a la vez que se evitan posibles errores humanos a la hora de rellenar losformularios. Para ello sería necesario estudiar en profundidad los estándars de transmisión dedatos que utilizan los dispositivos del laboratorio.

Otros dos temas que también dejamos abierto para su estudio y elaboración son:

➢ Un problema que nos encontramos en aplicaciones web es la seguridad, si le sumamos el hecho deque por ley los datos personales y sobre todo los de carácter sanitario deben cumplir con unasexigentes medidas de seguridad, el problema se acentúa aún mas. Se hace necesario sobre todo elaplicar unos altos niveles de encriptación a la información que viaje por la red y reforzar losmecanismos de control de acceso.

➢ También comentar que en la aplicación hay una página que permite introducir para cada prueba delaboratorio su correspondiente código LOINC. Esta tarea la deberá de realizar una técnico delaboratorio y para llevarla a cabo se aconseja que se use herramienta RELMA, proporcionadagratuitamente por el organismo Rentrefgief. Esta herramienta ayuda a encontrar cual es el códigoLOINC que le corresponde a una prueba de laboratorio.

Por último recordar que gracias a que la aplicación web ha sido desarrollada mediante el frameworkde Strust será relativamente fácil el introducir nuevos módulos a nuestra aplicación. Sirva de ejemplo lalínea de continuación propuesta de hacer una nueva vista para la PDA. Gracias a la arquitectura deStrust basada en el patrón de diseño Modelo-Vista-Controlador, podemos tener la seguridad quepodremos realizar una nueva vista sin necesidad de modificar la lógica de negocio. Aunque esto no esmás que una de las enormes ventajas que proporciona Struts.

- 124 -



BIBLIOGRAFÍA

5. BIBLIOGRAFÍA

I Libros o capítulos

[1] Galeano, Germán; Díaz, Pablo; Sánchez, José Carlos. Manual Imprescindible de HTML 4.EDICIONES ANAYA MULTIMEDIA, 2000.

[2] Apuntes de: “Curso de experto universitario en desarrollo de aplicaciones para internet y serviciosweb”. E.T.S. Ingeniería Informática.

[3] Keogh, Jim. “Objetos JDBC”. Manual de referencia J2EE. Mc Graw Hill, 2002. Capitulo 6

[4] Román Martínez, Isabel; Roa, Laura M.; Vozmediano, Juan M. Consideraciones Metodológicaspara conseguir la Historia Clínica Virtual como una composición de servicios. Área de Telemática,Universidad de Sevilla.

II Recursos web

➢ Laboratorios

[5] www.loinc.org

[6] CARE2X. Integrated Healthcare Environment. http://www.care2x.org/foundry/index.php [consultaNoviembre 2004]

[7] http://www.nlm.nih.gov/medlineplus/spanish/encyclopedia.html [consulta Febrero 2005]

[8] http://www.saludalia.com/ [consulta Febrero 2005]

➢ Struts

[9] http://struts.apache.org/

[10] http://struts.apache.org/api/

[11] http://struts.apache.org/userGuide/struts-html.html

[12] Altadill Izura, Pello Xabier. STRUTS. Implementación del patrón MVC en aplicaciones Web.http://www.pello.info/ [consulta 17 Febrero 2005]

[13] Turner, James. Struts Kick Start. Sams Publishing. December 09, 2002http://fama.us.es/search*spi/tstruts/tstruts/1,1,1,B/l856&FF=tstruts&1,0,,2,0 [consulta 20 Abril 2005]Acceso desde catalogo FAMA de la Bibliotieca de la Universidad de Sevilla.

➢ Tomcat

[14] http://jakarta.apache.org/tomcat/

[15] http://www.programacion.com/tutorial/tomcatintro/

➢ Postgres

[16] http://www.postgresql.org/

[17] http://www.sobl.org/traducciones/practical-postgres/practical-postgres.html

[18] Bailador Ferreras, Almudena; Gonzales Giralda, Carlos. Cómo construir una Aplicación Web dealto rendimiento, utilizando java almacenado en Oracle8I. Dpto. de Informática, CIEMAT – McytT.http://www.ciemat.es/informatica/documentacionp/cuore2001.pdf [consulta 20 Abril 2005]

[19] Curso Introductorio de OpenACS. Capitulos 3 y 4.http://www.efaber.net/formacion/fp/curso_acs/index.html [consulta Enero 2005]

- 125 -



BIBLIOGRAFÍA

➢ sevlets y jsp

20] Marty Hall Servlets y JSP.. Traductor: Palos, Juan Antonio. Java en castellano.http://www.programacion.com/java/tutorial/servlets_jsp [consulta Noviembre 2004]

➢ javascript

21] http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/dhtml_node_entry.asp[consulta Febrero 2005]

[22] Client-Side JavaScript 1.3 Reference. http://docs.sun.com/app/docs/coll/S1_Javascript_13[consulta Marzo 2005]

III Normas

[23] UNE-ENV 1614:1996. Informática Sanitaria. Estructura para la nomenclatura, la clasificación y lacodificación de las propiedades en los laboratorios de análisis clínicos.

- 126 -



ANEXOS

6. ANEXOS

6.1. Estructura de la Base de Datos LOINC

- 127 -


Field Name Type Width Description1 LOINC_NUM Text 7

2 COMPONENT Text 150

3 PROPERTY Text 304 TIME_ASPCT Text 155 SYSTEM Text 1006 SCALE_TYP Text 307 METHOD_TYP Text 508 RELAT_NMS Text 254

9 CLASS Text 20

10 SOURCE Text 8 This is for our internal use and should be ignored by database users.

11 EUCLIDE_CD Text 10

12 ASTM_CD Text 9

The unique LOINC Code. This is a numeric code with a mod 10-check digit. (The algorithm for calculating a mod 10-check digit is given in Appendix C.)

Fields 2-7 contain the six parts of the name. The fully specified name for a given LOINC code would be constructed by printing out the contents of these fields (2-7), inserting a colon (:) between the contents of each of these fields.

Fields 2-7 contain the six parts of the name. The fully specified name for a given LOINC code would be constructed by printing out the contents of these fields (2-7), inserting a colon (:) between the contents of each of these fields.

This field is no longer being maintained. It has been replaced by # 58 RelatedNames2 An arbitrary classification of the terms for grouping related observations together. The current classifications are listed in Table 20. We present the database sorted by the class field within class type (see field 35). Users of the database should feel free to re-sort the database in any way they find useful, and/or to add their own classifying fields to the database. The content of the laboratory test subclasses should be obvious from the subclass name. However some of these need more specification. Microbiology includes all tests used to identify microorganisms and evidence for infection by specific organisms as well as cultures direct microscopic exams that identify organisms or prove evidence for present or past infection with specific organisms. Microbiology includes tests for antibodies, antigens, DNA and RNA. The Serology class does not include measures antibodies or antigens related to microorganisms. Molecular pathology class does not include RNA or DNA based tests for infectious organisms. (They are all included in Microbiology.) The class Blood bank includes all blood bank testing including AB0- Rh testing. Allergy class includes testing for antibodies to allergens (cat dander, trees, etc). Serology includes rheumatological, and autoantibodies, and antigen measures not covered by these two classes. Hematology/cell counts excludes coagulation studies that are found in a separate class. Measures of complement activity are included within Hematology, not Chemistry. Chemistry does not include challenge tests such as Glucose tolerance, ACTH stimulation, etc. These are in a separate category - Challenge tests.

EUCLIDES analyte code. The Euclides code identifies the analyte (the first subpart of the first part of the name). The ASTM codes apply to only a few of the tests (e.g. cell counts, antibiotic sensitivities). These are the codes included in the appendices of HL7 and ASTM E1238-94. This field is no longer being maintained


ANEXOS

- 128 -


Field Name Type Width Description13 IUPAC_CD Text 8

14 DT_LAST_CH Text 8 Date last changed, in the format YYYYMMDD 15 CHNG_REAS Text 254

16 CHNG_TYPE Text 3

17 COMMENTS Text 254 Free-text comments relating to the test result. 18 ANSWERLIST Memo -

19 STATUS Text 3

20 MAP_TO Text 7

21 SCOPE Text 20 Not currently used. 22 SNOWMED_CD Text 10 SNOMED Code (future versions). Not currently used. 23 VA_CD Text 8 VA Code (future versions). Not currently used. 24 METPATH_CD Text 10 MetPath Code. Not currently used. 25 HCFA_CODE Text 12 HCFA code (future versions). Not currently used. 26 CDC_CODE Text 6

27 NORM_RANGE Text 30 Normal Range - Example answers from real tests 28 EX_US_UNITS Text 30

29 IPCC_UNITS Text 30 Example units used by IUPAC/IFCC (future) 30 GPI_CD Text 100

31 REFERENCE Memo -

32 EXACT_CMP_SY Text 50

The IUPAC code identifies the component, kind of property, and system. Note: Most of the IUPAC codes for chemistry assume the component is measured in substance concentration, e.g. moles, while most U.S. labs report in mass concentration. We have applied the IUPAC code for substance concentration to mass concentration, because IUPAC has no code for the mass concentration variant.

Reason term was changed. If a term has been changed, the reason for the change is detailed here. Change Type Code. DEL = Delete; ADD = add, NAM = change to Analyte/Component (field #2); MAJ = change to name field other than #2 (#3 - #7); MIN = change to field other than name.

The list of answers for results that are reportable from a multiplechoice list (e.g. the answers for the term DISPOSITION OF BLOOD PACK are GIVEN; PARTIALLY GIVEN; DISCARDED). This field provides examples, not required answer lists.

Deprecated or superseded status indicated by DEL in this field (otherwise blank). Used to mark terms as the database evolves. LOINC codes will not ever be re-used nor will they be removed from the database, they will instead be cross-referenced whenever possible to superseding terms in Field 20.

Used when a field has been dropped from the active database (by entering "DEL" in the Status field) because it has been replaced by an updated term. In those cases, Map_To contains the LOINC code of the new term that should be used.

Code from CDC Complexity file that maps laboratory tests to the instruments used to perform them. These codes are at the analyte level, not the test instrument level.

Example units used in the US. The terms have been standardized to more closely resemble HL7 version 3 units.

GPI Code. For drugs, this field contains a map to the Medispan GPI codes, a hierarchical system of classifying pharmaceutical products. In cases where a one-to-one mapping was not possible, all applicable GPI codes are contained in this field, separated by semicolons.

Contains references to medical literature, product announcements, or other written sources of information on the test or measurement described by the LOINC record.

Exact core component synonym: This field contains an exact synonym for the "core component" of the LOINC component name. We have included the mixed case and "superscript" form of blood bank and HLA antigens (e.g. Lua) here. As there is no ASCII representation for superscript letters, we use the hat (^) to signify superscripts in this field. (e.g. if the core component is represented as L LITTLE U LITTLE SUPER A in the LOINC component/analyte name field, it is represented in the Exact Core Synonym field as Lu^a.)


ANEXOS

- 129 -



ANEXOS

- 130 -


Field Name Type Width Description34 IUPC_ANLT_CD Text 13

35 CLASSTYPE Int 2

36 FORMULA Text 255 Regression equation details for many OB.US calculated terms. 37 MULTUM_CD Text 6 Maps to Multum Inc. database of codes for drugs. 38 DEEDS_CD Text 7

39 CSCQ_FRNCH_NM Text 255

40 CSCQ_GRMN_NM Text 255

41 SPNSH_NM Text 255

42 CSCQ_ITLN_NM Text 255

43 SPECIES Text 20

44 EXMPL_ANSWERS Memo -

45 ACSSYM Memo -

46 MOLEID Text 15 Molecular structure ID, usually CAS number 47 BASE_NAME Text 50 Chemical base name from CAS 48 FINAL Text 1 Internal LOINC use field 49 GENE_ID Text 20 OMIM (Online Mendelian Inheritance in Man) Names 50 NAACCR_ID Text 20

51 CODE_TABLE Text 10 Examples on CR0050 Cancer Registry 52 SetRoot Yes/No 1

53 PanelElements Memo - List of individual tests that comprise a panel 54 SURVEY_QUEST_TXT Text 255 Verbatim question from the survey instrument 55 SURVEY_QUEST_SRC Text 50 Exact name of the survey instrument and the item/question number

56 UnitsRequired Text 1

57 SUBMITTED_UNITS Text 30 Example units as submitted by original requester. 58 RelatedNames2 Memo -

59 SHORTNAME Text 40

60 ORDER_OBS Text 15

61 CDISC_COMMON_TES TS Text

IUPAC analyte code: This field contains the Chemical Abstract service number or the Enzyme Nomenclature number for the chemical components for chemicals and/or enzymes. These were also contributed by IUPAC.

1=Laboratory class; 2=Clinical class; 3=Claims attachments; 4=Surveys

Data Elements for Emergency Department Systems Codes (CDC). This field contains the DEEDS code value which maps to the LOINC code in question.

French name for LOINC term. Supplied by Centre Suisse de Contrôle de Qualité. This field contains extended characters and will not transfer correctly to 7-bit systems

German name for LOINC term. Supplied by Centre Suisse de Contrôle de Qualité. This field contains extended characters and will not transfer correctly to 7-bit systems

Spanish name for LOINC term. Supplied by Centre Suisse de Contrôle de Qualité. This field contains extended characters and will not transfer correctly to 7-bit systems

Italian name for LOINC term. Supplied by Centre Suisse de Contrôle de Qualité. This field contains extended characters and will not transfer correctly to 7-bit systems

Codes detailing which non-human species the term applies to. If blank, “human” is assumed. For some tests and measurements, we have supplied examples of valid answers, such as “1:64”, “negative @ 1:16”, or “55”. This differs from the ANSWERLIST field, which details possible choices for nominal scale terms.

Chemical name synonyms, alternative name synonyms, and chemical formulae supplied by the Chemical Abstract Society

Maps to North American Association of Central Cancer Registries Identification Number

Currently used for claims attachments. Yes in this field signifies that this record is the root of a set of LOINC codes.

Y/N field that indicates that units are required when this LOINC is included as an OBX segment in a HIPAA attachment

This is a new field introduced in version 2.05. It contains synonyms for each of the parts of the fully specified LOINC name (component, property, time, system, scale, method). It replaces #8, Relat_NMS.

Introduced in version 2.07, this field is a concatenation of the fully specified LOINC name. The field width may change in a future release.

Defines term as order only, observation only, or both. A fourth category, Subset, is used for terms that are subsets of a panel but do not represent a package that is known to be orderable we have defined them only to make it easier to maintain panels or other sets within the LOINC construct.

1 “Y” in this field means that the term is a part of subset of terms used by CDISC in clinical trials.

ANEXOS

6.2. strust-config.xml<?xml version = '1.0' encoding = 'windows-1252'?><!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"

"http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">



<struts-config>

 <form-beans> <form-bean name="usuarioPasswordForm" type="PruebasDeLaboratorio.struts.form.UsuarioPasswordForm"/> <form-bean name="personaForm" type="PruebasDeLaboratorio.struts.form.PersonaForm" /> <form-bean name="medicoForm" type="PruebasDeLaboratorio.struts.form.MedicoForm" /> <form-bean name="inicioLaboratoriosForm" type="PruebasDeLaboratorio.struts.form.InicioLaboratoriosForm" /> <form-bean name="inicioEnfermerosForm" type="PruebasDeLaboratorio.struts.form.InicioEnfermerosForm" /> <form-bean name="inicioAdministradoresForm" type="PruebasDeLaboratorio.struts.form.InicioAdministradoresForm" /> <form-bean name="resultadoSolicitudForm" type="PruebasDeLaboratorio.struts.form.ResultadoSolicitudForm" /> <form-bean name="solicitudBioquimicaForm" type="PruebasDeLaboratorio.struts.form.SolicitudBioquimicaForm" /> <form-bean name="solicitudHematologiaForm" type="PruebasDeLaboratorio.struts.form.SolicitudHematologiaForm" /> <form-bean name="solicitudMicrobiologiaForm" type="PruebasDeLaboratorio.struts.form.SolicitudMicrobiologiaForm" /> <form-bean name="parametrosForm" type="PruebasDeLaboratorio.struts.form.ParametrosForm" /> </form-beans>

 <global-forwards> <forward name="failure" path="/error.jsp"/> </global-forwards>  <action-mappings>

  

 <action path="/editUsuarioPassword" type="PruebasDeLaboratorio.struts.action.EditUsuarioPasswordAction">  <forward name="success" path="/inicioUsuarioPassword.html" /> </action>


 <action path="/controladorInicio" type="PruebasDeLaboratorio.struts.action.ControladorInicioAction"> <forward name="success" path="/inicio.jsp"/> </action>

 

- 131 -

ANEXOS



 <action path="/controladorPersona" type="PruebasDeLaboratorio.struts.action.ControladorPersonaAction" name="personaForm" scope="session" input="/personas.jsp" validate="true"> <forward name="success" path="/personas.jsp"/> <forward name="consultaListaPersonas" path="/consultaListaPersonas.jsp"/> <forward name="solicitudBioquimica" path="/paginaSolicitudBioquimica.jsp"/> <forward name="solicitudesPendientesBioquimica" path="/paginaSolicitudesPendientesBioquimica.jsp"/> <forward name="solicitudesConsolidadasBioquimica" path="/paginaSolicitudesConsolidadasBioquimica.jsp"/> <forward name="solicitudHematologia" path="/paginaSolicitudHematologia.jsp"/> <forward name="solicitudesPendientesHematologia" path="/paginaSolicitudesPendientesHematologia.jsp"/> <forward name="solicitudesConsolidadasHematologia" path="/paginaSolicitudesConsolidadasHematologia.jsp"/> <forward name="solicitudMicrobiologia" path="/paginaSolicitudMicrobiologia.jsp"/> <forward name="solicitudesPendientesMicrobiologia" path="/paginaSolicitudesPendientesMicrobiologia.jsp"/> <forward name="solicitudesConsolidadasMicrobiologia" path="/paginaSolicitudesConsolidadasMicrobiologia.jsp"/> </action>

 

 <action path="/controladorSolicitudBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudBioquimicaAction" name="solicitudBioquimicaForm" scope="session" input="/paginaSolicitudBioquimica.jsp" validate="true"> <forward name="success" path="/paginaSolicitudBioquimica.jsp"/> <forward name="solicitudEnviada" path="/paginaSolicitudBioquimicaEnviada.jsp"/> <forward name="personas" path="/personas.jsp"/> </action>



<action path="/controladorSolicitudesPendientesBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudesPendientesBioquimicaAction" name="solicitudBioquimicaForm" scope="session" validate="false"> <forward name="success" path="/paginaSolicitudesPendientesBioquimica.jsp"/> <forward name="personas" path="/personas.jsp"/> <forward name="resultado" path="/controladorResultadoBioquimicaSoloLecturaDeSolPendientes.do?action=CREATE"/> </action>

 <action path="/controladorResultadoBioquimicaSoloLecturaDeSolPendientes" type="PruebasDeLaboratorio.struts.action.ControladorResultadoBioquimicaSoloLecturaDeSolPendientesAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoBioquimicaSoloLecturaDeSolPendientes.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesBioquimicaSoloLecturaDeSolPendientes.do?action=CREATE"/> <forward name="volver" path="/paginaSolicitudesPendientesBioquimica.jsp"/> </action>  <action path="/controladorInformacionComponentesBioquimicaSoloLecturaDeSolPendientes" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesBioquimicaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesBioquimicaSoloLecturaDeSolPendientes.jsp"/> <forward name="volver" path="/paginaResultadoBioquimicaSoloLecturaDeSolPendientes.jsp"/> </action>



<action path="/controladorSolicitudesConsolidadasBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudesConsolidadasBioquimicaAction" name="solicitudBioquimicaForm" scope="session" validate="false">

- 132 -

ANEXOS

<forward name="success" path="/paginaSolicitudesConsolidadasBioquimica.jsp"/> <forward name="personas" path="/personas.jsp"/> <forward name="resultado" path="/controladorResultadoBioquimicaSoloLecturaDeSolConsolidadas.do?action=CREATE"/> </action>  <action path="/controladorResultadoBioquimicaSoloLecturaDeSolConsolidadas" type="PruebasDeLaboratorio.struts.action.ControladorResultadoBioquimicaSoloLecturaDeSolConsolidadasAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoBioquimicaSoloLecturaDeSolConsolidadas.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesBioquimicaSoloLecturaDeSolConsolidadas.do?action=CREATE"/> <forward name="volver" path="/paginaSolicitudesConsolidadasBioquimica.jsp"/> </action>  <action path="/controladorInformacionComponentesBioquimicaSoloLecturaDeSolConsolidadas" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesBioquimicaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesBioquimicaSoloLecturaDeSolConsolidadas.jsp"/> <forward name="volver" path="/paginaResultadoBioquimicaSoloLecturaDeSolConsolidadas.jsp"/> </action>  

 <action path="/controladorSolicitudHematologia" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudHematologiaAction" name="solicitudHematologiaForm" scope="session" input="/paginaSolicitudHematologia.jsp" validate="true"> <forward name="success" path="/paginaSolicitudHematologia.jsp"/> <forward name="solicitudEnviada" path="/paginaSolicitudHematologiaEnviada.jsp"/> <forward name="personas" path="/personas.jsp"/> </action>



<action path="/controladorSolicitudesPendientesHematologia" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudesPendientesHematologiaAction" name="solicitudHematologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaSolicitudesPendientesHematologia.jsp"/> <forward name="personas" path="/personas.jsp"/> <forward name="resultado" path="/controladorResultadoHematologiaSoloLecturaDeSolPendientes.do?action=CREATE"/> </action>  <action path="/controladorResultadoHematologiaSoloLecturaDeSolPendientes" type="PruebasDeLaboratorio.struts.action.ControladorResultadoHematologiaSoloLecturaDeSolPendientesAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoHematologiaSoloLecturaDeSolPendientes.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesHematologiaSoloLecturaDeSolPendientes.do?action=CREATE"/> <forward name="volver" path="/paginaSolicitudesPendientesHematologia.jsp"/> </action>  <action path="/controladorInformacionComponentesHematologiaSoloLecturaDeSolPendientes" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesHematologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesHematologiaSoloLecturaDeSolPendientes.jsp"/> <forward name="volver" path="/paginaResultadoHematologiaSoloLecturaDeSolPendientes.jsp"/> </action>



- 133 -

ANEXOS

<action path="/controladorSolicitudesConsolidadasHematologia" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudesConsolidadasHematologiaAction" name="solicitudHematologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaSolicitudesConsolidadasHematologia.jsp"/> <forward name="personas" path="/personas.jsp"/> <forward name="resultado" path="/controladorResultadoHematologiaSoloLecturaDeSolConsolidadas.do?action=CREATE"/> </action>  <action path="/controladorResultadoHematologiaSoloLecturaDeSolConsolidadas" type="PruebasDeLaboratorio.struts.action.ControladorResultadoHematologiaSoloLecturaDeSolConsolidadasAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoHematologiaSoloLecturaDeSolConsolidadas.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesHematologiaSoloLecturaDeSolConsolidadas.do?action=CREATE"/> <forward name="volver" path="/paginaSolicitudesConsolidadasHematologia.jsp"/> </action>  <action path="/controladorInformacionComponentesHematologiaSoloLecturaDeSolConsolidadas" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesHematologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesHematologiaSoloLecturaDeSolConsolidadas.jsp"/> <forward name="volver" path="/paginaResultadoHematologiaSoloLecturaDeSolConsolidadas.jsp"/> </action>

 

 <action path="/controladorSolicitudMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudMicrobiologiaAction" name="solicitudMicrobiologiaForm" scope="session" input="/paginaSolicitudMicrobiologia.jsp" validate="true"> <forward name="success" path="/paginaSolicitudMicrobiologia.jsp"/> <forward name="solicitudEnviada" path="/paginaSolicitudMicrobiologiaEnviada.jsp"/> <forward name="personas" path="/personas.jsp"/> </action>



<action path="/controladorSolicitudesPendientesMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudesPendientesMicrobiologiaAction" name="solicitudMicrobiologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaSolicitudesPendientesMicrobiologia.jsp"/> <forward name="personas" path="/personas.jsp"/> <forward name="resultado" path="/controladorResultadoMicrobiologiaSoloLecturaDeSolPendientes.do?action=CREATE"/> </action>  <action path="/controladorResultadoMicrobiologiaSoloLecturaDeSolPendientes" type="PruebasDeLaboratorio.struts.action.ControladorResultadoMicrobiologiaSoloLecturaDeSolPendientesAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoMicrobiologiaSoloLecturaDeSolPendientes.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesMicrobiologiaSoloLecturaDeSolPendientes.do?action=CREATE"/> <forward name="volver" path="/paginaSolicitudesPendientesMicrobiologia.jsp"/> </action>  <action path="/controladorInformacionComponentesMicrobiologiaSoloLecturaDeSolPendientes" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesMicrobiologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesMicrobiologiaSoloLecturaDeSolPendientes.jsp"/> <forward name="volver" path="/paginaResultadoMicrobiologiaSoloLecturaDeSolPendientes.jsp"/>

- 134 -

ANEXOS

</action>



<action path="/controladorSolicitudesConsolidadasMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorSolicitudesConsolidadasMicrobiologiaAction" name="solicitudMicrobiologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaSolicitudesConsolidadasMicrobiologia.jsp"/> <forward name="personas" path="/personas.jsp"/> <forward name="resultado" path="/controladorResultadoMicrobiologiaSoloLecturaDeSolConsolidadas.do?action=CREATE"/> </action>  <action path="/controladorResultadoMicrobiologiaSoloLecturaDeSolConsolidadas" type="PruebasDeLaboratorio.struts.action.ControladorResultadoMicrobiologiaSoloLecturaDeSolConsolidadasAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoMicrobiologiaSoloLecturaDeSolConsolidadas.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesMicrobiologiaSoloLecturaDeSolConsolidadas.do?action=CREATE"/> <forward name="volver" path="/paginaSolicitudesConsolidadasMicrobiologia.jsp"/> </action>  <action path="/controladorInformacionComponentesMicrobiologiaSoloLecturaDeSolConsolidadas" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesMicrobiologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesMicrobiologiaSoloLecturaDeSolConsolidadas.jsp"/> <forward name="volver" path="/paginaResultadoMicrobiologiaSoloLecturaDeSolConsolidadas.jsp"/> </action>

  

 <action path="/controladorInicioLaboratorios" type="PruebasDeLaboratorio.struts.action.ControladorInicioLaboratoriosAction" name="inicioLaboratoriosForm" scope="session" validate="false"> <forward name="success" path="/paginaInicioLaboratorios.jsp"/> <forward name="solicitudesPendientesBioquimica" path="/controladorLaboratorioBioquimica.do?action=Create"/> <forward name="solicitudesPendientesMicrobiologia" path="/controladorLaboratorioMicrobiologia.do?action=Create"/> <forward name="solicitudesPendientesHematologia" path="/controladorLaboratorioHematologia.do?action=Create"/> </action>

 

 <action path="/controladorLaboratorioBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorLaboratorioBioquimicaAction" name="solicitudBioquimicaForm" scope="session" validate="false"> <forward name="success" path="/paginaLaboratorioBioquimica.jsp"/> <forward name="resultado" path="/paginaResultadoBioquimica.jsp"/> <forward name="volver" path="/paginaInicioLaboratorios.jsp"/> </action>



<action path="/controladorResultadoBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorResultadoBioquimicaAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoBioquimica.jsp"/> <forward name="solicitud" path="/paginaLaboratorioBioquimica.jsp"/> <forward name="informacionComponentes" path="/controladorInformacionComponentesBioquimica.do?action=CREATE"/> <forward name="anadirComponentes" path="/paginaAnadirComponentesBioquimica.jsp"/> <forward name="resultadosSoloLectura" path="/controladorResultadoBioquimicaSoloLectura.do?action=CREATE"/>

- 135 -

ANEXOS

</action>  <action path="/controladorResultadoBioquimicaSoloLectura" type="PruebasDeLaboratorio.struts.action.ControladorResultadoBioquimicaSoloLecturaAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoBioquimicaSoloLectura.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesBioquimicaSoloLectura.do?action=CREATE"/> <forward name="inicioLaboratorios" path="/controladorLaboratorioBioquimica.do?action=Create"/> </action>  <action path="/controladorInformacionComponentesBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesBioquimicaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesBioquimica.jsp"/> <forward name="volver" path="/paginaResultadoBioquimica.jsp"/> </action>   <action path="/controladorInformacionComponentesBioquimicaSoloLectura" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesBioquimicaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesBioquimicaSoloLectura.jsp"/> <forward name="volver" path="/paginaResultadoBioquimicaSoloLectura.jsp"/> </action>



<action path="/controladorComponentesAnadirBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorComponentesAnadirBioquimicaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaAnadirComponentesBioquimica.jsp"/> <forward name="volver" path="/paginaResultadoBioquimica.jsp"/> </action>  

 <action path="/controladorLaboratorioHematologia" type="PruebasDeLaboratorio.struts.action.ControladorLaboratorioHematologiaAction" name="solicitudHematologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaLaboratorioHematologia.jsp"/> <forward name="resultado" path="/paginaResultadoHematologia.jsp"/> <forward name="volver" path="/paginaInicioLaboratorios.jsp"/> </action>


<action path="/controladorResultadoHematologia" type="PruebasDeLaboratorio.struts.action.ControladorResultadoHematologiaAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoHematologia.jsp"/> <forward name="solicitud" path="/paginaLaboratorioHematologia.jsp"/> <forward name="informacionComponentes" path="/controladorInformacionComponentesHematologia.do?action=CREATE"/> <forward name="anadirComponentes" path="/paginaAnadirComponentesHematologia.jsp"/> <forward name="resultadosSoloLectura" path="/controladorResultadoHematologiaSoloLectura.do?action=CREATE"/> </action>

- 136 -

ANEXOS



<action path="/controladorResultadoHematologiaSoloLectura" type="PruebasDeLaboratorio.struts.action.ControladorResultadoHematologiaSoloLecturaAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoHematologiaSoloLectura.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesHematologiaSoloLectura.do?action=CREATE"/> <forward name="inicioLaboratorios" path="/controladorLaboratorioHematologia.do?action=Create"/> </action>  <action path="/controladorInformacionComponentesHematologia" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesHematologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesHematologia.jsp"/> <forward name="volver" path="/paginaResultadoHematologia.jsp"/> </action>  <action path="/controladorInformacionComponentesHematologiaSoloLectura" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesHematologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesHematologiaSoloLectura.jsp"/> <forward name="volver" path="/paginaResultadoHematologiaSoloLectura.jsp"/> </action>


<action path="/controladorComponentesAnadirHematologia" type="PruebasDeLaboratorio.struts.action.ControladorComponentesAnadirHematologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaAnadirComponentesHematologia.jsp"/> <forward name="volver" path="/paginaResultadoHematologia.jsp"/> </action>

 

 <action path="/controladorLaboratorioMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorLaboratorioMicrobiologiaAction" name="solicitudMicrobiologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaLaboratorioMicrobiologia.jsp"/> <forward name="resultado" path="/paginaResultadoMicrobiologia.jsp"/> <forward name="volver" path="/paginaInicioLaboratorios.jsp"/> </action>


<action path="/controladorResultadoMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorResultadoMicrobiologiaAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoMicrobiologia.jsp"/> <forward name="solicitud" path="/paginaLaboratorioMicrobiologia.jsp"/> <forward name="informacionComponentes" path="/controladorInformacionComponentesMicrobiologia.do?action=CREATE"/> <forward name="anadirComponentes" path="/paginaAnadirComponentesMicrobiologia.jsp"/> <forward name="resultadosSoloLectura" path="/controladorResultadoMicrobiologiaSoloLectura.do?action=CREATE"/> </action> 

- 137 -

ANEXOS

<action path="/controladorResultadoMicrobiologiaSoloLectura" type="PruebasDeLaboratorio.struts.action.ControladorResultadoMicrobiologiaSoloLecturaAction" name="resultadoSolicitudForm" scope="session" validate="false" > <forward name="success" path="/paginaResultadoMicrobiologiaSoloLectura.jsp"/> <forward name="informacionComponentes"

path="/controladorInformacionComponentesMicrobiologiaSoloLectura.do?action=CREATE"/> <forward name="inicioLaboratorios" path="/controladorLaboratorioMicrobiologia.do?action=Create"/> </action>  <action path="/controladorInformacionComponentesMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesMicrobiologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesMicrobiologia.jsp"/> <forward name="volver" path="/paginaResultadoMicrobiologia.jsp"/> </action>  <action path="/controladorInformacionComponentesMicrobiologiaSoloLectura" type="PruebasDeLaboratorio.struts.action.ControladorInformacionComponentesMicrobiologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaInformacionComponentesMicrobiologiaSoloLectura.jsp"/> <forward name="volver" path="/paginaResultadoMicrobiologiaSoloLectura.jsp"/> </action>


<action path="/controladorComponentesAnadirMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorComponentesAnadirMicrobiologiaAction" name="resultadoSolicitudForm" scope="session" validate="false"> <forward name="success" path="/paginaAnadirComponentesMicrobiologia.jsp"/> <forward name="volver" path="/paginaResultadoMicrobiologia.jsp"/> </action>

    <action path="/controladorInicioEnfermeros" type="PruebasDeLaboratorio.struts.action.ControladorInicioEnfermerosAction" name="inicioEnfermerosForm" scope="session" validate="false"> <forward name="success" path="/paginaInicioEnfermeros.jsp"/> <forward name="solicitudesPendientesBioquimica" path="/controladorEnfermeroBioquimica.do?action=Create"/> <forward name="solicitudesPendientesMicrobiologia" path="/controladorEnfermeroMicrobiologia.do?action=Create"/> <forward name="solicitudesPendientesHematologia" path="/controladorEnfermeroHematologia.do?action=Create"/> </action>

 

 <action path="/controladorEnfermeroBioquimica" type="PruebasDeLaboratorio.struts.action.ControladorEnfermeroBioquimicaAction" name="solicitudBioquimicaForm" scope="session" validate="false"> <forward name="success" path="/paginaEnfermeroBioquimica.jsp"/> <forward name="volver" path="/paginaInicioEnfermeros.jsp"/> </action>  

- 138 -

ANEXOS

 <action path="/controladorEnfermeroHematologia" type="PruebasDeLaboratorio.struts.action.ControladorEnfermeroHematologiaAction" name="solicitudHematologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaEnfermeroHematologia.jsp"/> <forward name="volver" path="/paginaInicioEnfermeros.jsp"/> </action>    <action path="/controladorEnfermeroMicrobiologia" type="PruebasDeLaboratorio.struts.action.ControladorEnfermeroMicrobiologiaAction" name="solicitudMicrobiologiaForm" scope="session" validate="false"> <forward name="success" path="/paginaEnfermeroMicrobiologia.jsp"/> <forward name="volver" path="/paginaInicioEnfermeros.jsp"/> </action>

  

 <action path="/controladorInicioAdministradores" type="PruebasDeLaboratorio.struts.action.ControladorInicioAdministradoresAction" name="inicioAdministradoresForm" scope="session" validate="false"> <forward name="success" path="/paginaInicioAdministradores.jsp"/> <forward name="mantenimientoLoinc" path="/controladorAdministradorMantenimientoLoinc.do?action=Create"/> <forward name="mantenimientoParametros" path="/controladorAdministradorMantenimientoParametros.do?action=Create"/> <forward name="mantenimientoMedicos" path="/controladorAdministradorMantenimientoMedico.do?action=Create"/> </action>

 <action path="/controladorAdministradorMantenimientoParametros" type="PruebasDeLaboratorio.struts.action.ControladorAdministradorMantenimientoParametrosAction" name="parametrosForm" scope="session" input="/paginaMantenimientoParametros.jsp" validate="true"> <forward name="success" path="/paginaMantenimientoParametros.jsp"/> <forward name="volver" path="/paginaMantenimientoParametros.jsp"/> <forward name="volverMenu" path="/paginaInicioAdministradores.jsp" /> <forward name="consultaListaParametros" path="/paginaConsultaListaParametros.jsp"/> </action>

 <action path="/controladorAdministradorMantenimientoMedico" type="PruebasDeLaboratorio.struts.action.ControladorAdministradorMantenimientoMedicoAction" name="medicoForm" scope="session" input="/paginaMantenimientoMedicos.jsp" validate="true"> <forward name="success" path="/paginaMantenimientoMedicos.jsp"/> <forward name="volverMenu" path="/paginaInicioAdministradores.jsp" /> <forward name="consultaListaMedicos" path="/paginaConsultaListaMedicos.jsp"/> </action> </action-mappings>  <message-resources parameter="PruebasDeLaboratorio.struts.ApplicationResources"/> </struts-config>

- 139 -


ANEXOS

6.3. JAVADOC

- 140 -


PROYECTO FIN DE CARRERA DISEÑO Y...

Documents

Transcript of PROYECTO FIN DE CARRERA DISEÑO Y...