Tesis Historial Clinico v2

FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SOFTWARE
Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2 (REHC)
Proyecto profesional presentado por 200020020 Juan Rafael Arteaga Valeriano 200111035 Daniel Gutirrez Fernndez-Dvila
Para optar por el Titulo Profesional de Ingeniero de Software
Asesor: Ing. Jorge Cabrera Berros
Lima, Junio 2009
A nuestros padres, por el apoyo y empuje constante que nos brindaron, y a todas aquellas personas que nos apoyaron en el desarrollo del presente proyecto.
ndice de Diagramas
Figura 1: Subsistemas del Proyecto de Desarrollo de Soluciones para la Lnea de Salud......4 Figura 2: Actores del Sistema...........................................................................................12 Figura 3: Elementos de diseo de la Vista Lgica implementados por REHC 1.0................21 Figura 4: Paquetes de componentes implementados por REHC 1.0...................................23 Figura 5: Elementos de diseo de la Vista Lgica que implementar REHC 2.0.................26 Figura 6: Paquetes de Componentes que implementar REHC 2.0....................................28 Figura 7: Despliegue del Proyecto Desarrollo de Soluciones para la Lnea de Salud...........30 Figura 8: Paquetes de la capa de diseo Lgica Empresarial..........................................33 Figura 9: Clases Interfaces de Servicio y sus interfaces..................................................34 Figura 10: Clases Componentes Empresariales..............................................................35 Figura 11: Paquetes de la capa de diseo Acceso a Datos.............................................35 Figura 12: Clases Componentes Lgicos de Acceso a Datos...........................................36 Figura 13: Clases de Acceso a Datos del paquete Paciente.............................................37 Figura 14: Clases de Acceso a Datos del paquete Encuentro..........................................37 Figura 15: Clases de Acceso a Datos del paquete Orden................................................38 Figura 16: Clases de Acceso a Datos del paquete Observaciones...................................39 Figura 17: Clases de Acceso a Datos del paquete Servicios............................................40 Figura 18: Paquetes de Diseo de la Capa Comunes......................................................40 Figura 19: Clase Acuse de Recibo..................................................................................41 Figura 20: Clases Objetos de Transferencia de Datos.....................................................41 Figura 21: Clases Parmetros de Bsqueda...................................................................42 Figura 22: Diagrama de Componentes del sistema REHC 2.0............................................43 Figura 23: Componentes de la capa Lgica Empresarial.................................................44 Figura 24: Componentes de la capa Acceso a Datos......................................................45 Figura 25: Componentes de la capa Comunes...............................................................45 Figura 26: Organigrama del equipo de Proyecto...............................................................52 Figura 27: Instalador de Servicios ofrecidos por REHC 2...................................................61 Figura 28: Instalador de Base de Datos............................................................................62
ndice de Tablas
Tabla 1: Implementacin del Sistema de Historias Clnicas Electrnicas............................42 Tabla 2: Hitos y entregables del Sistema..........................................................................52 Tabla 3: Requerimientos implementados en cada Release................................................53 Tabla 4: Riesgos identificados en el Proyecto...................................................................58
Tabla de Cont enido

