SERVICIO DE DATOS SOA PARA ARQUITECTURAS EXTENSIBLES: DISEÑO E IMPLEMENTACIÓN DE HEALTHBOOK DATA SERVICES

MANUEL ANDRÉS CARRIZOSA BLUMENTHAL

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D. C., 2008

SERVICIO DE DATOS SOA PARA ARQUITECTURAS EXTENSIBLES: DISEÑO E IMPLEMENTACIÓN DE HEALTHBOOK DATA SERVICES

MANUEL ANDRÉS CARRIZOSA BLUMENTHAL

Proyecto de grado presentado para optar al título de

Ingeniero de Sistemas y Computación

Directora: Claudia Jiménez

Profesor Asociado

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D. C., 2008

iii

TABLA DE CONTENIDO

1.  Introducción .................................................................................................... 7 

2.  Objetivos ......................................................................................................... 9 

2.1 Objetivos específicos ................................................................................................................. 9 3.  Antecedentes y Contexto............................................................................. 10 

3.1 Healthbook.............................................................................................................................. 10 3.2 Estado del Arte ........................................................................................................................ 11 

3.2.1 Clinical Document Architecture (Dolin, Alschuler, Boyer, & Beebe, 2004) ........................ 11 3.2.2 Bases de Datos Nativas XML ........................................................................................... 14 3.2.3 Herramientas para el manejo de CDA .............................................................................. 15 

4.  Estrategia de la Solución ............................................................................. 17 

5.  Arquitectura de la Solución ......................................................................... 20 

6.  Diseño de la Solución................................................................................... 23 

6.1 Integración de HDS.................................................................................................................. 24 6.2 Clases de HDS ........................................................................................................................ 26 

6.2.1 Las clases CDAManager y CommunityManager .............................................................. 26 

6.2.2 La clase eXistManager ............................................................................................ 28 

6.2.4 Aplicación de Gestión de la información de Signos Vitales............................................... 29 6.2.5 Características de las funciones CDA de HDS ................................................................. 31 6.2.6 Nuevos Servicios Web...................................................................................................... 32 6.2.7 Mensajes XML de Signos Vitales...................................................................................... 33 6.2.8 Validación de documentos CDA ....................................................................................... 35 

7.  Implementación ............................................................................................ 37 

7.1 La base de datos eXist ............................................................................................................ 37 7.2 Estructura de Archivos de HDS ............................................................................................... 38 7.3 Construcción de una demostración Web ................................................................................. 38 

7.3.1 Requerimientos funcionales de la demostración............................................................... 39 

iv

7.3.2 Diseño de la demostración Web ....................................................................................... 39 7.3.3 Página de inicio de HB...................................................................................................... 40 7.3.4 Página de inicio de HDS ................................................................................................... 41 7.3.5 Página de consulta de Signos Vitales............................................................................... 42 7.3.6 Página para Ingresar un Nuevo Signo Vital ...................................................................... 43 7.3.7 Página de Importar o Exportar Historia Clínica ................................................................. 44 

8.  Resultados y Trabajo Futuro ....................................................................... 46 

9.  Conclusiones ................................................................................................ 47 

10.  Bibliografía .................................................................................................... 48 

Anexo A – Instrucciones para el despliegue de la base de datos eXist ......... 51 

v

Índice de Figuras

Figura 1. Estructura completa de CDA (Dolin, Alschuler, Boyer, & Beebe, 2004) ............................ 13 

Figura 2. Relación de componentes de HB....................................................................................... 18 

Figura 3. HB Vista por capas. .............................................................................................................. 1 

Figura 4. Arquitectura General de HB. (Rincón 2008 & Marcial 2008)............................................... 21 

Figura 5. Componentes de Persistencia. .......................................................................................... 22 

Figura 6. Diagrama de clases de HFS en HB 1.0 (Beltrán 2008)....................................................... 23 

Figura 7. Diagrama de clases de la Persistencia con el componente HDS en HB 1.1....................... 25 

Figura 8. Diagrama de métodos de HDS. .......................................................................................... 27 

Figura 9. Diagrama de métodos de la aplicación de gestión de signos vitales. ................................. 30 

Figura 10. Vista del paquete DataServices........................................................................................ 32 

Figura 11. Vista del paquete VitalSigns ............................................................................................. 33 

Figura 12. Mensaje XML para la creación de un signo vital............................................................... 34 

Figura 13. Esquema de mensaje XML para consultar Signos Vitales................................................ 35 

Figura 14. Cabecera de un documento CDA. .................................................................................... 36 

Figura 15. Estructura de archivos de HB. .......................................................................................... 38 

Figura 16. Relación de clases de la demostración Web .................................................................... 40 

Figura 17. Página de inicio de HB...................................................................................................... 41 

Figura 18. Home de HDS................................................................................................................... 42 

Figura 19. Página de consulta de signos vitales ................................................................................ 43 

Figura 20. Página para Ingresar un Nuevo Signo Vital ...................................................................... 44 

Figura 21. Página para Importar/Exportar Historia Clínica................................................................. 45 

vi

Índice de Tablas

Tabla 1. Comparación de Herramientas similares ............................................................................ 16 

Tabla 2. Comparación de Healthbook FileSystem con Healthbook Data Services. ........................... 17 

7

1. Introducción

El mundo requiere de tecnologías que hagan posible encontrar la información precisa en el momento correcto. Para lograr este objetivo la información debe estar disponible y debe ser capaz de distribuirse en medios electrónicos y físicos de manera fácil, rápida y segura. La necesidad de intercambiar datos entre múltiples aplicaciones ha conducido a la definición de estándares de interoperabilidad.

Uno de los sectores críticos en donde la necesidad de compartir la información se ha vuelto imperiosa es el sector de la salud. Los datos acerca de las personas que acceden a los servicios de salud necesitan ser fácilmente accedidos por médicos y pacientes, esto sin olvidar la privacidad intrínseca con la cuál debe ser tratada esta información.

Dada la gran cantidad de tratantes e instituciones con las cuales interactúa un paciente, la información relevante acerca de los tratamientos, diagnósticos y demás datos que corresponden a una historia clínica son susceptibles de comprometer su integridad, de tergiversar su contenido o de perderse a lo largo del camino.

El proyecto Healthbook (Jimenez, Bravo, & Castro, 2008), tiene como objetivo solucionar los problemas de duplicidad, falta de unicidad y dificultades de acceso de la información clínica por parte de tratantes y pacientes. Healthbook busca darle el control de la recopilación de la información clínica a los pacientes, utilizando las ventajas que presenta una red social. El proyecto se ha desarrollado mediante la integración de 4 componentes, un componente de manejo de comunidad virtual (Moreno, 2008), un componente de manejo de información clínica (Rincón, 2008), un componente de persistencia de datos estructurado mediante esquemas definidos y estándares (Beltrán, 2008) y finalmente este trabajo que busca extender el núcleo de Healthbook y optimizar la persistencia de los datos utilizando estándares.

En el módulo de persistencia (Beltrán, 2008) se define que el estándar de datos a utilizar es un subconjunto de HL7 (HL7 Organization, 1987) llamado CDA (Dolin, Alschuler, Boyer, & Beebe, 2004). Este tipo de documento se especializa en la representación de las historias clínicas de manera electrónica.

Este trabajo busca integrar a Healthbook un nuevo módulo que ofrece el soporte a documentos CDA para lograr la interoperabilidad de la información médica generada. También busca adoptar un punto centralizado para el almacenamiento de la información generada por Healthbook.

A lo largo de todo el documento se desarrolla la descripción específica de la implementación, diseño y construcción de un nuevo componente llamado Healthbook Data Services y se propone el manejo

8

