OpenHIE Architecture Specification
5.0-es
5.0-es
  • Resumen de la especificación
  • Cómo utilizar la especificación
  • Especificación de la arquitectura
    • Arquitectura
    • Principios arquitectónicos
    • Estándares y Perfiles
  • Especificaciones de componentes de OpenHIE
    • Requisitos no funcionales
    • Registro de Clientes (CR)
    • Registro de instalaciones (FR) de OpenHIE
    • Servicio de Finanzas y Seguros (FIS) de OpenHIE
    • Sistema de Información de Gestión de Salud (HMIS) de OpenHIE
    • Registro de Trabajadores de la Salud (HWR) de OpenHIE
    • Capa de Interoperabilidad (IOL) de OpenHIE
    • Sistema de Información para la Gestión Logística (LMIS) de OpenHIE
    • Catálogo de productos (PC) de OpenHIE
    • Historia Clínica Compartida (SHR) de OpenHIE
    • Servicio de Terminología (TS) de OpenHIE
    • Sistemas de punto de atención
  • Especificaciones del flujo de trabajo (intercambio)
    • Flujos de trabajo de informes agregados
      • Exportar datos agregados
      • Validar y guardar datos agregados
    • Alertar/enviar recordatorios o información
      • Flujo de trabajo de envío de alertas a los clientes
      • Enviar flujo de trabajo de alerta al trabajador de la salud
    • Descubrir servicios de atención
      • Flujo de trabajo de consulta de registros de trabajadores de la salud o de instalaciones
      • Consulta de flujo de trabajo de registros de servicios de atención
      • Flujo de trabajo de la búsqueda de servicios de atención
      • Flujo de trabajo para la solicitud de actualizaciones de servicios de atención
    • Flujos de trabajo del laboratorio
      • Solicitar prueba de laboratorio
      • Resultados del laboratorio informados
    • Flujos de trabajo de gestión de la identidad del paciente
      • Descripción general del flujo de trabajo de creación de registros demográficos de pacientes
      • Actualizar el flujo de trabajo del registro demográfico del paciente
      • Flujo de trabajo de la consulta de registros demográficos de pacientes por datos demográficos
      • Query Patient Demographic Records by Demographics Workflow
    • Historia Clínica Compartida
      • Guardar flujo de trabajo de datos clínicos a nivel de paciente
      • Consultar el flujo de trabajo de datos clínicos del paciente
    • Flujos de trabajo del servicio de terminología
      • Expandir el conjunto de valores
      • Traducir el código
      • Verificación de código existente
      • Verificación de la membresía del código
      • Consulta del conjunto de valores
      • Consulta de los sistemas de códigos
      • Consulta de mapas conceptuales
      • Código de búsqueda
    • Flujos de trabajo de las vacunas
    • Flujos de trabajo de los servicios de seguros y finanzas de OpenHIE
      • HFW-001: Inscribir beneficiarios
      • HFW-002: Consulta del beneficiario
      • HFW-003: Revisar la elegibilidad para la cobertura
      • HFW-004: Reclamaciones
      • HFW-005: Seguimiento a la reclamación
  • Cómo hacer comentarios y contribuciones
  • Registro de cambios y control de versiones
Powered by GitBook
On this page
  • Requisitos del flujo de trabajo de la IOL de OpenHIE
  • Requisitos funcionales de la IOL de OpenHIE
  1. Especificaciones de componentes de OpenHIE

Capa de Interoperabilidad (IOL) de OpenHIE

Aunque las funciones de otros componentes de OHIE que proporcionan servicios pueden entenderse más fácilmente, es la Capa de Interoperabilidad (Interoperability Layer, IOL) la que asegura y orquesta el intercambio de información. Al igual que un director de orquesta, la IOL proporciona la fuerza central que permite que todos los componentes del HIE trabajen juntos e interactúen con los sistemas de punto de servicio fuera del HIE.

Consulte también “Requisitos no funcionales”.

Requisitos del flujo de trabajo de la IOL de OpenHIE

Para ser un componente de la IOL de OHIE, la aplicación IOL debe ser capaz de soportar el siguiente estándar requerido:

N.º

Estándares de IHE

Recomendación o requisito

IOLWF-1

· Rastreo de Auditoría (Audit Trail, AT): describe cómo los mensajes de auditoría pueden ser enviados y almacenados en un repositorio central que en este caso sería la IOL.

· Autenticación de Nodos (Node Authentication, NA): describe cómo la IOL puede autenticar a los clientes (sistemas externos) que quieren enviar solicitudes al intercambio.

Requisito

Además, la capa de interoperabilidad está diseñada para ser el único punto de entrada a un HIE. Esto significa que la IOL debe participar en todos los flujos de trabajo de OpenHIE. Gestiona de forma transparente el enrutamiento de las transacciones, la seguridad y la auditoría, ya que son funciones comunes necesarias en todos los flujos de trabajo.

Requisitos funcionales de la IOL de OpenHIE

N.º

Requisitos funcionales de la IOL

Recomendación o requisito

IOLF-1