Introduccin.......................................................................................................................I CAPTULO 1: FUNDAMENTACIN TERICA.......................................................................1 1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 1.3.3 2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 2.2.3 3.1 3.1.1 3.1.2 3.2 3.2.1 3.2.2 3.2.3 3.3 4.1 4.1.1 4.1.2 Dominio del Problema...........................................................................................1 La Historia Clnica..................................................................................................1 El Proyecto Hipcrates...........................................................................................1 El Proyecto del Repositorio Electrnico de Historias Clnicas...................................2 Necesidad del Proyecto REHC 2.............................................................................3 Objetivos del Sistema............................................................................................5 Objetivo General...................................................................................................5 Objetivos Especficos.............................................................................................5 Lineamientos a emplear.........................................................................................6 RUP y UML............................................................................................................6 Manejador de Base de Datos.................................................................................7 Lenguaje de Programacin....................................................................................8 Requerimientos Funcionales.................................................................................10 Actores................................................................................................................10 Casos de Uso del Sistema....................................................................................12 Priorizacin y Clasificacin de los Casos de Uso....................................................16 Requerimientos No Funcionales...........................................................................18 Funcionalidad......................................................................................................18 Seguridad............................................................................................................19 Portabilidad.........................................................................................................19 Arquitectura propuesta por el Proyecto REHC 1.0.................................................20 Vista Lgica.........................................................................................................21 Vista de Componentes.........................................................................................23 Arquitectura de Software propuesta en el presente Proyecto................................24 Vista Lgica.........................................................................................................26 Vista de Componentes.........................................................................................28 Vista de Despliegue.............................................................................................29 Lineamientos a emplear.......................................................................................31 Diseo de Base de Datos.....................................................................................32 Tablas.................................................................................................................32 Diccionario de Datos............................................................................................32
CAPTULO 2: REQUERIMIENTOS DEL SISTEMA................................................................10
CAPTULO 3: DISEO ARQUITECTNICO........................................................................20
CAPTULO 4: DISEO DETALLADO DEL SISTEMA.............................................................32
4.2 4.2.1 4.2.2 4.2.3 4.3 4.3.1 4.3.2 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.2 5.2.1 5.2.2 5.3 6.1 6.2 6.2.1 6.2.2 6.3 6.4 7.1 7.1.1 7.1.2 7.2 7.2.1 7.2.2
Diseo de Clases.................................................................................................33 Clases que implementan los componentes de la capa Lgica Empresarial.............33 Clases que implementan los componentes de la capa Acceso a Datos..................35 Clases que implementan los componentes de la capa Comunes...........................40 Modelo de Implementacin..................................................................................42 Descripcin de la Implementacin del Aplicativo..................................................42 Implementacin de Componentes por Capa.........................................................43 Tcnicas de Aplicacin de Pruebas de Software....................................................46 Pruebas Unitarias................................................................................................46 Pruebas de Instalacin........................................................................................47 Pruebas de Integracin........................................................................................48 Pruebas de Stress................................................................................................48 Estrategias de Pruebas........................................................................................49 Estrategia de Pruebas de Funcin........................................................................49 Estrategia de Pruebas de Integracin...................................................................49 Resultados de Pruebas........................................................................................50 Organizacin del Equipo de Proyecto...................................................................51 Planificacin del Proyecto....................................................................................52 Hitos y Entregables del Proyecto..........................................................................52 Plan de Iteraciones..............................................................................................54 Estimacin del Proyecto.......................................................................................55 Administracin de Riesgos...................................................................................56 Instalador del Producto de Software....................................................................60 Instalador del Sistema en el servidor de Aplicaciones ..........................................61 Instalador para la Base de Datos.........................................................................61 Manuales del Producto.........................................................................................63 Manual de Instalacin..........................................................................................63 Manuales de Integracin......................................................................................63
CAPTULO 5: PRUEBAS DEL SISTEMA..............................................................................46
CAPTULO 6: GESTIN DEL PROYECTO...........................................................................51
CAPTULO 7: TRANSICIN DEL SISTEMA.........................................................................60
Conclusiones....................................................................................................................64 Bibliografa.......................................................................................................................66 Anexos A Priorizacin de Casos de Uso B Diagrama de Base de Datos C Diccionario de Tablas D Manual de Instalacin del Sistema
E Manual de Integracin del Sistema
Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2
INTRODUCCIN Dentro de la estrategia educativa de generacin de proyectos para la implementacin de soluciones para la lnea de Salud que fue establecida por la Facultad de Ingeniera de la Universidad Peruana de Ciencias Aplicadas (UPC), fueron definidos diferentes proyectos que tenan por finalidad el desarrollo de sistemas los cuales, en su conjunto, permitiran implementar una solucin global para la gestin de los procesos mdicos y administrativos del Instituto de Salud del Nio (ISN). Uno de estos proyectos definidos fue el Repositorio Electrnico de Historiales Clnicos (REHC) cuyo objetivo permitira implementar un sistema que centralice la informacin mdica de los pacientes proveniente de los dems sistemas del Proyecto para el ISN. Debido a que muchos de los proyectos definidos en el Proyecto para el ISN, el cual de ahora en adelante ser llamado Sistema de Gestin Mdico (SGM) en el presente documento, no iniciaron su desarrollo en simultneo con el proyecto REHC, estos no pudieron contar con todas las funcionalidades que deban implementarse en el sistema REHC y que eran requeridas en sus sistemas. Por otra parte, se dio inicio al desarrollo del Proyecto Sistema de Seguridad, el cual sera el encargo de brindar los mecanismos necesarios de seguridad y auditoria para todos los sistemas del SGM, incluyendo al sistema REHC. Por los motivos mencionados anteriormente se nos asigna el presente proyecto profesional cuyo objetivo principal es desarrollar una segunda versin del sistema REHC. Mediante el desarrollo de este proyecto se busca implementar aquellas funcionalidades que no fueron desarrolladas en la primera versin del sistema en
mencin, as como apoyar a los dems proyectos en la integracin de sus sistemas con el sistema REHC.
II
CAPTULO 1 FUNDAMENTACIN TERICA 1.1 Dominio del Problema 1.1.1 La Historia Clnica La historia clnica es el documento que contiene la informacin privada de la persona referida a su salud. Como tal, la historia clnica, es un documento estrictamente confidencial. En ella encontraremos informacin detallada de todo lo acontecido con un paciente en cada uno de los encuentros mdicos que haya tenido en el centro de salud tales como las prescripciones mdicas, exmenes practicados, resultados de los anlisis realizados, as como las observaciones encontradas. Adems, este documento es importante ya que permite a los mdicos de diversas especialidades poder realizar un diagnstico ms preciso sobre cualquier padecimiento de los pacientes, ya que es en este documento donde se registra toda la informacin detallada en lo referente a la salud del paciente durante su vida. La informacin presentada en la historia clnica es sensible y confidencial, sta debe ser vigilada por la entidad de salud y slo se debe dar acceso a ella por solicitud expresa del paciente. 1.1.2 El Proyecto Hipcrates Proyecto desarrollado por los egresados de la UPC: Ing. Gaby Mora, Ing. Alex Vidaurre e Ing. Miguel Zegarra en el cual se plantea la arquitectura para una
solucin que permita integrar un mdulo de historias clnicas con los diferentes mdulos que forman parte de un sistema de gestin mdico. Adems plantea la interaccin con sistemas externos. El objetivo del mencionado proyecto fue disear la arquitectura de un sistema que almacene las historias clnicas de los pacientes permitiendo la interaccin con los otros sistemas de salud, adems de definir los mensajes necesarios para el intercambio de informacin con los dems sistemas de salud. El proyecto Hipcrates se delimit como una solucin interna para un centro de salud, que aumente la eficiencia en el manejo de las historias clnicas proveyendo informacin a las reas internas y que pueda comunicarse con otros sistemas externos. Este proyecto se bas en estndares internacionales para la estructura de la informacin, como los estndares ASTM E1384 "Standard Guide for Content and Structure of the Electronic Health Record" y ASTM E1633 "Standard Specification for Coded Values Used in the Electronic Health Record", as como para la transmisin de esta se bas en el estndar Health Level (HL7) que es usado para el intercambio electrnico de datos entre sistemas de informacin vinculados a la atencin mdica. La definicin de esta arquitectura se baso en los patrones de diseo recomendados por Microsoft para el framework 1.11. El Proyecto del Repositorio Electrnico de His torias Clnicas
1.1.3
Proyecto desarrollado por los egresados de la UPC: Ing. Daniel Higa e Ing. Erika Leiblinger en el cual se plantea implementar un sistema que almacene en una base de datos centralizada la informacin mdica del paciente proveniente de los dems sistemas del Sistema de Gestin Mdico, el mismo que tom como base la arquitectura terica propuesta por el Proyecto Hipcrates. Este proyecto tuvo como objetivo general el adaptar la arquitectura y diseo desarrollado por el Proyecto Hipcrates a la realidad del Instituto de Salud del Nio e implementar la versin 1.0 del Repositorio Electrnico de Historias Clnicas
1
Cfr. Mora, 2004 2
(REHC). Adems tuvo como objetivos especficos el desarrollar la versin 1.0 del Repositorio Electrnico de Historias Clnicas, la cual ofrecera servicios que, usando como marco de referencia el estndar de mensajera HL7 y garantizando la seguridad y confiabilidad de la informacin a transmitir, permitan: El registro en la Historia Clnica desde los otros sistemas del Sistema de Gestin Mdico: Admisin, Descarga y Transferencia (ADT), Banco de Sangre, Banco de Tejidos, Ciruga, Consultorios Externos, Emergencia, Enfermera, Farmacia, Hospitalizacin, Imagenologa, Laboratorio Clnico, Laboratorio de Anatoma Patolgica, Nutricin, Seguros, Terapia y Unidad de Cuidados Intensivos (UCI). La consulta de la informacin contenida en la Historia Clnica desde los sistemas arriba mencionados. En resumen, este proyecto se delimit en la construccin de un sistema que solucione los problemas que se presentan actualmente con el manejo de las historias clnicas en documentos fsicos (papel) tales como disponibilidad, transportabilidad, actualizacin de la informacin, costos elevados de gestin, entre otros. Este sistema se encargara de almacenar centralizadamente la informacin del paciente proveniente de los sistemas del Sistema de Gestin Mdico2. 1.1.4 Necesidad del Proyecto REHC 2 En el ao 2002 la facultad de Ingeniera de la Universidad Peruana de Ciencias Aplicadas (UPC) inicia la ejecucin del Proyecto de Desarrollo de Soluciones para la lnea de Salud con el objetivo de implementar una solucin global para la gestin de los procesos mdicos y administrativos del Instituto de Salud del Nio (ISN). Este proyecto fue dividido en 31 proyectos de desarrollo de subsistemas que satisfagan las necesidades del Instituto de Salud del Nio. Estos proyectos fueron clasificados en 3 tipos: Mdicos, Administrativos y de Soporte; dando como resultado la siguiente distribucin3:
2 3
Cfr. Higa, 2005 Cfr. Higa, 2005 3
BANCO DE RGANOS BANCO DE SANGRE Y HEMOTERAPIA PEDIATRA HISTORIAS CLNICAS PEDATRICAS ADMINISTRACIN DE PERSONAL CONTROL PATRIMONIAL
CIRUGA
CONSULTORIOS EXTERNOS
EMERGENCIAS
HOSPITALIZACIN
UNIDAD DE CUIDADOS INTENSIVOS TERAPIA
BANCO DE TEJIDOS
ENFERMERA
NUTRICIN
REPOSITORIO DE HISTORIAS CLNICAS
LABORATORIO CLNICO
IMAGENOLOGA
MATERNIDAD ADMISIN, DESCARGA Y TRANSFERENCIA GESTIN DE SEGUROS DE SALUD SEGURIDAD
LABORATORIO DE HISTORIAS ANATOMA CLNICAS PATOLGICA ODONTOLGICAS COBRANZAS VOCABULARIOS Y PROTOCOLOS MDICOS FARMACIA
LOGSTICA
COMUNICACIONES DATAWAREHOUSE
FACTURACIN HOSPITALARIA
Figura 1: Subsistemas del Proyecto de Desarrollo de Soluciones para la Lnea de Salud
Uno de los proyectos creados fue el proyecto Repositorio Electrnico de Historias Clnicas (REHC) con la finalidad de implementar un sistema que centralice la informacin mdica de los pacientes proveniente de los dems sistemas del SGM. Cabe sealar que muchos de estos proyectos definidos, como por ejemplo los proyectos de Emergencia y Hospitalizacin; por citar algunos, no iniciaron su desarrollo en simultneo con el proyecto REHC. Esto ocasion que estos proyectos, cuando se encontraron en la etapa de desarrollo, no contasen con toda la funcionalidad que deba ser implementada en el sistema REHC y que era requerida por sus respectivos sistemas; as como no contar con personas involucradas del proyecto REHC que los apoyasen en la integracin de sus sistemas con la funcionalidad ya ofrecida por la primera versin del sistema en mencin. Adems, otros proyectos, tales como los proyectos de Historias Clnicas Peditricas e Imagenologa, iniciaron su ejecucin y requeran que el sistema REHC les brinde ciertas funcionalidades, las cuales no haban sido implementadas en la primera versin de este sistema.
Por otra parte, se inici el desarrollo del proyecto Sistema de Seguridad, el cual sera el sistema encargo de brindar los mecanismos necesarios de seguridad y auditoria para todos los sistemas del SGM, incluido el sistema REHC. Por esta razn era necesario adecuar la primera versin del sistema REHC para que contemple la integracin con este sistema. Con todos estos antecedentes se hizo necesario el desarrollo de una segunda versin del sistema REHC. Bajo este contexto nos fue asignado el proyecto REHC versin 2, que tendra como finalidad cubrir todos estos requerimientos mencionados. 1.2 Objetivos del Sistema El desarrollo del Repositorio Electrnico de Historiales Clnicos versin 2 tiene por finalidad cumplir con los objetivos planteados a continuacin. 1.2.1 (REHC). Objetivo s Especficos Desarrollar la versin 2.0 del Repositorio Electrnico de Historias Registro de la informacin de la historia clnica a travs de los sistemas mdicos pertenecientes al sistema integrado de salud; para aquellos cuyo desarrollo ha finalizado (Admisin, Banco de Sangre, Enfermera, Laboratorio Clnico y Maternidad), los que continan en desarrollo (Banco de Tejidos, Ciruga, Consultorios Externos, Emergencia, Hospitalizacin, Laboratorio de Anatoma Patolgica, Nutricin, Unidad de Cuidados Intensivos y Terapia) y los que iniciaron su desarrollo (Historias Clnicas peditricas e Imagenologa). o Consulta de la informacin de la historia clnica desde los sistemas mdicos mencionados en el punto anterior. Objetivo General
Implementar la versin 2.0 del Repositorio Electrnico de Historias Clnicas
1.2.2 o
Clnicas el cual contar con las siguientes funcionalidades:
Implementar la integracin entre el sistema de Historiales Clnicos
Electrnicos y el sistema de Seguridad con la finalidad de establecer un mecanismo de control para el acceso a las funcionalidades ofrecidas por el sistema de Historias Clnicas Electrnicas a los dems sistemas mdicos. Lineamientos a emple ar RUP y UML
1.3
1.3.1
Para el desarrollo de este proyecto se seleccion como proceso de desarrollo de software el Rational Unified Process (RUP) y el Unified Modeling Language (UML) como lenguaje de modelamiento, adems del Rational Rose como herramienta CASE (Computer Aided Software Engineering). La propuesta del RUP es dividir el proceso de desarrollo de software en cuatro fases: Concepcin, Elaboracin, Construccin y Transicin. Cada una de estas fases se realiza de manera iterativa, es decir, en una o varias iteraciones, lo que permite que en cada iteracin se puedan modificar requerimientos, integrar componentes, mitigar riesgos, corregir errores, etc.4 El RUP est basado en seis principios y mejores prcticas para el desarrollo de software: o o
4
Desarrollo de Software Iterativo Gestin de requerimientos Arquitectura Basada en Componentes Modelamiento de Software Visual Verificar la calidad del software continuamente Manejo de los cambios Disciplinas de Ingeniera Modelamiento del Negocio Requerimientos
Adems, dentro de cada fase, las tareas son categorizadas en nueve disciplinas:
Cfr. Jacobson, 1998. 6
o o o o o o o
Anlisis y Diseo Implementacin Pruebas Despliegue Disciplinas de Soporte Administracin de la Configuracin y Cambios Administracin del proyecto Entorno
El proceso tambin define: Roles: Define un juego de habilidades, competencias y responsabilidades. Artefactos: Representa el resultado de una tarea, incluyendo Tareas: Describe una unidad de trabajo asignada a un Rol que documentos, modelos, prototipos, componentes, etc. proporciona un resultado significante. Se seleccion el Unified Modeling Language (UML) como lenguaje de modelacin debido a que es un lenguaje estndar para visualizar, especificar, construir y documentar un sistema. Adems, nos proporciona una manera estndar de escribir los planos para los sistemas que debemos construir. 1.3.2 Manejador de Base de Datos
El Manejador de Base de Datos seleccionado fue el MS SQL Server 2000. MS SQL Server 2000 es un Sistema de Administracin de Base de Datos Relacinales de Microsoft (RDBMS, Relational Database Management System) que se encarga de: anlisis. Mantener las relaciones de la informacin en la base de datos. Asegurar que la informacin es almacenada correctamente y que Administrar el almacenamiento de informacin para transacciones y
las reglas definidas para las relaciones de la informacin no sean violadas.
Responder a solicitudes de aplicaciones clientes.
El motor de base de datos esta conformado por dos componentes: El motor Relacional, el cual se encarga de analizar instrucciones Transact-SQL, optimizar y ejecutar planes de ejecucin, procesar el lenguaje de definicin de informacin y ejecutar la seguridad. El motor de Almacenamiento, el cual se encarga de administrar los archivos de base de datos y el uso del espacio en estos archivos, construir y leer informacin de pginas fsicas, controlar la concurrencia, ejecutar operaciones de recuperacin (logging) e implementar funciones de utilidad como backup y restauracin. Tambin cuenta con procedimientos almacenados (Stored Procedure) los cuales son un grupo de instrucciones Transact-SQL que se encuentran precompiladas, agrupadas bajo un nombre y que son ejecutadas como una sola unidad5. 1.3.3 Lenguaje de Programacin
El lenguaje de programacin propuesto por el proyecto Hipcrates fue el Visual C# correspondiente al Framework 1.1 de Visual Studio .NET. Visual C# es un lenguaje de programacin que permite desarrollar aplicaciones Windows, Web y Servicios Web. Visual C# soporta programacin Orientada a Objetos, incluyendo herencia, sobrecarga operativa y funciones virtuales. Adems, el Visual C# tiene similitud con Java, lo que permite a desarrolladores con conocimiento en este lenguaje, poder adaptarse ms rpido a el. Todos los objetos definidos en Visual C# derivarn de la clase System.Object, por lo que contaran con todos los miembros definidos en esta clase. Una ventaja del lenguaje es que tiene soporte innato para la generacin de documentacin basada en XML (eXtensible Markup Language).
Cfr. Microsoft SQL Server: http://www.microsoft.com/spain/sql/default.mspx 8
CAPTULO 2 REQUERIMIENTOS DEL SISTEMA 2.1 Requerimientos Funcionales En esta seccin se describen las caractersticas funcionales con las que contar la segunda versin del sistema REHC. Se definen los actores y casos de uso del sistema, as como la agrupacin de estos en paquetes. 2.1.1 Actores
Son aquellas entidades externas al sistema que interactan con l. Por la estructura del proyecto, son todos aquellos sistemas que solicitan servicios de informacin al sistema REHC 2.0. A continuacin se da una breve descripcin de cada uno de los actores involucrados6. 2.1.1.1 Banco de Sangre
Sistema encargado de la gestin de transfusiones, as como de la consulta de los antecedentes clnicos del paciente y de los resultados de las transfusiones. 2.1.1.2 pacientes. 2.1.1.3 Ciruga Banco de Tejidos
Sistema encargado de la administracin de tejidos que sern usados en los
Sistema encargado de registrar los procedimientos y operaciones quirrgicas.