de una base de datos como punto centralizado de almacenamiento de la información. Este componente construye funciones que permiten generar información clínica siguiendo el estándar CDA para proporcionar un nivel de interoperabilidad en Healthbook, permitiendo así la posibilidad de importar y exportar datos clínicos que sigan este estándar. Adicionalmente se integra al proyecto, el manejo de nueva información clínica de signos vitales.

El documento se encuentra organizado de la siguiente manera: En el capítulo 2 se encuentran los objetivos generales y específicos de este proyecto. En el capítulo 3 se presenta una descripción de los antecedentes y el contexto de la solución propuesta. El capítulo 4 describe la estrategia de la solución. En los capítulos 5 y 6 se explica en detalle el diseño y la implementación del componente Healthbook Data Services. Los resultados obtenidos y las conclusiones del trabajo realizado se describen en los capítulos 8 y 9. Finalmente, el capítulo 10 muestra las fuentes bibliográficas y las referencias utilizadas en la realización del documento.

9

2. Objetivos El objetivo general de Healthbook es construir un marco de trabajo extensible, basado en servicios, que ofrezca a los usuarios la posibilidad de integrar su información médica relevante y compartirla con las personas correctas de manera fácil, ubicua y segura.

El objetivo específico de este trabajo es proporcionar una capa de servicios de datos que permita manipular la información médica bajo el estándar CDA en Healthbook, integrándola con el prototipo existente.

2.1 Objetivos específicos

• Integrar los servicios de CDA a Healthbook. Proporcionar el soporte para otras características de datos CDA, generando documentos válidos que permitan la interoperabilidad de la información médica.

• Integrar los servicios de bases de datos XML nativas a Healthbook para proporcionar un punto centralizado de integración de la información médica y de comunidad de la aplicación.

• Desarrollar un nuevo servicio en Healthbook que evidencie el uso de los componentes CDA desarrollados y su extensibilidad.

10

3. Antecedentes y Contexto

3.1 Healthbook

“Healthbook nace con el propósito de construir un marco de trabajo con infraestructura móvil, basada en web y grid, que ofrezca servicios de integración de información médica y de integración de la comunidad alrededor del paciente “(Jiménez, Bravo, & Castro, 2008).

Al inicio de este trabajo Healthbook se encuentra constituido por tres componentes que conforman el núcleo de la aplicación. Existe un componente para el manejo de servicios de comunidad (Moreno, 2008), un componente para el manejo de eventos médicos (Rincón, 2008) y un componente para el manejo de la persistencia (Beltrán, 2008). Por facilidad, esta versión se denomina Healthbook 1.0.

El componente de persistencia de Healthbook 1.0 (HB 1.0) es constituido por Healthbook FileSystem, en adelante HFS, que almacena la información de HB 1.0 en archivos XML guardados a nivel del sistema operativo (Beltrán, 2008). HB cuenta con dos tipos de sistemas de almacenamiento de datos, un sistema de archivos de datos XML para comunidad y paralelamente un archivo de datos clínicos por cada paciente.

La información clínica de cada paciente se almacena en un archivo XML que sigue mayormente el estándar CDA (Clinical Document Architecture), subconjunto de HL7. Este esquema se sigue ya que una de las restricciones del proyecto es contar con un estándar capaz de representar la información clínica de los pacientes de manera organizada. Esta debe ser capaz de proporcionar la interoperabilidad necesaria para el intercambio, integración y recuperación de esta información (Beltrán, 2008).

El documento clínico generado por (Beltrán, 2008), es un documento XML no valido ante el esquema definido por CDA. Esto impide la interoperabilidad necesaria para intercambiar la información generada por HB con aplicaciones externas.

El hecho de que el módulo de persistencia de HB 1.0 guarde la información como archivos en el sistema de operativo genera posibles retrasos en el procesamiento de la información, además de ser una manera no segura, no escalable y difícil de mantener y extender. En HB1.0 se maneja información clínica relativa a las observaciones y prescripciones de medicamentos generales que un médico le puede formular a un paciente.

11

El componente propuesto por este trabajo genera información clínica válida y aumenta el manejo de esta información clínica, implementando un componente para el manejo de signos vitales, y además, proporciona un punto centralizado para el manejo de la información generada por HB haciendo uso de una base de datos especializada en los documento XML gestionados. La versión de HB que integra con HB 1.0 con este nuevo componente se denomina HB 1.1 y es el objeto principal de este trabajo.

3.2 Estado del Arte

La información clínica que maneja HB 1.1 se construye bajo el estándar CDA. Para el desarrollo de este trabajo se estudia este estándar y se define un límite para su implementación. Además, se estudian diferentes alternativas para almacenar los archivos generados por HB y por último se analizan algunas herramientas similares que intentan dar solución al manejo de historias clínicas con el estándar CDA.

3.2.1 Clinical Document Architecture (Dolin, Alschuler, Boyer, & Beebe, 2004)

Un documento clínico HL7 CDA (World Wide Web Consortium, 2006) es un documento XML que especifica la estructura y la semántica de un documento clínico (Dolin, Alschuler, Boyer, & Beebe, 2004) y tiene como propósito el intercambio de información médica entre distintas aplicaciones. Un documento CDA puede ser utilizado fuera de una estructura HL7 o puede ser parte de un documento HL7 como un adjunto codificado como MIME. De esta forma CDA complementa la estructura compuesta por HL7.

La especificación CDA versión 2.0 indica la forma de estructurar un documento clínico bajo el lenguaje de marcación XML. Las instancias de un documento CDA deben ser válidas contra el esquema CDA y el esquema puede estar sujeto a validaciones adicionales. Un esquema CDA está compuesto por 3 elementos: Una definición para el vocabulario, una definición para los tipos de datos y otra para la definición de la estructura principal que compone un documento CDA.

La estructura principal de un documento CDA está compuesta por una cabecera y un cuerpo. Todo el documento se encuentra entre los marcadores <ClinicalDocument>. La cabecera se encuentra entre los marcadores <ClinicalDocument> y <StructuredBody>. En la

12

Figura 1 se puede observar un diagrama de las clases y objetos que están en el estándar CDA. Los elementos de color verde se refieren a las diferentes entidades posibles. Los elementos resaltados con amarillo reflejan los posibles roles de las entidades y los elementos de color azul reflejan el tipo de participación por parte de las entidades. Finalmente los elementos resaltados en rojo reflejan las posibles acciones a realizar y el elemento de color gris representa el lenguaje de comunicación usado en la entidad.

Para interpretar completamente un documento CDA también se debe entender la normatividad asociada a este estándar. La descripción jerárquica de CDA se deriva del modelo mostrado en la Figura 1 que a su vez se deriva del Modelo de Información de Referencia HL7 (RIM, Reference Information Model).

Algunas de estas normatividades se refieren por ejemplo los tipos de datos (Datatypes) que definen el formato estructural de los datos dentro de un atributo del modelo de referencia e influencian el conjunto de valores permitidos que un atributo puede tomar. Algunos tipos de datos tienen muy poco contenido semántico. Sin embargo HL7 también define algunos tipos de datos más extensos como el que se utiliza para el nombre de una entidad.

Otra de las normatividades se refiere a las palabras que se pueden utilizar para describir los objetos en un documento clínico, a esto se le llama el dominio de vocabulario. El dominio del vocabulario representa el diccionario de la salud, consta de miles de palabras definidas para describir todos los conceptos que se manejan en un documento clínico de forma codificada. Existen cientos de dominios de vocabularios cada uno con su propio código único de identificación. Algunos de estos dominios son:

• SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms) (United States National Library of Medicine, 2004): Es un diccionario de terminología clínica, originalmente creada por el Colegio de Patólogos. Proporciona un estándar para los términos de información clínica. Este código define conceptos, jerarquías y relaciones para obtener un punto de referencia común para el análisis de datos. Contiene terminología clínica para describir eventos, procedimientos, contextos sociales, sustancias y demás información relevante a la descripción de términos médicos.

