Método Flexible de Persistencia y Presentación de Observaciones Clínicas

Transcripción

1 Método Flexible de Persistencia y Presentación de Observaciones Clínicas Zottola Pareja, Darwin Rodrigo 1 1 Departamento de bioingeniería, Facultad de Ciencias Exactas y Tecnología, Instituto de Bioelectrónica, Facultad de medicina, Universidad Nacional de Tucumán, Av. Independencia 1.800, San Miguel de Tucumán, Tucumán, Argentina rodrigozeta@gmail.com Resumen. El siguiente trabajo propone método de persistencia de información, flexible y dinámico, y su aplicación en un prototipo Prototipo Web para Telemedicina, desarrollado como parte de un proyecto que busca generar una red de telemedicina para el Sistema Provincial de Salud de la Provincia de Tucumán. La actual arquitectura de software,que contiene un modelo puramente relacional en su capa de persistencia, presenta en particular el inconveniente de que la gestión y administración de la información referente a observaciones clínicas, que se caracterizan por una gran variabilidad en su estructura y tipo de datos, implica un nuevo diseño e implementación del esquema de datos cada vez que se ingresa un nuevo tipo de observación, impactando en el resto de las capas de la arquitectura ante lo cual dicho método propone formas alternativas al manejo actual de la información dentro del sistema representando observaciones clínicas con estructuras en lenguaje XML, y que sirven además de base a la capa de presentación. De esta manera, nuevos tipos de observaciones clínicas tienen que ver con agregar el modelo correspondiente en XML y su presentación, impactando mínimamente en la arquitectura. Logrando así soluciones basadas en software libre, otorgando flexibilidad a la hora de crear y visualizar las estructuras, facilitando su manejo y el mantenimiento del sistema total. 1. Introducción EL proyecto de telemedicina en Tucumán[1] surge en base a la existencia de numerosos centros asistenciales de diversa complejidad que pertenecen al Sistema Provincial de Salud de Tucumán (SIPROSA) y se encuentran dispersos en el interior de la provincia. En dichos centros existe un aprovechamiento deficiente de los recursos físicos y humanos, así como la mala difusión de los servicios que se prestan y la falta de médicos especialistas, ocasionando la generación de un importante número de derivaciones innecesarias hacia los centros de mayor complejidad. La Organización Mundial de la Salud (OMS), define a la Telemedicina como: El suministro de servicios de atención sanitaria, en los que la distancia constituye un factor crítico, por profesionales que apelan a las tecnologías de la información y de la comunicación con objeto de intercambiar datos para hacer diagnósticos, preconizar tratamientos y prevenir enfermedades y heridas, así como para la formación permanente de los profesionales de atención de salud y en actividades de investigación y evaluación, con el fin de mejorar la salud de las personas y de las comunidades en que viven. [2]. En base a esta definición queda claro que el intercambio de datos, trae consigo una variedad y complejidad de fuentes de información tales como señales, imágenes, videos y documentos de texto,

