Proceso:
ObjetoModelar la solicitud de peticiones de integración que se hacen a la Oficina de Interoperabilidad tanto para aplicaciones departamentales como para aplicaciones centralizadas. AlcanceEste proceso tiene como alcance las peticiones de integración de aplicaciones departamentales o centralizadas solicitadas a la Oficina de Interoperabilidad (en adelante OTI) según la normativa definida por ésta. Actividades del procesoLas tareas de integración van a modelarse en JIRA, con lo que el primer paso es asegurarse de que el proyecto (provincial o aplicación centralizada) esté dado de alta Por otra parte, por cada integración , la OTI creará una página en CONFLUENCE en el espacio de la Oficina de Interoperabilidad, 05. Aplicaciones, donde tiene acceso el proveedor de la aplicación que solicita la integración. La estructura de la página de aplicación es la siguiente:

Pueden darse dos casos: - Si el proveedor tiene acceso al proyecto en JIRA, podrá hacer el seguimiento de la tarea además de interactuar con la OTI en su espacio.
- Si el proveedor no tiene acceso al proyecto en JIRA, solamente hará la interacción con la OTI en CONFLUENCE
Una vez seleccionado el proyecto para el que se solicita la integración, hay que elegir el tipo de registro "Tarea de integración" y completar los datos solicitados: Título de la tarea: Se recomienda que sea con el formato Nombre de la Aplicación – Ámbito de Integración (Hospital) Descripción: Breve explicación de lo que se solicita Hospital: seleccionar en un desplegable el hospital para el que se solicita la integración Ámbitos de integración: desplegable con los posibles valores de los ámbitos de integración: - Asistencial,
- Censo,
- Citas,
- Clínico,
- Demográfico,
- Económico,
- Estructural,
- Historia,
- Prestaciones INSS,
- Índice Maestro paciente,
- Laboratorio,
- Logística,
- Maestros,
- Medicación,
- Profesional,
- Quirúrgico,
- Radiología,
- Seguridad,
- Usuario
- Notificación
Si se tienen, pueden informarse los códigos de MACO PRE y PRO. Primer caso: Hay que desarrollar el servicio de integraciónAplicaciones centralizadas