• LOINC (Logical Observation Identifiers Names and Codes, 2008): Este diccionario fué desarrollado para propocionar un estándar definitivo para identificar la iinformación clínica en reportes electronicos. La base de datos de LOINC proporciona un conjunto universal de nombres y códigos de identificación para resultados de laboratorio y exámenes médicos en el contexto de HL7. Una de las metas primarias de LOINC es facilitar el intercambio de información entre instituciones del cuidado médico, manejo de resultados e investigación.

13

Figura 1. Estructura completa de CDA (Dolin, Alschuler, Boyer, & Beebe, 2004)

14

• MESH (Medical Subject Headings) (United States Medical Library of Medicine, 1999): El diccionario MESH es utilizado por la Biblioteca Nacional de Medicina de los Estados Unidos para indexar articulos de las 5200 publicaciones médicas más importantes para la base de datos MEDLINE. Se utiliza para catalogar libros, documentos y audiovisuales adquiridos por la biblioteca. Cada referencia bibliográfica está asociada a un término MESH que describe el contenido de los items.

De los vocabularios tenidos en cuenta, se encontró que el vocabulario descrito por SNOMED CT es uno de los más completos ya que en éste, se definen la mayoría de términos médicos generales, además de eventos procedimientos y datos asociados al paciente. Otros vocabularios no tienen en cuenta muchos de estos datos, ya que son orientados a un objetivo específico, como es la descripción de la anatomía o la clasificación de la información médica.

3.2.2 Bases de Datos Nativas XML

Para escoger una base de datos nativa XML para la persistencia de los datos de HB, se estudian diferentes posibilidades. Las bases de datos relacionales o bases de datos orientadas a objetos fueron descartadas ya que todos los datos de HB están siendo guardados en formato XML, por lo tanto se busca un sistema especializado para el almacenamiento de los mismos.

De las múltiples alternativas a utilizar, se estudian principalmente tres bases de datos, todas de código abierto, ya que es una de las condiciones de este proyecto.

• BaseX Database System (BaseX Universidad de Konstanz, 2008): BaseX es una base de datos nativa XML, de código abierto que procesa XPath y XQuery 1.0. Alcanza a pasar el 99.9% de las pruebas que se realizan en la W3C para XQuery, las pruebas publican en W3C bajo el nombre de XQuery Test Suite (World Wide Web Consotrtium). Entre sus características principales se encuentra una interfaz visual muy completa que facilita el acceso interactivo a los datos. Es desarrollada por el grupo de Bases de datos y sistemas de información de la universidad de Konstanz. Implementa el API estándar para el manejo de bases de datos XML llamado XML: DB (XML:DB Initiative). Esta implementada en el lenguaje Java. Lamentablemente el problema que se encontró con este proyecto es que la documentación es limitada y debido a esto el desarrollo y puesta en marcha de proyectos con esta base de datos puede tener un alto nivel de dificultad.

• Oracle Berkeley Database (Oracle Corporation): Oracle Bekeley DB XML es una base de datos de código abierto, que se despliega dentro de las aplicaciones donde se va a utilizar. Proporciona acceso a los datos mediante XQuery y cumple el 99.5% de las pruebas

15

realizadas por la W3C (World Wide Web Consotrtium). Está construida sobre la base de datos Oracle Berkeley DB y hereda todas sus características y atributos. Es una base de datos nativa XML que proporciona acceso a sus funciones mediante un API propietario. Con esta base de datos se encuentran varios problemas, entre ellos, no proporciona una interfaz de administración ni control de acceso. Además la documentación proporcionada es algo limitada y no se puede acceder a ella utilizando un API estándar.

• eXist Database (Exist ): Exist es una base de datos nativa XML implementada en Java como una aplicación empresarial JEE (Java Enterprise Edition). Es de código abierto y fue fundada en el año 2000 por Wolfgang Meier. Cumple el 99.7% de las pruebas realizadas por la W3C para el cumplimiento de XQuery. Proporciona varias alternativas para ser desplegada y cumple con el API estándar XML: DB. La documentación acerca de esta base de datos es muy completa, lo cual facilita la puesta en marcha de proyectos que utilizan esta alternativa.

Algunos sistemas de bases de datos objeto-relacionales han incluido herramientas para la gestión nativa de datos XML. Sin embargo estos sistemas almacenan los datos como parte de una tabla objeto-relacional y esto elimina características importantes que ofrecen las bases de datos nativas XML como el manejo de colecciones o el acceso directo a la información utilizando URLs (URL: Localizado Uniforme de Recurso por sus siglas en inglés).

3.2.3 Herramientas para el manejo de CDA

Actualmente no existen muchas aplicaciones que se especialicen específicamente en el manejo del estándar CDA, la mayoría de herramientas son herramientas que permiten y facilitan la validación de estos documentos. Sin embargo para este proyecto se tuvieron en cuenta algunas herramientas que facilitarían el manejo de los datos XML que propone el estándar. Dentro de estas herramientas se evaluaron las siguientes:

• IBM WebSphere Transformation Extender (IBM Corporation): IBM WebSphere Transformation Extender es un motor de transformación que se encarga de la convertir mensajes de datos complejos para las aplicaciones. Puede manejar mensajes extensos, estructurados, jerárquicos y estructuras de datos anidadas. Puede ejecutarse en ambientes independientes o dentro de ambientes más complejos. Permite a los diseñadores de integración visualizar tipos de datos complejos a través de un modelo gráfico y proporciona capacidades de procesamiento y manipulación de datos. Este método libre de código permite la construcción de mapas de transformación basados en requerimientos de negocio sin depender de capacidades de programación avanzadas. Existe un paquete específico

16

para el manejo de del estándar HL7 versión 3 y sus subconjuntos que permite manejar y transformar mensajes que contienen esta especificación.

• HL7 Java SIG Project (The Java SIG Proyect): Este es un proyecto de código libre que proporciona un API para el manejo y creación de documentos que sigan el estándar clínico HL7 y CDA. El API facilita el desarrollo de aplicaciones la creación de documentos clínicos. Los datos generados son manejados en memoria y opcionalmente pueden persistirse a través de Hibernate (Red Hut Middleware).

La Tabla 1 muestra una comparación de las herramientas encontradas para el manejo específico de CDA. De las dos herramientas encontradas, aunque todas son integrables al proyecto, ninguna brinda el soporte por etapas con el que el proyecto Healthbook se ha venido desarrollando.

Herramienta Datos de comunidad  Integrable

Orientado en Paciente 

Soporta desarrollo por etapas de HB 

Código Abierto 

WebSphere Transformation Extender  No  Si  No  No  No 

The Java SIG Proyect  No  Si  Si  No  Si 

Healthbook Data Services  Si  Si  Si  Si  Si Tabla 1. Comparación de Herramientas similares

17

4. Estrategia de la Solución

Healthbook Data Services, en adelante HDS, propone un almacenamiento basado en bases de datos nativas XML y sigue fielmente el esquema CDA lo cual permite la interoperabilidad deseada de la información clínica. La integración de HDS a HB 1.0 conforma la versión HB 1.1.

En el siguiente cuadro se presenta una comparación del alcance que se obtiene con el componente Healthbook FileSystem (HFS) y el componente objeto del presente trabajo llamado Healthbook Data Services.

Criterio Healthbook FileSystem Healthbook Data Services Seguridad Baja Alta Interoperabilidad Media Alta Eficiencia Baja Alta Mantenibilidad Baja Alta Accesibilidad Baja Alta

Tabla 2. Comparación de Healthbook FileSystem con Healthbook Data Services.

En los ítems mostrados de la Tabla 2, se puede observar los beneficios del nuevo componente.

• Seguridad: Mientras en HFS es posible acceder a la información por el sistema de archivos, la información contenida en HDS es almacenada en una base de datos que proporciona control de acceso a los datos.