6
Cfr. Higa, 2005 9
2.1.1.4
Consultorios Externos
Sistema encargado de registrar y consultar los encuentros mdicos, ordenes, diagnsticos, evoluciones y prescripciones de un paciente en el consultorio. 2.1.1.5 Dieta
Sistema encargado del registro de dietas preparadas a los pacientes hospitalizados. 2.1.1.6 Emergencias
Sistema encargado de registrar las notas, procedimientos realizados e incidencias cuando el paciente ingresa por la sala de emergencia. 2.1.1.7 Enfermera
Sistema encargado de registrar los servicios de tratamientos, dietas, medicacin y las notas de enfermera del curso clnico de los pacientes. 2.1.1.8 Hospitalizacin
Sistema encargado de registrar todas las incidencias y procedimientos realizados al paciente durante su permanencia en la entidad de salud internado. 2.1.1.9 Imagenologa
Sistema encargado de registrar y consultar los resultados de las rdenes de observacin o pruebas de diagnsticos por medio de imgenes. 2.1.1.10 Laboratorio Clnico Sistema encargado de registrar y consultar los resultados de los anlisis clnicos realizados como apoyo al diagnstico. 2.1.1.11 Laboratorio Patolgico Sistema encargado de registrar y consultar los resultados de los anlisis clnicos o pruebas de diagnsticos ya sea una biopsia, citologa o necropsia realizados como apoyo al diagnstico mdico.
10
2.1.1.12 Pediatra Sistema encargado del registro de notas y procedimientos de nios y recin nacidos. 2.1.1.13 Terapia Sistema encargado de registrar el servicio y los resultados de las rdenes de terapia. 2.1.1.14 Unidad de Cuidados Intensivos (UCI) Sistema encargado de registrar las notas y procedimientos del cuidado intensivo del paciente.
Sistema Salud
Banco de Sangre
Ciruga
Dieta
Enfermera
Imagenologa
Laboratorio Patolgico
Terapia
Banco de Tejidos
Consultorios Externos
Emergencias
Hospitalizacin
Laboratorio Clnico
Pediatra
Unidad de Cuida...
Figura 2: Actores del Sistema
2.1.2 Casos de Uso del Sistema De acuerdo a los requerimientos de los actores presentados en el punto anterior, se identificaron los siguientes casos de uso. Todos estos casos de uso se encuentran definidos en base a los acuerdos y contratos firmados con cada uno de los clientes en la primera versin del sistema REHC7.
Cfr. Higa, 2005. 11
La funcionalidad del sistema REHC versin 2.0, al igual que la versin 1.0, fue clasificada en cinco paquetes: Paciente Encuentro Observaciones Orden Servicios
A continuacin, se describir cada uno de ellos. 2.1.2.1 paciente. 2.1.2.2 CUPA01 Afiliar Paciente. CUPA02 Consultar Informacin Demogrfica del paciente. Paquete Encuentro Paquete Paciente
Contiene la funcionalidad relacionada al registro y consulta de la informacin del
Contiene la funcionalidad relacionada al registro y consulta de la informacin que resulta del encuentro de un paciente con un mdico. 2.1.2.3 CUEN01 Actualizar Informacin Administrativa del Encuentro. CUEN02 Consultar Informacin Administrativa del Encuentro. CUEN03 Actualizar Reporte de Ciruga. CUEN04 Consultar Reporte de Ciruga. CUEN05 Actualizar Epicrisis. CUEN06 Consultar Epicrisis. CUEN07 Actualizar Informacin de Prescripcin. CUEN08 Consultar Informacin de Prescripcin. Paquete rdenes
Contiene la funcionalidad relacionada al registro y consulta de la informacin de las rdenes emitidas a un paciente. CUOR01 Actualizar Orden.
12
Las rdenes a registrar son las siguientes: Administrativa, Biopsia, Citologa, Dieta, Imgenes, Inmunizacin, Laboratorio Clnico, Medicacin, Necropsia, Tejido y Terapia. CUOR02 Consultar Orden. Las rdenes a consultar son las siguientes: Administrativa, Biopsia, Citologa, Dieta, Imgenes, Inmunizacin, Laboratorio Clnico, Medicacin, Necropsia, Tejido y Terapia. Paquete Observaciones
2.1.2.4
Contiene la funcionalidad relacionada al registro y consulta de la informacin relacionada a las observaciones realizadas al paciente y el resultado de sus rdenes. CUOB01 Actualizar Antecedentes Clnicos. Los antecedentes a registrar son: Alergia, General, Hbito, Histrico, Medicacin, Patolgico y Quirrgico CUOB02 Consultar Antecedentes Clnicos. Los antecedentes a consultar son: Alergia, General, Hbito, Histrico, Medicacin, Patolgico y Quirrgico CUOB03 Actualizar Examen Fsico. CUOB04 Consultar Examen Fsico. CUOB05 Actualizar Problema - Diagnstico. CUOB06 Consultar Problema - Diagnstico. CUOB07 Actualizar Signos Vitales. CUOB08 Consultar Signos Vitales. CUOB09 Actualizar Nota de Enfermera. CUOB10 Consultar Nota de Enfermera. CUOB11 Actualizar Curso Clnico. CUOB12 Consultar Curso Clnico. CUOB13 Actualizar Resultado de Orden de Apoyo al Diagnstico.
Los resultados a registrar son: Macro Biopsia, Macro Citologa, Macro Necropsia, Micro Biopsia y Micro Citologa. CUOB14 Consultar Resultado de Orden de Apoyo al Diagnstico.
13
Los resultados a consultar son: Macro Biopsia, Macro Citologa, Macro Necropsia, Micro Biopsia y Micro Citologa. 2.1.2.5 CUOB15 Actualizar Encuentro de Nebulizacin. CUOB16 Consultar Encuentro de Nebulizacin. CUOB17 Actualizar Nebulizaciones. CUOB18 Consultar Nebulizaciones. CUOB19 Actualizar Corticoides. CUOB20 Consultar Corticoides. Paquete Servicios
Contiene la funcionalidad relacionada al registro y consulta de la informacin relacionada a los servicios que ha recibido un paciente. CUSE01 Actualizar Servicio de Dieta. CUSE02 Consultar Servicio de Dieta. CUSE03 Actualizar Servicio de Terapia. CUSE04 Consultar Servicio de Terapia. CUSE05 Actualizar Servicio de Medicacin. CUSE06 Consultar Servicio de Medicacin. CUSE07 Actualizar Servicio de Inmunizacin. CUSE08 Consultar Servicio de Inmunizacin.
La descripcin detallada de cada uno de estos casos de uso se encuentra en el documento de tesis presentado por el Proyecto REHC versin 1.08. Cabe indicar que hubo Casos de Uso que no fueron implementados en la primera versin del sistema REHC. Estos Casos de Uso fueron los siguientes:
8
Actualizar Encuentro de Nebulizacin Consultar Encuentro de Nebulizacin Actualizar Nebulizacin Consultar Nebulizacin Actualizar Corticoide Consultar Corticoide
Cfr. Higa, 2005. 14
Actualizar Orden de Inmunizacin Consultar Orden de Inmunizacin Registrar Transfusin de Sangre Consultar Transfusin de Sangre
En la presente versin del sistema REHC no fueron implementados los Casos de Uso Registrar Transfusin de Sangre y Consultar Transfusin de Sangre debido a que el proyecto Banco de Sangre, cuyo sistema a desarrollar sera el consumidor de estos, no llego a iniciar su desarrollo. Por este motivo estos requerimientos no fueron priorizados. 2.1.3 Priorizacin y Clasificacin de los Casos de Uso Se hizo una evaluacin completa de los casos de uso a implementar y de los casos de uso que ya estaban implementados y que deban ser modificados. Luego de esta evaluacin se separaron todos los casos de uso en tres entregas (releases). Cada caso de uso fue priorizado de acuerdo a una serie de aspectos, asignndoseles un puntaje de entre 0 y 5 puntos (siendo 5 el ms alto). Estos aspectos fueron los siguientes: Premura: Se refiere a la urgencia con que se necesita que la funcionalidad ofrecida por el caso de uso este implementada. Este fue uno de los factores determinantes y que tuvo mayor peso. Complejidad: Este aspecto se refiere a la cantidad de tablas que se utilizan en la implementacin del caso de uso, los sistemas que consumen la funcionalidad brindada por el caso de uso y la cantidad de operaciones y clculos que realiza esta. Riesgo: Es para toda funcionalidad ofrecida por el caso de uso que de funcionar de manera incorrecta impactara negativamente en el funcionamiento del producto final, mientras ms severa la influencia es mayor el puntaje asignado.
15
El detalle de esta priorizacin de casos de uso se encuentra en el anexo A del presente documento. En base a la priorizacin se obtuvo la siguiente distribucin de casos de uso por entrega: Release 1: Release 2: CUEN05 Actualizar Epicrisis. CUEN06 Consultar Epicrisis. CUEN07 Actualizar Informacin de Prescripcin. CUEN08 Consultar Informacin de Prescripcin. CUOR01 Actualizar Orden. CUOR02 Consultar Orden. CUOB01 Actualizar Antecedentes Clnicos. CUOB02 Consultar Antecedentes Clnicos. CUOB03 Actualizar Examen Fsico. CUOB04 Consultar Examen Fsico. CUOB05 Actualizar Problema - Diagnstico. CUOB06 Consultar Problema - Diagnstico. CUOB07 Actualizar Signos Vitales. CUOB08 Consultar Signos Vitales. CUOB15 Actualizar Encuentro de Nebulizacin. CUOB16 Consultar Encuentro de Nebulizacin. CUOB17 Actualizar Nebulizaciones. CUOB18 Consultar Nebulizaciones. CUOB19 Actualizar Corticoides. CUOB20 Consultar Corticoides. CUPA01 Afiliar Paciente. CUPA02 Consultar Informacin Demogrfica del paciente. CUEN01 Actualizar Informacin Administrativa del Encuentro. CUEN02 Consultar Informacin Administrativa del Encuentro.
16
Release 3:
CUOB11 Actualizar Curso Clnico. CUOB12 Consultar Curso Clnico. CUOB13 Actualizar Resultado de Orden de Apoyo al Diagnstico. CUOB14 Actualizar Resultado de Orden de Apoyo al Diagnstico.
Integracin Paquete Pacientes con Sistema Seguridad. Integracin Paquete Encuentros con Sistema Seguridad. Integracin Paquete rdenes con Sistema Seguridad. Integracin Paquete Observaciones con Sistema Seguridad. Integracin Paquete Servicios con Sistema Seguridad.
2.2 Requerimientos No Funcionales Son aquellos requerimientos que dada su naturaleza no pueden ser representados en el modelo de casos de uso. 2.2.1 Funcionalidad Todos los errores internos, ya sean de base de datos o
componentes del sistema, sern capturados y devueltos al sistema que invoc al servicio y en el cual se produjo el error. Estas excepciones estarn documentadas en una librera que almacenara los cdigos que identifican al error que se haya producido en el sistema. Se implementar un servicio de auditoria el cual permitir almacenar la informacin del nombre de la tabla en la cual se esta modificando la informacin, el sistema que la modifica, el usuario del sistema que modifica la informacin, la fecha de modificacin del registro y la data del registro antes de su modificacin; esto con la finalidad de poder mantener un registro de la evolucin de la informacin en el tiempo. Debido a que el sistema REHC 2.0 es un sistema transaccional, las operaciones que se realicen sobre este debern cumplir las siguientes caractersticas:
17
Atomicidad: Es la propiedad que asegura que la operacin se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias. Consistencia: Es la propiedad que asegura que slo se empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos. Aislamiento: Es la propiedad que asegura que una operacin no puede afectar a otras. Esto asegura que la realizacin de dos transacciones sobre la misma informacin nunca generar ningn tipo de error. Durabilidad: es la propiedad que asegura que una vez realizada la operacin, sta persistir y no se podr deshacer aunque falle el sistema.
2.2.2
Seguridad
El sistema REHC 2.0 estar integrado con el Sistema de Seguridad versin 1.0 para implementar la validacin de los accesos a los servicios ofrecidos por el sistema de Historias Clnicas Electrnicas a los dems sistemas del SGM. 2.2.3 Portabilidad
El sistema funcionar bajo cualquier plataforma Windows con compatibilidad con el .NET Framework 1.1, esto quiere decir, bajo Windows 2000 y Windows XP.
18
CAPTULO 3 DISEO ARQUITECTNICO 3.1 Arquitectura propuesta por el Proyecto REHC 1.0 La arquitectura propuesta por el proyecto Hipcrates, la cual sirvi como base para la implementacin del Repositorio Electrnico de Historias Clnicas versin 1.0, y que a su vez se tom como base para la versin 2.0, fue representada siguiendo los lineamientos y recomendaciones propuestos por el RUP. Esta arquitectura esta compuesta de 5 vistas. a) Modelo de Casos de Uso (Vista de Casos Uso): Presenta la funcionalidad del sistema representada en Casos de Uso. b) Modelo de Diseo (Vista Lgica): Conformado por las clases de diseo, que definen el comportamiento del sistema. c) Modelo de Implementacin (Vista de Componentes): Conformado por los componentes del sistema, muestra la organizacin y dependencia de estos componentes en el sistema. d) Modelo de Despliegue (Vista de Despliegue): Modela la topologa del Hardware sobre el cual correr el sistema y nos indica en donde se ejecutara cada uno de los componentes del sistema.
19
e) Modelo de Base de Datos (Vista de Base de Datos): Presenta la organizacin de la informacin que almacena el sistema en un modelo Entidad / Relacin. En el presente documento solo se revisarn las Vistas Lgica y de Componentes propuesto por el Proyecto REHC versin 1.0, ya que estas nos servirn de base para la implementacin del proyecto REHC versin 2.0. 3.1.1 Vista Lgica
Presenta 3 capas: Lgica Empresarial, Acceso a Datos y Comunes.

