Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090

Escola Tècnica Superior d’Enginyeria Informàtica Universitat Politècnica de València Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. Proyecto Final de Carrera Ingeniería Técnica en Informática de Gestión Autor: Sergio Rodríguez Muñoz Directores: Montserrat Robles Viejo, José A. Maldonado Segura 25 de Septiembre de 2012 Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 2 3 Resumen En la metodología de modelo dual para el modelado de la historia clínica electrónica los arquetipos definen los potencialmente numerosos conceptos del dominio como problema, hoja de interconsulta, presión sanguínea, etc. En la definición de arquetipos, a parte de las terminologías de propósito puramente clínico, se hace uso de una gran cantidad de pequeñas terminologías que sirven para definir el contexto clínico de la información. Este proyecto tiene como objetivo el desarrollar un sistema informático en Java basado en la norma ISO 21090 de tipos de datos en salud para la gestión y consulta de estas terminologías por parte de un editor de arquetipos. Palabras clave: historia clínica electrónica, arquetipos, terminologías, modelos de información, tipos de datos en sanidad, ISO 21090, informática médica, JAVA, Hibernate, hypersql. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 4 Tabla de contenidos CAPÍTULO 1: INTRODUCCIÓ N. ........................................................................................ 6 1.1 - Problema a resolver ................................................................................................. 6 1.2 – Objetivos y alcance del proyecto ............................................................................ 7 1.3 - Contexto de realización de proyecto ....................................................................... 7 CAPÍTULO 2: MODELADO DE LA HISTORIA CLÍNICA ELECTRONICA (HCE). ........ 8 2.1 - Problemas en el modelado de la HCE ..................................................................... 8 2.2 - Modelo dual de AHCE .......................................................................................... 10 2.3 - Uso de terminologías en las AHCE ........................................................................ 11 2.4 -Tipos de datos en sanidad ...................................................................................... 12 2.4.1 - Tipos de datos para la representación de terminologías ............................... 12 CAPÍTULO 3: DISEÑO. .................................................................................................... 19 3.1 - Planificación del proyecto mediante modelos. ..................................................... 19 3.2 - Planificación de la distribución y la persistencia de datos. ................................. 21 3.3 - Métodos y consultas de la base de datos. ............................................................. 22 CAPÍTULO 4: IMPLEMENTACIÓN DEL PROYECTO. .................................................. 25 4.1 - Fase 1: implementación objetos java. ................................................................... 25 4.2 - Fase 2: Base de datos. .......................................................................................... 26 4.2.1 - Hibernate. ....................................................................................................... 27 4.2.2 - Archivos de mapping. ..................................................................................... 28 4.2.3 -Volcado de datos a un XML. ........................................................................... 30 4.3 - Fase 3: Métodos para la interfaz de usuario. ....................................................... 33 CAPÍTULO 5: PRUEBAS DE FUNCIONAMIENTO. ....................................................... 37 5.1 - Pruebas funcionales. .............................................................................................. 37 CAPÍTULO 6: CONCLUSIONES. .................................................................................... 40 6.1 - Conclusiones sobre el trabajo realizado. ............................................................. 40 6.2 - Conclusiones personales. ..................................................................................... 40 6.3 - Posibles ampliaciones y mejoras. ......................................................................... 41 CAPÍTULO 7: BIBLIOGRAFÍA. ........................................................................................ 42 5 Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 6 CAPÍTULO 1: INTRODUCCIÓN. En la actualidad, dentro del ámbito clínico la necesidad de comunicación y transmisión de la información se hace cada día más necesaria. El uso de estándares para la comunicación de las historias clínicas electrónicas (HCE) es crucial para asegurar que la comunicación se realiza de manera segura y conservando el significado original de los datos, es decir con un nivel de interoperabilidad semántica suficiente. Pero la adopción de estos estándares es costosa, debido principalmente complejidad de propios estándares y del dominio clínico. Por todo ello, son necesarias herramientas que oculten lo máximo posible la complejidad de los estándares. Una de las principales y primeras tareas en cualquier proyecto de intercambio de HCE es la definición de los conceptos del dominio (por ejemplo hoja de interconsulta, informe de alta, lista de medición, etc.) a comunicar y establecer su relación con el estándar de HCE utilizado. La metodología del modelo dual [1] de arquitectura de historia clínica electrónica facilita mecanismos para este fin. En este modelo existe una clara separación entre la representación de datos (el modelo de referencia) y la representación de los modelos clínicos (el modelo de arquetipos). Mientras que el primero proporciona una sintaxis para representar cualquier dato de la historia clínica electrónica así como de la información de contexto necesaria para interpretarla correctamente, los arquetipos permiten definir de manera formal los conceptos del dominio. Esta aproximación se utiliza en la norma ISO 13606 [2], así como por las especificaciones de openEHR [3]. También HL7 v3 [4] utiliza una metodología similar, si bien no emplea el concepto de arquetipo, la cual define un modelo de referencia y un mecanismo de refinamiento para crear modelos de dominio específicos. 1.1 - Problema a resolver Los arquetipos son el vínculo de las estructuras de información con las terminologías (vocabulario) y potencialmente con las ontologías que describen la semántica de la información clínica. Existen diversos terminologías relevantes en el ámbito clínico, que van desde simple listas de términos a ontologías basadas en algún formalismo lógico como Snomed-CT. En la definición de arquetipos se hace uso de dos tipos de terminologías: las puramente clínicas y la de contexto clínico. En el caso de las terminologías puramente clínicas, como Snomed-CT o LOINC, y debido a su complejidad (en el caso de Snomed-CT estamos hablando de más de 300000 términos) es necesario utilizar servidores de terminología con funcionalidades avanzadas. Por el contrario las terminologías de contexto son pequeñas terminologías 7 que pueden ser externas o definidas en el propio modelo de referencia. Contienen términos que sirven para interpretar adecuadamente un extracto de HCE, clasificar los extractos o especificar información ético-legal como auditoría, idioma o control de cambios. Por tanto, están íntimamente relacionadas con el modelo de referencia y son básicas en la definición de arquetipos. Como consecuencia es recomendable que los editores de arquetipos sean capaces de gestionar estas pequeñas terminologías de manera independiente de los servidores de terminología, los cuales no están disponibles en la mayoría de las organizaciones y ofrecen interfaces de consulta variable. Por otro lado, los modelos de referencia en sanidad imponen el uso de un conjunto de tipos de datos, por ejemplo norma ISO 21090 [5], para la representación de la información que incluyen tipos para la representación de términos codificados lo cuales hay que tener en consideración. 1.2 – Objetivos y alcance del proyecto Diseño e implementación de un sistema informático en Java basado en la norma ISO 21090 (Tipos de datos para la salud) para la gestión y consultas de pequeñas terminologías, concretamente: · Terminologías locales de los modelos de referencia para la comunicación de la historia clínica electrónica como ISO13606 o CDA. · Terminologías que aportan contexto básico a la información clínica como ISO 639-2 (Idiomas) o ISO 3166 (países). Este sistema informático estará orientado para su uso en la definición formal de conceptos clínicos expresados como arquetipos. Su uso es relevante tanto para detallar los metadatos del arquetipo (por ejemplo idiomas soportados) como en la definición de los conceptos clínicos a partir de los modelos de referencia. 1.3 - Contexto de realización de proyecto Este proyecto fin de carrera se ha realizado bajo la dirección de Montserrat Robles y José Alberto Maldonado miembros del grupo de Informática Biomédica (IBIME) del Instituto ITACA. El trabajo a desarrollar se encuadra dentro de la línea de investigación en el modelado semántico de historias clínicas electrónica de IBIME y pretende facilitar una herramienta para la consulta de pequeñas terminologías durante la edición de arquetipos. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 8 CAPÍTULO 2: MODELADO DE LA HISTORIA CLÍNICA ELECTRONICA (HCE). 2.1 - Problemas en el modelado de la HCE En la actualidad, el intercambio de información clínica entre profesionales sanitarios o entre sistemas informáticos es hoy en día un problema crítico para el sector sanitario. Este intercambio debe realizarse conservando fielmente el significado original de los datos (interoperabilidad semántica) y la integridad médico-legal. Este problema de comunicación no es trivial y es aún más complejo que en otros sectores. La principal razón es la propia complejidad y variabilidad de la medicina que da lugar a modelos muy grandes, cambiantes y difícilmente manejables. La medicina no es sólo muy amplia, sino que no tienen límites: · En amplitud: porque cada día se descubre nueva información o información que no era relevante ahora si lo es. · En profundidad: porque cada día se descubre información más detallada o ésta pasa a ser relevante. · En complejidad: porque siempre se descubren nuevas relaciones o relaciones que no eran relevantes ahora si lo son. A esto se debe añadir la gran heterogeneidad en cuanto a las necesidades de los usuarios de la información: pacientes, facultativos, investigadores, gestores, laboratorios, gestores, etc. Un aspecto clave a la hora de intercambiar historias clínicas electrónicas (HCE) es el contexto, de hecho, se suele dividir cualquier anotación en una historia clínica electrónica en tres partes: contenedor (encabezamientos de secciones, subsecciones y elementos atómicos de información), contenido y contexto. Se puede definir el contexto como cualquier tipo de información que influye en la interpretación de una anotación. Esta información es básica para poder conservar fielmente el significado de los datos clínicos y para preservar la integridad médico-legal. La información de contexto puede ser de diversos tipos: · Contexto estático o posición de la anotación dentro de la historia clínica. 9 · Contexto dinámico representado por todas aquellas anotaciones que influyen en el significado de la anotación considerada. · Contexto de seguridad que engloba todos aquellos detalles que son esenciales para interpretar correctamente una anotación, por ejemplo: sujeto (paciente, donante, feto, familiar del paciente…), estado especial del paciente (diabético/a, embarazada, alérgico/a…), certeza (confirmado, suposición, descartado...). · Contexto ético y legal que engloba toda aquella información relevante para cumplir los requerimientos de la legislación vigente y para dar soporte a posteriores labores de auditoria o control, como responsable de la atención sanitaria, persona o dispositivo que registró la información, firma digital, fechas y horas de las acciones sanitarias y de registro de la información en el sistema informático. Es por todo esto, que uno de los aspectos más importantes a la hora de desarrollar cualquier sistema que intercambie o gestione información clínica es cómo organizar la información para que satisfagan todos estos los requerimientos básicos. Una arquitectura de información de la historia clínica electrónica (AHCE) modela las características genéricas aplicables a cualquier anotación en una historia clínica independientemente de la organización (primaria, especializada, etc.), del profesional (médico, enfermera, etc.), especialidad o uso (asistencial, investigación, salud pública, etc.). Una AHCE como un modelo conceptual de la información que puede estar contenida en cualquier HCE por tanto modela las características comunes a todas las HCE, pero no detalla qué información debe estar contenida en una historia ni cómo un sistema de HCE debe implementarse. El desarrollo de una AHCE precisa de un elevado nivel de abstracción para definir componentes de uso general que permitan describir cualquier entrada en una historia clínica. Las organizaciones de normalización en el sector sanitario como HL7 o CEN/TC 251 y de propósito general como ISO han sido conscientes de la importancia de las AHCE para facilitar la interoperabilidad semántica de la HCE. Una de las aportaciones más importantes de la última generación de AHCE es el uso de un modelo dual para su especificación. Concretamente, la norma ISO 13606 [1], la arquitectura propuesta por el consorcio OpenEHR [2] y en cierta medida HL7 CDA [3] se basan en un modelo dual. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 16 “translation” será una lista vacía. Sólo el CD raíz tiene un conjunto de traducciones que enumera todas las posibles traducciones. · source <<CD>>: Una referencia a la terminología CD que es la fuente de esta traducción. Se empleará este atributo si este CD fue creado para traducirlo de otro CD. Esta propiedad es una referencia, y se utiliza en los CDs dentro del grupo de CDs que representan el mismo concepto. Ilustrando el tipo de dato de codificación descrito anteriormente se encuentra este ejemplo. <CD> <Code>784.0</Code> <CodeSystem>2.16.840.1.113883.6.42</CodeSystem> <CodeSystemName>ICD-9</CodeSystemName> <CodeSystemVersion>3.0</CodeSystemVersion> <ValueSet>2.16.840.1.113883.19.11.1</ValueSet> <ValueSetVersion>20070711</ValueSetVersion> <CodingRationale>12</CodingRationale> <Translation> <Tranlations> <CD> <Code>784.0</Code> <CodeSystem>2.16.840.1.113883.6.42</CodeSystem> <CodeSystemName>ICD-9</CodeSystemName> <CodeSystemVersion>3.0</CodeSystemVersion> <ValueSet>2.16.840.1.113883.19.11.1</ValueSet> <ValueSetVersion>20070711</ValueSetVersion> <CodingRationale>12</CodingRationale> <DisplayName>Headache</DisplayName> <OriginalText>""</OriginalText> <Source>784.0</Source> </CD> </Tranlations> </Translation> <DisplayName>Headache</DisplayName> <OriginalText>Burnt ear with iron. Burnt other ear calling for ambulance</OriginalText> <Source>""</Source> </CD> Figura 1. Representación del arquetipo CD. CS – Coded Simple Value Codificado de datos en su forma más simple, donde el atributo “code” por si sólo está predeterminado. Las propiedades “codeSystem” y “codeVersion” del sistema están implícitas y establecidas por el contexto en el que el CS se produce. Debido a que está altamente restringida su funcionalidad, CS sólo se utilizará para simple atributos estructurales con terminologías muy controladas y estables. Respecto a la propiedad de igualdad entre dos valores de CS se determina únicamente en base al código explícito y el “codeSystem.” Otro dato relevante es que los valores de CS pueden ser iguales a los valores de CD si ambos especifican el mismo “code” y “codeSystem”, por tanto pueden ser comparados. 17 Atributos: · validTimeLow <<string>>. · validTimeHigh <<string>>. · controlActRoot <<string>>. · controlActExtension <<string>>. · nullFlavor <<string>>. · updateMode <<string>>. · flavorId <<string>>. Estos atributos proceden de la herencia de la especialización de ANY, por el contrario el siguiente es propio de la clase CS. · code <<string>>: Código simple definido por el sistema de codificación. Si el valor está vacío o es nulo, entonces no hay código en el sistema de código que representa el concepto. El código se define a partir de la combinación de estos caracteres: una letra, un dígito, un '-', '_' , '.' o ':'. La expresión que forma código no contendrá espacios en blanco ni otros caracteres que no están en esta lista. CD.CV - Coded Value Restringe a la terminología de la que se especializa, CD. Los datos son codificados, especificando sólo un código, código de sistema y, opcionalmente el nombre y el texto original. Sólo se utiliza como tipo de propiedades de otras terminologías de sistema. CV se utiliza para cualquier caso de uso que requiera un valor de código único para ser enviados. Por lo tanto, no debe utilizarse en circunstancias donde un determinado valor tenga varias alternativas que lo representen. No puede ser un requisito para migrar a un nuevo sistema de codificación. Atributos: Los atributos de esta terminología proceden de la especialización de CD en CD.CV. Ambas terminologías comparten los mismos atributos salvo porque la lista de traducciones y el atributo “originalText” para CD.CV tendrán valor nulo. · validTimeLow <<string>>. · validTimeHigh <<string>>. · controlActRoot <<string>>. · controlActExtension <<string>>. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 18 · nullFlavor <<string>>. · updateMode <<string>>. · flavorId <<string>>. · code <<string>>. · codeSystem <<string>>. · codeSystemName <<string>>. · codeSystemVersion <<string>>. · valueSet <<string>>. · valueSetVersion <<string>>: . · displayName <<string>>. · originalText <<string>>. · codingRationale <<string>>. · translation <<HashSet<CD>>>. · source <<CD>>. 19 CAPÍTULO 3: DISEÑO. En la etapa de diseño de un proyecto se dan respuesta a preguntas como la forma en la que se va desarrollar el proyecto para que cumpla con todos los requerimientos especificados, en que partes se divide, etc. En el módulo gestor de terminologías sobre el que se ha trabajado podemos distinguir que hay una parte de representación del concepto terminología y de los tipos de datos de codificación; una parte de almacenamiento de los datos; y por último unos servicios que ofrecer sobre ellas. El trabajo derivado de la etapa de diseño es necesario ya que es tan importante tener claro el trabajo a realizar como el saber la manera en la que se va a realizar. 3.1 - Planificación del proyecto mediante modelos. Los modelos suponen un estándar en la representación visual del proyecto. Es una herramienta de apoyo para los programadores con la que a través de diagramas conocen la envergadura del proyecto, sus componentes y como se estructura. Puesto que son estándares también son una buena herramienta para la documentación de los proyectos. En el sistema desarrollado aparecen los conceptos de terminología y de tipo de dato de codificación. Terminologías identificadas por un valor único para cada una de ellas, que tienen las propiedades nombre y versión y que a su vez contienen tipos de datos de codificación que amplían su información. Cada tipo de datos estándar de representación de códigos contiene información adicional que se especificada en el documento ISO 21090, estándar de comunicación de historias clínicas (HCE). Entre los lenguajes de modelado esta UML (Lenguaje Unificado de Modelado), el cual se usa para especificar, visualizar, modificar, construir y documentar los artefactos de un software orientado a objetos de obra sistema en desarrollo. Como la intención es representar los conceptos mencionados anteriormente se ha empleado el sistema de representación visual llamado Diagrama de Clases. El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. La figura 2 muestra el diagrama de clases del servidor de terminologías. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 20 Figura 2. Diagrama de Clases del proyecto sobre la gestión de terminologías clínicas. Tras analizar y estudiar cada una de las clases y las relaciones que existen entre ellas la implementación es más sencilla. Aunque esta la posibilidad de usar un programa que dado el diagrama genere de forma automática el código de las clases para este proyecto la implementación será manual. 21 Figura 3. Diagrama del clases del servidor de terminologías de contexto clínico. 3.2 - Planificación de la distribución y la persistencia de datos. Un vez que ya se ha dejado claro los tipos de datos de codificación que se van a trabajar hay que diseñar y estructurar conforme a la especificación de los tipos de datos el lugar de almacenamiento de las instancias de los objetos en el sistema. Lo habitual en este tipo de proyectos sería hacer uso de un servidor de terminologías pero en el caso tratado es inviable por su complejidad y coste. En su lugar, se empleará una base de datos que cumpla con todos los requerimientos especificados para las terminologías. El esquema entidad-relación del modelo conceptual de la base de datos se muestra en la Figura 3. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 22 Este diagrama recoge todas las entidades relevantes junto con sus atributos y las relaciones entre ellas con sus respectivas restricciones de cardinalidad. En el diseño se aprecia la jerarquía que se da en la entidad HXIT y como se especializan de ella diversas entidades. Estas entidades especializadas tienen restricciones de especialización total y disyunta para el caso de la entidad ANY y su descendencia. 3.3 - Métodos y consultas de la base de datos. A continuación se desglosan cada uno de los métodos diseñados para llevar a cabo las operaciones pertinentes de la interfaz de usuario. Son métodos de consulta, inserción, búsqueda, modificado y borrado sobre los objetos contenidos en el sistema gestor de terminologías. En definitiva constituyen el listado de operaciones que el usuario del sistema podrá realizar.  getAllTerminologies: Método público que devuelve una colección con las terminologías almacenadas en la base de datos. Esta función no recibe parámetros de entrada.  getAllElementsByTerminology: Método público que dado el identificador de una terminología devuelve el listado de elementos de tipo CD, CS o CDCV contenidos en ella. La colección devuelta puede ser una colección vacía si se da el caso de que a la terminología indicada no se le han añadido ningún tipo de datos de los mencionados.  searchElementIntoTerminology: Dado un identificador de un tipo de dato (CS, CD o CDCV) a encontrar y un identificador de un terminología donde buscarlo se devuelve el objeto solicitado en caso de encontrarse en la lista de elementos de la terminología o un nulo junto a un mensaje de error si no se ha encontrado. Es un método público y forma parte de los métodos para la interfaz de usuario.  createTerminology: Método público cuya función es insertar entrada en la tabla de almacenamiento de terminologías. Los parámetros de entrada son los siguiente: el identificador de la terminología, el nombre y la versión.  searchTerminology: Dado un identificador de una terminología devuelve si lo encuentra el objeto terminología correspondiente al identificador. En el caso contrario devuelve un valor nulo.  updateTerminology: Método encargado de modificar una determinada terminología indica en la entrada estándar a la función modificándole los valores de sus atributos y poniendo en su lugar los valores 23 correspondientes pasados al método. Este método devuelve un valor buleano dependiendo de si se ha llevado a cabo la operación o no.  deleteTerminology: Método que permite eliminar una terminología del sistema. El identificador de la terminología será el único parámetro de entrada. El método devuelvo verdadero o falso en función de si se ha realizado la operación con existo o no se ha encontrado la terminología.  insertCS: Método pensado para introducir un elemento CS en la terminología indicada. Los parámetros de entrada son el identificador de la terminología y los atributos para crear el elemento CS. Antes de crear el objeto se hará una comprobación para ver si la terminología con la que se esta trabajando permite elementos de tipo CS.  searchCS: Permite buscar un elemento CS dentro de una terminología. Para ello se pasan como parámetros de entrada el identificador del elemento y el de la terminología.  updateCS: Método que sirve para modificar un elemento CS dentro de una terminología. Se pasan como parámetros de entrada el identificador del elemento y el de la terminología. Devuelve un booleano con el resultado de la operación; true operación correcta, false ha habido algún problema.  deleteCS: Método que dada un terminología elimina de su lista de elementos el CS indicado en los parámetros de entrada de la función. Esta función devuelve true o false según el resultado de la operación.  insertCD: Método pensado para introducir un elemento CD en la terminología indicada. Los parámetros de entrada son el identificador de la terminología y los atributos para crear el elemento CD. Antes de crear el objeto se hará una comprobación para ver si la terminología con la que se esta trabajando permite elementos de este tipo.  searchCD: Permite buscar un elemento CD dentro de una terminología. Para ello se pasarán los parámetros que identifique ambos conceptos por la entrada de la función. Este método devuelve el objeto CD en caso de encontrarlo o en caso de no hacerlo devuelve nulo.  updateCD: Método para modificar un elemento CD que esta contenido dentro de la terminología indicada. Los parámetros de entrada son el id de la terminología, el identificador del CD y los nuevos valores de los atributos del elemento CD.  deleteCD: Método que dada un terminología elimina de su colección de elementos el CD indicado en los parámetros de entrada de la función. Esta Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 24 función devuelve true o false según el resultado de la operación.  insertCDCV: Método para insertar un nuevo CDCV en una terminología ya existente. Se pasan como parámetros de entrada el id de la terminología y los atributos para crear el CDCV.  searchCDCV: Método que permite buscar un elemento CDCV en una terminología a través del identificador del elemento y de la terminología.  updateCDCV: Método que sirve para modificar un elemento CD dentro de una terminología. Se pasan como parámetros de entrada el identificador del elemento y el de la terminología. Devuelve un booleano con el resultado de la operación.  deleteCDCV: Función pensada par eliminar un elemento CDCV de una terminología en concreto. Por la entrada estándar del método se pasan los identificadores del CDCV y de la terminología. La función indicará si la operación se ha realizado con éxito mediante la salida estándar. 25 CAPÍTULO 4: IMPLEMENTACIÓN DEL PROYECTO. Tras el exhaustivo análisis realizado y el posterior diseño puede comenzar la etapa de implementación. La implementación del sistema de gestión y consulta de terminologías se podría dividir en tres partes. Una primera fase en la que se implementarían los objetos que representan a las terminologías y a los tipos de datos de codificación, otra fase en la que se llevaría a cabo la definición de una base de datos donde almacenar las instancias de los objetos y por último la implementación de métodos para consultar a esa base de datos, métodos que representarían cada una de la funcionalidades ofrecidas en la interfaz de usuario. A continuación se desglosan esas fases en las que se divide la etapa de implementación. 4.1 - Fase 1: implementación objetos java. JAVA es el lenguaje de programación escogido para la representación de los objetos de este proyecto. El motivo principal es que el proyecto desarrollado forma parte de un proyecto mayor LinkEHR [6][7] usa este lenguaje. Por tanto y puesto que la intención es integrar el proyecto de consulta y gestión de pequeñas terminologías clínicas, la implementación se ha hecho mediante ese lenguaje. Es necesario que fuese un lenguaje de programación orientado a objetos. Además es un lenguaje de creación de software multiplataforma lo cual proporciona la ventaja de poder funcionar en diversas plataformas. Los objetos a implementar representan los conceptos de terminología y de tipos de datos para la codificación de estas. Partiendo de la representación de estos conceptos se realiza en la fase de análisis, concretamente en el diagrama de clases de la aplicación, crearemos una clase para cada uno de ellos. Terminology: Clase pública que recoge la información necesaria acerca de una terminología. Con atributos TerminologyId que la identifica, Name, Version los tres de tipo String y una colección de objetos de codificación de tipo CD, CS o CDCV. Esta colección sólo puede contener elementos del mismo tipo. HXIT: Clase pública y abstracta por tanto no instanciable y que servirá para complementar la información de codificación de las clases que se especializan de ella. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 32 El igual que con los objetos java serán necesarios unos ficheros de mapeo de la estructura de los objetos. Se disponen dos ficheros de mapping uno para la clase Terminology y otro para la jerarquía de herencia que representa a los tipos de datos de codificación para las terminologías. Estos ficheros no difieren mucho de los creados para los objetos java. La principal diferencia es que se añade “node” junto a “name” en cada etiqueta (<class name="Customer", table="CUSTOMER", node="customer">). Aparte de los ficheros de mapeo será necesaria una clase que de forma al árbol de representación de la estructura XML. En esta clase se incluye un método que recorrerá las terminologías e irá añadiendo la información de cada una de ellas, recuperando los datos mediante consultas a la base de datos y las propiedades de los elementos, a un String. Esta función será llamada desde el método main de la clase Manager. El método descrito se llama exportToXML y se detalla a continuación: public String exportToXML() { String result = "<TERMINOLOGIES>\n"; Terminology t = new Terminology(); session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; for(int i = 0; i < terminologies.size(); i++){ t = (Terminology) terminologies.get(i); result += "<TERMINILOGY>\n<TerminologyId>"+t.getTerminologyId()+"</TerminologyId>/n" + "<Name>"+t.getName()+"</Name>\n<Version>"+t.getVersion()+"</Version>\n"+ "<Elemenents>\n"; try { tx = session.beginTransaction(); Iterator it = t.getElements().iterator(); result +="<"+t.getElementType()+">"; Element element = null; while (it.hasNext()) { element = (Element)it.next(); result += element.asXML(); } tx.commit(); } catch (RuntimeException e) { if (tx != null) tx.rollback(); System.err.println("No se ha podido exportar la base de datos a un xml"); return ""; } result += "\n</Elements>\n</TERMINOLOGY>"; } result += "</TERMINOLOGIES>"; session.close(); return result; } Figura 6. Método para el volcado de la base de datos. 33 4.3 - Fase 3: Métodos para la interfaz de usuario. En el segundo capítulo de la presente memoria se describen los diferentes métodos y consultas que formarán la interfaz de usuario de este sistema gestor de terminologías. En este apartado se va a describir la implementación de los métodos agrupados en los siguientes grupo: métodos de inserción, de búsqueda, de modificado y de borrado. La interfaz se compone de los siguientes métodos: getAllTerminoligies, getAllElementsByTerminology, searchElementIntoTerminilogy, createTerminology, searchTermonology, updateTerminology, deleteTerminology, insertCS, searchCS, updateCS, deleteCS, insertCD, searchCD, updateCD, deleteCD, insertCDCV, searchCDCV, updateCDCV y deleteCDCV. Métodos de inserción: Mediante los parámetros de entrada se identifica la terminología en la cual se va a insertar y se crea el elemento a insertar. Una vez recuperado el objeto terminología se comprueba que el tipo de datos que se intenta añadir a ella es el tipo de datos permitido por la terminología. Se creará el objeto y se incluirá en la lista de tipos de codificación. En la Figura 7 se muestra un ejemplo de método para la inserción. Métodos de búsqueda: Estos métodos comprueban si un elemento se encuentra dentro de una terminología y en caso de encontrarse en ella lo devuelven. Este método se apoya en otro método implementado, searchElementIntoTerminilogy como se muestra en la Figura 8. Métodos de modificado: Este tipo de métodos se emplea para modificar un elemento contenido en una terminología, ambos son parámetros de entrada del método. Se busca el elemento y si se encuentra se modifica. Un ejemplo de ello es el método updateCS que se muestra en la Figura 9. Métodos de borrado: Su utilidad es eliminar un elemento dentro de la lista de tipos de datos para la codificación en una determinada terminología, un ejemplo se muestra en la Figura 10. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 34 public boolean insertCS(String terminologyId, String code, String nullFlavor, String updateMode, String flavorId, String validTimeLow, String validTimeHigh, String controlInformationRoot, String controlActExtension) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; /*Se busca y se comprueba que existe la terminologia*/ Terminology t = searchTerminology(terminologyId); if(t == null){ System.err.println("Terminologia no encontrada: Error al recuperar la terminologia: "+terminologyId); return false; } /*Comprobación del tipo de datos permitido por la termiologia*/ if(t.getElementType().equals("") || t.getElementType().equals("CS")){ t.setElementType("CS"); try { tx = session.beginTransaction(); CS elementCS = new CS(); /*Creación del elemento CS*/ elementCS.setCode(code); elementCS.setControlActExtension(controlActExtension); elementCS.setControlInformationRoot(controlInformationRoot); elementCS.setFlavorId(flavorId); elementCS.setNullFlavor(nullFlavor); elementCS.setUpdateMode(updateMode); elementCS.setValidTimeHigh(validTimeHigh); elementCS.setValidTimeLow(validTimeLow); session.save(elementCS); /*guarda en la base de datos*/ tx.commit(); return true; } catch (RuntimeException e) { if (tx != null) tx.rollback(); System.err.println("Error al insertar el CS en la terminologia: "+terminologyId); return false; } finally {session.close();} } else { System.err.println("Error al insertar el CS en la terminologia: "+terminologyId+". Esta terminologia no admite CSs."); return false; } } Figura 7. Ejemplo de implementación de un método de inserción. public CS searchCS(Long id, String terminologyId) { if(searchTerminology(terminologyId).getElementType().equals("CS")){ return (CS)searchElementIntoTerminology(terminologyId, id); } else { System.err.println("No se encuentra el CS solicitado."); return null; } } Figura 8. Ejemplo de implementación de un método de búsqueda. 35 public boolean updateCS(Long id, String terminologyId, String code) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; Terminology t = searchTerminology(terminologyId); if(t == null) return false; try { tx = session.beginTransaction(); CS elementCS = searchCS(id, terminologyId); if(elementCS == null) return false; elementCS.setCode(code); session.saveOrUpdate(elementCS); tx.commit(); return true; } catch (RuntimeException e) { if (tx != null) tx.rollback(); System.err.println("Error al modificar el CS "+id+" en la terminologia: "+terminologyId); return false; } finally {session.close();} } Figura 9. Ejemplo de implementación de un método de modificado. public boolean deleteCS(Long id, String terminologyId) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; Terminology t = searchTerminology(terminologyId); if(t == null) return false; try { tx = session.beginTransaction(); CS elementCS = searchCS(id, terminologyId); session.delete(elementCS); tx.commit(); return true; } catch (RuntimeException e) { if (tx != null) tx.rollback(); System.err.println("Error al eliminar el CS "+id+" en la terminologia: "+terminologyId); return false; } finally { session.close(); } } Figura 10. Ejemplo de implementación de un método de borrado. Métodos de listado: Este tipo devuelven una lista de objetos en función de la consulta realizada a la base de datos. Podemos hacer cualquier consulta mediante la función createQuery de la clase Session de Hibernate como se muestra en la Figura 11. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 36 public HashSet<Terminology> getAllTecnologies() { return (HashSet<Terminology>)session.createQuery("from Terminology"); } Figura 11. Ejemplo de implementación de un método de listado. 37 CAPÍTULO 5: PRUEBAS DE FUNCIONAMIENTO. Llegados a este punto la implementación del módulo de gestión y consulta de pequeñas terminologías se da por concluida pero no se puede decir que el software este terminado. Es necesario realizar una serie de pruebas para comprobar el correcto funcionamiento de la aplicación y el cumplimiento de todos los requisitos especificados en la fase de análisis. Partiendo de los requerimientos especificados para esta aplicación se deben diseñar una serie de casos de estudio y una planificación de pruebas para cada uno. Tras determinar los casos a probar y llevar a cabo las pruebas el resultado puede desencadenar en la necesidad de depurar el código o en la confirmación de que es correcto. Cada caso de prueba consiste en un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular a estudiar. 5.1 - Pruebas funcionales. Determinar el correcto funcionamiento de la aplicación dependerá de confirmar que los siguientes cuatro puntos son correctos: la implementación de los objetos java que representan los conceptos de terminologías y los arquetipos, verificar el correcto mapeo de los objetos java para formar la base de datos, comprobar los cinco tipos de consultas de la interfaz de usuario y cerciorarse de que se puede exportar el contenido de la base de datos a un fichero XML. El primer caso de estudio consiste en la comprobación de los objetos java creados en representación de los conceptos de terminología y arquetipos. Verificar la correcta implementación de dichos objetos se limita a comprobar que las clases representan exactamente los conceptos según la especificación y con sus debidas restricciones, y comprobar la sintaxis de la implementación para que se corresponda con la del lenguaje java. El resto de comprobaciones se realizaran a partir de la ejecución de diferentes métodos en el main de la clase Manager verificando que se cumplan los requisitos de la aplicación y que no den lugar a excepciones o errores no controlados. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 38 La comprobación del mapeo de objetos mediante Hibernate y la correcta implementación de las consultas van ligadas. Las pruebas consistirán en la creación de diferentes objetos, usando los métodos creados, y la manipulación de estos. Para ello se ejecutarán una serie de órdenes desde la raíz de la aplicación y mediante un gestor de base de datos se observarán los resultados de la ejecución. Esto permite comprobar la estructura de tablas con sus relaciones derivada de los objetos java junto con los archivos de mapeo y la correcta implementación de los métodos para la gestión y consulta a la base de datos. 1 Ejecución de las siguientes órdenes: /*Creación de dos terminologías*/ mgr.createTerminology("100", "terminologia1", "1.1"); mgr.createTerminology("200", "terminologia2", "1.1"); /*Comprobación de método que devuelve las terminologías*/ HashSet<Terminology> list = mgr.getAllTecnologies(); for (int i = 0; i<list.size(); i++) { System.out.println("TEMINOLOGIA" + i+"\n"); } CD source = new CD("230","codeSystem", "codeSystemName", "codeSystemVersion","valueSet", "valueSetVersion","displayName", "originalText", "", new HashSet<CD>(), null,"", "", "", "", "", "", ""); /* Inserción de diferentes arquetipos en las terminologías */ mgr.insertCS("100", "234.3", "", "", "", "", "", "", ""); mgr.insertCS("100", "456.1", "", "", "", "", "", "", ""); mgr.insertCS("300", "234.3", "", "", "", "", "", "", ""); mgr.insertCD("100", "789", "codeSystem", "codeSystemName", "codeSystemVersion", "valueSet", "valueSetVersion", displayName", "originalText", source, "O"); mgr.insertCD("200","789", "codeSystem", "codeSystemName", "codeSystemVersion", "valueSet", "valueSetVersion", "displayName", "originalText", source, "O"); 2 Comprobación mediante el gestor de base de datos(RazorSql en este caso): La inserción de las terminologías es correcta y aparecen en su correspondiente tabla. Las inserciones de los dos primeros arquetipos y el cuarto son correctas pero el tercero y el cuarto producen errores que son capturados por el método. En el primer caso la terminología indicada no se encuentra en la base de datos y en el segundo se intenta insertar un elemento CD en una terminología que solo admite CSs. Figura 12. Pruebas de funcionamiento de los métodos. La figura 12 muestra el proceso de prueba de algunas de las consultas implementadas. La prueba comienza con la creación de varias terminologías mediante 39 el método “createTerminology”. La inserción de estas terminologías al servidor se comprueba mediante las cuatro líneas de código posteriores a la creación, además al mismo tiempo se comprueba el funcionamiento de la función de listado “getAllTerminologies”. A continuación se insertan arquetipos a las terminologías probando diferentes casos de estudio: qué ocurre si se intenta insertar un arquetipo en una terminología que no está creada, qué sucede si se intenta insertar un tipo de datos no permitido por la terminología, etc. La figura 12 sólo muestra las pruebas de inserción y listado pero del mismo modo se ha realizado las de búsqueda, modificación y borrado. Por último se debe probar el volcado de datos de la base de datos de terminologías a un fichero XML. Esta tarea es esencial puesto que proporciona un copia de seguridad de los datos almacenados. Para su comprobación y verificado del correcto funcionamiento se debe ejecutar el método exportToXML, desde la clase Manager, y comparar la estructura de datos resultante con el contenido de la base de dados. Es importante comprobar que se imprimen la etiquetas adecuadas, en el orden correcto, con sus correspondientes cierres y cumpliendo las reglas de un fichero XML. La estructura general del documento XML resultante del volcado se muestra en la Figura 13. <TERMINOLOGIES> <TERMINOLOGY> <TerminologyID>...<TerminologyID> <Name>...<Name> <Version>...<Version> <Archetypes> <CS> … información del elemento CS... </CS> … los demás arquetipos ... </Archetypes> </TERMINOLOGY> … resto de terminologías de la base de datos ... </TERMINOLOGIES> Figura 13. Estructura del fichero de volcado del servidor de terminologías. Desarrollo de un módulo de gestión y consulta de pequeñas terminologías clínicas conforme con ISO 21090. 40 CAPÍTULO 6: CONCLUSIONES. 6.1 - Conclusiones sobre el trabajo realizado. El desarrollado de la aplicación para la gestión y consulta de pequeñas terminologías clínicas se ha llevado a cabo cumpliendo con los requisitos especificados de la manera más eficiente gracias a la combinación de tecnologías y lenguajes empleada. Se ha querido seguir un modelo de desarrollo divido en cuatro partes planificación, diseño, implementación y pruebas lo cual da lugar a un trabajo eficiente, bien calculado y meticulosamente probado. La base de un buen desarrollo de un proyecto está en la planificación y en el posterior diseño, puesto que se ha dedicado la mitad del tiempo a planificación y dado el resultado se puede concluir que ha sido todo un acierto. Hibernate ha supuesto también un gran punto a favor de este proyecto. La combinación Java, Hibernate y Hypersql ha sido clave en la implementación y desarrollado de este módulo. Se ha tenido que estudiar la librería Hibernate desde cero y estudiar el sistema gestor de base de datos Hypersql ya que no nos queríamos limitar a los conocimientos ya adquiridos si no que la idea era explorar y aprender algo nuevo a la vez que se realizaba este proyecto final de carrera. 6.2 - Conclusiones personales. La experiencia de haber desarrollado este proyecto con los miembros del departamento IBIME del instituto ITACA ha sido grata y es de agradecer el haberme otorgado esta oportunidad de ampliar mi formación con ellos y el poder colaborar en su proyecto LinkEHR realizando este proyecto final de carrera el cual se integrará y formará parte de él. Como ya se ha mencionado anteriormente el desarrollo de este módulo ha supuesto un trabajo por mi parte para aprender a usar Hibernate lo cual supone para mi una ventaja de cara a futuros proyectos. Este trabajo ha supuesto también el conocer y experimentar el hecho de estar en un departamento con un grupo de trabajo y un director que te ayuden, te guíen y te controlen el trabajo que vas realizando. 41 Por tanto y para concluir que muy satisfecho con el trabajo realizado, con los conocimientos aprendidos durante su desarrollado y con la dirección de este proyecto final de carrera. 6.3 - Posibles ampliaciones y mejoras. El trabajo desarrollado en el presente proyecto puede ser continuado en distintas direcciones con el fin de ofrecer nuevas funcionalidades a las aplicaciones clientes como el editor de arquetipos LinkEHR del grupo de Informática Biomédica del Instituto ITACA. Estas nuevas funcionalidades son: · Diseñar e implementar una interfaz gráfica para la gestión de las terminologías integrada con el editor de arquetipos LinkEHR. · Aumentar la metainformación sobre las terminologías gestionadas para soportar la existencia de múltiples versiones de una misma terminología. Actualmente, es posible tener distintas versiones de una misma terminología pero son tratadas con terminologías independientes y por tanto sin relación entre ellas. · Desarrollar un módulo que facilite la importación de terminologías expresadas en un XML propietario, es decir, no conforme con ISO 21090.