• Interoperabilidad: En HFS el formato de la información clínica no se ciñe completamente al estándar CDA, en HDS se sigue el estándar dando la posibilidad de incorporar información externa que siga el estándar y exportar la información a otras aplicaciones.

• Eficiencia: Es mucho más eficiente manejar los datos directamente de un motor capaz de procesar la información directamente, que cargar todos los archivos planos en memoria.

• Mantenibilidad: En HFS mantener y organizar los archivos es muy tedioso y extenso debido a que éste guarda la información en archivos en el sistema operativo, mientras que en una base de datos se puede lograr un mejor orden ya que los datos se encuentran centralizados en un solo punto.

• Accesibilidad: Los datos de la base de datos pueden replicarse y mantenerse fuera de la aplicación, de esta manera son accesibles mediante mecanismos distintos.

18

Healthbook 1.0 (HB 1.0), está formado por tres grandes componentes que integrados conforman el núcleo de la aplicación, esta arquitectura se conserva en HB 1.1. Como ya se ha venido mencionando, la aplicación cuenta con un componente para el manejo de comunidad, un componente para el manejo de los servicios de los pacientes y un componente de persistencia. Estos componentes se relacionan entré sí como se observa en la Figura 2:

Figura 2. Relación de componentes de HB.

Healthbook Patient Services (Rincón, 2008) (HBPS) y Healthbook Community Services (Moreno, 2008) (HBCS) dependen del componente Persistance para su funcionamiento.

Este trabajo propone el componente Healthbook Data Services (HDS) que gestiona la información clínica ciñéndose al estándar CDA, lo cual permite importar y exportar las historias clínicas, aunque la información contenida en ellas no sea manipulada en su totalidad. La ventaja es que se da la posibilidad para la construcción de futuros componentes capaces de manejar los datos almacenados que no se encuentren ya gestionados por HB.

El componente HDS es capaz de manejar la semántica de propuesta por CDA, pero así mismo esto impone una enorme limitación. La definición de un documento CDA es extensa. Requiere de una gran cantidad de tiempo y trabajo implementar un componente para manejar la semántica completa

19

que define este tipo de documento. Por esto, se define que el alcance de HDS debe limitarse a algunas de las características que propone este estándar.

HDS incorpora un componente que integra al núcleo de HB, una aplicación de gestión de la información de signos vitales sobre las historias clínicas. Este nuevo componente, extiende la persistencia y ofrece los servicios Web necesarios a las capas superiores de presentación, para que éstas sean capaces de almacenar información acerca de los signos vitales de los pacientes sin preocuparse por el manejo del estándar.

Aunque HDS persiste los datos de HB en una base de datos, ofreciendo un punto centralizado para el manejo de la información y un nuevo nivel de seguridad, se hace necesario tener un componente encargado de la autenticidad, autorización e integridad sobre la información manejada por la aplicación.

HDS se integra al módulo de persistencia reemplazando en algunos casos las funciones proporcionadas por HFS, pero brindando la posibilidad de hacer uso de éstas si así se define en los archivos de configuración de la aplicación.

Finalmente, se implementa un prototipo Web con la finalidad de mostrar los nuevos servicios ofrecidos por la aplicación satélite para el manejo de signos vitales y su integración con el resto de los servicios de Healthbook.

20

5. Arquitectura de la Solución

Healthbook está diseñado bajo una Arquitectura Orientada a Servicios y separado en componentes. En la Figura 3 se muestra una vista por capas de la arquitectura en donde se refleja la orientación a servicios. Se observa una capa de presentación que debe poder ser accedida mediante dispositivos móviles y browsers. Una capa API - SOA (Interface de programación de aplicación, por sus siglas en inglés) que ofrece Servicios Web a las capas superiores. Todo esto utilizando los servicios proporcionados por el núcleo de la aplicación y por aplicaciones satélite que extienden el núcleo de la aplicación. En el núcleo se encuentra el módulo de persistencia, que es el tema de interés en este trabajo.

Como ya observamos en la Figura 2, el núcleo de HB está compuesto por tres componentes. Una visión más detallada de la arquitectura del núcleo y su interacción con el componente de persistencia es presentada en conjunto por Rincón (Rincón, 2008) y Marcial (Moreno, 2008) conjuntamente y se puede ver en la Figura 4.

Si bien el componente Magos de la Figura 4 está completamente desarrollado y permite el soporte de una infraestructura grid para HB, éste aún no ha sido integrado (Lopez Ramirez, 2007).

Figura 3. HB Vista por capas.

21

Figura 4. Arquitectura General de HB. (Rincón 2008 & Marcial 2008)

HFS presentado por Beltrán (Beltrán, 2008) está compuesto por tres componentes, ahora se presenta aumentado por los componentes de HDS. En la Figura 5 se pueden observar los componentes del paquete de persistencia. Como una de las restricciones del proyecto es mantener lo hecho anteriormente, se modificaron algunos componentes de HFS para que mediante el patrón Fabrica (Gamma, Helm, johnson, & Vlissides, 1994) fuera posible mantener ambos sistemas de persistencia.

22

Figura 5. Componentes de Persistencia.

Los componentes resaltados son los paquetes que hacen parte de la solución de HDS y extienden HFS. El componente PersistanceFactory es el contenedor de la fábrica que modifica el funcionamiento de HFS para permitir almacenar la información en la base de datos. El componente eXist contiene las clases encargadas de relacionarse con la base de datos.

Se construye un nuevo componente para la gestión de la información de signos vitales, que utiliza el componente eXist para persistir la información. Los nuevos servicios prestados por los componentes de HDS se exponen por medio de Servicios Web a las capas superiores.

Adicionalmente se construye una aplicación de prueba, con el propósito de mostrar el funcionamiento de los nuevos componentes.

23

6. Diseño de la Solución

La restricción principal para diseñar la solución es integrar este trabajo con lo hecho en los trabajos anteriores. Para esto hay que analizar las clases que pertenecen al componente de persistencia y fueron desarrolladas por HFS (Beltrán, 2008) y se pueden observar en la Figura 6.

Figura 6. Diagrama de clases de HFS en HB 1.0 (Beltrán 2008)

24

El componente mostrado en la figura consta de tres partes básicas. Dos partes para manejar por separado los datos pertenecientes a la comunidad de HB y los datos clínicos de los pacientes, communityPersistance y CDAPersistance respectivamente. Las clases ResultPolimorphism generan resultados intermedios para las capas superiores y separan los detalles de los datos en objetos fácilmente manejables. Una descripción más profunda de este componente puede encontrarse en el documento producido por Beltrán 2008.

Para mantener lo descrito anteriormente, se conservaron las clases para el manejo de resultados (ResultPolimorphism) y mediante el patrón fábrica se da la posibilidad de configurar la aplicación para manejar los datos clínicos y de comunidad con el componente HFS o con el nuevo componente HDS.

6.1 Integración de HDS

“El patrón de fábrica es un patrón de diseño de software que permite crear clases sin especificar la clase exacta con la cual serán creados” (Gamma, Helm, johnson, & Vlissides, 1994). El creador sólo conoce la interfaz de los objetos a ser creados y sólo le permite a sus subclases la instanciación de los objetos concretos.

En el caso de este proyecto se implementó este patrón como un método cuya abstracción permite decidir en tiempo de ejecución que tipo de objetos se van crear, es decir, mediante un archivo de configuración se especifican los objetos apropiados para utilizar.

Fue necesario rehacer algunas clases paralelas a las clases de HFS para que éstas guarden los datos que este componente estaba guardando en archivos, directamente en la base de datos. De esta forma el diagrama final para HB 1.1 quedó como lo muestra la Figura 7. Los componentes resaltados en la figura, pertenecen al módulo de HDS. Se puede ver claramente las dos implementaciones en paralelo, CDAPersistance y CDAeXist básicamente hacen lo mismo pero guardan los archivos de manera diferente. De igual forma CommunityPersistance y CommunityeXist son clases que ofrecen los mismos servicios, pero persisten la información de manera diferente.

