Interoperabilidad Cláusulas de Ejemplo

Interoperabilidad. 6.1 El Cliente recibirá la funcionalidad de interoperabilidad de conformidad con la Cláusula 2 anterior (ver paquete CONNECT más arriba). Symantec no efectúa garantía alguna sobre la capacidad de EIM para interoperar con cualquier proveedor de Mensajería Instantánea, entre lo que se incluye AOL, MSN y Yahoo!.

Interoperabilidad. La ASI aspira a maximizar la interoperabilidad entre los sistemas del GCABA buscando que cada sistema se atenga a la resolución de los problemas propios del dominio en que actúa. Al mismo tiempo, es habitual que las áreas de gobierno interactúen y, por lo tanto, haya interdependencia de datos. Se espera que en estos casos las estrategias de intercambio de datos estén dirigidas a intercambio vía servicios-web. En caso de sistemas legacy, se debe analizar la posibilidad de creación de interfaces de interacción web, considerándose éstas como un módulo más de la aplicación/solución entregada por el proveedor o, como una dependencia del proyecto, en caso que el proveedor de datos tenga la capacidad de desarrollar la interfaz al sistema.

Interoperabilidad. En la medida de lo exigido por la legislación aplicable, Cisco Le proporcionará la información de la interfaz necesaria para conseguir la interoperabilidad entre el Software y otro programa de creación independiente. Sujeto a Su solicitud por escrito, y una vez haya pagado las cuotas de licencia de Cisco (si existieran), Cisco Le proporcionará esta información de interfaz. Esta información se mantendrá en estricta confidencialidad y se cumplirán siempre todos los términos y condiciones aplicables sobre cuya base Cisco proporciona dicha información.

Interoperabilidad. La Comisión de Regulación de Energía y Gas (CREG), establecerá las condiciones que permitan la interoperabilidad de los distintos componentes de la infraestructura de medición avanzada, incluso entre diferentes operadores de red. ART. 11.

Interoperabilidad. Los requisitos de integración de diversos sistemas de información de Osakidetza se realizaran de acuerdo a una arquitectura orientada a servicios (SOA) sobre la plataforma Oracle SOA Suite (Oracle BPEL Process Manager, Oracle Service Bus (OSB), Oracle Business Rules, ...). Dicha arquitectura proporciona una forma bien definida de exposición e invocación de Servicios Web, lo cual facilita la interacción entre diferentes sistemas propios o de terceros. Sobre la misma arquitectura SOA, Osakidetza implementa una solución de integración orientada a Eventos; es un diseño a medida que gestiona un conjunto de sistemas que publican eventos y un conjunto de aplicaciones que se suscriben a determinados eventos. Dicha solución se denomina Gestor de Eventos-Event Manager y es responsable de recibir los eventos publicados, ejecutar las validaciones adecuadas, enrutar y almacenar los eventos para su envío a los subscriptores que estén asociados a cada uno de los elementos recibidos. Relación de estándares de comunicación soportados: • Protocolos a nivel de mensaje: o SOAP 1.1 y SOAP 1.2 o WSDL 1.1 y WSDL 1.2 Binding o SOAP con Attachments o JSON – REST (para aplicaciones móviles) • Protocolos de seguridad a nivel de mensaje: o WS-Security 1.0/1.1 o WS-SecurityPolicy o WS-Policy o WSPolicyAttachment o WS-Security: Username Token Profile 1.0/1.1 o WS-Security: X.509 Token Profile 1.0/1.1 o WSSecurity: ▇▇▇▇ ▇▇▇▇▇ Profile 1.0/1.1 o WS-Security: KerberosToken Profile 1.1 o WS-Reliable Messaging 1.0 o WS-Addressing o WS-I Basic Profile 1.1 o WSSecurity: JWT Token (aplicaciones móviles en internet) • Protocolos a nivel de transporte: o HTTP 1.0, HTTP 1.1 o TLS, SSL o Interoperabilidad con registros UDDI v3-compliant o Sistemas middleware basados en JMS/MQ o HTTPS

Interoperabilidad. La dispensación de recetas electrónicas prescritas a través del Sistema de Receta Electrónica de un Servicio Público de Salud de una CA distinta, se regirá por las condiciones establecidas en la CA donde se realice la dispensación. Serán dispensados a través del Sistema de Interoperabilidad de la Receta Electrónica, los medicamentos, y los efectos y accesorios, incluidos en la prestación farmacéutica del SNS. También podrán ser dispensables a través de dicho sistema otros productos farmacéuticos financiados, así como los productos dietéticos incluidos en la prestación. En todo caso, el Sistema de Receta Electrónica informará al farmacéutico de la cantidad de aportación del usuario que deberá abonar para proceder a la correspondiente dispensación. No obstante, las Oficinas de Farmacia podrán dispensar a través del mencionado sistema cualquier medicamento no financiado prescrito en otra CA, así como un medicamento prescrito para una indicación no financiada. El farmacéutico será informado por el sistema de estas situaciones para poder aplicarlo y en estos casos el paciente abonará el 100 % del precio del medicamento, no siendo facturable a MUFACE la dispensación realizada. cve: BOE-A-2023-483 Verificable en ▇▇▇▇▇://▇▇▇.▇▇▇.▇▇ Las prescripciones electrónicas dispensadas al colectivo de MUFACE a través del Sistema de Interoperabilidad de la Receta Electrónica, serán facturadas por los correspondientes Colegios Oficiales de Farmacéuticos de la CA donde se encuentre la farmacia que ha realizado la dispensación, de acuerdo con las condiciones establecidas para las prescripciones electrónicas prescritas en el ámbito de MUFACE.

