Diseño y desarrollo del sistema sanitario de prescripción según el Real Decreto-Ley 9/2011

Diseño y desarrollo del sistema sanitario de prescripción según el Real Decreto-Ley 9/2011 Autor: Iván Garrido Vargas Director de Tesis: Vicente Pelechano Ferragud Índice Página 2 Índice 1 Introducción .......................................................................................................................... 6 1.1 Antecedentes ................................................................................................................ 7 1.2 Motivación .................................................................................................................... 8 1.3 Objetivos ....................................................................................................................... 8 1.4 Estructura de la tesina ................................................................................................... 9 2 Visión general del sistema de información existente ......................................................... 11 2.1 Sistema de Información Poblacional ........................................................................... 12 2.2 Sistema de Catálogos y Recursos ................................................................................ 14 2.3 Sistema de Citas e Historia Clínicas ............................................................................. 16 2.4 Repositorio de Medicamentos .................................................................................... 18 2.5 Sistema de Prescripción y Prestación Farmacéutica ................................................... 20 2.5.1 Módulo de Prescripción ...................................................................................... 20 2.5.2 Módulo de Tareas y Servicios .............................................................................. 25 2.6 Sistema de Receta Electrónica .................................................................................... 27 2.7 Sistema de Facturación de la Prestación Farmacéutica .............................................. 31 2.8 Sistema de Visados de Inspección ............................................................................... 31 3 Análisis Funcional ................................................................................................................ 34 3.1 Texto legal ................................................................................................................... 34 3.1.1 Texto literal del nuevo artículo 85 de la Ley de Garantías .................................. 34 3.1.2 Resumen .............................................................................................................. 35 3.1.3 Necesidad terapéutica ........................................................................................ 35 3.1.4 Prescripción de principios activos asociados ...................................................... 36 3.2 Sistemas afectados ...................................................................................................... 36 3.3 Repositorio de Medicamentos .................................................................................... 37 3.3.1 Mantenimiento de los motivos de superación del precio menor ....................... 37 3.3.2 Justificar la prescripción de principios activos asociados ................................... 39 3.3.3 Modificaciones en la duplicación de presentaciones farmacéuticas .................. 40 3.3.4 Modificaciones en la utilidad de replica de datos entre presentaciones farmacéuticas ...................................................................................................................... 40 3.4 Módulo de prescripción .............................................................................................. 42 3.4.1 Justificar la prescripción de principios activos asociados ................................... 44 3.4.2 Modificaciones en la búsqueda y selección de productos/presentaciones ........ 44 3.4.3 Modificaciones en el proceso de prescripción de un nuevo tratamiento .......... 54 3.4.4 Modificaciones en las acciones disponibles para los tratamientos .................... 54 Índice Página 3 3.4.5 Limitar el número de tratamientos prescritos con excepciones mensualmente 57 3.4.6 Modificaciones en las acciones de impresión de recetas disponibles ................ 57 3.4.7 Modificación de los informes .............................................................................. 58 3.4.8 Impacto en los tratamientos no electrónicos ..................................................... 59 3.4.9 Modificaciones en la receta ................................................................................ 60 3.5 Módulo de Tareas y Servicios ...................................................................................... 62 3.5.1 Tarea de Generación de Recetas ......................................................................... 62 3.6 Nuevo Módulo de Sustitución de Tratamientos ......................................................... 62 3.6.1 Sustitución por Prescripción por Principio Activo (PPA) ..................................... 62 3.6.2 Sustitución de Productos de Baja ........................................................................ 66 4 Análisis Técnico ................................................................................................................... 67 4.1 Repositorio de Medicamentos .................................................................................... 67 4.1.1 Motivos de superación del precio menor ........................................................... 67 4.1.2 Justificación de los principios activos asociados ................................................. 68 4.2 Módulo de prescripción .............................................................................................. 69 4.2.1 Soporte a las justificaciones en los tratamientos y recetas ................................ 69 4.3 Módulo de Tareas y Servicios ...................................................................................... 70 4.3.1 Tarea de Generación de Recetas ......................................................................... 70 4.3.2 Ampliación del módulo de Servicios Web ........................................................... 73 4.3.3 Cola de ejecución de tareas ................................................................................ 79 4.4 Nuevo Módulo de Sustitución de Tratamientos ......................................................... 86 5 Desarrollo realizado ............................................................................................................ 87 5.1 Módulo de Tareas y Servicios ...................................................................................... 87 5.1.1 Tarea de Generación de Recetas ......................................................................... 88 5.1.2 Implementación de los Servicios Web ................................................................ 89 5.1.3 Implementación de la cola de ejecución de tareas ............................................. 92 5.2 Nuevo Módulo de Sustitución de Tratamientos ......................................................... 98 6 Implantación del sistema .................................................................................................. 103 7 Conclusiones...................................................................................................................... 108 8 Glosario ............................................................................................................................. 109 9 Referencias ........................................................................................................................ 112 10 Anexos ........................................................................................................................... 113 10.1 Anexo 1 (Nota de prensa del RDL 9/2011) ................................................................ 114 10.2 WSDL para los Servicios Web .................................................................................... 115 Índice de Figuras Página 4 Índice de Figuras Figura 1 - Composición del sistema de información sanitario .................................................... 12 Figura 2 - Modelo básico del Sistema de Catálogos y Recursos .................................................. 15 Figura 3 - Modelo básico del Sistema de Citas e Historia Clínicas .............................................. 17 Figura 4 - Modelo básico del Repositorio de Medicamentos ..................................................... 19 Figura 5 - Formulario de Prescripción ......................................................................................... 21 Figura 6 - Modelo básico del Sistema de Prescripción y Prestación Farmacéutica .................... 22 Figura 7 - Sistema de Receta Electrónica y sus servicios ............................................................. 28 Figura 8 - Visión general de los sistema que intervienen en la Receta Electrónica .................... 29 Figura 9 - Modelo básico del Sistema de Receta Electrónica ..................................................... 30 Figura 10 - Modelo básico del Sistema de Visados de Inspección .............................................. 33 Figura 11 - Modelo UML de actores del sistema......................................................................... 37 Figura 12 - Repositorio de Medicamentos, formulario de mantenimiento de motivos justificativos ................................................................................................................................ 38 Figura 13 - Repositorio de Medicamentos, mantenimiento de motivos justificativos en modo edición ......................................................................................................................................... 39 Figura 14 - Repositorio de Medicamentos, fragmento de la ficha de la presentación farmacéutica ............................................................................................................................... 40 Figura 15 - Repositorio de Medicamentos, utilidad de replica de datos .................................... 41 Figura 16 - Módulo de prescripción, búsqueda de productos sin excepciones .......................... 46 Figura 17 - Módulo de prescripción, búsqueda de productos con excepciones ......................... 47 Figura 18 - Módulo de prescripción, introducción de justificaciones (I) ..................................... 48 Figura 19 - Módulo de prescripción, introducción de justificaciones (II) .................................... 49 Figura 20 - Módulo de prescripción, algoritmo de selección de presentación ........................... 50 Figura 21 - Módulo de prescripción, algoritmo de selección de producto ................................. 51 Figura 22 - Módulo de prescripción, algoritmo de solicitud de justificaciones .......................... 52 Figura 23 - Módulo de prescripción, selección de favoritos ....................................................... 53 Figura 24 - Módulo de prescripción, formulario de prescripción ............................................... 54 Figura 25 - Módulo de prescripción, algoritmo para permitir gestionar un tratamiento existente ..................................................................................................................................................... 56 Figura 26 - Módulo de prescripción, informe de tratamientos vigentes .................................... 59 Figura 27 - Módulo de prescripción, formato de receta impresa ............................................... 61 Figura 28 - Módulo de Sustitución de Tratamientos, prescripción por principio activo (I) ........ 63 Figura 29 - Módulo de Sustitución de Tratamientos, selección de nueva presentación o producto ...................................................................................................................................... 64 Figura 30 - Módulo de Sustitución de Tratamientos, prescripción por principio activo (II) ....... 66 Figura 31 - Modelo motivos de superación del precio menor .................................................... 67 Figura 32 - Modelo de presentación farmacéutica ..................................................................... 68 Figura 33 - Modelo de tratamiento y prescripción modificado .................................................. 69 Figura 34 - Modelo de clases de la tarea de generación de recetas ........................................... 71 Figura 35 - Tarea de generación de recetas ................................................................................ 72 Figura 36 - Módulo de Tareas y Servicios, y los nuevos servicios publicados ............................. 73 Índice de Figuras Página 5 Figura 37 - Modelo para la gestión de tareas de sustitución ...................................................... 76 Figura 38 - Modulo de Tareas y Servicios, estado de los mensajes en las colas ......................... 79 Figura 39 - Modelo para la gestión de mensajes y colas ............................................................. 82 Figura 40 - Módulo de Sustitución de Tratamientos, y los nuevos clientes de Servicios Web ... 86 Figura 41 - Módulo de Tareas y Servicios, arquitectura del proyecto ........................................ 87 Figura 42 - Web Service de Sustituciones, clases generadas ...................................................... 90 Figura 43 - Módulo de Tareas Y Servicios, implementación del sistema de colas y ejecución de tareas ........................................................................................................................................... 93 Introducción Página 6 1 Introducción El actual clima de incertidumbre, producto de la crisis nacional e internacional, ha propiciado que el Gobierno de España, junto a sus socios europeos, continúe adoptando medidas fiscales y presupuestarias para la consecución de los objetivos de reducción de déficit público y consolidación fiscal que se han fijado en el seno de la Unión Europea. El contexto económico que nos rodea está obligando a que las políticas públicas se orienten más que nunca hacia escenarios de austeridad y racionalidad del gasto público, de forma que, permitan mantener un nivel adecuado de los servicios públicos sin menoscabar la equidad y calidad de los mismos. El Sistema Nacional de Salud (S.N.S.), como parte esencial del estado del bienestar y motor relevante del desarrollo económico y social de nuestro país, supone una parte muy importante del gasto público del estado. El uso intensivo de los recursos que son necesarios para el mantenimiento de nuestro Sistema Nacional de Salud, y la actual coyuntura económica, están provocando grandes tensiones financieras que el Gobierno de España pretende abordar con la intención de mantener la sostenibilidad del sistema. El Gobierno de España aprobó y publicó en el Boletín Oficial del Estado (B.O.E.), el viernes 19 de agosto de 2011, el Real Decreto-Ley 9/2011 que contiene un conjunto de medidas para la mejora de la calidad y cohesión del sistema nacional de salud, de contribución a la consolidación fiscal, y de elevación del importe máximo de los avales del Estado para 2011. En el Real Decreto-Ley se han concretado una serie de medidas de austeridad en la prestación farmacéutica que pretenden aliviar la tensión financiera que se están generando en los servicios de salud, junto a otro conjunto de medidas que pretenden mejorar la equidad, la cohesión y la calidad de Sistema Nacional de Salud, como la optimización de la aplicación de las nuevas tecnologías en los sistemas de información sanitaria y la mejora de la coordinación de la atención socio-sanitaria. La principal medida de austeridad que se contempla en el Real Decreto-Ley es la obligatoriedad de realizar la prescripción por principio activo en todos los supuestos, excepto en aquellos casos que por necesidades terapéuticas, el paciente requiera la utilización de una marca comercial concreta. Con esta medida, el Gobierno y el Ministerio de Sanidad, estiman que el ahorro puede alcanzar la cifra de 2.400 millones anuales, lo que supondría un ahorro aproximado del 20% del gasto farmacéutico anual del Estado. En este contexto, los sistemas de información sanitarios de los que disponen las diferentes comunidades autónomas deberán incorporar todos aquellos aspectos legales incluidos en la nueva normativa. Introducción Página 7 El sistema de información sanitario se puede dividir en un subconjunto de sistemas con diferentes ámbitos de aplicación muy definidos, por ejemplo, tenemos los sistemas encargados de la información de los pacientes y la emisión de su TSI (Tarjeta Sanitaria Individual), los sistemas que hacen posible el uso de la historia clínica electrónica o los sistemas dedicados a mejorar la prestación farmacéutica, entre otros muchos. El sistema de información sanitario, y de manera más concreta, todos aquellos sistemas involucrados en la prestación farmacéutica deben adaptarse antes del 1 de noviembre para cumplir con los plazos legalmente establecidos. El sistema de prescripción, que forma parte del sistema de información utilizado en algunas comunidades autónomas, es el sistema que más afectado se ha visto, dado que se deben revisar todos sus procesos de prescripción, así como contemplar la modificación de los millones de prescripciones médicas que se encuentran vigentes en la actualidad, y que no cumplirán con la nueva normativa una vez que haya entrado en vigor. Finalmente, también es necesario realizar una profunda revisión de los sistemas de receta electrónica y facturación que son utilizados por las comunidades, también pertenecientes al área de prestación farmacéutica, para tener en cuenta las nuevas condiciones de prescripción y dispensación impuestas desde el Gobierno. 1.1 Antecedentes Con anterioridad, y debido a diferentes situaciones, se han tenido que preparar procesos masivos para la actualización de los miles de prescripciones médicas que se veían afectadas por cambios en sus condiciones tanto legales como de comercialización. Normalmente se han tenido que desarrollar este tipo de procesos cuando los medicamentos que se encontraban dentro de la prestación farmacéutica, han dejado de estarlo, y por lo tanto, todos aquellos tratamientos y prescripciones médicas que utilizaban dichos medicamentos han tenido que modificarse, en algunas ocasiones sustituyendo el medicamento por otros que si estaban financiados, y en otros casos, interrumpiendo aquellos tratamientos que no tenían una alternativa financiada. En otras ocasiones se han preparado procesos de este tipo, bien porque su medicamento ha dejado de comercializarse, por alertas farmacéuticas que impiden la comercialización de los mismos, etc. El procedimiento habitual en estos casos ha sido preparar diferentes scripts de base de datos, con las condiciones particulares que requiere cada caso, escritos en PL/SQL, y con instrucciones concretas, proporcionadas por el organismo competente, del tipo de modificación a realizar en las prescripciones médicas. Introducción Página 8 La ejecución de este tipo de scripts impide controlar a los médicos las diferentes acciones que se realizan sobre los tratamientos de sus pacientes, y por lo tanto, se realizan sin atender las necesidades particulares de cada uno de ellos. Desde el punto de vista técnico, estos procesos son muy complejos dado el gran volumen de datos que deben manejar, y las limitaciones impuestas por el software utilizado que no permiten tener un excesivo control sobre los mismos: ventanas de ejecución en horario de baja actividad, número de prescripciones procesadas concurrentemente, distribución de la carga entre diferentes servidores, etc. 1.2 Motivación El trabajo desarrollado en esta tesina viene motivado por la publicación del Real Decreto-Ley 9/2011 sobre la prescripción por principio activo, para proporcionar una herramienta que permita gestionar las modificaciones necesarias sobre los millones de prescripciones médicas que incumplen la citada ley, así como, la necesidad de actualizar los sistemas de información sanitarios, especialmente aquellos relacionados con la prestación farmacéutica. Dicha necesidad es planteada por las diferentes comunidades autónomas que contratan los servicios de Indra Sistemas S.A. como principal proveedor de los sistemas de información utilizados en el ámbito sanitario. 1.3 Objetivos El objetivo principal de la tesina es desarrollar una herramienta que permita gestionar las modificaciones necesarias sobre los millones de prescripciones médicas, que desde el 1 de noviembre de 2011 incumplen la normativa vigente, debido a la publicación del Real Decreto Ley 9/2011, que obliga a realizar la prescripción médica por principio activo, excepto en aquellos casos que esté justificado por una necesidad terapéutica. La gran cantidad de prescripciones existentes, así como los controles que se aplican sobre cada una de ellas, hacen que la viabilidad técnica de este tipo de procesos sea muy compleja. Por otro lado, aunque no menos importante, estudiaremos las adaptaciones que serán necesarias en los sistemas implicados en la prestación farmacéutica para que las nuevas prescripciones médicas se realicen dentro del nuevo marco legal. El fin es proporcionar a los profesionales sanitarios las herramientas necesarias para adaptarse a la nueva legalidad vigente, de la forma menos traumática posible, y que puedan seguir desarrollando su trabajo, con todas las facilidades que las nuevas tecnologías aportan. Para poder afrontar con garantías los objetivos marcados, se plantean los siguientes puntos: 1. Analizar en profundidad los cambios normativos que se desprenden de la publicación del Real Decreto-Ley 9/2011, tanto desde el punto de vista funcional, como técnico. Introducción Página 9 2. Desarrollar un sistema de alta disponibilidad que permita la transformación de todas aquellas prescripciones médicas que no cumplen con la nueva normativa. a. Para ello habrá que tener en cuenta las dificultades derivadas de la gran cantidad de recetas existentes que hay que modificar. b. Se desea facilitar una herramienta que permita al personal sanitario tomar la última decisión sobre los cambios a efectuar en los tratamientos de sus pacientes. c. Dicha herramienta debe ser fácilmente ampliable para poder reutilizarla en futuros procesos de este tipo. 1.4 Estructura de la tesina La estructura principal de esta tesina está dividida en 7 capítulos: En el capítulo 1 se realiza una introducción sobre el actual contexto económico, lo que ha provocado la publicación de la nueva normativa, y los cambios que esto supone en el ámbito sanitario. De la misma forma, se realiza una breve introducción a los sistemas sanitarios utilizados por las diferentes comunidades autónomas, mostrando aquellos que principalmente se han visto afectados por el Real Decreto-Ley 9/2011. Finalmente se define la motivación del trabajo desarrollado y los objetivos que se han planteado en el mismo. En el capítulo 2 se describe de forma general el sistema de información sanitario que se están utilizando en algunas comunidades autónomas para poner en contexto los diferentes sistemas que existen, y la utilidad de cada uno de ellos. Esto nos proporcionará una visión más clara de los sistemas que se ven afectados por la nueva normativa. En el capítulo 3 se analiza en profundidad, desde el punto de vista funcional, lo que supone la publicación del Real Decreto-Ley 9/2011. En este capítulo se analizarán en detalle todos aquellos sistemas que se han visto afectados, mostrando todos los cambios funcionales que deben aplicarse para poder cumplir con la nueva normativa, así como el tratamiento que habrá que realizar de las prescripciones médicas ya existentes. En el capítulo 4 se analiza desde el punto de visto técnico todos aquellos cambios funcionales descritos en el capítulo anterior, centrándonos con especial interés, en el proceso de generación de prescripciones médicas y la infraestructura necesaria para la construcción del nuevo sistema de modificación masiva de prescripciones médicas. En el capítulo 5, se hace una revisión del trabajo desarrollado centrando nuestra atención en aquellos procesos que se han descrito en el análisis técnico con un mayor nivel de detalle. En el capítulo 6 se describe la implantación llevada a cabo en los centros de datos de las comunidades autónomas de los nuevos sistemas de información en el momento en que entraba en vigor el RDL publicado. Visión general del sistema de información existente Página 16 Como se puede apreciar en la figura, cualquier profesional puede tener asignado varios recursos, es ocurre habitualmente en zonas rurales, donde un médico pasa consulta en consultorios de diferentes localidades, o personal de cualquier tipo, que realiza sustituciones en diferentes puestos, etc. Finalmente, este sistema suele proporcionar otra serie de catálogos de menor interés para nuestro estudio, como son los catálogos de países, comunidades, provincias, localidades, etc. 2.3 Sistema de Citas e Historia Clínicas El siguiente subsistema es una de las piezas claves en los sistemas de información sanitarios que se han implantado en las diferentes comunidades. Vamos a comentar a lo largo del siguiente capítulo alguno de los principales cometidos que tiene esta aplicación en el ámbito sanitario, y de esta forma, veremos el porqué de su importancia dentro del sistema de información. El principal cometido de este sistema es la posibilidad de crear, editar y mantener la historia clínica asociada a cada uno de los pacientes que acude a los servicios sanitarios incluidos en el estado del bienestar, y que son ofertados y mantenidos por la comunidad autónoma. La historia clínica, también conocido por expediente clínico, es un documento legal que se cumplimenta por parte del profesional de la salud (médico, enfermero, etc.), en el cual se recoge la información necesaria para la correcta atención del paciente. La historia clínica es un documento válido desde el punto de vista clínico y legal, que recoge información de tipo asistencial, preventivo y social. En nuestro sistema de información, la historia clínica se compone por un conjunto de hojas de seguimiento ordenadas que pueden ser ordenadas por orden cronológico (habitualmente utilizado en hospitales), o por el contrario, se permite agrupar y ordenar por los diferentes problemas de salud (utilizada comúnmente en los centros de atención primaria) que presenta el paciente. La información que contiene la historia clínica, o en este caso, cada una de las diferentes hojas de seguimiento, se puede dividir en cinco apartados principales claramente diferenciados:  En primer lugar se encuentra la información subjetiva aportada por el paciente cuando se realiza la entrevista clínica, esta información se conoce con el término de anamnesis.  Los datos objetivos obtenidos a partir de la exploración, clasificada en dos subtipos: o Examen físico: se obtiene un conjunto de datos básicos a través de la inspección, palpación, percusión y auscultación. o Examen complementario: se comprende aquí todas aquellas pruebas de laboratorio, diagnóstico por imágenes, o cualquier tipo de especial que se realice al paciente. Visión general del sistema de información existente Página 17  A partir de la información recabada en los dos apartados anteriores se incluye en la hoja de seguimiento el diagnóstico presuntivo que se ha realizado por parte del personal sanitario.  El pronóstico que se realiza sobre el problema de salud detectado.  Finalmente, el plan de acción, conjunto de tratamientos instaurados, vacunas, dietas, o recomendaciones que debe cumplir el paciente para su recuperación. En la siguiente figura podemos ver una representación básica del modelado de la historia clínica electrónica (HCE) que utiliza el sistema, así como las relaciones entre las diferentes entidades que la componen. -fecha : Date -motivoConsulta : string -anamnesis : string -observaciones : string Hoja De Seguimiento -nivel : int Alergia -medicamento : object Acontecimiento Adverso -codigo : long -dni : string -nombre : string -apellido1 : string -apellido2 : string Paciente -nhc : string -fechaInicio : Date -fechaActualizacion : Date Historia Clínica 1 0..1 1 * 1* * * -codificador : string -codigo : string -descripcion : string Procedimiento * * -codificador : string -codigo : string -descripcion : string Diagnóstico * * Exploración 1 * -tipo : string -unidadMedida : string -resultado : double Exploración::Analitica -talla : double -peso : double -imc : double Exploración::Clinica -abdomen : object -utero : object Exploración::Ginecologica Figura 3 - Modelo básico del Sistema de Citas e Historia Clínicas A parte de los cinco puntos principales que contiene la hoja de seguimiento, existe otro tipo de información que también puede recogerse en la historia clínica del paciente, como pueden ser:  Alergias conocidas, habitualmente clasificadas en dos tipos: o Alergias medicamentosas: se incluyen todos aquellos medicamentos cuyo principio activo provoca reacciones alérgicas sobre el paciente. o Resto de alergias: alergias conocidas sobre alimentos, ácaros, hongos, etc.  Acontecimientos adversos, cualquier tipo de reacción no esperada sobre un tratamiento o medicamento que se le ha suministrado al paciente. Visión general del sistema de información existente Página 18 La aplicación puede proporcionar la información que contiene la historia clínica de cualquier paciente a otros sistemas mediante la utilización de estándares que permiten la interoperabilidad entre sistemas. En este caso el estándar más desarrollado y utilizado es HL7, que permite de forma clara y precisa representar la información contenida en la historia clínica de cualquier paciente. Otro aspecto a destacar en esta aplicación es la posibilidad de gestionar las citas que solicitan los diferentes pacientes, tanto para el médico de atención primaria que tiene asignado, para servicios de enfermería, así como todas aquellas citas que precise el paciente con profesionales sanitarios de diferentes especialidades médicas. Desde el punto de vista del profesional sanitario, la gestión de citas que se ha realizado, permite proporcionarle una visión de las mismas en forma de agenda de trabajo, lo que le proporciona una visión global de las citas que debe atender cada día, de forma que pueda preparárselas con antelación. 2.4 Repositorio de Medicamentos En el sistema de información sanitario existe un conjunto de aplicaciones conocidas como módulos de BackOffice. En general, los módulos de BackOffice se utilizan para gestionar las configuraciones del resto de módulos, así como realizar el mantenimiento de todos los datos básicos que son utilizados por el resto de aplicaciones del sistema de información. El repositorio de medicamentos es uno de los módulos pertenecientes al área de BackOffice. Mediante este sistema se mantiene toda la información relevante de los medicamentos, desde los principios activos existentes, hasta los diferentes productos comerciales que hay disponibles en el mercado. Vamos a comentar a continuación la información más relevante que se mantiene.  Grupo Terapéutico ATC (ATC: acrónimo de Anatomical, Therapeutic, Chemical), es un sistema de clasificación de los medicamentos y sustancias farmacológicas. El sistema fue creado por la OMS (Organización Mundial de la Salud) y adoptado en Europa. El código ATC está formado por cinco niveles: o Primer nivel, o anatómico, indica sobre que órgano o sistema actual el fármaco. Se identifica por una letra. Por ejemplo: A – sistema digestivo y metabolismo, C – sistema cardiovascular, etc. o Segundo nivel, indica el subgrupo terapéutico, y se identifica por un número de dos cifras. o Tercer nivel, indica el subgrupo terapéutico o farmacológico, identificado por una letra. o Cuarto nivel, indica el subgrupo terapéutico, farmacológico o químico, identificado por una letra. o Quinto nivel, indica el nombre del principio activo o asociación farmacológica, y se identifica por un número de dos cifras. Visión general del sistema de información existente Página 19  Principio Activo, es toda aquella sustancia, independientemente de su procedencia, a la que se le atribuye una propiedad adecuada para ser utilizada en un medicamento. Por ejemplo: amoxicilina, ibuprofeno, paracetamol, etc.  Nemónico, este concepto es utilizado para indicar la forma farmacéutica en la que se presenta el principio activo, así como la cantidad utilizada del mismo en cada forma, sin llegar, por ejemplo, el paracetamol en comprimidos de 500mg sería el nemónico, y posteriormente lo podemos encontrar en el mercado en cajas de 12, 24 o 30 comprimidos. No existen nemónicos para todos los medicamentos, aunque sí para la mayoría, esto se debe a que algunos medicamentos solo son comercializados por un único laboratorio que tiene la patente en exclusividad.  Presentación, partiendo del concepto de nemónico, se introduce la forma en la que se presenta ese medicamento el público, es decir el tamaño de la caja o blíster, así como la cantidad de formas farmacéuticos, siguiendo el ejemplo anterior, podríamos encontrar una caja de paracetamol 500mg de 24 comprimidos.  Producto, introducimos este concepto cuando se habla de la marca comercial de una determinada presentación. En la siguiente figura se pueden observar las diferentes relaciones existentes entre las entidades principales del repositorio de medicamentos. Esta información se explicará más detalladamente si es necesario en las próximas secciones, para comprender correctamente el funcionamiento que tendrán las aplicaciones después de aplicar la nueva normativa publicada. +isCompuesto() : bool -codigo : string -descripcion : string Principio Activo +isPrescribible() : bool +getPrecioMenor() : double +hasNemonico() : bool -codigo : long -descripcion : string -cantidadPorForma : double -visible : bool -soloPorProducto : bool Presentación +isPrescribible() : bool +isProductoDeBaja() : bool -codigo : long -descripcion : string -visible : bool -precio : double Producto -codigo : string -descripcion : string -cantidadPorForma : double Nemonico +getPadre() +getHijos() -codigo : string -descripcion : string -nivel : int Grupo Terapeutico ATC 1 * 1* 1 * * 0..1 1 * * * ** -codigo : int -descripcion : string Forma Farmaceutica 1 1 1 1 Figura 4 - Modelo básico del Repositorio de Medicamentos Visión general del sistema de información existente Página 20 Una de las principales funcionalidades que oferta este módulo permite importar mensualmente el Nomenclátor que se publica en el boletín oficial del estado (BOE), con todos los cambios que hayan sufrido los productos farmacéuticos, así como el alta y baja de los mismos. En general, este módulo es uno de los pilares básicos que sustentan al sistema de prescripción y receta electrónica, ya que todas las operaciones que realizan dichos módulos utilizan una gran parte de la información que se proporciona y mantiene desde el repositorio de medicamentos. 2.5 Sistema de Prescripción y Prestación Farmacéutica El siguiente módulo del sistema de información sanitario, es una de las piezas claves y con mayor relevancia junto al sistema de historia clínica que ya hemos visto anteriormente. El sistema de prescripción y prestación farmacéutica es la aplicación que utilizan los profesionales sanitarios legalmente autorizados para instaurar los tratamientos que requiere su paciente, así como, gestionar todo el ciclo de vida de dicho tratamiento y las recetas que se tienen que emitir periódicamente para poder proporcionárselas al paciente. Este subsistema es el que ha recibido un mayor impacto en su modo de funcionamiento por la publicación del Real Decreto-Ley 9/2011, y por lo tanto, es el sistema que vamos a estudiar con un mayor nivel de detalle, tanto en este capítulo, como en el resto del documento. El sistema se encuentra físicamente dividido en dos módulos o aplicaciones independientes, que interactúan en algunas tareas. Vamos a describir a continuación ambas aplicaciones, y en las próximas secciones veremos que modificaciones son necesarias en cada una de ellas para cumplir con la nueva ley publicada. 2.5.1 Módulo de Prescripción La aplicación principal, o modulo de prescripción, como habitualmente lo conocen los usuarios que la utilizan habitualmente, es una aplicación Web, a la que se accede siempre desde el sistema de citas e historia clínica, y tiene disponibles cuatro puntos de acceso principales, según la tarea que desee realizar el usuario, aunque una vez dentro de la aplicación, es posible acceder al resto de funcionalidades sin tener que salir de la misma, como veremos más adelante. Vamos a conocer ahora los diferentes accesos a la aplicación y la utilidad de cada uno de ellos. 2.5.1.1 Formulario de prescripción Se accede principalmente desde la hoja de seguimiento del sistema de historia clínica, aunque también es posible acceder en modo consulta desde las utilidades de prescripción del propio sistema. Visión general del sistema de información existente Página 21 Cuando se accede, el sistema de historia clínica le proporciona una serie de información de gran valor sobre el paciente al sistema, número de la historia clínica, información sobre la financiación del paciente, diagnósticos activos en la historia clínica, alergias detectadas, acontecimientos adversos que se hayan producido, etc. para que sea tenido en cuenta, tanto cuando se vaya a instaurar un nuevo tratamiento, como cuando se realice cualquier acción sobre un tratamiento ya existente. El principal usuario de esta parte de la aplicación, son los facultativos, tanto de atención primaria como de especializada, que acceden al sistema para instaurar y/o gestionar los tratamientos que creen necesarios. Cuando accede el usuario, si desea instaurar un nuevo tratamiento, debe acceder al buscador de fármacos, el cual permite navegar por los grupos terapéuticos ATC, o bien, buscar por principio activo, presentación o producto hasta localizar el medicamento deseado. Una vez localizado, deberá seleccionarlo para su prescripción, volviendo automáticamente al formulario de prescripción, desde donde podrá seleccionar el diagnóstico al cual está destinado el fármaco y definir la posología que debe seguir el paciente. A parte de esta información se pueden añadir una serie de observaciones o recomendaciones, tanto para la dispensación por parte del farmacéutico, como para el consumo por parte del paciente. Figura 5 - Formulario de Prescripción En el proceso de prescripción existen una gran cantidad de comprobaciones que no vamos a estudiar en detalle, dado que no se ven modificadas por el Real Decreto-Ley, aunque si es interesante el conocimiento de las mismas. Algunos de estos controles son: Visión general del sistema de información existente Página 22  Alerta de Acontecimientos Adversos, se comprueba si el paciente ha tenido algún tipo de acontecimiento adverso al fármaco o al principio activo del mismo, en cuyo caso se avisaría al facultativo, pero no se impide la prescripción.  Alerta de Alergias, se comprueba si el paciente tiene detectada alguna alergia al principio activo que se le está prescribiendo, en cuyo caso, dependiente del grado de alergia (leve, moderada, grave), se impide o no la prescripción.  Alerta CIE-ATC, el sistema verifica que el grupo terapéutico ATC del fármaco que se está prescribiendo se encuentra indicado para el diagnóstico para el que se está prescribiendo. Este control no impide la prescripción, pero en caso de que el fármaco no este indicado debe justificar su prescripción.  Alerta de Duplicidad Terapéutica, antes de realizar la prescripción, se verifica que no exista un fármaco prescrito y vigente de la misma presentación, principio activo, nemónico o grupo terapéutico ATC, en este orden. El sistema permite configurar que debe hacer en cada caso (permitir, permitir haciendo una justificación o denegar), según el tipo de duplicidad y número de tratamientos vigentes del mismo tipo.  Alerta de Interacciones, se comprueba que no existan interacciones conocidas entre los diferentes principios activos que tiene prescritos el paciente.  Alertas farmacológicas, se informa si el fármaco esta contraindicado en mujeres embarazadas, o pacientes con insuficiencia renal y/o hepática, si afecta a la conducción, etc. +getRecetas() -fechaInicio : Date -fechaFin : Date -duracionEnvase : double -numeroEnvases : long Tratamiento -numeroReceta : string -estado : char -fecha : Date -financiacion : int Receta 1..* 1 +isCronico() +getLineas() Posologia -tipo : char -cantidad : double -cadencia : double -duracion : long Linea Posologica 11 1..* 1 -fechaInicio : Date -fechaFin : Date -estado : char -informe : string -indicacion : string Visado 1..* 0..1 -codigo : long -descripcion : string Presentacion -codigo : long -descripcion : string Producto 1 * 1 * 0..1 * Figura 6 - Modelo básico del Sistema de Prescripción y Prestación Farmacéutica Visión general del sistema de información existente Página 23 En la figura anterior podemos observar el modelo principal que utiliza el modulo de prescripción, así como las relaciones existentes entre entidades del propio módulo, y entidades pertenecientes a otros sistemas, como por ejemplo, el repositorio de medicamentos. Si el facultativo desea hacer algún tipo de gestión sobre un tratamiento que el paciente ya tiene pautado, puede acceder a la pantalla de “Tratamientos”, donde puede ver todos los tratamientos que tiene su paciente ordenados por fecha de forma descendente, y tiene acceso a las diferentes opciones para gestionar cada uno de ellos.  Prolongar, permite ampliar o reducir la duración del tratamiento para ajustarla al tiempo deseado, utilizado normalmente con pacientes con tratamientos crónicos para ampliar la duración de sus tratamientos. Un cambio en algún dato básico, como el producto o la dosis suministrada en la posología hace que automáticamente se interrumpa el tratamiento y se paute uno nuevo.  Repetir, a partir del tratamiento seleccionado, se crea uno nuevo con los datos que ya había introducido el facultativo en el anterior, producto, diagnostico, posología, etc. Antes de finalizar la repetición, podría modificar alguno de estos datos si es necesario.  Modificar, interrumpe el tratamiento seleccionado, y crea uno nuevo con los datos del anterior, antes de finalizar, el médico puede modificar los datos que deseaba cambiar.  Corregir, es un proceso que permite cambiar únicamente la posología de un tratamiento, cuando aún le quedan recetas por emitirse o las recetas que se ya se han emitido tienen una fecha futura, por ejemplo, un receta para la semana que viene. En estos casos, se permite finalizar el tratamiento anticipadamente, y crear un nuevo a continuación modificando únicamente la posología del mismo.  Interrumpir, finaliza anticipadamente, con la fecha actual, el tratamiento, no permitiendo que se emitan más recetas del mismo.  Informes, para todos los tratamientos se pueden acceder a una serie de informes para comprobar su estado, datos que se introdujeron al prescribirse, recetas emitidas, impresas o dispensadas. Por otra parte, para aquellos tratamientos que lo requieran, se pueden acceder a los informes de visado, situaciones especiales, metadona, protocolos especiales, etc. Cualquiera de las acciones que hemos descrito debe firmarse electrónicamente por el médico, en caso contrario, no tendrían validez legal. 2.5.1.2 Historia farmacológica La historia farmacológica de un paciente, básicamente mantiene la información relativa a todos los fármacos que se le han pautado a dicho paciente, asociado al diagnóstico para el cual se le prescribió. Se accede principalmente desde la hoja de seguimiento del sistema de historia clínica, aunque también es posible acceder en modo consulta desde las utilidades de prescripción del propio sistema. Cuando se accede a la historia farmacológica, se representa de forma gráfica, 18 meses en el pasado, y 12 meses hacia el futuro, de forma que se pueden ver de forma muy rápida y visual Visión general del sistema de información existente Página 24 los tratamientos que se la han prescrito en ese periodo de tiempo. Evidentemente, la escala de tiempo representada se puede modificar para tener una visión más amplia de todos los tratamientos que ha tenido un paciente. Los tratamientos se representan agrupados por el diagnostico para el que fueron prescrito, para que sea más sencillo buscar información sobre que tratamientos se le prescribieron para tratar un cierto problema de salud en el pasado. Al igual que ocurre en el formulario de prescripción, mediante la pantalla de tratamientos, desde el historial se pueden realizar prácticamente las mismas acciones que ya conocíamos con anterioridad, acceso a informes, modificar, corregir o interrumpir un tratamiento. La gran diferencia reside en los conceptos de prolongar y repetir, que no están disponibles en la historia, pero se oferta una utilidad más potente para “continuar” tratamientos. La utilidad de continuar tratamientos, permite seleccionar uno o varios tratamientos a la vez, e indicar el mes en el que quieres que finalicen todos los tratamientos seleccionados. Internamente esta utilidad se apoya en las acciones de prolongar o repetir que ya conocemos, decidiendo que acción debe realizar en cada caso según el estado actual del tratamiento. De esta forma se permite realizar con una única acción la prolongación o repetición de múltiples tratamientos, ahorrando mucho tiempo en pacientes crónicos, que acuden habitualmente a su médico para continuar con su medicación crónica. 2.5.1.3 Entrega de recetas Se puede acceder tanto desde la hoja de seguimiento del sistema de historia clínica, como desde las propias utilidades de prescripción de la aplicación, y a diferencia de los casos anteriores, esta pantalla si se puede acceder en modo edición desde las utilidades de prescripción. Se utiliza principalmente para imprimir y entregar a los pacientes las recetas que tienen pendientes de sus tratamientos. Las recetas de un tratamiento nunca son entregadas completamente si su duración es superior a 2 meses, y periódicamente deben acudir a su centro de salud para obtener el siguiente grupo de recetas. Las principales opciones ofrecidas son:  Imprimir, para una receta o un grupo de recetas, se permite la impresión en papel de las recetas que el paciente puede presentar en la farmacia para retirar los fármacos que le han prescrito. El formato y papel varían según la comunidad, aunque en cualquier caso, independientemente del formato, la receta es legar en todo el territorio nacional.  Repetir impresión, si por algún motivo ha fallado la impresión, se ha extraviado la receta o cualquier otra razón que lo requiera, se puede repetir la impresión de una receta, de forma que queda anulada la receta anterior y se emite una nueva receta.  Imprimir receta complementaria, si al paciente le falta medicación con los recetas que ya se le habían impreso, por la razón que sea, el facultativo puede imprimir una receta complementaria al tratamiento para su dispensación. Visión general del sistema de información existente Página 25  Anticipar e imprimir recetas, en el caso de que el paciente no pueda venir a recoger el siguiente grupo de recetas, tal vez por que esté fuera de su lugar de residencia en las fechas que debería recogerlas, se le puede anticipar el siguiente grupo de recetas. Como veremos con el sistema de receta electrónica, conforme se vaya avanzando en su desarrollo e implantación, esta parte de la aplicación prácticamente dejará de tener utilidad, puesto que los pacientes únicamente deberán acudir a su farmacia a recoger los medicamentos que tienen prescritos, y no será necesario la visita al centro de salud únicamente para recoger las recetas que necesitas. 2.5.1.4 Utilidades de prescripción Como ya hemos comentado, desde las opciones de utilidades de prescripción se permite acceder a las tres utilidades anteriores, aunque siempre en modo de consulta, excepto para la opción de entrega de recetas, que si se puede acceder en modo edición. Otra de las grandes utilidades que se proporcionan, es el acceso al módulo de Dispensación Hospitalaria. En los hospitales existen farmacias, que bajo un estricto control médico pueden dispensar una serie de fármacos que no se pueden vender en las oficinas de farmacia convencionales. Este modulo permite a los farmacéuticos de los hospitales llevar una agenda para atender las visitas de los paciente que acuden a recoger su medicación , así como, ir anotando en cada tratamiento la cantidad dispensada, y poder tener un control para no exceder de la medicación que se le ha prescrito. Por otro lado, existen otras utilidades menores, que permiten acceder a una serie de informes sobre tratamientos, recetas, etc., información sobre los visados que ha solicitado el usuario, informes sobre cambio del tipo de financiación en los pacientes, acceso a una serie de guías terapéuticas, información sobre alérgenos y realizar diferentes configuraciones, como por ejemplo, la activación de la receta electrónica en un paciente concreto, o la modificación de las agrupaciones de recetas que se hacen en el centro. 2.5.2 Módulo de Tareas y Servicios La segunda aplicación, el módulo de tareas y servicios, donde únicamente pueden acceder los administradores del sistema para realizar las configuraciones pertinentes. Los profesionales sanitarios no necesitan acceder, puesto que el funcionamiento de este módulo no influye en el trabajo que desempeñan habitualmente. Tiene en la actualidad 3 características principales que vamos a comentar a continuación, aunque una de ellas, dada su importancia para el funcionamiento del sistema destaca por encima del resto. 2.5.2.1 Tarea de Generación de Recetas Cuando se prescribe un tratamiento desde el modulo de prescripción, en la mayoría de los casos, hablamos de un 85% de los tratamientos, únicamente se generan el primer grupo de recetas para que el paciente retire la primera medicación que debe tomar. Visión general del sistema de información existente Página 32  Los datos del paciente: número identificativo, sexo, edad, etc.  El diagnóstico para el cual se le está prescribiendo.  La indicación terapéutica por la cual se considera que es adecuado este fármaco para el problema de salud que presenta el paciente. Finalmente, el facultativo puede añadir toda la información que crea necesaria para que el inspector pueda valorar adecuadamente la solicitud del visado de inspección. Para completar la solicitud el facultativo debe firmar electrónicamente con su certificado la solicitud. A partir de ese momento la persona designada por el servicio de Inspección de los Servicios Sanitarios, a partir de ahora el inspector, deberá valorar la solicitud y cada uno de los datos que consta en ella de forma que pueda adoptar una decisión sobre la aprobación o rechazo de la solicitud. Cuando el inspector ha decidido que tiene toda la información necesaria, y que es correcta, por lo tanto, va a aprobar el visado, puede aprobarlo con una duración comprendida entre 1 día y 5 años. Si el inspector considera que el tratamiento está destinado para un paciente crónico, el inspector puede decidir aprobarlo con la máxima duración para evitar futuras solicitudes y evitar los inconvenientes que se causan al paciente. En el caso de que el inspector decida rechazar el visado, le llegaría un aviso al facultativo para que pueda revisar la solicitud y complementar la información necesaria, o en otros casos, buscar un tratamiento alternativo para el paciente. Hay que tener en cuenta que existen una serie de reglas en los visados de inspección que se solicitan, por ejemplo, nunca pueden existir dos visados aprobados para la misma presentación, se trataría de una duplicidad terapéutica. Tampoco es posible la existencia de dos tratamientos asociados a un mismo visado que se encuentran vigentes al mismo tiempo. Las aplicaciones si permiten este caso, pero los tratamientos quedan bloqueados temporalmente hasta que el inspector decide con cuál de los dos tratamientos se queda, interrumpiendo el otro. A continuación tenemos una figura en la que se muestra la relación existente entre los visados, los tratamientos, y los grupos de recetas de los mismos, así como algunas otras entidades de relevancia para los visados de inspección. Visión general del sistema de información existente Página 33 +getRecetas() -fechaInicio : Date -fechaFin : Date -duracionEnvase : double -numeroEnvases : long Tratamiento -numeroReceta : string -estado : char -fecha : Date -financiacion : int Receta 1 1..* -fechaInicio : Date -fechaFin : Date -estado : char -informe : string -indicacionManual : string Visado * 0..1 -fecha : Date -estado : char Grupo Recetas 1..* 0..1 1..* 0..1 -codigo : long -descripcion : string Indicacion -codigo : long -descripcion : string Presentacion -codigo : long -descripcion : string Producto 1 1..* -observaciones : string Incidencia -numeroReceta : string -fecha : Date -motivo : string Receta Manual 1 * 1 * 1 * 0..1 * 1 * Figura 10 - Modelo básico del Sistema de Visados de Inspección Análisis Funcional Página 34 3 Análisis Funcional En este capítulo vamos a estudiar en profundidad el texto publicado en el Real Decreto-Ley 9/2011, y veremos como afecta esto en la prestación farmacéutica, y sus consecuencias en los diferentes sistemas de información que son utilizados en este ámbito. De la misma forma, veremos los cambios que necesariamente se deben realizar en los mismos para adaptar su funcionamiento. 3.1 Texto legal Vamos a empezar estudiando el texto legal, y todo lo que se recoge dentro del mismo, para posteriormente poder mostrar estos cambios funcionales en las diferentes aplicaciones utilizadas en la prestación farmacéutica. 3.1.1 Texto literal del nuevo artículo 85 de la Ley de Garantías «1. La prescripción, indicación o autorización de dispensación de los medicamentos se realizará por principio activo, en la receta médica oficial u orden de dispensación, del Sistema Nacional de Salud. Asimismo, en los productos sanitarios para pacientes no hospitalizados que requieran para su dispensación en oficina de farmacia receta médica oficial u orden de dispensación, del Sistema Nacional de Salud, la prescripción, indicación o autorización de dispensación se realizará por denominación genérica por tipo de producto y por las características que lo definan, especificando su tamaño y contenido. En ambos casos, el farmacéutico dispensará la presentación del medicamento o del producto sanitario que tenga menor precio, de acuerdo con las agrupaciones homogéneas que determine la Dirección General de Farmacia y Productos Sanitarios del Ministerio de Sanidad, Política Social e Igualdad. No obstante cuando por excepción a la norma general la prescripción, indicación o autorización de dispensación se hubiera realizado identificando el medicamento o el producto sanitario respectivamente, por su denominación comercial, no tratándose de los supuestos previstos en el punto 2 de este artículo, el farmacéutico dispensará dicho medicamento o producto si es el de menor precio de la correspondiente agrupación, y si no lo fuera dispensará el que tenga menor precio de la misma. 2. No obstante, cuando las necesidades terapéuticas lo justifiquen, así como cuando los medicamentos pertenezcan a agrupaciones integradas exclusivamente por un medicamento y sus licencias, al mismo precio que el medicamento de referencia, la prescripción, indicación o Análisis Funcional Página 35 autorización de dispensación se podrá realizar identificando el medicamento o, en su caso, el producto sanitario por su denominación comercial.» 3.1.2 Resumen Se generaliza la prescripción por principio activo para medicamentos y productos sanitarios y se dispensará el medicamento o producto sanitario de menor precio, sin distinción entre marca o genérico de acuerdo con las agrupaciones homogéneas que determine la Dirección General de Farmacia y Productos Sanitarios. Se incluyen 3 excepciones a la prescripción por principio activo, en las que se podrá prescribir por marca:  Por necesidad terapéutica (ni se define, ni se desarrolla exactamente y serán las CCAA las que establecerán, en último término este aspecto). En este caso el farmacéutico dispensará el medicamento prescrito, con independencia de que su precio se ajuste o no al precio menor.  Por agrupaciones integradas únicamente por un medicamento y sus licencias al mismo precio (identificadas por el Ministerio).  Por excepción a la norma general de prescripción por principio activo y a los dos casos anteriores, si la marca comercial tiene un precio inferior o igual al precio menor de la presentación, se podrá prescribir por dicha marca.  Por excepción a la norma general de prescripción por principio activo y a los dos puntos primeros: o Si la prescripción por denominación comercial está a precio menor se deberá dispensar el medicamento prescrito. o Si la prescripción por denominación comercial supera el precio menor se deberá sustituir por un medicamento a precio menor. 3.1.3 Necesidad terapéutica De acuerdo con las indicaciones de la Dirección General de Farmacia y Productos Sanitarios, en relación con la excepción de la prescripción por principio activo por necesidad terapéutica justificada, en el supuesto que el producto prescrito supere el precio menor de la agrupación homogénea que le corresponda, y al objeto de garantizar la libre elección de oficina de farmacia de los usuarios del Sistema Nacional de Salud (SNS), la Comisión Permanente de Farmacia del Consejo Interterritorial del SNS ha consensuado el requisito formal que deben incluir las recetas oficiales, para que cualquier oficina de farmacia pueda dispensar y facturar la receta afectada de excepción por necesidad terapéutica, con independencia de la Comunidad de origen de la prescripción. En estos supuestos, sin perjuicio de las condiciones y procedimientos que en el ámbito de cada Comunidad puedan establecerse para la justificación de la prescripción excepcional en estas recetas así como su dispensación y facturación, se acuerdan los siguientes criterios mínimos: Análisis Funcional Página 36 La necesidad terapéutica debe estar adecuadamente documentada y justificada ante la administración sanitaria donde se emite la receta oficial u orden de dispensación del SNS y en la forma que dicha administración haya establecido.  Para las recetas en formato papel, el prescriptor consignará en la receta, preferentemente en el apartado de información al farmacéutico, la anotación, necesidad terapéutica. En las recetas de cumplimentación manual, dicha anotación debe ser avalada con nueva rubrica, además de la consignada en el apartado de datos del prescriptor.  Cuando el medicamento prescrito por denominación comercial haya sido expresamente autorizado para su dispensación mediante visado de la Administración sanitaria de la Comunidad de procedencia de la receta, o conste en la misma una validación oficial, no será necesaria la anterior anotación, entendiendo que el visado o la validación oficial ha ratificado la excepción del prescriptor. 3.1.4 Prescripción de principios activos asociados De cara a evitar el aumento del gasto sanitario que está suponiendo la prescripción de principios activos asociados, por ejemplo el producto “ZALDIAR 37,5MG/325MG 20 COMPRIMIDOS RECUBIERTOS” es en realidad la asociación de dos principios activos que se pueden adquirir por separado (paracetamol y tramadol) con un coste muy inferior al producto nombrado. Se desea tener un mayor control sobre la prescripción de este tipo de fármacos, de forma similar a la prescripción por principio activo, que requiere una justificación por necesidad terapéutica, para que los facultativos se encuentren con la obligación de justificar la prescripción de dichos productos, y en caso de que no sea necesario, realicen la prescripción de los diferentes principios activos por separado. 3.2 Sistemas afectados Hay cuatro sistemas que se han visto afectados por la publicación de la ley, el primero de ellos, y que sufrido un mayor impacto es el sistema de prescripción y prestación farmacéutica, y en menor grado el sistema de receta electrónica. Finalmente, el repositorio de medicamentos sufre algún pequeño cambio, que estudiaremos ligeramente para poder comprender mejor el impacto en el sistema de prescripción. El sistema de facturación también sufre alguna modificación, aunque no vamos a estudiarlo en este documento. Dentro de las aplicaciones del sistema que están implicadas en la prestación farmacéutica del S.N.S., existen unos perfiles de usuarios muy concretos que son utilizados en todas estas aplicaciones. A lo largo del análisis iremos haciendo referencia al tipo de usuario que puede realizar cada acción, o las limitaciones que existan en función de este criterio. En la siguiente figura podemos ver una representación rápida de todos los perfiles que pueden acceder a las aplicaciones, tanto al sistema de prescripción, como al repositorio de medicamentos. Análisis Funcional Página 37 Usuario Administrador Auxiliar Enfermero Medico Consultor Medico Especialista Farmaceutico Figura 11 - Modelo UML de actores del sistema En cualquier caso, no es habitual que todos estos perfiles accedan a ambas aplicaciones en el desempeño de sus tareas habituales. Así pues, los administradores y consultores suelen ser los únicos usuarios que acceden al repositorio de medicamentos, mientras que el resto de perfiles suelen ser los usuarios habituales del sistema de prescripción. Vamos a estudiar a continuación los cambios funcionales que requieren los distintos sistemas, empezaremos en primer lugar por revisar los cambios en el repositorio de medicamentos, que son un requisito indispensable para poder abordar posteriormente el estudio del impacto en el sistema de prescripción y de receta electrónica. 3.3 Repositorio de Medicamentos Este sistema, conocido por formar parte de los módulos de BackOffice, requiere de unos ligeros ajustes, tanto en el modelo de clases que sustenta el sistema, como en alguno de los casos de uso o utilidades que proporciona a sus usuarios. 3.3.1 Mantenimiento de los motivos de superación del precio menor La introducción de las justificaciones, cuando por necesidad terapéutica se requiera y el médico lo crea conveniente, o para justificar la utilización de un principio activo asociado, requiere de la creación de un mantenimiento básico en el repositorio de medicamentos donde Análisis Funcional Página 38 los administradores del sistema puedan gestionar (consultar, añadir, eliminar o actualizar) los motivos que los usuarios pueden utilizar para justificar la utilización de estos fármacos. La información básica que se deberá registrar para cada motivo será:  Código que lo generará automáticamente el sistema.  Descripción del motivo, por el cual el usuario argumentará que la prescripción es necesaria.  Válido, se trata de un “flag” o marca que indica si el motivo puede ser utilizado para realizar una nueva prescripción con justificaciones por parte de un facultativo. Inicialmente, con la actualización de la nueva versión de la aplicación, se creará el motivo con código “0”, descripción “OTROS” y la marca de válido a verdadero. La aplicación no permitirá en ningún caso la modificación de este motivo, ya que será utilizado para obligar a introducir a los usuarios, a mano, el texto justificativo que quieran hacer constar. En ningún otro motivo se permitirá la introducción de texto manual. Todo aquel motivo que haya sido utilizado por el modulo de prescripción para instaurar un nuevo tratamiento no se permitirá que se elimine. Si el administrador no desea que se utilice más, puede marcarlo cono no válido. Pero seguirá apareciendo en todos aquellos tratamientos que lo hayan utilizado. Figura 12 - Repositorio de Medicamentos, formulario de mantenimiento de motivos justificativos Cuando se desee añadir un nuevo elemento, se pulsará el botón “Añadir” y automáticamente se creará un nuevo registro con el siguiente código que le corresponda, y la marca de valido con valor por defecto verdadero, a falta de que el usuario introduzca la descripción del motivo y pulse el botón “Guardar”. Análisis Funcional Página 39 De forma similar, cuando el usuario desea editar un motivo, basta con hacer doble “click” sobre el motivo deseado, y aparecerá el mismo elemento de edición que en el caso de añadir, permitiendo en este caso modificar la descripción y la marca de válido. Figura 13 - Repositorio de Medicamentos, mantenimiento de motivos justificativos en modo edición Tanto al añadir, como al actualizar un registro, el usuario puede cancelar la acción si así lo considera oportuno, utilizando el botón “Cancelar” del elemento de edición. 3.3.2 Justificar la prescripción de principios activos asociados Se están comercializando en la actualidad una serie de productos que son la asociación de dos o más principios activos en la misma forma farmacéutica. Por norma general, estos productos tienen un precio muy superior al que podrían tener la prescripción de los mismos principios activos por separado. Si hacemos uso del ejemplo visto anteriormente, el producto “ZALDIAR 37,5MG/325MG 20 COMPRIMIDOS RECUBIERTOS” que está compuesto por paracetamol y tramadol, podríamos localizar fácilmente un producto equivalente de cada principio activo con un precio conjunto que oscila entre un 18% y un 21% menor, según datos de mayo de 2012. Para evitar el aumento del gasto sanitario que está suponiendo la prescripción de este tipo de producto, se quiere aprovechar las modificaciones que se van a realizar en los procesos de prescripción se quiere incluir la posibilidad de que la prescripción de este tipo de principios activos asociados requiera una justificación por parte del usuario, al estilo de la justificación por necesidad terapéutica de la prescripción por principio activo. Para poder atender esta situación, en la configuración de las presentaciones farmacéuticas que se realiza actualmente, se incluye un nuevo “flag” o marca junto al resto de condiciones de prescripción, el cual nos permitirá indicar si deseamos que se justifique la prescripción de esta presentación y sus productos asociados. El aspecto de la ficha de las “Condiciones de Prescripción” tras incluir el nuevo campo “Justificación prescripción P.A. asociado” podría ser el siguiente. Análisis Funcional Página 40 Figura 14 - Repositorio de Medicamentos, fragmento de la ficha de la presentación farmacéutica Cuando se realice la actualización de la versión, todas las presentaciones tendrán el nuevo campo sin marcar. Cabe destacar que este tipo de configuraciones son realizadas por los administradores del sistema, el resto de usuarios solo podría acceder a esta visa en modo de solo lectura. 3.3.3 Modificaciones en la duplicación de presentaciones farmacéuticas El repositorio de medicamentos ya tiene una utilidad que permite rápidamente hacer una copia de una presentación, es decir, duplicarla, de forma que se crea una nueva presentación idéntica a la anterior. Este proceso es utilizado habitualmente cuando aparece una nueva presentación farmacéutica muy similar a alguna ya existente, se realiza el duplicado, y se modifican todos los valores necesarios hasta ajustarse a la nueva presentación. De esta forma el usuario, que en este caso sería el administrador, evita realizar un gran número de configuraciones que ya ha obtenido de la presentación original. El proceso que realiza la duplicación de la presentación farmacéutica, cuando llegue a la ficha de las “Condiciones de Prescripción” tendrá en cuenta el nuevo campo “Justificación prescripción P.A. asociado” para copiar también su valor. 3.3.4 Modificaciones en la utilidad de replica de datos entre presentaciones farmacéuticas Para tener en cuenta el nuevo campo “Justificación prescripción P.A. asociado” en todos los procesos que tiene el repositorio de medicamentos, hay que considerar las modificaciones en la utilidad de “Replica de Datos”. La replica de datos permite copiar un conjunto de valores concretos, tal y como los tiene definido una presentación origen, en una o varias presentaciones destino, esto quiere decir Análisis Funcional Página 41 que a partir de la presentación farmacéutica que se está consultando o editando en el repositorio de medicamentos, podemos decidir copiar una serie de campos, tal y como se encuentran configurados en dicha presentación, a un conjunto de presentaciones farmacéuticas que nos permite buscar la aplicación. Actualmente la utilidad de replica de datos permite copiar los siguientes campos:  Prescripción fuera de indicación  Indicado por Enfermería  Dispensable por S.F. Hospitalarios Se propone incluir el nuevo campo “Justificación prescripción P.A. asociado” para que los usuarios tengan facilidades para configurar rápidamente un gran número de presentaciones farmacéuticas. Figura 15 - Repositorio de Medicamentos, utilidad de replica de datos Se puede entrar a esta utilidad desde el botón “Replicar Datos” que está disponible en la ficha de la presentación farmacéutica cuando se consultando o editando. Por lo tanto, ya se entra a la utilidad con la presentación origen seleccionado. El usuario debe seleccionar que valores son los que quiere copiar, los que no se marquen se quedaran en su estado original. Análisis Funcional Página 48 En la siguiente figura podemos volver a observar la ventana de búsqueda de productos, en este caso con el botón de “Excepciones PPA” habilitado (de color rojo), y por lo tanto, vemos como en todas las presentaciones farmacéuticas y productos comerciales mostrados se pueden seleccionar para su prescripción. Siguiendo el ejemplo anterior, la presentación farmacéutica “PARACETAMOL 120MG EN 5 ML / 1 FRASCO SOL ORAL DE 120 ML (AUTO)” no está definida dentro de la configuración PPA. Pero como tenemos las excepciones PPA activas, tenemos habilitado el botón (P) para prescribir la marca comercial “TERMALGIN 120 MG / 5 ML SOLU ORAL 120 ML (AUTO)”, en este caso como su precio supera el precio menor definido en la presentación farmacéutica (la descripción del producto se muestra en rojo), si seleccionamos dicho producto para prescribir, el sistema nos solicitará la justificación por utilizar dicho medicamento. En estos casos se le mostrará al usuario este mensaje: “El Real Decreto-Ley 9/2011, impone la prescripción por principio activo, excluyendo aquellas situaciones donde las necesidades terapéuticas lo justifiquen. Deberá justificar el motivo de este tratamiento. ” Si el usuario decide realizar la prescripción de este producto, se le abrirá una nueva ventana con donde se mostrará el mensaje anterior, y el usuario podrá seleccionar el motivo por el cual decide realizar esta prescripción. El usuario en cualquier momento podrá decidir continuar con el proceso “Aceptar”, una vez que haya justificado la prescripción, o detener el proceso de prescripción ya que no quiere realizar la justificación, y en este caso puede cerrar esta ventana, pulsando el botón “Cancelar”, volviendo a la búsqueda de productos en el estado que estaba anteriormente. A continuación podemos ver el aspecto general de la ventana de justificaciones. Figura 18 - Módulo de prescripción, introducción de justificaciones (I) Análisis Funcional Página 49 Esta ventana será exactamente igual tanto si aparece porque el precio del producto supera el precio menor de la presentación, como si la presentación tiene la marca de “Justificación prescripción P.A. asociado”. Los motivos que se mostrarán en esta ventana son los que se permiten mantener en el repositorio de medicamentos, tal y como se explicado anteriormente en el punto “Mantenimiento de los motivos de superación del precio menor” del análisis funcional del repositorio de medicamentos. Con la actualización previa que se realizará del repositorio de medicamentos, y tal como se indica en su análisis, se creará el motivo con código “0”, descripción “OTROS” y la marca de válido a verdadero, que no se podrá modificar en el repositorio, por lo tanto es un registro fijo. Si el usuario selecciona al registro “OTROS” identificado por el código “0”, se habilitara el campo de observaciones para que el usuario pueda introducir la justificación manualmente. En cualquier caso, si el usuario desea continuar con la prescripción deberá seleccionar un motivo previamente, mostrándole un mensaje en caso de que no lo haya hecho: “Debe seleccionar el motivo para justificar adecuadamente el tratamiento.” Si selecciona el motivo “OTROS” pero no introduce las observaciones, se le avisará con el mensaje: “Debe seleccionar el motivo para justificar adecuadamente el tratamiento.” A continuación podemos ver un ejemplo donde otro ejemplo de la misma pantalla donde se muestran todos los motivos válidos que habíamos visto anteriormente en el ejemplo “Mantenimiento de los motivos de superación del precio menor” del análisis funcional del repositorio de medicamentos. Figura 19 - Módulo de prescripción, introducción de justificaciones (II) Análisis Funcional Página 50 3.4.2.1 Algoritmo para habilitar o deshabilitar el botón “P” de un presentación farmacéutica Se ha utilizado un diagrama de flujo para representar el algoritmo que determina si es necesario habilitar o deshabilitar el botón para poder prescribir una presentación farmacéutica desde la pantalla de búsqueda de productos. Inicio Consultar Configuración Presentación ¿Sólo por producto? Botón “P” habilitado Botón “P” deshabilitado SI NO ¿Tiene Configuración PPA? NO ¿Por presentación o precio menor? SI SI NO ¿Excepciones PPA activas? NO SI Figura 20 - Módulo de prescripción, algoritmo de selección de presentación Análisis Funcional Página 51 3.4.2.2 Algoritmo para habilitar o deshabilitar el botón “P” de un producto comercial Se ha utilizado un diagrama de flujo para representar el algoritmo que determina si es necesario habilitar o deshabilitar el botón para poder prescribir un producto o marca comercial desde la pantalla de búsqueda de productos. Inicio Consultar Configuración Presentación y Producto ¿Sólo por producto? Botón “P” habilitado Botón “P” deshabilitado SI SI ¿Tiene Configuración PPA? NO ¿Por marca o precio menor? SI SI NO Precio <= PrecioMenor ¿Excepciones PPA activas? NO NO NO ¿Tiene Precio Menor? NO SI SI Figura 21 - Módulo de prescripción, algoritmo de selección de producto Análisis Funcional Página 52 3.4.2.3 Algoritmo para la solicitud de las justificaciones Diagrama de flujo que representa el algoritmo de decisión para mostrar la pantalla de solicitud de justificaciones, así como la acción que se realizará finalmente, continuar la prescripción o volver a la búsqueda de productos, según las acciones realizadas por el usuario. ¿Excepciones PPA activas? Permite Continuar NO Inicio (Búsqueda de Productos) Prescribir ¿Marca de Justificación activada? SI ¿Tiene precio menor y lo supera? NO Justificar Tratamiento SI ¿Tratamiento Justificado? SI NO SI NO Figura 22 - Módulo de prescripción, algoritmo de solicitud de justificaciones Análisis Funcional Página 53 3.4.2.4 Favoritos Desde la pantalla de búsqueda de producto, el usuario puede guardarse aquellas presentaciones que utiliza de forma habitual para poder localizarlas más rápidamente. Todas aquellas presentaciones añadidas se pueden consultar en la ventana de “Favoritos” accesible desde el formulario de prescripción. Igual que ocurre en la búsqueda de productos, disponemos del botón “Excepciones PPA” para poder activar o desactivar las excepciones declaradas en el Real Decreto-Ley. A continuación podemos ver el aspecto general que presenta esta pantalla. Figura 23 - Módulo de prescripción, selección de favoritos Como se puede ver, en este caso se ofrecen dos acciones diferentes a las que habíamos visto en la búsqueda de productos. El botón “PM” permite la selección de la presentación farmacéutica, mientras que el botón “M”, permite la selección de marcas comerciales, si solo existe una, la seleccionará automaticamente, en caso contrario mostrará un listado con las diferentes opciones. El botón “PM” utiliza el algoritmo descrito anteriormente para habilitar la prescripcion de presentaciones en la búsqueda de productos. Del mismo modo, el botón “M” aplica el algoritmo para productos, pero en este caso, se ejecutaría por cada uno de los productos existentes, y se mostraría habilitado si encontramos un producto que habilite el botón para prescribir en la búsqueda de productos. Finalmente, a la derecha se proporciona una tercera acción, con un icono, que nos permite eliminar presentaciones de nuestra lista de favoritos. Análisis Funcional Página 54 3.4.3 Modificaciones en el proceso de prescripción de un nuevo tratamiento La aprobación del Real Decreto-Ley 9/2011 no ha afectado al funcionamiento actual del formulario de prescripción, que ya habíamos explicado anteriormente, en la visión global del sistema de información con más detalle. Figura 24 - Módulo de prescripción, formulario de prescripción En cambio, si que se ha visto afectado el proceso de prescripción que se desencadena desde el formulario, dado que ahora, el producto que se haya seleccionado, es posible que haya requerido la introducción de una justificación, que deberá asociarse tanto al tratamiento, como a sus recetas. Siguiendo con el ejemplo del punto anterior, si seleccionamos para prescribir la marca comercial “TERMALGIN 120 MG / 5 ML SOLU ORAL 120 ML (AUTO)”, como el precio del producto es superior al precio menor definido en la presentación farmacéutica, el usuario debe introducir la justificación del uso de este medicamento. El motivo seleccionado por el usuario, o las observaciones introducidas manualmente si selecciona el caso “OTROS” debe guardarse asociado tanto al tratamiento como a las recetas en el momento de la prescripción. Así mismo, se incluirá esta información en la firma electrónica que se realiza del tratamiento. 3.4.4 Modificaciones en las acciones disponibles para los tratamientos Cuando los pacientes ya disponen de tratamientos prescritos, es decir, su historia farmacológica no está vacía, se ofrecen una serie de acciones sobre estos tratamientos para Análisis Funcional Página 55 facilitar y agilizar las tareas comunes de los usuarios, que en muchas ocasiones deben prescribir continuamente los mismos tratamientos para pacientes crónicos, lo que permite a los médicos proporcionar una mejor atención al paciente, ya que no invierten tanto tiempo utilizando el sistema de información, y pueden centrarse en la atención que requieren sus pacientes. Estas acciones se ofrecen tanto desde la historia farmacológica como de la pantalla de tratamientos. Cuando se vaya a realizar cualquiera de las acciones disponibles (corregir, modificar, prolongar o repetir) sobre el tratamiento, el sistema debe comprobar si la presentación farmacéutica o la marca comercial prescrita cumplen con las reglas definidas por la nueva normativa de prescripción por principio activo, o en caso contrario, el tratamiento debe tener introducidas las justificaciones necesarias, lo cual, supone que se ha prescrito como excepción por necesidad terapéutica. En el momento que se realice la actualización del sistema, existirán muchos tratamientos que no cumplan con la nueva normativa:  Tratamientos pautados por marca comercial que supera el precio menor.  Tratamientos pautados por marca comercial o presentación farmacéutica que incumple la nueva configuración PPA.  Tratamientos de presentaciones o productos con principios activos asociados que ahora tienen la nueva marca activada. Para estos casos, se ha diseñado un algoritmo que comprobará la situación actual del tratamiento, y en caso necesario, solicitará el cambio de marca comercial, o la selección de la presentación farmacéutica, según la configuración que haya definida, o bien, si no se desea realizar un cambio en el tratamiento, y para que quede prescrito correctamente como excepción por necesidad terapéutica, se solicitará la introducción de las justificaciones necesarias. Este algoritmo se aplicará por igual, tanto en las acciones ofertadas en la pantalla de tratamientos e historia farmacológica (corregir, modificar, prolongar o repetir), como en la acción de continuar tratamientos disponible en la historia farmacológica, que internamente se trata de un prolongar o repetir según el estado y vigencia del tratamiento seleccionado. Análisis Funcional Página 56 3.4.4.1 Algoritmo de decisión para las acciones sobre los tratamientos Diagrama de flujo que representa el algoritmo de decisión a la hora de corregir, modificar, prolongar o repetir tratamientos ya pautados, así como la herencia de las posibles justificaciones cuando el tratamiento original las tuviese. Inicio (Continuar / Repetir / Modificar /Corregir) Hereda Justificación No Hereda Justificación Solicita Nueva Justificación Obtener Datos Presentación y Producto ¿Producto Financiable? Precio > PrecioMenor SI NO ¿Marca de justificación activada? NO SI NO ¿Cambio de Producto? SI NO ¿Financiable? SI NO Precio > PrecioMenor SI SI NO Proceso Selección Producto o Presentación Figura 25 - Módulo de prescripción, algoritmo para permitir gestionar un tratamiento existente Análisis Funcional Página 57 3.4.5 Limitar el número de tratamientos prescritos con excepciones mensualmente Las administraciones autonómicas ven con cierto recelo las excepciones por necesidad terapéutica, dado que un facultativo puede decidir prescribir las marcas comerciales que quiera introduciendo la justificación necesaria. Para estos casos, se ha decidido crear un límite mensual de prescripciones de este tipo. De forma que las excepciones mensuales queden limitadas mensualmente y no puedan abusar de este sistema. En cualquier caso, si un facultativo que ha llegado al límite de prescripciones necesita hacer otra más, podrá ponerse en contacto con la dirección médica de su departamento, donde tendrá que justificar su necesidad, y desde allí, los administradores del sistema le podrán reiniciar el contador mensual, en caso de que lo crean conveniente. El número de justificaciones mensuales que se podrá realizar será configurable en la aplicación, y su valor inicial será de 100, que se estima suficientemente alto para que los usuarios no tengan que solicitar el reinicio antes de fin de mes, y suficientemente bajo para que no abusen del sistema. Cuando el usuario seleccione una presentación farmacéutica o marca comercial para su prescripción, o desde las acciones disponibles en la pantalla de historia farmacológica o en la de tratamientos (corregir, modificar o repetir), si requiere la justificación por superar el precio menor o por tener la marca de justificaciones, se comprobará el valor actual del número de justificaciones, y si es igual o mayor al límite establecido se parará el proceso, informando al usuario con un mensaje: “ATENCIÓN: Su petición supera el límite de tratamientos con justificación mensuales permitidos (100). Si necesita ampliar este límite por favor contacte con la Dirección Médica de su Departamento.” La información sobre el número de tratamientos que se han instaurado con excepciones por necesidad terapéutica, es decir, introduciendo las justificaciones a la hora de seleccionar el producto, se podrá consultar desde la pantalla de preferencias del usuario, donde podremos encontrar el número de justificaciones realizadas el mes actual, así como la fecha de la última justificación. 3.4.6 Modificaciones en las acciones de impresión de recetas disponibles Desde la pantalla de “Entrega de Recetas”, del módulo de prescripción, se proporciona cuatro procesos diferentes para realizar la impresión de recetas, según las necesidades del paciente y el usuario en cada caso.  Imprimir, permite la impresión de las recetas que se han generado por el proceso nocturno de generación de recetas, y no necesita realizar ninguna acción adicional.  Reimprimir, al anular la receta anterior, y generar una nueva, tendrá que incorporar la información referente a las justificaciones en el supuesto de que el tratamiento esté justificado. Análisis Funcional Página 64 En el caso de que seleccione el filtro de cupo o CPA, se cargarán automáticamente los resultados de la última ejecución de la consulta en modo diferido, en el caso de que existan, y se mostrará en la esquina superior derecha la fecha en la que se calcularon dichos datos. Si el usuario desea actualizar estos datos, solo tendrá que pulsar el botón “Actualizar / Solicitar Información” que invocara de nuevo el proceso que realiza la búsqueda según el filtro que tuviese seleccionado, en cuyo caso, podrá volver al cabo de unos minutos para poder ver los resultados actualizados. En el bloque inferior, se presenta, en una tabla, el resultado de las consultas realizadas anteriormente, agrupando en primer lugar por principio activo, después por presentación farmacéutica y finalmente por marca comercial. Junto a estos datos, se muestra el número de tratamientos detectados de este tipo que están vigentes y, por tanto, están incumpliendo la normativa publicada en el Real Decreto-Ley 9/2011. Utilizando la lupa de búsqueda que hay junto a cada agrupación de tratamientos, se abrirá una nueva ventana que nos ofertará las diferentes posibilidades que tenemos para transformar los tratamientos acordes con la ley. En la siguiente figura podemos observar el prototipo de la nueva ventana. Figura 29 - Módulo de Sustitución de Tratamientos, selección de nueva presentación o producto La pantalla se divide en dos bloques claramente diferenciados:  El primero de ellos ofrecerá la posibilidad de seleccionar la presentación farmacéutica, siempre y cuando esta selección no incumpla la P.P.A., que como ya hemos visto Análisis Funcional Página 65 antes, se puede configurar para seleccionar una marca comercial concreta, o existe la marca especial que obliga a la prescripción por marca.  El segundo bloque oferta las marcas comerciales que podemos escoger para transformar los tratamientos, únicamente se ofertaran aquellos productos que cumplan la configuración PPA, es decir, productos de precio menor, o la marca comercial configurada. El funcionamiento general de ambos bloques es muy similar, permitiendo seleccionar en la tabla la presentación farmacéutica o la marca comercial deseada, y pulsando el botón “Seleccionar” volveríamos a la pantalla principal con el medicamento que deseamos utilizar. Cuando se ha realizado la elección de un nuevo medicamento, automáticamente la fila de la tabla queda marcada con el “check” que aparece al principio de la misma, si finalmente no quisiésemos hacer la sustitución de algún grupo de tratamientos, bastaría con quitar esta marca. En el último paso del proceso, el usuario deberá programar la sustitución de los grupos de tratamientos deseados, para ello se le ofrecen dos opciones en la parte superior derecha de la tabla:  Sustituir el producto pautado, todos los grupos de tratamientos seleccionados y correctamente configurados se programarán para que se realice la sustitución el mismo día en horario de baja actividad. Debido a la gran cantidad de tareas que ya existen en ese horario, únicamente se permitirá sustituir diariamente 10.000 tratamientos. Este valor será configurable en la aplicación y se podrá ajustar para adaptarse a la ventana de tiempo disponible. Cuando la aplicación detecte que se ha alcanzado el límite marcado, se desactivara automáticamente dicha opción.  Programar la sustitución el viernes, debido al límite impuesto en la opción anterior, se le proporciona a los usuarios la posibilidad de programar las sustituciones en los tratamientos los viernes, ya que desde el viernes a las 20:00 horas, hasta el lunes a las 08:00 horas está considerado horario de baja actividad y se pueden realizar todas las sustituciones que sean necesarias. Análisis Funcional Página 66 Figura 30 - Módulo de Sustitución de Tratamientos, prescripción por principio activo (II) Finalmente, el modulo de sustitución de tratamientos ofrecerá un informe para que el usuario puede consultar las sustituciones que se están realizando. En este informe aparecerán los siguientes datos:  Paciente, el TSI y nombre  Principio activo  Presentación farmacéutica  Marca comercial anterior  Fecha de inicio y fin del tratamiento  Sustitución realizada, es decir, la nueva marca comercial o la presentación, la elección que realizase el usuario. 3.6.2 Sustitución de Productos de Baja Aprovechando la utilidad que se está pretende desarrollar para gestionar las sustituciones masivas de tratamientos, se quiere hacer una utilidad similar que permita a los usuarios cambiar los productos que se han dado de baja por otros diferentes. El nuevo módulo tendrá en cuenta que se piensa realizar este desarrollo en la futura versión, y el diseño de las interfaces se ha realizado pensando en la ampliación del módulo. Por el momento, la sustitución de productos de baja queda fuera del alcance del requerimiento del impacto del Real Decreto-Ley 9/2011 y se abordará en la próxima versión. Análisis Técnico Página 67 4 Análisis Técnico A lo largo de este capítulo vamos a realizar el análisis técnico que suponen los cambios funcionales descritos anteriormente como consecuencia de la publicación del Real Decreto-Ley 9/2011. Debido a la gran cantidad de cambios que existen, vamos a detallar únicamente los cambios de modelo que afectan a los diferentes sistemas para tener una visión general, y posteriormente desarrollaremos con mayor profundidad la parte del análisis técnico que he desarrollado personalmente durante el desempeño de mis funciones en Indra. Debido al reparto de tareas entre el equipo de desarrollo, a mi pidieron desarrollar los cambios que afectaban al módulo de tareas y servicios, y por lo tanto, será la parte del análisis técnico que desarrollaré con un mayor detalle. 4.1 Repositorio de Medicamentos Los cambios propuestos por los analistas funcionales de Indra para el repositorio de medicamentos han sido bastante reducidos, y su modelo ha sufrido pequeños cambios que vamos a ver a continuación. 4.1.1 Motivos de superación del precio menor Es necesaria la creación de una nueva tabla en el esquema de base de datos perteneciente al repositorio de base de datos para que la aplicación pueda realizar el mantenimiento de los motivos de superación del precio menor. Figura 31 - Modelo motivos de superación del precio menor Código SQL completo para la generación de la tabla y sus restricciones, así como la inserción del registro “OTROS”. Análisis Técnico Página 68 4.1.2 Justificación de los principios activos asociados Por otro lado, para detectar aquellas presentaciones que por utilizar principios activos asociados con un precio superior a sus equivalentes por separado, es necesaria la creación de una marca en la presentación para poder detectarlos. Figura 32 - Modelo de presentación farmacéutica Código SQL para añadir la nueva columna en la presentación farmacéutica. ALTER TABLE presentacion ADD reqjustificacion CHAR(1) DEFAULT 'N' NOT NULL; ALTER TABLE presentacion ADD CONSTRAINT pfar_reqjustificacion_ck CHECK (reqjustificac ion IN ('S','N')) ENABLE NOVALIDATE; CREATE TABLE motivosuperacionpmenor ( codigo VARCHAR2(2) NOT NULL, descripcion VARCHAR2(100) NOT NULL, validosn CHAR(1) DEFAULT 'S' NOT NULL, fechacreacion DATE NOT NULL, fechaactualizacion DATE ) INITRANS 12 TABLESPACE &4; ALTER TABLE motivosuperacionpmenor ADD CONSTRAINT moti_validosn_ck ); ALTER TABLE motivosuperacionpmenor ADD CONSTRAINT moti_pk PRIMARY KEY (codigo) USING INDEX INIT RANS 16 TABLESPACE &5; INSERT INTO motivosuperacionpmenor (codigo, descripcion, fechacreacion) VALUES ('0', 'OTROS', Trunc(SYSDATE)); Análisis Técnico Página 69 4.2 Módulo de prescripción Las modificaciones que requiere el módulo de prescripción para soportar la prescripción por principio activo son muy sencillas, puesto que solo es necesario tener en cuenta que ahora un tratamiento puede estar justificado. 4.2.1 Soporte a las justificaciones en los tratamientos y recetas Se define tanto en la tabla de tratamientos, como en la de prescripción, el código del motivo de superación del precio menor y la descripción asociada. La descripción únicamente se utilizara cuando el usuario seleccione la opción “OTROS” para introducir las observaciones. En motivos codificados la descripción se leerá del maestro del repositorio de medicamentos. Figura 33 - Modelo de tratamiento y prescripción modificado La información sobre la justificación se guardará tanto en el tratamiento como en la receta, esto se debe a que una modificación en el tratamiento puede ocasionar que cambie la justificación, pero solo debe cambiar para las nuevas recetas, las antiguas ya se han impreso o dispensado con la justificación antigua, en caso de que existiese. A continuación tenemos el fragmento de código SQL para generar los cambios en la base de datos de la prestación farmacéutica. Análisis Técnico Página 70 4.3 Módulo de Tareas y Servicios En este módulo se incluyen todas aquellas tareas que se ejecutan en modo offline o segundo plano, siendo la tarea de generación de recetas la más destacada de todas las que existen. En la reunión de diseño técnico, se ha decido ampliar este módulo, para implementar todos los procesos offline y tareas que necesita el nuevo módulo de sustitución de tratamientos, como veremos más detenidamente ahora. Vamos a empezar a comentar los cambios necesarios en cada punto de la aplicación. 4.3.1 Tarea de Generación de Recetas El proceso que se ejecuta diariamente para generar los próximos bloques de recetas de los tratamientos vigentes de los pacientes necesita un pequeño ajuste para que funcione correctamente tras la implantación de la nueva versión del módulo. Cuando el proceso llegue al punto en el cual debe generar un nuevo bloque de recetas para un tratamiento, tendrá en cuenta los nuevos campos “codmotivosuppm” y “descmotivosuppm” que se han añadido al modelo de tratamiento y prescripción, copiando la información que haya en el tratamiento en ese momento a las nuevas recetas generadas. Esta información se utilizará en los proceso de impresión de recetas para obtener las justificaciones sin tener que consultar el tratamiento. ALTER TABLE tratamiento ADD codmotivosuppm VARCHAR2(2); ALTER TABLE tratamiento ADD descmotivosuppm VARCHAR2(100); ALTER TABLE tratamiento ADD CONSTRAINT trat_motipm_fk FOREIGN KEY ( codmotivosuppm ) REFERENCES motivosuperacionpmenor ( codigo ); ALTER TABLE prescripcion ADD codmotivosuppm VARCHAR2(2); ALTER TABLE prescripcion ADD descmotivosuppm VARCHAR2(100); ALTER TABLE prescripcion ADD CONSTRAINT presc_motipm_fk FOREIGN KEY ( codmotivosuppm ) REFERENCES motivosuperacionpmenor ( codigo ); Análisis Técnico Página 71 4.3.1.1 Cambios en el modelo de clases Crearemos la nueva entidad “MotivoJustificacion”, y se asociara tanto al tratamiento como a la receta. Sus atributos son:  Código: se corresponde con el código oficial de la tabla “motivosuperacionpmenor”  Descripción: se corresponde con la descripción oficial de la tabla “motivosuperacionpmenor”  Observaciones: en caso de que el usuario elija el motivo “OTROS” con código “0”, las observaciones contendrá el texto manual introducido por el usuario. +getRecetas() -fechaInicio : Date -fechaFin : Date -duracionEnvase : double -numeroEnvases : long Tratamiento -codigo : string -descripcion : string -observaciones : string MotivoJustificacion -numeroReceta : string -estado : char -fecha : Date -financiacion : int Receta * 0..1 * 0..1 11..* Figura 34 - Modelo de clases de la tarea de generación de recetas 4.3.1.2 Modificación en la tarea de generación de recetas La tarea de generación de recetas, que se pone en marcha diariamente en horario de baja actividad, cuando se pone en marcha, realiza inicialmente en una consulta sobre la base de datos para recuperar todos aquellos tratamientos que se encuentran vigentes (estado = ‘A’) y que tienen la fecha de próxima generación menor a la fecha de hoy más diez días (fechaproxgen < hoy + 10). Debido a la gran cantidad de tratamientos, esta consulta suele tardar entre 30 y 40 minutos en ejecutarse, y recupera diariamente entre 70.000 y 80.000 tratamientos, y se generan aproximadamente entre 3 y 4 recetas por cada tratamiento, más de 250.000 recetas diarias. Posteriormente, para cada tratamiento, y comprobando que aún estamos en horario de baja actividad, se recupera toda la información relacionada con el tratamiento y necesaria para los siguientes procesos. A partir de este momento, se empiezan a realizar los cálculos de cuantas recetas se necesitan generar para el tratamiento actual. Una vez que se conoce el número de recetas necesarias, se inicia el proceso de generación del nuevo grupo de recetas, dentro del cual se incluirá el nuevo subproceso para copiar la información de la justificación (MotivoJustificacion), si existe, del tratamiento a las nuevas recetas generadas. Análisis Técnico Página 72 Cabe destacar, que por cada tratamiento que se procesa mediante la tarea de generación, se utiliza una transacción de base de datos diferente por razones de concurrencia y rendimiento en la propia base de datos, de esta forma evitamos bloqueos innecesarios entre la aplicación y la tarea de generación de tratamientos. En la siguiente figura tenemos el diagrama de flujo que representa la tarea de generación de recetas, donde se ha incluido el subproceso de copia de justificaciones, la pequeña modificación que hay que realizar en la tarea. Inicio Tarea de Generación de Recetas Tratamientos Vigentes: Estado = ‘A’ FechaProxGen < Hoy + 10 Hora Actual < Hora Fin Lista de Tratamientos Pendiente Tratamientos Procesados < Total SI Fin Proceso NO NO Obtener Datos Completos del Siguiente Tratamiento SI Calcular Número de Recetas a Generar Nuevas Recetas > 0 NO Generar Recetas Copiar MotivoJustificacion en la Nuevas Recetas SI Completar Transacción por Tratamiento Figura 35 - Tarea de generación de recetas Análisis Técnico Página 73 4.3.2 Ampliación del módulo de Servicios Web Se crearán dos nuevos Servicios Web que permitan comunicarse al nuevo módulo de sustitución de tratamientos con el módulo de tareas y servicios. De esta forma se podrían programar tanto la ejecución de las consultas que utilizan el filtro de cupo o CPA, que se consideran excesivamente pesadas, así como poder programar el momento en el que se quiere realizar las sustituciones en los tratamientos. Módulo de Tareas y Servicios SolicitarConsultaPPACupo SolicitarSustituirPPACupo Figura 36 - Módulo de Tareas y Servicios, y los nuevos servicios publicados 4.3.2.1 Servicio Web para consultar tratamientos Es necesaria la creación de un nuevo servicio web que se llamará “SolicitarConsultaPPACupo” para poder realizar la petición para consultar los tratamientos que incumplen la prescripción por principio activo en segundo plano, y poder recuperar los datos posteriormente, cuando el filtro de búsqueda utilizado es por cupo o CPA. Los parámetros de entrada que se utilizarán en este servicio son: Bloque Metadatos MensajeId integer FechaEnvio dateTime Usuario string Clave string Bloque Consulta PPA CodCPA long ClaveMedica long UserKey string CodProvinciaCol string NumColegiado string DcColegiado string Filtro string Los parámetros de salida son: Bloque Cabecera RespuestaId integer FechaRespuesta dateTime Análisis Técnico Página 80 El sistema de colas y ejecución de tareas está pensado para que tanto un servicio web, como una tarea que se ejecuta a una hora determinada puedan hacer uso de él. Inicialmente el proceso en cuestión, en nuestro caso el servicio web de solicitud de tratamientos no conformes con la prescripción por principio activo, enviarían un mensaje que contendría toda la información relativa a que tiene que ejecutarse, y con que parámetros. Este mensaje puede acabar encolado (“Q”) o huérfano (“H”) si la cola estuviese llena en ese momento. Los mensajes que están huérfanos (“H”), se intentarán enviar a la cola de nuevo con un cierto retardo, y si no está llena pasarán a estar encolados (“Q”). Los mensajes que se encuentra en la cola, por orden de llegada, se irán ejecutando, lo que nos lleva a tres estados diferentes en función del éxito de la ejecución:  Finalizado (“E”), el mensaje se ha ejecutado correctamente, y por tanto se finaliza el proceso.  Retrasado (“D”), se ha producido un error al intentar ejecutar el mensaje, puede deberse a varias razones, un fallo de comunicación con un WS, un bloqueo en la base de datos, etc. Se paralizará un tiempo (configurable) este mensaje, y se volverá a enviar al estado huérfano para que entre de nuevo en el circuito.  Cancelado (“C”), el mensaje se ha intentado ejecutar un número máximo de reintentos, pero siempre ha fallado, se cancela y finaliza su ciclo de vida. Con este sistema, se pretende controlar el tamaño de la cola que se genera, el número de mensajes que se procesan concurrentemente, tiempo entre mensajes, tiempo que se paran los mensajes para reintentar su ejecución, así como numero máximo de reintentos. Cabe destacar que todos los mensajes se persisten en la base de datos cuando llegan inicialmente, en el supuesto de que el sistema se parase, al volver a arrancar podría recuperar todos los mensajes que se estaban procesando. 4.3.3.1 Modelo de datos A continuación vamos a ver el modelo de datos necesario para soportar el sistema de mensajes que hemos planteado. El modelo está basado los mensajes que se encuentran dentro de las colas, y los servicios web o tareas programadas que originan los mensajes. El modelo se compone de cuatro tablas, que vamos a ver a continuación, junto a las columnas más importantes:  SERVICIOS_WEB: mantiene la relación y configuración de los diferentes servicios web que se gestionan mediante las colas, de momento serán únicamente los servicios de sustitución de tratamientos. o SERVICIOS_WEB_ID, identificador del servicio. o CLASE_NOMBRE, nombre descriptivo del servicio. Análisis Técnico Página 81 o URL, en caso de tratarse de un cliente. o USUARIO, nombre de usuario para invocar el servicio. o CONTRASENYA, contraseña utilizada para invocar el servicio. o PROCESADOMSG, indica si se procesan las peticiones recibidas en la cola ‘C’ o fuera de ella ‘L’. o CALLBACK, nombre del bean que debe invocarse después de la ejecución del servicio. o CLIENTE_SERVIDOR, indica si se trata de un cliente de WS ‘C’ o un servidor ‘S’.  COLAMSG: tabla para mantener los mensajes que están en la cola del sistema. o COLAMSG_ID, identificar del mensaje que se encuentra en la cola, o que ya ha sido procesado. o SERVICIOS_WEB_ID, identificador del servicio web que ha generado el mensaje en la cola. o ESTADO, estado del mensaje o tarea, puede tener los siguientes valores:  RUNNING ("P"), está ejecutándose la tarea.  FINISHED ("E"), la tarea ya se ha ejecutado y está finalizada.  CANCELLED ("C"), la tarea se ha intentado ejecutar un número máximo de reintentos, pero siempre ha fallado, finalmente se cancela.  QUEUED ("Q"), se encuentra en la cola, esperando su turno de ejecución.  DELAYED ("D"), se ha producido un error en la ejecución, y se reintentará más tarde.  KILLED ("K"), se ha matado la tarea, actualmente no se utiliza, pero esta pensado para proporcionar un método de matar o detener las tareas en ejecución.  ORPHAN ("H"), mensajes que se han quedado fuera de la cola por estar llena, y que se intentarán enviar posteriormente. o CONTENIDO, el contenido del mensaje que ha llegado codificado en JSON para poder revisar los mensajes de la cola, se utiliza como auditoría.  COLAMSG_LOG: auditoria sobre los mensajes de la cola. o COLAMSG_LOG_ID, identificador del log del mensaje. o COLAMSG_ID, mensaje al que hace referencia. o NUMEROREINTENTO, número de reintentos que lleva. o FECHA, fecha en la que se ha generado la auditoria.  CONTENIDOMSG: mantiene el contenido de los mensajes mientras está pendiente la tarea, posteriormente se elimina el registro. o COLAMSG_ID, mensaje al que hace referencia. o MENSAJE, contenido del mensaje serializado sin alterar. o MOCHILA, información adicional que se le puede asociar a un mensaje. o RESPUESTA, respuesta del servicio serializada, si es necesario. Análisis Técnico Página 82 Figura 39 - Modelo para la gestión de mensajes y colas Análisis Técnico Página 83 Script de base de datos para generar el modelo correspondiente con los servicios web. CREATE TABLE servicios_web ( servicios_web_id NUMBER (14) NOT NULL, clase_nombre VARCHAR2 (254) NOT NULL, descripcion VARCHAR2 (254) NOT NULL, url VARCHAR2 (254) NOT NULL, usuario VARCHAR2 (254), contrasenya VARCHAR2 (254), procesadomsg CHAR (1) DEFAULT 'C' NOT NULL, politicareintento CHAR (1) DEFAULT 'F' NOT NULL, intervalo_reintentos NUMBER (6) NOT NULL, numeromaximoreintentos NUMBER (3) DEFAULT 10 NOT NULL, callback VARCHAR2 (254) NOT NULL, version NUMBER (14) NOT NULL, validosn CHAR (1) DEFAULT 'S' NOT NULL, fechacreacion DATE NOT NULL, fechaactualizacion DATE, cliente_servidor CHAR (1) DEFAULT 'C' NOT NULL, diaejecucion VARCHAR2 (500 byte), mesejecucion VARCHAR2 (36 byte), enejecucion CHAR (1 byte), fechaultimaejecucion DATE ); ALTER TABLE servicios_web ADD CONSTRAINT ckc_procesadomsg_servicio CHECK ( procesadoms g IN ('C', 'L')); ALTER TABLE servicios_web ADD CONSTRAINT ckc_politicareintento_servicio CHECK ( politi careintento IN ('F', 'L', 'G')); ALTER TABLE servicios_web ADD CONSTRAINT ckc_validosn_servicio CHECK ( validosn IN ('N ', 'S')); ALTER TABLE servicios_web ADD CONSTRAINT ckc_cliente_servidor_servicio CHECK ( cliente _servidor IN ('C','S')); ALTER TABLE servicios_web ADD CONSTRAINT ckc_enejecucion_servicio CHECK ( enejecucion IS NULL OR ( enejecucion IN ('S', 'N'))); Análisis Técnico Página 84 Script de base de datos para generar el modelo correspondiente con los mensajes en las colas. CREATE TABLE colamsg ( colamsg_id NUMBER (14) NOT NULL, servicios_web_id NUMBER (14) NOT NULL, fechaultimoenvio DATE NOT NULL, numeroreintentos NUMBER (3) DEFAULT 0 NOT NULL, estado CHAR (1 byte) DEFAULT 'P' NOT NULL, fecharecepcion DATE, version NUMBER (14) NOT NULL, fechacreacion DATE NOT NULL, fechaactualizacion DATE, contenido VARCHAR2 (2000 byte) NOT NULL, respuesta VARCHAR2 (2000 byte) ); ALTER TABLE colamsg ADD CONSTRAINT ckc_estado_colamsg CHECK ( estado IN ('C', 'D ', 'E', 'H', 'K', 'P', 'Q')); CREATE UNIQUE INDEX colamsg_pk ON colamsg ( colamsg_id ASC ); CREATE INDEX colamsg_idx ON colamsg ( servicios_web_id ASC ); ALTER TABLE colamsg ADD CONSTRAINT colamsg_pk PRIMARY KEY ( colamsg_id ); ALTER TABLE colamsg ADD CONSTRAINT colamsgservicios_web_fk FOREIGN KEY ( servici os_web_id ) REFERENCES servicios_web ( servicios_web_id ); CREATE UNIQUE INDEX servicios_web_pk ON servicios_web ( servicios_web_id ASC ); CREATE UNIQUE INDEX servicios_web_ak ON servicios_web ( clase_nombre ASC ); ALTER TABLE servicios_web ADD CONSTRAINT servicios_web_pk PRIMARY KEY ( servicios_web_ id ); ALTER TABLE servicios_web ADD CONSTRAINT servicios_web_ak UNIQUE ( clase_nombre ); Análisis Técnico Página 85 Script de base de datos para generar el modelo correspondiente para auditar las colas. Script de base de datos para generar el modelo correspondiente con el contenido de los mensajes de las colas. CREATE TABLE contenidomsg ( colamsg_id NUMBER (14) NOT NULL, mensaje BLOB, mochila BLOB, respuesta BLOB ); CREATE UNIQUE INDEX contenidomsg_pk ON contenidomsg ( colamsg_id ASC ); ALTER TABLE contenidomsg ADD CONSTRAINT contenidomsg_pk PRIMARY KEY ( colamsg_id ); ALTER TABLE contenidomsg ADD CONSTRAINT contenidomsgcolamsg_fk FOREIGN KEY ( colamsg_ id ) REFERENCES colamsg ( colamsg_id ); CREATE TABLE colamsg_log ( colamsg_log_id NUMBER (14) NOT NULL, colamsg_id NUMBER (14) NOT NULL, numeroreintento NUMBER (3) DEFAULT 0 NOT NULL, fecha DATE NOT NULL ); CREATE UNIQUE INDEX colamsg_log_pk ON colamsg_log ( colamsg_log_id ASC ); CREATE INDEX colamsg_log_idx ON colamsg_log ( colamsg_id ASC ); ALTER TABLE colamsg_log ADD CONSTRAINT colamsg_log_pk PRIMARY KEY ( colamsg_log_id ) ; ALTER TABLE colamsg_log ADD CONSTRAINT colamsg_logcolamsg_fk FOREIGN KEY ( colamsg_i d ) REFERENCES colamsg ( colamsg_id ); Análisis Técnico Página 86 4.4 Nuevo Módulo de Sustitución de Tratamientos El nuevo módulo utilizará tanto el modelo de datos que ya hemos visto anteriormente en el módulo de tareas y servicios, como los nuevos servicios web que permitirán:  Ejecutar las consultas de tratamientos que incumplen la prescripción por principio activo cuando el filtro utilizado es por cupo o CPA.  Ejecutar las sustituciones en los tratamientos que se hayan configurado a partir de una tarea de consulta. Módulo de Sustitución de Tratamientos SolicitarConsultaPPACupo SolicitarSustituirPPACupo Figura 40 - Módulo de Sustitución de Tratamientos, y los nuevos clientes de Servicios Web Con este objetivo, se implementarán los clientes de los servicios “SolicitarConsultaPPACupo” y “SolicitarSustituirPPACupo” que se publicarán con la nueva versión del módulo de tareas y servicios. En el anexo 3 se incluye el WSDL (Web Services Description Language) que define ambos servicios. Desarrollo realizado Página 87 5 Desarrollo realizado A lo largo del siguiente capítulo vamos a hablar del desarrollo que se ha realizado por parte del equipo de desarrollo que estaba a disposición del proyecto, y más concretamente, por las piezas de software que han sido desarrolladas por mí. El equipo de desarrollo de Indra para este proyecto se componía en dicho momento de 7 personas, equipo en el cual me hallaba incluido desempeñando mi trabajo a tiempo completo. Como ya hemos visto en el capítulo anterior, la parte de desarrollo que se me asignó se correspondió principalmente con las modificaciones del módulo de tareas y servicios, que es principalmente lo que vamos a estudiar en esta parte del documento. 5.1 Módulo de Tareas y Servicios El módulo de tareas y servicios es una aplicación web construida en java (J2EE), que utiliza Ibatis para la capa de acceso a base de datos, Spring para crear los servicios e integrar las diferentes piezas, así como la generación de las diferentes tareas programadas, control de transacciones, etc., Apache CXF para gestionar los servicios web (cliente y servidor), y se publican algunos servicios mediante RESTful para la interfaz de administración. Web Services RESTful Services CXF Spring MVC Database Services Business Layer Workflows Components Entities DAO Layer ORM (Ibatis) Other Data Sources Spring (AOP, Exception, Transaction, Logging, Scheduling) Figura 41 - Módulo de Tareas y Servicios, arquitectura del proyecto Desarrollo realizado Página 88 Para poder gestionar el proyecto fácilmente, agilizar el desarrollo y tener una forma sencilla de construcción de los empaquetados finales, se utiliza Apache Maven en el proyecto. Los cambios que son necesarios aplicar en el módulo de tareas y servicios están separados en tres partes claramente diferencias, las modificaciones en la tarea nocturna de generación de recetas, la creación de los dos nuevos servicios web, y el sistema de colas de ejecución de tareas para gestionar las peticiones que nos vayan llegando desde el módulo de sustitución de tratamientos. 5.1.1 Tarea de Generación de Recetas Para hacer posible que la tarea de generación de recetas pueda copiar la información del tratamiento, referente a las justificaciones introducidas por el facultativo, a las nuevas recetas que se van a generar, ha sido necesario realizar las siguientes modificaciones en la tarea:  El primer paso es crear la entidad de modelo “MotivoJustificacion”, dentro del paquete “es.indra.pfar.job.genrec.model”, con los atributos: o “codigo”, de tipo “string”. o “descripcion”, de tipo “string”. o “observaciones”, de tipo “string”.  Se crea en las clases de modelo “Tratamiento” y “Receta” un atributo con el nombre “motivoJustificación” de tipo “MotivoJustificacion”.  Se modifica el archivo “Tratamiento.xml” de configuración de Ibatis, para incluir en la consulta a la base de datos la lectura del motivo de justificación, si es que existe, y que lo cargue correctamente en el atributo “motivoJustificacion” de la clase “Tratamiento”. o “codigo”, campo “codmotivosuppm” de la tabla “tratamiento”. o “descripcion”, campo “descripcion” de la tabla “motivosuperacionpmenor”. Será necesario incluir dicha tabla en la consulta para poder recuperar este valor. o “observaciones”, campo “descmotivosuppm” de la tabla “tratamiento”.  Se modifica la clase “JobGeneracionReceta” que se encuentra en el paquete “es.indra.pfar.job.genrec.service” para que realice la copia de la justificación del tratamiento a la receta. o Método “doNewReceta”, se incluye la siguiente instrucción: receta.setMotivoJustificacion(tratamiento.getMotivoJustificacion);  Se modifica el archivo “Receta.xml” de configuración de Ibatis, para incluir en la sentencia de inserción en la base de datos, los campos destinados a contener la justificación del facultativo. o “codmotivosuppm”: atributo “codigo” de la clase “MotivoJustificacion”. o “descmotivosuppm”: atributo “observaciones” de la clase “MotivoJustificacion”. Desarrollo realizado Página 89 5.1.2 Implementación de los Servicios Web El módulo de tareas y servicios ya implementaba anteriormente algunos servicios web que utilizaban CXF, por lo tanto la configuración que hubo que realizar en caso se corresponde únicamente con la publicación de los nuevos servicios. El archivo de configuración de Maven (pom.xml) del proyecto ya contenía las dependencias necesarias para poder hacer uso de CXF, el fragmento de configuración de Maven que obtiene las dependencias es el siguiente: Haciendo uso de las facilidades que proporciona Maven, hacemos uso del “plugin” que proporciona Apache CXF (“cxf-codegen-plugin”) para la generación automática del código fuente tanto de los clientes como de los servidores, proporcionándole simplemente el archivo WSDL (Web Services Description Language), habitualmente conocido como contrato, ya que informa claramente de la interfaz del servicio. Así pues, añadimos a la configuración de nuestro “plugin” un grupo de etiquetas nuevas, que nos permite indicar la ubicación de nuestro WSDL, para que genere automáticamente el código. Le añadimos dentro de la configuración mediante las etiquetas <wsdlOption> la información que necesita para encontrar el WSDL. A continuación podemos ver la sección de código completa que sería necesaria para incluir este “plugin”, así como su configuración, con el caso que estamos describiendo. <wsdlOption> <wsdl>${basedir}/src/main/resources/wsdl/sustitucion.wsdl</wsdl> <wsdlLocation>classpath:/wsdl/sustitucion.wsdl</wsdlLocation> </wsdlOption> <!-- CXF (JAX-WS) --> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-frontend-jaxws</artifactId> <version>${cxf.version}</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-transports-http</artifactId> <version>${cxf.version}</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-ws-security</artifactId> <version>${cxf.version}</version> </dependency> Desarrollo realizado Página 96 A continuación tenemos el archivo de configuración de Spring “appContext-process.xml” que donde se encuentra toda la configuración del router, la cola y los diferentes canales que se han utilizado de Spring Integration, y que se describe en la figura anterior. <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:int="http://www.springframework.org/schema/integration" xmlns:task="http://www.springframework.org/schema/task" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans3.0.xsd http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/springintegration-1.0.xsd http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task-3.0.xsd"> <int:channel id="inbox"> <int:queue capacity="${PFAR.InboxCapacity}" /> </int:channel> <int:router input-channel="inbox" ref="senderRouter"> <int:poller max-messages-per-poll="${PFAR.MessagesPerPoll}"> <int:cron-trigger expression="${PFAR.PollerTrigger}" /> </int:poller> </int:router> <int:channel id="pending"> <int:interceptors> <int:ref bean="delayCalculatorListener" /> </int:interceptors> </int:channel> <int:delayer default-delay="0" delay-header-name="delay" inputchannel="pending" output-channel="delayed" /> <int:channel id="delayed" /> <int:outbound-channel-adapter id="resend" channel="delayed" ref="endEndpoint" method="resend" /> <int:outbound-channel-adapter id="finished" ref="endEndpoint" method="finish" /> <int:outbound-channel-adapter id="cancelled" ref="endEndpoint" method="cancel" /> <int:outbound-channel-adapter id="changeowner" ref="endEndpoint" method="abort" /> <!-- Se encarga de cargar en la cola los mensajes expirados (aquellos que están en la cola demasiado tiempo, posiblemente porque el contenedor se ha reiniciado) --> <task:scheduler id="schedulerExpired" pool-size="1" /> <!-- Se encarga de cargar los mensajes que no pertenecen a ningún proceso, estos procesos no se pudieron añadir a la cola por sobrecarga --> <task:scheduler id="schedulerOrphan" pool-size="1" /> <!-- Se encarga de procesar los servicios de tipo job --> <task:scheduler id="schedulerCron" pool-size="10" /> </beans> Desarrollo realizado Página 97 Adjunto a continuación un fragmento de código procedente del “SenderRouter” donde se puede observar como intenta ejecutar el mensaje recibido a través del “callback” que se le haya definido, según el resultado de la ejecución devuelve los siguientes valores:  FINISHED, se ha procesado correctamente.  CHANGE_OWNERSHIP, en el caso de que el registro del mensaje haya cambiado en la base de datos, por motivos de concurrencia, se deja morir el mensaje, puesto que lo estará procesando otro nodo diferente.  CANCELLED, la tarea ha fallado y ya se ha superado el número máximo de reintentos.  FINISHED, la tarea ha fallado, pero aún tenemos hay disponibles reintentos. El valor devuelto por este método indica el canal al que será enviado el mensaje. @Router public String resolveMessageChannel(Mensaje message) { try { logger.info("SenderRouter - Ejecutando " + message); mensajeService.ejecutar(message); Object data = null; if (servicioConRespuestaWs(message)) { data = invokeService(message); // Guardamos la respuesta en el objeto, al finalizar se persistirán en BD ObjectParser oRespuesta = new ObjectParser(data); oRespuesta.setAlias("respuesta", CrearSolicitudResponse.class); message.getContenidoMensaje().setRespuesta(oRespuesta.getXmlDest()); message.setRespuesta(oRespuesta.getJsonDest()); } if ( ! "none".equals(message.getServicio().getCallback())) { MessageCallback callback = callbackLocator.locate(message.getServicio().getCallback()); callback.invoke(data, message); } } catch (OptimisticLockException e) { return CHANGE_OWNERSHIP; } catch (Exception e) { logger.error("Error al ejecutar el servicio: ", e); // check limit to cancel message delivery if (message.getNumeroReintentos() + 1 > message.getServicio().getNumeroMaximoReintentos()) { return CANCELLED; } else { return PENDING; } } return FINISHED; } Desarrollo realizado Página 98 Finalmente, tenemos una última clase “SustitucionesMessageLoader”, que es una tarea programada que se pone en marcha a las 20:00 horas de cada día, y que buscará todas aquellas sustituciones que están en estado 4 y con la fecha de solicitud de sustitución menor o igual a hoy (WHERE FLAGESTADO = 4 AND FECHAINISUST <= SYSDATE). Para cada uno de los resultados devueltos por la consulta se generará un mensaje que se enviará al “SenderGateway” para iniciar su procesado. 5.2 Nuevo Módulo de Sustitución de Tratamientos La tecnología utilizada para la arquitectura del nuevo módulo ha sido exactamente la misma que hemos descrito en el módulo de tareas y servicios, se trata de una aplicación Web construida con Java, y que utiliza Ibatis para la capa de acceso a base de datos, Spring para crear los servicios e integrar las diferentes piezas, y finalmente Apache CXF para hacer uso de los diferentes servicios web que requería el nuevo módulo. Finalmente, con el objetivo de poder gestionar el proyecto fácilmente, agilizar el desarrollo y tener una forma sencilla de construcción de los empaquetados finales, se ha incluido el uso de Apache Maven en el proyecto. Mi desarrollo en este nuevo módulo se limitó a la configuración de Apache CXF para poder utilizarlo como framework para desarrollar los clientes de servicios web que necesita la aplicación, y el desarrollo de los mismos. El primer paso consiste en configurar Maven para nuestro proyecto, para agregarle las dependencias que necesita CXF. Para ello hemos editado el archivo “pom.xml” que contiene toda la configuración, y hemos añadido las dependencias de CXF que podemos ver en el siguiente bloque. Simplemente con esta modificación de la configuración de Maven, conseguimos incluir todas las dependencias que requiere CXF para la construcción y utilización de servicios web. <!-- CXF (JAX-WS) --> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-frontend-jaxws</artifactId> <version>${cxf.version}</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-transports-http</artifactId> <version>${cxf.version}</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-ws-security</artifactId> <version>${cxf.version}</version> </dependency> Desarrollo realizado Página 99 En el mismo fichero de configuración, existen otros grupos de dependencias para el resto de librerías y frameworks utilizados en el proyecto, entre los que destaca:  Spring, para la gestión de servicios e integración entre los diferentes frameworks.  Ibatis, para la capa de acceso a la base de datos.  Jettison, para el uso de JSON como formato de serializado.  Joda Time, para facilitar la gestión de fechas en Java.  Jasper Reports, para la generación de informes.  Junit y JMockit para crear pruebas unitarias para las diferentes piezas del proyecto. Por otro lado, y en la misma configuración de Maven, hemos añadido un “plugin” que nos permite generar código automáticamente a partir de un archivo de tipo WSDL, y por lo tanto, nos genera de forma sencilla, tanto la parte cliente como la parte servidor de cualquier servicio. Utilizamos el “plugin” que proporción Apache CXF para la integración con Maven, y que se llama “cxf-codegen-plugin”, de forma que al indicarle la ubicación de nuestro WSDL nos generará el código de nuestro servicio web. A continuación podemos ver la sección de código necesaria para incluir este “plugin”, así como su configuración. El archivo WSDL utilizado se encuentra en el anexo 3 de este documento. Una vez que ya hemos acabado con la configuración de Maven para el proyecto, simplemente necesitamos ejecutar la fase de generación de fuentes para que genere todas las clases necesarias para el servicio web. <!-- CXF CodeGen Maven Plugin --> <plugin> <!-- This plugin allows to generate jax-ws classes from wsdl --> <groupId>org.apache.cxf</groupId> <artifactId>cxf-codegen-plugin</artifactId> <version>${cxf.version}</version> <executions> <execution> <id>generate-sources</id> <phase>generate-sources</phase> <configuration> <wsdlOptions> <wsdlOption> <wsdl>${basedir}/src/main/resources/wsdl/sustitucion.wsdl</wsdl> <wsdlLocation>classpath:/wsdl/sustitucion.wsdl</wsdlLocation> </wsdlOption> </wsdlOptions> </configuration> <goals> <goal>wsdl2java</goal> </goals> </execution> </executions> </plugin> Desarrollo realizado Página 100 O simplemente ejecutando esta fase desde nuestro IDE favorito, en eclipse por ejemplo, sería pulsando con el botón derecho del ratón en el proyecto, en el menú “Run As”, la entrada “Maven generate-sources”. El siguiente paso consiste en configurar el contexto de Spring, para que inicialice correctamente CXF, y nos cree los servicios clientes que queremos utilizar.  Para ello, le tenemos que decir a Spring que importe la configuración de CXF, que se encuentra en “META-INF/cxf/cxf.xml”.  Opcionalmente, podemos configurar los logs para CXF, y así poder ver la entrada y salida de los diferentes servicios web. Esto se hace con los interceptores de entrada y salida (LoggingInInterceptor y LoggingOutInterceptor).  Y por último, solo quedaría pedirle a Spring, que cree nuestro servicio web cliente. Con la etiqueta <jaxws:client> es posible configurar todo lo relativo a nuestro servicio. En nuestro caso hemos configurado el nombre de la instancia que se creará, la clase que lo define y la URL donde está el servidor publicado. A continuación se muestra la configuración completa de Spring que se ha hecho para integrar CXF y crear el cliente del servicio web “sustitucionesClient”. path>mvn generate-sources Desarrollo realizado Página 101 Con este desarrollo, mi parte del módulo de sustituciones de tratamientos había finalizado, ya que los encargados de utilizar estos servicios dentro de la aplicación eran otros compañeros del equipo. A modo de ejemplo, a continuación se muestra una pequeña clase en Java en la que podemos ver lo sencillo que sería utilizar este cliente. <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.apache.org/jaxws" xmlns:cxf="http://cxf.apache.org/core" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd"> <!-- Load CXF modules --> <import resource="classpath:META-INF/cxf/cxf.xml" /> <!-- Logging messages definitions (start) === --> <bean id="logInbound" class="org.apache.cxf.interceptor.LoggingInInterceptor" /> <bean id="logOutbound" class="org.apache.cxf.interceptor.LoggingOutInterceptor" /> <cxf:bus> <cxf:inInterceptors> <ref bean="logInbound" /> </cxf:inInterceptors> <cxf:outInterceptors> <ref bean="logOutbound" /> </cxf:outInterceptors> <cxf:outFaultInterceptors> <ref bean="logOutbound" /> </cxf:outFaultInterceptors> <cxf:inFaultInterceptors> <ref bean="logInbound" /> </cxf:inFaultInterceptors> </cxf:bus> <!-- Logging messages definitions (end) === --> <!-- Client bean definitions (start) === --> <jaxws:client id="sustitucionesClient" serviceClass="es.indra.pfar.ws.sustituciones.Sustituciones" address="{ws.url.sustituciones}"> <jaxws:properties> <entry key="schema-validation-enabled" value="true" /> </jaxws:properties> </jaxws:client> <!-- === Client bean definitions (end) --> </beans> Desarrollo realizado Página 102 Únicamente es necesario pedirle a Spring que nos inyecte el cliente del servicio web con la anotación “@Autowired”, y finalmente, ya podemos utilizar el cliente. En este caso, estaríamos haciendo una petición de cada tipo en el método “foo”, pero que se encuentran vacías, y por lo tanto, el servidor nos debería devolver un error. package es.indra.pfar.ws.inte; import org.springframework.beans.factory.annotation.Autowired; import es.indra.pfar.ws.sustituciones.SolicitarConsultaPPACupoRequest; import es.indra.pfar.ws.sustituciones.SolicitarConsultaPPACupoResponse; import es.indra.pfar.ws.sustituciones.SolicitarSustituirPPACupoRequest; import es.indra.pfar.ws.sustituciones.SolicitarSustituirPPACupoResponse; import es.indra.pfar.ws.sustituciones.Sustituciones; public class Dummy { @Autowired private Sustituciones sustitucionesClient; public void foo() { // Data Petition SolicitarConsultaPPACupoResponse responseConsulta = sustitucionesClient.solicitarConsultaPPACupo(new SolicitarConsultaPPACupoRequest()); // Substitution Petition SolicitarSustituirPPACupoResponse responseSustituir = sustitucionesClient.solicitarSustituirPPACupo(new SolicitarSustituirPPACupoRequest()); } } Implantación del sistema Página 103 6 Implantación del sistema Indra proporcionó a los diferentes centros de datos de las comunidades autónomas que utilizan su sistema, una semana antes de la entrada en vigor del Real Decreto-Ley 9/2011, los siguientes recursos:  Formularios de actualización y reversión de las aplicaciones.  Ficheros en formato EAR con las diferentes aplicaciones o backoffice_2.08.00.ear o prescripcion_2.08.00.ear o prescripción_ws_2.08.00.ear  Ficheros comprimidos con los ficheros fuente de las aplicaciones, para realizar estudios y análisis de código o backoffice_2.08.00_src.zip o prescripcion_2.08.00_src.zip o prescripción_ws_2.08.00_src.zip  Ficheros con los scripts de base de datos necesarios para hacer la actualización de la versión, así como la reversión si ocurriese algún tipo de contingencia. En los formularios consta toda la información necesaria para que los técnicos de los centros de datos, con el soporte de los técnicos de Indra, puedan realizar la actualización de sus sistemas la noche del 31 de Octubre de 2011, para que estén disponibles todas las novedades el día 1 de Noviembre, momento en el que entra en vigor la nueva normativa. Implantación del sistema Página 104 DATOS GENERALES Fecha de solicitud 31/10/2011 Nombre de la aplicación Repositorio de medicamentos Módulo de prescripción Módulo de tareas y servicios Versión de la aplicación 2.08.00 Coordinador de la aplicación - Responsable desarrollo (técnico-empresa) - Tipo de despliegue Actualización Plataforma NISS Entorno al que se dirige el despliegue Producción DATOS TÉCNICOS Nombre del fichero con la aplicación backoffice_2.08.00.ear prescripcion_2.08.00.ear prescripción_ws_2.08.00.ear Ficheros de script (por orden de ejecución) Nombre Descripción BBDD OPERATIVA backoffice_ddl_v2.08.00_1.sql Modo de operación, en una sola línea: bash$ sqlplus /nolog @ backoffice_ddl_v2.08.00_1.sql user bbdd Cambios en el modelo. backoffice_dml_v2.08.00_1.sql Modo de operación, en una sola línea: bash$ sqlplus /nolog @ backoffice_dml_v2.08.00_1.sql user bbdd Cambios en los datos. prescripcion_ddl_v2.08.00_1.sql Modo de operación, en una sola línea: bash$ sqlplus /nolog @prescripcion_ddl_v2.08.00_1.sql user bbdd Cambios en el modelo. prescripcion_dml_v2.08.00_1.sql Modo de operación, en una sola línea: bash$ sqlplus /nolog @ prescripcion_dml_v2.08.00_1.sql user bbdd Cambios en los datos. Otros ficheros incluidos (manuales, documentación, ...) Fichero con los fuentes: backoffice_2.08.00_src.zip prescripcion_2.08.00_src.zip prescripción_ws_2.08.00_src.zip Modificaciones en el fichero de propiedades #ATENCION, EL TEXTO DE LA VARIABLE DEBE COPIARSE EN UNA SOLA LÍNEA Implantación del sistema Página 105 Añadir en el fichero local.properties: PFAR.limiteJustificaciones=100 PFAR.alerta.ppa.reqjustificacion=ALERTA, LA PRESENTACI\u00D3N NO DISPONE DE JUSTIFICANTE DE LA NECESIDAD TERAP\u00C9UTICA DE SU PRESCRIPCI\u00D3N Especificación secuencia de pasos a seguir en el despliegue: Secuencia de los pasos para realizar despliegue: parada contenedor de la aplicación y/o aplicaciones afectadas en el caso que proceda, ejecución sql si procede, despliegue del ear, arranque contenedor , reinicio, cambio propiedades, subir formularios y/o reports, etc. 1.- Modificar properties 2.- Parar la aplicación 3.- Ejecutar scripts BBDD 4.- Desplegar ear 5.- Parar y arrancar el Contenedor 6.- Arrancar la aplicación Nota: Por defecto si no indica nada, el orden con el que se efectuará el despliegue es : 1.- Modificar propiedades 2.- Subida de formularios, reports y/o ficheros estáticos 3.- Ejecución de scripts de base de datos 4.- Desplegar ear: En OAS v9 se hace parada contenedor, despliegue y arranque de contenedor. En OAS v10 se hace parada de aplicación, despliegue del ear y arranque de aplicación. Referencias Página 112 9 Referencias España. Real Decreto-ley 9/2011, de 19 de agosto. Boletín Oficial del Estado, 20 de agosto de 2011, núm. 200, p. 93143. Disponible en internet: http://www.boe.es/boe/dias/2011/08/20/pdfs/BOE-A-2011-14021.pdf España. Real Decreto 1718/2010, de 17 de diciembre. Boletín Oficial del Estado, 20 de enero de 2011, núm. 17, p. 6306. Disponible en internet: http://www.boe.es/boe/dias/2011/01/20/pdfs/BOE-A-2011-1013.pdf España. Consejo General de Colegios Oficiales de Farmacéuticos. Publicación RDL 9/2011 y prescripción por principio activo. 21 de octubre de 2011. España. Indra. Documentación oficial de análisis para las comunidades autónomas. 7 de septiembre de 2011. España. SemFYC (Sociedades de Medicina de Familia y Comunitaria). Disponible en internet: http://www.semfyc.es España. FarmaIndustria (Asociación Nacional Empresarial de la Industria Farmacéutica). Disponible en internet: http://www.farmaindustria.es Apache CXF. Disponible en internet: http://cxf.apache.org Spring Integration. Disponible en internet: http://www.springsource.org/spring-integration Wikipedia. Disponible en internet: http://es.wikipedia.org El Gobierno prevé ahorrar 2.400 millones con los medicamentos [en línea]. El país. España. 19 de agosto de 2011. Disponible en internet: http://politica.elpais.com/politica/2011/08/19/actualidad/1313743915_655940.html Anexos Página 113 10 Anexos Anexos Página 114 10.1 Anexo 1 (Nota de prensa del RDL 9/2011) Nota de prensa publicada cuando se aprobó el Real Decreto-Ley 9/2011 Anexos Página 115 10.2 WSDL para los Servicios Web <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="sustituciones" targetNamespace="http://www.pfar.indra.es/ws/sustituciones/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.pfar.indra.es/ws/sustituciones/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <wsdl:types> <xsd:schema targetNamespace="http://www.pfar.indra.es/ws/sustituciones/"> <!-- Types --> <xsd:complexType name="MensajeMetadata"> <xsd:sequence> <xsd:element name="MensajeId" type="xsd:positiveInteger" /> <xsd:element name="FechaEnvio" type="xsd:dateTime" /> <xsd:element name="Usuario" type="xsd:string" /> <xsd:element name="Clave" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="RespuestaGenerica"> <xsd:sequence> <xsd:element name="RespuestaId" type="xsd:positiveInteger" /> <xsd:element name="FechaRespuesta" type="xsd:dateTime" /> <xsd:element name="NumSolicitud" type="xsd:int" /> <xsd:element name="CodigoError" type="xsd:string" /> <xsd:element name="Descripcion" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="SolicitarConsultaPPACupoRequest"> <xsd:sequence> <xsd:element name="Metadata" type="tns:MensajeMetadata" maxOccurs="1" minOccurs="1" /> <xsd:element name="ConsultaPPA" type="tns:ConsultaPPAReq" maxOccurs="1" minOccurs="1" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="SolicitarConsultaPPACupoResponse"> <xsd:sequence> <xsd:element name="Cabecera" type="tns:RespuestaGenerica" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="SolicitarSustituirPPACupoRequest"> <xsd:sequence> <xsd:element name="Metadata" type="tns:MensajeMetadata" /> <xsd:element name="IdTarea" type="xsd:long" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="SolicitarSustituirPPACupoResponse"> Anexos Página 116 <xsd:sequence> <xsd:element name="Cabecera" type="tns:RespuestaGenerica" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ConsultaPPAReq"> <xsd:sequence> <xsd:element name="CodCPA" type="xsd:long" maxOccurs="1" minOccurs="0" /> <xsd:element name="ClaveMedica" type="xsd:long" maxOccurs="1" minOccurs="0" /> <xsd:element name="UserKey" type="xsd:string" /> <xsd:element name="CodProvinciaCol" type="xsd:string" maxOccurs="1" minOccurs="0" /> <xsd:element name="NumColegiado" type="xsd:string" maxOccurs="1" minOccurs="0" /> <xsd:element name="DcColegiado" type="xsd:string" maxOccurs="1" minOccurs="0" /> <xsd:element name="filtro" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <!-- Elements --> <xsd:element name="SolicitarConsultaPPACupoRequest" type="tns:SolicitarConsultaPPACupoRequest" /> <xsd:element name="SolicitarConsultaPPACupoResponse" type="tns:SolicitarConsultaPPACupoResponse" /> <xsd:element name="SolicitarSustituirPPACupoRequest" type="tns:SolicitarSustituirPPACupoRequest" /> <xsd:element name="SolicitarSustituirPPACupoResponse" type="tns:SolicitarSustituirPPACupoResponse" /> </xsd:schema> </wsdl:types> <!-- Message --> <wsdl:message name="SolicitarConsultaPPACupoRequest"> <wsdl:part name="parameters" element="tns:SolicitarConsultaPPACupoRequest" /> </wsdl:message> <wsdl:message name="SolicitarConsultaPPACupoResponse"> <wsdl:part name="data" element="tns:SolicitarConsultaPPACupoResponse" /> </wsdl:message> <wsdl:message name="SolicitarSustituirPPACupoRequest"> <wsdl:part name="parameters" element="tns:SolicitarSustituirPPACupoRequest" /> </wsdl:message> <wsdl:message name="SolicitarSustituirPPACupoResponse"> <wsdl:part name="data" element="tns:SolicitarSustituirPPACupoResponse" /> </wsdl:message> <!-- Port Type --> <wsdl:portType name="Sustituciones"> <wsdl:operation name="SolicitarConsultaPPACupo"> Anexos Página 117 <wsdl:input message="tns:SolicitarConsultaPPACupoRequest" /> <wsdl:output message="tns:SolicitarConsultaPPACupoResponse" /> </wsdl:operation> <wsdl:operation name="SolicitarSustituirPPACupo"> <wsdl:input message="tns:SolicitarSustituirPPACupoRequest" /> <wsdl:output message="tns:SolicitarSustituirPPACupoResponse" /> </wsdl:operation> </wsdl:portType> <!-- Bindings --> <wsdl:binding name="SustitucionesSOAP" type="tns:Sustituciones"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="SolicitarConsultaPPACupo"> <soap:operation soapAction="http://www.pfar.indra.es/ws/sustituciones/SolicitarConsultaPPACup o" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="SolicitarSustituirPPACupo"> <soap:operation soapAction="http://www.pfar.indra.es/ws/sustituciones/SolicitarSustituirPPACu po" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <!-- Service --> <wsdl:service name="SustitucionesService"> <wsdl:port name="SustitucionesSOAPPort" binding="tns:SustitucionesSOAP"> <soap:address location="http://www.pfar.indra.es/ws/sustituciones/" /> </wsdl:port> </wsdl:service> </wsdl:definitions>