Las clases CDAPersistance y CDAeXist implementan la interfaz ICDAFactory que presta servicios a ImpFacade que es la fachada de servicios del componente Persistance y su funcionamiento se encuentra explicado en (Beltrán, 2008). De igual forma CommunityPersistance y CommunityeXist implementan la interfaz ICommunityFactory que presta servicios a ImpCommunityFacade.

25

La fábrica concreta son las clases CDAManager y el CommunityManager capaces de crear los objetos según se especifique en el archivo de configuración persistance.properties que se encuentra en el ambiente de ejecución. Ambos utilizan en patrón Singleton para garantizar una única instancia y un único punto de acceso global a las mismas.

Figura 7. Diagrama de clases de la Persistencia con el componente HDS en HB 1.1.

Finalmente y como parte de la integración de HDS y HFS, se utilizan las clases para la entrega de los resultados ya implementadas por HFS. Estas clases se pueden ver en la Figura 7, ya que se

26

encuentran sin resaltar. Los resultados mantienen cierta independencia entre los datos propios que manejan los sistemas de persistencia y los datos que son entregados a los componentes superiores.

Los resultados son entregados en objetos IResult, forma en la cual es entregado cualquier resultado solicitado por los componentes superiores (Beltrán, 2008). Esto se logra mediante la implementación de un patrón polimorfismo para diferenciar los distintos tipos de resultado.

“Internamente en el objeto IResult se mantienen dos elementos (Contenido y mensaje), donde el contenido puede variar gracias a la facultad polimórfica. El contenido puede ser: un conjunto de relaciones, un conjunto de usuarios (tratante o paciente), un conjunto de observaciones, un conjunto de prescripciones o un conjunto de mensajes” (Beltrán, 2008).

6.2 Clases de HDS

Las clases de HDS están contenidas en el módulo de persistencia de HB, y son integradas a algunos componentes de HFS, utilizando el patrón fábrica como se menciona anteriormente. Todas las clases de HDS persisten la información en la base de datos eXist. De esta forma las clases que reemplazan las funciones de HFS y las clases que extienden la funcionalidad de Healthbook dependen de la clase eXistManager encargada de la relación con la base de datos eXist. Con el objetivo de desacoplar las funciones de eXistManager, se debe interactuar con su interface llamada IeXistManager.

6.2.1 Las clases CDAManager y CommunityManager

El punto de separación entre HDS y HFS son las clases CDAManager y el CommunityManager, en donde según un archivo de configuración, llamado persistance.properties, ubicado en C:\temp\cdaData\general se crean objetos de HFS o HDS. La propiedad de la cual depende la creación de los objetos es persistance.cdauri y persistance.comunityuri donde se especifica la ubicación y el nombre del objeto a crear en la jerarquía de archivos de HB. Los objetos HDS son las clases CDAeXist y CommunityeXist. Estas clases reemplazan las funciones prestadas por CDAPersistance y CommunityPersistance respectivamente.

Así, para crear objetos HFS para el manejo de CDA y comunidad, la configuración debe ser:

27

• persistance.cdauri=uniandes.healthbook.hFramework.hCore.persistance.fileSystem.CDAPersistance

• persistance.comunityuri=uniandes.healthbook.hFramework.hCore.persistance.fileSystem.CommunityPersistance

Y para crear objetos HDS, la configuración de estas propiedades debe ser:

• persistance.cdauri=uniandes.healthbook.hFramework.hCore.persistance.eXist.CDAeXist

• persistance.comunityuri=uniandes.healthbook.hFramework.hCore.persistance.eXist.CommunityeXist

Figura 8. Diagrama de métodos de HDS.

28

Tanto CDAeXist como CommunityeXist dependen de la clase eXistManager. El eXistManager es la encargada de manejar la relación con la base de datos eXist. Un diagrama de métodos se observa en la Figura 8.

6.2.2 La clase eXistManager

La clase eXistManager es la encargada de manejar las funciones relacionadas con la base de datos nativa XML llamada eXist. Esta clase maneja todas las funciones necesarias en HB para la manipulación de documentos XML dentro de la base de datos. Dentro de las funciones ofrecidas por esta clase, se encuentran:

• createElement: Crea un elemento un archivo XML especificado, dada una expresión XPath, XQuery.

• deleteElement: Borra un elemento en un archivo XML especificado, dada una expresión XPath, XQuery.

• modifyElement: Modifica un elemento en un archivo XML especificado.

• getXMLFile: Retorna un archivo XML de la base de datos mediante su nombre.

• saveXMLFile: Guarda un archivo XML en la base de datos.

• deleteXMLFile: Elimina un archivo XML de la base de datos.

• countCDAFiles: Cuenta los archivos XML cuyo nombre comienza por CDA.

• getAllCDA: Retorna una lista con todos los documentos CDA.

• exportCDAPart: Retorna la cabecera CDA y una parte específica del documento CDA.

• exportCDA: Dado una identificación de paciente y el tipo de identificación, retorna su respectivo archivo CDA.

• getAllCDAUsers: Retorna una lista con todos los identificadores de los pacientes que tienen un documento CDA.

• importCDA: Esta importa un documento CDA, lo valida contra el esquema y si es válido lo guarda en la base de datos.

29

• executeXQUERYXPATH: Esta función ejecuta un XQuery o un XPath ya que internamente la base de datos no diferencia entre las dos (Meier).

6.2.4 Aplicación de Gestión de la información de Signos Vitales

Con el objetivo de mostrar la extensibilidad de los componentes desarrollados sobre CDA, se implementa un nuevo componente capaz de manejar información acerca de los signos vitales de los pacientes bajo el estándar CDA. Esta aplicación maneja prácticamente todos los signos vitales que se pueden tomar en un examen físico simple, como por ejemplo la presión sanguínea, la altura, el peso, la regularidad de la respiración, la regularidad del ritmo cardiaco, el índice de masa corporal, la temperatura y las pulsaciones por minuto.

En general los signos vitales CDA son de tipo Osbservation, con atributos como código (Code) y tiempo efectivo (effectiveTime) y valor (value). En especial el signo vital que indica la presión arterial es un signo vital compuesto que en vez de tener un valor tiene un atributo de tipo relación (entryRelationship) y un atributo que indica el sitio de la toma (brazo izquierdo o derecho) llamada sitio objetivo (targetSiteCode). Opcionalmente pueden tener elemento de traducción (translation) para indicar la conversión de unidades, aunque cabe anotar que HDS no implementa este atributo.

La clase encargada de la gestión de los signos vitales, es CDAVitalSigns que utiliza el eXistManager para persistir los datos. Los servicios principales de esta clase son insertar un nuevo signo vital, consultar todos los signos vitales, y consultar signos vitales en un rango de fechas.

30

Figura 9. Diagrama de métodos de la aplicación de gestión de signos vitales.

En CDA el tipo de valor cambia según el signo vital. Algunos signos vitales son apreciativos, otros son valores simples con una unidad y otros son valores compuestos. En CDA se clasifican los tipos de signo vital de la forma siguiente:

• Signos vitales PQ: Estos son signos vitales sencillos cuyo valor o entrada consta de un valor numérico y una unidad. Este tipo se utiliza, por ejemplo para describir la altura, cuyo valor es numérico y tiene una unidad. (Ej.: valor numérico: 1 Unidad: m)

• Signos vitales CD: En este tipo de signo vital, el valor es una entrada de tipo apreciativa. Se utiliza para describir, mediante palabras definidas por los diferentes vocabularios médicos definidos para CDA, signos vitales que no tienen valores numéricos. Un ejemplo de este signo vital es la regularidad del ritmo cardiaco, que toma valores como: “Ritmo cardiaco regular” (“Heart Regular” en código SNOMED CT).