2 que se suelen presentar en un encuentro real de interconsulta con el objetivo de elaborar un diagnóstico, debatir tratamientos, traslados, etc. lo que supone la existencia de un gran número de formatos distintos que complican su manipulación. Hablando específicamente de las observaciones clínicas, veremos que su complejidad puede variar dependiendo el tipo de las mismas, así como de la exactitud deseada en sus resultados. Pero el mayor problema no estará solamente en la variedad de datos si no específicamente en la variedad de estructuras correspondientes a nuevas observaciones que deben ser agregadas con una frecuencia considerable, es de esta manera que estas estructuras impactan de una manera considerable en el sistema en general, forzando a un nuevo diseño e implementación de cada una de las capas de su arquitectura. Sobre esta problemática las propuestas de este trabajo se basan en tomar la arquitectura existente en el proyecto de telemedicina y otorgar soluciones en las etapas más afectadas utilizando entre otras cosas la tecnología XML(Extensible Markup Language) y las herramientas disponibles para la manipulación de este tipo de archivo de texto que poseen datos y su respectiva estructura. La utilización de nuevos frameworks y soluciones basadas en software libre, para otorgar flexibilidad a la hora de crear y visualizar las estructuras, facilitar su manejo y el mantenimiento del sistema total. 2. Prototipo Web para Telemedicina Arquitectura. La Figura 1 muestra un esquema de la arquitectura actual de la aplicación de telemedicina. Figura 1. Arquitectura Prototipo Web Para Telemedicina En la misma distinguimos 4 capas: La capa de datos que es donde residen los datos y es la encargada de acceder a los mismos; la Base de Datos (BD) donde se almacenan los documentos multimedia, datos de pacientes y sus observaciones clínicas, agentes de salud colaboradores, etc. (Implementada con MySQL). La capa de negocios donde residen los programas que se ejecutan, es también donde se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Estas reglas de negocios creadas en esta capa fueron implementadas con lenguaje Java 1.6. La capa que se encuentra entre la capa de aplicación y las vistas de navegador web, fue confeccionada con Java Server Faces (JSF)[3] particularmente mediante el framework ICE Faces 1.8 [4]. Y por último la capa de presentación que es la que se comunica con el usuario final. 3. Observaciones Clínicas y su estructuras En las figuras 2 y 3 se observa cuan complejas y disímiles pueden llegar a ser las estructuras de datos creadas a partir de las observaciones Clínicas, en el ejemplo se puede observar las estructuras de dos tipos: Presión sanguínea y Temperatura corporal ambos propuesto por openehr [5] una fundación sin fines de lucro la cual desarrolla especificaciones y código, de código abierto con el propósito de buscar estándares para los sistemas en medicina.

3 Figura 2. Presión sanguínea según openehr. Figura 3. Temperatura corporal según openehr. Ambos gráficos confirman la afirmación de que la estructura de una respectiva observación clínica puede crecer en base a su complejidad o la exactitud buscada en la misma. Estas dos observaciones deberán almacenar diferentes tipo de información y el sistema deberá tener la capacidad de administrarlas y poder mostrarlas en su interface para cualquier consulta, modificación y sobre todo en los casos en que una consulta de un tipo de observación requiera el mostrar por ejemplo los datos de la presión sanguínea y temperatura de un mismo paciente para una consulta en particular. Este estándar propone divisiones dentro de los datos mismos en la presión Data haciendo referencia a los datos propios de la observación de presión sanguínea; la presión diastólica o sistólica, presión arterial media y el pulso, mientras que en la temperatura corporal la división Data solo contiene el dato que hace referencia a la temperatura misma, por el contrario hace hincapié en State donde se destacan datos referente al estado del paciente al momento de ser efectuado el estudio como la exposición del cuerpo o datos referentes a las condiciones del entorno en donde fue efectuada dicha observación, ciclo mestrual,etc. Estas observaciones que son habituales, y a veces complementarias, marcan una clara diferencia tanto en la forma que toma la estructura como en los datos que se almacenan y como varía la importancia de cada una. Si a esto se suma el hecho de que existen algunas observaciones que requerirán el apoyo de, por ejemplo, datos multimedia, imágenes, sonidos, ect. Otras veces se cuenta con estudios y observaciones que serán una composición de dos o más. Es decir, por ejemplo que no serán los mismos datos los que se necesitaran enviar en una ecografía, en un puntaje de pagar, presión

4 sanguínea, audiometría, etc; de esa manera podríamos nombrar una lista voluminosa de observaciones clínicas, totalmente distintas en la información que ofrecen, y la cual no solo debe persistir en el sistema, sino que el mismo debe tener la capacidad de mostrarla de una manera eficiente al respectivo usuario. En base a esto en las figuras 4 y 5 se proponen esquemas reducidos, para otorgar gráficamente una manera de comprender y mostrar, como el ingreso de una observación nueva al sistema genera cambios en todas las capas de la arquietectura del sistema. Figura 4. Versión reducida de Blood Pressure. Figura 5. Versión reducida de Body Temperature. 4. Nueva Arquitectura Con las capas actuales el proceso para agregar un nuevo tipo de observaciones clínicas de manera gráfica seria el siguiente: (Figura 6)