<<layer>> Lgica Empresarial Interfaces de Servicio Global
global
<<layer>> Comunes
Controladoras
Lgica de Negocio
Entidades Empresariales DTO

global
<<layer>> Acceso a Datos Seguridad Agentes de Servicio Componentes Lgicos de Acceso a Datos
global
Figura 3: Elementos de diseo de la Vista Lgica implementados por REHC 1.0
3.1.1.1
Lgica Empresarial
La capa de Lgica Empresarial implementa la funcionalidad del REHC 1.0. Esta compuesta por Interfaces de Servicios, Controladoras, Lgica de Negocio y Entidades Empresariales. a) Interfaces de Servicio Permiten exponer la funcionalidad del sistema REHC 1.0, a travs de servicios, a los dems sistemas del SGM para que estos puedan actualizar
20
o consultar la informacin que este almacena. Esta interaccin se realiza en base a contratos de comunicacin definidos entre el sistema REHC 1.0 y los dems sistemas del SGM. b) Controladoras Definen y coordinan los procesos empresariales que conllevan varios pasos de ejecucin larga. Estos se pueden implementar utilizando herramientas de administracin de procesos empresariales, como BizTalk Server Orchestration. c) Lgica de Negocio Implementan la lgica empresarial de la aplicacin, independientemente de si el proceso empresarial consta de un solo paso o un flujo de trabajo. Estos definen las reglas y tareas empresariales de la aplicacin. d) Entidades Empresariales Representan las clases entidades identificadas en el anlisis. Estos permiten el paso de datos a travs de las distintas capas de la aplicacin. 3.1.1.2 Acceso a Datos
Contiene los componentes que permiten obtener la informacin que el sistema necesita. Esta compuesta de: a) Componentes Lgicos de Acceso a Datos Permiten acceder a un almacn de datos en un momento determinado del proceso empresarial, ya sea para consultar o actualizar la informacin almacenada. b) Agentes de Servicio Permiten hacer uso de la funcionalidad proporcionada por otra aplicacin o servicio externo.
21
3.1.1.3
Capa Comunes
Este paquete contiene los componentes de visibilidad global que sern utilizados por los componentes que se encuentran definidos en las capas de Lgica Empresarial y de Acceso a Datos. Esta compuesta por: a) Global Permite manejar la conexin a la base de datos del sistema, estableciendo los parmetros de conexin con los cuales se acceder a esta ltima. Adems, genera los mensajes con la informacin del xito o fallo de la transaccin. b) DTO Son implementados para la transferencia de datos entre el sistema REHC y los dems sistemas del SGM que solicitan actualizaciones. c) Seguridad Maneja la seguridad interna del sistema, validando si el sistema que consume el servicio cuenta con el permiso necesario para acceder a esta. 3.1.2 Vista de Componentes La estructura de los componentes esta divida en: Lgica Empresarial, Acceso a Datos y Comunes.
Lgica Empresarial
Comunes
Acceso a Datos BDHC
Figura 4: Paquetes de componentes implementados por REHC 1.0
22
3.1.2.1
Lgica Empresarial
Contiene las interfaces de servicio, las controladoras, las clases de lgica de negocio y las entidades empresariales. La nomenclatura de estos componentes tuvo la siguiente regla: [Nombre del paquete].[Siglas de la funcin].dll. Donde:
[Nombre del paquete] = Paciente, Encuentros, Observaciones, Ordenes, Servicios. [Siglas de la funcin] = IS, CC, LN, EE.
3.1.2.2
Acceso a Datos
Contiene los componentes de Acceso a Datos y los Agentes de Servicio. La nomenclatura para los componentes de este paquete tuvo el formato:
[Nombre del paquete].DAL.dll y [Nombre del paquete].AS.dll.