31

• Signos vitales RTO_PQ_PQ: Estos signos vitales son aquellos que para describirlos, se necesita un valor fraccionario. Por ejemplo, para describir el pulso cardiaco se utiliza la fracción 74 / 1 minuto.

• Signos vitales COMP: Este tipo de signo vital, es compuesto por dos observaciones relacionadas. Se utiliza específicamente para describir la presión sanguínea. En su estructura primaria se especifica el lugar donde fue tomada la presión, puede ser en el brazo izquierdo o derecho. Y luego hay dos signos vitales PQ donde se describe el valor tomado para el componente sistólico y el componente diastólico de este signo vital.

Debido a los múltiples tipos de signos vitales, se decide utilizar el patrón Polimorfismo para el manejo de los mismos, con el fin de aumentar la cohesión de estos componentes y disminuir su acoplamiento. Las clases que modelan cada uno de los tipos de signo vital, se pueden ver en la Figura 9. Todos implementan la interfaz IVitalSigns y lo que los diferencia unos de otros, es el contenido.

6.2.5 Características de las funciones CDA de HDS

HDS tiene la capacidad de generar documentos CDA válidos. Sin embargo debido a las restricciones de tiempo se limita el alcance de los eventos médicos implementados por HDS. Tanto las observaciones, los medicamentos y los signos vitales generados deben utilizar lenguajes definidos en el dominio de vocabularios codificado de CDA. Debido a la gran cantidad de palabras y códigos que estos sistemas implican, se decide limitar la implementación de los mismos para que proporcionen una implementación sencilla que sea válida contra los esquemas principales propuestos por el estándar. Esto impone una limitación al momento de al momento de interpretar este tipo de eventos con todos sus datos.

Por otra parte, es necesario que los documentos que se importen mediante las capacidades de HDS no contengan información acerca prescripciones de los pacientes. Esto se debe a que en HB 1.0 las prescripciones implementadas contienen un campo obligatorio en HB que describe la razón de la prescripción. En el estándar definido en ReleaseTwo.CommitteeBallot03 (CDA HL7 Organization, 2004) este tipo de campo fue eliminado. Para soportar esta caracteristica, en HB 1.1 se define un campo de texto libre aceptado por el estándar.

Respecto a los signos vitales, al momento de importar, se debe tener en cuenta que éstos no deben tener elementos tipo <text> que se utilizan en las transformaciones XSLT de signos vitales. También deben eliminarse todos los elementos utilizados para la transformación de unidades que se

32

denotan con el atributo <translation>. Por último, antes de importar se debe revisar que todos los valores tengan el atributo “unit” correspondiente así su valor se encuentra vacío.

6.2.6 Nuevos Servicios Web

Los servicios generados por este componente son expuestos a las capas superiores mediante Servicios Web. Para este objetivo se crean dos paquetes. El paquete DataServices que contiene la clase DataServicesManager encargada de manejar la lógica de los nuevos servicios que presta HDS se puede observar en la Figura 10. Este paquete orquesta los servicios prestados por las fachadas IeXistManager, ImpCommunityFacade y por ICDAVitalSigns, para integrar lo hecho en HDS a los servicios prestados por el núcleo de HB.

Figura 10. Vista del paquete DataServices

El segundo paquete llamado VitalSigns se encarga de exponer los servicios que presta la aplicación de gestión de signos vitales como servicios Web. Contiene la clase llamada VitalSignsServicesWS como se observa en la Figura 11.

33

Figura 11. Vista del paquete VitalSigns

La clase VitalSignsServicesWS se encarga de manejar los mensajes entre el manager y las capas superiores. Los mensajes que se manejan en esta clase son cadenas de caracteres o mensajes codificados XML. La mayoría de mensajes que se utilizan, son mensajes de los componentes de comunidad para la validación de usuarios. Solamente se crearon dos mensajes XML nuevos para los servicios Web y son los referentes a crear un nuevo signo vital y a consultar los signos vitales. Estos mensajes se crearon de forma sencilla para efectos de la demostración Web y por lo tanto no abarcan toda la información generada por un signo vital CDA.

6.2.7 Mensajes XML de Signos Vitales.

Particularmente exponer la información manejada por HDS se construyeron dos mensajes XML con información de signos vitales, como anteriormente se mencionaba. El esquema del mensaje que se envía para crear un signo vital en Healthbook se aprecia en la Figura 12.

34

Figura 12. Mensaje XML para la creación de un signo vital.

Un mensaje de creación de signo vital cuenta con los siguientes elementos:

• Name: El nombre del signo vital a ingresar

• Type: El tipo de signo vital

• Date: Fecha en la que se ingresa el signo vital

• User: El usuario al que se le ingresa el signo vital

• Numerator: Campo que contiene los datos del signo vital.

• Denominator: Campo opcional que contiene los datos de un signo vital que tiene denominador.

El esquema se utiliza para consultar los signos vitales se puede ver en la Figura 13. Este mensaje XML debe ser capaz de tener un número ilimitado de signos vitales de todos los tipos. El mensaje

35

VitalSigns, contiene un número ilimitado de elementos Signo Vital. Los signos vitales individuales, son idénticos a los que se utilizan para crear un signo vital.

Figura 13. Esquema de mensaje XML para consultar Signos Vitales

6.2.8 Validación de documentos CDA

La base de datos eXist, valida los documentos XML si el usuario así lo define. Sin embargo, la validación se encuentra limitada debido a un problema en la versión del servidor de aplicaciones Tomcat (The Apache Software Foundation) que utiliza eXist para su funcionamiento (Exist Database XML Validation). Por esta razón se decide utilizar las funciones que presta DOM4J para éste propósito.

Sin embargo los documentos CDA utilizan en su cabecera una referencia un NameSpace cuya utilización es restringida en todas las implementaciones de herramientas para el manejo de XML (World Wide Web Consortium, 2006). Este NameSpace se puede observar resaltado en la Figura 14.

36

Figura 14. Cabecera de un documento CDA.

Esto impide generar documentos CDA completamente válidos ya que en el momento no es posible generar el NameSpace xmlns="urn:hl7-org:v3" que se encuentra en la cabecera de los documentos CDA.

El componente HDS ofrece la posibilidad de importar documentos CDA y para esto se debe verificar que los documentos a importar, sean documentos válidos contra el estándar CDA. La función de importar documentos, recibe documentos CDA SIN el NameSpace y manipula el archivo recibido para insertar el NameSpace restringido. Una vez insertado el este NameSpace, el documento es un documento CDA válido que puede ser importado a Healthbook. Pero debido a este NameSpace, las herramientas que manejan los XML tampoco se encuentran en capacidad de manipular estos archivos, por lo tanto el NameSpace es retirado una vez la validación ha sido exitosa, para su almacenamiento en la base de datos.

37

7. Implementación 

Al igual que los proyectos anteriores, HDS está implementado utilizando la versión 5 del lenguaje Java. Para el ambiente de desarrollo se utiliza Eclipse versión 3.2.0 (The Eclipse Foundation). Los nuevos servicios Web implementados por HDS se montan utilizando el servidor de aplicaciones jBoss 4.0.5 GA. Adicionalmente para el manejo y construcción y validación de la información XML se utiliza DOM4J versión 1.6.1.

Para generar la información clínica bajo el estándar CDA, se utilizó el esquema concebido en Agosto del 2004 por el comité de CDA llamado CDA.ReleaseTwo.CommitteeBallot03 (CDA HL7 Organization, 2004).