5 Figura 6. Observ. generan estructuras y estas se unen a una mayor Si consideramos cualquiera de los dos casos Presión sanguínea (Blood Pressure) y temperatura corporal (Body Temperature), cada observación generará una estructura de datos nueva con sus respectivas tablas en base a sus necesidades en cuanto a los datos necesarios es por eso que tendrán sus propios atributos y relaciones que deberán ser agregadas a la base de datos ya existente lo que genera un cambio en las relaciones y reglas de claves establecida en la base de datos preexistente obligando a un rediseño y una nueva implementación de la base de datos, por la inserción de cada una de ellas. Como primera propuesta se sugiere tomar una porción de la base de datos, es decir la que hace referencia a las observaciones, y almacenar estas estructuras en forma de metadatos dentro de un archivo de texto como lo indica la figura 8, de manera que esto nos permita que su manipulación sea general, flexible e independiente del modelo relacional, haciendo hincapié en mantener la coherencia con el modelo original. Figura 8. Una observación y su estructura completa podrían estar dentro de un archivo de texto y el mismo dentro de una tabla como un dato tipo TEXT. Así, la antigua capa de datos queda dividida en dos capas: la capa de datos propiamente dicha y una nueva capa que llamada capa de integración, quedando una nueva arquitectura de la manera en que se muestra en la Figura 9. Figura 9. Nueva Arquitectura propuesta con capa de integración Por lo tanto en la nueva capa de datos solo existirá una tabla general que podría llamarse Estudios perteneciente al modelo actual del sistema que haría referencia a la lista de observaciones que se manejarán en el mismo, es decir que el ingreso de cada tipo de observación clínica solo verá afectada la base de datos actual al momento de agregar una fila en la tabla mencionada, dejando el control de los datos como la formación de sus estructuras a la capa siguiente: La capa de integración Capa de integración En esta capa se encuentran los componentes que nos permiten hacer más transparente el acceso a la capa de datos. Obtendremos de ella las estructuras de datos a partir de un metadato, es decir el archivo de texto posee toda la información de dichas estructuras en su interior, a su vez obtendremos de este

6 archivo los datos de cada observación clínica y su estructuras. Lo que permitirá la manipulación de este archivo será el hecho que este escrito en lenguaje XML(Extensible Markup Language)[6], un metalenguaje que puede ser utilizado para describir la estructura lógica y el contenido de una gran variedad documentos por lo tanto permite definir lenguajes de marcado adecuados a usos determinados y de esta manera darle un requerido formato a la información, la cual se manipula en forma de texto. En base a las reglas para escribir archivos XML Blood Pressure el formato es mostrado en la figura 10. Figura 10. BloodPressure.xml Dicho archivo XML posee los datos de la observación entre las etiquetas con los nombres correspondientes, de esta manera genera una jerarquía del tipo árbol en donde se puede o no, agrupar los distintos campos. Si bien se definen los nombres de los datos y su jerarquía pero no así el tipo de dato a utilizar, por lo tanto aún no se declaró ningún tipo de restricción y el campo Systolic, por ejemplo, sin restricción podría ser un dato tipo texto y no un dato tipo numérico como muestra el ejemplo y a un así ser un documento xml bien formado, lo que quiere decir que cumple con las reglas sintácticas del lenguaje XML. De la misma manera la temperatura, por contraparte tendría el archivo mostrado en la Figura 11.

