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

InterSystems recomienda establecer un conjunto completo de convenciones de nomenclatura al inicio del proyecto, en lugar de dejar que crezcan interfaz a interfaz. Los nombres se componen de segmentos breves (3-6 caracteres):

• Palabras clave: From (entrada), To (salida), Router (enrutamiento), Rules (rule

sets), y un número de categoría de schema base (2.1 … 2.7.1) para los schemas

• Un nombre corto para cada aplicación (EMR, ERChart, Billing)
• Una palabra clave de clase de mensaje (ADT, ORM, ORU) o un nombre completo de estructura

de mensaje (ADT_A01)

Los nombres distinguen mayúsculas de minúsculas.

> La documentación señala que *cualquier* convención que identifique claramente los componentes > por su función es aceptable — el conjunto siguiente es el que publica InterSystems, y el que > espera el examen.

Nomenclatura de Business Service

Convención: FromSourceAppName

• Ejemplos: "FromERChart", "FromFineOR", "FromDeskAdm"
• Variación: cuando una aplicación envía a través de más de un business service, se añade

una palabra clave MessageTypes (normalmente las tres primeras letras de la estructura del mensaje): FromSourceAppNameMessageTypes → "FromEMRADT"

Nomenclatura del Proceso de Enrutamiento

Convención: SourceAppNameRouter

• Ejemplos: "ERChartRouter", "FineORRouter", "DeskAdmRouter"
• Variación: SourceAppNameMessageTypesRouter → "ERChartADTRouter", "ERChartORMRouter",

"ERChartOtherRouter"

Nomenclatura de Rule Sets de Enrutamiento

Nombra cada rule set para que coincida con su proceso de enrutamiento: para cada SourceAppNameRouter, llama al rule set SourceAppNameRules; para cada SourceAppNameMessageTypesRouter, SourceAppNameMessageTypesRules.

• Ejemplos: "DeskAdmRules", "DeskAdmORMRules"

Nomenclatura de Business Operation

Convención: ToTargetAppName

• Ejemplos: "ToImagit", "ToFineOR", "ToPindex"
• Variación: cuando una aplicación recibe a través de más de una business operation, se

añade una palabra clave MessageTypes: ToTargetAppNameMessageTypes → "ToBillingADT"

• El transporte no se codifica en el nombre — los ajustes del adaptador ya lo registran

Nomenclatura de Categorías de Schema Personalizadas

Convención: ApplicationNameBaseSchemaNumber (p. ej. "EMR2.5"), donde el nombre de aplicación puede ser la aplicación emisora o la receptora.

> Nota sobre los esquemas de prefijos. Convenciones de prefijo por tipo de componente como > BS_EMR_ADT_TCP, MR_EMR_ADT y BO_Billing_ADT_TCP se usan ampliamente en clientes y > cumplen el criterio de "identificar claramente por función", pero no son la convención > documentada por InterSystems. Las preguntas de examen que piden el patrón recomendado esperan > el conjunto From/To/Router/Rules anterior.

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