Interoperabilidad. 1. El sistema debe permitir el uso y despliegue de WebServices seguros para la integración con aplicaciones internas y externas con estándar WS-I, debe generar clientes de WebServices de forma automática a partir de la especificación WSDL del WebService, sin necesidad de programación. 2. Para todos los casos en los que se implementen servicios de interoperabilidad, se debe contar con un plan alternativo para el ingreso de información manual, el cual debe suministrar toda la trazabilidad del(os) proceso(s). 3. Los componentes de interoperabilidad (Web Services) deben ser instalados e implementados en el bus empresarial Microsoft BizTalk, propiedad de la Supersalud. 4. El sistema se debe integrar con el correo electrónico para realizar automáticamente el envío de documentos y/o notificaciones y recepción de documentos a direcciones electrónicas, utilizando protocolos estándares. 5. El sistema debe permitir la consulta e interoperar en general con los sistemas de información que la entidad tiene contemplados en la actualidad:  Aplicaciones Internas de Gestión de los procesos de la entidad: o Proceso de Cobro Coactivo o Citaciones y Notificaciones o Procesos Administrativos o Procesos Disciplinarios o Delegada de Jurisdiccional y Conciliación o Sistema de Gestión de liquidación de TASA o Portal Web Institucional o Extranet de Quejas y Reclamos.  Aplicaciones con servicios externos: o Empresa de mensajería o ClicSalud o Sistema Certimail. Los anteriores por medio de WebServices, así mismo el contratista debe considerar el ingreso de nuevos procesos a interoperar en el momento que la entidad así lo requiera. 6. El sistema debe permitir publicar WebServices en el ESB de la entidad (Ms BizTalk) para el consumo desde otras aplicaciones. 7. El sistema debe permitir la Integración con Microsoft Office. 8. Debe integrar con el correo electrónico Microsoft Office 365 para realizar automáticamente el envío de documentos y/o notificaciones y recepción de documentos a direcciones electrónicas y/o a dispositivos móviles, utilizando protocolos estándares. 9. La solución debe permitir la Integración a través de web services con el módulo de correspondencia, los repositorios de documentos para la administración de los documentos, soportes de las transacciones de cobro persuasivo y coactivo. 10. La solución debe disponer de mecanismos para adjuntar imágenes o archivos digitalizados a las transacciones de la aplicación. 11. La solución debe permitir la integración a través de...

Interoperabilidad. Seguridad de información: · Nivel de madurez

Interoperabilidad. El PROVEEDOR deberá alinear los diseños de la solución del Repositorio Único de Datos al marco de interoperabilidad y la plataforma de interoperabilidad de la DIAN. La solución del DataR tiene interacción con diversos servicios y contratos que forman parte de la estrategia de modernización tecnológica de la DIAN, a continuación, se describen los principales requerimientos de interoperabilidad. En concordancia con los servicios de la plataforma de interoperabilidad de la DIAN, los mecanismos que se pueden usar son: a) API Gateway b) Eventos c) Data Streaming 3.1.1.5.6.1. Nuevo Sistema de Gestión de Aduanas. El plan de modernización de la DIAN contempla el desarrollo de nuevos sistemas para la operación de la entidad, siendo uno de ellos el Nuevo Sistema de Gestión de Aduanas (NSGA). El PROVEEDOR del DataR deberá tener en cuenta los siguientes requerimientos para dicho sistema: • El NSGA deberá tener acceso a la información histórica de los sistemas actuales que se requiera para procesar las operaciones de comercio exterior, por lo que los proveedores deberán comunicarse y coordinarse, en conjunto con la DIAN, para tener satisfecho este requerimiento, tanto para el diseño, las pruebas como para la implementación en producción. Lo anterior de acuerdo con la estrategia definida en el numeral 3.2. y de acuerdo con la metodología de integración del numeral 3.5.3. • Para el proceso de desarrollo del NSGA se deberán tener disponibles las definiciones que se requieran, respecto del acceso a datos, configuraciones y demás políticas que el DataR proporciona de manera transversal a los consumidores. • Se deberán proveer las definiciones de las interfaces (API) que serán empleadas en la construcción del NSGA para el acceso a los datos. Lo anterior, de acuerdo con los requerimientos específicos que el proveedor del NSGA solicitará al DataR. • Se deberán proveer los mecanismos para recepción de datos en el repositorio que serán empleados en la construcción del NSGA. • El PROVEEDOR del DataR deberá contemplar en las definiciones de la propuesta de la solución, el uso de la versión 3.7 del modelo de datos de la Organización Mundial de Aduanas (OMA). • El PROVEEDOR de la solución del DataR es el responsable de realizar la migración de datos históricos desde las fuentes originales hacia el repositorio único, para lo cual se deberán realizar actividades de mapeo, clasificación e identificación de estructuras de datos a ser migrados. Dichas actividades serán realizadas por el ...