Para la base de datos, se utiliza eXist versión 1.2.4 llamada Rennes (Exist ), como un servidor de proceso independiente. Las funciones para XQuery y XPath son proporcionadas por el servidor de base de datos. Particularmente cuando la información se encuentra en memoria, se utiliza Jaxen versión 1.1 para estas funciones.

7.1 La base de datos eXist

Exist (Exist ) es una base de datos nativa XML implementada en Java como una aplicación empresarial JEE (Java Enterprise Edition). Puede ser desplegada en tres formas distintas.

• Como un Servlet: Parte de una aplicación Web.

• Como un servidor con proceso independiente: De esta forma utiliza su propia instancia de la máquina virtual de Java. Los clientes acceden mediante una conexión de red utilizando los protocolos XML-RPC o WebDAV o el API HTTP estilo REST.

• Embebida en una aplicación: Básicamente funcionando como una librería más de la aplicación.

Particularmente para este proyecto se escoge desplegar la base de datos como un servidor de proceso independiente, ya que esto brinda dos grandes ventajas: La primera es la instancia de la máquina virtual de Java es diferente, por lo tanto existe mayor capacidad de memoria en la instancia JVM de la aplicación y la base de datos; y la segunda es que se obtiene una mejor separación de componentes de la aplicación.

38

De las opciones para conectar la aplicación a eXist se escogió utilizar un API estándar para el manejo de bases de datos XML llamado XML: DB (XML:DB Initiative). Este API utiliza llamados XML-RPC para comunicarse con un servidor de base de datos remoto.

7.2 Estructura de Archivos de HDS

HDS se constituye dentro de la estructura general creada para HB por los proyectos anteriores. Esta estructura es el resultado de la integración de los componentes creados por HBPS (Rincón, 2008), HBCS (Moreno, 2008), HFS (Beltrán, 2008) y HDS objeto del presente trabajo.

Figura 15. Estructura de archivos de HB.

En la Figura 15 se observa la estructura general de archivos de HB, Los componentes de HDS se encuentran en el directorio persistance. También se observan los directorios en los que se encuentran las clases para la exposición a servicios Web, que son vitalSigns y dataServices.

7.3 Construcción de una demostración Web

Con el objetivo de mostrar la funcionalidad que proporciona el componente HDS, se implementa una demostración Web, que simula una aplicación satélite que consume los servicios de HDS. Esta demostración no pretende representar una aplicación para usuario final de HB, sino por el contrario demostrar la funcionalidad del componente HDS, motivo por el cual, se presentan las funciones de

39

HDS de manera sencilla, pero de tal forma que se evidencie el efectivo funcionamiento de los componentes.

7.3.1 Requerimientos funcionales de la demostración

Los requerimientos funcionales de esta demostración, que muestran las funcionalidades prestadas por el componente HDS son:

• Ingresar un nuevo Signo Vital

• Ver todos los Signos Vitales

• Ver los signos vitales por Fecha

• Exportar un documento CDA completo

• Exportar una parte del documento CDA

• Importar un documento CDA completo

Adicionalmente se tuvieron en cuenta algunos requerimientos no funcionales, como la posibilidad de hacer uso de las funciones de HDS desde un equipo remoto. Por este motivo se implementaron los servicios prestados por HDS como servicios Web. La aplicación de prueba de HDS hace uso de todos los servicios Web implementados.

7.3.2 Diseño de la demostración Web

Para el diseño de esta demostración se construyen 3 clases principales. La clase VitalSignsBean es responsable de la comunicación entre la interfaz gráfica y la lógica de la aplicación. La interfaz gráfica fue desarrollada utilizando tecnología JSP (Java Server Pages) que permite embeber código java dentro de HTML. La clase VitalSignsDelegate implementa la interfaz IVitalSignsServicesWS que expone los servicios de HDS como servicios Web. Esta clase localiza el servicio Web y comunica los mensajes del servicio Web al VitalSignsBean. El VitalSignsBean utiliza el XMLDemoParser para convertir los mensajes del servicio Web a objetos de negocio de la interfaz. La relación de estas clases se puede ver en la Figura 16.

40

Figura 16. Relación de clases de la demostración Web

7.3.3 Página de inicio de HB

La Figura 17 muestra la vista de la página de inicio de HB. Esta página permite ingresar el número de documento, el tipo de documento y el nombre del usuario que intenta iniciar sesión en HB. Si el usuario no está inscrito se le da la opción de inscribirse. Esta página no representa el proceso real de inicio de sesión de un usuario a HB. Existen tres botones que cargan la información relacionada con cada una de las aplicaciones de prueba. Como el objetivo de esta demostración es probar la funcionalidad de los componentes, la página de inicio separa las funciones de usuario para comunidad, historias clínicas y signos vitales. Debido a que todos los componentes de esta

41

demostración se encuentran relacionados, para iniciar sesión, se debe cargar la información de todos los componentes pulsando sobre los tres botones de inicio de sesión.

Figura 17. Página de inicio de HB

7.3.4 Página de inicio de HDS

Una vez el usuario ha iniciado sesión, y se dirige a la aplicación de HDS, será dirigido a la página principal de la misma. En esta página se presentan las opciones relacionadas con las funciones de HDS, como se muestra en la Figura 18. El usuario puede elegir entre consultar signos vitales, ingresar un nuevo signo vital o importar o exportar su información clínica.

42

Figura 18. Home de HDS

7.3.5 Página de consulta de Signos Vitales

Cuando el usuario elige consultar signos vitales se despliega la vista mostrada en la Figura 19. En esta página el usuario tiene la opción de consultar todos los signos vitales de su historia médica o filtrar los signos vitales por fecha. Los signos vitales son presentados en una tabla que puede ser organizada por el usuario eligiendo el criterio de organización, es decir, puede organizarlos por Nombre, Fecha o Valor.

43

Figura 19. Página de consulta de signos vitales

7.3.6 Página para Ingresar un Nuevo Signo Vital

En esta pantalla el usuario tiene la opción de ingresar un signo vital a un paciente. Cabe anotar que para ingresar un signo vital el usuario debe pertenecer al grupo de tratantes de HB. En esta se encuentran los menús necesarios para ingresar cualquier tipo de signo vital. Además los componentes de formulario, restringen la descripción de los signos vitales al uso de palabras que se encuentran dentro del Vocabulario para CDA definido por SNOMED CT. La vista de esta pantalla se puede apreciar en la Figura 20.

44

Figura 20. Página para Ingresar un Nuevo Signo Vital

7.3.7 Página de Importar o Exportar Historia Clínica

En esta página el usuario tiene la opción de importar o exportar su Historia clínica. La Figura 21 muestra las opciones que tiene el usuario en esta página. La primera opción es importar un archivo CDA. Para importar un archivo CDA se tienen algunas restricciones.

• El archivo a importar debe ser un documento válido contra el estándar CDA.

• El archivo a importar no debe tener el NameSpace restringido que usualmente tiene la cabecera de los archivos CDA.

• El archivo a importar no debe tener una sección de Medicaciones y la sección de signos vitales debe ser revisada para cumplir lo especificado en la sección 6.2.5 de este trabajo.

Además de importar, es posible exportar toda la historia clínica del usuario, o una historia clínica CDA con su cabecera con una de las tres secciones que maneja HDS que son, Observaciones, Prescripciones o Signos Vitales.

45

Figura 21. Página para Importar/Exportar Historia Clínica

46

8. Resultados y Trabajo Futuro 

Como resultado de este trabajo se obtiene el componente HDS completamente integrado a Healthbook. Este componente integra los servicios de CDA y aumenta el soporte para otras características CDA en HB. Además de esto se obtiene una demostración Web capaz de probar completamente los nuevos servicios de HDS.

El componente HDS además maneja la información XML perteneciente a la comunidad para los mensajes, los usuarios, los tratantes y las relaciones entre los mismos. HDS almacena toda la información de HB en una base de datos nativa, lo cual proporciona un punto centralizado de integración de toda la información de HB.