3.1.2.3 Comunes
Contiene los componentes de Seguridad, DTO, las Bases, Administrador de la configuracin y las referencias al proyecto Microsoft.ApplicationDataBlock para simplificar el trabajo de los componentes de Acceso a Datos (DAL). Todos estos son encapsulados en un nico componente llamado Global.dll. Arquitectura de Software propuesta en el presente Proyecto
3.2
Luego de revisar la arquitectura propuesta por la primera versin del proyecto REHC, se realizaron los siguientes cambios los cuales se veran reflejados en la arquitectura de software propuesto por el presente proyecto. a) No implementar el componente Flujos de Trabajo Empresariales de la Capa Empresarial. En la presente versin del sistema se vio conveniente no implementar el componente Flujos de Trabajo Empresariales, definido como Controladoras en la versin 1.0 del REHC, debido a que los procesos empresariales que implementa el sistema REHC constan de un solo paso independiente y estos pueden establecerse en un solo componente empresarial. Los Flujos de Trabajo Empresariales deben ser implementados cuando los procesos
23
empresariales conllevan una serie de pasos para completar una tarea y estos deben ser organizados y ejecutados en un orden especfico. Con esto se busco darle simplicidad a la arquitectura del sistema y facilitar su mantenimiento. Para este punto se sigui la propuesta de las guas de diseo de arquitectura de aplicaciones .NET publicadas por Microsoft9. b) No implementar el componente Entidades Empresariales de la Capa Empresarial. Esta versin del sistema no considerar la implementacin de los componentes Entidades Empresariales para la transferencia de informacin a travs de los distintos niveles o capas definidas en la arquitectura, ya que la implementacin de estos componentes requiere una implementacin de serializacin personalizada y puede repercutir negativamente en el rendimiento del sistema. En lugar de estos componentes se utilizarn los Objetos de Transferencia de Datos (DTOs) para la transferencia de la informacin entre los distintos niveles de la arquitectura. c) Reestructuracin del Componente Global. El componente Administrador de la Configuracin, que forma parte del componente Global y el cual es el encargado de manejar la conexin a la Base de Datos del Sistema, fue separado del componente Global hacia otro componente llamado Master, con la finalidad de que los componentes de la Capa de Acceso a Datos sean los que nicamente puedan referenciar a este componente y no los componentes de las dems capas definidas. d) Eliminacin del componente Seguridad de la Capa Comunes. Se elimin el componente Seguridad de la Capa Comunes y toda referencia a este componente debido a que la versin 2.0 del sistema REHC utilizar los servicios ofrecidos por el Sistema de Seguridad para la verificacin y validacin de los accesos a los servicios ofrecidos por el sistema a los dems sistemas del SGM.
9
Cfr. Microsoft: http://www.microsoft.com/spanish/msdn/arquitectura/das/distapp.mspx 24
e) Inclusin del componente Parmetros de Bsqueda en la Capa Comunes. El componente Parmetros de Bsqueda fue incluido como parte de la capa Comunes. f) Implementacin de un Servicio de Auditoria. Este servicio permitir almacenar toda la informacin necesaria para la auditoria al sistema, como son, la informacin que se modifica, la persona que realiza la modificacin y la fecha y hora en que se realiza esta. Con esto ya no fue necesario mantener los campos de auditoria definidos en cada tabla de la base de datos. A continuacin se describir cada vista utilizada para la representacin de la Arquitectura del Sistema de este proyecto. 3.2.1 Vista Lgica
Se mantiene la agrupacin de los elementos de diseo en tres capas propuesto por la primera versin del Proyecto REHC: Lgica Empresarial, Acceso a Datos y Comunes.
<<layer>> Comunes
<<layer>> Logica Empresarial
Global
Componentes Empresariales
Interfaces de Servicio
DTOs
<<layer>> Acceso a Datos Parametros de Busqueda Componentes Logicos de Acceso de Datos Agentes de Servicio
Figura 5: Elementos de diseo de la Vista Lgica que implementar REHC 2.0
25
3.2.1.1
Capa Lgica Empresarial
La capa Lgica Empresarial implementa toda la funcionalidad del sistema REHC 2.0. De acuerdo a los puntos expuestos sobre la arquitectura de software propuesta en el presente proyecto, esta capa solo se compone de los paquetes Interfaces de Servicios y Componentes Empresariales. El paquete de Interfaces de Servicio mantiene la misma definicin planteada por el proyecto REHC 1.0 y en el caso del Paquete Componentes Empresariales, este hace referencia al paquete Lgica del Negocio planteada por el proyecto REHC 1.010. El servicio de Auditoria, a pesar de haber sido implementado en el presente proyecto, no se considerar como parte de la solucin final ya que este se ejecutar como un servicio externo al igual que el servicio que es brindado por el Sistema de Seguridad. 3.2.1.2 Capa Acceso a Datos
Esta capa contiene los componentes que permiten acceder a la informacin que el sistema necesita. Se mantiene lo planteado por el proyecto REHC 1.0 respecto a esta capa, es decir, se cuenta con los paquetes de Componentes Lgicos de Acceso de Datos y Agentes de Servicio. 3.2.1.3 Capa Comunes
Esta capa contiene los componentes que sern usados de manera comn por los componentes de la capa de Lgica Empresarial y los componentes de la capa de Acceso a Datos. A diferencia de lo planteado por el proyecto REHC 1.0 respecto a esta capa, el paquete Global fue modificado, se elimin el paquete Seguridad y se agreg el paquete Parmetros de Bsqueda, todo esto segn lo especificado anteriormente en la arquitectura de software propuesta en el presente proyecto. El Paquete DTO mantiene la definicin planteada por el proyecto REHC 1.0.
a) Global
10
Cfr. Higa, 2005 26
Permite manejar los mensajes con la informacin del xito o fallo de la transaccin. b) Parmetros de Bsqueda Permiten manejar los parmetros con los cuales el sistema REHC 2.0 buscar la informacin solicitada por los dems sistemas del SGM. 3.2.2 Vista de Componentes
Los componentes estn agrupados en Lgica Empresarial, Acceso a Datos y Comunes.
Lgica Empresarial
Comunes
Acceso a Datos
DBHC
Figura 6: Paquetes de Componentes que implementar REHC 2.0
3.2.2.1
Lgica Empresarial
Este paquete contempla la funcionalidad del sistema. Est conformado por las Interfaces de Servicio y Componentes Empresariales. Los nombres de los componentes de este paquete sern los siguientes: Interfaces de Servicio: SGHCE.[Nombre del Paquete].IS.dll Componentes Empresariales: SGHCE.CE.dll
27
Donde Nombre del Paquete puede ser: Paciente, Encuentro, Observaciones, Orden o Servicios. 3.2.2.2 Acceso a Datos
Este paquete se encarga de interactuar directamente con la Base de Datos del Sistema y con las fuentes de informacin externas. Esta conformada por los Componentes Lgicos de Acceso a Datos (DAL) y los Agentes de Servicio. El nombre del componente Lgico de Acceso ser: 3.2.2.3 SGHCE.DAL.dll Comunes
Este paquete contiene bsicamente los componentes que sern usados de manera comn por los dems paquetes del sistema. Esta conformado por los componentes Global, Objetos de Transferencias de Datos (DTO) y Parmetros de Bsqueda. El nombre para estos componentes ser: 3.2.3 Global: SGHCE.Global.dll DTO: SGHCE.DTO.dll Parmetros de Bsqueda: SGHCE.Parametros.dll Vista de Despliegue
La definicin de los requerimientos especficos de hardware no forma parte de este proyecto, pero a pesar de ello se incluye la propuesta del despliegue de software a nivel institucional. Podemos apreciar la interaccin de los siguientes sistemas: Sistema REHC Sistema de Seguridad Sistema de Vocabularios Sistema Interno (cualquiera de los sistemas mdicos, por ejemplo:
Ciruga, Consultorio Externo, Emergencias, Hospitalizacin, Laboratorio Clnico, Pediatra, Terapia, etc.)
28
BD
MS SQL Server 2000
BD
BD
REHC Servidor BD
Paciente (COM+) Encuentro (COM+) Observaciones (COM+) Orden (COM+) Servicios (COM+) Auditoria (COM+) .NET Framework 1.1
SEGURIDAD Servidor BD
VOCABULARIO Servidor BD
REHC Servidor Aplicaciones
SEGURIDAD Servidor Aplicaciones
VOCABULARIO Servidor Aplicaciones
PC Cliente SERVIDOR INTERNO Servidor Aplicaciones SERVIDOR INTERNO Servidor Web / Presentacin
BD SERVIDOR INTERNO Servidor BD
Figura 7: Despliegue del Proyecto Desarrollo de Soluciones para la Lnea de Salud
Segn la figura 7 tenemos lo siguiente: Todos los componentes del sistema REHC estarn alojados en un servidor de aplicaciones y la base de datos se encuentra en un servidor independiente de base de Datos. Los Sistemas Internos solicitarn servicios al sistema REHC a travs Los componentes del Sistema de Seguridad estarn alojados en un del Servidor de Aplicaciones. servidor de aplicaciones distinto al del sistema REHC y estos validarn el acceso a los servicios expuestos por parte del sistema REHC hacia los dems Sistemas Internos. La base de datos del Sistema de Seguridad tambin estar alojado en otro servidor independiente. Los componentes del Sistema de Vocabularios, los cuales proporcionan la definicin de los cdigos manejados en el sistema REHC y los
29
sistemas mdicos, estarn alojados tambin en otro servidor de aplicaciones distinto a los mencionados anteriormente. La base de datos de este sistema tambin se encontrar alojado en un servidor independiente. 3.3 Lineamientos a emplear Al igual que el proyecto REHC 1.0, el mecanismo seleccionado para dar soporte a las transacciones distribuidas del sistema REHC 2.0 son los servicios de COM+. Para el uso de los servicios de COM+, se utiliza la programacin basada en atributos, la cual consiste en utilizar atributos que permitan conocer al servidor de componentes que servicio prestar a cada componente definido en la aplicacin COM+. Por otra parte, Enterprise Services (COM+) son una clara opcin para constituir el entorno host para los componentes empresariales. Enterprise Services ofrecen a los componentes seguridad basada en funciones, control de transacciones heterogneo, agrupacin de objetos e interfaces basadas en mensajes a travs de componentes en cola (entre otros) 11. La siguiente tabla muestra todos los valores posibles que puede tener el atributo transaccin de un objeto COM+.
Atributo Transaccin Requerida (Required) Requerida Nueva (Required New) Soportada (Supported) Descripcin Utilice esta opcin para aquellos componentes que puedan ser la raz de una transaccin o que participarn en transacciones existentes. Utilice esta opcin si desea que el componente inicie una nueva transaccin independiente de las transacciones existentes. Utilice esta opcin para aquellos componentes que no requieren necesariamente una transaccin, pero que desea que participen en una transaccin existente, si es que hay una. Utilice esta opcin si no desea que el componente participe en transacciones. El objeto ignora por completo el atributo transaccin cuando determina la situacin del contexto. Esta situacin hace que un componente configurado se comporte como uno no configurado.
No Soportada (Not Supported) Deshabilitada (Disabled)
11
Cfr. Microsoft, 2006 30
CAPTULO 4 DISEO DETALLADO DEL SISTEMA 4.1 Diseo de Base de Datos En esta seccin se presentar el Modelo Entidad / Relacin de la Base de Datos del sistema REHC 2.0. El diagrama de Base de Datos tendr la misma estructura de la primera versin del sistema REHC con la variante de la adicin de algunas tablas para soportar los procesos que no fueron implementados en la primera versin, as como eliminar de las tablas existentes los campos de auditoria definidas en cada una de ellas, ya que en lugar de ello se defini una tabla adicional, en la cual se almacenar toda la informacin necesaria para la auditoria al sistema, como es la informacin que se modifica, la persona que realiza la modificacin y la fecha y hora en que se realiza esta. 4.1.1 Tablas
Para facilitar la lectura del documento, el diagrama de la base de datos del sistema REHC 2.0 se encuentra en el Anexo B del presente documento. 4.1.2 Diccionario de Datos Se prepar un diccionario de datos el cual presenta el detalle de cada tabla de la Base de Datos, indicando que campos componen la tabla, cuales de ellos son llaves primarias, el tipo de dato que almacenan, su longitud y si permite valores null o no. Este documento se encuentra en el Anexo C.
31
4.2 Diseo de Clases En esta seccin se detalla el diseo de la arquitectura de software, presentando a detalle las clases de diseo que componen cada capa de la arquitectura de software expuesta en el capitulo anterior. El detalle de los atributos y operaciones de estas clases se encuentran en el Modelo Rose que se adjunta en el CD. Clases que implementan los componentes de la capa Lgica
4.2.1
Empresarial La capa Lgica Empresarial contiene los paquetes Interfaces de Servicio y Componentes Empresariales.
<<layer>> Logica Empresarial
Figura 8: Paquetes de la capa de diseo Lgica Empresarial
4.2.1.1
Las Interfaces de Servicio dependen de los Componentes Empresariales. Las clases de tipo Interfaz de Servicio son nombradas con el sufijo IS para una mejor identificacin de estas. Las clases de tipo Interfaz de Servicio han sido agrupadas de la misma manera que los casos de uso, es decir, estn agrupadas en: Paciente, Encuentros, Observaciones, rdenes y Servicios. A continuacin presentamos el diagrama de ellas, mostrando la interfaz que implementan.
32
InfoDemograficaIS
(f rom PacienteIS)
AntecedenteIS
(f rom Observ acionesIS)
IInfoDemograci aIS
(f rom PacienteIS)
IAntecedenteIS
EncuentroIS
(f rom EncuentroIS)
ExamenFisicoIS
IEncuentroI S
(f rom EncuentroIS) ...)
IExamenFisicoIS
OrdenIS
(f rom OrdenIS)
CursoClinicoIS
IOrdenIS
(f rom OrdenIS)
ICursoClinicoIS
ServicioDietaIS
(f rom Serv iciosIS)
ProblemaIS
IServicioDiet aIS
(f rom Serv iciosIS) ...)
IProblemaIS
ServicioInmunizacionIS
ResultadoIS
IServicioInmuni zacionIS
IResultadoIS
ServicioMedicacionIS
EncNebulizacionIS
IServicioMedica cionIS
IEncNebulizacionIS
ServicioTerapiaIS
IServicioTerapiaI S
Figura 9: Clases Interfaces de Servicio y sus interfaces
4.2.1.2
Los Componentes Empresariales dependen de los componentes de Acceso a Datos descritas en el punto 4.2.2.1 de este documento. Estos componentes estn agrupados de la misma manera que las Interfaces de Servicio. Las clases de tipo Componente Empresarial son nombradas con el sufijo CE para una mejor identificacin de estas.
33
InfoDemograficaCE
(from PacienteCE)
EncuentroAdministrativoCE
(from EncuentroCE)
OrdenCE
(from OrdenCE)
CursoClinicoCE
(from ObservacionesCE)
ExamenFisicoCE
NebulizacionesCE
ProblemaCE
AntecedenteCE
ResultadoCE
ServicioCE
(from ServiciosCE)
Figura 10: Clases Componentes Empresariales
4.2.2
Clases que implementan los componentes de la capa Acceso a
Datos La capa de Acceso a Datos contiene los paquetes Componentes Lgicos de Acceso a Datos y Agentes de Servicio. En esta versin del sistema REHC no se implementar ningn Agente de Servicio, por lo que no se har referencia en este documento a ninguno de estos elementos.
<<layer>> Acceso a Datos
Componentes Logicos de Acceso de Datos
Agentes de Servicio
Figura 11: Paquetes de la capa de diseo Acceso a Datos
4.2.2.1
Componentes Lgicos de Acceso a Datos
Los Componentes Lgicos de Acceso a Datos (DALC por sus siglas en ingls Data Acces Layer Component) permiten interactuar directamente con la base de datos
34
del sistema para poder recuperar y registrar la informacin de los dems sistemas. Todas las clases de este paquete heredan de la clase BaseDAL, la cual contiene todos los atributos y operaciones comunes de las clases de acceso a datos. Esta clase a su vez depende de dos clases para poder realizar las operaciones que implementa: AdministradorConfig: Se encarga de obtener la cadena de conexin a la base de datos del sistema, encriptndola y desencriptndola para que no pueda ser obtenida por ningn agente externo al sistema. SQLHelper: Proporciona un conjunto de mtodos para ejecutar varios tipos de comandos diferentes contra una base de datos SQL Server. Esta clase fue tomada del Bloque de Aplicacin de Acceso a Datos (Data Access Application Block) liberada por Microsoft en Patterns & Practices Enterprise Library12.
AdministradorConfig Ad minis rad orCo nfig() t Ca dCone xi on() SQLHelper ExecuteNonQuery() ExecuteDataset()
<<Ab s trac t>> BaseDA L BaseDAL() inicializar() inicializarGeneradorCodigo() getParametros() getProximoCod() consultar() insertar() modificar() NombreTabla() SqlCnn() SqlCmdCodigo()
PacienteDAL
NebulizacionDAL
En cu en troDAL
OrdenDAL
ObservacionesDAL
Figura 12: Clases Componentes Lgicos de Acceso a Datos
4.2.2.1.1 Paquete PacienteDAL Contiene las clases de acceso a datos del paquete Paciente. Todas las clases de este paquete heredan de la clase BaseDAL.
12
Cfr. Microsoft Patterns & Practices: http://msdn.microsoft.com/en-us/library/cc467893.aspx 35
<<Abstract>> BaseDAL
(from Componentes Logicos de Acceso de Datos)
PacienteDAL
ParienteDAL
InfoLaboralDA L
DireccionDAL
SeguroDAL
Figura 13: Clases de Acceso a Datos del paquete Paciente
4.2.2.1.2 Paquete EncuentroDAL Contiene las clases de acceso a datos del paquete Encuentro. Todas las clases de este paquete heredan de la clase BaseDAL.
EncuentroDAL
EpisodioDAL
Epi crisisDAL
ReporteCirugiaDAL
MedicacionDAL
DetalleMedicacionDAL
Figura 14: Clases de Acceso a Datos del paquete Encuentro
36
4.2.2.1.3 Paquete OrdenDAL Contiene las clases de acceso a datos del paquete Orden. Todas las clases de este paquete heredan de la clase BaseDAL.
(f rom Componentes Logicos de Acceso de Datos)
AdministrativaDAL
Te jid oDAL
Te rapi aDAL
DetalleTejidoDAL
DietaDAL
CitologiaDAL
Im age nes DAL
BiopsiaDAL
Inm unizacionDAL
NecropsiaDAL
LaboratorioClinicoDAL
DatosOrdenDAL
Figura 15: Clases de Acceso a Datos del paquete Orden
4.2.2.1.4 Paquete ObservacionesDAL Contiene las clases de acceso a datos del paquete de Observaciones. Todas las clases de este paquete heredan de la clase BaseDAL.
37
(f rom Componentes Logicos de Acceso de Datos)
AlergiaDAL
CursoClinicoDAL
GeneralDAL
SignosVitalesDAL
HabitoDAL
Nota_EnfermeriaDAL
MedicacionDAL
ResultadoMacroBiopsiaDAL
HistoricoDAL
ResultadoMacroCitologiaDAL
PatologicoDAL
ResultadoMacroNecropciaDAL
QuirurgicoDAL
ResultadoMicroBiopsi aDAL
ProblemaDAL
ResultadoMicroCitologiaDAL
ExamenFisicoDAL
DetalleExam enFisicoDAL
EncNebulizacionDAL
NebulizacionDAL
ExAsmaticoDAL
CorticoideDAL
Figura 16: Clases de Acceso a Datos del paquete Observaciones
38
4.2.2.1.5 Paquete ServiciosDAL Contiene las clases de acceso a datos del paquete Servicio. Todas las clases de este paquete heredan de la clase BaseDAL.
ServicioDietaDAL
ServicioMedicacionDAL
ServicioInmunizacionDAL
ServicioTerapiaDAL
Figura 17: Clases de Acceso a Datos del paquete Servicios
4.2.3
Clases que implementan los componentes de la capa
Comunes La capa Comunes contiene los componentes que son usados tanto por la capa de Lgica Empresarial como por la capa de Acceso a Datos. Esta capa contiene los paquetes Global, DTOs y Parmetros de Bsqueda.
<<layer>> Comunes
Gl obal
DTOs
Parmetros de Bsqueda
Figura 18: Paquetes de Diseo de la Capa Comunes
4.2.3.1
Global
39
En este paquete se encuentra la clase que permite manejar los mensajes de xito o fallo de la transaccin entre el sistema REHC 2.0 y los dems sistemas del SGM.
AcuseRecibo <<const>> S_OK : Integer = 0 <<const>> S_FALSO : Integer = 1 <<const>> S_ADV ERTENCIA : Int eger = 2 <<const>> S_ERROR : Int eger = 3 Respuesta : Int eger Mensaje : St ring MensajeInterno : St ring FuenteError : String Modulo : St ring Int erfaceS ervicio : St ring Version : S tring AcuseRec ibo() Error() Advert encia() Int erfaceS ervicio() Modulo() FuenteError() MensajeInterno() Mensaje() Respuesta() Version()
Figura 19: Clase Acuse de Recibo
4.2.3.2
Objetos de Transferencia de Datos (DTO)
En este paquete se encuentran las clases que permiten la transferencia de la informacin entre las capas del sistema REHC 2.0.
InfoDemograficaDTO
Encuentro Admin is trativoDTO
Prescripcio nDTO
OrdenDTO
CursoClinicoDTO
ResultadoDTO
ExamenFi s icoDTO
HistorialSaludDTO
ProblemaDiagnosticoDTO
NebulizacionesDTO
Figura 20: Clases Objetos de Transferencia de Datos
4.2.3.3
Parmetros de Bsqueda
40
En este paquete se encuentran las clases que permiten manejar los parmetros con los cuales el sistema REHC 2.0 buscar la informacin solicitada por los dems sistemas del SGM.
ParametrosBusqueda ParametrosBusquedaEncuentro
ParametrosBusquedaOrdenes
ParametrosBusquedaNebuCort
ParametrosBusquedaAntecedentes
ParametrosBusquedaObservacion
Figura 21: Clases Parmetros de Bsqueda
4.3 Modelo de Implementacin Descripcin de la Implementacin del Aplicativo
4.3.1
La implementacin del sistema se encuentra en el archivo solucin de .net SGHCE.sln, el cual contiene los proyectos desarrollados en la implementacin. Cada paquete definido en el diseo de la arquitectura se corresponde con un espacio de nombres y las clases definidas dentro de estos paquetes estn agrupadas dentro de un espacio de nombres, as tenemos el siguiente agrupamiento de los componentes definidos en la arquitectura:
Capa
Paquete Interfaces de Servicio
Lgica Empresarial Componentes Empresariales
Componente SGHCE.IS.Paciente.dll SGHCE.IS.Encuentro.dll SGHCE.IS.Observaciones.dll SGHCE.IS.Orden.dll SGHCE.IS.Servicio.dll
SGHCE.CE.dll
Acceso a Datos Comunes
Componentes Lgicos de Acceso a Datos Global
SGHCE.DAL.dll
SGHCE.Global.dll
Espacio de Nombres SGHCE.IS.Paciente SGHCE.IS.Encuentro SGHCE.IS.Observaciones SGHCE.IS.Orden SGHCE.IS.Servicio SGHCE.CE.Paciente SGHCE.CE.Encuentro SGHCE.CE.Observaciones SGHCE.CE.Orden SGHCE.CE.Servicios SGHCE.DAL.Paciente SGHCE.DAL.Encuentro SGHCE.DAL.Observaciones SGHCE.DAL.Orden SGHCE.DAL.Servicio SGHCE.Global
41
Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2 DTOs Parmetros de Bsqueda SGHCE.DTO.dll SGHCE.DTO SGHCE.Parametros.Paciente SGHCE.Parametros.Encuentro SGHCE.Parametros.Observaciones SGHCE.Parametros.Orden SGHCE.Parametros.Servicio
SGHCE.Parametros.dll
Tabla 1: Implementacin del Sistema de Historias Clnicas Electrnicas
La implementacin de cada uno de estos espacios de nombres nos da como resultado un ensamblado (assembly) o archivo .dll. A continuacin se presenta el diagrama general de Componentes del sistema REHC 2.0.
COMUNES
LOGICA EMPRESARIAL IAntecedenteIS ICursoClinicoIS <<COM+>> SGHCE.Obser vaciones.IS.dll IEncNebulizacion IS IExamenFisicoIS IProblemaIS IResultadoIS SGHCE. DTO.dll <<COM+>> SGHCE.Pac iente.IS.dll <<COM+>> SGHCE.Enc uentros.IS.dll <<COM+>> SGHCE.Ord enes.IS.dll IServicioT erapiaIS <<COM+>> SGHCE.Ser vicios.IS.dll IServicioDietaIS IServicioMedicacionIS
IServicioInm unizacio nIS
IInfoDemogra ciaIS
IEncuentroIS
IOrdenIS
SGHCE. Global.dll SGHCE.CE.dll
SGHCE.Pa rametros.dll ACCESO A DATOS
SGHCE.SqlHelper.dl l SGHCE.DAL.dll
SGHCE.Master.dll
DBHC
Figura 22: Diagrama de Componentes del sistema REHC 2.0
4.3.2 4.3.2.1
Implementacin de Componentes por Capa Lgica Empresarial
42
En la Figura 23 se puede observar los cinco componentes de tipo Interfaz de Servicio definidos en el proyecto y la interaccin de estos componentes con el componente que maneja la lgica empresarial (SGHCE.CE.dll).
<<COM+>> SGHCE.Pacien te.IS.dll
IInfoDemogr aciaIS <<COM+>> SGHCE.Ord enes.IS.dll
<<COM+>> SGHCE.Enc uentros.IS.dll
IEncuentroI S SGHCE.CE.dll
IOrdenIS
IExamenFisicoI ICursoClinicoIS S <<COM+>> SGHCE.Ser vicios.IS.dll IServicioInmunizacio nIS IProblemaIS
<<COM+>> SGHCE.Observ aciones.IS.dll
IAntecedenteIS
IServicioTerapiaIS IServicioMedicacionI S IServicioDietaIS IEncNebulizacio nIS IResultadoIS
Figura 23: Componentes de la capa Lgica Empresarial
4.3.2.2
Acceso a Datos
Los Componentes Lgicos de Acceso a Datos que encapsulan la lgica para la comunicacin con la Base de Datos para las consultas y actualizaciones estn agrupados en el componente SGHCE.DAL.dll. Estos componentes son referenciados por los componentes de Lgica Empresarial. Como podemos observar en la Figura 24, el componente SGHCE.DAL.dll referencia a dos componentes, el componente SGHCE.Master.dll, el cual permite manejar la encriptacin y desencriptacin de la cadena de conexin a la base de datos; y el componente SGHCE.SQLHelper.dll, el cual se encarga de facilitar las operaciones de consulta, insercin y modificacin de los registros en la base de datos.
43
SGHCE.SqlHelper.dll
SGHCE.Master.dll
SGHCE.DAL.dll
DBHC
Figura 24: Componentes de la capa Acceso a Datos
4.3.2.3
Comunes
Estos componentes son referenciados tanto por los componentes de la capa de Lgica Empresarial como por la capa de Acceso a Datos. En la Figura 25 podemos observar los componentes SGHCE.Global.dll, SGHCE.DTO.dll, el cual agrupa a las clases DTO para cada uno de los 5 paquetes definidos, y el componente SGHCE.Parametros.dll.
SGHCE.Global.dll
SGHCE.DTO.dll
SGHCE.Parametros.dll
Figura 25: Componentes de la capa Comunes
44
CAPTULO 5 PRUEBAS DEL SISTEMA En este captulo se tratar sobre las pruebas que se realizaron al sistema REHC 2.0. La etapa de pruebas es muy importante para la Ingeniera de Software ya que permite asegurar que el producto funcione de manera correcta y satisfaga los requerimientos presentados por el usuario. Se realizaron pruebas a cada componente implementado para poder verificar el correcto funcionamiento de estos. Durante la realizacin de las pruebas al sistema REHC 2.0, se cont con el apoyo de un equipo de pruebas. Este estuvo conformado por los alumnos Cesar Vsquez y Jos Valencia. Los equipos de cmputo en los que se desarrollaron las pruebas del sistema tuvieron las siguientes caractersticas: Servidor: Computadora IBM Pentium IV, procesador de 2.4 Ghz, PC Cliente: Computadora IBM Pentium IV, procesador de 2.4 Ghz, Memoria RAM 512 MB. Sistema Operativo: Windows 2000 Professional. Memoria RAM 256 MB. Sistema Operativo: Windows 2000 Professional. 5.1 Tcnicas de Aplicacin de Pruebas de Software 5.1.1 Pruebas Unitarias
El propsito de estas pruebas fue validar el correcto funcionamiento de cada uno de los servicios que ofrece el sistema REHC 2.0. Para realizar estas tareas, el
45
equipo de proyecto desarroll un aplicativo de pruebas en las que se utilizaban los servicios implementados. El mtodo utilizado en estas pruebas fue el de caja negra. Al probar el registro y modificacin de la informacin, se realizaron pruebas para uno y varios registros a la vez. Para el caso de los servicios de consulta de informacin tambin se manej de dos maneras: enviando un solo parmetro de bsqueda y enviando varios parmetros de bsqueda a la vez. Para reportar los errores que se presentaban y poder hacer seguimiento a la correccin de estos se utiliz la herramienta IBM Rational ClearQuest. 5.1.2 Pruebas de Instalacin
El propsito de estas pruebas fue validar el correcto desarrollo de los instaladores del sistema e instalacin de los mismos, tanto de los servicios COM+ en el Servidor de Aplicaciones como en las PCs de los clientes que consumen los servicios ofrecidos por el sistema REHC 2.0. Los componentes COM+ instalados en el Servidor de Aplicaciones fueron: Proyecto SGHCE - Paciente Proyecto SGHCE - Encuentro Proyecto SGHCE - Observaciones Proyecto SGHCE - Orden Proyecto SGHCE - Servicios Proyecto SGHCE - Auditoria
En las PCs clientes se instalaron los respectivos componentes cliente usando los siguientes archivos: Paciente.msi Encuentros.msi Observaciones.msi Ordenes.msi Servicios.msi
46
5.1.3
Pruebas de Integracin
Permite verificar el correcto funcionamiento, y la deteccin de fallas, de los servicios ofrecidos por el sistema de REHC 2.0 a los dems sistemas del SGM. Estas pruebas se basaron completamente en la especificacin de los requerimientos del sistema. Por ejemplo, se deba comprobar que el registro de informacin, ya sea de un Paciente, del Encuentro Mdico de ste, de una Orden o de un Antecedente Clnico en el sistema se realice correctamente. Tambin deba validarse el funcionamiento correcto de las consultas de informacin al sistema REHC 2.0, es decir, devolver la informacin solicitada por los dems sistemas del SGM de acuerdo a los parmetros especificados por estos. Los encargados de realizar este tipo de pruebas fueron cada uno de los integrantes de los dems proyectos del SGM, cuando se realizaban las respectivas revisiones a sus sistemas en un ambiente integrado. 5.1.4 Pruebas de Stress
Garantizan el funcionamiento del sistema cuando tengan acceso a ella una gran cantidad de usuarios en un mismo momento (concurrencia), demandando grandes volmenes de informacin. Las pruebas de stress sobre los componentes COM+ de la aplicacin se realizaron mediante una interfaz grafica en la cual se simulaba el ingreso de gran cantidad de registros (100, 200 y 500 registros). En todas ellas el tiempo de respuesta fue menor a 10 segundos. Tambin se realizaron pruebas para las consultas, en este caso se realizaron 100 consultas masivas sobre la informacin de Paciente y Encuentros y el tiempo de respuesta obtenido fue menor a 10 segundos.
5.2 Estrategias de Pruebas
47
La estrategia de pruebas solo fue aplicado a los casos de pruebas unitarias y pruebas de integracin. 5.2.1 Estrategia de Pruebas de Funcin
En las pruebas de funcin, una vez que el equipo de desarrollo del proyecto terminaba la construccin de un servicio, la funcionalidad de este era validado primero por el mismo equipo, en este caso solo se aplicaban pruebas simples para continuar con el desarrollo de los dems servicios. Luego que no se encontraba error alguno, los componentes desarrollados eran entregados al equipo de pruebas para que realicen pruebas ms completas. Si el equipo de pruebas encontraba algn error, este era registrado en el IBM Rational ClearQuest para su respectivo seguimiento. Esta herramienta permite detallar la descripcin del error, el responsable, el estado y la severidad (Critical, Major y Average). Luego, el equipo de desarrollo revisaba los errores registrados en el IBM Rational ClearQuest y poda optar por las siguientes opciones: Atender la solicitud de correccin del error. Posponer la correccin de este debido a que es un defecto de baja
prioridad y deba atender otros. Despus de corregido el error, el desarrollador colocaba el estado Resuelto a la solicitud de correccin. El equipo de pruebas volva a probar las correcciones realizadas. Si el error se mantena, la correccin pasaba al estado Rechazado, de lo contrario pasaba al estado Cerrado. 5.2.2 Estrategia de Pruebas de Integracin
Una vez que la funcionalidad del servicio implementado era validada por el equipo de pruebas, los componentes de este eran instalados en el Servidor de Aplicaciones para que el servicio pueda ser usado por los dems sistemas del SGM. Si algn error era encontrado por parte de los dems grupos de proyectos del SGM en la integracin de sus sistemas con los servicios ofrecidos por el sistema REHC 2.0, estos eran reportados directamente al equipo de proyecto, y
48
este error era revisado conjuntamente por el equipo de proyecto y de pruebas para hallar el problema y la solucin respectiva. 5.3 Resultados de Pruebas Las pruebas unitarias fueron realizadas por el equipo de pruebas, los errores encontrados fueron registrados en la herramienta IBM Rational ClearQuest para poder hacer el seguimiento respectivo a la correccin de los errores por parte de los equipos de proyecto y de pruebas. Los errores identificados fueron completamente corregidos al finalizar las iteraciones y al momento de terminar la versin final del sistema REHC 2.0. Las pruebas de integracin fueron completamente satisfactorias al finalizar la fase de construccin, ya que se llego a integrar con todos los sistemas del SGM sin presentar errores en los servicios expuestos. Los errores de integracin que fueron encontrados al inicio del proyecto fueron corregidos, probados e integrados nuevamente con los dems sistemas.
49
CAPTULO 6 GESTIN DEL PROYECTO En este capitulo se describir como se llev a cabo la gestin del proyecto Repositorio Electrnico de Historiales Clnicos 2. Se presentar la organizacin del equipo de proyecto, la planificacin del proyecto, las actividades realizadas y la administracin de los riesgos. 6.1 Organizacin del Equipo de Proyecto Los roles y responsabilidades definidos para el Proyecto Salud fueron: Rol Comit de Proyectos Responsabilidades Grupo de personas encargadas de decidir el destino de un proyecto. Son los que lo aprueban, deciden su continuidad, aprueban los acuerdos y, en general, controlan que se cumplan los objetivos de cada uno de los proyectos. Encargado de revisar los diferentes planes que se produzcan a lo largo del proyecto. Encargado de la administracin de programas, supervisin del avance de los proyectos y la coordinacin entre los diferentes proyectos. Encargado de validar el alcance de los proyectos. Es el cliente final del producto. Encargado del diseo de la arquitectura de los sistemas.
Jefe de Proyecto Gerente de Proyecto
Jefe de Lnea de Producto Arquitecto
50
A continuacin se presenta el organigrama del equipo de Proyecto:

L C . M m d i c i t e d e I . P A n a c h e r o y e c t o
J J J e o f e r g e d e
I l v e e f e C L a n b e
r d
A e
n P
c h e r o y e
t o . F r a n c ia
rE e .r a R a m r e z - J a d A e r q P u r oi t ed cu t c o t o
M G e
i g
u e l A r e n t e
r r u e
n t e g u P r o y e c t o
J n
n A r t e a gD a a n i e l G u t i T ar r l el e z r d e l i s t a / D e sA a n r r o l i sl l at a d / oD r e s P a r r or o g l ra a d m o
DT ra d
ea o
sl l ea r r do el l o D e rT (e e s s t )e r ( e
s a s )
r r o
l l o
Figura 26: Organigrama del equipo de Proyecto
El equipo del proyecto Repositorio Electrnico de Historiales Clnicos 2 estuvo conformado por dos personas. Se requiri del apoyo de tres personas adicionales al grupo de proyecto para que cumplieran el rol de Programador (en las etapas 1 y 2 de Construccin) y dos personas encargadas de realizar las pruebas del sistema. 6.2 Planificacin del Proyecto 6.2.1 Hitos y Entregables del Proyecto
Segn los lineamientos del RUP, el proyecto se organizo de la siguiente manera:
Fase Concepcin
Elaboracin
Construccin
Iteracin Hito Entregables 1 Comprensin del Documento de Visin negocio. Especificacin de Requerimientos de Software Objetivos del Sistema (SRS) Plan de Aceptacin Plan de Desarrollo de Software 1 Diseo Conceptual de la Documento de Arquitectura de Software solucin. Arquitectura del Sistema Modelo del Sistema 1 Elaboracin del Primer Release nro. 1 Release 2 Elaboracin del Release nro. 2 Segundo Release
51
Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2 3 Transicin 1 Elaboracin del Tercer Release nro. 3 (Integracin REHC 2.0 con Release Sistema Seguridad) Entrega del Producto Manual de Instalacin y Configuracin Final Paquete de Instalacin del Software Tabla 2: Hitos y entregables del Sistema
Releases
Release 1
Release 2
Release 3
Requerimientos implementados Actualizar Encuentro de Nebulizacin Consultar Encuentro de Nebulizacin Actualizar Nebulizaciones Consultar Nebulizaciones Actualizar Corticoides Consultar Corticoides Afiliar Paciente Consultar Informacin Demogrfica del paciente Actualizar Informacin Administrativa del Encuentro Consultar Informacin Administrativa del Encuentro Actualizar Epicrisis Consultar Epicrisis Actualizar Informacin de Prescripcin Consultar Informacin de Prescripcin Actualizar Orden Consultar Orden Actualizar Antecedentes Clnicos Consultar Antecedentes Clnicos Actualizar Examen Fsico Consultar Examen Fsico Actualizar Problema - Diagnstico Consultar Problema - Diagnstico Actualizar Signos Vitales Consultar Signos Vitales Actualizar Curso Clnico Consultar Curso Clnico Actualizar Resultado de Orden de Apoyo al Diagnstico Actualizar Resultado de Orden de Apoyo al Diagnstico Integracin Paquete Pacientes con Sistema Seguridad Integracin Paquete Encuentros con Sistema Seguridad Integracin Paquete rdenes con Sistema Seguridad Integracin Paquete Observaciones con Sistema Seguridad Integracin Paquete Servicios con Sistema Seguridad
Tabla 3: Requerimientos implementados en cada Release
6.2.2 Plan de Iteraciones
52
Fase: Fecha Inicio: Fecha Fin: Artefactos Internos
Concepcin - Iteracin nica 31/05/2004 20/07/2004 Plan de Iteracin Estimacin del Proyecto Lista de Riesgos Informe de Cierre de Iteracin Documento Visin Especificacin de los Requerimientos del Software (SRS) Plan de Aceptacin Plan de Desarrollo del Software
Entregables
Fase: Fecha Inicio: Fecha Fin: Artefactos Internos Entregables
Elaboracin - Iteracin nica 20/07/2004 18/08/2004 Plan de Iteracin Lista de Riesgos Informe de Cierre de Iteracin Documento de Arquitectura de Software Modelo del Sistema
Construccin - Iteracin 1 23/08/2004 01/10/2004 Plan de Iteracin Estimacin del Proyecto Informe de Cierre de Iteracin Release 1 del Sistema
Construccin - Iteracin 2 15/10/2004 26/11/2004 Plan de Iteracin Lista de Riesgos Informe de Cierre de Iteracin Release 2 del Sistema
53
Construccin - Iteracin 3 28/03/2005 08/06/2005 Plan de Iteracin Lista de Riesgos Informe de Cierre de Iteracin Release 3 del Sistema
Transicin - Iteracin nica 09/06/2005 08/07/2005 Plan de Iteracin Lista de Riesgos Informe de Cierre de Iteracin Manual de Instalacin y Configuracin Paquete de Instalacin del Software.
6.3 Estimacin del Proyecto Utilizando la metodologa de Estimacin por Casos de Uso, se realiz la estimacin del proyecto, lo cual nos dio como resultado:
Resultados de la Estimacin Horas requeridas para el proyecto Horas disponibles del grupo Nro. de CU totales Nro. de CU a desarrollar
1455,51 1120,00 32,00 25,00
Como se puede observar en el cuadro, las horas estimadas para la finalizacin del proyecto fue mayor a las horas disponibles por parte de los integrantes del grupo de proyecto, lo que ocasion que se requiriera contar con recursos adicionales para la fase de construccin. La estimacin del proyecto se bas en 2 criterios: la implementacin de Casos de Uso que no fueron implementados en la primera versin del sistema REHC, y la correccin de Casos de Uso que fueron implementados en la primera versin del
54
sistema y que presentaban fallas en la integracin con los dems sistemas del SGM. El nivel de esfuerzo para cada uno de estos dos criterios fue distinto, ya que para el primero se necesitaba de un esfuerzo mayor debido a que involucraba anlisis, diseo y programacin, en cambio para el segundo, solo involucraba programacin debido a que se trata de encontrar los errores en las unidades de programacin y corregirlos. A lo largo del proyecto, se presentaron diversos cambios en la Arquitectura de Software propuesta por la primera versin del sistema REHC, los cuales fueron presentados en el punto 3.2 de este documento, lo que ocasion que el esfuerzo estimado se incremente y los integrantes del grupo tuviesen que incrementar sus horas disponibles se para poder cumplir con lo planeado. 6.4 Administracin de Riesgos En esta seccin se presentara los principales riesgos identificados en el proyecto. En el siguiente cuadro se presenta los riesgos identificados en el proyecto, el impacto de estos en el mismo, la estrategia de mitigacin y plan de contingencia en caso estos se hagan presentes: el riesgo. Indicador, forma en que sabemos que el riesgo se est Estrategia de Mitigacin, medida que se tomar para menguar el Plan de Contingencia, que seran las acciones a realizar en caso el consumando. efecto del riesgo. riesgo se haga presente. Descripcin breve del riesgo a tratar. Puntaje, que es un indicador del peso o valor del riesgo, este puede Impacto, que nos dice las reas que podra afectar de consumarse
tomar valores entre 1 y 10.
55
Descripcin Breve Puntaje Impacto Escasos 10 Claridad y precisin de las conocimientos en el especificaciones de caso de rea de uso. historial clnico. Las cadas del 8 servidor que aloja los servicios del mdulo. Imposibilidad de uso de los servicios de HC por los diferentes mdulos.
Desarrollo de auditoria para mdulo.
la 8 el
Los otros mdulos 7 del sistema de salud no estn adaptados a los requerimientos de Historial Clnico. No contar con 5 desarrolladores en la 3ra Fase de Construccin
Al no ser una actividad contemplada en el plan de iteracin, cambiaba la programacin del ciclo. Ingreso errnea de informacin en la base de datos del sistema.
Indicadores Falta de terminologa mdica y entendimiento del lenguaje de los stakeholders No contar con el visto bueno del funcionamiento de los servicios por parte de los mdulos. Avance lento, con desfase.
Estrategia de mitigacin Investigar sobre Historias Clnicas. Alta comunicacin con el jefe de producto. Instalar alternos. en
Plan de contingencia Realizar reuniones mas seguidas con el anterior grupo de Historial Clnico para revisin de documentacin antigua.
servidores Instalar los servicios de Historial Clinico en una de las PCs de los miembros del grupo.
Ampliar las horas de trabajo Usar fines de semana y del proyecto (trabajar fines vacaciones para avance de semana, amanecidas). del proyecto. Crear manuales de cmo usar los servicios ofrecidos por el modulo de Historial Clnico v2 en los otros mdulos. Usar fines de semana y vacaciones para avance del proyecto.
Organizar reuniones continuas con encargados de los otros mdulos. Crear procedimientos para, en caso se hagan cambios, estar al tanto de los mismos. Tener menor disponibilidad Avance lento, Ampliar las horas de trabajo de recursos humanos para con desfase. del proyecto (trabajar fines el desarrollo de lo de semana, amanecidas). programado.
56
Tabla 4: Riesgos identificados en el Proyecto
57
De todos los riesgos presentados en el cuadro anterior ninguno se lleg a manifestar en su totalidad, esto permiti cumplir con los planes realizados de acuerdo a las estimaciones para cada una de las etapas del proyecto sin tener mayores retrasos o contratiempos.
58
CAPTULO 7 TRANSICIN DEL SISTEMA En este capitulo se describir el plan de liberacin del producto de software as como la documentacin necesaria a entregar a los usuarios del sistema con fin educativo. Estos documentos son el manual de Instalacin y los manuales de integracin con los dems sistemas del SGM. 7.1 Instalador del Producto de Software Una vez concluida la construccin del sistema de REHC 2.0 y realizado las pruebas necesarias sobre este, se procedi con el desarrollo del instalador del producto final. Para esto, todas las unidades de programacin desarrolladas durante la etapa de Construccin fueron compiladas en modo Release para la generacin de los ensamblados respectivos. Luego se procedi con el diseo de los scripts de Base de Datos, los cuales tenan la finalidad de la creacin de la base de datos en el servidor, creacin de las tablas y procedimientos almacenados, as como la carga de informacin inicial necesaria para el funcionamiento del sistema. Tanto los ensamblados como los scripts de base de datos fueron agregados a un proyecto .NET de instalacin. Para poder instalar los componentes COM+ en el servidor y poder ejecutar los scripts de base de datos, se disearon dos formularios para realizar estas funciones.
59
7.1.1
Instalador del Sistema en el servidor de Aplicaciones
Se dise un formulario para la instalacin de los servicios (componentes COM+) de la aplicacin en el Servidor de Aplicaciones. Este formulario cuenta con opciones que permiten escoger que servicio se desea instalar en el servidor. Las opciones que muestra el formulario son: Auditoria: Instala el servicio de Auditoria. Paciente: Instala los servicios que comprende el paquete Paciente. Encuentro: Instala los servicios que comprende el paquete rdenes: Instala los servicios que comprende el paquete Orden. Observaciones: Instala los servicios que comprende el paquete Servicios: Instala los servicios que comprende el paquete Servicios.
Encuentro.
Observaciones.
Figura 27: Instalador de Servicios ofrecidos por REHC 2
7.1.2 Instalador para la Base de Datos Se dise un formulario para la ejecucin de los scripts de base de datos los cuales permitiran la creacin de la base de datos en el servidor, las tablas y procedimientos almacenados que este contendr, adems de la cargar de datos iniciales en la base de datos para el funcionamiento del sistema. A su vez, el
60
formulario permite la creacin de un usuario de base de datos, el cual permitir al sistema conectarse a la base de datos. La informacin que se debe de ingresar en el formulario para la instalacin de la base de datos en el servidor es la siguiente: de datos. Nombre de la Base de Datos. Nombre del usuario Administrador del Servidor de Base de Datos. Password del usuario Administrador. Ruta desde la cual sern cargados los scripts de base de datos. Nombre del Servidor de Base de Datos en el cual se creara la base
Luego de completar la informacin solicitada e iniciar la ejecucin de los scripts, el formulario arrojara como resultado una cadena de texto, la cual contendr la cadena de conexin que permitir que la aplicacin pueda comunicarse con la base de datos creada. Para que los scripts puedan ser ejecutados, es necesario que la PC donde se realizar la instalacin de la base de datos cuente con las herramientas cliente de SQL Server.
61
Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2 Figura 28: Instalador de Base de Datos
7.2 Manuales del Producto Se consideraron los siguientes manuales del producto: manual de instalacin, manuales de integracin y el documento de clases. 7.2.1 Manual de Instalacin
El manual de instalacin fue desarrollado una vez concluido el instalador del producto final. Este documento contiene los pasos necesarios para la correcta instalacin del sistema REHC 2.0 en el servidor de aplicaciones. El contenido del manual es el siguiente: Los requerimientos mnimos y recomendados para la instalacin. El proceso de instalacin de los componentes COM+. El proceso de instalacin de la Base de Datos.
En el Anexo D se adjunta el manual de instalacin del sistema REHC 2.0. 7.2.2 Manuales de Integracin
Los manuales de integracin fueron desarrollados luego del trmino de la construccin de cada paquete de servicios definido en la parte de desarrollo (Paciente, Encuentro, Orden, Observaciones y Servicios). Estos manuales especifican el cdigo necesario a escribir por parte de los dems sistemas del SGM para poder integrarse de manera adecuada con los servicios ofrecidos por el sistema REHC 2.0. El contenido del manual es el siguiente: Los pasos a seguir para instalar los servicios COM+ localmente. Libreras que deben ser referenciadas dentro de los dems proyectos. Segmentos de cdigo de programacin como gua de integracin de los servicios.
62
En el anexo E se adjunta los manuales de integracin del sistema REHC 2.0.
63
CONCLUSIONES El proyecto REHC es un proyecto extenso y con un gran alcance, por lo cual era complicado implementarlo en una sola sesin de taller de proyectos. Por este motivo fue necesario crear una segunda versin del mismo, con la finalidad de implementar los casos de uso que no fueron desarrollados en la primera versin del sistema y poder cubrir los requerimientos que no se contemplaron en esta primera versin y que eran requeridos por los dems sistemas del SGM. Con el desarrollo de esta segunda versin del sistema se atienden todos los requerimientos de software de los dems proyectos que fueron creados hasta la fecha de implementacin de esta segunda versin. La integracin entre sistemas fue un factor crtico para el desarrollo del presente proyecto, ya que la funcionalidad del sistema de Historias Clnicas Electrnicas esta basada en la exposicin de servicios que son consumidos por los dems sistemas del Sistema de Gestin Mdico. Sin el correcto funcionamiento e integracin de estos servicios, los dems sistemas del SGM no podran funcionar correctamente. Los cambios realizados en la arquitectura de software propuesta por la anterior versin del proyecto REHC buscan mejorar el desempeo y mantenimiento del sistema, simplificando la distribucin de componentes del sistema y adecundolo a las exigencias del mismo. La priorizacin de Casos de Uso permiti brindar la disponibilidad de los servicios de software ofrecidos por el sistema REHC 2.0 en el momento en
64
que estos fueron requeridos por los dems sistemas del SGM y as no generar atrasos en el desarrollo de estos proyectos.
65
BIBLIOGRAFA CURIOSO, Walter; SALDAS, Jos y ZAMBRANO, Roberto 2002 Historias Clnicas Electrnicas. Experiencia en un Hospital Nacional. Satisfaccin por parte del personal de salud y pacientes. www.enlacesmedicos.com/hce.htm CURIOSO, Walter; SALDAS, Jos y ZAMBRANO, Roberto 2002 Historia Clnica Electrnica permite manejo eficiente de informacin. www.enlacesmedicos.com/gestion.htm GIMNEZ, Dolores 2008 La Historia Clnica: Aspectos ticos y Legales. http://geosalud.com/malpraxis/historiaclinica.htm HIGA, Daniel y LEIBLINGER, Erika 2005 Desarrollo del Repositorio Electrnico de Historias Clnicas para el Instituto de Salud del nio. Tesis (Ingeniera de Sistemas). Lima: UPC HL7 (Health Level Seven) 2008 Pgina principal del estndar HL7 para comunicacin e intercambio de datos en el rea de salud. http://www.hl7.org INSTITUTO NACIONAL DE SALUD DEL NIO 2008 Pagina principal del Instituto Nacional de Salud del Nio http://www.isn.gob.pe/index1.php
INCAS.NET
66
2008
Empresa peruana que ha desarrollado un producto para el manejo de historias clnicas http://www.incas.net/inkasoft.htm
LOLIMSA 2008
Empresa proveedora de software para la lnea de Salud. http://www.lolimsa.com.pe
JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James 1998 El Proceso Unificado de Desarrollo de Software. Madrid: Pearson Educacin. MICROSOFT 2006 Arquitectura de aplicaciones de .NET: Diseo de aplicaciones y servicios. http://www.microsoft.com/spanish/msdn/arquitectura/das/distapp.mspx MICROSOFT C# 2006 Learn C#. http://msdn2.microsoft.com/en-us/vcsharp/aa336766.aspx MICROSOFT Patterns & Practices Developer Center 2005 Microsoft Enterprise Library. http://msdn.microsoft.com/en-us/library/cc467893.aspx MICROSOFT SQL SERVER 2006 Pgina principal del producto. http://www.microsoft.com/spain/sql/default.mspx MORA, Gaby; VIDAURRE, Alex y ZEGARRA, Miguel 2004 Diseo de la Arquitectura de Software del Repositorio de Historias Clnicas Electrnicas para Centros de Salud. Tesis (Ingeniera de Sistemas). Lima: UPC
67