Aplicaciones departamentalesPara el caso de aplicaciones departamentales, al crear la tarea de integración habrá que indicar si está o no preaprobada por un Responsable de la STIC. En el caso de que no estuviera preaprobada, se requerirá la aprobación de dicho Responsable. Hay que tener en cuenta que la aplicación que tiene la necesidad de integrarse es la que debe crear la tarea de integración en su proyecto. En principio, la aplicación con la que se debe integrar no debe desarrollar nada, aunque es ciero que hay veces ebn las que el proveedor de la aplicación destino debe participar en esas tareas. En estos casos, se solicitará acceso al proyecto en el que se gestiona la tarea de integración. 
La tarea se crea asignada al grupo de la Oficina de Interoperabilidad (OTI en adelante) en un estado denominado INICIO DOCUMENTACION. En este estado, la OTI analiza de entrada la integración solicitada y pide al solicitante todos los detalles sobre las necesidades funcionales y técnicas de la integración. Será necesario detallar cada requisito que consideren necesario cumplir con sus casos de uso correspondientes. Esta definición de necesidades se hace con la tarea en estado REQUISITOS asignada al solicitante. Una vez que los requisitos están claros por parte de la aplicación solicitante, la tarea vuelve a la OTI pasando al estado ANÁLISIS/DISEÑO. Normalmente en este estado, la OTI solicita autorización a la STIC de la definición de servicios. Para ello, solicita autorización al Responsable de producto de la aplicación destino. Si no la obtuviera, volvería a ese estado y desde el mismo se cancelaría la tarea, Una vez obtenida, la OTI desarrolla el servicio de integración para cubrir las necesidades del solicitante. Si surgen dudas se podrán resolver o bien mediante comentarios en la propia tarea si es que el proveedor tiene acceso al proyecto en JIRA o con comentarios en la página de CONFLUENCE del espacio de a OTI donde se documenta la integración. Normalmente se incluye en esta un diagrama donde se muestra de forma esquemática los servicios presentes en la integración, además de una tabla con todos ellos y enlaces a la documentación detallada de cada uno para poder abordar el desarrollo de manera eficaz. Una vez definido el servicio de integración, la tarea pasa a estado DESARROLLO asignada al solicitante para que el proveedor desarrolle todo lo necesario en su aplicación para que la integración funcione. Una vez hechos los desarrollos, es necesario hacer la configuración en PRE, con lo que la tarea pasará a estado CONFIGURACIÓN PRE y se asignará de nuevo a la OTI. Una vez hecha la configuración en PRE, será necesario que la OTI haga las pruebas de integración sobre los servicios que se consumen y exponen en la integración en caso de que no se hayan certificado anteriormente. En la página de CONFLUENCE correspondiente se documentarán todas esas pruebas y podrán revisarse los resultados de la mismas. Mientras la OTI esté realizando estas pruebas, la tarea estará en estado PRUEBAS INTEGRACIÓN. Una vez acabadas las pruebas satisfactoriamente, la tarea pasará a estado PRUEBAS FUNCIONALES asignada al solicitante, para que el proveedor identifique todos los casos de uso de pruebas funcionales que se crean oportunos e indique los resultados cuando se ejecuten. Para ello, están disponibles apartados donde indicar los casos de uso, los mensajes obtenidos en las respuestas y un resumen de cada caso de uso con su resultado. Como guía se ofrecen unas recomendaciones sobre los casos de uso más comunes para sistemas que ya han sido integrados en otros hospitales, pero por supuesto se pueden proponer tantos casos de uso como el proveedor y el hospital en cuestión consideren necesarios. Cuando se den por satisfactorias las pruebas funcionales, la tarea pasará a estado CONFIGURACIÓN PRO de nuevo en el tejado de la OTI. Una vez hecha la configuración en PRO, la tarea vuelve a pasar al solicitante en estado COORDINACIÓN ARRANQUE para acordar la fecha en la que comenzará este nuevo módulo. Es importante que se actualice el espacio de la aplicación solitcitante, y que en la página correspondiente a interopeabilidad se enlace al esacio d la OTI donde se ha documentado todo. Una vez hecho, la tareas se pasará a CIERRE DOCUMENTACIÓN por parte de la OTI. Al acabar el cierre de la documentación, la tarea se cerrará.
Hay que tener en cuenta que desde cualquier estado la tarea de integración puede pasar a PARALIZADA si es que se bloquea por algún motivo, no reanudándose hasta que no se haya eliminado el bloqueo. Por otra parte, hay integraciones que dependen de que se finalicen otras, por lo que siempre que la tarea esté asignada a la OTI puede llegar a ese estado, retomando el flujo una vez que haya acabado la integración que bloqueaba la primera. Por último, hay un estado de las tareas de integración que es EN COLA, de manera que en ese estado se indica que hay actividad que sobrepasa al dimensionamiento de la OTI y están a la espera de que vaya acabándose el trabajo que está en curso.
Segundo caso: El servicio de integración está ya desarrolladoEl ciclo de vida de la tarea de integración es el mismo, con la diferencia de que hay estados por los que no debe pasar, por ejemplo, no hace falta pasar por DESARROLLO ni por PRUEBAS INTEGRACIÓN.
Cuando se crea una tarea de integración, se crea siempre relacionada con ella una tarea para que la OTI gestione los incurridos de las tareas de integración. |
¿Cómo se gestionan posibles actuaciones relacionadas con las tareas de integrción cuando éstas ya están cerradas? Cualquier actuación una vez que la tarea esté cerrada, entrará en la línea de Operación y por tanto, tiene que ser creada como una solicitud en ayudaDIGITAL. Además, esbuna práctica crear una tarea general en el proyecto y relacionarla con la tarea de integración. De esta forma, los integrantes de la OTI podrán interactuar con el proveedor, sibre todo en los casos en los que este no trabaje habitualmente con ayudaDIGITAL. |
|