T1.2: Chooses Production Architecture

Resumen General

Los Business Services sirven como punto de entrada a tu production HL7, actuando como puente entre sistemas de salud externos y tu entorno de integración de InterSystems. Comprender las capacidades y restricciones de los Business Services es fundamental para el diseño de production.

Responsabilidad Principal

La responsabilidad principal de un Business Service es recibir datos entrantes de sistemas externos:

• Cuando una aplicación externa (EMR, sistema de laboratorio, sistema de radiología) necesita enviar mensajes HL7 a IRIS for Health, se conecta a un Business Service
• El Business Service utiliza un InboundAdapter para manejar el protocolo de comunicación:
• TCP: Para mensajería en tiempo real
• FTP: Para transferencias basadas en archivos
• File adapter: Para monitoreo del sistema de archivos local
• HTTP: Para llamadas a servicios web
• SOAP: Para servicios web basados en SOAP

Capacidad de Manejo de ACK

Una capacidad crítica de los Business Services HL7:

• Cuando un sistema externo envía un mensaje HL7, espera una confirmación de recepción
• El Business Service puede generar y devolver ACKs automáticamente a la aplicación llamante
• Esta confirmación inmediata satisface la necesidad del sistema emisor de confirmación
• El mensaje puede procesarse asincrónicamente dentro de la production

Restricción de Fuente Única

Los Business Services operan bajo una restricción de fuente única:

• Cada Business Service procesa datos de una fuente
• TCP: Escucha en un puerto específico
• Files: Monitorea un directorio específico
• FTP: Lee de una ubicación FTP
• Esto simplifica la configuración y solución de problemas con propiedad clara
• Para múltiples fuentes, crea múltiples Business Services

Limitación de Versión de Schema

Una limitación arquitectónica significativa:

• Cada Business Service solo puede ser asignado a una versión de schema HL7 (Message Schema Category)
• Esto permite al Business Service analizar mensajes entrantes según las definiciones estructurales correctas
• Un solo Business Service no puede manejar una mezcla de versiones HL7
• Si el laboratorio envía HL7 2.5 y radiología envía HL7 2.3, debes crear Business Services separados

Múltiples Tipos de Mensajes

Dentro de una sola versión HL7, un Business Service puede recibir múltiples tipos de mensajes de la misma aplicación:

• Ejemplo: Un Business Service usando la versión de schema 2.5 podría recibir ADT_A01, ADT_A08, SIU_S12 y ORM_O01
• Todos del mismo sistema de información hospitalaria
• El factor unificador es que todos usan la estructura HL7 2.5

Reenvío de Mensajes

Después de recibir y opcionalmente confirmar un mensaje:

• El Business Service lo reenvía al siguiente componente en la cadena de production
• El destino se especifica en la configuración TargetConfigNames
• Típicamente apunta a un HL7 Message Router (Business Process)
• El trabajo del Business Service está completo una vez que ha entregado el mensaje

Resumen General

Los Business Operations representan el límite de salida de tu production, manejando la comunicación saliente a sistemas de salud externos. Son la contraparte de los Business Services, gestionando la entrega final de mensajes que han sido recibidos, enrutados y potencialmente transformados dentro de tu production.

Responsabilidad Principal

La responsabilidad principal de un Business Operation es enviar datos salientes a sistemas externos:

• Cuando una regla de enrutamiento o Business Process determina que un mensaje debe enviarse, lo reenvía al Business Operation apropiado
• El Business Operation utiliza un OutboundAdapter para manejar el protocolo de comunicación:
• TCP: Para mensajería en tiempo real
• FTP: Para cargas de archivos
• File adapter: Para escritura en sistema de archivos local
• HTTP: Para llamadas a servicios web
• SOAP: Para servicios web basados en SOAP

Restricción de Destino Único

Los Business Operations operan bajo una restricción de destino único:

• Cada Business Operation se conecta a un destino
• TCP: Una combinación de dirección IP y número de puerto
• FTP: Un servidor FTP y ruta de directorio
• Salida basada en archivos: Un directorio de sistema de archivos
• Esta relación uno a uno simplifica la configuración, gestión de seguridad y solución de problemas

Múltiples Destinos

Si necesitas enviar mensajes a múltiples sistemas destino:

• Crea múltiples Business Operations
• Ejemplo: Enviar mensajes ADT a tres sistemas (EMR, facturación, reportes) requiere tres Business Operations separadas
• Cada una configurada con detalles de conexión para su destino específico
• Las reglas de enrutamiento en el Message Router envían mensajes a uno, dos o los tres según la lógica de negocio

Restricción Arquitectónica

Una restricción arquitectónica importante:

• Los Business Operations no pueden llamar a Business Processes
• El flujo de datos en las productions es unidireccional desde Services a través de Processes hacia Operations
• Un Business Operation puede devolver mensajes de respuesta al Business Process o Service llamante
• No puede iniciar llamadas a Business Processes
• Esto mantiene límites arquitectónicos claros y previene dependencias circulares

