Resolviendo el diseño de modelos de dominio HL7 mediante soluciones guiadas por modelos

Resolviendo el diseño de modelos de dominio HL7 mediante soluciones guiadas por modelos TESIS DOCTORAL Autor: Dña. Alicia Martínez García Directores: Dra. Dña. María José Escalona Cuaresma Dr. D. Francisco José Domínguez Mayo Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla Sevilla, diciembre de 2016 A aquellos que me enseñaron que el éxito es un camino y no un destino. “Braver than you believe, stronger than you seem, smarter than you think” ─ A.A. Milne. Escritor (1882 – 1956) i Agradecimientos on muchas las personas que me gustaría mencionar en este apartado de agradecimientos, ahora que mi Tesis Doctoral ha pasado de ser un reto a ser una realidad. Por una parte, a todas aquellas personas que han influido en mi inmersión en el mundo de la investigación en general, y más específicamente en el mundo de la ingeniería dirigida por modelos aplicada al ámbito sanitario. Y por otra parte, a mis familiares y amigos que han estado junto a mí durante estos años y de una u otra manera han hecho más llevadero este camino. A mis compañeros del Grupo de Innovación Tecnológica (GIT) del Hospital Universitario Virgen del Rocío, por abrirme las puertas a la investigación y ayudarme a dar el salto desde el mundo de la consultoría informática, por trabajar codo a codo siempre con compañerismo y sin rivalidad. A Cristina, María, Alberto, Paco, David, Germán, Kiko, Jesús, Noa… todos grandes investigadores sin lugar a duda. En especial a Cristina por escucharme durante horas y horas, algunas historias relacionadas con esta Tesis Doctoral, otras no. A algunos compañeros que estuvieron en mis comienzos aunque a día de hoy no sigan colaborando con nosotros: Ana, Chari, Alba,… Al responsable del GIT, Carlos Parra, por empujarme a iniciar este camino que nunca hubiera recorrido sin su motivación, y sin su visión de mi carrera profesional como investigadora. A mi directora de tesis, María José, por compartir conmigo sus conocimientos, por sus consejos y por su apoyo incondicional. Por acompañarme durante el largo recorrido que ha supuesto esta aventura. A mi director de tesis, Franci, por aportar una visión aplicada de esta Tesis Doctoral, por revisar infinitas veces esta memoria. A ambos, por tantas tutorías, por ser tan positivos y transmitirme tanta ilusión. A todos los investigadores del grupo de investigación Ingeniería Web y Testing Temprano, por ayudarme cuando tenía problemas técnicos, por las charlas en la Universidad. Especialmente a Julián, Pepe, Juanmi, Paco,... Y por último, y no menos importante, a mi familia y a mis amigos. A mi padre Juan, por haberme contagiado el interés por las ciencias, por enseñarme que el éxito es un camino y no un destino. A mi madre Elena, por hacerme creer que yo puedo con todo, por perdonarme haber tenido tan poco tiempo para ella los últimos meses. A ambos, por venir a verme siempre que tienen oportunidad, por hacerme todos los favores que les pido. A mi hermano Andrés por ser mi amigo y confidente, por empujarme a seguir cuando me quedaba sin fuerzas. Sin ellos nada hubiera sido posible. S ii A mi pareja, Germán, por acompañarme de la mano en esta aventura que es la vida, por aguantar las infinitas tardes estudiando y los viajes de trabajo, por construir juntos nuestra casa -el principio de una larga vida juntos-, por crear en mí ilusiones de futuro, por hacerme reír, por llenar mi vida, por regalarme una magnifica familia política. En especial a mis suegros Rosarito y Juani, a mi cuñado Jairo y a mi cuñada Ana, por arroparme como si fuera una más de la familia. A mis amigas: Margarita, Afri, Mamen, Vane, Moni, Rocío, Mari, Amparito, Ana, María, Marta, Fati, y un largo etcétera. En especial: A mi prima Margarita por ser como mi hermana y por compartir conmigo el interés por la informática. A mi cuñada Afri por ser tan detallista conmigo, por cuidar de mi hermano, y por regalarme una de las cosas más bonitas que tengo en mi vida. A mi comadre Mamen por permitirme formar parte de su familia. A Vane, Moni, Rocío, por llenar de diversión los pocos ratos libres que he tenido los últimos meses (años), por las interminables conversaciones. A mis niños (en orden de nacimiento porque es difícil poner un orden): Valeria, Daniella, Gonzalo, Darío, por conseguir que me olvide del estrés, por enseñarme lo bonita que es la vida, por crear en mí nuevas ilusiones. A todas aquellas personas que, sin ningún conocimiento sobre investigación y/o informática, me han pedido que les explicara sobre qué trata mi Tesis Doctoral, gracias a ellos comprendí mucho mejor la practicidad de mi trabajo. Posiblemente he olvidado mencionar a muchos que, de alguna manera, han formado parte de este camino. Para ellos también, mi agradecimiento porque este trabajo no sería el mismo sin todos y cada uno de vosotros. ¡Gracias a todos! Ali iii Resumen oy en día, los sistemas de información sanitarios son cada vez más complejos, y su desarrollo se presenta como un desafío para las empresas de desarrollo de software que deseen encontrar mercado en los sistemas sanitarios, ofreciendo productos de calidad, mantenibles e interoperables. La necesidad de una historia clínica compartida a nivel mundial es una realidad, surgiendo la necesidad de utilizar estándares de informática sanitaria que permitan establecer las normas de intercambio de información clínica. UML (Unified Modeling Language) es un lenguaje estándar de modelado ampliamente conocido por los ingenieros del software, que permite definir las entidades y relaciones que presenta un sistema de información, permitiendo diseñar un sistema software en todas las fases del ciclo de vida por las que puede pasar. Existen múltiples herramientas que soportan el lenguaje estándar de modelado UML. Son muchos los estándares que podemos encontrar en el ámbito de la interoperabilidad de información clínica. HL7 (Health Level 7) International es una organización internacional sin ánimo de lucro que define y mantiene estándares relacionados con los sistemas de información sanitarios. La mayoría de los modelos de dominio con los que trabaja HL7 están diseñados en base a un lenguaje gráfico propio. Muy pocas herramientas soportan los lenguajes de HL7. En la presente Tesis Doctoral se pretenden acercar estos 2 mundos, UML y HL7, para ofrecer a los ingenieros del software una metodología capaz de modelar sistemas de información sanitarios conformes a HL7, utilizando modelos de dominio UML ampliamente conocidos. Para tal fin, se decidió utilizar técnicas basadas en el paradigma MDE (Model Driven Engineering), consiguiendo un marco de referencia usable, reduciendo la curva de aprendizaje de los usuarios finales, y permitiendo modelar sistemas de información sanitarios mantenibles y adaptables. Este marco de referencia, desarrollado en el contexto de la presente Tesis Doctoral, bautizado como MoDHE (Model Driven Health Engineering), se sustenta sobre en 3 pilares principales. El primer pilar, la metodología, ofrece un procedimiento que permite diseñar modelos de dominio HL7 como parte del desarrollo de un sistema de información sanitario. El segundo pilar, el lenguaje de modelado basado en HL7, extiende a UML para modelar sistemas de información sanitarios conforme a todo el espectro de estándares de HL7. El tercer pilar, los mecanismos de derivación, hacen posible la interoperabilidad entre estándares, facilitando la mantenibilidad y extensión de los sistemas. H x xi Índice de Tablas Tabla 1. Visión de HL7. ....................................................................................................................................... 9 Tabla 2. Términos de búsqueda de la SLR. ............................................................................................... 14 Tabla 3. Motores de búsqueda tenidos en cuenta en la SLR. ............................................................ 15 Tabla 4. Criterios de inclusión / exclusión. .............................................................................................. 16 Tabla 5. Resultados de la SLR. ....................................................................................................................... 19 Tabla 6. Experiencias identificadas en el uso de HL7 en el contexto de MDE. .......................... 22 Tabla 7. Introducción al diseño de un metamodelo de HL7 [Ortiz et al. 2011b] ...................... 25 Tabla 8. Formatos disponibles de los modelos HL7 [Ortiz et al. 2011b] ..................................... 25 Tabla 9. Resultados evaluación características ...................................................................................... 27 Tabla 10. Porcentaje de entidades que cubre MoDHE ........................................................................ 60 Tabla 11. Elementos de HL7 CDA y HL7 v2.x que quedan fuera del alcance ............................. 61 Tabla 12. Correspondencia entre elementos de los metamodelos en estudio .......................... 79 Tabla 13. Ventajas e inconvenientes de las alternativas para definir sintaxis concretas. .... 96 Tabla 14. Diferencias entre CDA de Prevensalud vs CDA modelado con MoDHE Suite. .... 119 Tabla 15. Tipificación de errores identificados. .................................................................................. 120 Tabla 16. Errores identificados en el modelo de Prevensalud por no cumplir el estándar. ................................................................................................................................................................................. 120 xii xiii Índice de Figuras Figura 1. Etapas fundamentales del SLR ................................................................................................... 12 Figura 2. SLR. Etapa de planificación de la revisión ............................................................................. 13 Figura 3. SLR. Etapa de desarrollo de la revisión .................................................................................. 17 Figura 4. Estudios encontrados en la SLR ................................................................................................. 20 Figura 5. SLR. Etapa de presentación de los resultados ..................................................................... 20 Figura 6. Marco de referencia ........................................................................................................................ 30 Figura 7. Solución desarrollada en la presente Tesis Doctoral ........................................................ 33 Figura 8. Diagramas ofrecidos por UML .................................................................................................... 35 Figura 9. Contexto ............................................................................................................................................... 43 Figura 10. Definición formal de la propuesta .......................................................................................... 45 Figura 11. Marco de referencia. Pilar ‘Metodología’ ............................................................................. 47 Figura 12. Proceso .............................................................................................................................................. 48 Figura 13. Definición formal de la propuesta. Parte NDT .................................................................. 49 Figura 14. Fases cubiertas por la metodología NDT. Actividades dentro de DRS .................... 50 Figura 15. Modelado del ciclo de vida del software utilizando NDT ............................................. 51 Figura 16. Definición formal de la propuesta. Parte HL7 ................................................................... 52 Figura 17. Definición formal de la propuesta. Parte MoDHE ............................................................ 54 Figura 18. Fases cubiertas por la metodología de MoDHE. Actividades dentro de DRS ....... 55 Figura 19. Modelado del ciclo de vida del software sanitario utilizando MoDHE ................... 56 Figura 20. Marco de referencia. Pilar ‘Lenguaje de modelado basado en HL7’ ........................ 59 Figura 21. Metamodelo de MoDHE v3, que corresponde al estándar HL7 v3. Entidades. Parte 1 ..................................................................................................................................................................... 63 xiv Figura 22. Metamodelo de MoDHE v3, que corresponde al estándar HL7 v3. Entidades. Parte 2 ..................................................................................................................................................................... 64 Figura 23. Metamodelo de MoDHE v3, que corresponde al estándar HL7 v3. Entidades. Parte 3 ..................................................................................................................................................................... 65 Figura 24. Metamodelo de MoDHE v3, que corresponde al estándar HL7 v3. Tipos de datos .................................................................................................................................................................................... 66 Figura 25. Metamodelo de MoDHE v3, que corresponde al estándar HL7 v3. Enumerados .................................................................................................................................................................................... 66 Figura 26. Metamodelo de MoDHE CDA, que corresponde al estándar HL7 CDA. Entidades .................................................................................................................................................................................... 67 Figura 27. Definición formal de la propuesta. CDA como refinamiento de v3 .......................... 68 Figura 28. Metamodelo de MoDHE CDA (que corresponde al estándar HL7 CDA) y MoDHE v3 (que corresponde al estándar HL7 v3). Relaciones entre entidades ...................................... 69 Figura 29. Metamodelo de MoDHE v2.x, que corresponde al estándar HL7 v2.x. Entidades .................................................................................................................................................................................... 70 Figura 30. Metamodelo de MoDHE v2.x, que corresponde al estándar HL7 v2.x. Tipos de datos ......................................................................................................................................................................... 71 Figura 31. Metamodelo de MoDHE v2.x, que corresponde al estándar HL7 v2.x. Enumerados .......................................................................................................................................................... 72 Figura 32. Marco de referencia. Pilar ‘Mecanismos’ ............................................................................. 75 Figura 33. Definición formal de la propuesta. Parte mecanismos de derivación ..................... 76 Figura 34. Perfil UML de MoDHE en EA. Parte v3. Entidades relacionadas con Entity. ........ 97 Figura 35. Perfil UML de MoDHE en EA. Parte v3. Entidades relacionadas con Role y Participation. ........................................................................................................................................................ 98 Figura 36. Perfil UML de MoDHE en EA. Parte v3. Entidades relacionadas con Act. .............. 99 Figura 37. Perfil UML de MoDHE en EA. Parte CDA. Entidades. ................................................... 100 Figura 38. Perfil UML de MoDHE en EA. Parte CDA-v3. Relación entre CDA y v3. ............... 101 Figura 39. Perfil UML de MoDHE en EA. Parte CDA. Valores enumerados. ............................. 102 Figura 40. Perfil UML de MoDHE en EA. Parte CDA-v3. Tipos de datos. ................................... 103 Figura 41. Perfil UML de MoDHE en EA. Parte v2.x. Entidades. ................................................... 104 xv Figura 42. Perfil UML de MoDHE en EA. Parte v2.x. Valores enumerados. .............................. 105 Figura 43. Perfil UML de MoDHE en EA. Parte v2.x. Tipos de datos. .......................................... 106 Figura 44. Arquitectura de MoDHE Suite. .............................................................................................. 108 Figura 45. Estructura de carpetas del proyecto “MDG Technology” de MoDHE Suite. ....... 109 Figura 46. Toolbox de MoDHE Suite. ....................................................................................................... 111 Figura 47. Porción de la guia de implementación HL7 modelada en el proyecto Prevensalud. ....................................................................................................................................................... 116 Figura 48. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (i). ........... 117 Figura 49. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (ii). .......... 117 Figura 50. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (iii).......... 118 Figura 51. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (iv). ......... 118 Figura 52. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (v). .......... 119 Figura 53. Manual de usuario MoDHE Suite. Pantalla inicial ......................................................... 243 Figura 54. Manual de usuario MoDHE Suite. Navegador de proyecto ....................................... 244 Figura 55. Manual de usuario MoDHE Suite. Diagrama de requisitos de información ....... 244 Figura 56. Manual de usuario MoDHE Suite. Paleta .......................................................................... 245 Figura 57. Manual de usuario MoDHE Suite. Editor de documentos clínicos. Datos ........... 246 Figura 58. Manual de usuario MoDHE Suite. Editor de documentos clínicos. Asociaciones ................................................................................................................................................................................. 247 Figura 59. Manual de usuario MoDHE Suite. Botón guardar ......................................................... 247 Figura 60. Manual de usuario MoDHE Suite. Editor de identificador ........................................ 248 Figura 61. Manual de usuario MoDHE Suite. Editor de paciente ................................................. 248 Figura 62. Manual de usuario MoDHE Suite. Diagrama de requisitos de información (i) . 249 Figura 63. Manual de usuario MoDHE Suite. Diagrama de requisitos de información (ii) 250 Figura 64. Manual de usuario MoDHE Suite. Menú de transformaciones ................................ 250 xvi Figura 65. Manual de usuario MoDHE Suite. Configuración de transformaciones ............... 251 Figura 66. Manual de usuario MoDHE Suite. Botón para iniciar la transformación ............ 252 Figura 67. Manual de usuario MoDHE Suite. Progreso de la transformación......................... 252 Figura 68. Manual de usuario MoDHE Suite. Elementos autogenerados ................................. 252 Figura 69. Manual de usuario MoDHE Suite. Editor Segmento información del paciente 253 Figura 70. Escenario proyecto Prevensalud. Estructura general de la red de interoperabilidad ............................................................................................................................................. 255 Figura 71. Escenario proyecto Prevensalud. Diagrama de casos de uso .................................. 257 Figura 72. Escenario proyecto Prevensalud. Diagrama de clases................................................ 258 Figura 73. Escenario proyecto Prevensalud. Diagrama de actividades .................................... 259 Figura 74. Plataforma donde el profesional cumplimenta los informes de derivación ...... 260 Figura 75. Informe de derivación. Datos generales ........................................................................... 261 Figura 76. Informe de derivación. Evolución del paciente en hemodiálisis ............................ 262 Figura 77. Informe de derivación. Resumen de Historia Clínica .................................................. 263 Figura 78. Informe de derivación. Inicio estudio Pretrasplante .................................................. 264 Figura 79. Modelo CDA de Prevensalud. Parte 1 ................................................................................ 265 Figura 80. Modelo CDA de Prevensalud. Parte 2 ................................................................................ 266 xvii Índice de Expresiones Expresión 1. Transformación para derivar el modelo MoDHE v2.x desde el modelo MoDHE CDA ........................................................................................................................................................................... 81 Expresión 2. Mapeo QVT de la metaclase «ClinicalDocument» a «Messagev27» ..................... 82 Expresión 3. Mapeo QVT de la metaclase «PatientRole» a «SegmentPID» ................................. 82 Expresión 4. Mapeo QVT de la metaclase «Patient» a «SegmentPID» .......................................... 82 Expresión 5. Transformación para derivar el modelo MoDHE CDA desde el modelo MoDHE v2.x ............................................................................................................................................................................ 83 Expresión 6. Mapeo QVT de la metaclase «Messagev27» a «ClinicalDocument » .................... 84 Expresión 7. Mapeo QVT de la metaclase «SegmentPID» a «Patient» .......................................... 84 Expresión 8. Mapeo QVT de la metaclase «SegmentPID» a «PatientRole» ................................. 85 Expresión 9. Transformación para derivar el modelo MoDHE v2.x desde el modelo MoDHE v3 ............................................................................................................................................................................... 86 Expresión 10. Mapeo QVT de la metaclase «Entity» a «Messagev27» .......................................... 87 Expresión 11. Mapeo QVT de la metaclase «Entity» a «SegmentPID» .......................................... 87 Expresión 12. Mapeo QVT de la metaclase «LivingSubject» a «SegmentPID» .......................... 87 Expresión 13. Mapeo QVT de la metaclase «Person» a «SegmentPID» ........................................ 88 Expresión 14. Transformación para derivar el modelo MoDHE v3 desde el modelo MoDHE v2.x ............................................................................................................................................................................ 89 Expresión 15. Mapeo QVT de la metaclase « Messagev27» a «Entity» ......................................... 90 Expresión 16. Mapeo QVT de la metaclase «SegmentPID» a «Entity» .......................................... 90 Expresión 17. Mapeo QVT de la metaclase «SegmentPID» a «LivingSubject» .......................... 90 Expresión 18. Mapeo QVT de la metaclase «SegmentPID» a «Person» ........................................ 91 Expresión 19. Correspondencia entre códigos QVT vs C# .............................................................. 112 xviii Expresión 20. Restricciones OCL de HL7 v3. Restricción sobre Access .................................... 140 Expresión 21. Restricciones OCL de HL7 v3. Restricción sobre Account ................................. 140 Expresión 22. Restricciones OCL de HL7 v3. Restricción sobre Act ........................................... 143 Expresión 23. Restricciones OCL de HL7 v3. Restricción sobre ActRelationship ................. 145 Expresión 24. Restricciones OCL de HL7 v3. Restricción sobre Container ............................. 146 Expresión 25. Restricciones OCL de HL7 v3. Restricción sobre ContextStructure .............. 147 Expresión 26. Restricciones OCL de HL7 v3. Restricción sobre ControlAct ............................ 147 Expresión 27. Restricciones OCL de HL7 v3. Restricción sobre Device .................................... 148 Expresión 28. Restricciones OCL de HL7 v3. Restricción sobre DeviceTask .......................... 149 Expresión 29. Restricciones OCL de HL7 v3. Restricción sobre DiagnosticImage ............... 149 Expresión 30. Restricciones OCL de HL7 v3. Restricción sobre Diet ......................................... 150 Expresión 31. Restricciones OCL de HL7 v3. Restricción sobre Document ............................. 150 Expresión 32. Restricciones OCL de HL7 v3. Restricción sobre Employee ............................. 151 Expresión 33. Restricciones OCL de HL7 v3. Restricción sobre Entity ..................................... 153 Expresión 34. Restricciones OCL de HL7 v3. Restricción sobre Exposure .............................. 154 Expresión 35. Restricciones OCL de HL7 v3. Restricción sobre FinancialContract ............. 154 Expresión 36. Restricciones OCL de HL7 v3. Restricción sobre InvoiceElement .................. 156 Expresión 37. Restricciones OCL de HL7 v3. Restricción sobre LanguageCommunication ................................................................................................................................................................................. 157 Expresión 38. Restricciones OCL de HL7 v3. Restricción sobre LicensedEntity ................... 157 Expresión 39. Restricciones OCL de HL7 v3. Restricción sobre LivingSubject ...................... 158 Expresión 40. Restricciones OCL de HL7 v3. Restricción sobre ManufacturedMaterial .... 159 Expresión 41. Restricciones OCL de HL7 v3. Restricción sobre Material................................. 160 Expresión 42. Restricciones OCL de HL7 v3. Restricción sobre NonPersonLivingSubject 160 Expresión 43. Restricciones OCL de HL7 v3. Restricción sobre Observation ......................... 161 Expresión 44. Restricciones OCL de HL7 v3. Restricción sobre Organization ....................... 162 xix Expresión 45. Restricciones OCL de HL7 v3. Restricción sobre Participation ....................... 164 Expresión 46. Restricciones OCL de HL7 v3. Restricción sobre Patient ................................... 164 Expresión 47. Restricciones OCL de HL7 v3. Restricción sobre PatientEncounter.............. 165 Expresión 48. Restricciones OCL de HL7 v3. Restricción sobre Person ................................... 166 Expresión 49. Restricciones OCL de HL7 v3. Restricción sobre Place ....................................... 167 Expresión 50. Restricciones OCL de HL7 v3. Restricción sobre Procedure ............................ 167 Expresión 51. Restricciones OCL de HL7 v3. Restricción sobre PublicHealthCase .............. 168 Expresión 52. Restricciones OCL de HL7 v3. Restricción sobre QualifiedEntity ................... 169 Expresión 53. Restricciones OCL de HL7 v3. Restricción sobre Role ......................................... 170 Expresión 54. Restricciones OCL de HL7 v3. Restricción sobre RoleLink ............................... 171 Expresión 55. Restricciones OCL de HL7 v3. Restricción sobre SubstanceAdministration ................................................................................................................................................................................. 172 Expresión 56. Restricciones OCL de HL7 v3. Restricción sobre Supply .................................... 173 Expresión 57. Restricciones OCL de HL7 CDA. Restricción sobre AssignedEntity .............. 188 Expresión 58. Restricciones OCL de HL7 CDA. Restricción sobre Authenticator ................ 189 Expresión 59. Restricciones OCL de HL7 CDA. Restricción sobre Birthplace........................ 190 Expresión 60. Restricciones OCL de HL7 CDA. Restricción sobre ClinicalDocument......... 191 Expresión 61. Restricciones OCL de HL7 CDA. Restricción sobre LegalAuthenticator ..... 192 Expresión 62. Restricciones OCL de HL7 CDA. Restricción sobre Organization .................. 193 Expresión 63. Restricciones OCL de HL7 CDA. Restricción sobre OrganizationPartOf ..... 194 Expresión 64. Restricciones OCL de HL7 CDA. Restricción sobre Patient .............................. 195 Expresión 65. Restricciones OCL de HL7 CDA. Restricción sobre PatientRole ..................... 196 Expresión 66. Restricciones OCL de HL7 CDA. Restricción sobre Person............................... 197 Expresión 67. Restricciones OCL de HL7 CDA. Restricción sobre Place .................................. 197 Expresión 68. Restricciones OCL de HL7 CDA. Restricción sobre RecordTarget ................. 198 6 3. Estructura de la Tesis Doctoral La presente investigación profundiza en el uso de UML en el campo del diseño de los modelos de dominio de HL7. Para ello, se propone la aplicación de técnicas, herramientas y metodologías propias del paradigma MDE. Estos aspectos son presentados a lo largo de los capítulos de esta memoria de Tesis Doctoral estructurada de la siguiente forma: El Capítulo I ofrece una visión introductoria de esta Tesis Doctoral, presentando la relación de conceptos básicos que motivaron que se comenzara a trabajar en esta línea de investigación, así como los antecedentes que, tanto los autores como los 2 grupos de investigación involucrados en esta investigación, presentan en la temática. A continuación, el Capítulo II presenta un estado del arte realizado en el marco de la presente Tesis Doctoral, con el objetivo de identificar posibles experiencias existentes en el uso del paradigma MDE en el contexto sanitario. En el primer apartado dentro de dicho capítulo, se define el contexto sobre el cual se han analizado las experiencias previas existentes. En el segundo capítulo, se realiza una Revisión Sistemática de la Literatura que, al concluir que en la literatura científica apenas existen experiencias relacionadas, desemboca en una búsqueda de carácter general en la Web. Finalmente, en dicho apartado, se analizan en profundidad las experiencias identificadas más relevantes, utilizando un esquema de caracterización. Por último, en este segundo capítulo se describen las lecciones aprendidas una vez revisado el estado del arte. Con la visión alcanzada después de analizar el estado del arte, el Capítulo III centra el problema, presentando un planteamiento específico y detallado de éste, y enunciando los objetivos perseguidos en la presente investigación. Además, se describen las influencias que inicialmente focalizaron esta línea de investigación. Por último, se formaliza una propuesta de solución que resuelve el reto consistente en diseñar modelos de dominio HL7 utilizando una interfaz basada en UML, mediante soluciones guiadas por modelos. A partir de este punto, una vez establecidos los objetivos derivados del problema a resolver, en los siguientes 3 capítulos, se define el marco de referencia al que hemos denominado MoDHE (MOdel Driven Health Engineering), profundizando sobre cada uno de los elementos en los que se sustenta la solución propuesta, incluyendo metodología, metamodelos, restricciones y transformaciones. El Capítulo IV presenta la metodología propuesta. El Capítulo V presenta los metamodelos utilizados y las restricciones identificadas y modeladas. El Capítulo VI presenta las transformaciones teóricas que hacen de nexo de unión para posibilitar la derivación entre modelos conformes a los metamodelos presentados. Para materializar y automatizar metodología, metamodelos, restricciones y transformaciones planteados en los capítulos Capítulo IV, Capítulo V y Capítulo VI, se ha desarrollado una herramienta de soporte, registrada como MoDHE Suite. El Capítulo VII muestra los aspectos principales de dicha herramienta. El Capítulo VIII muestra los resultados de una validación tanto técnica como funcional haciendo uso de la herramienta MoDHE Suite, y por tanto haciendo uso del marco de referencia MoDHE. La validación funcional se ha realizado escenificando un caso real 7 sobre un marco de interoperabilidad basado en HL7 para la atención de pacientes de hemodiálisis. Finalmente, el Capítulo IX cierra la memoria de Tesis Doctoral haciendo una reflexión sobre las aportaciones que esta investigación aporta a la comunidad científica, presentando el trabajo futuro que nos planteamos así como nuevas líneas de investigación complementarias. El Capítulo X presenta las referencias bibliográficas consultadas y referenciadas a lo largo de esta memoria de Tesis Doctoral. Como primer apéndice, el Anexo A muestra un glosario de términos, definiendo los términos y acrónimos más utilizados en la presente memoria de Tesis Doctoral. Para facilitar la legibilidad de la presente memoria de Tesis Doctoral, el detalle de todos los elementos presentes en el metamodelo se ha incluido en el Anexo B, incluyendo las restricciones identificadas definidas en lenguaje OCL. El Anexo C presenta un manual de la herramienta MoDHE Suite, que permitirá a cualquier ingeniero del software diseñar un modelo de dominio conforme a HL7, utilizando una interfaz basada en UML. El Anexo D incluye la descripción funcional del caso práctico utilizado para validar la herramienta, incluyendo diagramas de casos de uso, clases y actividad, y el modelo basado en el estándar HL7 CDA (Clinical Document Architecture) que aplica al caso en cuestión. Este caso práctico trata sobre el proyecto Prevensalud en el que trabajó el GIT del HUVR, dando respuesta a una necesidad de interoperabilidad entre sistemas sanitarios para cubrir el flujo de información de pacientes en diálisis. Por último, el Anexo E incluye un resumen de la actividad investigadora de la doctoranda en los últimos 5 años, haciendo especial hincapié en las publicaciones y participación en congresos y proyectos de investigación, así como en certificaciones, comités y cursos, relacionados con la presente Tesis Doctoral. 4. Conclusiones La Tesis Doctoral que se presenta en esta memoria viene motivada por el reto de facilitar a la comunidad de ingenieros de software el diseño de modelos de dominio en UML bajo el prisma de HL7, usando para ello el paradigma MDE. El escenario perseguido es acercar los modelos de dominio de sistemas de información sanitarios basados en HL7 con el diseño en UML tomando como base la riqueza que aporta UML y el amplio uso que tiene en la comunidad de ingenieros del software. 8 El presente capítulo introductorio, además de ofrecer una visión a alto nivel sobre el reto que se pretende solventar con la presente Tesis Doctoral, detalla los antecedentes que presentan los autores, así como los grupos de investigación involucrados. Además, se proporciona al lector una visión global sobre la estructura que se ha seguido en la presente memoria para detallar los resultados de la investigación realizada en el marco de esta Tesis Doctoral. 9 Capítulo II. Trabajos relacionados a presente Tesis Doctoral tiene como objetivo cubrir la necesidad de ofrecer un marco de trabajo basado en modelos UML que permita a los ingenieros del software gestionar de una manera eficaz y eficiente los modelos de dominio conformes a HL7 de los sistemas de información sanitarios que implementen. Dicho marco de trabajo tiene el objetivo de ofrecer la posibilidad de desarrollar dichos sistemas de información sanitaria, mejorar el mantenimiento de éstos, así como de posibilitar la realización de una mejora continua efectiva. Para llevar a cabo este objetivo, se propone el uso de técnicas MDE. Para realizar una propuesta original, el primer paso a llevar a cabo es identificar y analizar el conocimiento existente en cuanto al uso de HL7 en el marco de MDE. Para ello, el primer apartado de este capítulo presenta el contexto en el que se enmarca la temática. El segundo apartado, muestra los resultados del estudio del estado del arte de propuestas relacionadas llevado a cabo, identificando los trabajos relacionados más recientes de la literatura actual. El apartado 3 muestra las lecciones aprendidas tras haber analizado este estado del arte. Por último, el apartado 4 presenta unas breves conclusiones sintetizando los aspectos más relevantes del estado del estudio del arte realizado. 1. Contexto A continuación, se presenta el contexto en el que nos enmarcamos cuando nos planteamos hacer un estudio del estado del arte sobre el uso de HL7 en el marco de MDE. Este contexto constituye los antecedentes del estudio del estado del arte expuesto en el presente capítulo, contexto que provocó la necesidad de acometer una revisión sistemática de la literatura siguiendo un método formal. HL7 es una organización cuya base fundamental apuesta por los estándares en el ámbito sanitario, para conseguir un mundo en el cual podamos acceder y utilizar los datos sanitarios de forma segura donde y cuando lo necesitemos. Así lo describe la visión de la organización mostrada en la Tabla 1. Tabla 1. Visión de HL7. “HL7 Vision: A world in which everyone can securely access and use the right health data when and where they need it.” L 10 Esta organización utiliza modelos de información para definir sus estándares. Todos estos modelos de información extienden el MIF, metamodelo de HL7. Encontramos 4 tipos de modelos en HL7 10 . A continuación, se muestra una breve descripción de cada uno de estos tipos de modelos:  RIM (Reference Information Model) 11 . Modelo de información de referencia de HL7. Se trata de un modelo estático que representa los elementos que se pueden encontrar en un escenario sanitario. Surgió como resultado del trabajo desempeñado por los grupos de trabajo de HL7, y de sus afiliados internacionales. Gracias al modelado utilizando el RIM, se pueden modelar: actos, entidades, roles, participaciones, etc. Actualmente, el RIM es un estándar aprobado por ANSI (American National Standards Institute) 12 .  D-MIM (Domain Message Information Model). Refinamiento del RIM que incluye aquellos elementos necesarios para modelar información en un dominio concreto. HL7 cuenta con más de 15 dominios definidos.  R-MIM (Refined Message Information Model). Subconjunto de un D-MIM concreto, generado mediante restricciones. Dado un escenario determinado, el R-MIM incluye toda la información necesaria para formar un mensaje o un conjunto de mensajes.  HDM (Hierarchical Message Descriptions). Es una derivación de un R-MIM. Dado un mensaje concreto, el HDM contiene los campos exactos que debe contener, incluyendo la obligatoriedad, la cardinalidad, etc. A partir de los HDM se obtiene el conjunto de reglas necesarias para construir un mensaje determinado. Aunque HL7 es una organización que claramente apuesta por la estandarización en el campo de la interoperabilidad, la mayoría de los metamodelos de los estándares de HL7 están diseñados en base a un lenguaje gráfico propio. Algunos miembros de la comunidad HL7 se han planteado la necesidad de utilizar un estándar de modelado en vez del lenguaje de modelado propio en el cual están definidos la mayoría de los metamodelos de HL7. Como ejemplo, en la Wiki de HL7 internacional hay un apartado llamado PIIM 13 (Platform Independent Implementation Model) donde, entre otras discusiones, distintos miembros de HL7 identifican ventajas e inconvenientes que encuentran a la publicación de una especificación UML para los metamodelos de HL7. 10 https://www.hl7.org/documentcenter/public/wg/mnm/hdf/v3guide.doc 11 http://www.hl7.org/implement/standards/rim.cfm 12 http://www.ansi.org/ 13 http://wiki.hl7.org/index.php?title=PIIM 11 Entre las ventajas, cabe destacar el uso de herramientas estándar, la reducción de la complejidad de las soluciones basadas en HL7, y el aumento de consistencia y trazabilidad de dichas soluciones. Como discusión, se comenta que el desarrollo de este modelo de implementación independiente de la plataforma, es costoso y por ello la comunidad HL7 debe valorar si transformar los metamodelos de HL7 al completo o solo un subconjunto. Adicionalmente, algunos miembros de la comunidad HL7 se han planteado la posibilidad de utilizar HL7 en el ámbito de MDE:  En el apartado ‘Model Driven Engineering’ de la Wiki de HL7 14 hablan de MDE y de su aplicabilidad dentro de los estándares de HL7. Es más, cuándo se comenzó a diseñar el estándar v3 de HL7, uno de los objetivos de éste era que siguiera una metodología basada en MDE, pero finalmente el estándar evolucionó y no se llegó a abarcar esta característica.  En 2012, HL7 comenzó a trabajar en el llamado “HL7 Tooling Challenge” 15 –en adelante ‘TC’-, celebrando concursos anuales para fomentar el desarrollo de herramientas HL7 basadas en MDE. El primer TC 2012/2013 pretendía producir herramientas que ayudaran a los implementadores desarrollar artefactos del estándar HL7 v3 basados en el MIF. El siguiente TC 2013/2014 pretendía definir detalladamente y evaluar una metodología para utilizar una herramienta UML que permita gestionar artefactos del estándar HL7 v3. El lector encontrará más información acerca de los TC de HL7 en el apartado 2.2.1 de este capítulo. Tal y como se evidencia en el presente capítulo, además de los propios miembros de la comunidad HL7, muchos investigadores de la comunidad científica han identificado la necesidad de poder utilizar HL7 en el contexto de MDE, para así poder contar con herramientas de apoyo de modelado, pruebas, etc. Resumiendo, a lo largo de los últimos años se evidencia que investigadores expertos en HL7 aprecian que el uso de HL7 en el contexto de MDE puede traer beneficios. Esto ha motivado la realización de un estudio del estado del arte que se detalla en el siguiente apartado. 14 http://wiki.hl7.org/index.php?title=Model_Driven_Engineering 15 http://www.hl7.org/events/toolingchallenge.cfm 12 2. Estudio del estado del arte de propuestas relacionadas A lo largo de esta sección se describen las experiencias relacionadas más relevantes encontradas después de haber llevado a cabo un estudio del estado del arte en cuanto a propuestas basadas en el uso de los estándares de HL7 en el contexto de MDE. Para comenzar este estudio del estado del arte, se inició una búsqueda de otros estudios de estado del arte sobre el uso de estándares de HL7 en el contexto de MDE. No se han identificado trabajos que expongan el estado del arte en este tema. Para llevar a cabo el estudio del estado del arte se ha optado por realizar una revisión sistemática de la literatura (en adelante ‘SLR’, por sus siglas en inglés: Systematic Literature Review), método que permite la identificación, evaluación e interpretación de la información existente relevante en un área de investigación específica. A continuación se presenta la SLR realizada para identificar propuestas relacionadas con el uso de HL7 en el marco de MDE. La revisión finalizó sin obtener resultados prometedores, llegando a la conclusión de que los portales de búsqueda consultados están orientados a trabajos teóricos, pero no a trabajos prácticos relacionados con la temática. Estos trabajos prácticos nos deben interesar debido al carácter práctico de la presente Tesis Doctoral. Por ello, para cubrir el estudio del estado del arte de propuestas relacionadas, se ha optado por realizar una búsqueda general en portales de búsqueda web de propósito general. 2.1. Revisión Sistemática de la Literatura Una SLR es una revisión de la literatura enfocada en una pregunta de investigación cuyo objetivo es identificar, evaluar, seleccionar y sintetizar toda la evidencia relevante de alta calidad relacionada con dicha pregunta de investigación, en un área específica. Gracias a esta metodología, podemos identificar las lagunas existentes relacionadas con la temática para sugerir áreas de investigación prospectivas y novedosas. Las SLR minimizan las posibilidades de desembocar en conclusiones erróneas. Para la SLR llevada a cabo en la presente Tesis Doctoral nos hemos basado en uno de los métodos más aceptados dentro de la ingeniería del software para realizar este tipo de revisiones [Kitchenham et al. 2007]. Este método propone 3 etapas fundamentales (Figura 1): Planificación Desarrollo Presentación de los resultados Figura 1. Etapas fundamentales del SLR 13  Planificación de la revisión. En esta etapa se debe describir la necesidad que se ha identificado para realizar el SLR, se deben especificar las preguntas de investigación, así como el protocolo de revisión.  Desarrollo de la revisión. En esta etapa se identifican y extraen los estudios que se van a tener en cuenta en el SLR.  Presentación de los resultados de la revisión. En esta etapa se deben presentar los resultados de la revisión, así como especificar mecanismos de diseminación. Los siguientes 3 subapartados (apartado 2.1.1, apartado 2.1.2, apartado 2.1.3) presentan detalladamente los resultados de cada etapa de la SLR. 2.1.1. Planificación de la revisión Tal y como muestra la Figura 2, este apartado presenta los resultados de haber llevado a cabo la primera etapa de la SLR, es decir, la planificación de la revisión. Planificación Desarrollo Presentación de los resultados Figura 2. SLR. Etapa de planificación de la revisión Esta etapa tiene como objetivo especificar las cuestiones de investigación que se pretenden responder con la revisión, así como fijar todos los parámetros necesarios para definir la estrategia de búsqueda a llevar a cabo (buscadores científicos a consultar, expresión a utilizar a la hora de buscar, criterios de inclusión y exclusión, etc). Cuestiones de investigación Dado que la presente Tesis Doctoral se centra en el ámbito del uso de HL7 en el contexto de MDE, el estado del arte pretende responder la siguiente cuestión general de investigación: ¿Puede ayudar MDE en el diseño de modelos de dominio basados en HL7? Dado que esta cuestión es muy abierta, para poder guiar el resto de la SLR, podemos concretarla en las siguientes cuestiones de investigación (CI) más específicas:  CI1. “¿Existen experiencias previas en el uso de HL7 en el contexto de MDE?”  CI2. “Las experiencias existentes, ¿pretenden cubrir todos los estándares de HL7?”  CI3. “¿Qué tipos de técnicas MDE utilizan las experiencias existentes?”  CI4. “¿Qué temas sin resolver se identifican en los resultados?” 14 Expresión de búsqueda A partir de estas preguntas, se han identificado una serie de términos de búsqueda que serán utilizados en la SLR. La siguiente tabla (Tabla 2) muestra estos términos de búsqueda en función de si están relacionados con MDE o con HL7. Tabla 2. Términos de búsqueda de la SLR. Términos relacionados con MDE Términos relacionados con HL7 A1. Model Driven Engineering B1. Health Level 7 A2. Model Driven Approach B2. Model Interchange Format A3. Metamodel B3. HL7 La expresión EXP_GLOBAL es la que se ha utilizado en la búsqueda, utilizando los términos descritos anteriormente: EXP_MDE = (A1 OR A2 OR A3) EXP_HL7 = (B1 OR B2 OR B3) EXP_GLOBAL = EXP_MDE AND EXP_HL7 Buscadores científicos Las bases de datos (BD) de buscadores científicos electrónicos consideradas en la SLR se muestran en la siguiente tabla (Tabla 3), incluyendo el nombre de la BD en cuestión, así como los campos específicos donde se han aplicado los términos de búsqueda. 15 Tabla 3. Motores de búsqueda tenidos en cuenta en la SLR. BD Campos de búsqueda Pubmed16 Titulo / Resumen Springer Link17 Todo el texto ScienceDirect18 Titulo / Resumen / Palabras clave IEEE Xplore19 Titulo / Resumen / Palabras clave Scopus20 Titulo / Resumen / Palabras clave ACM DL21 Titulo / Resumen / Palabras clave TDG Scholar22 Todo el texto En el caso de Springer Link, se ha realizado una búsqueda en todo el texto de los estudios porque el buscador avanzado, en referencia a búsquedas parciales, solo permite realizar búsquedas en el título, lo cual se ha considerado insuficiente para este SLR. En el caso de TDG Scholar se ha realizado una búsqueda en todo el texto de los estudios, porque en este caso este buscador científico no ofrece buscador avanzado, así que las búsquedas se hacen en todo el texto. Criterios de inclusión/exclusión El siguiente paso es establecer unos criterios objetivos para preseleccionar, de los estudios encontrados, aquellos que se deseen incluir en el análisis. En el caso de algunos criterios de inclusión/exclusión y en el caso de algunas BD científicas, el propio buscador avanzado de la BD científica provee opciones para ejecutar el criterio. En otros casos, es necesario 16 http://www.ncbi.nlm.nih.gov/pubmed 17 http://link.springer.com/ 18 http://www.sciencedirect.com/ 19 http://ieeexplore.ieee.org/Xplore/home.jsp 20 https://www.scopus.com/ 21 http://dl.acm.org/ 22 http://scholar.tdg-seville.info/ 22 Según la metodología llevada a cabo en la presente SLR, en esta fase también se deberían especificar mecanismos de diseminación. En este caso, teniendo en cuenta los resultados obtenidos, no aplica. 2.2. Búsqueda general Para realizar la búsqueda general, se ha utilizado el portal de búsqueda web de propósito general Google 24 , incluyendo los mismos términos de búsqueda definidos en la Tabla 2. La siguiente tabla (Tabla 6) recoge los resultados obtenidos tras llevar a cabo la búsqueda general en cuanto a posibles experiencias del uso de HL7 en el contexto de MDE. Tabla 6. Experiencias identificadas en el uso de HL7 en el contexto de MDE. Experiencias identificadas HL7 Tooling Challenge Ortiz et al.: Transformación de modelos de HL7 a UML Model Driven Health Tool (MDHT) En primer lugar, se presentan las características más importantes de cada una de las experiencias identificadas en el uso de HL7 en el contexto de MDE. En segundo lugar, se evalúa el esquema de caracterización anteriormente definido, para comparar los diferentes resultados. 2.2.1. Experiencias identificadas HL7 Tooling Challenge HL7 da especial importancia a la creación de herramientas HL7 que ayuden a los implementadores HL7 a gestionar artefactos basados en los estándares HL7. Como muestra de ello, en 2012 se publica el primer HL7 Tooling Challenge, concurso para fomentar el desarrollo de herramientas HL7. El concurso está patrocinado por Sparx Systems 25 , proveedor líder de herramientas de modelado basadas en estándares, y empresa creadora de Enterprise Architect (EA). 24 https://www.google.es/ 25 https://www.sparxsystems.es/ 23 El TC 2012/2013 26 consistía en producir un perfil UML para los modelos estáticos del MIF haciendo uso de la herramienta EA, permitiendo a las herramientas de modelado UML comerciales trabajar con modelos estáticos de HL7, los cuales presentan características que requieren la extensión de las expresiones UML estándares. En septiembre de 2012 se comenzó a anunciar este primer TC. En este caso, los criterios que determinaron el ganador fueron:  Validez del perfil según los perfiles UML definidos por la OMG.  Validez del perfil representando las construcciones del modelo estático del MIF.  Capacidad del perfil para ser utilizado en EA para construir modelos estáticos HL7 válidos conformes al MIF.  Rigurosidad de la documentación del perfil.  Capacidad del perfil para crear nuevos modelos basados en el estándar HL7 v3.  Extensibilidad del perfil.  Capacidad para realizar cambios en la metodología. Los participantes podían presentar sus contribuciones hasta el 1 de Julio de 2013. Al equipo ganador se le premió con una cantidad monetaria de 4.000$ USD. El 1 de octubre de 2013 se comenzó a difundir el ganador de este concurso, condecorado en la Working Group Meeting de septiembre de 2013 27 . Los ganadores de este concurso fueron Antoni Olivé y Antonio Villegas, profesores de la Universidad Politécnica de Cataluña. El TC 2013/2014 28 consistía en definir detalladamente y evaluar una metodología para utilizar una herramienta UML off-the-shelf para gestionar artefactos de HL7 v3, permitiendo a un desarrollador crear una herramienta que cubra las necesidades de HL7. A finales de 2013 se comenzó a anunciar este segundo TC. En este caso, los criterios que determinarían el ganador eran:  Representación válida y completa de un perfil UML que represente los modelos estáticos del MIF. 26 http://wiki.hl7.org/index.php?title=HL7_Tooling_Challenge_2013 27 http://www.healthcareitnews.com/press-release/hl7-sparx-systems-announce-winners-2012- 2013-tooling-challenge 28 http://wiki.hl7.org/index.php?title=HL7_Tooling_Challenge 24  Validez del perfil UML, y capacidad de interoperabilidad con otros estándares de la OMG.  Capacidad del perfil para producir modelos.  Documentación acerca de las dificultades encontradas al aplicar el perfil UML.  Perfil UML correctamente documentado y fácil de entender para nuevos desarrolladores de artefactos HL7 v3.  Extensibilidad del perfil.  Capacidad para realizar cambios en la metodología. Los participantes podrían presentar sus contribuciones hasta el 1 de Julio de 2014. Según se indica en la página del Tooling Challenge de HL7, el ganador se anunciaría durante la Working Group Meeting de septiembre de 2014. Finalmente, HL7 declaró que no habría ganador para este concurso por falta de propuestas. Derivado de la falta de propuestas en la edición 2013/2014, HL7 decidió no publicar nuevos concursos Tooling Challenge 2014/2015 o 2015/2016, cerrándose así la corta trayectoria (solo 2 ediciones) que tuvo esta iniciativa conjunta entre HL7 y Sparx Systems para realizar herramientas HL7 basadas en MDE. A principios de 2016, HL7 publica un nuevo concurso con el mismo nombre, Tooling Challenge, pero en este caso no está patrocinado por Sparx Systems, y no está enfocado al desarrollo de herramientas HL7 basadas en MDE. En este caso, la propuesta consiste en el desarrollo de una herramienta para trabajar con documentos basados en el estándar HL7 Consolidated Clinical Document Architecture (CCDA). Ortiz et al.: Transformación de modelos de HL7 a UML Esta investigación [Ortiz et al. 2011a] comenzó a raíz del Proyecto Fin de Carrera (PFC) de David Ortiz [Ortiz et al. 2011b], estudiante de Ingeniería Informática de la Facultat d' Informàtica de Barcelona (FIB). Tras identificar dificultades consecuentes de la utilización de un lenguaje de modelado propio en HL7, propusieron realizar una traducción de los modelos de dominio de HL7 a una nomenclatura UML. Para representar los metamodelos de HL7 y UML, estos investigadores utilizaron el formato .ecore, lenguaje propio de la herramienta Eclipse para definir metamodelos 29 . El metamodelo de UML no lo tuvieron que diseñar ellos mismos, ya que la OMG se encarga de dicho diseño. Tampoco tuvieron que desarrollar la versión en formato .ecore, porque ese trabajo ya lo han realizado distintos grupos de desarrollo de Eclipse. 29 https://eclipse.org/modeling/ 25 En cambio, el metamodelo de HL7 si lo diseñaron ellos mismos. Así lo describe el autor David Ortiz en la afirmación mostrada en la Tabla 7. Tabla 7. Introducción al diseño de un metamodelo de HL7 [Ortiz et al. 2011b] “Los modelos disponibles en el estándar HL7, se rigen por toda una serie de normas y restricciones definidas implícitamente. El primer paso que debemos dar, consiste en diseñar un metamodelo que refleje todas esas características y del cual, todos los modelos disponibles en el estándar se puedan considerar instancias.” En este trabajo, no se justifica la decisión de diseñar un metamodelo para HL7 en vez de utilizar los metamodelos de HL7 ya existentes. De hecho, en la memoria del PFC de David Ortiz, nombran el MIF como un posible formato en el que utilizar un modelo HL7, concepto claramente equivocado a día de hoy, tal y como indican los autores en la afirmación mostrada en la Tabla 8: Tabla 8. Formatos disponibles de los modelos HL7 [Ortiz et al. 2011b] “La información de los modelos del estándar HL7, se encuentra disponible en distintos formatos. En el proyecto que nos ocupa, se ha optado por utilizar los archivos MIF (Model Interchange Format).” En esta investigación, han llegado a implementar las transformaciones de un metamodelo HL7 -diseñado por ellos mismosal metamodelo de UML, realizando una prueba práctica de transformar el modelo de dominio de HL7 v3 a modelos UML. Los directores de esta investigación coinciden con los ganadores del HL7 Tooling Challenge 2012/2013 que se publicaría algo más de un año después, concurso detallado al comienzo del presente apartado, en la sección con encabezado ‘HL7 Tooling Challenge’. Model Driven Health Tool (MDHT) El proyecto de código abierto Model-Driven Health Tools (MDHT) 30 desarrolla un marco de modelado común con el objetivo de promover y mejorar la interoperabilidad en las 30 https://www.projects.openhealthtools.org/sf/projects/mdht/ 26 infraestructuras sanitaria, permitiendo la creación de modelos procesables por ordenador, basados en CDA, haciendo uso de plantillas basadas en UML. Para ello, ofrece un marco común de modelado que incluye herramientas que dan soporte a la creación, diseño y publicación de artefactos. MDHT da soporte al ciclo de vida completo del desarrollo de estándares, ofreciendo una solución que permite colaborar activamente a diseñadores e implementadores. Esta propuesta centra sus esfuerzos en uno de los estándares primarios de HL7, CDA, pero no cubre el espectro completo de conceptos que existe en los metamodelos de HL7. Gracias al uso del marco desarrollado por MDHT, se pueden conseguir los siguientes beneficios:  Publicación de una API Java para implementar los modelos.  Generación automática de herramientas de validación.  Publicación automática de guías de implementación.  Reducción de los costes y tiempos de desarrollo, ofreciendo documentación concisa con recursos de implementación que soporten dichos desarrollos.  Reutilización de plantillas existentes.  Compartición de guías de implementación para iniciativas futuras.  Mejorar la comunicación y el intercambio de información, lo cual finalmente desemboca en una mejor gestión de los datos de los pacientes. A día de hoy, este proyecto ha permitido construir modelos de algunas especificaciones existentes de HL7 (HL7 Continuity of Care Document 31 , HL7 CDA implementation guide Public Health Case Reports 32 , HL7 CDA implementation guide Personal Healthcare Monitoring Report 33 , HL7 Common Document Types 34 ), así como otras especificaciones mantenidas por otras organizaciones (IHE Patient Care Coordination Technical Framework 35 , HITSP C83 36 Sections and Entries). 31 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=6 32 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=34 33 http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&Project Number=209 34 http://wiki.hl7.org/index.php?title=CDA_for_Common_Document_Types_%28CDA4CDT%29 35 http://www.ihe.net/Patient_Care_Coordination/ 27 En la literatura gris, se pueden encontrar algunos trabajos presentados a congresos sobre el uso satisfactorio del conjunto de herramientas ofrecidas por MDHT [Renly et al. 2012, Farkash et al. 2012]. 2.2.2. Ejecución del esquema de caracterización La siguiente tabla (Tabla 9) recoge de manera completa los resultados obtenidos tras la evaluación de cada una de las características objetivas definidas en el esquema de caracterización, evaluadas sobre cada una de las experiencias descritas en la sección anterior. Tabla 9. Resultados evaluación características Característica HL7 Tooling Challenge Ortiz et al.: Transformación de modelos de HL7 a UML MDHT Estándares HL7 HL7 v3 HL7 v3 HL7 CDA Ampliable No No No Madurez 2012 2011 2009 Comunidad No No Si Documentación No Si Si Revistas No No No Literatura gris Si Si Si Analizando los resultados obtenidos tras la evaluación de cada una de las características del esquema de caracterización, cabe destacar que las 3 experiencias se centran en un solo estándar de HL7, y no presentan capacidad de ampliación. MDHT se diferencia levemente de las otras 2 experiencias por tener unos años más de madurez y por presentar una comunidad de usuarios que, junto a la documentación, puede dar soporte al uso de sus herramientas. 36 http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=83 28 2.3. Análisis de las cuestiones de investigación Teniendo en cuenta los resultados de la revisión sistemática de la literatura, así como los resultados de la revisión general, a continuación se analiza cada una de las cuestiones de investigación definidas en la fase de planificación de la revisión. CI1: ¿Existen experiencias previas en el uso de HL7 en el contexto de MDE? Si, existen experiencias previas en el uso de HL7 en el contexto de MDE, desde hace más de una década. Tras realizar una SLR rigurosa en 7 BD científicas, solamente se ha identificado 1 estudio prometedor. En cambio, al realizar una búsqueda general en el buscador de propósito general Google, se han identificado algunas experiencias de gran magnitud que trabajan en este campo. Estas experiencias no han sido publicadas en revistas de impacto, en cambio sí han sido publicadas en literatura gris. Todas las experiencias identificadas se centran en un estándar de HL7 y no cuentan con capacidades de ampliación para incluir todos los estándares de HL7. CI2: Las experiencias existentes, ¿pretenden cubrir todos los estándares de HL7? No, las experiencias existentes se centran en un metamodelo específico de HL7, como puede ser el metamodelo del estándar CDA o el metamodelo del estándar v3. Se podría aumentar significativamente el impacto de las herramientas construidas en estas experiencias si se definieran mecanismos de ampliación para incluir otros estándares de HL7, teniendo en cuenta que HL7 cuenta con cientos de estándares diferentes. CI3: ¿Qué tipos de técnicas MDE utilizan las experiencias existentes? En las experiencias existentes, para conseguir un escenario de herramientas MDE, hemos identificado el uso de diferentes tipos de técnicas complementarias entre ellas: Modelado de perfiles UML, modelado de metamodelos, restricciones en OCL (Object Constraint Language), transformaciones automáticas entre modelos dado un metamodelo origen y un metamodelo destino, representaciones XMI, mecanismos de refinamiento de UML, reglas de transformación en ATL (Atlas Transformation Language), etc. CI4: ¿Qué temas sin resolver se identifican en los resultados? Teniendo en cuenta los resultados obtenidos, identificamos la necesidad de trabajar en un marco de trabajo que presente una capacidad de ampliación para cubrir el metamodelo completo de HL7, para así poder incluir nuevos metamodelos con poco esfuerzo y ofrecer la capacidad de trabajar con cualquiera de los estándares de HL7 existentes. 29 3. Lecciones aprendidas En el apartado 2.1 del presente capítulo se ha realizado una SLR. Al concluir que en la literatura científica apenas existen experiencias previas relacionadas, identificando 1 solo resultado prometedor, se ha realizado una revisión general en la Web (apartado 2.2 del presente capítulo). Se analizaron las diferentes experiencias encontradas siguiendo un esquema de caracterización (apartado 2.2.2), y se dio respuesta a las cuestiones de investigación propuestas (apartado 2.3). Teniendo en cuenta los trabajos relacionados identificados, se pone de manifiesto desde hace años la importancia del modelado de información en el ámbito sanitario para compartir conocimiento, mejorar los procesos y documentar los requisitos de las soluciones de sistemas de información sanitarios. El hecho de que existan experiencias previas en el uso de HL7 en el contexto de MDE refuerza el interés identificado por la autora de la presente Tesis Doctoral para trabajar en esta línea. Aunque las experiencias anteriormente descritas combinan las temáticas de MDE y HL7, encontramos principalmente un obstáculo: aunque aplican técnicas basadas en MDE (transformación entre modelos, generación automática de código, etc.), no llegan a tratar el metamodelo de HL7 en su totalidad, ya que se centran en un metamodelo específico de HL7. Derivado de esta decisión, estas experiencias tienen menos impacto. La presente Tesis Doctoral aporta un marco de referencia compuesto por 3 pilares básicos que ofrece el siguiente valor añadido a la base científica existente:  Metodología. Procedimiento para diseñar modelos de dominio HL7 en un proyecto de software sanitario, utilizado una interfaz basada en UML.  Lenguaje de modelado basado en HL7. Lenguaje que extiende a UML para modelar sistemas de información sanitarios conformes a todo el espectro de estándares de HL7.  Mecanismos de derivación. Elemento clave para hacer posible la interoperabilidad entre estándares, y para facilitar la mantenibilidad y extensión de los sistemas. Este marco de referencia ha sido denominado MoDHE (MOdel Driven Health Engineering) por su estrecha relación con el paradigma MDE y con el contexto sanitario. La siguiente figura (Figura 6) refleja este planteamiento basado en pilares: 30 Marco de referencia Lenguaje de modelado basado en HL7 Metodología Mecanismos de derivación Figura 6. Marco de referencia 4. Conclusiones En el presente capítulo, se ha realizado un análisis del estado del arte en referencia al uso de HL7 en el contexto de MDE. El apartado 1 analiza el contexto en el que se enmarca el estado del arte. El apartado 2 presenta la SLR realizada, desembocando en una búsqueda general en la Web por no encontrar suficientes resultados prometedores. Los resultados identificados en la búsqueda general fueron comparados siguiendo un esquema de caracterización. El apartado 3 presenta una reflexión de las lecciones aprendidas y el valor añadido que aporta la presente Tesis Doctoral respecto a la base científica existente. Experiencias previas proponen traducir los metamodelos de HL7 modelados en un lenguaje gráfico propio a un lenguaje de propósito general como UML. El planteamiento expuesto en la presente memoria, a diferencia de estas experiencias, ofrece un enfoque diferente, a favor de la libertad de elección (lenguaje propio de HL7 vs lenguaje de propósito general UML), facilitando el diseño de modelos de dominio HL7 en cualquiera de estos casos, gracias al uso de un marco de referencia (bautizado como MoDHE). Otras experiencias han estudiado la correspondencia entre UML y un metamodelo específico de HL7, traduciendo elementos de un metamodelo a otro. Estas experiencias no llegan al nivel de abstracción de la presente Tesis Doctoral, debido a que se centran en un solo estándar de HL7. No se han encontrado experiencias previas que pretendan utilizar HL7 en el contexto de MDE haciendo una correspondencia de los elementos de sus metamodelos con UML, con el objetivo de ofrecer una herramienta a los ingenieros del software con la que puedan trabajar con UML directamente (pudiendo apoyarse en todas las herramientas existentes para UML en el contexto de MDE) y con la que de forma transparente estén trabajando con los metamodelos de HL7. 31 Capítulo III. Propuesta detallada os anteriores capítulos (Capítulo I y Capítulo II) asientan las bases teóricas del reto consistente en diseñar modelos de dominio HL7 utilizando elementos propios de UML, mediante soluciones guiadas por modelos. Estas bases introducen los conceptos básicos utilizados en la presente línea de investigación, así como el estado del arte actual sobre el tema. En el presente capítulo, se detalla el planteamiento del problema, así como los objetivos definidos en esta Tesis Doctoral. También se presentan los aspectos que han influenciado a esta investigación. Por último, se presenta una propuesta de solución que cubre los objetivos planteados, incluyendo una definición formal de la propuesta. 1. Planteamiento del problema Una vez analizados los trabajos existentes relacionados con el reto consistente en diseñar modelos de dominio HL7 por ingenieros del software haciendo uso de soluciones guiadas por modelos, nos planteamos buscar solución a los siguientes problemas:  Curva de aprendizaje. UML es un lenguaje estándar de modelado de sistemas software ampliamente conocido y utilizado. La mayoría de los metamodelos de HL7 están diseñados siguiendo un lenguaje de modelado gráfico propio, el cual solo es conocido y utilizado por los miembros de HL7, así como aquellos ingenieros del software que alguna vez se hayan enfrentado a ellos. Algunos metamodelos de HL7 ni siquiera están modelados de un modo gráfico, sino de forma textual a través de extensos documentos. Por ello, si un ingeniero del software desea diseñar un sistema sanitario basado en HL7, se enfrenta a una curva de aprendizaje mayor, frente a diseñar un modelo de dominio UML.  Usabilidad. Las herramientas que permiten trabajar con los estándares de HL7 son muy limitadas, y menos usables que las que utilizan un lenguaje de modelado estándar por utilizar de forma explícita la semántica de HL7. En cambio, existen multitud de herramientas para diseñar sistemas con UML. Estas herramientas son más usables por estar el ingeniero del software más familiarizado con la semántica de UML. Si un ingeniero del software diseña un sistema de información sanitario haciendo uso de una herramienta que consiga establecer conformidad de elementos de UML con elementos de HL7 de forma transparente, la usabilidad de la herramienta podrá ser mucho mayor.  Mantenibilidad y adaptación. Teniendo en cuenta la enorme complejidad y magnitud de los estándares de HL7, los sistemas de información creados en base a HL7 son menos mantenibles y tienen una capacidad de adaptación al cambio L 38 Está diseñado para soportar un sistema donde los datos pueden estar almacenados en un almacén de datos único, o bien en un sistema distribuido donde los datos se almacenan en los sistemas departamentales. Gracias al uso del estándar HL7 v2.x, obtendremos los siguientes beneficios:  Soporta la mayoría de interfaces que se utilizan en la industria sanitaria a nivel mundial.  Proporciona un marco de negociación para aquellos aspectos que no están cubiertos por el estándar.  Reduce gastos de implementación.  Es compatible con versiones anteriores del estándar. Estándar HL7 v3 El estándar HL7 v3, Version 3 Product Suite, consiste en un conjunto de especificaciones basadas en el RIM, que proporcionan a los implementadores los recursos necesarios para trabajar con mensajes, tipos de datos, y terminologías. Incluye canales de comunicación que permiten gestionar la atención y el tratamiento de pacientes en diferentes entornos sanitarios. Se basa en una metodología que representa mensajes y documentos en formato XML (Extensible Markup Language). Se comenzó a trabajar en este estándar alrededor de 1995, pero hasta 2005 no se creó la primera publicación oficial. Se considera un estándar más robusto que HL7 v2.x, ya que reduce la ambigüedad semántica y mejora los procesos, por contar con un modelo de referencia de información subyacente (dicho modelo de referencia es el RIM). Este estándar recomienda el uso de vocabularios controlados a través de terminologías internacionales (LOINC, CIE-10, Snomed CT, etc.). Gracias al uso del estándar HL7 v3, obtendremos los siguientes beneficios:  Abarca interoperabilidad semántica, asegurando que los sistemas origen y destino comparten el significado de la información que se intercambia.  Permite a los implementadores utilizar las tecnologías de implementación más recientes y eficaces.  Facilita el desarrollo constante, así como la capacidad de almacenar y manipular las especificaciones en repositorios de datos robustos.  Diseñado para un uso universal. Estándar HL7 CDA HL7 CDA es un estándar de marcado de documentos que especifica la estructura y semántica que debe cumplir cualquier documento clínico con el objetivo de que pueda ser intercambiado entre proveedores de salud y/o pacientes. Este estándar trabaja sobre el modelo de información R-MIM, el cual es un subconjunto del RIM. 39 Este estándar surgió del trabajo de un grupo de médicos que detectaron la necesidad de utilizar documentos clínicos estructurados. Se utiliza para intercambiar documentos clínicos entre sistemas de información sanitarios. Define el concepto de documento clínico, así como sus características principales. El estándar CDA en su versión Release 2, ha sido adoptado como una norma ISO, en concreto la norma ISO/HL7 27932 [ISO/HL7 2009]. Gracias al uso del estándar HL7 CDA, obtendremos los siguientes beneficios:  Proporciona un marco de soporte al intercambio de documentos clínicos entre aquellas personas involucradas en la atención de un paciente.  Proporciona un marco de soporte a la reutilización de los datos provenientes de diferentes tipos de documentos clínicos (informes asistenciales, seguridad, ensayos clínicos, etc.).  Puede ser reutilizado en múltiples aplicaciones. 3.2.3. Grupos de trabajo de HL7 Los miembros de HL7 participan en los grupos de trabajo de HL7. Estos grupos de trabajo pueden ser comités permanentes que discuten algún topic, o comités temporales con el objetivo de crear o revisar un estándar, los cuales se archivan cuando el trabajo está realizado. Actualmente, existen en HL7 un total de 65 grupos de trabajo (GT) 38 . A continuación mencionamos un subconjunto de éstos, mostrando una clasificación por el tipo de GT:  Grupos de trabajo sobre estándares: Arden Syntax, Clinical Decision Support, etc.  Grupos de trabajo sobre patologías o escenarios clínicos: Anatomic Pathology, Anesthesia, etc.  Grupos de trabajo sobre procesos asistenciales: Patient Care, Patient Administration, Emergency Care, etc.  Grupos de trabajo sobre líneas de investigación en informática médica: Architectural Review, Electronic Health Records, Mobile Health, Modeling and Methodology, Services Oriented Architecture, etc. 38 http://www.hl7.org/Special/committees/index.cfm?ref=nav 40 De todos los grupos de trabajo, el GT llamado “Modeling and Methodology” es de especial interés para la presente Tesis Doctoral, teniendo en cuenta la misión de dicho GT:  Creación, mantenimiento y facilitación del uso de la metodología de desarrollo de HL7.  Mantenimiento de un modelo de referencia y un modelo de tipos de datos que gobiernan los modelos desarrollados y utilizados por los GT de HL7, creando un desarrollo basado en estándares de modelado.  Gestión de patrones y constructores de modelado reutilizables para los diseños de HL7.  Desarrollo, aplicación y difusión de buenas prácticas de modelado. 3.3. MDE La ingeniería dirigida por modelos (MDE) es un paradigma que ofrece una nueva perspectiva de trabajo en el desarrollo del software, ofreciendo al campo de la ingeniería del software una vía importante para facilitar los desarrollos y reducir tiempos, aumentando la consistencia y trazabilidad del software. El paradigma MDE permite centrarse en los conceptos y sus relaciones y despreocuparse de la representación de los mismos, representándolos de forma abstracta. Los conceptos se relacionan entre sí estableciendo conexiones que luego se pueden sistematizar para facilitar la derivación de unos modelos a partir de otros. Una vez definidos los conceptos del dominio del problema y las relaciones entre estos, se pueden definir transformaciones. Las transformaciones definen, mediante relaciones dinámicas, los pasos que hay que dar para conseguir un modelo a partir de otro. Encontramos 2 tipos de transformaciones:  Model to Model (M2M). Consiste en transformar un modelo conforme a un primer metamodelo, al otro modelo con contenido similar pero conforme a un segundo metamodelo.  Model to Text (M2T). Consiste en transformar un modelo conforme a un metamodelo en código fuente, para construir una herramienta software. Gracias al uso de MDE conseguimos los siguientes beneficios [Escalona et al. 2007b, Moreno et al. 2008]:  Mayor nivel de abstracción. Centra la atención en los modelos, y no en los datos, posibilitando al ingeniero del software una mejor gestión del sistema.  Independencia de la plataforma. Permite desacoplar la definición conceptual de las aplicaciones de la tecnología en la que se ejecutan.  Simplifica el proceso de diseño. MDE simplifica el diseño de los sistemas, teniendo en cuenta que los modelos pueden servir como base para los sistemas de aplicación. 41  Aumenta la productividad. MDE aumenta la productividad, ya que maximizamos la compatibilidad entre sistemas, gracias a la reutilización y la representación abstracta de conceptos, y garantizamos la trazabilidad.  Reduce el tiempo de desarrollo. Derivado de la automatización de la generación de modelos, se consigue una reducción en el tiempo de desarrollo.  Reduce los errores. MDE permite reducir errores, principalmente gracias a la sistematización, incrementándose por la posibilidad de automatización que en algunos casos ofrece. En los últimos años, el paradigma MDE se está aplicando en un gran número de campos dentro de la ingeniería del software, como por ejemplo en el uso de técnicas de ingeniería de requisitos [Loniewski et al. 2010], o en la gestión de la trazabilidad [Santiago et al. 2012]. También se está aplicado en un gran número de campos dentro del ámbito sanitario, como por ejemplo en la genética [Maier et al. 2015, Beal et al. 2015], o de forma transversal en el desarrollo de herramientas para mejorar la creación y mantenimiento de Historias Clínicas Electrónicas [Curcin et al. 2014]. 3.4. NDT NDT 39 es una metodología basada en la ingeniería guiada por modelos que proporciona un soporte formal y completo la gestión del ciclo de vida del software (estudio de viabilidad, requisitos, análisis, diseño, implementación, mantenimiento, pruebas) [Escalona et al. 2008]. Utilizando NDT, podemos cubrir las fases del ciclo de vida en ingeniería del software de una forma estructurada, reduciendo errores y redundancias. Las características que ofrece NDT son:  Cubre todas las fases del ciclo de vida en ingeniería del software.  Soporta la realización de patrones y artefactos.  Reduce inconsistencias y errores.  Transforma el desarrollo de modelos en un proceso automático y sistemático.  Genera automáticamente documentación, tales como el documento de requisitos, el documento de análisis, prototipos, etc.  Soporta la visualización de modelos gráficos.  Soporta la gestión de varios proyectos simultáneamente. 39 http://www.iwt2.org/web/opencms/IWT2/ndt/?locale=en 42  Soporta la gestión de varios equipos de desarrollo trabajando al mismo tiempo. La metodología NDT define un conjunto de metamodelos (y transformaciones entre éstos) para tratar formalmente las fases del ciclo de vida del software anteriormente mencionadas. En sus inicios, esta metodología cubría exclusivamente 2 fases del ciclo de vida del software (elicitación de requisitos y análisis de requisitos). Con los años, la metodología NDT ha ido evolucionando, proporcionando un marco de trabajo para cubrir todas las fases del ciclo de vida del software. En concreto, NDT define las siguientes fases: 1. EVS. Estudio de viabilidad del sistema. En esta fase, se debe analizar la viabilidad de un determinado proyecto software. Suele realizarse bajo demanda del proyecto o bien cuando el proyecto se desarrolle en un entorno complejo o poco conocido que pueda hacer dudosa la viabilidad del mismo. 2. DRS. Ingeniería de requisitos. Define un catálogo de requisitos que debe definir las necesidades del sistema. Se deben establecer los requisitos catalogados según su tipología y no entrar en ningún aspecto de detalle sobre cómo se solventará el desarrollo. 3. DAS. Análisis del sistema. Productos resultantes de analizar, definir y estructurar los requisitos establecidos en la fase anterior, de forma independiente de la plataforma tecnológica que finalmente se use para desarrollar el software. 4. DDS. Diseño del sistema. Aspectos concretos sobre cómo el análisis se implementará en la máquina. Está orientado a la plataforma concreta con la que se vaya a trabajar y debe corresponderse con la estructura del futuro código. 5. Construcción. Esta fase se refiere a la propia implementación o desarrollo del sistema software. 6. DPS. Pruebas del sistema. Mientras que las otras fases del ciclo de vida tienen su momento concreto de realización, la fase de pruebas se realiza de manera paralela al resto del ciclo de vida. Las pruebas que se tendrán en cuenta son las correspondientes a: pruebas de implantación, pruebas del sistema y pruebas de aceptación o de usuario. 7. DMS. Mantenimiento del sistema. El proceso de mantenimiento es un proceso que comienza cuando el proyecto ha pasado a producción, y termina cuando el sistema cae en desuso. Por esta razón, su complejidad es bastante alta y crítica, siendo, sin duda, una de las etapas más costosas del mismo. El equipo de NDT ofrece un paquete de herramientas de software libre, llamado NDT- Suite, que guía al ingeniero del software en el uso de la metodología, cubriendo las fases de desarrollo, control de la calidad, mantenimiento, pruebas y seguridad. Las herramientas NDT utilizan y extienden modelos UML, siguiendo un proceso basado en MDE. Hoy en día, NDT se ha utilizado en múltiples proyectos y experiencias empresariales [Escalona et al. 2010, García-García et al. 2014]. 4. Propuesta de solución Como se ha comentado anteriormente, el objetivo de la solución es dar soporte al desarrollo de sistemas de información sanitarios conformes a HL7, a través de un marco 43 de referencia que permita acercar los estándares de HL7 y el lenguaje de modelado de propósito general UML, haciendo uso del paradigma MDE. MoDHE hace realidad dicho marco de referencia. La siguiente figura (Figura 9) muestra una vista del contexto en el que se desarrolla el marco de referencia MoDHE. Gracias a la solución propuesta, los ingenieros del software pueden modelar sistemas de información sanitarios mantenibles y adaptables haciendo uso de UML, en conformidad con los estándares de HL7 que requieran utilizar, consiguiendo un marco de referencia usable, y reduciendo la curva de aprendizaje del ingeniero del software que necesita trabajar con los estándares de HL7. Ingeniero del software Ingeniero del software Herramienta de soporte MoDHE Suite Marco de referencia MoDHE <<usa>>  Metodología  Metamodelos  Restricciones  Transformaciones <<desarrolla>> Modelos de sistemas de información sanitarios  Mantenibilidad  Adaptación  Usabilidad  Curva de aprendizaje menor Figura 9. Contexto El marco de referencia MoDHE se centra en la fase de definición de requisitos, ya que es la fase más crítica en proyectos clínicos por existir multitud de estándares principales de HL7 que aplican a esa fase específica de la ingeniería del software, estándares que deben ser aplicados para obtener software sanitario interoperable. Una vez resuelta la fase de requisitos, el resto de fases del ciclo de vida del software sanitario se podría desarrollar de forma similar a cualquier otro proyecto software no sanitario. Teniendo en cuenta que la metodología NDT soporta el diseño de todas las fases del ciclo de vida del software, se ha considerado conveniente crear la metodología de MoDHE como una extensión de la metodología NDT, obteniendo los siguientes beneficios:  La metodología NDT extiende el metamodelo de UML. Por tanto, de forma intrínseca, la metodología de MoDHE extiende el metamodelo de UML.  Al crear la metodología de MoDHE como una extensión de la metodología NDT, una vez superada la fase de definición de requisitos aplicando estándares de HL7, la metodología de MoDHE ofrecerá la capacidad de continuar modelando el resto de fases del ciclo de vida del software.  La metodología de MoDHE mantiene los artefactos propios de la metodología NDT. Por tanto, si el sistema de información sanitario a desarrollar combina requisitos 44 sanitarios y requisitos independientes del contexto sanitario, también se podrán definir requisitos no sanitarios. Para realizar la extensión de la metodología NDT, incluyendo los metamodelos y restricciones propios de HL7, se debe estudiar en profundidad el metamodelo de cada estándar de HL7 que se desea incorporar al marco de referencia, así como sus restricciones y las relaciones existentes con otros estándares de HL7. En la propuesta Tesis Doctoral, se ha incorporado el estándar HL7 v3 en su totalidad, así como los estándares HL7 CDA y HL7 v2.x de forma parcial, teniendo en cuenta la enorme extensión que éstos presentan. Cabe destacar que la metodología de MoDHE está diseñada con capacidad de ampliación, pudiendo incluir otros estándares de HL7 con una reducción importante del esfuerzo que supondría realizarla desde cero. La siguiente figura (Figura 10) representa gráficamente la definición formal anteriormente descrita. Por una parte, en la parte izquierda de la figura, se representan los metamodelos de HL7. Por otra parte, en la parte derecha, se representan los metamodelos de MoDHE, que extienden los metamodelos de NDT (más específicamente, el metamodelos de requisitos de almacenamiento de información), que a su vez extienden los metamodelos de UML (más específicamente, los metamodelos de diagrama de clases). Se representan también mecanismos de derivación, entre los diferentes metamodelos de MoDHE. Los metamodelos de HL7 y los metamodelos de MoDHE presentan relaciones 1 a 1, ya que para modelar los metamodelos de MoDHE se han tenido en cuenta los metamodelos y las restricciones presentes en los estándares de HL7. 45 Metamodelo HL7 Metamodelo UML Metamodelos estándares HL7 extiende Metamodelos NDT extiende Metamodelos MoDHE extiende HL7 v3 HL7 CDA HL7 v2.x RA MoDHE v3 MoDHE CDA MoDHE v2.x Diagrama de clases Transformaciones Figura 10. Definición formal de la propuesta El siguiente capítulo (Capítulo IV) desarrolla de forma detallada la descripción de la metodología de MoDHE que se ha presentado en este apartado sin entrar en profundidad. Los 2 capítulos posteriores (Capítulo V y Capítulo VI) detallan el resto de elementos que, junto con la metodología, forman parte del marco de referencia (metamodelos, restricciones y transformaciones). 5. Conclusiones En este capítulo se han detallado definiciones relevantes para la presente Tesis Doctoral, tales como el planteamiento del problema, el objetivo principal y los objetivos específicos, teniendo en cuenta las conclusiones obtenidas tras el estudio del estado del arte desarrollado en el Capítulo II. Además, se revisan los 4 grandes ámbitos de la investigación, la informática, la ingeniería y el mundo sanitario que han influenciado este trabajo: HL7, UML, MDE, y NDT. Se ha presentado una propuesta de solución, que establece una metodología de trabajo para dar soporte al diseño de modelos de dominio HL7 usando modelos UML mediante una solución guiada por modelos. 46 Una vez finalizado el presente capítulo, se consideran sentadas las bases necesarias para comenzar a presentar en profundidad, en los siguientes capítulos, la propuesta. 47 Capítulo IV. Metodología de MoDHE n el capítulo anterior, se ha definido una propuesta detallada de la solución ofrecida por la presente Tesis Doctoral, especificando el planteamiento del problema, los objetivos, así como los diferentes aspectos que han influenciado en el desarrollo de dicha solución. También se ha presentado una definición formal a alto nivel de la metodología propuesta. En el presente capítulo, se presenta detalladamente la metodología de MoDHE. Esta propuesta metodológica permite al ingeniero del software modelar sistemas de información sanitarios de forma sistemática trabajando diagramas UML, y garantiza el cumplimiento de los estándares de HL7 incluyendo mecanismos de extensión que permiten incluir cualquier estándar existente en HL7. Esta metodología forma parte de unos de los 3 pilares definidos en el Capítulo II, apartado 3, para centrar el marco de referencia. La siguiente figura (Figura 11) identifica el pilar en el que nos centramos en el presente capítulo, dentro del marco de referencia. Marco de referencia Lenguaje de modelado basado en HL7 Metodología Mecanismos de derivación Figura 11. Marco de referencia. Pilar ‘Metodología’ La metodología de MoDHE extiende a la metodología NDT, ampliando los metamodelos que cubren los elementos del ciclo de vida del software, y contemplando los metamodelos propios de los estándares de HL7, permitiendo así un marco de trabajo formal y completo que permite modelar un sistema de información sanitario conforme a HL7 de manera sistemática usando modelos UML. E 54 Metamodelo HL7 Metamodelo UML Metamodelos estándares HL7 extiende Metamodelos NDT extiende Metamodelos MoDHE extiende HL7 v3 HL7 CDA HL7 v2.x RA MoDHE v3 MoDHE CDA MoDHE v2.x Diagrama de clases Transformaciones Figura 17. Definición formal de la propuesta. Parte MoDHE Una vez analizado en profundidad un estándar específico de HL7 con el objetivo de incluirlo como parte de la metodología de MoDHE, se identifica la fase de NDT sobre la que aplica, y se extiende el metamodelo de NDT de la fase en cuestión, modelando un metamodelo propio de MoDHE basado en el metamodelo del estándar correspondiente de HL7. Por ejemplo, para cubrir el estándar HL7 v2.x, se extiende la fase RA de NDT, creando el metamodelo de MoDHE v2.x que se basa en el metamodelo de HL7 v2.x. Además de extender dicho metamodelo para incluir las entidades específicas del estándar de HL7 en cuestión (entidades que no se identifican en una definición de requisitos de un software no sanitario), se definen las restricciones necesarias en lenguaje OCL para cubrir en su totalidad las peculiaridades que estos estándares presentan. Analizando cada uno de los estándares de HL7, se evidencia que existe cierta trazabilidad entre los elementos de diferentes estándares. Por ejemplo, en los metamodelos de los estándares v3, CDA y v2.x cubiertos en la presente Tesis Doctoral, existen atributos para dar cabida a la definición de los datos demográficos del paciente. La metodología de MoDHE define transformaciones para hacer posible transformar modelos de un estándar a otro. Para cubrir la parte estática del sistema, la presente Tesis Doctoral cubre los estándares HL7 v3, HL7 CDA y HL7 v2.x. Estos 3 estándares se pueden corresponder con los elementos modelados en los ‘Requisitos de Almacenamiento de Información’ (RA) de la fase DRS de NDT. Por tanto, para abarcar estos 3 estándares de HL7, se ha extendido el 55 metamodelo de NDT correspondiente a la fase DRS, añadiendo los elementos propios de cada estándar. Al utilizar la metodología de MoDHE para desarrollar software sanitario, además de diseñar los requisitos de información en base a uno o más estándares de HL7, se puede diseñar el resto del proceso por el que pasa el ciclo de vida del software, ya es común a cualquier otro software no sanitario. De forma adicional a la definición de requisitos sanitarios conformes a HL7, esta metodología permite definir requisitos de información no sanitarios si fuera necesario. El siguiente diagrama (Figura 18) extiende el diagrama incluido en la Figura 14, mostrando las características con las que cuenta la metodología de MoDHE gracias a la extensión de la metodología NDT (azul), y las fases que cubre la metodología de MoDHE por el desarrollo específico realizado en la presente Tesis Doctoral (morado): Metodología NDT Metodología MoDHE Definición de MoDHE v3 Definición de MoDHE CDA Definición de MoDHE v2.x Estudio de viabilidad del sistema (EVS) Ingeniería de requisitos (DRS) Análisis del sistema (DAS) Definición de Objetivos Definición de Servicios Definición de Requisitos de Almacenamiento de Información Definición de Actores del Sistema Definición de Requisitos Funcionales Definición de Requisitos de Interacción Definición de Requisitos no Funcionales Diseño del sistema (DDS) Construcción Pruebas del sistema (DPS) Mantenimiento del sistema (DMS) Figura 18. Fases cubiertas por la metodología de MoDHE. Actividades dentro de DRS Una vez el ingeniero del software haya modelado los requisitos de información conforme a HL7 utilizando la metodología de MoDHE, podrá generar automáticamente la fase de análisis del sistema y las fases posteriores del ciclo de vida del software como si de un proyecto software no sanitario se tratara. De este modo, conseguimos sistematizar el proceso de desarrollo. Más específicamente: 56  De la fase de requisitos de información, se podrá generar la base que formará los diagramas de clases del modelo conceptual en la fase de Análisis del Sistema (DAS).  Para la fase análisis del sistema, se podrán generar automáticamente las clases de proceso a partir de los diagramas de casos de uso y la descripción de los requisitos funcionales, sistematizando el desarrollo de los diagramas de secuencia y los de estado.  Para la fase pruebas del sistema, se podrán generar completamente los casos de prueba a partir de la definición de los Requisitos Funcionales. Utilizando la metodología de MoDHE, un ingeniero del software, para construir un sistema software sanitario, realizaría las mismas fases que se han descrito anteriormente en el caso de NDT (EVS, DRS, DAS, DDS, Construcción, DPS, DMS), con la diferencia de que en la fase DRS, además de definir requisitos de información no sanitarios (y otros tipos de requisitos, como objetivos, actores, nuevas naturalezas, etc.), definiría requisitos de información sanitarios conformes a HL7. El siguiente diagrama (Figura 19) muestra gráficamente este proceso: Modelar requisitos sanitarios [proyecto no sanitario] [proyecto sanitario] Identificar, definir y validar documento HL7 CDA [modela documentos clínicos] [no modela documentos clínicos] Identificar, definir y validar mensajes HL7 v3 o HL7 v2.x [no modela intercambio de Información entre sistemas] Fase EVS Fase DRS Fase DAS Fase DDS Fase de Construcción Fase DPS Fase DMS Estudio de viabilidad Documento de requisitos Documento de análisis Documento de diseño Código fuente Documento de pruebas Documento de mantenimiento [modela intercambio de Información entre sistemas] Documento en formato HL7 CDA Mensaje en formato HL7 v3 o HL7 v2.x Fase DRS Modelar objetivos Modelar servicios Modelar requisitos de almacenamiento Modelar actores Modelar requisitos funcionales Modelar requisitos de Interacción Modelar requisitos no funcionales Modelar requisitos de almacenamiento Identificar, definir y validar requisitos de almacenamiento Identificar, definir y validar nuevas naturalezas Modelar requisitos sanitarios Figura 19. Modelado del ciclo de vida del software sanitario utilizando MoDHE 57 Por simplicidad, en la anterior figura (Figura 19) se ha representado el ciclo de vida siguiendo un modelo tradicional, pero con NDT es posible modelar el software siguiendo otros ciclos de vida, como iterativo, ágil, incremental, etc [Leau et al. 2012]. Nuevamente, la curva de aprendizaje del ingeniero del software que utiliza MoDHE por primera vez es mínima, ya que (al igual que NDT) la metodología de MoDHE propone utilizar notación UML para definir los modelos de todas las fases. Cabe destacar que, centrándonos en el modelado de requisitos sanitarios, no es obligatorio realizar el diseño de modelos según todos los 3 estándares de HL7, los estándares a utilizar dependerán del escenario concreto. Cuando el usuario ejecuta la actividad ‘Identificar, definir y validar mensajes HL7 v3 o HL7 v2.x’ debe decidir si utilizar el estándar HL7 v3 o utilizar el estándar HL7 v2.x. En el siguiente apartado se profundiza sobre estas 2 alternativas. 3.1. HL7 v3 frente a HL7 v2.x. Tal y como se ha comentado anteriormente, cuando el usuario ejecuta la actividad ‘Identificar, definir y validar mensajes HL7 v3 o HL7 v2.x’ debe decidir si utilizar el estándar HL7 v3 o utilizar el estándar HL7 v2.x. Esta decisión no se ha incluido en el diagrama de actividades representado en la Figura 19 por no complejizar el diagrama. Ambos estándares tienen un objetivo común: modelar mensajes para el intercambio de información entre sistemas sanitarios. El estándar HL7 v2.x es ampliamente utilizado. En cambio, el estándar HL7 v3 no ha conseguido una adopción a gran escala. En cualquier caso, un ingeniero del software para decidir si utilizar el estándar HL7 v3, debe revisar las siguientes cuestiones [Shaver 2012]:  ¿Se está diseñando una aplicación con requisitos legales? El ingeniero del software debe valorar si el software a desarrollar presenta restricciones desde el punto de vista ético y legal.  ¿Se está diseñando un entorno de comunicaciones nuevo, en el cual el estándar HL7 v2.x nunca ha sido utilizado? El ingeniero del software debe valorar si el marco de mensajería sobre el que va a construir el software utiliza previamente el estándar HL7 v2.x o no.  El equipo de gobierno del sistema sanitario donde se va a diseñar la aplicación, ¿ha solicitado que se enfoquen los esfuerzos en el uso del estándar HL7 v3? Si la petición de utilizar el estándar HL7 v3 viene desde niveles de gobernanza superiores, el ingeniero del software debe tenerlo en cuenta. 58 Si el usuario responde alguna de estas preguntas de forma afirmativa, debe utilizar el estándar HL7 v3. Por el contrario, si el usuario responde todas las preguntas de forma negativa, debe utilizar el estándar HL7 v2.x. 4. Conclusiones La metodología de MoDHE permite al ingeniero del software no conocedor de HL7 modelar la fase de ingeniería de requisitos del ciclo de vida del software sanitario utilizando elementos propios de UML, aplicando las pautas, recomendaciones y restricciones de los estándares de HL7. Es decir, gracias a la presente propuesta, un ingeniero del software sin conocimientos sobre HL7 puede resolver el problema de modelar sistemas sanitarios conformes a HL7. Al tomar como base la metodología NDT, la metodología de MoDHE cubre todo el ciclo de vida del software, incluso permite modelar requisitos no sanitarios en la fase de ingeniería de requisitos. Al implementar transformaciones entre los diferentes metamodelos de MoDHE (cada uno representando un estándar de HL7), la metodología de MoDHE permite reutilizar modelos ya creados en un estándar de HL7, cuando se estén modelando requisitos conforme a otro estándar de HL7, reutilizando la información, eliminando duplicidad, redundancia, y reduciendo errores. Los 2 siguientes capítulos (Capítulo V y Capítulo VI) detallan los metamodelos, restricciones y transformaciones que forman parte del marco de referencia MoDHE. A continuación, el Capítulo VII presenta la herramienta MoDHE Suite, herramienta CASE implementada en C# que da soporte a dicho marco de referencia. 59 Capítulo V. Metamodelos de MoDHE n el Capítulo IV se ha descrito en profundidad el proceso de la metodología de MoDHE. El presente capítulo presenta el lenguaje de modelado basado en HL7 (metamodelos de MoDHE) que se ha definido como parte de la metodología de MoDHE, para cubrir el modelado según los principales estándares de HL7 que cubren los requisitos de información. Los metamodelos de MoDHE forman parte de unos de los 3 pilares definidos en el Capítulo II, apartado 3, para centrar el marco de referencia. La siguiente figura (Figura 20) identifica el pilar en el que nos centramos en el presente capítulo, dentro del marco de referencia. Marco de referencia Lenguaje de modelado basado en HL7 Metodología Mecanismos de derivación Figura 20. Marco de referencia. Pilar ‘Lenguaje de modelado basado en HL7’ 1. Metamodelos de MoDHE Como se ha comentado anteriormente, en la presente Tesis Doctoral se cubren 3 de los principales estándares de HL7: HL7 v3, HL7 CDA y HL7 v2.x. El estándar HL7 v3 se ha cubierto en su totalidad. Los estándares HL7 CDA y HL7 v2.x no se han cubierto totalmente por considerarse un esfuerzo fuera del alcance de la presente Tesis Doctoral. El primer subapartado (subapartado 1.1) dentro del presente apartado, detalla exactamente las porciones cubiertas de los estándares HL7 CDA y HL7 v2.x. E 60 Seguidamente, en los subapartados 1.2, 1.3 y 1.4, se presentan los metamodelos de MoDHE que cubren cada uno de los estándares de HL7, posibilitando la creación de requisitos de información de un sistema de información sanitario basado en HL7. 1.1. Cobertura actual de MoDHE para cada estándar de HL7 Para cubrir el modelado de requisitos de información según los principales estándares de HL7, se han metamodelado los elementos y las restricciones correspondientes a los estándares HL7 v3, HL7 CDA y HL7 v2.x (si el lector desea conocer el detalle funcional de estos estándares, puede consultar el apartado 3.2.2 del Capítulo III). En el caso del estándar HL7 v3, el metamodelo de MoDHE v3 cubre el metamodelo de HL7 v3 completamente, ya que presenta una extensión razonable para el alcance de la presente Tesis Doctoral. En cambio, en el caso de los estándares HL7 CDA y HL7 v2.x, solo se ha cubierto un porcentaje del espectro completo de sus metamodelos (ver Tabla 10), por presentar una magnitud desproporcionada al alcance de esta memoria. La metodología de MoDHE se considera cubierta en su totalidad. El trabajo de campo correspondiente a la completitud de los estándares HL7 CDA y HL7 v2.x para ampliar el contexto de uso de la metodología, es un trabajo futuro que se puede articular como ampliaciones a la presente Tesis Doctoral (si el lector desea más información acerca de este mecanismo de ampliación futuro, puede consultar el apartado 3.1 del Capítulo IX). Más específicamente, la siguiente tabla (Tabla 10) muestra la proporción de entidades que cubre cada uno de los estándares, en relación con el total de entidades que presentan dichos estándares. Tabla 10. Porcentaje de entidades que cubre MoDHE Estándar de HL7 Total que define el estándar Total que cubre MoDHE % de entidades cubiertas Tipos de datos Enumerados HL7 v3 39 39 100% 20 - HL7 CDA 85 12 14.12% 20 16 HL7 v2.x 143 3 2.10% 14 48 De cara a identificar una parte representativa de los estándares HL7 CDA y v2.x, se decidió cubrir la parte que modela la información demográfica del paciente. Esta información es una información común que aparece en la mayoría de los metamodelos de HL7, ya que los estándares de HL7 proponen una infraestructura centrada en el paciente. Por ejemplo, los datos demográficos de un paciente en cuestión, se representan haciendo uso de:  En el estándar HL7 CDA, a través de la clase Patient.  En el estándar HL7 v2.x, haciendo uso del segmento PID.  En el estándar HL7 v3, instanciando la clase Entity. 61 En concreto, los elementos de información cubiertos por MoDHE para cada estándar de HL7, son:  HL7 CDA: Se ha incluido el documento clínico ya que es la parte troncal de todos los modelos CDA. Se ha incluido el paciente, junto con todos los datos demográficos de éste. Se ha incluido de forma complementaria los actores que autentifican el documento, información que puede incluirse en un modelo CDA.  HL7 v2.x: Se han incluido los elementos de información correspondientes al segmento MSH (Message Header) por corresponder con el segmento de cabecera, parte común a todos los mensajes HL7. Se ha incluido el segmento que da soporte a los datos del paciente, en este caso se trata del segmento PID (Patient Identification). Adicionalmente, se ha incluido el segmento de control EVN (Event Type Segment) por ser obligatorio en el caso de querer definir un mensaje conteniendo datos de pacientes. El resto de elementos de información presentes en los estándares HL7 CDA y HL7 v2.x se consideran fuera del alcance de la presente Tesis Doctoral. A continuación, la Tabla 11 detalla estos elementos que, para cada estándar, quedan fuera del alcance. Tabla 11. Elementos de HL7 CDA y HL7 v2.x que quedan fuera del alcance Estándar de HL7 Tipo de elemento Elemento HL7 CDA Actores Autor Guardián Destinatario Codificador Participante Entidades asociadas Documento padre Evento Orden Consentimiento Episodio clínico Componentes Estructuradas No estructuradas Secciones Observaciones Región de interés Medios Administración de medicamentos Suministros Procedimientos Actos 62 Complementos externos Actos externos Observaciones externas Documentos externos Procedimientos externos HL7 v2.x Gestión informática Puntos de continuación Tratamiento de errores Ficheros Aceptaciones Credenciales Software Ficheros maestros Soporte de aplicaciones Administración Gestión financiera Agendas Derivaciones Consultas Reclamaciones y rembolsos Gestión de materiales Gestión clínica Pruebas u órdenes Observaciones Problemas Estudios de laboratorio Personal sanitario Otros Notas Anexos 1.2. MoDHE v3 En este apartado se presenta el metamodelo que, como parte del marco de referencia MoDHE, cubre el estándar HL7 v3. Como se ha mencionado anteriormente, este metamodelo cubre en su totalidad el modelo de referencia que presenta este estándar. A continuación, las siguientes 3 figuras (Figura 21, Figura 22 y Figura 23) muestran una primera porción del metamodelo de MoDHE v3 que representa todas las entidades del modelo de referencia de HL7 v3, y aquellos tipos de datos que se relacionan con entidades para habilitar campos múltiples. Posteriormente, las figuras Figura 24 y Figura 25, muestran el resto del metamodelo de MoDHE v3 que representa los tipos de datos y los valores enumerados, cubriendo así el metamodelo completo de HL7 v3. Se ha considerado necesario presentar el metamodelo de MoDHE correspondiente al estándar HL7 v3 por vistas, para facilitar la legibilidad, teniendo en cuenta el gran número de entidades que presenta este modelo de referencia. La siguiente figura (Figura 21) muestra la porción del metamodelo MoDHE v3 que abarca conceptos relacionados con entidades. 63 Figura 21. Metamodelo de MoDHE v3, que corresponde al estándar HL7 v3. Entidades. Parte 1 En el Anexo B, apartado 1, el lector podrá encontrar el detalle de cada elemento del metamodelo de MoDHE v3, incluyendo una breve descripción, las relaciones de generalización que presenta, así como los atributos, asociaciones y restricciones. Dichas restricciones han sido modeladas en OCL. La siguiente figura (Figura 22) muestra la porción del metamodelo MoDHE v3 que abarca conceptos relacionados con roles y participaciones. pkg DRS - Requisitos de Almacenamiento «metaclass» II - assigningAuthorityName :string - displayable :string - extension :string - root :string «metaclass» AD - addressPart :ADXP - use :PostalAddressUse - useablePeriod :string «metaclass» TEL - use :TelecommunicationAddressUse - useableperiod :string - value :string «metaclass» EN - value :string - type :string «metaclass» Entity - classCode :CS - determinerCode :CS - code :CD - quantity :PQ - desc :ED - statusCode :CS «metaclass» LivingSubject - administrativeGenderCode :CD - birthTime :TS - deceasedInd :boolean - deceasedTime :TS - multipleBirthInd :boolean - multipleBirthOrderNumber :INT - organDonorInd :boolean «metaclass» Person - maritalStatusCode :CD - educationLevelCode :CD - livingArrangementCode :CD - religiousAffiliationCode :CD «metaclass» Organization - standardIndustryClassCode :CD «metaclass» Place - mobileInd :boolean - addr :AD - directionsText :ED - positionText :ED - gpsText :string «metaclass» NonPersonLivingSubject - straingText :ED - genderStatusCode :CD «metaclass» Material - formCode :CD «metaclass» ManufacturedMaterial - lotNumberText :string «metaclass» Container - capacityQuantity :PQ - heightQuantity :PQ - diameterQuantity :PQ - capTypeCode :CD - separatorTypeCode :CD - barrierDeltaQuantity :PQ - bottomDeltaQuantity :PQ «metaclass» Device - manufacturerModelName :CS - softwareName :CS - localRemoteControlStateCode :CD - alertLevelCode :CD - lastCalibrationTime :CD «metaclass» TS - value :date «metaclass» CD - code :string - codeSystem :string - codeSystemName :string - codeSystemVersion :string - displayName :string - originalText :string - translation :string - qualifier :string «metaclass» LanguageCommunication - languageCode :CD - modeCode :CD - proficiencyLevelCode :CD - preferenceInd :boolean «disabilityCode» 0..* «raceCode» 0..* «ethnicGroupCode» 0..* «expirationTime» 0..2 1 0..* «addr» 0..* «addr» 0..* «stabilityTime» 0..2 «id» 0..* «name» 0..* «existenceTime» 0..2 «telecom» 0..* «riskCode» 0..* «handlingCode» 0..* 70 1.4. MoDHE v2.x En este apartado se presenta el metamodelo modelado como parte del marco de referencia MoDHE para cubrir el estándar HL7 v2.x. Este metamodelo cubre –tal y como se indicó en la Tabla 10- un 2.1% el modelo de referencia que presenta este estándar. El modelado de este estándar de HL7 ha supuesto un esfuerzo adicional ya que, en este caso, este estándar no se sustenta sobre un modelo de referencia definido gráficamente. Este estándar se define de modo textual a lo largo de 28 extensos documentos PDF, alguno de estos con cientos de páginas [ANSI/HL7 2011]. A continuación, la siguiente figura (Figura 29) muestra una primera porción del metamodelo de MoDHE v2.x representando todas las entidades del modelo de referencia, y aquellos tipos de datos que se relacionan con entidades para habilitar campos múltiples. Figura 29. Metamodelo de MoDHE v2.x, que corresponde al estándar HL7 v2.x. Entidades En el Anexo B, apartado 3, el lector podrá encontrar el detalle de cada elemento del metamodelo de MoDHE v2.x, incluyendo una breve descripción, las relaciones de generalización que presenta, así como los atributos, asociaciones y restricciones. Dichas restricciones han sido modeladas en OCL. pkg DRS - Requisitos de Almacenamiento «metaclass» Message_v2-7 «metaclass» SegmentMSH - SegmentID :string = MSH - FieldSeparator :string - EncodingCharacters :string = ^~\& - SendingApplication :HD - SendingFacility :HD - ReceivingApplication :HD - ReceivingFacility :HD - DateTimeOfMessage :date - Security :string - MessageType :MSG - MessageControlID :string - ProcessingID :PT - VersionID :VID - SequenceNumber :double - ContinuationPointer :string - AcceptAcknowledgmentType :0155 - Accept/Application Acknowledgment Conditions - ApplicationAcknowledgmentType :0155 - Accept/Application Acknowledgment Conditions - CountryCode :0399 - ISO-3166 - PrincipalLanguageOfMessage :CWE - AlternateCharacterSetHandlingScheme :0356 - Alternate Character Set Handling Scheme - SendingResponsibleOrganization :XON - ReceivingResponsibleOrganization :XON - SendingNetworkAddress :HD - ReceivingNetworkAddress :HD «metaclass» SegmentEVN - SegmentID :string = EVN - EventTypeCode - RecordedDateTime :date - DateTimePlannedEvent :date - EventReasonCode :CWE - EventOccurred :date - EventFacility :HD «metaclass» SegmentPID - SegmentID :string = PID - SetID-PID :int - PatientID - AlternatePatientID-PID - DateTimeOfBirth :date - AdministrativeSex :CWE - PatientAlias - CountyCode - PrimaryLanguage :CWE - MaritalStatus :CWE - Religion :CWE - PatientAccountNumber :CX - SSNNumberPatient - DriversLicenseNumberPatient - BirthPlace :string - MultipleBirthIndicator :0136 - Yes/no Indicator - BirthOrder :double - VeteransMilitaryStatus :CWE - Nationality - PatientDeathDateAndTime :date - PatientDeathIndicator :0136 - Yes/no Indicator - IdentityUnknownIndicator :0136 - Yes/no Indicator - LastUpdateDateTime :date - LastUpdateFacility :HD - SpeciesCode :CWE - BreedCode :CWE - Strain :string «enumeration» 0211 - Alternate Character Sets ASCII 8859/1 8859/2 8859/3 8859/4 8859/5 (...) «metaclass» CWE - Identifier :string - Text :string - NameOfCodingSystem :0396 - Coding System - AlternateIdentifier :string - AlternateText :string - NameOfAlternateCodingSystem :0396 - Coding System - CodingSystemVersionID :string - AlternateCodingSystemVersionID :string - OriginalText :string - SecondAlternateIdentifier :string - SecondAlternateText :string - NameOfSecondAlternateCodingSystem :0396 - Coding System - SecondAlternateCodingSystemVersionID :string - CodingSystemOID :string - ValueSetOID :string - ValueSetVersionID :date - AlternateCodingSystemOID :string - AlternateValueSetOID :string - AlternateValueSetVersionID :date - SecondAlternateCodingSystemOID :string - SecondAlternateValueSetOID :string - SecondAlternateValueSetVersionID :date «metaclass» EI - EntityIdentifier :string - NamespaceID :0363 – Assigning Authority - UniversalID :string - UniversalIDType :0301 - Universal ID Type «metaclass» XCN - PersonIdentifier :string - FamilyName :FN - GivenName :string - SecondAndFurtherGivenNamesOrInitialsThereof :string - Suffix :string - Prefix :string - Degree - SourceTable :CWE - AssigningAuthority :HD - NameTypeCode :0200 - Name Type - IdentifierCheckDigit :string - CheckDigitScheme :0061 - Check Digit Scheme - IdentifierTypeCode :0203 - Identifier Type - AssigningFacility :HD - NameRepresentationCode :0465 - Name/Address Representation - NameContext :CWE - NameValidityRange - NameAssemblyOrder :0444 - Name Assembly Order - EffectiveDate :date - ExpirationDate :date - ProfessionalSuffix :string - AssigningJurisdiction :CWE - AssigningAgencyOrDepartment :CWE - SecurityCheck :string - SecurityCheckScheme :0904 - Security Check Scheme «metaclass» CX - IDNumber :string - IdentifierCheckDigit :string - CheckDigitScheme :0061 - Check Digit Scheme - AssigningAuthority :HD - IdentifierTypeCode :0203 - Identifier Type - AssigningFacility :HD - EffectiveDate :date - ExpirationDate :date - AssigningJurisdiction :CWE - AssigningAgencyOrDepartment :CWE - SecurityCheck :string - SecurityCheckScheme :0904 - Security Check Scheme «metaclass» XPN - FamilyName :FN - GivenName :string - SecondAndFurtherGivenNamesOrInitialsThereof :string - Suffix :string - Prefix :string - Degree - NameTypeCode :0200 - Name Type - NameRepresentationCode :0465 - Name/Address Representation - NameContext :CWE - NameValidityRange - NameAssemblyOrder :0444 - Name Assembly Order - EffectiveDate :date - ExpirationDate :date - ProfessionalSuffix :string - CalledBy :string «metaclass» XAD - StreetAddress :SAD - OtherDesignation :string - City :string - StateOrProvince :string - ZipOrPostalCode :string - Country :0399 - ISO-3166 - AddressType :0190 - Address Type - OtherGeographicDesignation :string - CountyParishCode :CWE - CensusTract :CWE - AddressRepresentationCode :0465 - Name/Address Representation - AddressValidityRange - EffectiveDate :date - ExpirationDate :date - ExpirationReason :CWE - TemporaryIndicator :0136 - Yes/no Indicator - BadAddressIndicator :0136 - Yes/no Indicator - AddressUsage :0617 - Address Usage - Addressee :string - Comment :string - PreferenceOrder :int - ProtectionCode :CWE - AddressIdentifier :EI «metaclass» XTN - TelephoneNumber - TelecommunicationUseCode :0201 - Telecommunication Use Code - TelecommunicationEquipmentType :0202 - Telecommunication Equipment Type - CommunicationAddress :string - CountryCode :string - AreaCityCode :string - LocalNumber :string - Extension :string - AnyText :string - ExtensionPrefix :string - SpeedDialCode :string - UnformattedTelephoneNumber :string - EffectiveStartDate :date - ExpirationDate :date - ExpirationReason :CWE - ProtectionCode :CWE - SharedTelecommunicationIdentifier :EI - PreferenceOrder :int «segmentMSH» 1 «OperatorID» 0..* «PatientTelecommunicationInformation» 0..* «CharacterSet» 0..* «segmentPID» 1 «MothersMaidenName» 0..* «PatientName» 1..* «PatientIdentifierList» 1..* «MothersIdentifier» 0..* «PhoneNumberBusiness» 0..* «PhoneNumberHome» 0..* «PatientAddress» 0..* «Race» 0..* «TribalCitizenship» 0..* «segmentEVN» 1 «MessageProfileIdentifier» 0..* «ProductionClassCode» 0..2 «IdentityReliabilityCode» 0..* «Citizenship» 0..* «EthnicGroup» 0..* 71 Aparecen campos sin tipo, como EventTypeCode en SegmentEVN. Esto ocurre porque en el propio estándar están creados sin tipo. Se trata de campos obsoletos. El hecho de mantener el campo sin tipo es un modo de mantener la compatibilidad hacia atrás, según el propio estándar: ‘retained for backward compatibility’ [ANSI/HL7 2011]. La siguiente figura (Figura 30) muestra la porción del metamodelo MoDHE v2.x que representa los tipos de datos que no tienen relación con ninguna otra entidad del metamodelo de MoDHE v2.x por no existir ningún campo múltiple de ese tipo de datos (sí existen campos sin multiplicidad de estos tipos, por eso es necesario incluirlos en el metamodelo). Figura 30. Metamodelo de MoDHE v2.x, que corresponde al estándar HL7 v2.x. Tipos de datos En el Anexo B, apartado 3, el lector podrá encontrar el detalle de cada elemento del metamodelo de MoDHE v2.x. pkg DRS - Requisitos de Almacenamiento «metaclass» HD - NamespaceID :0300 - Namespace ID - UniversalID :string - UniversalIDType :0301 - Universal ID Type «metaclass» MSG - MessageCode :0076 - Message Type - TriggerEvent :0003 - Event Type - MessageStructure :0354 - Message Structure «metaclass» PT - ProcessingID :0103 - Processing ID - ProcessingMode :0207 - Processing Mode «metaclass» VID - InternationalizationCode :CWE - VersionID :0104 - Version ID - InternationalVersionID :CWE «metaclass» XON - OrganizationName :string - OrganizationNameTypeCode :CWE - IDNumber :string - IdentifierCheckDigit :double - CheckDigitScheme :0061 - Check Digit Scheme - AssigningAuthority :HD - IdentifierTypeCode :0203 - Identifier Type - AssigningFacility :HD - NameRepresentationCode :0465 - Name/Address Representation - OrganizationIdentifier :string «metaclass» FN - Surname :string - OwnSurnamePrefix :string - OwnSurname :string - SurnamePrefixFromPartnerSpouse :string - SurnameFromPartnerSpouse :string «metaclass» SAD - StreetOrMailingAddress :string - StreetName :string - DwellingNumber :string 72 Por último, la siguiente figura (Figura 31) muestra la porción del metamodelo MoDHE v2.x que representa los valores enumerados. Figura 31. Metamodelo de MoDHE v2.x, que corresponde al estándar HL7 v2.x. Enumerados En el Anexo B, apartado 3, el lector podrá encontrar el detalle de cada elemento del metamodelo de MoDHE v2.x. pkg DRS - Requisitos de Almacenamiento «enumeration» 0361 - Application User-defined Table. No suggested values defined «enumeration» 0362 - Facility User-defined Table. No suggested values defined «enumeration» 0155 - Accept/Application Acknowledgment Conditions Always Never Error/reject conditions only Successful completion only «enumeration» 0399 - ISO-3166 en es fr de (...) «enumeration» 0356 - Alternate Character Set Handling Scheme ISO 2022-1994 2.3 <null> «enumeration» 0300 - Namespace ID User-defined Table. No suggested values defined «enumeration» 0301 - Universal ID Type DNS EUI64 CLIA CLIP GUID (...) «enumeration» 0076 - Message Type ACK ADR ADT BAR (...) «enumeration» 0003 - Event Type A01 A02 A03 A04 A05 A06 (...) «enumeration» 0354 - Message Structure ACK ADR_A19 ADT_A01 ADT_A02 (...) «enumeration» 0103 - Processing ID Debugging Production Training «enumeration» 0207 - Processing Mode Archive Restore from archive Initial load Current processing, transmitted at intervals (scheduled or on demand) Not present (the default, meaning current processing) «enumeration» 0104 - Version ID 2.0 2.0D 2.1 2.2 2.3 2.3.1 2.4 2.5 2.5.1 2.6 2.7 «enumeration» 0396 - Coding System Local general code American College of Radiology finding codes German Alpha-ID v2006 (...) «enumeration» 0363 – Assigning Authority User-defined Table. No suggested values defined «enumeration» 0061 - Check Digit Scheme Bank Card Validation Number Check digit algorithm in the US National Provider Identifier ISO 7064: 1983 Mod 10 algorithm Mod 11 algorithm «enumeration» 0203 - Identifier Type Accession ID American Express American Medical Association Number (...) «enumeration» 0465 - Name/Address Representation Ideographic Alphabetic Phonetic «enumeration» 0062 - Event Reason Patient request Physician/health practitioner order Census management Other Unknown «enumeration» 0188 - Operator ID User-defined Table. No suggested values defined «enumeration» 0200 - Name Type Customary Name OfficialRegistryName TemporaryName NewbornName Assigned Pseudonym (...) «enumeration» 0444 - Name Assembly Order Prefix Given Middle Family Suffix Prefix Family Middle Given Suffix «enumeration» 0904 - Security Check Scheme Bank Card Validation Number Credit Card Security code Version ID «enumeration» 0136 - Yes/no Indicator Yes No «enumeration» 0190 - Address Type Bad address Billing Address Birth (nee) (birth address, not otherwise specified) Birth delivery location (...) «enumeration» 0617 - Address Usage Mailing Visit Classification «enumeration» 0201 - Telecommunication Use Code Primary Residence Number Other Residence Number Work Number Vacation Home Number Answering Service Number Emergency Number Network (email) Address Beeper Number Personal «enumeration» 0202 - Telecommunication Equipment Type Telephone Fax Modem Cellular or Mobile Phone Satellite Phone Beeper Internet Address X.400 email address Telecommunications Device for the Deaf Teletypewriter «enumeration» 0001 - Administrative Sex Female Male Other Unknown Ambiguous Not applicable «enumeration» 0005 - Race American Indian or Alaska Native Asian Black or African American Native Hawaiian or Other Pacific Islander White Other Race «enumeration» 0296 – Primary Language User-defined Table. No suggested values defined «enumeration» 0002 - Marital Status Separated Divorced Married Single Widowed Common law Living together Domestic partner Registered domestic partner Legally Separated Annulled Interlocutory Unmarried Unknown Other Unreported «enumeration» 0006 - Religion Agnostic Atheist Baha'i Brethren Buddhist (...) «enumeration» 0189 - Ethnic Group Hispanic or Latino Not Hispanic or Latino Unknown «enumeration» 0171 - Citizenship User-defined Table. No suggested values defined «enumeration» 0172 - Veterans Military Status User-defined Table. No suggested values defined «enumeration» 0445 - Identity Reliability Code Unknown/Default Social Security Number Unknown/Default Date of Birth Unknown/Default Address Patient/Person Name is an Alias «enumeration» 0446 - Species Code User-defined Table. No suggested values defined «enumeration» 0447 - Breed Code User-defined Table. No suggested values defined «enumeration» 0429 - Production Class Code Breeding/genetic stock Dairy Draft Dual Purpose Layer, Includes Multiplier flocks Meat Other Pleasure Racing Show Not Applicable Unknown «enumeration» 0297 - CN ID Source User-defined Table. No suggested values defined «enumeration» 0448 - Name Context User-defined Table. No suggested values defined «enumeration» 0204 - Organizational Name Type Alias name Legal name Display name Stock exchange listing name «enumeration» 0289 - County/Parish User-defined Table. No suggested values defined «enumeration» 0288 - Census Tract User-defined Table. No suggested values defined «enumeration» 0616 - Address Expiration Reason Moved Added in error On request Corrected «enumeration» 0868 - Telecommunication Expiration Reason Moved Added in error On request Corrected No longer in service «enumeration» 0618 - Protection Code Listed Unlisted (Should not appear in directories) Unpublished 73 2. Conclusiones A lo largo de este capítulo, se ha definido formalmente el lenguaje de modelado que forma parte del marco de referencia MoDHE, cuyo objetivo es el de gestionar el ciclo de vida del software sanitario basado en HL7 desde la perspectiva del paradigma MDE. Si el lector desea conocer el detalle de los elementos incluidos en dicho lenguaje de modelado, puede consultar el Anexo B. A raíz de esta sintaxis abstracta de MoDHE, se ha definido una sintaxis concreta. Para ello, se han utilizado perfiles UML con el objetivo de definir nuevos conceptos a partir de constructores ya existentes en UML, consiguiendo así una semántica más precisa y concreta que sea capaz de modelar toda la riqueza existente en los estándares de HL7. A partir de cada metaclase definida en los metamodelos de MoDHE, se define un estereotipo en el perfil UML, que extiende una metaclase de UML, en concreto todos los estereotipos del perfil UML de MoDHE extienden la metaclase Class de UML. Esto implica que todos los modelos de MoDHE se diseñen usando la misma notación visual que usan las clases de UML. El lector puede encontrar más información acerca del perfil UML de MoDHE en el apartado 2 del Capítulo VII, capítulo donde se detallan los aspectos más relevantes de la herramienta MoDHE Suite, herramienta creada para dar soporte práctico al marco de referencia MoDHE. El siguiente capítulo (Capítulo VI) define formalmente el último pilar del marco de referencia definido: las transformaciones. 74 75 Capítulo VI. Mecanismos de derivación n el Capítulo II, apartado 3, se definió el marco de referencia MoDHE sobre el que se ha trabajado en la presente Tesis Doctoral, formado por 3 pilares: metodología, lenguaje de modelado basado en HL7, y mecanismos de derivación. El Capítulo IV describe la metodología de MoDHE (fases, actividades y modelos), primer pilar del marco de referencia. El Capítulo V describe el lenguaje de modelado basado en HL7 desarrollado en la presente Tesis Doctoral (metamodelos de MoDHE), segundo pilar del marco de referencia. El presente capítulo presenta los mecanismos de derivación utilizados para: (i) Relacionar metamodelo source con metamodelo target (apartado 1). (ii) Automatizar transformaciones entre diferentes modelos de MoDHE (apartado 2). Una vez desarrollado este tercer pilar del marco de referencia, se consideran cubiertos todos los elementos necesarios para realizar un modelado según los principales estándares de HL7 que cubren los requisitos de información, gracias al marco de referencia MoDHE. La siguiente figura (Figura 32Figura 11) identifica el pilar en el que nos centramos en el presente capítulo, dentro del marco de referencia. Marco de referencia Lenguaje de modelado basado en HL7 Metodología Mecanismos de derivación Figura 32. Marco de referencia. Pilar ‘Mecanismos’ Tomando como base la definición formal de la propuesta representada en el Capítulo III, este apartado se centra en la parte del marco de referencia MoDHE correspondiente a los E 76 mecanismos de derivación que hacen posible transformar modelos de un metamodelo a otro, ya sea entre un metamodelo de HL7 y un metamodelo de MoDHE (a través de relaciones 1 a 1), como entre diferentes modelos de MoDHE (a través de transformaciones). La siguiente figura (Figura 33) refleja la parte de la propuesta sobre la que se profundiza en el presente capítulo, marcando en azul los mecanismos de derivación entre metamodelos de HL7 y de MoDHE (relaciones 1 a 1), y en morado los mecanismos de derivación entre diferentes partes del metamodelo de MoDHE (transformaciones). Metamodelo HL7 Metamodelo UML Metamodelos estándares HL7 extiende Metamodelos NDT extiende Metamodelos MoDHE extiende HL7 v3 HL7 CDA HL7 v2.x RA MoDHE v3 MoDHE CDA MoDHE v2.x Diagrama de clases Transformaciones Figura 33. Definición formal de la propuesta. Parte mecanismos de derivación 1. Derivación de los metamodelos de HL7 a los metamodelos de MoDHE. Relaciones 1 a 1 Los metamodelos de MoDHE son una extensión de los metamodelos de HL7. Para crear cada metamodelo de MoDHE, se ha ido estudiando cada metamodelo de HL7, y se han ido modelando elementos con una relación 1-1. 2. Derivación de un metamodelo de MoDHE a otro metamodelo de MoDHE. Transformaciones Teniendo en cuenta que los estándares HL7 v3, HL7 CDA, HL7 v2.x presentan la característica común de que cubren la definición de requisitos de información de un 77 sistema sanitario, se identifican elementos comunes en dichos estándares. Estos elementos comunes permiten que se puedan definir transformaciones sencillas entre entidades de un estándar y otro, permitiendo así crear parcialmente la estructura del modelo basado en un estándar tomando como entrada el modelo basado en otro estándar. El proceso sistemático de obtención de un modelo MoDHE derivado desde otro modelo MoDHE debe contemplar qué información se va a tomar desde el modelo source, cómo se va a transformar esa información, qué dependencias existen entre elementos de información, y qué información se genera en el modelo target. Es decir, se debe clarificar cómo se puede definir un modelo target a partir de un modelo source específico, así como el grado de automatización que se puede aplicar al proceso. En este capítulo, basándose en la definición formal de los metamodelos que se ha realizado en el capítulo anterior (Capítulo V), se estudian y se formalizan las relaciones semánticas que se establecen, mediante las cuales se puede conseguir el modelo target a raíz de un modelo source específico. Este proceso, teniendo en cuenta dichas relaciones semánticas, establece un mecanismo de transformación basado en reglas para obtener el modelo final. Gracias a dicho proceso de transformación, se establece una trazabilidad entre ambos metamodelos, permitiendo automatizar el desarrollo, así como mejorar la calidad y consistencia de los modelos. Por ejemplo: si el usuario ha modelado un modelo según el metamodelo de MoDHE v2.x, puede generar automáticamente parte del modelo MoDHE CDA con la misma información anteriormente modelada según el metamodelo de MoDHE v2.x. En el presente apartado, se especifica formalmente el proceso sistemático para obtener modelos MoDHE a partir de otro modelo MoDHE. Para ello, es necesario definir el conjunto de reglas de derivación entre modelos que permitan sistematizar este proceso. Estas reglas son especificadas con el lenguaje estándar QVT [OMG 2015b], y comúnmente conocidas como reglas “model-to-model” (M2M). En la presente Tesis Doctoral se ha optado por utilizar QVT frente a otros lenguajes de transformaciones como ATL (Atlas Transformation Language) 40 porque la propuesta presentada en la presente Tesis Doctoral se plantea como una extensión de la metodología NDT, que usan especificaciones de transformaciones en QVT, por tanto al utilizar QVT mejorará la compatibilidad entre ambos conjuntos de transformaciones (los propios de NDT, y los propios de MoDHE). 40 https://eclipse.org/atl/ 78 2.1. El lenguaje QVT El lenguaje QVT [OMG 2015b] es un lenguaje estándar propuesto por la OMG para la definición de transformaciones M2M. Este lenguaje nace a finales de 2005 como propuesta común de varias instituciones de investigación y empresas. Para la definición de la estructura y sintaxis de los metamodelos, este lenguaje se basa en las especificaciones de los estándares MOF [OMG 2015a] y OCL [OMG 2014] propuestos por la OMG. El lenguaje QVT define 3 abstracciones fundamentales:  Consultas (Query): Expresión que se evalúa sobre el modelo origen –instancia del metamodelo origen-, resultando una o varias instancias de tipos (del modelo fuente o en el lenguaje de consulta).  Vistas (View): Modelo obtenido a partir de otro modelo base.  Transformaciones (Transformation): Operación que, proyectando los resultados de las consultas sobre una vista, genera un modelo destino a partir de un modelo origen. QVT es un lenguaje declarativo e imperativo a la vez. Está compuesto por 3 sublenguajes específicos de dominio:  Relaciones (Relations): Lenguaje declarativo que representa el conjunto de relaciones que deben existir entre los modelos origen y destino. Estas relaciones se definen por 2 o más dominios, unas precondiciones y unas postcondiciones. Un dominio es un elemento de un tipo específico el cual podemos encontrar en el modelo. Una transformación puede ser de 2 tipos “ckeckonly” (solo chequea la consistencia) o “enforced” (modifica el modelo destino).  Núcleo (Core): Lenguaje declarativo tan potente como el lenguaje de relaciones, pero a diferencia de éste, no utiliza patrones. Su semántica se define de forma más simple.  Mapeos (Operational Mappings): Conocido como QVTo, este lenguaje es un lenguaje imperativo que extiende los lenguajes de relaciones y núcleo. Su sintaxis es similar a otros lenguajes imperativos como Java. A diferencia de los lenguajes declarativos, este lenguaje es unidireccional, es decir, existirá un solo modelo origen y uno o varios modelos destinos. Define operaciones que implementan una transformación completa o una parte de ésta. De los 3 sublenguajes que componen QVT, el lenguaje imperativo QVTo es la opción elegida porque existen herramientas más potentes para trabajar con él, está mejor documentado y presenta una comunidad de usuarios más grande. 2.2. Contexto y planteamiento previo Antes de definir formalmente las reglas de transformación QVT para derivar elementos, resulta necesario establecer cuál es la correspondencia identificada entre elementos de cada metamodelos. 79 A continuación, la Tabla 12 muestra el listado de elementos comunes identificados en los estándares para la creación de requisitos de información de un sistema de información sanitario basado en HL7. Se trata de elementos relacionados con los datos demográficos de los pacientes. Tabla 12. Correspondencia entre elementos de los metamodelos en estudio HL7 CDA HL7 v2.x HL7 v3 Descripción del campo ClinicalDocument.RecordTarg et.PatientRole.id.extension Message_v2- 7.SegmentPID.PatientIde ntifierList.IDNumber Entity.id Identificador del paciente ClinicalDocument.RecordTarg et.PatientRole.Patient.name.n amePart.name [name.entityPartName = "GIV"] Message_v2- 7.SegmentPID.PatientNa me.GivenName Entity.name.valu e [name.type = "GIV"] Nombre del paciente ClinicalDocument.RecordTarg et.PatientRole.Patient.name.n amePart.name [name.entityPartName = "FAM"] Message_v2- 7.SegmentPID.PatientNa me.FamilyName.Surname Entity.name.valu e [name.type = "FAM"] Apellido del paciente ClinicalDocument.RecordTarg et.PatientRole.Patient.birthTi me Message_v2- 7.SegmentPID.DateTime OfBirth Entity.LivingSubj ect.birthTime Fecha de nacimiento del paciente ClinicalDocument.RecordTarg et.PatientRole.Patient.adminis trativeGenderCode Message_v2- 7.SegmentPID.Administr ativeSex Entity.LivingSubj ect.administrativ eGenderCode Sexo del paciente ClinicalDocument.RecordTarg et.PatientRole.Patient.raceCo de Message_v2- 7.SegmentPID.Race Entity.LivingSubj ect.Person.raceC ode Raza del paciente ClinicalDocument.RecordTarg et.PatientRole.addr.addressPa rt.city [addr.use = "H"] Message_v2- 7.SegmentPID.PatientAd dress.City Entity.LivingSubj ect.Person.addr.a ddressPart.city Ciudad de la dirección del paciente ClinicalDocument.RecordTarg et.PatientRole.addr.addressPa rt.postalCode [addr.use = "H"] Message_v2- 7.SegmentPID.PatientAd dress.ZipOrPostalCode Entity.LivingSubj ect.Person.addr.a ddressPart.posta lCode Código postal de la dirección del paciente ClinicalDocument.RecordTarg et.PatientRole.addr.addressPa rt.country [addr.use = "H"] Message_v2- 7.SegmentPID.PatientAd dress.Country Entity.LivingSubj ect.Person.addr.a ddressPart.count ry País de la dirección del paciente ClinicalDocument.RecordTarg et.PatientRole.addr.addressPa rt.streetName [addr.use = "H"] Message_v2- 7.SegmentPID.PatientAd dress.StreetAddress.Stre etName Entity.LivingSubj ect.Person.addr.a ddressPart.street Name Calle de la dirección del paciente ClinicalDocument.RecordTarg et.PatientRole.telecom.value [telecom.use = "H"] Message_v2- 7.SegmentPID.PhoneNu mberHome.LocalNumber Entity.telecom.va lue [telecom.use = "H"] Teléfono de casa del paciente ClinicalDocument.RecordTarg et.PatientRole.telecom.value [telecom.use = "WP"] Message_v2- 7.SegmentPID.PhoneNu mberBusiness.LocalNum Entity.telecom.va lue [telecom.use = "WP"] Teléfono del trabajo del paciente 86 Expresión 9. Transformación para derivar el modelo MoDHE v2.x desde el modelo MoDHE v3 transformation MoDHE-v3_MoDHE-v2x_M2M (in source:MoDHECDAv3Metamodel, out target:MoDHEv2xMetamodel) { main() { /* Se define el conjunto de propiedades que actúan como identificadores unívocos del nuevo objeto. */ key MoDHEv2x_Messagev27 (id); key MoDHEv2x_SegmentPID (id); // Se realizan las llamadas a las funciones de mapeo. source.objectsOfType(Entity)  map tov2xSegmentPID1(); source.objectsOfType(LivingSubject)  map tov2xSegmentPID2(); source.objectsOfType(Person)  map tov2xSegmentPID3(); source.rootObjects()[Entity]  map toMessagev27(); } } Una vez definidos el conjunto de propiedades que serán los identificadores unívocos del objeto destino, se realizan una serie de llamadas a funciones de mapeo que se describen en el siguiente subapartado. Entre estas llamadas, se debe destacar la función de mapeo que permite transformar el «Entity», elemento raíz del metamodelo de entrada. Esta transformación del elemento raíz se obtiene mediante la instrucción «rootObjects» de QVT. Esta función, cuyo objetivo es generar el elemento raíz «Messagev27» del metamodelo destino MoDHE v2.x, recibe el nombre de «toMessagev27». A continuación, los siguientes subapartados describen de manera concreta todas las reglas de mapeo que conforman el protocolo de derivación del modelo MoDHE v2.x a partir del modelo MoDHE v3. 2.5.1. Especificación del mapeo de las metaclases «Entity», «LivingSubject» y «Person» Para especificar las reglas de mapeo se utiliza la directiva «mapping» de QVT. La siguiente expresión describe cómo derivar cada «Messagev27», elemento raíz del modelo MoDHE v2.x, a partir de un «Entity», elemento raíz del modelo MoDHE v3. En primer lugar, la Expresión 10 inicializa el nuevo elemento «Messagev27». En segundo lugar, las expresiones Expresión 11, Expresión 12 y Expresión 13 generan todos los elementos que componen el modelo MoDHE v2.x a raíz de los elementos que componen el modelo MoDHE v3. 87 Expresión 10. Mapeo QVT de la metaclase «Entity» a «Messagev27» mapping MoDHEv3Metamodel::Entity:: toMessagev27 : MoDHEv2xMetamodel:: Messagev27 { /* Sin instrucciones de mapeo. */ } Expresión 11. Mapeo QVT de la metaclase «Entity» a «SegmentPID» mapping MoDHEv3Metamodel::Entity::tov2xSegmentPID1: MoDHEv2xMetamodel::SegmentPID { /* Se transforma cada elemento relacionado con MoDHE v3 con el homólogo dentro del modelo de MoDHE v2.x. */ PatientIdentifierList.IDNumber = self.id; if (self.name.type == ‘GIV’) then { PatientName.GivenName = self.name.value; } else if (self.name.type == ‘FAM’) then { PatientName.FamilyName.Surname = self.name.value; } if (self.telecom.use == ‘H’) then { PhoneNumberHome.LocalNumber = self.telecom.value; } else if (self.telecom.use == ‘WP’) then { PhoneNumberBusiness.LocalNumber = self.telecom.value; } } Expresión 12. Mapeo QVT de la metaclase «LivingSubject» a «SegmentPID» mapping MoDHEv3Metamodel::LivingSubject::tov2xSegmentPID2: MoDHEv2xMetamodel::SegmentPID { /* Se transforma cada elemento relacionado con MoDHE v3 con el homólogo dentro del modelo de MoDHE v2.x. */ DateTimeOfBirth = self.birthTime; AdministrativeSex = self.administrativeGenderCode; } 88 Expresión 13. Mapeo QVT de la metaclase «Person» a «SegmentPID» mapping MoDHEv3Metamodel::Person::tov2xSegmentPID2: MoDHEv2xMetamodel::SegmentPID { /* Se transforma cada elemento relacionado con MoDHE v3 con el homólogo dentro del modelo de MoDHE v2.x. */ Race = self.raceCode; PatientAddress.City = self.addr.addressPart.city; PatientAddress.ZipOrPostalCode = self.addr.addressPart.postalCode; PatientAddress.Country = self.addr.addressPart.country; PatientAddress.StreetAddress.StreetName = self.addr.addressPart.streetName; MaritalStatus = self.maritalStatusCode; Religion = self.religiousAffiliatinoCode; EthnicGroup = self.ethnicGroupCode; } 2.6. Especificación de la transformación MoDHE-v2x_MoDHE-v3_M2M Esta sección detalla la transformación que convierte un modelo creado siguiendo el metamodelo de MoDHE v2.x en un modelo conforme al metamodelo de MoDHE v3, representada por el término MoDHE-v2x_MoDHE-v3_M2M. Dicha transformación toma como entrada los elementos identificados en el metamodelo de MoDHE v2.x y genera todos los elementos necesarios para construir un modelo HL7 conforme al metamodelo de MoDHE v3. Es decir, en este caso el metamodelo source es el metamodelo de MoDHE v2.x, y el metamodelo target es el metamodelo de MoDHE v3. La Expresión 14 se inicia mediante la directiva «transformation» de QVT formando la cabecera de la transformación. La transformación toma como entrada un modelo conforme a MoDHE v2.x indicado mediante la directiva «in», y genera como salida un modelo conforme a MoDHE v3 indicado mediante la directiva «out». Para definir el cuerpo principal se utiliza la directiva «main». Dentro de dicho cuerpo principal, mediante la directiva «key», se definen el conjunto de propiedades que actúan como identificadores unívocos del nuevo objeto destino. 89 Expresión 14. Transformación para derivar el modelo MoDHE v3 desde el modelo MoDHE v2.x transformation MoDHE-v2x_MoDHE-v3_M2M (in source:MoDHECDAv2xMetamodel, out target:MoDHEv3Metamodel) { main() { /* Se define el conjunto de propiedades que actúan como identificadores unívocos del nuevo objeto. */ key MoDHEv3_Entity (id); key MoDHEv3_LivingSubject (id); key MoDHEv3_Person (id); // Se realizan las llamadas a las funciones de mapeo. source.objectsOfType(SegmentPID)  map tov3Entity(); source.objectsOfType(SegmentPID)  map tov3LivingSubject(); source.objectsOfType(SegmentPID)  map tov3Person(); source.rootObjects()[Messagev27]  map toEntity(); } } Una vez definidos el conjunto de propiedades que serán los identificadores unívocos del objeto destino, se realizan una serie de llamadas a funciones de mapeo que se describen en el siguiente subapartado. Es imprescindible tener en cuenta el orden de invocación de estas funciones de mapeo, ya que permite consultar elementos generados previamente. Entre estas llamadas, se debe destacar la función de mapeo que permite transformar el «Package», elemento raíz del metamodelo de entrada UML. Esta transformación del elemento raíz se obtiene mediante la instrucción «rootObjects» de QVT. Esta función, cuyo objetivo es generar el elemento raíz «Entity» del metamodelo destino MoDHE v3, recibe el nombre de «toEntity». A continuación, los siguientes subapartados describen de manera concreta todas las reglas de mapeo que conforman el protocolo de derivación del modelo MoDHE v3 a partir del modelo MoDHE v2.x. 2.6.1. Especificación del mapeo de las metaclases «Messagev27» y «SegmentPID» Para especificar las reglas de mapeo se utiliza la directiva «mapping» de QVT. La siguiente expresión describe cómo derivar cada «Entity», elemento raíz del modelo MoDHE v3, a partir de un «Messagev27», elemento raíz del modelo MoDHE v2.x. 90 En primer lugar, la Expresión 15 inicializa las propiedades del nuevo elemento «Entity». En segundo lugar, las expresiones Expresión 16, Expresión 17 y Expresión 18 generan todos los elementos que componen el modelo MoDHE v3 a raíz de los elementos que componen el modelo MoDHE v2.x. Expresión 15. Mapeo QVT de la metaclase « Messagev27» a «Entity» mapping MoDHEv2xMetamodel::Messagev27:: toEntity : MoDHEv3Metamodel:: Entity { /* Sin instrucciones de mapeo. */ } Expresión 16. Mapeo QVT de la metaclase «SegmentPID» a «Entity» mapping MoDHEv2xMetamodel::SegmentPID::tov3Entity: MoDHEv3Metamodel:: Entity { /* Se transforma cada elemento relacionado con MoDHE v2.x con el homólogo dentro del modelo de MoDHE v3. */ id = self.PatientIdentifierList.IDNumber; name[0].value = self.PatientName.GivenName; name[0].type = ‘GIV’; name[1].value = self.PatientName.FamilyName.Surname; name[1].type == ‘FAM’; telecom[0].value = self.PhoneNumberHome.LocalNumber; telecom[0].use = ‘H’; telecom[1].value = self.PhoneNumberBusiness.LocalNumber; telecom[1].use = ‘WP’; } Expresión 17. Mapeo QVT de la metaclase «SegmentPID» a «LivingSubject» mapping MoDHEv2xMetamodel:: SegmentPID::tov3LivingSubject: MoDHEv3Metamodel::LivingSubject { /* Se transforma cada elemento relacionado con MoDHE v2.x con el homólogo dentro del modelo de MoDHE v3. */ birthTime = self.DateTimeOfBirth; administrativeGenderCode = self.AdministrativeSex; } 91 Expresión 18. Mapeo QVT de la metaclase «SegmentPID» a «Person» mapping MoDHEv2xMetamodel::SegmentPID::tov3Person: MoDHEv3Metamodel:: Person { /* Se transforma cada elemento relacionado con MoDHE v2.x con el homólogo dentro del modelo de MoDHE v3. */ raceCode = self.Race; addr.addressPart.city = self.PatientAddress.City; addr.addressPart.postalCode = self.PatientAddress.ZipOrPostalCode; addr.addressPart.country = self.PatientAddress.Country; addr.addressPart.streetName = self.PatientAddress.StreetAddress.StreetName; maritalStatusCode = self.MaritalStatus; religiousAffiliatinoCode = self.Religion; ethnicGroupCode = self.EthnicGroup; } 3. Conclusiones Los 3 últimos capítulos (Capítulo IV, Capítulo V, Capítulo VI) han definido formalmente el marco de referencia basado en los siguientes 3 pilares que sustentan la presente propuesta:  La metodología de MoDHE fue detallada en el Capítulo IV.  El lenguaje de modelado basado en HL7 ha sido presentados en el Capítulo V, modelando los metamodelos y las restricciones.  Las transformaciones han sido presentadas en el presente capítulo. El siguiente capítulo muestra las características más importantes de la herramienta MoDHE Suite, implementada en C# como un plugin para Enterprise Architect, dando soporte al marco de referencia anteriormente descrito. 92 93 Capítulo VII. Herramienta MoDHE Suite os capítulos anteriores presentan el marco de referencia MoDHE, que permite diseñar modelos de dominio HL7 en base a UML, utilizando técnicas basadas en el paradigma MDE. Este marco de referencia está compuesto por la metodología y los metamodelos necesarios para realizar este diseño, así como las transformaciones necesarias para poder crear modelos tomando la información previamente modelada en otros modelos. Para hacer posible el uso práctico de este marco teórico que nos permite generar modelos UML conformes a HL7, es necesario disponer de una herramienta CASE de soporte. El presente capítulo detalla los aspectos más relevantes de dicha herramienta, a la que hemos llamado MoDHE Suite, la cual ha sido implementada en C# como un plugin para Enterprise Architect. El primer apartado del presente capítulo detalla algunas consideraciones que previamente se tuvieron en cuenta a la hora de modelar la sintaxis concreta de los metamodelos de MoDHE. El apartado 2 del presente capítulo describe la sintaxis concreta -basada en perfiles UML- a utilizar para los metamodelos descritos en el Capítulo V. Integrando la definición de la sintaxis concreta de los metamodelos, y la automatización de reglas de trasformación, obtenemos la herramienta MoDHE Suite. El apartado 3 describe los detalles más relevantes del diseño de dicha herramienta, que permite modelar sistemas de información sanitarios conforme a HL7, modelando con diagramas UML. Por último, el apartado 4 cierra el capítulo con unas breves conclusiones. 1. Planteamiento previo Antes de definir la sintaxis concreta de los metamodelos y comenzar a trabajar en la herramienta MoDHE Suite, se tuvieron en cuenta una serie de consideraciones, en relación a la herramienta de modelado a utilizar, y en relación al mecanismo a utilizar para modelar la sintaxis concreta. Estas consideraciones se describen a continuación. 1.1. Enterprise Architect como herramienta de modelado Para desarrollar la herramienta MoDHE Suite, en la presente Tesis Doctoral se ha utilizado como base EA, una herramienta de modelado ya existente que proporciona mecanismos de extensión a través de plugins. L 94 En un estudio comparativo realizado por el grupo IWT2 y la Consejería de Educación, Cultura y Deporte (actuales Consejería de Educación y Consejería de Cultura) [ITW2 et al. 2008] y con supervisión de la Consejería de Innovación, Ciencia y Empleo (actual Consejería de Empleo, Empresa y Comercio) de la Junta de Andalucía, se valoraron las siguientes 9 herramientas de modelado:  ArgoUML 41 , herramienta de software libre propuesta por Tigris 42 .  Poseidon for UML 43 , versión comercial de la herramienta ArgoUML.  StarUML 44 , herramienta de software libre propuesta por la compañía coreana MKLab.  Rational Rose 45 , herramienta de IBM para desarrollar sistemas modelando con UML.  Rational Software Modeler45, herramienta de IBM que sustituye a la anterior (Rational Rose).  Doors45, herramienta de IBM con capacidad para dar soporte a la especificación de requisitos.  Enterprise Architect (EA) 46 , herramienta de modelado propuesta por Sparx Systems 47 .  IRqA 48 , herramienta propuesta por Visure con capacidad para dar soporte a la especificación de requisitos.  NDT-Suite 49 , herramienta software libre de la Universidad de Sevilla que da soporte práctico a la metodología NDT. El esquema de caracterización utilizado para realizar el estudio comparativo, abarca las siguientes características: 41 http://argouml.tigris.org/ 42 http://www.tigris.org/ 43 http://www.gentleware.com/ 44 http://staruml.io/ 45 http://www-03.ibm.com/software/products/ 46 http://www.sparxsystems.com.au/products/ea/ 47 http://www.sparxsystems.com.au/ 48 http://www.visuresolutions.com/ 49 http://iwt2.org/actividad-grupo/investigacion/resultados/ndt/ndt-suite/ 95  Soporte a mecanismos de extensión de UML para poder definir perfiles UML.  Soporte a mecanismos para generar de forma sistemática modelos y código a partir de modelos.  Soporte para generar documentación de forma automática, personalizada y flexible.  Soporte para gestionar el ciclo de vida software de grandes proyectos.  Soporte para gestionar de manera completa el ciclo de vida software teniendo cuenta las fases de: estudio de viabilidad, captura de requisitos, análisis, diseño, implementación, pruebas y mantenimiento.  Compatibilidad con UML. Este estudio concluye que EA es la herramienta de modelado que más se adecua a las necesidades de la Consejería de la Junta de Andalucía con una mejor relación calidad/precio. En la presente Tesis Doctoral se ha decidido utilizar EA por esta razón, así como porque esta herramienta de modelado es ampliamente conocida por las empresas y organizaciones en las que MoDHE Suite podrá ser validada y evaluada una vez puesta a punto. 1.2. Perfiles UML como mecanismo para definir sintaxis concreta La definición de la sintaxis concreta se ha realizado mediante perfiles UML, más específicamente, se ha utilizado la versión 2.5 de UML [OMG 2015c]. Un perfil UML es una extensión formal del propio lenguaje UML con el objetivo de definir nuevos conceptos a partir de constructores ya existentes en UML, para dotarles de una semántica más precisa y concreta. Para facilitar el uso de lenguajes basados en modelos dentro de entornos de explotación, la OMG propone definir sintaxis concretas utilizando una de las siguientes alternativas:  Definir un nuevo lenguaje específico.  Extender UML a través de la especialización de sus conceptos, definiendo otros nuevos conceptos que aprovechen la semántica (restricciones, propiedades y asociaciones) de los conceptos de UML. La siguiente tabla (Tabla 13) presenta las ventajas e inconvenientes que se identifican en cada alternativa: 102 La siguiente figura (Figura 39) muestra los valores enumerados creados para dar soporte a las listas de valores predeterminados en el metamodelo de MoDHE CDA. En el perfil, a diferencia del metamodelo, se ha decidido incluir códigos en vez de descripciones. Las descripciones se modelan en ficheros de configuración, permitiendo utilizar la herramienta en diferentes idiomas (en el prototipo desarrollado se incluye español e inglés). Figura 39. Perfil UML de MoDHE en EA. Parte CDA. Valores enumerados. pkg DRS - Requisitos de Almacenamiento «enumeration» x_BasicConfidentialityKind 2.16.840.1.113883.5.25.N 2.16.840.1.113883.5.25.R 2.16.840.1.113883.5.25.V «enumeration» DocumentType 2.16.840.1.113883.21.175.AR 2.16.840.1.113883.21.175.CD 2.16.840.1.113883.21.175.CN 2.16.840.1.113883.21.175.DI 2.16.840.1.113883.21.175.DS 2.16.840.1.113883.21.175.ED 2.16.840.1.113883.21.175.HP 2.16.840.1.113883.21.175.OP 2.16.840.1.113883.21.175.PC 2.16.840.1.113883.21.175.PH 2.16.840.1.113883.21.175.PN 2.16.840.1.113883.21.175.PR 2.16.840.1.113883.21.175.SP 2.16.840.1.113883.21.175.TS «enumeration» HumanLanguage RFC1766.en RFC1766.es RFC1766.fr RFC1766.de RFC1766.(...) «enumeration» ParticipationSignature 13977 10284 10283 «enumeration» PostalAddressUse V10628 V19613 10638 10639 (...) «enumeration» RoleCode 17623 17624 V19579 (...) «enumeration» TelecommunicationAddressUse V10628 V19613 20891 10634 10636 10635 (...) «enumeration» EntityNamePartType 10654 10655 10657 10658 10656 (...) «enumeration» EntityNamePartQualifier 15890 10665 10673 17938 20932 (...) «enumeration» OrganizationIndustryClass DOMAIN «enumerati... RoleStatus V16000 16001 20856 20855 16002 16003 16004 «enumeration» AdministrativeGender 10174 10173 17718 «enumeration» MaritalStatus 12213 12214 12215 12216 12217 12220 12218 15981 12219 «enumeration» ReligiousAffiliation 19189 19192 19198 19205 19207 19221 (...) «enumeration» Race V15743 15744 15745 15746 15747 15748 15749 (...) «enumeration» Ethnicity V15837 V15854 15855 15856 (...) 103 La siguiente figura (Figura 40) muestra los estereotipos y artefactos de los tipos de datos de los estándares HL7 CDA y HL7 v3. Encontramos 2 tipos de datos:  Tipos de datos instanciables. Se trata de tipos de datos que se requieren instanciar en la herramienta, es decir, se requiere tener la posibilidad de arrastrar un nuevo elemento de la paleta de elementos. En este caso, se modelan como estereotipos. Se ha creado en estereotipo abstracto DataType para centralizar la extensión a la metaclase Class, simplificando así los diagramas.  Tipos de datos no instanciables. Se trata de tipos de datos que no se necesitan instanciar en la herramienta, es decir, existen campos de dichos tipos de datos, pero no es necesario dar al usuario la posibilidad de arrastrar un nuevo elemento de la paleta de elementos. Figura 40. Perfil UML de MoDHE en EA. Parte CDA-v3. Tipos de datos. pkg DRS - Requisitos de Almacenamiento «metaclass» Class + isActive :Boolean - Language = NDT Requisitos CE - code :string - codeSystem :string - codeSystemName :string - codeSystemVersion :string - displayName :string - originalText :string HL7-II - assigningAuthorityName :string - displayable :string - extension :string - root :string HL7-AD - addressPart :ADXP - use :PostalAddressUse - useablePeriod :string ADXP - streetName :string - direction :string - country :string - state :string - postalCode :string - city :string - delimiter :string HL7-TEL - use :TelecommunicationAddressUse - useableperiod :string - value :string HL7-PN - namePart :ENXP - use :string = L=LEGAL - useablePeriod :string ENXP - qualifier :EntityNamePartQualifier - partType :EntityNamePartType - language :HumanLanguage ON - name :string IVL_TS - low :date - high :date HL7-EN - value :string - type :string ST - value :string - language :string HL7-TS - value :date HL7-INT - value :integer HL7-CS - code :string HL7-CD - code :string - codeSystem :string - codeSystemName :string - codeSystemVersion :string - displayName :string - originalText :string - translation :string - qualifier :string HL7-PQ - value :double - unit :string - translation :PQR PQR - value :string - code :string - codeSystem :string - codeSystemName :string - codeSystemVersion :string - displayName :string - originalText :string HL7-MO - value :string - currency :string HL7-ED - data :string - representation :string - mediaType :string - charset :string - language :HumanLanguage - compression :string - reference :string HL7-ANY - xsi:type :string - value :string DataType 104 La siguiente figura (Figura 41) muestra los estereotipos relacionados con el estándar HL7 v2.x. Figura 41. Perfil UML de MoDHE en EA. Parte v2.x. Entidades. La siguiente figura (Figura 42) muestra los estereotipos relacionados con los tipos de datos del estándar HL7 v2.x. Al igual que en el caso anterior, encontramos 2 tipos de datos:  Tipos de datos instanciables. Se trata de tipos de datos que se requieren instanciar en la herramienta, es decir, se requiere tener la posibilidad de arrastrar un nuevo elemento de la paleta de elementos. En este caso, se modelan como estereotipos. Se ha creado en estereotipo abstracto Instanciable para centralizar la extensión a la metaclase Class, simplificando así los diagramas.  Tipos de datos no instanciables. Se trata de tipos de datos que no se necesitan instanciar en la herramienta, es decir, existen campos de dichos tipos de datos, pero no es necesario dar al usuario la posibilidad de arrastrar un nuevo elemento de la paleta de elementos. pkg DRS - Requisitos de Almacenamiento «metaclass» Class + isActive :Boolean - Language = NDT Requisitos HL7-v2.7-Message - icon :int = C:\Users\martin... HL7-v2.7-SegmentMSH - SegmentID :string = MSH - FieldSeparator :string = | - EncodingCharacters :string = ^~\& - SendingApplication :HD - SendingFacility :HD - ReceivingApplication :HD - ReceivingFacility :HD - DateTimeOfMessage :date - Security :string - MessageType :MSG - MessageControlID :string - ProcessingID :PT - VersionID :VID - SequenceNumber :double - ContinuationPointer :string - AcceptAcknowledgmentType :0155 - Accept/Application Acknowledgment Conditions - ApplicationAcknowledgmentType :0155 - Accept/Application Acknowledgment Conditions - CountryCode :0399 - ISO-3166 - PrincipalLanguageOfMessage :HL7-CWE - AlternateCharacterSetHandlingScheme :0356 - Alternate Character Set Handling Scheme - SendingResponsibleOrganization :XON - ReceivingResponsibleOrganization :XON - SendingNetworkAddress :HD - ReceivingNetworkAddress :HD HL7-v2.7-SegmentEVN - SegmentID :string = EVN - EventTypeCode - RecordedDateTime :date - DateTimePlannedEvent :date - EventReasonCode :HL7-CWE - EventOccurred :date - EventFacility :HD HL7-v2.7-SegmentPID - SegmentID :string = PID - SetID-PID :int - PatientID - AlternatePatientID-PID - DateTimeOfBirth :date - AdministrativeSex :HL7-CWE - PatientAlias - CountyCode - PrimaryLanguage :HL7-CWE - MaritalStatus :HL7-CWE - Religion :HL7-CWE - PatientAccountNumber :HL7-CX - SSNNumberPatient - DriversLicenseNumberPatient - BirthPlace :string - MultipleBirthIndicator :0136 - Yes/no Indicator - BirthOrder :double - VeteransMilitaryStatus :HL7-CWE - Nationality - PatientDeathDateAndTime :date - PatientDeathIndicator :0136 - Yes/no Indicator - IdentityUnknownIndicator :0136 - Yes/no Indicator - LastUpdateDateTime :date - LastUpdateFacility :HD - SpeciesCode :HL7-CWE - BreedCode :HL7-CWE - Strain :string 105 Figura 42. Perfil UML de MoDHE en EA. Parte v2.x. Valores enumerados. pkg DRS - Requisitos de Almacenamiento «metaclass» Class + isActive :Boolean - Language = NDT Requisitos HD - NamespaceID :0300 - Namespace ID - UniversalID :string - UniversalIDType :0301 - Universal ID Type HL7-0211 - Alternate Character Sets «enum» + ASCII + 8859/1 + 8859/2 + 8859/3 + 8859/4 + 8859/5 + (...) MSG - MessageCode :0076 - Message Type - TriggerEvent :0003 - Event Type - MessageStructure :0354 - Message Structure PT - ProcessingID :0103 - Processing ID - ProcessingMode :0207 - Processing Mode VID - InternationalizationCode :HL7-CWE - VersionID :0104 - Version ID - InternationalVersionID :HL7-CWE HL7-CWE - Identifier :string - Text :string - NameOfCodingSystem :0396 - Coding System - AlternateIdentifier :string - AlternateText :string - NameOfAlternateCodingSystem :0396 - Coding System - CodingSystemVersionID :string - AlternateCodingSystemVersionID :string - OriginalText :string - SecondAlternateIdentifier :string - SecondAlternateText :string - NameOfSecondAlternateCodingSystem :0396 - Coding System - SecondAlternateCodingSystemVersionID :string - CodingSystemOID :string - ValueSetOID :string - ValueSetVersionID :date - AlternateCodingSystemOID :string - AlternateValueSetOID :string - AlternateValueSetVersionID :date - SecondAlternateCodingSystemOID :string - SecondAlternateValueSetOID :string - SecondAlternateValueSetVersionID :date HL7-EI - EntityIdentifier :string - NamespaceID :0363 – Assigning Authority - UniversalID :string - UniversalIDType :0301 - Universal ID Type XON - OrganizationName :string - OrganizationNameTypeCode :HL7-CWE - IDNumber :string - IdentifierCheckDigit :double - CheckDigitScheme :0061 - Check Digit Scheme - AssigningAuthority :HD - IdentifierTypeCode :0203 - Identifier Type - AssigningFacility :HD - NameRepresentationCode :0465 - Name/Address Representation - OrganizationIdentifier :string HL7-XCN - PersonIdentifier :string - FamilyName :FN - GivenName :string - SecondAndFurtherGivenNamesOrInitialsThereof :string - Suffix :string - Prefix :string - Degree - SourceTable :HL7-CWE - AssigningAuthority :HD - NameTypeCode :0200 - Name Type - IdentifierCheckDigit :string - CheckDigitScheme :0061 - Check Digit Scheme - IdentifierTypeCode :0203 - Identifier Type - AssigningFacility :HD - NameRepresentationCode :0465 - Name/Address Representation - NameContext :HL7-CWE - NameValidityRange - NameAssemblyOrder :0444 - Name Assembly Order - EffectiveDate :date - ExpirationDate :date - ProfessionalSuffix :string - AssigningJurisdiction :HL7-CWE - AssigningAgencyOrDepartment :HL7-CWE - SecurityCheck :string - SecurityCheckScheme :0904 - Security Check Scheme HL7-CX - IDNumber :string - IdentifierCheckDigit :string - CheckDigitScheme :0061 - Check Digit Scheme - AssigningAuthority :HD - IdentifierTypeCode :0203 - Identifier Type - AssigningFacility :HD - EffectiveDate :date - ExpirationDate :date - AssigningJurisdiction :HL7-CWE - AssigningAgencyOrDepartment :HL7-CWE - SecurityCheck :string - SecurityCheckScheme :0904 - Security Check Scheme HL7-XPN - FamilyName :FN - GivenName :string - SecondAndFurtherGivenNamesOrInitialsThereof :string - Suffix :string - Prefix :string - Degree - NameTypeCode :0200 - Name Type - NameRepresentationCode :0465 - Name/Address Representation - NameContext :HL7-CWE - NameValidityRange - NameAssemblyOrder :0444 - Name Assembly Order - EffectiveDate :date - ExpirationDate :date - ProfessionalSuffix :string - CalledBy :string FN - Surname :string - OwnSurnamePrefix :string - OwnSurname :string - SurnamePrefixFromPartnerSpouse :string - SurnameFromPartnerSpouse :string HL7-XAD - StreetAddress :SAD - OtherDesignation :string - City :string - StateOrProvince :string - ZipOrPostalCode :string - Country :0399 - ISO-3166 - AddressType :0190 - Address Type - OtherGeographicDesignation :string - CountyParishCode :HL7-CWE - CensusTract :HL7-CWE - AddressRepresentationCode :0465 - Name/Address Representation - AddressValidityRange - EffectiveDate :date - ExpirationDate :date - ExpirationReason :HL7-CWE - TemporaryIndicator :0136 - Yes/no Indicator - BadAddressIndicator :0136 - Yes/no Indicator - AddressUsage :0617 - Address Usage - Addressee :string - Comment :string - PreferenceOrder :int - ProtectionCode :HL7-CWE - AddressIdentifier :HL7-EI HL7-XTN - TelephoneNumber - TelecommunicationUseCode :0201 - Telecommunication Use Code - TelecommunicationEquipmentType :0202 - Telecommunication Equipment Type - CommunicationAddress :string - CountryCode :string - AreaCityCode :string - LocalNumber :string - Extension :string - AnyText :string - ExtensionPrefix :string - SpeedDialCode :string - UnformattedTelephoneNumber :string - EffectiveStartDate :date - ExpirationDate :date - ExpirationReason :HL7-CWE - ProtectionCode :HL7-CWE - SharedTelecommunicationIdentifier :HL7-EI - PreferenceOrder :int SAD - StreetOrMailingAddress :string - StreetName :string - DwellingNumber :string Instanciable 106 La siguiente figura (Figura 43) muestra los enumerados correspondientes al metamodelo de MoDHE v2.x. Figura 43. Perfil UML de MoDHE en EA. Parte v2.x. Tipos de datos. pkg DRS - Requisitos de Almacenamiento «enumeration» 0361 - Application No suggested values defined «enumeration» 0362 - Facility No suggested values defined «enumeration» 0155 - Accept/Application Acknowledgment Conditions 0155.AL 0155.NE 0155.ER 0155.SU «enumeration» 0399 - ISO-3166 0399.en 0399.es 0399.fr 0399.de (...) «enumeration» 0356 - Alternate Character Set Handling Scheme 0356.ISO.2022.1994 0356.2.3 0356.null «enumeration» 0300 - Namespace ID No suggested values defined «enumeration» 0301 - Universal ID Type 0301.DNS 0301.EUI64 0301.CLIA 0301.CLIP 0301.GUID (...) «enumeration» 0076 - Message Type 0076.ACK 0076.ADR 0076.ADT 0076.BAR (...) «enumeration» 0003 - Event Type 0003.A01 0003.A02 0003.A03 0003.A04 0003.A05 0003.A06 (...) «enumeration» 0354 - Message Structure 0354.ACK 0354.ADR_A19 0354.ADT_A01 0354.ADT_A02 (...) «enumeration» 0103 - Processing ID 0103.D 0103.P 0103.T «enumeration» 0207 - Processing Mode 0207.A 0207.R 0207.I 0207.T 0207.NotPresent «enumeration» 0104 - Version ID 0104.2.0 0104.2.0D 0104.2.1 0104.2.2 0104.2.3 0104.2.3.1 0104.2.4 0104.2.5 0104.2.5.1 0104.2.6 0104.2.7 «enumeration» 0396 - Coding System 0396.L 0396.ACR 0396.ALPHAID2006 (...) «enumeration» 0363 – Assigning Authority No suggested values defined «enumeration» 0061 - Check Digit Scheme 0061.BCV 0061.NPI 0061.ISO 0061.M10 0061.M11 «enumeration» 0203 - Identifier Type 0203.ACSN 0203.AM 0203.AMA (...) «enumeration» 0465 - Name/Address Representation 0465.I 0465.A 0465.P «enumeration» 0062 - Event Reason 0062.01 0062.02 0062.03 0062.O 0062.U «enumeration» 0188 - Operator ID No suggested values defined «enumeration» 0200 - Name Type 0200.D 0200.L 0200.TEMP 0200.NB 0200.A 0200.S (...) «enumerati... 0444 - Name Assembly Order 0444.G 0444.F «enumeration» 0904 - Security Check Scheme 0904.BCV 0904.CCS 0904.VID «enumeration» 0136 - Yes/no Indicator 0136.Y 0136.N «enumeration» 0190 - Address Type 0190.BA 0190.BI 0190.N 0190.BDL (...) «enumeration» 0617 - Address Usage 0617.M 0617.V 0617.C «enumeration» 0201 - Telecommunication Use Code 0201.PRN 0201.ORN 0201.WPN 0201.VHN 0201.ASN 0201.EMR 0201.NET 0201.BPN 0201.PRS «enumeration» 0202 - Telecommunication Equipment Type 0202.PH 0202.FX 0202.MD 0202.CP 0202.SAT 0202.BP 0202.Internet 0202.X.400 0202.TDD 0202.TTY «enumeration» 0001 - Administrative Sex 0001.F 0001.M 0001.O 0001.U 0001.A 0001.N «enumeration» 0005 - Race 0005.1002-5 0005.2028-9 0005.2054-5 0005.2076-8 0005.2106-3 0005.2131-1 «enumeration» 0296 – Primary Language No suggested values defined «enumeration» 0002 - Marital Status 0002.A 0002.D 0002.M 0002.S 0002.W 0002.C 0002.G 0002.P 0002.R 0002.E 0002.N 0002.I 0002.B 0002.U 0002.O 0002.T «enumeration» 0006 - Religion 0006.AG 0006.AT 0006.BA 0006.BR 0006.BU (...) «enumeration» 0189 - Ethnic Group 0189.H 0189.N 0189.U «enumeration» 0171 - Citizenship No suggested values defined «enumeration» 0172 - Veterans Military Status No suggested values defined «enumeration» 0445 - Identity Reliability Code 0445.US 0445.UD 0445.UA 0445.AL «enumeration» 0446 - Species Code No suggested values defined «enumeration» 0447 - Breed Code No suggested values defined «enumeration» 0429 - Production Class Code 0429.BR 0429.DA 0429.DR 0429.DU 0429.LY 0429.MT 0429.OT 0429.PL 0429.RA 0429.SH 0429.NA 0429.U «enumeration» 0297 - CN ID Source No suggested values defined «enumeration» 0448 - Name Context No suggested values defined «enumeration» 0204 - Organizational Name Type 0204.A 0204.L 0204.D 0204.SL «enumeration» 0289 - County/Parish No suggested values defined «enumeration» 0288 - Census Tract No suggested values defined «enumeration» 0616 - Address Expiration Reason 0616.M 0616.E 0616.R 0616.C «enumeration» 0868 - Telecommunication Expiration Reason 0868.M 0868.E 0868.R 0868.C 0868.N «enumeration» 0618 - Protection Code 0618.LI 0618.UL 0618.UP 107 Como se puede visualizar en todas las vistas del perfil UML mostradas anteriormente, todos los estereotipos extienden la metaclase Class de UML. Se ha optado por extender esta metaclase UML en cuestión porque esta metaclase tiene como objetivo especificar una clasificación de objetos y especificar sus propiedades (atributos, operaciones, asociaciones, etc.), caracterizando la estructura y el contexto de estos objetos. De este modo, cuando se modele un elemento propio de HL7, se podrán definir los atributos, asociaciones, etc, usando una nomenclatura similar a la utilizada por la metaclase Class de UML, reduciendo así la curva de aprendizaje en el uso de la metodología y de la herramienta, y mejorando la usabilidad de éstas. 3. MoDHE Suite: Herramienta CASE de soporte al marco de trabajo teórico Para hacer posible el uso práctico del marco de referencia definido en los apartados anteriores, que permite construir modelos UML conformes a los estándares de HL7, es necesario desarrollar una herramienta CASE que dé soporte a esta construcción y automatice las reglas de derivación anteriormente definidas. El presente apartado describe los fundamentos de dicha herramienta, bautizada como MoDHE Suite. Gracias a esta herramienta, se podrán modelar sistemas de información sanitarios conformes a los estándares de HL7 sin tener un conocimiento profundo de los estándares propuestos por HL7. A continuación se describe cuál es la arquitectura del marco de trabajo MoDHE Suite dentro del entorno de EA, cómo se han implementado los perfiles UML definidos en el apartado 2 de este capítulo, y cómo se han implementado las reglas de derivación descritas en el Capítulo VI. Si el lector está interesado, en el Anexo C de la presente memoria puede encontrar un manual de usuario de la herramienta MoDHE Suite. 3.1. Arquitectura de MoDHE Suite Teniendo en cuenta que la metodología de MoDHE extiende la metodología NDT, la herramienta MoDHE Suite toma como base la implementación de la herramienta NDT-Suite, que a su vez usa como base la arquitectura software que proporciona EA. La siguiente figura (Figura 44) muestra la arquitectura de la herramienta MoDHE Suite vista como un plugin de EA. 108 Figura 44. Arquitectura de MoDHE Suite. A continuación, se detallan cada uno de los módulos internos de EA que utiliza la herramienta MoDHE Suite, garantizando la capacidad de extensión a través de plugins:  Objeto COM (DLL). Biblioteca de vínculos dinámicos con objetos COM que exponen un conjunto de métodos públicos para, entre otras funcionalidades, facilitar el control de acceso a datos y la captura de eventos.  Acceso a datos. Conector al repositorio de datos donde se almacenan las instancias de los metamodelos definidos.  Capturador de eventos. Controla los eventos que se producen en la interfaz de usuario.  MDG (Model Driven Generation) Technologies. Módulo que permite definir: sintaxis concretas, perfiles UML, patrones de diseño, plantillas, y otros recursos. En el nivel inferior del diagrama se identifica el repositorio de datos donde se almacenan instancias de los metamodelos involucrados. Esta base de datos relacional se puede implementar en diferentes entornos: Microsoft Access, MySQL, Oracle, PostgreSQL, SQL Server, etc. En el caso específico de MoDHE Suite, la base de datos relacional se implementa en Microsoft Access, por ser la opción utilizada por NDT-Suite. En el nivel superior del diagrama representado en la anterior Figura 44 se identifican los siguientes módulos funcionales que componen el plugin específico de MoDHE Suite:  Interfaz de usuario. Pantallas a disposición del usuario final para utilizar las funcionalidades de la herramienta MoDHE Suite. 109  Restricciones. Módulo encargado de implementar las restricciones OCL definidas como parte del detalle de los metamodelos de MoDHE definidos en el Capítulo V (detalle incluido en el Anexo B).  Transformaciones. Módulo encargado de implementar las reglas de derivación definidas de forma teórica en el Capítulo VI.  Perfiles UML. Módulo que implementa la sintaxis concreta de los metamodelos de MoDHE, definida de forma teórica en el apartado 2 del presente capítulo. 3.2. Trasladando la sintaxis concreta definida a Enterprise Architect Uno de los aspectos más importantes en el desarrollo de la herramienta MoDHE Suite es la traslación de la sintaxis concreta dentro de EA. Para ello, se ha utilizado el módulo MDG Technologies de EA. El primer paso para definir la sintaxis concreta en EA es crear un proyecto del tipo “MDG Technology” utilizando el asistente de EA. En el caso de la herramienta MoDHE Suite, al ser una extensión de la herramienta NDT-Suite, no se ha creado un proyecto MDG Technology desde cero, en su defecto se han utilizado los 5 proyectos MDG Technology ya existentes para la implementación de la herramienta NDT-Suite, correspondientes a las siguientes fases de desarrollo de software: requisitos, análisis, diseño, pruebas, mantenimiento. La siguiente figura (Figura 45) muestra la estructura de carpetas presente en los proyectos MDG Technology de MoDHE Suite. Figura 45. Estructura de carpetas del proyecto “MDG Technology” de MoDHE Suite. 110 Como se puede ver en la anterior figura (Figura 45), para cada proyecto MDG Technology, EA crea por defecto 2 paquetes:  Paquete Toolbox. Contiene el conjunto de estereotipos que componen el perfil UML, junto con sus valores etiquetados. Cada uno de estos estereotipos deben estar enlazados con la metaclase UML oportuna a través de una relación «extend». Cada uno de los estereotipos contemplados se define por medio de un conjunto de valores etiquetados, que se corresponden con los atributos de los estereotipos definidos en el perfil UML.  Paquete «profile». Contiene todos aquellos artefactos de EA necesarios para definir la creación de diagramas según determinados estereotipos definidos en el paquete anterior, y seleccionados previamente. A partir de este conjunto de artefactos, se le otorga al usuario la capacidad para modelar siguiendo un determinado perfil UML. El siguiente paso llevado a cabo en el desarrollo de la herramienta MoDHE Suite, es crear e instalar el fichero «MDG Technology» desde EA. Para ello, se deben seguir los siguientes pasos: 1. Crear una ruta de carpetas donde almacenar los ficheros de configuración, por ejemplo: “C:\MoDHE\Recursos\”. 2. Generar el fichero de configuración del perfil. a. En el árbol de navegación por proyectos, pulsar sobre “PROFILE 2.0 (Toolbox) | <<Profile>> NDT – REQUISITOS | Toolbox | <<profile>> DRS – Requisitos de Almacenamiento” con el botón derecho, y seleccionar la opción “Save package as UML Profile”. b. Indicar los siguientes parámetros de configuración (los parámetros no indicados se mantienen por defecto): o Profile Name: “MoDHE – Requisitos de Información” o Filename: “C:\MoDHE\Recursos\profile.xml” o Notes: “Toolbox de MoDHE con los artefactos para definir los Requisitos de Información” 3. Generar el fichero de configuración del diagrama. a. En el árbol de navegación por proyectos, pulsar sobre “PROFILE 2.0 (Toolbox) | <<Profile>> NDT – REQUISITOS | <<profile>> Diagramas DRS” con el botón derecho, y seleccionar la opción “Save package as UML Profile”. b. Indicar los siguientes parámetros de configuración (los parámetros no indicados se mantienen por defecto): o Filename: “C:\MoDHE\Recursos\diagram.xml” 4. Generar el fichero de configuración MDG. a. Pulsar sobre la siguiente opción en el menú superior “Tools | Generate MDG Technology File”. b. En la pantalla “Create”, indicar los siguientes parámetros de configuración (los parámetros no indicados se mantienen en blanco): o Technology: UML Profile for MoDHE o Filename: “C:\MoDHE\Recursos\ProfileMoDHE.xml”. o ID: ProfileMoDHE 111 o Version: 1 o Notes: PERFIL UML PARA MoDHE c. En la pantalla “Contents”, mantener marcadas exclusivamente las siguientes opciones: Profiles, Diagram Types. d. En la pantalla “Profile files selection”, indicar los siguientes parámetros: o Directory: “C:\MoDHE\Recursos” o Selected files: profile.xml e. En la pantalla “Diagram Types”, indicar los siguientes parámetros: o Directory: “C:\MoDHE\Recursos” o Selected files: diagram.xml f. Este asistente finaliza generando un fichero XML llamado ProfileMoDHE con la configuración indicada, en la ruta especificada. 5. Para utilizar finalmente el perfil, se debe desplegar el fichero generado dentro de la carpeta “MDGTechnologies” situada en el directorio de instalación de EA. Tras llevar a cabo estos pasos, ya está todo preparado para utilizar el plugin específico de la herramienta MoDHE Suite. Al ejecutar EA, nos aparece un nuevo menú que permite modelar en UML requisitos de información sanitarios conformes a los estándares de HL7. La siguiente figura (Figura 46) muestra el resultado visual de este toolbox. Figura 46. Toolbox de MoDHE Suite. Cabe destacar que el toolbox de MoDHE Suite para modelar los requisitos de información, además de incluir los elementos propios de estándares de HL7, incluye los elementos necesarios para modelar requisitos de información no sanitarios (subsistemas, requisitos 118 Figura 50. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (iii). Figura 51. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (iv). 119 Figura 52. Aplicación práctica de MoDHE Suite sobre el proyecto Prevensalud (v). Al comparar el modelo CDA de Prevensalud con el resultado de modelar el escenario con la herramienta MoDHE Suite, se identifican las siguientes diferencias (Tabla 14): Tabla 14. Diferencias entre CDA de Prevensalud vs CDA modelado con MoDHE Suite. Clase Atributo Diferencias ClinicalDocument classCode Este atributo está presente en el modelo que genera la herramienta MoDHE Suite, pero no aparece en el modelo original de Prevensalud. ClinicalDocument moodCode Este atributo está presente en el modelo que genera la herramienta MoDHE Suite, pero no aparece en el modelo original de Prevensalud. El siguiente paso ha sido revisar en profundidad el estándar CDA de HL7 para verificar qué modelo es más consistente con el estándar. No se ha identificado ningún error comparando el modelo modelado por la herramienta MoDHE Suite con la definición del estándar. 120 En cambio, se han identificado 3 tipos de errores en el modelo CDA de Prevensalud, los cuales se tipifican en la siguiente tabla (Tabla 15). Tabla 15. Tipificación de errores identificados. Identificador Error Error OBLIG Elemento obligatorio en el estándar. No ha sido incluido en el modelo. Error VALOR Elemento con valor obligatorio en el estándar. Se ha utilizado un valor diferente al que marca el estándar. Error MULTI Elemento con multiplicidad máximo 1 en el estándar. Se ha definido con multiplicidad * (n repeticiones) en el modelo. La siguiente tabla (Tabla 16) muestra los errores identificados en el modelo CDA de Prevensalud, clasificando el error en cuestión según la tipificación definida en la Tabla 15. Tabla 16. Errores identificados en el modelo de Prevensalud por no cumplir el estándar. Clase Atributo Error ClinicalDocument classCode Error OBLIG. ClinicalDocument moodCode Error OBLIG. legalAuthenticator - Error MULTI. OrganizationPartOf classCode Error OBLIG. OrganizationPartOf id Error OBLIG. AuthoringDevice classCode Error OBLIG. AuthoringDevice determinerCode Error OBLIG. ParentDocument classCode Error OBLIG. ParentDocument moodCode Error OBLIG. inFulfillmentOF typeCode Error OBLIG. Order classCode Error OBLIG. Order moodCode Error OBLIG. ManufacturedProduct classCode Error OBLIG. Material classCode Error OBLIG. Material determinerCode Error OBLIG. consumable typeCode Error OBLIG. product typeCode Error OBLIG. PlayingEntity determinerCode Error OBLIG. PlayingEntity classCode Error VALOR. En el estándar establece valor obligatorio a “ENT”. En la guía de implementación, define “PLC” o “MMAT”. participantRole classCode Error VALOR. En el estándar establece el valor obligatorio a “ROL”. En la guía de implementación, define “SDLOC” o “MANU”. 121 2. Conclusiones MoDHE permite desarrollar modelos UML conformes a HL7, gracias a un marco de referencia compuesto por 3 pilares: el método, el lenguaje de modelado basado en HL7, y las derivaciones entre modelos. La herramienta MoDHE Suite, cuyos aspectos principales se detallan en el Capítulo VII, da soporte al marco de referencia MoDHE. En el presente capítulo se ha realizado una validación funcional sobre un caso real llevado a cabo en el HUVR: el proyecto Prevensalud. El resultado de dicha validación evidencia que al desarrollar el modelo HL7 de Prevensalud se cometieron una serie de errores de incumplimiento del estándar que, utilizando la herramienta MoDHE Suite, se hubieran evitado. 122 123 Capítulo IX. Aportación, trabajo futuro y conclusiones urante el desarrollo de la presente Tesis Doctoral se han ido abordando todos los elementos necesarios para completar el marco de referencia MoDHE que facilita el diseño de modelos de dominio basados en HL7 de sistemas de información sanitarios. Inicialmente, se realizó un estudio del estado del arte exhaustivo para conocer la situación de partida y, una vez analizados los resultados obtenidos, se comenzó a trabajar en dicho marco de referencia, detallado en la presente memoria de Tesis Doctoral. Para resolver el problema se optó por una solución basada en el paradigma MDE, cuyo marco de referencia se sustenta por 3 pilares principalmente: (i) La metodología de MoDHE, que ofrece al ingeniero del software un procedimiento para diseñar modelos de dominio HL7 como parte de un sistema de información sanitario, usando una interfaz UML. (ii) Un lenguaje de modelado basado en HL7, que extiende a UML modelando el espectro de conceptos existente en los estándares de HL7. (iii) Mecanismos de derivación, que hacen posible transformar modelos conformes a un estándar, en modelos conformes a otro estándar. Además, como prueba de viabilidad práctica del marco de referencia teórico definido, se ha desarrollado la herramienta MoDHE Suite. Dicha herramienta ha sido validada en un escenario real del proyecto Prevensalud, un proyecto de investigación en el que se estuvo trabajando en el Hospital Universitario Virgen del Rocío. En definitiva, todo este material constituye el trabajo realizado en la presente Tesis Doctoral. Para dejar constancia de las aportaciones que ofrece a la comunidad investigadora, este capítulo concluye describiendo el marco estratégico de investigación en el que se ha desarrollado la presente Tesis Doctoral (apartado 1) que ha influenciado los resultados obtenidos, describiendo las aportaciones específicas haciendo referencia a los objetivos planteados al inicio (apartado 2), y proponiendo un conjunto de líneas futuras de investigación en las que seguir trabajando relacionadas con la presente línea de investigación (apartado 3). 1. Marco estratégico en el que se desarrolla la presente Tesis Doctoral La presente Tesis Doctoral se ha desarrollado en el contexto de las líneas de investigación en las que trabajan los grupos de investigación IWT2 y GIT, influenciando en gran medida su desarrollo. Ambas relaciones se detallan a continuación. D 124 1.1. Línea de investigación en el grupo IWT2 El grupo IWT2 presenta, como una de sus principales líneas estratégicas, la combinación de forma satisfactoria del paradigma MDE con la gestión de la información en múltiples ámbitos, con el objetivo de resolver necesidades que se han ido identificando. El hecho de contar con una línea sobre la aplicación del paradigma MDE permite armonizar propuestas y planteamientos, provocando que los resultados de un trabajo de investigación apoyen las hipótesis de los siguientes, avanzando conjuntamente. Dentro de los objetivos de esta línea de investigación se contempla la necesidad de ofrecer soluciones en el marco de la ingeniería de la salud, facilitando al ingeniero del software el desarrollo de sistemas de información sanitarios robustos y mantenibles, utilizando para ello el paradigma MDE. Además, a raíz de la presente Tesis Doctoral, en el marco del grupo IWT2, se han iniciado Trabajos Fin de Grado en el ámbito del desarrollo de modelos de dominio HL7 usando el paradigma MDE, motivado por la incipiente trayectoria del grupo IWT2 en el sector sanitario. 1.2. Línea de investigación en el grupo GIT El grupo GIT presenta como una de sus principales líneas estratégicas el uso de estándares de informática sanitaria, con el objetivo de ofrecer nuevo conocimiento a la comunidad investigadora sobre la practicidad real que pueden tener estos estándares. En diversos proyectos han experimentado tanto con múltiples estándares de HL7 (v2.x, CDA, CCOW, FHIR, vMR, etc), como con otros estándares promovidos por otras organizaciones de estandarización (OpenEHR, ISO 13606, ISO 13940, etc). El desarrollo del marco de referencia MoDHE ha sido un avance importante para esta línea de investigación del grupo GIT, ya que ofrece un soporte robusto para el desarrollo de modelos de dominio HL7 a través de una metodología basada en el paradigma MDE, que reduce la curva de aprendizaje de los ingenieros del software que necesiten desarrollar modelos de dominio HL7, y produce sistemas de información sanitarios mantenibles y adaptables, ya que ofrece una interfaz basada en modelos UML. 2. Aportaciones de este trabajo de tesis Este segundo apartado recapitula las principales aportaciones que ofrece la presente Tesis Doctoral a la comunidad científica, haciendo referencia a los objetivos que se plantearon al inicio de la investigación, comprobando que existe al menos una correspondencia para cada objetivo, concluyendo que todos los objetivos han sido cubiertos. 2.1. Estudio del estado del arte En el desarrollo de la investigación llevada a cabo en la presente Tesis Doctoral, era fundamental conocer la situación actual en cuanto al uso de MDE y HL7 de forma conjunta, 125 puesto que el planteamiento podría haber sido diferente en el caso de existir múltiples propuestas. Para conocer dicha situación actual, se realizó una revisión sistemática de la literatura sobre los trabajos que usaban estándares de HL7 de forma conjunta al paradigma MDE. En este estudio, se concluyó que la literatura científica aportaba pocas evidencias, por lo que se decidió realizar una revisión general en buscadores de propósito general. Con esta aportación se cubre el primero de los objetivos planteados en el Capítulo III que consistía en Realizar un estudio del estado del arte para identificar propuestas para el diseño de modelos de dominio basados en HL7 haciendo uso del paradigma de la ingeniería dirigida por modelos. 2.2. Marco de referencia MoDHE para el diseño de modelos de dominio HL7 La principal aportación realizada con el desarrollo de la presente Tesis Doctoral es el marco de referencia que permite diseñar modelos de dominio HL7 utilizando una interfaz basada en UML. Este marco hace posible que los ingenieros del software diseñen modelos de dominio HL7 con una herramienta usable, basada en UML, reduciendo la curva de aprendizaje, y consiguiendo sistemas fácilmente mantenibles y adaptables. Cabe destacar la gran influencia que ha tenido el paradigma MDE en el desarrollo de dicho marco de referencia, puesto que ha dirigido en gran medida las soluciones adoptadas. Para desarrollar este marco de referencia al que hemos llamado MoDHE, se han definido y desarrollado 3 pilares fundamentales: una propuesta metodológica, un lenguaje de modelado basado en HL7, y las transformaciones necesarias para enriquecer MoDHE con la posibilidad de convertir modelos de un estándar a otro de HL7. 1. La metodología de MoDHE. Este método garantiza la posibilidad de definir modelos de dominio HL7 para facilitar el diseño de sistemas de información sanitarios. Destacar que con el desarrollo de esta metodología, queda cubierto el segundo objetivo planteado en el Capítulo III, que consistía en Definir y desarrollar una propuesta metodológica para diseñar modelos de dominio HL7 de una manera sistemática, consiguiendo reducir los costes de aprendizaje. 2. El lenguaje de modelado basado en HL7. Este lenguaje ha sido definido a través de los metamodelos de MoDHE para dar soporte al marco de referencia en su misión de definir modelos de dominio conformes a HL7. Para definirlo, se han tenido en cuenta los conceptos definidos en los estándares v3, CDA y v2.x de HL7. Con la definición de este lenguaje, se ha logrado el siguiente objetivo planteado en el Capítulo III: Definir un metamodelo de diseño de modelos de dominio HL7 para poder modelar sistemas de información sanitarios en conformidad con los siguientes estándares de HL7: v3, CDA y v2.x. 126 3. Los mecanismos de derivación. Además de la metodología y del lenguaje de modelado, para completar el marco de referencia, se han contemplado mecanismos de derivación que permiten transformar automáticamente modelos diseñados en base a un estándar de HL7, en modelos diseñados en base a otro estándar de HL7. Con el desarrollo de estos mecanismos de derivación, se ha cubierto el siguiente objetivo planteado en el Capítulo III: Definir un conjunto de mecanismos de derivación sistemáticos que habiliten la trazabilidad entre diferentes modelos conformes a diferentes estándares de HL7. 2.3. Herramienta MoDHE Suite para dar soporte al marco de referencia definido Unas de las pretensiones principales desde el inicio del desarrollo de la presente Tesis Doctoral, era que el marco de referencia pudiera llevarse a la práctica para poder utilizarlo en escenarios reales. Para ello, se planteó la necesidad de desarrollar una herramienta de soporte que implementa el marco de referencia abarcando los 3 pilares fundamentales que lo conforman. La herramienta resultante, bautizada como MoDHE Suite, fue desarrollada tomando como base el entorno de NDT-Suite, que a su vez toma como base la herramienta Enterprise Architect. NDT permite diseñar los modelos necesarios para cubrir el ciclo de vida completo de un software (sin necesidad de ser software sanitario). Derivado del uso de NDT-Suite como base de la herramienta desarrollada en la presente Tesis Doctoral, la herramienta MoDHE Suite, además de permitir diseñar modelos de dominio HL7, permite diseñar el resto de modelos necesarios en otras fases del ciclo de vida del software, así como requisitos no sanitarios, si es necesario. Una vez finalizado el desarrollo de MoDHE Suite, se considera cubierto el quinto objetivo planteado en el Capítulo III, que consistía en Desarrollar una versión aplicable de los metamodelos y de los mecanismos de derivación mencionados en los objetivos OE3 y OE4, a través de la implementación de una herramienta CASE que dé soporte a estas definiciones y procesos. Para validar la herramienta MoDHE Suite, se ha utilizado un caso extraído de un escenario real: el proyecto Prevensalud, proyecto en el que participó el Hospital Universitario Virgen del Rocío, donde se creó una red de sistemas interoperables que hacían uso del estándar CDA de HL7. De esta forma se cubre el último objetivo planteado en el Capítulo III, que consistía en Evaluar los resultados obtenidos en un escenario real basado en la instanciación de la solución en un entorno de producción cuya aplicación haya sido considerada como satisfactoria. 3. Trabajos futuros y nuevas líneas de investigación Una vez recapituladas las principales aportaciones realizadas con el desarrollo de la presente Tesis Doctoral, es importante poner en valor que sus resultados propician la apertura de nuevas líneas de investigación que permitirán avanzar en la temática. A continuación se plantean algunos trabajos futuros representativos. 127 3.1. Metodología de ampliación Un aspecto complementario a la presente Tesis Doctoral, es definir la metodología de ampliación que permitirá a un ingeniero del software introducir más estándares de HL7 de cara a enriquecer la herramienta MoDHE Suite y que ésta ofrezca la capacidad de trabajar con cualquier estándar de HL7. A alto nivel, estos son los pasos que se incluirán en dicha metodología: 1. Identificar en qué fase del ciclo de vida del software de NDT se podría enmarcar el estándar de HL7 en cuestión. 2. Extender un metamodelo específico de NDT correspondiente a la fase del ciclo de vida del software donde se enmarca el estándar específico de HL7 a incluir. Extender el perfil UML correspondiente a dicho metamodelo en el mismo sentido. 3. Generar el XML de configuración para EA a raíz del perfil UML extendido. 4. Desplegar dicho XML para que el nuevo estándar aparezca en la paleta de modelado de EA en la fase correspondiente. La metodología de MoDHE ha sido desarrollada intencionadamente con capacidad de ampliación. Definir la metodología de ampliación queda fuera del alcance de la presente Tesis Doctoral, y se plantea como una línea de investigación futura, necesaria para la evolución de la línea de investigación iniciada con la presente Tesis Doctoral. 3.2. Completitud del contexto de uso En el caso del estándar HL7 v3, se ha cubierto el espectro completo de conceptos que presenta su modelo de referencia. En el caso de los estándares HL7 CDA y HL7 v2.x, solo se ha cubierto un porcentaje del amplio espectro que presentan sus modelos de referencia, por presentar una magnitud desproporcionada al alcance de esta Tesis Doctoral. En concreto se han cubierto los elementos que hacen referencia a los datos demográficos de pacientes. El marco de referencia MoDHE se considera cubierto en su totalidad. El trabajo de campo correspondiente a la completitud de los estándares HL7 CDA y HL7 v2.x es un trabajo futuro que se puede articular como ampliaciones a la presente Tesis Doctoral. 3.3. Alinear estándares de HL7 con sistemas de conceptos estándares Existen sistemas de conceptos estándares en el ámbito sanitario, como la norma ISO 13940, que definen el listado de conceptos que se pueden identificar en un escenario concreto. Alinear los conceptos utilizados en los estándares de HL7 con este tipo de sistemas de conceptos, es una tarea ardua y tediosa. 230 Literales: ─ A01 ─ A02 ─ A03 ─ A04 ─ A05 ─ A06 ─ (...) 3.22. Enumerado «0005 - Race» Descripción: Raza. Literales: ─ American Indian or Alaska Native ─ Asian ─ Black or African American ─ Native Hawaiian or Other Pacific Islander ─ White ─ Other Race 3.23. Enumerado «0006 - Religion» Descripción: Afiliación religiosa. Literales: ─ Agnostic ─ Atheist ─ Baha'i ─ Brethren ─ Buddhist ─ (...) 3.24. Enumerado «0061 - Check Digit Scheme» Descripción: Esquema del dígito de control. Literales: ─ Bank Card Validation Number ─ Check digit algorithm in the US National Provider Identifier ─ ISO 7064: 1983 ─ Mod 10 algorithm 231 ─ Mod 11 algorithm 3.25. Enumerado «0062 - Event Reason» Descripción: Causa del evento. Literales: ─ Patient request ─ Physician/health practitioner order ─ Census management ─ Other ─ Unknown 3.26. Enumerado «0076 - Message Type» Descripción: Tipo de mensaje. Literales: ─ ACK ─ ADR ─ ADT ─ BAR ─ (...) 3.27. Enumerado «0103 - Processing ID» Descripción: Tipo de procesado. Literales: ─ Debugging ─ Production ─ Training 3.28. Enumerado «0104 - Version ID» Descripción: Versión. Literales: ─ 2.0 232 ─ 2.0D ─ 2.1 ─ 2.2 ─ 2.3 ─ 2.3.1 ─ 2.4 ─ 2.5 ─ 2.5.1 ─ 2.6 ─ 2.7 3.29. Enumerado «0136 - Yes/no Indicator» Descripción: Indicador booleano. Literales: ─ Yes ─ No 3.30. Enumerado «0155 - Accept/Application Acknowledgment Conditions» Descripción: Condiciones en las que se debe enviar un ACK como respuesta. Literales: ─ Always ─ Never ─ Error/reject conditions only ─ Successful completion only 3.31. Enumerado «0171 - Citizenship» Descripción: Nacionalidad. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.32. Enumerado «0172 - Veterans Military Status» Descripción: Estado militar. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 233 3.33. Enumerado «0188 - Operator ID» Descripción: Identificadores de operadores. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.34. Enumerado «0189 - Ethnic Group» Descripción: Grupo étnico. Literales: ─ Hispanic or Latino ─ Not Hispanic or Latino ─ Unknown 3.35. Enumerado «0190 - Address Type» Descripción: Tipo de dirección. Literales: ─ Bad address ─ Billing Address ─ Birth (nee) (birth address, not otherwise specified) ─ Birth delivery location ─ (...) 3.36. Enumerado «0200 - Name Type» Descripción: Tipo de nombre. Literales: ─ Customary Name ─ OfficialRegistryName ─ TemporaryName ─ NewbornName ─ Assigned ─ Pseudonym ─ (...) 234 3.37. Enumerado «0201 - Telecommunication Use Code» Descripción: Código de uso de un número de telecomunicaciones. Literales: ─ Primary Residence Number ─ Other Residence Number ─ Work Number ─ Vacation Home Number ─ Answering Service Number ─ Emergency Number ─ Network (email) Address ─ Beeper Number ─ Personal 3.38. Enumerado «0202 - Telecommunication Equipment Type» Descripción: Tipo de equipamiento disponible para las telecomunicaciones. Literales: ─ Telephone ─ Fax ─ Modem ─ Cellular or Mobile Phone ─ Satellite Phone ─ Beeper ─ Internet Address ─ X.400 email address ─ Telecommunications Device for the Deaf ─ Teletypewriter 3.39. Enumerado «0203 - Identifier Type» Descripción: Tipo de identificador. Literales: ─ Accession ID ─ American Express ─ American Medical Association Number ─ (...) 235 3.40. Enumerado «0204 - Organizational Name Type» Descripción: Tipo de nombre. Literales: ─ Alias name ─ Legal name ─ Display name ─ Stock exchange listing name 3.41. Enumerado «0207 - Processing Mode» Descripción: Modo de procesamiento. Literales: ─ Archive ─ Restore from archive ─ Initial load ─ Current processing, transmitted at intervals (scheduled or on demand) ─ Not present (the default, meaning current processing) 3.42. Enumerado «0211 - Alternate Character Sets» Descripción: Conjunto de caracteres alternativo. Literales: ─ ASCII ─ 8859/1 ─ 8859/2 ─ 8859/3 ─ 8859/4 ─ 8859/5 ─ (...) 3.43. Enumerado «0288 - Census Tract» Descripción: Sección dentro del censo. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 236 3.44. Enumerado «0289 - County/Parish» Descripción: Condado. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.45. Enumerado «0296 – Primary Language» Descripción: Idioma. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.46. Enumerado «0297 - CN ID Source» Descripción: Origen de los identificadores. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.47. Enumerado «0300 - Namespace ID» Descripción: Identificador del conjunto de nombres. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.48. Enumerado «0301 - Universal ID Type» Descripción: Tipo de identificador universal. Literales: ─ DNS ─ EUI64 ─ CLIA ─ CLIP ─ GUID ─ (...) 3.49. Enumerado «0354 - Message Structure» Descripción: Estructura del mensaje. 237 Literales: ─ ACK ─ ADR_A19 ─ ADT_A01 ─ ADT_A02 ─ (...) 3.50. Enumerado «0356 - Alternate Character Set Handling Scheme» Descripción: Esquema del conjunto de caracteres alternativo. Literales: ─ ISO 2022-1994 ─ 2.3 ─ <null> 3.51. Enumerado «0361 - Application» Descripción: Listado de aplicaciones diponibles para enviar o recibir mensajes. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.52. Enumerado «0362 - Facility» Descripción: Listado de instalaciones disponibles para enviar o recibir mensajes. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.53. Enumerado «0363 – Assigning Authority» Descripción: Listado de autoridades asignadoras. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.54. Enumerado «0396 - Coding System» Descripción: Sistema de codificación. 238 Literales: ─ Local general code ─ American College of Radiology finding codes ─ German Alpha-ID v2006 ─ (...) 3.55. Enumerado «0399 - ISO-3166» Descripción: Idioma. Literales: ─ en ─ es ─ fr ─ de ─ (...) 3.56. Enumerado «0429 - Production Class Code» Descripción: Tipo de código. Literales: ─ Breeding/genetic stock ─ Dairy ─ Draft ─ Dual Purpose ─ Layer, Includes Multiplier flocks ─ Meat ─ Other ─ Pleasure ─ Racing ─ Show ─ Not Applicable ─ Unknown 3.57. Enumerado «0444 - Name Assembly Order» Descripción: Orden de cada componente dentro de un nombre compuesto. Literales: ─ Prefix Given Middle Family Suffix ─ Prefix Family Middle Given Suffix 239 3.58. Enumerado «0445 - Identity Reliability Code» Descripción: Fiabilidad de un código. Literales: ─ Unknown/Default Social Security Number ─ Unknown/Default Date of Birth ─ Unknown/Default Address ─ Patient/Person Name is an Alias 3.59. Enumerado «0446 - Species Code» Descripción: Especie. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.60. Enumerado «0447 - Breed Code» Descripción: Raza. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.61. Enumerado «0448 - Name Context» Descripción: Contexto. Literales: Tabla a definir por el usuario dependiendo del escenario en cuestión. No existe un listado de valores predefinidos. 3.62. Enumerado «0465 - Name/Address Representation» Descripción: Representación de nombres y direcciones. Literales: ─ Ideographic ─ Alphabetic ─ Phonetic 246 Como ejemplo, se muestra la creación de modelos en base al estándar CDA de HL7. Al arrastrar la opción ‘HL7-CDA-ClinicalDocument’, la herramienta muestra la interfaz de usuario correspondiente al Editor de Requisitos de Información (Documento Clínico) (Figura 57). Figura 57. Manual de usuario MoDHE Suite. Editor de documentos clínicos. Datos La primera pestaña del editor, muestra los campos disponibles para modelar el elemento en cuestión, en este caso el documento clínico. En este punto, para cada campo, el usuario tiene disponibles las siguientes opciones:  El check que aparece a la izquierda del nombre del campo, permite al usuario decidir cuales campos desea incluir en su implementación específica del estándar, y cuáles no. Los campos obligatorios aparecen marcados por defecto, y desactivados para que el usuario no pueda desmarcarlos.  A la derecha del nombre del campo, aparece un campo de texto donde el usuario puede indicar comentarios al campo, por ejemplo si debe tomar un valor en cuestión, u otras apreciaciones.  Los campos para los cuales el estándar marca un listado de valores posibles, incluyen un desplegable a la derecha del campo de texto. Este listado solo es informativo, para que el usuario conozca el listado de valores definido por HL7 para un campo en cuestión, listado que debe incluirse en el modelo diseñado. 247 La siguiente figura (Figura 58) muestra la segunda pestaña de la ventana de edición de elementos: Figura 58. Manual de usuario MoDHE Suite. Editor de documentos clínicos. Asociaciones En esta segunda pestaña, se deben marcar las asociaciones que se quieren añadir en el modelo. Se pueden modelar 2 tipos de asociaciones:  Elementos múltiples. En la primera pestaña del editor, aparecen los elementos que solo pueden aparecer una vez. En esta pestaña, aparecen los elementos que se pueden crear más de una vez (en el ejemplo de la Figura 58, Identificador e Identificador conjunto).  Asociaciones con otros elementos. En esta segunda pestaña, aparecen las asociaciones con las que el elemento en cuestión debe o puede relacionarse (en el ejemplo de la Figura 58, Autenticador, Autenticador Legal y Sujeto de la asistencia). Nuevamente, las asociaciones obligatorias según el estándar aparecen marcadas por defecto y desactivadas para que el usuario no pueda crear un modelo sin incluirlas. Una vez detallados los elementos simples, elementos compuestos y asociaciones con otros elementos, el usuario debe pulsar el botón guardar (Figura 59). Figura 59. Manual de usuario MoDHE Suite. Botón guardar 248 Una vez almacenada la información cumplimentada, la herramienta automáticamente activará los elementos relacionados a través de las asociaciones marcadas. En el ejemplo, tras guardar el elemento Documento Clínico, se mostrarán a disposición del usuario los editores de Identificador (Figura 60) y Sujeto de la Asistencia. Figura 60. Manual de usuario MoDHE Suite. Editor de identificador El editor de Sujeto de la Asistencia invoca el editor de Rol de paciente, y éste a su vez invoca el editor de Paciente (Figura 61). Figura 61. Manual de usuario MoDHE Suite. Editor de paciente 249 Todos los editores se utilizan del mismo modo. Si en algún editor no aparece la pestaña de campos, es porque el elemento en cuestión no tiene ningún campo a cumplimentar. Si en algún editor no aparece la pestaña de asociaciones, es porque el elemento en cuestión no presenta asociaciones. En el diagrama de requisitos de información, al crear los elementos mencionados anteriormente, se irá creando una agrupación de elementos similar a la que muestran las siguientes figuras (Figura 62, Figura 63). Figura 62. Manual de usuario MoDHE Suite. Diagrama de requisitos de información (i) 250 Figura 63. Manual de usuario MoDHE Suite. Diagrama de requisitos de información (ii) 2. Transformando modelos en base a un estándar de HL7, en modelos en base a otro estándar de HL7 Una vez modelado un conjunto de elementos en base a un estándar, se pueden ejecutar transformaciones automáticas para obtener unos modelos tomando como entrada los datos previamente especificados en otros modelos. Para iniciar una transformación, se debe seleccionar la opción: ‘Extensions > MoDHE-Suite > MoDHE-Driver’ en la interfaz de EA (Figura 64). Figura 64. Manual de usuario MoDHE Suite. Menú de transformaciones 251 Al pulsar la opción MoDHE-Driver, aparece la pantalla de configuración de transformaciones (Figura 65). Figura 65. Manual de usuario MoDHE Suite. Configuración de transformaciones Las transformaciones que aparecen bajo la etiqueta “ENTRE DIFERENTES FASES” son transformaciones heredadas de NDT-Suite. Las transformaciones que aparecen bajo la etiqueta “DENTRO DE LA FASE DE REQUISITOS” son transformaciones propias de MoDHE Suite. Encontramos 4 transformaciones propias de MoDHE Suite, entre diferentes modelos dentro de la fase de requisitos:  HL7 CDA – HL7 v2.x. Esta transformación toma como entrada los modelos de HL7 CDA diseñados en el diagrama de requisitos de información, y genera nuevos modelos HL7 v2.x con la información contenida en los modelos HL7 CDA.  HL7 v2.x – HL7 CDA. Esta transformación toma como entrada los modelos de HL7 v2.x diseñados en el diagrama de requisitos de información, y genera nuevos modelos HL7 CDA con la información contenida en los modelos HL7 v2.x.  HL7 v3 – HL7 v2.x. Esta transformación toma como entrada los modelos de HL7 v3 diseñados en el diagrama de requisitos de información, y genera nuevos modelos HL7 v2.x con la información contenida en los modelos HL7 v3.  HL7 v2.x – HL7 v3. Esta transformación toma como entrada los modelos de HL7 v2.x diseñados en el diagrama de requisitos de información, y genera nuevos modelos HL7 v3 con la información contenida en los modelos HL7 v2.x. Como ejemplo, se muestra el modo de uso para el caso de la transformación HL7 CDA – HL7 v2.x. 252 Una vez seleccionada la opción ‘HL7 CDA – HL7 v2.x’ de la lista de posibles transformaciones, se debe pulsar el botón Transformar (Figura 66). Figura 66. Manual de usuario MoDHE Suite. Botón para iniciar la transformación Una vez la barra de progreso alcance el 100% (Figura 67), se podrán encontrar en el árbol los 4 elementos autogenerados junto con el documento clínico que el usuario había modelado manualmente (Figura 68). Figura 67. Manual de usuario MoDHE Suite. Progreso de la transformación Figura 68. Manual de usuario MoDHE Suite. Elementos autogenerados Al hacer doble click sobre el elemento SegmentPID, se puede observar cómo la información cumplimentada en el editor de pacientes (Figura 61) aparece automáticamente cumplimentada en el campo correspondiente (Figura 69). 253 Figura 69. Manual de usuario MoDHE Suite. Editor Segmento información del paciente 254 255 Anexo D. Caso Práctico: Prevensalud El proyecto Prevensalud tiene como objetivo principal la creación de un sistema inteligente de prevención de riesgos de salud a partir de historiales clínicos electrónicos distribuidos, a través de la creación de una red de interoperabilidad semántica entre diversos sistemas sanitarios, tanto públicos como privados. Se trata de un proyecto que se llevó a cabo desde 2009 a 2011, liderado por la empresa REDSA, patrocinado por el Living Lab Salud de Andalucía y cofinanciado por la Corporación Tecnológica de Andalucía. El HUVR participó en el proyecto para llevar a cabo un piloto donde demostrar la funcionalidad y usabilidad de la tecnología. La herramienta estuvo funcionando en un entorno productivo hasta diciembre de 2014. La siguiente figura (Figura 70) muestra la estructura general de la red de interoperabilidad semántica que diseñó e implementó el proyecto. Figura 70. Escenario proyecto Prevensalud. Estructura general de la red de interoperabilidad El proyecto cubría 3 casos de uso:  Hemodiálisis. Interconexión con sistemas de centros concertados de hemodiálisis.  Facturación a terceros. Interconexión con sistemas de compañías de seguros.  Derivaciones de resonancias magnéticas. Interconexión con centros concertados de resonancias magnéticas. De estos 3 casos de uso, por limitar el alcance del caso de prueba que se va utilizar para validar la herramienta MoDHE Suite en la presente Tesis Doctoral, solo vamos a profundizar en el primero: Hemodiálisis. En la Unidad de Nefrología del HUVR, y más específicamente en la atención a pacientes con necesidad de hemodiálisis, frecuentemente necesitan aplicar tratamientos para la 262 Figura 76. Informe de derivación. Evolución del paciente en hemodiálisis 263 Figura 77. Informe de derivación. Resumen de Historia Clínica 264 Figura 78. Informe de derivación. Inicio estudio Pretrasplante 7. Modelo CDA utilizado en el proyecto A continuación, las siguientes figuras (Figura 79, Figura 80) muestran el modelo HL7 CDA utilizado en el proyecto Prevensalud. Como cualquier modelo CDA, toma como modelo inicial el modelo completo 50 que define el estándar CDA de HL7, y le realiza restricciones o extensiones a través de una guía de implementación CDA definida en el marco del proyecto. Las clases existentes en el modelo inicial de CDA pero no incluidas en el modelo (restringidas), se han eliminado del modelo. Los atributos existentes en el modelo inicial de CDA pero no incluidas en el modelo (restringidas), se han tachado del modelo. 50 http://www.vico.org/CDAR22005_HL7SP/infrastructure/cda/graphics/L-POCD_RM000040.gif 265 Figura 79. Modelo CDA de Prevensalud. Parte 1 266 Figura 80. Modelo CDA de Prevensalud. Parte 2 267 Anexo E. Actividad Investigadora continuación se presenta la actividad investigadora que ha realizado la doctoranda en los últimos 5 años, haciendo especial hincapié en las publicaciones y participación en proyectos de investigación, así como en certificaciones, realización de estancias de investigación, y participación en comités y cursos relacionados con la presente Tesis Doctoral. 1. Líneas de investigación Ingeniería guiada por modelos, estándares en informática médica (HL7, IHE, ISO 13606, ISO 13940), ingeniería del software, telemedicina, eSalud, interoperabilidad semántica, herramientas de apoyo a la decisión clínica. 2. Estancias Destino: Department of Biomedical Informatics, School of Medicine, University of Utah51 Trabajo a desarrollar: Familiarización y despliegue de la nueva generación de la herramienta OpenCDS52, incluyendo la migración de HL7 vMR a HL7 FHIR Fecha: Del 13 al 28 de Octubre de 2016 Lugar: Salt Lake City, Utah, EEUU 51 http://medicine.utah.edu/dbmi/ 52 http://www.opencds.org/ A 268 3. Publicaciones 3.1. Capítulos de libro Autores: Carlos L. Parra, A. Martínez-García, F. Jódar-Sánchez, A. Moreno-Conde and S. Leal Título: Hospital Universitario Virgen del Rocío: Results in Chronic Obstructive Pulmonary Disease, Multimorbidity and Headache Patients Scenarios Capítulo: 4 Páginas, inicial: 64 final: 75 Fecha: Abril 2014 Editorial: INSTITUTO DE SALUD CARLOS III – MINISTERIO DE ECONOMÍA Y COMPETITIVIDAD Lugar de publicación: Madrid: Unidad de Investigación en Telemedicina y e-Salud – Instituto de Salud Carlos III 3.2. Revistas Autores (p.o. de firma): A. Martínez-García, J.A. García-García, M.J. Escalona, C.L. Parra- Calderón Título: Working with the HL7 metamodel in a Model Driven Engineering context Volumen: 57(2015) Páginas, inicial: 415 final: 424 Fecha: Octubre 2015 Lugar de publicación: Journal of Biomedical Informatics Índice de impacto: 2.126 Autores (p.o. de firma): Alicia Martínez-García, Carlos Luís Parra Calderón Título: Perfil de integración de IHE para movilidad: Mobile access to Health Documents Volumen: 110 Páginas, inicial: 14 final: 17 Fecha: Abril 2015 Lugar de publicación: Revista Informática y Salud (I+S) de la Sociedad Española de Informática y Salud (SEIS) 269 Autores (p.o. de firma): Alicia Martínez-García, Jordi Gabaldá i Azofra, Ana Moraga Ferreira Título: CONTRATACIÓN EFECTIVA A TRAVÉS DEL DIÁLOGO COMPETITIVO Volumen: 108 Páginas, inicial: 18 final: 20 Fecha: Diciembre 2014 Lugar de publicación: Revista Informática y Salud (I+S) de la Sociedad Española de Informática y Salud (SEIS) Autores: Alicia Martínez-García, Carlos Luís Parra Calderón Título: Experiencia del CTN 139 de AENOR en la revisión de la norma ISO 13940 “CONTSYS” Volumen: 107 Páginas, inicial: 7 final: 9 Fecha: Octubre 2014 Lugar de publicación: Revista Informática y Salud (I+S) de la Sociedad Española de Informática y Salud (SEIS) Autores (p.o. de firma): Alicia Martínez-García, Alberto Moreno, Francisco Jódar- Sánchez, Sandra Leal, Carlos Parra Título: Sharing clinical decisions for multimorbidity case management using social network and open-source tools Volumen: 46(6) Páginas, inicial: 977 final: 984 Fecha: Diciembre 2013 Lugar de publicación: Journal of Biomedical Informatic Índice de impacto: 2.131 270 Autores (p.o. de firma): R. González-Otal J. L. López C. L. Parra, A. Martínez, V. Suarez, J. Peinado, A. Moreno, M. J. Ortiz Título: Estudio preliminar sobre extracción automática del tamaño tumoral para la estadificación del cáncer de mama a partir de texto libre de informes clínicos Volumen: 26 (2) Páginas, inicial: 41 final: 46 Fecha: Marzo 2013 Lugar de publicación: Revista de Senología y Patología Mamaria 4. Contribuciones a congresos 4.1. Ponencias Título: Proyectos de innovación del Grupo de Innovación Tecnológica Jornadas: ADAE, Acortando Distancias entre Alumnos y Empresas53 Lugar celebración: Sevilla, España Fecha: 25 de noviembre de 2016 Título: Introducción a los Estándares de Referencia en Informática Sanitaria: HL7 CDA, mensajería HL7 y CONTSYS Asignatura: Proyectos en Informática Clínica de cuarto curso, en la Mención de Informática Clínica del Grado de Ingeniería de la Salud. Lugar celebración: Sevilla, España Fechas: 26 de marzo de 2015, 1 de abril de 2016 53 http://iwt2.org/jornadas-adae/ 271 Título: ISO 13940 (ContSys) Jornada Técnica: Interoperabilidad, la base para una atención integrada del paciente crónico Lugar celebración: Sevilla, España Fecha: 20 de marzo de 2013 4.2. Congresos internacionales / europeos Autores: Santiago Rodríguez-Suarez, Alicia Martínez-García, Salvador García-Morillo, Georgia Karanasiou, Yorgos Goletsis, Dimitris Fotiadis, Carlos Luís Parra Calderón Título: Prospective data gathering to set-up a knowledge management system to target adherence and management of Heart Failure (HF) patients Tipo de participación: Póster Congreso: 15th European Congress of Internal Medicine Lugar celebración: Amsterdam, Países bajos Fecha: 2 al 3 de septiembre de 2016 Autores: Alicia Martínez-García, Salvador García Morillo, Santiago Rodriguez Suarez, Georgia Karanasiou, Dimitris Fotiadis, Roger Fuoco, Wolfram Miekisch, Carlos Luís Parra Calderón Título: Proyecto HEARTEN: ecosistema mHealth para pacientes con Insuficiencia Cardíaca Crónica Tipo de participación: Comunicación oral Congreso: SALUD CONECTADA: II Congreso Iberoamericano de Telesalud y Telemedicina, XIII Reunión del Foro de Telemedicina de la SEIS, XII Reunión del Fórum Ibérico de Telemedicina Lugar celebración: Sevilla, España Fecha: 23 al 25 de noviembre de 2015 278 Autores: A. Moreno, A. Martínez, F. Nuñez, C. Parra Título: Testing a New CDA Development Strategy in a Standardized Infrastructure for Continuity of Care in Chronic Kidney Disease Patients Tipo de participación: Comunicación oral Congreso: International HL7 InteroperabilityConference Publicación: European Journal of Biomedical Informatics, volume 8, no 3, pages 31-36 (2012). Lugar celebración: Vienna Fecha: Septiembre de 2012 Autores: Alicia Martínez García, Alberto Moreno Conde, Carlos Parra Calderón, Francisco Javier Galindo Ocaña, Manuel Ollero Baturone Título: Clinical Wall applied for Polypathological Patient Care Tipo de participación: Comunicación oral Congreso: eTELEMED 2012: The Fourth International Conference on eHealth, Telemedicine, and Social Medicine Lugar celebración: Valencia, Spain Fecha: 30 de enero al 4 de febrero de 2012 4.3. Congresos nacionales / autonómicos Autores: Carlos Luís Parra Calderón, Alicia Martínez-García, María José Garcia Lozano, Francisco Núñez Benjumea, Bosco Barón Franco, Lourdes Moreno Gaviño, Jose María de la Higuera, Manuel Ollero Baturone Título: PITeS-TIiSS: Soporte a la Decisión Personalizada al Paciente Crónico Complejo Tipo de participación: Comunicación oral Congreso: VIII Congreso Nacional de Atención Sanitaria al Paciente Crónico Lugar celebración: Madrid, España Fecha: 7 al 8 de abril de 2016 279 Autores: Germán Antonio Escobar Rodríguez, Pilar Osborne Sánchez-Arjona, Alicia Martínez García, Carlos Luis Parra Calderón Título: Correspondencia entre el proceso asistencial integrado y la ISO/DIS 13940 de continuidad asistencial Tipo de participación: Comunicación oral Congreso: XIX Congreso Nacional de Informática de la Salud Lugar celebración: Madrid, España Fecha: 8 al 10 de marzo de 2016 Autores: J. Moreno Conde, C. L. Parra Calderón, B. David Delgado León, A. Martínez García, A. Moreno Conde, F. Núñez Benjumea, J. L López Guerra Título: Sistema de soporte a la decisión para Oncología Neumológica (S31) Tipo de participación: Comunicación oral Congreso: IV Reunión de la Plataforma Tecnológica para la Innovación en Salud Lugar celebración: Sevilla, España Fecha: 25 al 26 de noviembre de 2015 Autores: Francisco José Núñez Benjumea, Alicia Martínez García, Alberto Moreno Conde, Jesús Moreno Conde, Carlos L. Parra Calderón Título: Plataforma ITC-Bio: Infraestructura de apoyo a la investigación traslacional y clínica Tipo de participación: Comunicación oral Congreso: IV Reunión de la Plataforma Tecnológica para la Innovación en Salud Lugar celebración: Sevilla, España Fecha: 25 al 26 de noviembre de 2015 280 Autores: S. García Morillo, A. Martínez-García, S. Rodriguez Suarez, G. Karanasiou, D. Fotiadis, R. Fuoco, W. Miekisch, M. Sideri Título: ANÁLISIS DE LOS REQUISITOS FUNCIONALES PARA EL DESARROLLO DE UN ENTORNO M-HEALTH EN LA ATENCIÓN DE PACIENTES CON INSUFICIENCIA CARDIACA. PROYECTO HEARTEN Tipo de participación: Póster Congreso: XXXVI Congreso Nacional de la Sociedad Española de Medicina Interna (SEMI) Lugar celebración: Sevilla, España Fecha: 11 al 13 de noviembre de 2015 Autores: José Luis López Guerra, David Blas Delgado León, Jesús Moreno Conde, Alberto Moreno Conde, Carlos Luis Parra Calderón, Alicia Martínez García y María José Ortiz Gordillo Título: PROYECTO S31: UNA HERRAMIENTA INNOVADORA QUE CONTRIBUYE AL DESARROLLO DE COMPETENCIAS BÁSICAS EN INVESTIGACIÓN UNIVERSITARIA CLÍNICA ONCOLÓGICA Tipo de participación: Comunicación oral Congreso: XII FORO INTERNACIONAL SOBRE LA EVALUACIÓN DE LA CALIDAD DE LA INVESTIGACIÓN Y DE LA EDUCACIÓN SUPERIOR Lugar celebración: Sevilla. España Fecha: 9 al 11 de julio de 2015 Autores: J. Moreno; J.L. López; A. Moreno; A. Martínez; F. Núñez; C. L. Parra; M, Ortiz Título: Semantic Support System for Lung Cancer Management Tipo de participación: Póster Congreso: XVIII congreso de SEOR Lugar celebración: Valencia, España Fecha: 4 al 6 de junio de 2015 281 Autores: Raquel Guerrero Vázquez, Alicia Martínez-García, Francisco Jódar Sánchez, Mónica Enríquez Macías, Carmen Ruiz Trillo,Carlos Parra Calderón, María Asunción Martínez Brocca Título: DISEÑO, IMPLANTACIÓN Y VALIDACIÓN CLÍNICA DE UNA PLATAFORMA DE ATENCIÓN TELEMÁTICA PARA PACIENTES CON DIABETES MELLITUS 1 (E-SALUD- DIABETES): RESULTADOS DEL ESTUDIO PILOTO Tipo de participación: Póster Congreso: XXVI Congreso Nacional de la Sociedad Española de Diabetes Lugar celebración: Valencia, España Fecha: 15 al 17 de abril de 2015 Autores: Jacinto Mata Vázquez, Noa Patricia Cruz Díaz, Juan Luis Domínguez Olmedo, Victoria Pachón Álvarez, Manuel de la Villa Cordero, Alberto Moreno Conde, Alicia Martínez García, Carlos Luis Parra Calderón Título: BIDAMIR: BIomedical DAta Mining and Information Retrieval Tipo de participación: Comunicación oral Congreso: XVIII Congreso Nacional de Informática de la Salud, INFORSALUD 2015 Lugar celebración: Madrid, España Fecha: 16 al 18 de febrero de 2015 Autores: J. Moreno Conde, J.L. López Guerra, A. Moreno Conde, A. Martínez García, F. Núñez Benjumea, M, Ortiz Gordillo, C. L. Parra Calderón Título: Ayuda a la toma de decisiones mediante la integración de resultados de investigación traslacional Tipo de participación: Comunicación oral Congreso: XVIII Congreso Nacional de Informática de la Salud, INFORSALUD 2015 Lugar celebración: Madrid, España Fecha: 16 al 18 de febrero de 2015 282 Autores: J. Moreno Conde, J.L. López Guerra, A. Moreno Conde, C. L. Parra Calderón, A. Martínez García, M, Ortiz Gordillo Título: INFRAESTRUCTURA PARA LA INTEGRACION DE LA INVESTIGACION TRASLACIONAL EN LAS DECISIONES CLINICAS EN EL CÁNCER DE PULMÓN Tipo de participación: Comunicación oral Congreso: XIX CONGRESO DE LA SOCIEDAD ANDALUZA DE CANCEROLOGÍA Lugar celebración: Granada, España Fecha: 13 al 14 de noviembre de 2014 Autores: R. De Haro –Piedra, J.L. López Guerra, A. Moreno Conde, C. L. Parra Calderón, A. Martínez García, M, Ortiz Gordillo Título: HERRAMIENTA INFORMATICA INTUITIVA, RAPIDA Y EFICAZ, PARA EL SOPORTE A LA DECISION TERAPEÚTICA EN EL CANCER DE MAMA Tipo de participación: Comunicación oral Congreso: XIX CONGRESO DE LA SOCIEDAD ANDALUZA DE CANCEROLOGÍA Lugar celebración: Granada, España. Fecha: 13 al 14 de noviembre de 2014 Autores: A. MARTÍNEZ-GARCÍA, M.A. MARTÍNEZ-BROCCA, A. SOTO-MORENO, R. GUERRERO-VÁZQUEZ, F. JODAR-SÁNCHEZ, C.L. PARRA-CALDERÓN Título: DESARROLLO Y EVALUACIÓN DE UNA PLATAFORMA DE ATENCIÓN TELEMÁTICA DEL PACIENTE CON DIABETES MELLITUS TIPO 1 Tipo de participación: Comunicación oral Congreso: XII Reunión del Foro de Telemedicina Lugar celebración: Valladolid, España Fecha: 18 al 19 de noviembre de 2014 283 Autores: A. MARTÍNEZ-GARCÍA, MC. GONZALEZ-ORIA, MM. SANCHEZ-CALLE, F. JODARSÁNCHEZ, F. NÚÑEZ-BENJUMEA, D. JIMÉNEZ-HERNÁNDEZ, C. PARRA Título: DISEÑO, DESARROLLO Y EVALUACIÓN DE UN eSERVICIO DE SOPORTE A LA ASISTENCIA INTEGRADA EN PACIENTES CON CEFALEA Tipo de participación: Comunicación oral Congreso: XVI Congreso Nacional de Informática Médica Lugar celebración: Madrid, España. Fecha: 11 al 13 de marzo de 2014 Autores: J. MORENO-CONDE, J. L. LOPEZ-GUERRA, A. MORENO-CONDE, A. MARTÍNEZGARCÍA, R. GONZALEZ-OTAL, M. J. ORTIZ GORDILLO, C. PARRA. Título: PROPUESTA DE PLATAFORMA PARA LA INVESTIGACIÓN TRASLACIONAL ONCOLÓGICA. Tipo de participación: Comunicación oral Congreso: XVII CONGRESO NACIONAL DE INFORMÁTICA DE LA SALUD. Lugar celebración: Madrid, España. Fecha: 11 al 13 de marzo de 2014 Autores: J. Lopez Guerra, A. Moreno, C. Parra, R. Gonzalez, A. Martínez, J. de Leon, B. Vieites, M. Ruiz, M. Lopez, J. Nieto, M. Fernandez, E. Rodriguez, B. Quintana, M. Ortiz Título: Machine learning techniques to improve therapeutic decision-making in breast cancer Tipo de participación: Video Congreso: XVII Congreso Nacional de la SEOR Publicación: Reports of Practical Oncology & Radiotherapy, Volume 18, Supplement 1, June 2013, Page S126. Lugar celebración: Vigo Fecha: 18 al 21 de junio de 2013 284 Autores: J. L. López, R. González, C. L. Parra , A. Martínez, J. Peinado, V. Suarez, B. Quintana, M.C. Fernández, A. Moreno, M. J. Ortiz Título: Application of Artificial Intelligence for Breast Cancer Classification before Radiatiotherapy Tipo de participación: Póster Congreso: XVII Congreso Nacional Sociedad Española de Radioterapia y Oncología Publicación: Reports of Practical Oncology & Radiotherapy, Volume 18, Supplement 1, June 2013, Pages S391-S392. Lugar celebración: Vigo Fecha: 18 al 21 de junio de 2013 Autores: R. González Otal, J. L. López Guerra, C. L. Parra Calderón , A. Martínez García, V. Suarez Gironzini , J. Peinado Serrano , A. Moreno Conde, A. García Escudero y M. J. Ortiz Gordillo Título: Estudio sobre Extracción Automática del Tamaño Tumoral en el Cáncer de Mama a partir de Informes Clínicos de Anatomía Patológica Tipo de participación: Póster Congreso: XXVI Congreso de la Sociedad Española de Anatomía Patológica y División Española de la Academia Internacional de Patología Lugar celebración: Cádiz Fecha: 22 al 24 de mayo de 2013 Autores: A. Martínez-García, M.J. Escalona, C.L. Parra-Calderón Título: El metamodelo de HL7 en el contexto de la Ingeniería Dirigida por Modelos Tipo de participación: Comunicación oral Congreso: XV Congreso Nacional de Informática Médica Lugar celebración: Madrid Fecha: Abril de 2013 285 Autores: J. L. López Guerra, R. González Otal, C. L. Parra Calderón, A. Martínez García, V. Suarez Gironzini, J. Peinado Serrano, A. Moreno Conde y M. J. Ortiz Gordillo Título: Aplicación de Inteligencia Artificial en la Clasificación por Tamaño Tumoral en Cáncer de Mama Tipo de participación: Comunicación oral Congreso: XVIII Congreso de la Sociedad Andaluza de Cancerología Lugar celebración: Jaén Fecha: Noviembre de 2012 Autores: J. L. López Guerra, R. González Otal, C. L. Parra Calderón, A. Martínez García, V. Suarez Gironzini, J. Peinado Serrano, A. Moreno Conde y M. J. Ortiz Gordillo Título: Aplicación de Inteligencia Artificial en la Clasificación por Tamaño Tumoral en Cáncer de Mama Tipo de participación: Póster Congreso: Congreso de la Sociedad Española de Senología y Patología Mamaria Publicación: Revista de Senología y Patología Mamaria. ISSN 0214-1582. Página 87. Lugar celebración: Barcelona Fecha: 18 al 20 de octubre de 2012 Autores: F. Jódar Sánchez, C. Parra Calderón, A. Martínez García, A. Moreno Conde y S. Leal González Título: Muro clínico: herramienta 2.0 aplicada a la asistencia de pacientes pluripatológicos Tipo de participación: Comunicación oral Congreso: XXXII Jornadas de Economía de la Salud: El reto de la gestión eficiente de la cronicidad Publicación: GacSanit. 2012; 26(EspecCongr 1):29. ISSN: 0213-9111. Lugar celebración: Bilbao Fecha: 15 al 18 de mayo de 2012 286 Autores: A. Martínez-García, C.L. Parra-Calderón, A. Moreno-Conde, F.J. Galindo-Ocaña, V. Rodríguez-Pappalardo, M. Ollero-Baturone, S. Leal-González Título: Muro Clínico aplicado a la asistencia de Pacientes Pluripatológicos Tipo de participación: Comunicación oral Congreso: INFORSALUD 2012: XV Congreso Nacional de Informática de la Salud Publicación: Libro de Comunicaciones INFORSALUD 2012. XV Congreso Nacional de Informática de la Salud. ISBN: 978-84-695-2722-1. Lugar celebración: Palacio de Congresos de Madrid Fecha: 20 al 22 de marzo de 2012 Autores: M. A. Ortiz Camúñez, V. Rodríguez Pappalardo, P. Bohórquez Colombo, D. Nieto Martín, A. Martínez García y M. Ollero Baturone Título: Desarrollo de un proyecto de telemedicina para la atención a Pacientes Pluripatológicos Tipo de participación: Póster Congreso: IV Congreso Nacional de Atención Sanitaria al Paciente Crónico Lugar celebración: Auditorio de la Diputación de Alicante Fecha: 8 al 10 de marzo de 2012 5. Participación en proyectos de I+D+i 5.1. Financiados en convocatorias públicas Título del proyecto: KNOWBED: Sistema de apoyo a la decisión clínica en movilidad basado en la integración del conocimiento científico a pie de cama Número de expediente: PIN-0213-2016 Entidad financiadora: Consejería de Salud Entidades participantes: GIT del HUVR, UGC Pediatría del HUVM, Servicio de Coordinación de Sistemas de Información del SAS, Digitalica Salud S.L. Duración, desde: 01/01/2017 hasta: 30/06/2018 Investigador responsable: Alicia Martínez García 287 Título del proyecto: POLOLAS: Explorando soluciones guiadas para sistematizar el aseguramiento temprano de la calidad del software Número de expediente: TIN2016-76956-C3-2-R Entidad financiadora: Ministerio de Economía y Competitividad Entidades participantes: Universidad de Sevilla, Universidad de Oviedo, Universidad de Cádiz Duración, desde: 2016 hasta: 2019 Investigador responsable: María José Escalona Cuaresma, Manuel Mejías Risoto Título del proyecto: IDE4ICDS: Integrated Development Environment for Improving Clinical Decision Support based on Clinical Guidelines Número de expediente: SRTC1600C004793XV0 Entidad financiadora: Ministerio de Economía y Competitividad Entidades participantes: Soltel, Universidad de Sevilla, Hospital Universitario Virgen del Rocío, Serviguide Duración, desde: 01/05/2016 hasta: 30/04/2019 Investigador responsable: Alicia Martínez García Título del proyecto: SmokeFreeBrain: Multidisciplinary tools for improving the efficacy of public prevention measures against smoking Número de expediente: 400200100800 Entidad financiadora: Comisión Europea Duración, desde: 01/11/2015 hasta: 31/10/2018 Investigador responsable: Carlos Luís Parra Calderón 294 5.2. Financiados en convocatorias privadas Título del proyecto: Semagnition Número de expediente: 00087865 / ITC-20151099 Entidad financiadora: CDTI (Centro para el Desarrollo Tecnológico Industrial) Entidades participantes: Hospital Universitario Virgen del Rocío, IECISA, Treelogic Yerbabuena Software Duración, desde: 01/01/2015 hasta: 31/12/2017 Investigador responsable: Jose Manuel Raposo Villamor Título del proyecto: BigData T-Systems. Prueba de concepto de cálculo y visualización de indicadores complejos de gestión hospitalaria basado en Big Data. Entidad financiadora: T-Systems Entidades participantes: T-Systems, HUVR Duración, desde: 2015 hasta: 2016 Investigador responsable: Carlos Luis Parra Calderón Título del proyecto: Creación de un sistema inteligente de prevención de riesgos de salud a partir de historiales clínicos electrónicos distribuidos (Prevensalud) Entidad financiadora: Corporación Tecnológica de Andalucía Entidades participantes: Hospital Universitario Virgen del Rocío, REDSA. Duración, desde: 2009 hasta: 2011 Investigador responsable: Sandra Leal González 295 6. Registros de propiedad intelectual de software Inventores: Alicia Martinez Garcia, Maria Jose Escalona Cuaresma, Francisco José Domínguez Mayo, Carlos Luis Parra Calderon Título: MODHE SUITE –HERRAMIENTA SOFTWARE PARA EL DISEÑO DE MODELOS DE INFORMACIÓN SANITARIA BASADOS EN LOS ESTÁNDARES DE HL7 N. de solicitud: Pendiente de concesión Fecha: Pendiente de concesión Entidad titular: UNIVERSIDAD DE SEVILLA, SERVICIO ANDALUZ DE SALUD Inventores: Julian Alberto Garcia Garcia, Maria Jose Escalona Cuaresma, Gustavo Aragón Serrano, Alicia Martinez Garcia, Carlos Luis Parra Calderon, Alberto Moreno Conde Título: ADAPTACIÓN DE LA PLATAFORMA DE eSALUD A UNA ARQUITECTURA DE PROCESOS BASADA EN SOA N. de solicitud: SE-319-15 (número de concesión 201599900539332) Fecha: 06/04/2015 Entidad titular: SERVICIO ANDALUZ DE SALUD Inventores: Alicia Martínez García, Ricardo Gonzalez Otal, María José Ortiz Gordillo, Carlos Luis Parra Calderón, Jose Luis Lopez Guerra, Alberto Moreno Conde Título: SISTEMA DE INFORMACIÓN PARA LA ASISTENCIA INTEGRADA ONCOLÓGICA DE PACIENTES CON CÁNCER DE MAMA. N. de solicitud: SE-315-14 (número de concesión 201499900444870) Fecha: 28/03/2014 Entidad titular: SERVICIO ANDALUZ DE SALUD. FUNDACIÓN PÚBLICA ANDALUZA PARA LA GESTIÓN DE LA INVESTIGACIÓN EN SALUD DE SEVILLA (FISEVI). 296 7. Participación en comités Título del Comité: AEN/CTN139/GT2 Plataformas de telesalud y teleasistencia Entidad de la que depende: AENOR Tema: Definir los requisitos funcionales que debe tener una plataforma de telemedicina. Fecha: Desde abril 2013 hasta Actualidad Título del Comité: AEN/CTN139/GT1 Interoperabilidad organizativa Entidad de la que depende: AENOR Temas: Entre otros, revisión de la norma ISO 13940, traducción de la norma ISO 13940. Fecha: Desde enero 2013 hasta Actualidad Título del Comité: Comité Técnico HL7 SPAIN: Grupo de Trabajo Guía de CDA de Espirometría Entidad de la que depende: HL7 SPAIN Tema: Definición de una guía de implementación CDA de Espirometría Fecha: Desde Julio 2011 hasta agosto 2012 8. Revisión de artículos científicos Congreso: European Federation for Medical Informatics, Special Topic Conference 2016 Organización: European Federation for Medical Informatics Fecha colaboración: Desde octubre 2015. Revista: Journal of Biomedical Informatics Editorial: El Sevier Fecha colaboración: Desde septiembre 2015. 297 Revista: Applied Computing and Informatics Editorial: El Sevier Fecha: Desde septiembre 2014. 9. Experiencia en organización de actividades de I+D Título: SALUD CONECTADA. II Congreso Iberoamericano de Telesalud y Telemedicina. XIII Reunión Foro de Telemedicina de la SEIS. XII Reunión del Fórum Ibérico de Telemedicina Tipo de actividad: Moderadora en una sesión Fecha: 23 al 25 de noviembre 2015 Título:2ª Asamblea anual de la Plataforma ITEMAS Tipo de actividad: Secretaria Científica Fecha: 24 al 25 de noviembre 2014 Título: Órgano Técnico de trabajo de normalización CTN139 de AENOR Tipo de actividad:Portavoz designado en representación a FISEVI Fecha: Desde el 6 de octubre de 2014 hasta la actualidad Título: XXI Jornadas Nacionales de Informática Sanitaria en Andalucía. “Hacia una guía efectiva para la contratación y financiación de proyectos TIC” Tipo de actividad: Secretaria Científica Fecha: 11 al 13 de junio 2014 298 Título: XII Feria de la Ciencia Tipo de actividad: Divulgador de proyectos de innovación Fecha: Mayo 2014 Título: XI Feria de la Ciencia Tipo de actividad: Divulgador de proyectos de innovación Fecha: Mayo 2013 10. Certificaciones Certificación: Certified HL7 V2.7 Chapter 2 Control Specialists Entidad certificadora: HL7 International Fecha: Junio 2012 Certificación: Certified HL7 CDA Specialists Entidad certificadora: HL7 International Fecha: Junio 2011 11. Cursos Curso: La transferencia de tecnología en Ciencias de la Salud Entidad: Fundación Progreso y Salud Número de horas: 35 horas Fecha: Septiembre 2015 – noviembre 2015 299 Curso: Propiedad industrial e intelectual Entidad: Fundación Progreso y Salud Número de horas: 45 horas Fecha: Junio 2015 – agosto 2015 Curso: Curso de UML para HL7 “Practitioners” Entidad: HL7 Spain Número de horas: 50 horas Fecha: Octubre 2011 – enero 2012