7 Figura 11. BodyTemperature.xml Para poder dar la estructura deseada a estos datos, XML posee una gramática definida que permite restringir los elementos válidos dentro de un nuevo derivado de XML y esto puede expresarse en forma de un archivo XSD (XML Schemas),que permite definir estructuras complejas pudiendo definir tipos de datos específicos. Se puede observar que cada archivo XML hace referencia a un archivo con extensión.xsd con su mismo nombre. Tomando como ejemplo a la Presión Sanguínea nuestro esquema en base a la gramática XSD (XML Schemas), tendrá el formato mostrado en la Figura 12. Figura 12. BloodPressure.xsd No solo se definen los tipos de datos sino que también obliga a que se respete la estructura jerárquica definida en el archivo y si se quisiera se podría restringir la cardinalidad como el nivel de anidamiento, por lo tanto toda observación clínica de la presión deberá respetar esta estructura y la restricción de datos para ser un archivo XML validado mostrado en la Figura11.

8 Figura 13. Un archivo de texto que se encuentra en una base de datos, en su interior poseerá las estructuras de datos y los datos en si en un archivo de texto(.xml) que hará referencia a otro que posee las reglas y restricciones para su formación.(.xsd) Por lo tanto tendremos dos archivos de texto: BloodPresured.xml en donde se encontraran los datos propiamente dichos y BloodPresured.xsd que poseerá la definición de las estructuras y los tipos de datos, ambos archivos serán comparados (Parsing) por una aplicación llamada parser, en nuestro caso utilizamos el parser Xerces[7] del proyecto apache que posee compatibilidad con XML Schemas, el resultado de esta comparación me dará el archivo validado o no, si el archivo BloodPressure.xml respeta las reglas de su par BloodPresured.xsd. Este proceso de Parsing se repetirá de la misma manera para la observación de Temperatura. Figura 14 Figura 14.Parsing: El parser Xerces toma ambos documentos tomando como referencia las reglas en BloodPressure.xsd y compara para poder validar BloodPressure.xml Así una vez obtenido el XML validado se utilizará JDOM [8] que es una biblioteca open source para la manipulación optimizada de datos XML optimizada para el lenguaje java. A diferencia de los demás Api (Application programming interface) para la manipulación de XML. JDOM es un api puro de java basado en árbol para crear, parsear, manipular y serializar documentos en XML. JDOM utiliza las convenciones de java y posee sus propias clases y métodos para la manipulación de XML. Gracias a JDOM se obtienen los datos solicitados por la capa de negocios o depositar dichos datos dentro de un archivo de texto con una estructura ya definida en la base de datos de manera transparente; es decir lograr que la capa de aplicación vea solo una capa de datos y no la fusión de estos datos mas la integración, como se puede observar Figura 14. Así la agregación de un tipo de observación solo verá afectada a la capa de integración y constara de la creación de dos archivos de texto escritos en lenguaje XML y su validación.

9 Figura 14. La capa de negocios ve aun la misma capa de datos y no ve la fusión entre la capa de datos y la capa de integración 4.2. Capa de Control Como ya se dijo, esta capa esta implementada con Java Server Faces (JSF) particularmente mediante el framework ICE Faces 1.8. Estas herramientas aportan benéficos tales como el poder utilizar tecnologías como AJAX acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML) [9], permite crear aplicaciones más interactivas y rápidas. Y las hojas de estilo CSS (Cascading Style Sheets) [10]. Entregando un diseño dinámico. Y como resultado despegar la presentación del contenido. Sin embargo la creación de las mencionadas estructura en las capas de datos afectaran las vistas existentes, teniendo que desarrollar las modificaciones de las actuales vistas por nuevas en las cuales se consideren los nuevos tipos de observaciones a la hora de, por ejemplo, ver los datos de presión correspondiente a un paciente en especial y mucho mayor, aun, en caso que se deba comparar más de una observación en la misma vista. En base a este problema, si se pudiera usar plantillas para las vistas de cada observación, se podría, también, hacer una anidación de las mismas y la reutilización de código de por medio; es decir crear una vista y poder utilizarla una y otra vez, combinándola con sus pares creando vistas complejas a partir de vistas independientes. Esto disminuiría el problema de la mantención del sistema, como asi también, la generación de las nuevas vistas, simplificando los procesos de esta capa en general. Asi Facelet [11], un framework para plantillas (templates), no solo cumple con lo antes expuesto si no que está centrado en la tecnología JSF y es un perfecto complemento de icefaces ya que incorpora nuevas funciones fáciles de desarrollar, siendo un perfecto componente para trabajar con las tecnologías utilizadas en nuestro sistema. Facelet también utiliza la creación de un árbol de UIcomponent (User Interface component) y soporta las deseadas plantillas reutilizables. De esta manera este framework entrega la posibilidad de crear una vista por cada nueva estructura proporcionado la capacidad de reutilizar cada facelet, poder anidarlos y agruparlos en una misma vista, según la necesidad. Estas cualidades de facelet llevarían a tener una correspondencia de uno a uno con la definición de la estructura, en este caso con BloodPressure.xsd; dándo la ventaja de agregar solo una plantilla nueva (facelets template) por cada observación agregada quedando casi intacta la interacción de las antiguas vistas haciendo que sea sencilla tanto su creación como su mantenimiento y/o modificación. Figura 15. Se puede crear una relación directa entre ls vistas y las estructura y combinar las vistas según sea necesario.