La demostración Web, se integra a la demostración pasada y muestra la integración de HDS a todos los componentes construidos en trabajos anteriores y del nuevo componente al hacer uso de todos los servicios implementados en HB.

Como se evidenció a lo largo de este trabajo, el componente HDS genera documentos CDA válidos contra su esquema y permite la interoperabilidad de la información clínica, permitiendo importar y exportar documentos clínicos bajo algunas limitaciones. Los elementos clínicos manejados por este componente son eventos básicos y no contemplan algunas características más profundas que el estándar permite.

Un trabajo posterior, es necesario para ampliar las características de los eventos médicos manejados por este componente. Con este trabajo se ha demostrado la extensibilidad de la arquitectura propuesta para HB, lo cual hace posible proponer como trabajo futuro, la extensión de las funciones de HB sobre CDA. También se hace necesaria la construcción de un módulo para el manejo del dominio de vocabulario codificado utilizando alguno de los sistemas de vocabulario definidos para CDA que permitan completar las funciones generadas por este trabajo.

47

9. Conclusiones

Se desarrolla satisfactoriamente el componente Healthbook data Services, cumpliendo con los objetivos propuestos y generando información clínica válida e interoperable. Se persisten los datos en un punto centralizado de manera eficaz y segura, utilizando la base de datos eXist.

El componente se desarrolla utilizando una arquitectura extensible, que cumple con los requerimientos de funcionalidad para el almacenamiento de datos. Además proporciona la posibilidad de almacenar otro tipo de información aun no implementada en Healthbook para su posterior utilización por componentes que sean capaces de interpretarla.

HDS proporciona capacidades para exportar la información médica generada, lo cual brinda la posibilidad de integrar esta información a otros sistemas y de nuevo a HB1.1.

48

10.  Bibliografía 

• BaseX Universidad de Konstanz. (2008). BaseX Org. Recuperado el 12 de Enero de 2009, de http://basex.org/

• Beltrán, J. D. (Junio de 2008). INTERFAZ DE SERVICIOS Y VALIDACION DE DATOS PARA HEALTHBOOK. Healthbook FileSystem . Bogota, Colombia: Universidad de los Andes.

• CDA HL7 Organization. (Agosto de 2004). Technical Comitees and Special Interests Group. Recuperado el 11 de Enero de 2009, de http://www.hl7.org/special/Committees/ccow_sigvi.htm

• Dolin, R. H., Alschuler, L., Boyer, S., & Beebe, C. (2004). Clinical Document Architecture Release 2.0. Recuperado el 02 de Enero de 2009, de http://xml.coverpages.org/CDA-Release2-Unofficial.html

• Exist . (s.f.). Open Source Native XML Database. Recuperado el 15 de Octubre de 2008, de http://exist.sourceforge.net/index.html

• Exist Database XML Validation. (s.f.). XML Validation. Recuperado el 12 de Enero de 2008, de http://demo.exist-db.org/docs.xql?path=/db/xqdocs/validation.xml&q=.%2F%2Fsection%2Ftitle%5B.%20%26%3D%20'schema'%5D%20or%20.%2F%2Fpara%5B.%20%26%3D%20'schema'%5D&id=1.3.3.5.5#sect6

• Gamma, E., Helm, R., johnson, R., & Vlissides, J. (1994). Dessign Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

• HL7 Organization. (1987). Health Level 7. Recuperado el 6 de Noviembre de 2008, de http://www.hl7.org

• IBM Corporation. (s.f.). IBM WebSphere Transformation Extender. Recuperado el 12 de Enero de 2009, de http://www-01.ibm.com/software/integration/wdatastagetx/editions.html

• Jimenez, C., Bravo, G., & Castro, H. (11 de Abril de 2008). HealthBook : Red social de información de salud, centrada en el paciente. Recuperado el 11 de Noviembre de 2008, de http://agamenon.uniandes.edu.co/%7Ecjimenez/wiki/doku.php?id=healthbook

49

• Logical Observation Identifiers Names and Codes. (28 de Agosto de 2008). LOINC Overview. Recuperado el 12 de Enero de 2009, de http://loinc.org/faq/getting-started/getting-started/

• Lopez Ramirez, C. H. (Enero de 2007). Generic Grid Interface for Multimedia XML Services. Generic Grid Interface for Multimedia XML Services . Bogotá, Colombia: Universidad de los Andes.

• Meier, W. M. (s.f.). Exist Developers Guide. Recuperado el 20 de Octubre de 2008, de http://exist.sourceforge.net/devguide_xmldb.html

• Moreno, M. A. (Junio de 2008). REDES SOCIALES APLICADAS A LA SALUD. Healthbook Community Services HBCS . Bogotá, Colombia: Universidad de los Andes.

• Oracle Corporation. (s.f.). Oracle Berkeley Database. Recuperado el 12 de Enero de 2009, de http://www.oracle.com/database/berkeley-db/xml/index.html

• Red Hut Middleware. (s.f.). Hibernate. Recuperado el 12 de Enero de 2009, de http://www.hibernate.org/

• Rincón, M. A. (Junio de 2008). SOLUCION DE ALMACENAMIENTO DE HISTORIAS CLINICAS EN LA RED. Healthbook Patient Services . Bogota, Colombia: Universidad de los Andes.

• The Apache Software Foundation. (s.f.). Apache - Tomcat. Recuperado el 12 de Enero de 2008, de http://tomcat.apache.org/

• The Eclipse Foundation. (s.f.). eclipse.org. Recuperado el 11 de Enero de 2008, de http://www.eclipse.org

• The Java SIG Proyect. (s.f.). HL7 Java SIG. Recuperado el 12 de Enero de 2009, de http://aurora.regenstrief.org/javasig/wiki

• United States Medical Library of Medicine. (01 de Septiembre de 1999). Medical Subject Headings Fact Sheet. Recuperado el 12 de Enero de 2009, de http://www.nlm.nih.gov/pubs/factsheets/mesh.htm

• United States National Library of Medicine. (26 de Marzo de 2004). SNOMED Clinical Terms. Recuperado el 12 de Enero de 2008, de http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html

50

• World Wide Web Consortium. (16 de Agosto de 2006). Namespaces in XML 1.0 (Second Edition). Recuperado el 01 de Enero de 2008, de http://www.w3.org/TR/REC-xml-names/

• World Wide Web Consotrtium. (s.f.). XQuery Test Suite Result Summary. Recuperado el 12 de Enero de 2009, de http://www.w3.org/XML/Query/test-suite/XQTSReportSimple.html

• XML:DB Initiative. (s.f.). XML:DB Initiative: API for XML Databases. Recuperado el 08 de Enero de 2009, de http://xmldb-org.sourceforge.net/xapi/

51

Anexo A – Instrucciones para el despliegue de la base de datos eXist 

Una vez instalada la base de datos, es necesario editar algunos archivos de configuración.

• Se descarga el eXist.jar que corresponde a la versión 1.2.4 de eXist. Se instala ejecutando el .jar por consola de comandos o haciendo uso del JRE instalado en el sistema operativo.

• Se debe editar el archivo conf.xml que se ubica en el directorio base de instalación y se debe editar el elemento validation para que quede de la siguiente forma <validation mode="no">. Esto impide que la base de datos intente validar los documentos XML que contengan referencia a un esquema. Esto se hace debido a que las funciones de validación de exist están limitadas (Ver Item 6.2.8 de este documento).

• Además se debe editar el archivo jetty.xml que se encuentra en eXist\tools\jetty\etc para modificar el puerto del servidor Web que utiliza eXist para evitar conflictos con JBoss. La propiedad a editar es <SystemProperty name="jetty.port" default="8090"/>.

• Una vez instalado eXist, se debe crear la colección Healthbook desde la consola administrativa para el funcionamiento de HB.