Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

1.Procedimiento de Gestión de Peticiones de Integración

La petición de integración puede solicitarse por parte del responsable del hospital o por un responsable de la STIC, y ésta solicitud puede venir por correo o a través de CGES. Una vez que recepcionamos y planificamos por parte de la OTI dicha petición, el procedimiento que seguimos para tratarla es el siguiente: 

1. Se deben responder las cuestiones planteadas para tener un análisis de la situación y las necesidades lo más completo posible. A modo genérico, dichas cuestiones son:
   • ¿Cuál es el nombre de la aplicación?
   • ¿En qué ámbito funcional se engloba? 
   • ¿Cuál es el objetivo principal del sistema a integrar/cuál es la necesidad funcional?
   • ¿Cuál es el circuito funcional, dentro del ámbito de la integración, que se sigue cuando el usuario utiliza la aplicación?
   • ¿El sistema a integrar está funcionando en otros hospitales del SAS?
   • ¿Qué información necesita recibir?
   • ¿Qué información necesita notificar?
2. Entrega por parte de la OTI de la definición de servicios a la STIC para su aprobación. 
   • Plantilla de Solicitud de Acceso a Servicio
3. Con el OK a la definición de los servicios por parte de la STIC, realización del contrato de integración por parte de la OTI.
4. Entrega de contrato de integración al cliente.
5. Desarrollo por parte de la OTI
6. Entrega de documentación referente a los servicios a los que se integra, así como la documentación referente a MACO y ticket MACO para el desarrollo por parte del módulo que solicita la integración.
   Indicar que por parte del Área de Arquitectura se ofrece una libreria de MACO, la cual está desarrollada en Java y .Net: https://ws001.sspa.juntadeandalucia.es/unifica/web/gobernanza/integracion-con-maco.
7. Desarrollo por parte del cliente, siempre teniendo claro que se puede contar con la OTI para cualquier duda que surja.
8. Pruebas en local por parte del cliente.
9. Paso por parte del cliente al entorno de despliegue (en caso de que se tengan tres entornos: despliegue, preproducción y producción).
10. Gestionar el alta del módulo correspondiente en MACO de Preproducción.
    • Plantilla de Solicitud de Alta Módulo en Maco
11. Entrega por parte del cliente del informe de pruebas de integración en este entorno. El informe de pruebas de integración se hace llegar una vez se vayan a realizar.
    • Informe de Pruebas de Integración
12. Aprobación por parte de la STIC del informe de pruebas de integración.
13. Con el OK al paso anterior, subida por parte del cliente al entorno de Preproducción.
14. Entrega por parte del cliente del informe de pruebas funcionales en este entorno. Igual que el anterior, se pasa llegado el punto.
    • Informe de Pruebas Funcionales
15. Aprobación por parte de la STIC del informe de pruebas funcionales.
16. Gestionar el alta del módulo correspondiente en MACO de Producción.
    • Plantilla de Solicitud de Alta Módulo en Maco
17. Con el OK al paso anterior, subida por parte del cliente al entorno de Producción.
18. Coordinar conjuntamente, la fecha de arranque de éste nuevo módulo en el entorno de Producción.

Nota: La OTI valorará y estudiará casos excepcionales en los cuales este procedimiento no se adecúe completamente a la petición. 

2.Uso de la herramienta Confluence en Integraciones de Sistemas Corporativos

La petición de integración puede solicitarse por parte del responsable del hospital o por un responsable de la STIC, y ésta solicitud puede venir por correo o a través de CGES. Una vez que recepcionamos y planificamos por parte de la OTI dicha petición, el procedimiento que seguimos para tratarla puede dividirse en cuatro partes o fases: requisitos de integración, diseño de integración, pruebas de integración y pruebas funcionales.

A continuación se muestra un esquema de las cuatro fases anteriormente mencionadas de una petición de integración y un diagrama a modo de resumen del uso y la relación entre estas fases, lo cual se explica más adelante en profundidad.

     2.1.Requisitos de integración

Es una etapa de análisis de la integración, en la cual el proveedor tiene permisos de edición sobre la primera subpágina para que pueda transmitir a la OTI todos los detalles sobre las necesidades funcionales y técnicas de la integración. Para ello el proveedor debe contestar a las preguntas de contexto funcional y detallar cada requisito que consideren necesario cumplir con sus casos de uso correspondientes. Se hará uso de la caja de comentarios para que la persona encargada de la OTI pida la aprobación de acceso a datos por parte del proveedor.

Si se producen dudas, la OTI también utilizará el apartado de comentarios para transmitirlas, pudiendo ser resueltas por vías ágiles, pero siempre quedando reflejadas las respuestas en la página por parte del proveedor. Una vez que se finaliza la etapa de análisis, quedando resueltas todas las dudas sobre las necesidades, el proveedor dejará de tener permisos de edición en la página.

      2.2.Diseño de Integración

Esta subpágina es utilizada por la OTI para documentar la integración que se llevará a cabo para cubrir las necesidades expuestas en la subpágina anterior. El proveedor solo tiene permisos de visualización en esta página y si se generan dudas pueden plantearlas en el apartado de comentarios y ser resueltas por canales ágiles, actualizándose si fuese necesario el contrato de integración. En esta página se incluye 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.

      2.3.Pruebas de Integración

En esta subpágina la OTI expondrá las pruebas de integración realizadas sobre los servicios que se consumen y exponen en la integración en caso de que no se hayan certificado anteriormente. En esta página el proveedor vuelve a tener únicamente permisos de visualización para revisar los resultados de las rondas de pruebas. El apartado de comentario puede ser utilizado para resolver dudas e indicar por parte del proveedor la disponibilidad de los correctivos para planificar rondas de pruebas.

      2.4.Pruebas Funcionales

En esta subpágina vuelve a tener permisos de edición el proveedor, ya que debe identificar todos los casos de uso de pruebas funcionales que se crean oportunos e indicar 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.