Oficina de Calidad Subdirección de Tecnologías de la Información y Comunicaciones

Descripción de Interfaces con Otros Sistemas

Proyecto

Proceso de Gestión de Proyectos

CONTROL DE CAMBIOS DEL DOCUMENTO

Registro de cambios

Autor	Versión	Referencia de cambios	Fecha

Revisores

Nombre	Versión Aprobada	Posición	Fecha

Propiedades del documento

Propiedad	Detalle
Título	Descripción de Interfaces con Otros Sistemas
Proyecto	Proyecto
Autor
Nombre fichero	Documento1
Fecha de creación	05/11/2018 10:30
Ultima actualización	01/01/1601 1:00
Plantilla base	[PPP-INT_xxxxxx_v3.1].dot

INDICE

1	Objeto del documento	3

2	Alcance del documento	3

3	Participantes	3

4	Requerimientos de integración a nivel general	3

5	Necesidad funcional de las integraciones	3

6	Situación general de las integraciones	3

7	Análisis detallado de las integraciones	3

8	Anexo - Formularios de Integración	3

8.1	Cuestionario USUARIO TÉCNICO	3

8.2	Cuestionario USUARIO FUNCIONALES	3

9	Referencias	3

LISTA DE FIGURAS

No se encuentran elementos de tabla de ilustraciones.

Figura 1: Esquema de integración	9

LISTA DE TABLAS

Tabla 1: Análisis patengora integraciones	14

Tabla 2: Referencias	22

Instrucciones Generales

El texto de color azul provee una guía para el autor y debería ser eliminado antes de la publicación del documento.

Objeto del documento

El presente documento recoge la descripción técnica de la integración de este proyecto con otros sistemas; se especifican la definición de los distintos servicios que serán utilizados por las aplicaciones y módulos correspondientes.

Dentro de los distintos subsistemas indicados en el Análisis del Sistema, se describen aquellas funcionalidades que se han de contemplar dentro de la comunicación de datos con otros sistemas.

El objetivo que se persigue con el mismo es definir los modelos de comunicación establecidos entre dichos sistemas. Para ello se va describir la arquitectura que se va aplicar, el medio de transporte y se van ha definir las diferentes entidades y funciones que va a contener dicha comunicación.

A continuación se indican los mecanismos para acceder a estos servicios así como el formato para esta comunicación.

Alcance del documento

Define el alcance del documento

Participantes

Enumere los participantes del documento

Participantes
Departamento
Teléfono
Rol

Requerimientos de integración a nivel general

Descripción de las integraciones entre sistemas a alto nivel (sistemas, tipo de interconexión, tipo de comunicación, etc.).

Ejemplo:

La solución aplicada pasa por crear un “Servicio Web” que comunica a los componentes de gestión publicados en los servidores con el resto de sistemas. Se determinan las siguientes características:

Acceso al Servicio Web bajo el protocolo SOAP.

Los componentes que se publiquen contendrán un método público llamado “Solicitud” con un parámetro de entrada de tipo cadena y un retorno de tipo cadena.

La entrada única será un XML validado por un esquema XSD.

Cada entrada contendrá una petición identificada por una clave única que corresponderá a una función del sistema. Esta entrada se llama solicitud.

Cada solicitud conlleva un mensaje de respuesta identificado por la misma clave. Dicho mensaje de respuesta contendrá opcionalmente un elemento de error indicando una codificación predeterminada y un texto libre.

La respuesta a una solicitud tiene que ser inmediata y el operador esperará la misma para actuar en consecuencia ante la respuesta.

En resumen, una función del sistema está identificada por una clave y realiza una funcionalidad específica contra la base de datos de Receta a partir de un mensaje XML que contiene esta clave además de los datos propios de la solicitud devolviendo otro XML de respuesta.

Figura 1: Esquema de integración

Necesidad funcional de las integraciones

Listado de las integraciones de la solución con otras aplicaciones a nivel funcional. Describir las necesidades funcionales con las integraciones descritas.

Situación general de las integraciones

Situación actual de las integraciones de los sistemas (si procede). En el caso de que ya exista una integración del aplicativo con otros sistemas y se deba modificar, añadiendo o quitando relaciones, se especificará el sistema existente.

Análisis detallado de las integraciones

Introduzca contenido y borre cuadro adjunto. Para completar las siguientes tablas, se adjuntan cuestionarios anexos.