El sistema debe proporcionar un punto de acceso central para los servicios del HIE. Por ejemplo, esta interfaz proporcionará acceso a las bases de datos de CR, catálogo de productos (Product Catalogue, PC), FR y SHR. Este punto central de acceso simplifica la gestión de la seguridad y proporciona un único punto de entrada al HIE.

Recomendación

IOLF-2

El sistema proporcionará funciones de enrutamiento que permitan dirigir los mensajes a los sistemas correctos de los proveedores de servicios dentro del HIE.

Requisito

IOLF-3

El sistema deberá proporcionar un mecanismo central de registro de los mensajes enviados a través del intercambio. Esta función deberá registrar copias de los mensajes que viajan a través de la capa de interoperabilidad con fines de auditoría e información.

Requisito

IOLF-4

El sistema deberá permitir la repetición de transacciones fallidas a nivel central, aliviando la necesidad de que los sistemas de punto de servicio vuelvan a enviar datos, por ejemplo, en caso de problema con un componente de la infraestructura.

Recomendación

IOLF-5

Debe apoyar la transformación de los mensajes que viajan desde la capa de interoperabilidad a los sistemas del proveedor de servicios y viceversa si el proveedor de servicios no puede comunicarse en el formato requerido, es decir, proporciona adaptadores específicos de la implementación para transformar los mensajes

Recomendación

del formulario interno de la capa de interoperabilidad a un formulario que el proveedor de servicios espera (p. ej.,

SHR, CR o PC).

IOLF-6

El sistema debe permitir el enrutamiento de los mensajes al componente de arquitectura apropiado o al sistema de punto de servicio externo.

· Realizar tareas de orquestación de transacciones complejas para aliviar la carga de los sistemas de los clientes. Esta orquestación puede ponerse en contacto con varios proveedores de servicios dentro del HIE en nombre de un cliente y compilar una respuesta adecuada para devolverla al cliente.

· Ejemplos de orquestación podrían ser la ejecución de un plan de atención o la validación de elementos (como identificadores o códigos) en un mensaje contra otros proveedores de servicios dentro del HIE (p. ej., PC, CR, FR, Servicios de Terminología [Terminology Services, TS]).

· Las tareas de orquestación son las que se requieren para completar la transacción actual y, por lo tanto, deben ejecutarse a tiempo, ya que la transacción no puede continuar sin estos pasos.

Recomendación

Los sistemas deberán incluir una interfaz a la que se pueda conectar un motor de flujo de trabajo.

· Este motor de flujo de trabajo deberá ser capaz de hacer un seguimiento del estado de la atención de un paciente a largo plazo y podrá realizar acciones basadas en este contexto (como

IOLF-7

el envío de alertas) para mejorar la atención al paciente.

· Este motor de flujo de trabajo está fuera del alcance de la capa de interoperabilidad. Sin embargo, se espera que la capa de interoperabilidad exponga una interfaz que permita implementar este tipo de sistemas.

Requisito

IOLF-8

El sistema deberá soportar la capacidad de ser ampliado permitiendo añadir o eliminar funciones de mediación adicionales a medida que sean necesarias.

Recomendación

IOLF-9

El sistema deberá soportar un mecanismo de gestión y seguimiento de errores, p. ej., una consola para ver las transacciones fallidas.

Requisito

IOLF-10

El sistema deberá permitir que las transacciones fallidas se agrupen por tipo de error y razón, de modo que los errores puedan rectificarse eficazmente encontrando la causa raíz del error, solucionando el problema y volviendo a ejecutar esas transacciones.

Requisito

IOLF-11

El sistema deberá soportar la capacidad de que un usuario vuelva a ejecutar las transacciones con errores a través del HIE una vez que se haya rectificado el motivo de su fallo.

Recomendación

IOLF-12

El sistema proporcionará a los usuarios autorizados una visión de las métricas para supervisar el flujo de mensajes a través del HIE.

Requisito

IOLF-13

El sistema gestionará la seguridad del HIE mediante autenticación (verificación de la identidad), autorización (permiso para interactuar con componentes específicos del HIE) y cifrado y descifrado de mensajes.

Requisito

IOLF-14

El sistema deberá soportar autenticación y autorización de sistemas que intenten enviar datos al HIE.

Requisito

IOLF-15

El sistema deberá soportar cifrado de datos en vuelo (cuando no se encuentre en una red físicamente segura) y en reposo (siempre que se almacenen datos, p. ej., cuando se almacenen transacciones para su registro).

Recomendación

IOLF-16

El sistema debe capturar estadísticas de seguimiento, como cargas de transacciones y métricas de rendimiento, y proporciona una vista de estas para supervisar el flujo de mensajes a través del HIE.

Recomendación

PreviousRegistro de Trabajadores de la Salud (HWR) de OpenHIENextSistema de Información para la Gestión Logística (LMIS) de OpenHIE

Last updated 2 years ago

: se divide en dos partes lógicas

El Rastreo de Auditoría y Autenticación de Nodos (Audit Trail and Node Authentication, ATNA) de Integrating the Healthcare Enterprise (IHE)