Excepción al Layering Estricto

Aunque poco común, hay una excepción:

• Una Business Operation no HL7 puede llamar a otra Business Operation
• Usado en integraciones complejas donde una operación realiza preprocesamiento y luego delega a otra
• Mejor práctica: Crear un Business Process para orquestar múltiples Business Operations en su lugar
• Esto hace que la lógica de orquestación sea más visible y mantenible

Traducción de Arquitectura

Comprender las capacidades y restricciones de Business Operation es esencial:

• Cada sistema destino en tu paisaje de integración requiere su propio Business Operation
• La elección del adaptador depende de cómo ese sistema destino prefiere recibir datos

Resumen General

Los Business Processes proporcionan la orquestación, enrutamiento y lógica de transformación en el corazón de las integraciones HL7. Se sitúan entre Business Services y Business Operations, tomando decisiones sobre dónde deben ir los mensajes y qué transformaciones deben aplicarse.

HL7 Message Router

El tipo de Business Process más comúnmente usado para integraciones HL7, proporcionando tres capacidades principales:

• Validación de mensajes: Controlada por la configuración Validation
• Ejecución de reglas de enrutamiento: Basada en el RuleSet
• Manejo de errores: A través de la configuración BadMessageHandler

Validación de Mensajes

• Valida mensajes contra definiciones de schema antes de que se ejecuten las reglas de enrutamiento
• La validación predeterminada (dm-z) verifica:
• El mensaje tiene un DocType asignado
• La estructura de segmento coincide con la definición del schema
• Permite Z-segments al final
• Los fallos de validación impiden que el mensaje sea enrutado, protegiendo sistemas posteriores

Manejo de Errores

La configuración BadMessageHandler:

• Especifica otro componente (típicamente una Business Operation) para mensajes de error
• Podría ser una salida de archivo que escribe errores en disco para revisión manual
• O una operación que envía alertas a un sistema de monitoreo
• Sin BadMessageHandler configurado, los mensajes fallidos simplemente se registran

Reglas de Enrutamiento

Después de una validación exitosa, el Message Router ejecuta sus reglas de enrutamiento (RuleSet):

• Las reglas determinan dónde se envían los mensajes según constraints (tipo de mensaje, fuente, valores de campos)
• Pueden aplicar transformaciones de datos durante el enrutamiento
• Pueden tener lógica compleja con muchas reglas o lógica simple enrutando a un destino
• Pueden generar alertas basadas en condiciones configurables

Business Processes Personalizados (BPL)

Más allá del Message Router estándar, puedes crear Business Processes personalizados usando BPL:

• Definir flujos de trabajo complejos con lógica condicional, bucles, procesamiento paralelo
• Llamadas síncronas y asíncronas
• Manejo de errores y transacciones compensatorias
• Usado para orquestaciones multi-etapa, consultas a sistemas externos, patrones de agregación complejos

Llamadas a Otros Componentes

Capacidades de los Business Processes:

• Pueden llamar: Otros Business Processes (orquestación multi-etapa)
• Pueden llamar: Múltiples Business Operations (patrones fan-out)
• No pueden llamar: Business Services (flujo unidireccional desde Services a través de Processes hacia Operations)

Mejor Práctica

InterSystems recomienda asociar cada Business Service con su propio HL7 Message Router dedicado:

• Proporciona aislamiento - los cambios en la lógica de enrutamiento para una integración no afectan a otras
• Mejora la mantenibilidad y solución de problemas
• Mantiene la lógica de enrutamiento enfocada y cohesiva

Resumen General

InterSystems IRIS for Health proporciona un conjunto completo de adaptadores HL7 integrados que soportan cinco protocolos de comunicación. Estos adaptadores manejan los detalles técnicos de la comunicación, permitiendo que Business Services y Operations se enfoquen en la lógica de procesamiento de mensajes.

Adaptadores TCP

Los adaptadores más comúnmente usados para integraciones HL7:

• Nombres de clase: EnsLib.HL7.Adapter.TCP.InboundAdapter y EnsLib.HL7.Adapter.TCP.OutboundAdapter
• Proporciona comunicación en tiempo real orientada a conexión
• Casos de uso: Notificaciones de admisión de pacientes, resultados de pruebas críticas que requieren entrega inmediata
• InboundAdapter: Escucha en un puerto especificado para conexiones entrantes
• OutboundAdapter: Inicia conexiones a sistemas remotos
• Maneja gestión de conexión, encuadre de mensajes (MLLP) y procesamiento de confirmaciones automáticamente

Adaptadores File

Comúnmente usados para escenarios de procesamiento por lotes:

• Nombres de clase: EnsLib.HL7.Adapter.File.InboundAdapter y EnsLib.HL7.Adapter.File.OutboundAdapter
• InboundAdapter: Monitorea un directorio para archivos nuevos, lee mensajes, opcionalmente mueve a directorio procesado
• OutboundAdapter: Escribe mensajes HL7 en archivos en un directorio especificado
• Casos de uso: Transferencias por lotes programadas, cargas de datos históricos, escenarios de procesamiento offline