Elemento	Descripción	Ejemplo
Interfaz de servicio de cada aplicación	Cada aplicación que intervenga en la solución deberá exponer una interfaz pública con la que se podrá interactuar de forma externa y de manera no intrusiva, respetando la lógica de la aplicación. Además esta interfaz de servicio deberá ser pactada al inicio entre las distintas partes a integrar.	”Cada sistema dispone de un interfaz constituido por servicios web disponible para los sistemas con los que se relaciona. Los consumidores de estos servicios podrán hacerlo de forma síncrona o asíncrona”
Tipos de mensajes	Aunque este punto está relacionado con el anterior, trata de la definición en detalle de cada mensaje; es decir para cada mensaje que interviene se ha de definir su tipo y especificación.	Para mensajes representados por HL7 se debe identificar el tipo de mensaje que interviene (ORR, MFR, etc) y la versión del estandar (2.3.1, 3.0), para mensajes XML la especificación vendrá representada por esquemas XSD, y para los ficheros planos vendría representado por un documento que defina su estructura y tipos de datos. (*) Los casos de mensajes XML y ficheros planos serían excepcionales, puesto la recomendación es HL7. ”La mensajería entre los diferentes sistemas estará formada por ficheros XML según definición del SNS. En el Anexo 1 se incluyen los documentos DTD correspondientes a los mensajes utilizados”
Transformaciones	Colaboración en la definición de los mapas de transformación entre mensajes, es decir, la correspondencia entre los diferentes campos y funciones a aplicar. Dichos mapas serán implementados por plataforma de integración.	”Las transformaciones de datos entre los sistemas se realizarán según el documento incluido en el Anexo 2.”
Transporte	Identificación del protocolo de transporte a usar con la aplicación destino.	SOAP, para servicios web HTTP, para acceso web FILE, acceso a ficheros sobre plataforma windows FTP,MLLP, MQ Series, MSMQ, EDI, SAP, SQL, propietario de la aplicación, etcétera.: “El transporte de los mensajes entre sistemas se llevará a cabo mediante protocolo SOAP y http / https sobre TCP/IP”
Auditoría	Necesidades adicionales de auditoría de mensajes aparte de las establecidas por plataforma de integración, las cuales registrarán los mensajes intercambiados, el proveedor del mensaje, tiempo de ocurrencia y el mensaje.	“No existen necesidades adicionales de auditoría de mensajes aparte de las establecidas por plataforma de integración”
Enrutamiento	Definición de cómo se realizará el enrutado de mensajes, es decir, estático o dinámico basado en el contenido del mensaje. Una vez definido, la arquitectura de integración dispone de los mecanismos necesarios para su configuración.	“Todos los mensajes tendrán como destino el SNS. Si es posible que el servicio web que se invoque cambie en función del tipo de mensaje.”
Seguridad	Necesidad de aplicar mecanismos de seguridad: a nivel de transporte (SSL), de mensajes (encriptación, firma digital), de autorización y autenticación a nivel de sesión (MACO, LDAP, SSO).	“A la mensajería entre sistemas se aplicará el protocolo de encriptación SSL y será necesaria la autenticación de los operadores mediante certificado digital. La integridad, autenticidad y no repudio en caso necesario se realizaría mediante firma digital de los mensajes intercambiados”
Tratamiento de errores funcionales	Definición de los procesos a seguir para los errores funcionales. Los errores técnicos podrán seguir los mecanismos establecidos por la arquitectura de integración: registro en el sistema de eventos de Windows, monitorización mediante herramientas como Microsoft Operations Management.	Notificación mediante NACK funcionales, etcétera. “Las aplicaciones implementarán las operaciones correctivas y/o informativas pertinentes para el tratamiento de este tipo de errores. Se empleará la notificación mediante NACK”
Patrones de comunicación y procesos de negocio	Este punto permitirá definir el proceso de integración, es decir, si la comunicación es síncrona o asíncrona, si el servicio de integración debe coordinar ("orquestar") varios servicios de diferentes aplicaciones, si se debe considerar la garantía de entrega, etcétera. Una vez identificado el patrón de comunicación, el siguiente paso (en caso de que sea necesario) será definir el proceso de negocio en sí. En cualquier caso la definición de este patrón depende de cada proceso funcional y es necesario el conocimiento previo de los requerimientos funcionales.	"sync-agregator", "async-agregator", "parallel convoy", "interruptible-process" “La comunicación entre sistemas podrá realizarse de manera síncrona o asíncrona. No será necesario coordinar servicios de otras aplicaciones y se considerará la garantía de entrega”
Factores de rendimiento	Tamaño medio y máximo de los mensajes, número de peticiones por segundo, tiempo de respuesta máximos de cada integración.	“Número de peticiones por segundo: Se estima una media 0,4 con picos de actividad de 0,9. Tamaño máximo de los mensajes: 60Kb. Tamaño medio de los mensajes: 1000 bytes.”

Tabla 1: Análisis para integraciones