Tesis Historial Clinico v2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Historial Clinico v2

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SOFTWARE

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2 (REHC)

Para optar por el Titulo Profesional de Ingeniero de Software

Asesor: Ing. Jorge Cabrera Berros

Lima, Junio 2009

Tabla de Cont enido

CAPTULO 2: REQUERIMIENTOS DEL SISTEMA................................................................10

CAPTULO 3: DISEO ARQUITECTNICO........................................................................20

CAPTULO 4: DISEO DETALLADO DEL SISTEMA.............................................................32

CAPTULO 5: PRUEBAS DEL SISTEMA..............................................................................46

CAPTULO 6: GESTIN DEL PROYECTO...........................................................................51

CAPTULO 7: TRANSICIN DEL SISTEMA.........................................................................60

E Manual de Integracin del Sistema

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Cfr. Mora, 2004 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Cfr. Higa, 2005 Cfr. Higa, 2005 3

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

UNIDAD DE CUIDADOS INTENSIVOS TERAPIA

REPOSITORIO DE HISTORIAS CLNICAS

MATERNIDAD ADMISIN, DESCARGA Y TRANSFERENCIA GESTIN DE SEGUROS DE SALUD SEGURIDAD

Figura 1: Subsistemas del Proyecto de Desarrollo de Soluciones para la Lnea de Salud

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Implementar la versin 2.0 del Repositorio Electrnico de Historias Clnicas

Clnicas el cual contar con las siguientes funcionalidades:

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Implementar la integracin entre el sistema de Historiales Clnicos

Cfr. Jacobson, 1998. 6

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

las reglas definidas para las relaciones de la informacin no sean violadas.

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Responder a solicitudes de aplicaciones clientes.

Cfr. Microsoft SQL Server: http://www.microsoft.com/spain/sql/default.mspx 8

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema encargado de la administracin de tejidos que sern usados en los

Sistema encargado de registrar los procedimientos y operaciones quirrgicas.

Cfr. Higa, 2005 9

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Figura 2: Actores del Sistema

Cfr. Higa, 2005. 11

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Contiene la funcionalidad relacionada al registro y consulta de la informacin del

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Cfr. Higa, 2005. 14

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Presenta 3 capas: Lgica Empresarial, Acceso a Datos y Comunes.

Entidades Empresariales DTO

Figura 3: Elementos de diseo de la Vista Lgica implementados por REHC 1.0

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2

Acceso a Datos BDHC

Figura 4: Paquetes de componentes implementados por REHC 1.0

Sistema Integrado de Salud: Repositorio Electrnico de Historiales Clnicos 2