Adaptadores FTP

Capacidades de procesamiento por lotes similares para sistemas remotos:

• Nombres de clase: EnsLib.HL7.Adapter.FTP.InboundAdapter y EnsLib.HL7.Adapter.FTP.OutboundAdapter
• InboundAdapter: Se conecta al servidor FTP, descarga archivos, los procesa, opcionalmente elimina/mueve en el servidor
• OutboundAdapter: Carga archivos a un servidor FTP
• Casos de uso: Intercambio de datos con compañías de seguros, intercambios de información de salud, laboratorios de referencia

Adaptadores HTTP

Soportan integración basada en servicios web:

• Nombres de clase: EnsLib.HL7.Adapter.HTTP.InboundAdapter y EnsLib.HL7.Adapter.HTTP.OutboundAdapter
• InboundAdapter: Recibe mensajes HL7 mediante peticiones HTTP POST
• OutboundAdapter: Envía mensajes HL7 a endpoints de servicios web
• Cada vez más común a medida que los sistemas de salud adoptan patrones de API RESTful

Adaptadores SOAP

Soportan integración de servicios web SOAP legacy:

• Nombres de clase: EnsLib.HL7.Adapter.SOAP.InboundAdapter y EnsLib.HL7.Adapter.SOAP.OutboundAdapter
• Menos común en implementaciones nuevas (reemplazado por REST/HTTP)
• Aún usado con sistemas empresariales antiguos
• Proporciona manejo de mensajes SOAP, procesamiento WSDL y características de seguridad de servicios web

Elección de Adaptadores

Al seleccionar adaptadores para una nueva integración, considera:

• Capacidades de comunicación: Lo que el sistema externo soporta
• Requisitos de latencia: Tiempo real vs. lotes
• Arquitectura de red: Firewalls, consideraciones de DMZ
• Preferencias operacionales: Estándares y prácticas organizacionales
• TCP: Preferido para mensajería clínica en tiempo real
• File y FTP: Común para transferencias de datos administrativos por lotes
• HTTP: Cada vez más usado para integraciones basadas en API modernas

Resumen General

Las convenciones de nomenclatura consistentes para componentes de production son esenciales para:

• Mantenibilidad
• Colaboración en equipo
• Soporte operacional
• Arquitecturas auto-documentadas

Elementos de Nomenclatura de Componentes

Los nombres de componentes deben identificar claramente:

• El tipo de componente (BS, BP, BO)
• El sistema o aplicación con el que se integra
• El tipo de mensaje o función que maneja
• El protocolo de comunicación usado

Nomenclatura de Business Service

Patrón común: BS_{NombreSistema}_{TipoMensaje}_{Protocolo}

• Ejemplo: "BS_EMR_ADT_TCP" - Business Service recibiendo mensajes ADT de EMR vía TCP
• Ejemplo: "BS_Lab_ORU_FTP" - Business Service recibiendo resultados de laboratorio vía FTP
• Esta claridad es invaluable al solucionar problemas de trazas de mensajes

Nomenclatura de Business Process

Para Message Routers: MR_{NombreSistema}_{TipoMensaje}

• Ejemplo: "MR_EMR_ADT" - Message Router para mensajes ADT de EMR

Para procesos BPL personalizados: BP_{NombreFunción}

• Ejemplo: "BP_OrderOrchestrator" o "BP_PatientMergeProcessor"

Nomenclatura de Business Operation

Patrón similar a Business Services: BO_{NombreSistema}_{TipoMensaje}_{Protocolo}

• Ejemplo: "BO_Billing_ADT_TCP"
• Ejemplo: "BO_Archive_All_File"
• Deja claro dónde se envían los mensajes y cómo

Nomenclatura de Estructura de Mensaje

Elección entre nombres de clase generales y DocTypes específicos:

• Nombres generales (ADT, ORM, SIU): Funcionan bien cuando no necesitas distinguir entre eventos específicos
• DocTypes específicos (ADT_A01): Usar cuando diferentes eventos enrutan de manera diferente o requieren diferentes transformaciones

Nomenclatura de Data Transformation (DTL)

Incluir schemas origen y destino:

• Conversión de versión: "DTL_ADT_A01_2.5_to_2.3"
• Mapeo de sistema: "DTL_EMR_to_Billing_ADT"
• Subtransformaciones: "SubDTL_PID_Standard" o "SubDTL_PV1_AddFacilityCode"

Nomenclatura de Reglas de Enrutamiento

Describir el propósito:

• "Route_ADT_to_Billing"
• "Filter_OutpatientOnly"
• "Transform_Version_2.5_to_2.3"

Extensiones Organizacionales

Muchas organizaciones extienden las convenciones base con:

• Prefijos de entorno: DEV_, TEST_, PROD_
• Identificadores de departamento: ADT_, LAB_, RAD_
• Sufijos de versionado: _v1, _v2
• Principio clave: Establecer convenciones y seguirlas rigurosamente