Anexo - Formularios de Integración

Cuestionario USUARIO TÉCNICO

Este cuestionario debe ser facilitado al personal de las empresas implicadas que prestan servicio en el hospital, por lo que se ha desarrollado con un lenguaje más técnico.

INFORMACIÓN DEMOGRÁFICA
Empresa
Ámbito
Información de contacto	Teléfono: email:

DATOS GENERALES DE LA APLICACIÓN
Nombre y versión de la aplicación
Nivel de complejidad	( ) Muy alta ( ) Alta ( ) Media ( ) Baja ( ) Muy baja
Descripción y propósito
Propietario de la aplicación (responsable de especificar requerimientos)
Información de contacto	Teléfono: email:
Marcar todos los entornos en los que existe actualmente la aplicación	( ) Desarrollo ( ) Pruebas de usuario ( ) Producción ( ) Otros:
¿Es una aplicación de terceros? ¿Quién es el proveedor?	( ) Sí ( ) No

USO DE LA APLICACIÓN
¿Qué tipo de usuario utiliza la aplicación?
¿Con qué frecuencia se revisa o actualiza la aplicación?

DATOS TÉCNICOS DE LA APLICACIÓN
Interfaz de servicios
¿De qué otras aplicaciones depende ésta?
¿Qué otras aplicaciones dependen de esta?
¿Utiliza librerías, interfaces o cualquier otro módulo de terceros?
Tipos de mensajes
¿Qué estándar o formato de intercambio de mensajes usa?
¿Qué versión de HL7 usa?
Transformaciones
¿La representación de la información en las dos aplicaciones es la misma?
Transporte
Para cada aplicación con la se realiza una integración especificar lo siguiente: ¿Qué protocolo de comunicación se utiliza?	() SOAP () HTTP () Intercambio de ficheros () Acceso a la base de datos () FTP () Otros. Especificar
Auditoría
¿Se requiere auditar los mensajes intercambiados?
¿Es necesario conocer los tiempos de ejecución del servicio, número de mensajes procesados?
Enrutamiento
La localización de la aplicación destino, ¿es siempre fija (enrutamiento estático), o puede cambiar (enrutamiento dinámico) en función del contenido de la información a intercambiar?
Seguridad
¿Qué protocolo de encriptación a nivel de transporte usa la aplicación?
¿Qué protocolo de seguridad a nivel de mensaje usa la aplicación?
¿Qué protocolo de seguridad a nivel de autorización usa la aplicación?
¿Qué protocolo de seguridad a nivel de autenticación usa la aplicación?
¿Existen otras políticas de seguridad asociada a la aplicación?
Tratamiento de errores funcionales
Especificar el tratamiento para los errores funcionales Ejemplo: Notificación explicita de error vía NACK funcionales, procedimientos de compensación, etcétera.
Tratamiento de errores técnicos
Los errores técnicos se registrarán en el log de eventos, para que así puedan ser monitorizados por herramientas de monitorización (por ejemplo: Microsoft Opertations Manager, etcétera). ¿Se requiere algún procedimiento adicional para este tipo de errores?
Patrones de comunicación y procesos de negocio
¿La comunicación es síncrona o asíncrona?
¿Requiere la integración de un proceso de negocio asociado? (Ej: No se enviará el mensaje al destino hasta que no se acumulen todas las peticiones del día; antes de responder a la aplicación destino ha de consumir de otro sistema un servicio, reglas de negocio a considerar, etcétera)
Factores de rendimiento
¿Cuál el tamaño máximo de los mensajes?
¿Cuántas peticiones por segundo es capaz de gestionar?
¿Cuál es el tiempo máximo de respuesta?

Cuestionario USUARIO FUNCIONALES

Este cuestionario debe ser facilitado al personal no técnico usuario del sistema a integrar.

INFORMACIÓN DEMOGRÁFICA
Localización
Ámbito
Información de contacto	Teléfono: email:

DATOS GENERALES DE LA APLICACIÓN
Nombre y versión de la aplicación
Nivel de complejidad	( ) Muy alta ( ) Alta ( ) Media ( ) Baja ( ) Muy baja
Descripción y propósito
Propietario de la aplicación (responsable de especificar requerimientos)

CUESTIONES GENERALES
Enumere las reglas de negocio
¿Cuál es el tiempo máximo de respuesta de la aplicación?
¿La aplicación puede funcionar de forma desconectada (“offline”)?
¿Permite funcionar por lotes?
¿Cuál es el flujo de la información?

Referencias

Lista y ubicación de los documentos referenciados en el documento de alcance.

Se desglosa a continuación el material de soporte, utilizado para la elaboración del presente documento:

Código	Título

Tabla 2: Referencias