10 4.3. Capa de Negocios Por último la capa de aplicación o de negocios solamente se nombran los cambios hechos en la arquitectura. Idealmente no afectaran a la capa de aplicación inicial, y si bien la creación de una nueva estructura afectará su contenido el trabajo para llegar a ello será el mismo que con la arquitectura anterior. 5. Conclusiones Si bien las herramientas usadas, para solucionar las problemáticas de los sistemas de gestión en medicina, son esencialmente las mismas que hasta hoy dieron excelentes resultados en los sistemas de gestión comercial, empresarial, etc. Está claro que para problemáticas específicas en el mundo de la medicina como el trato de las observaciones clínicas, dichas herramientas suelen no ser del todo satisfactoria. Gracias a las tecnologías XML y las poderosas herramientas que posee para la manipulación de datos en forma de texto conseguimos la tan preciada flexibilidad en cuanto a la creación de estructuras independizándolas de las reglas del modelo relacional tradicional y aun así estar vinculados a el por medio de un identificador, creando una seudo unión entre una base de datos relacionales y una base de datos del tipo texto. Solo agregando una capa más a la arquitectura inicial para complementar la capa de datos y proponiendo el uso de un nuevo framework de tecnología web y su combinación con las tecnologías en uso, para alivianar los problemas existentes en la capa de control. Se logró que la inserción de nuevas observaciones clínicas, impacte mínimamente en el sistema inicial, creando por así llamarlo una línea paralela a todas las capas y relacionando de forma directa lo que sería la definición de una estructura de datos con su respectiva vista. Sin que su creación y modificaciones exijan una reingeniería del sistema en su totalidad. Como valor agregado se puede considerar que todas las herramientas utilizadas son software libre y de un uso en alza en los últimos tiempos. Lo que logramos es solucionar en parte problemas de forma innovadora empleando tecnologías actuales y variadas para atender las necesidades aún no resueltas del todo de la forma tradicional. Referencias Bibliográfica [1] Prototipo Web para Telemedicina (SABI 2009).Pablo F. Solarz, Viviana I Rotger y Luis Medina Ruiz [2] IN SALUD PLAN DE TELEMEDICINA. Ministerio de Sanidad y Consumo. MADRID [3] Sitio de Sun Microsystems sobre la tecnología Java Server Faces. [4] Sitio de ICEsoft Technologies Inc. Sobre tecnología ICEFaces- / ICEfaces 1.8: Next Generation Enterprise Web Development Rainer Eschen [5] Sitio de la fundación openehr [6] Sitio Recomendaciones W3C [7] Apache Jakarta Xerces ( [8] Sitio sobre el proyecto JDOM. [9] Jesse James Garrett ( ), Articulo que origino el nombre a dicha tecnología [10] Recomendaciones W3C [11] Facelets Essentials -Bruno Aranda and Zubin Wadia / ICEfaces 1.8: Next Generation Enterprise Web Development Rainer Eschen / Core Java Server Faces David Geary cay Horntmann