T1.1: Interprets Interface Requirements

Resumen General

Comprender la relación uno a uno entre productions activas y namespaces es fundamental para la arquitectura de integración HL7 en InterSystems IRIS for Health. Esta restricción arquitectónica significa que independientemente de cuántos sistemas externos estés integrando, solo puedes tener una production ejecutándose en un namespace dado en cualquier momento.

Estrategia de Consolidación

En la práctica, esto se traduce en una estrategia de consolidación donde múltiples circuitos o integraciones HL7 coexisten dentro de una sola production:

• Incluso cuando te conectas a docenas de sistemas de salud diferentes (EMRs, sistemas de laboratorio, sistemas de radiología, aplicaciones de facturación), todas estas integraciones típicamente residen en una production dentro de un namespace
• Cada integración está representada por su propio conjunto de componentes (Business Services, Business Processes, Business Operations) pero todos pertenecen a la misma production

Cuándo Separar Namespaces

La decisión de separar integraciones en múltiples namespaces debe estar impulsada por la escala y las necesidades organizacionales:

• Cuando se gestionan cientos de integraciones, el rendimiento, la complejidad de mantenimiento y los límites organizacionales pueden justificar la creación de múltiples namespaces
• Cada namespace con su propia production proporciona mejor aislamiento, solución de problemas más fácil y límites de propiedad más claros
• Sin embargo, para la mayoría de las organizaciones de salud, una sola production maneja todas las interfaces HL7 efectivamente

Consideraciones de Planificación

Al planificar la arquitectura de namespace y production, considera:

• Impacto del reinicio de production: Reiniciar la production afecta a todas las integraciones
• Conflictos de nombres de componentes: Se requieren nombres únicos dentro de un namespace
• Límites de seguridad: Cada namespace puede tener diferentes configuraciones de seguridad
• Entornos de desarrollo vs producción: Namespaces separados para diferentes etapas
• Estructuras de equipos organizacionales: Propiedad clara y cronogramas de despliegue

Resumen General

Los tres tipos de componentes principales en las productions HL7 de InterSystems forman una arquitectura de flujo de datos unidireccional. Comprender qué componentes pueden llamar a cuáles es esencial tanto para el diseño como para la solución de problemas.

Business Services

Los Business Services representan el límite de entrada de tu production:

• Reciben datos entrantes de sistemas externos a través de varios adaptadores (TCP, FTP, File, HTTP, SOAP)
• Procesan datos de una fuente - un puerto TCP, un directorio para entrada de archivo, una ubicación FTP
• Responsables de recibir el mensaje sin procesar, opcionalmente enviar un ACK de vuelta a la aplicación que llama
• Reenvían el mensaje al siguiente componente a través de la configuración TargetConfigNames

Business Processes

Los Business Processes proporcionan capacidades de orquestación, enrutamiento y transformación:

• Message Router: El tipo más común para HL7, realiza validación de mensajes, ejecuta reglas de enrutamiento y opcionalmente aplica transformaciones de datos
• Pueden llamar a otros Business Processes para orquestación compleja de múltiples etapas
• Pueden llamar a múltiples Business Operations para implementar patrones fan-out donde un mensaje entrante desencadena múltiples mensajes salientes

Business Operations

Los Business Operations manejan la comunicación saliente a sistemas externos:

• Cada uno se conecta a un destino - una combinación de dirección IP y puerto, un servidor FTP, un directorio de archivos
• Aunque poco común, una Business Operation no HL7 puede llamar a otra Business Operation
• La mejor práctica sugiere crear un Business Process para orquestar múltiples operaciones

Restricciones Arquitectónicas Críticas

• BP no puede llamar a BS: Los Business Processes no pueden llamar a Business Services (solo pueden devolver respuestas)
• BO no puede llamar a BP: Las Business Operations no pueden llamar a Business Processes (solo pueden devolver respuestas)
• InboundAdapters: Asociados con Business Services
• OutboundAdapters: Asociados con Business Operations

Resumen General

Traducir especificaciones de interface en arquitectura de production requiere comprender la relación entre sistemas externos y componentes de InterSystems:

• Cada aplicación externa que envía datos a IRIS requiere un Business Service
• Este Business Service representa el endpoint de integración para esa aplicación específica

Múltiples Tipos de Mensajes por Business Service

Un solo Business Service puede manejar múltiples tipos de mensajes HL7 de la misma aplicación, siempre que todos usen la misma versión de HL7:

• Un Business Service podría recibir mensajes ADT para admisiones de pacientes, mensajes SIU para programación de citas y mensajes ORM para órdenes
• Todos deben ser del mismo sistema de información hospitalaria usando la misma versión HL7 (ej., 2.5)
• Limitación crítica: Cada Business Service solo puede ser asignado a una versión de schema HL7
• Si necesitas recibir HL7 2.3 de una aplicación y HL7 2.5 de otra, debes crear Business Services separados

Mejor Práctica: Relación Uno a Uno

Las mejores prácticas de InterSystems recomiendan asociar cada Business Service con su propio HL7 Message Router dedicado:

• Aunque no es técnicamente obligatorio, esto proporciona beneficios arquitectónicos significativos
• Simplifica la evolución con el tiempo al modificar reglas de enrutamiento o agregar nuevas integraciones
• Permite cambios para una aplicación sin riesgo de afectar a otras
• Reduce la carga de pruebas y el riesgo de despliegue

Comunicación Saliente

Para comunicación saliente:

• Cada aplicación externa que recibe datos requiere una Business Operation
• Cada Business Operation se conecta a un solo destino (una combinación de dirección TCP/IP y puerto, un servidor FTP, un directorio de sistema de archivos)
• Para enviar mensajes a múltiples destinos, crea múltiples Business Operations

Revisión de Especificaciones de Interface

Al revisar especificaciones de interface:

• Cuenta sistemas fuente: Cada uno requiere un Business Service
• Identifica versiones HL7: Pueden requerir Business Services separados
• Cuenta sistemas destino: Cada uno requiere una Business Operation
• Message Routers: Se sitúan entre BS y BO, proporcionando validación, lógica de enrutamiento y transformación

Resumen General

Determinar las necesidades de transformación de datos a partir de requisitos de interface implica identificar desajustes entre lo que recibes y lo que debes enviar. Los escenarios de transformación más comunes en integraciones HL7 son:

• Conversión de versión
• Mapeo estructural
• Mapeo de valores

Transformaciones de Conversión de Versión

Requeridas cuando el sistema emisor usa una versión HL7 diferente al sistema receptor:

• Ejemplo: El sistema de laboratorio envía resultados usando HL7 2.5 (estructura ORU_R01 2.5), pero el EMR solo acepta HL7 2.3
• Aunque los tipos de mensajes son conceptualmente iguales, las estructuras de segmentos, posiciones de campos y tipos de datos pueden diferir entre versiones
• Requiere transformación explícita usando una clase Data Transformation Language (DTL)

Transformaciones de Mapeo Estructural

Abordan diferencias en cómo los sistemas organizan datos:

• Un sistema podría incluir información de seguro del paciente en el segmento estándar IN1, mientras que otro requiere que esté en un Z-segment personalizado
• Algunos sistemas incluyen segmentos opcionales como PD1 (Patient Additional Demographic), otros no
• DTL maneja estas diferencias extrayendo datos de una estructura y mapeándolos a otra

Transformaciones de Mapeo de Valores

Convierten códigos y formatos entre sistemas:

• Códigos de género: Un sistema usa "M" y "F", otro usa "Male" y "Female"
• Códigos de instalación, identificadores de proveedor, códigos de departamento: A menudo requieren mapeo entre diferentes sistemas de códigos
• Los DTL proporcionan capacidades de tabla de búsqueda para estas conversiones

Subtransformaciones

Una característica de eficiencia poderosa para lógica reutilizable a nivel de segmento:

• Crear una subtransformación para un segmento (como PID) que aparece en múltiples tipos de mensajes
• Llamar a la misma subtransformación desde múltiples DTLs principales (ADT_A01, SIU_S12, etc.)
• Beneficios: Reduce la duplicación, asegura consistencia, simplifica el mantenimiento

Contexto de Ejecución

Las transformaciones se ejecutan de dos maneras:

• Como parte de las acciones "transform" de las reglas de enrutamiento
• Programáticamente desde código BPL (Business Process Language) en Business Processes personalizados

Resumen General

La validación de mensajes en HL7 Message Routers está controlada por la configuración "Validation", que determina qué tan estrictamente se verifican los mensajes contra sus definiciones de schema antes de que se ejecuten las reglas de enrutamiento. Comprender las configuraciones de validación es crítico porque los fallos de validación impiden el procesamiento de mensajes - el mensaje no será enrutado a ningún destino (excepto opcionalmente a un componente BadMessageHandler si está configurado).

Configuración de Validación Predeterminada

La configuración de validación predeterminada es "1", que es equivalente a "dm-z". Esta es la configuración de validación más comúnmente usada en entornos de producción.

Componentes de Validación Explicados

• d (DocType): DocType debe estar asignado al mensaje
• El Business Service debe tener una Message Schema Category asignada en su configuración
• La categoría de schema (como "2.5") combinada con la estructura del mensaje (como "ADT_A01") forma el DocType completo (como "2.5:ADT_A01")
• Al usar el Testing Service, debes completar el campo DocType o la validación fallará
• m (Estructura de mensaje): Valida la estructura del mensaje a nivel de segmento
• Verifica si los segmentos requeridos están presentes
• Verifica si los segmentos que deben ser únicos no están repetidos
• Verifica si hay segmentos extra que no están definidos en el schema
• Detecta problemas estructurales como un segmento EVN faltante en un mensaje ADT_A01
• -z (Z negativo): Permite Z-segments no reconocidos al final del mensaje
• Incluso si no están definidos en la Message Schema Category
• Útil para aceptar mensajes con segmentos personalizados sin definir schemas personalizados

Qué NO Verifica dm-z

Las validaciones a nivel de campo no están incluidas:

• Si los campos exceden la longitud máxima
• Si los campos requeridos dentro de los segmentos están poblados
• Si los valores cumplen con las restricciones de la tabla de códigos
• Si los tipos de datos son correctos
• Opciones adicionales como "r" (verificación de campos requeridos) y "l" (verificación de longitud) se usan menos comúnmente

Momento de la Validación

• La validación se ejecuta antes del procesamiento de reglas de enrutamiento
• Si la validación falla, no se ejecutan reglas de enrutamiento
• El mensaje se descarta o se envía a BadMessageHandler si está configurado
• Este enfoque fail-fast previene que mensajes inválidos se propaguen

Resumen General

Las reglas de enrutamiento forman la lógica de decisión en los HL7 Message Routers, determinando dónde se envían los mensajes y qué transformaciones se aplican. Comprender la estructura de las reglas de enrutamiento es esencial tanto para diseñar integraciones como para solucionar problemas de enrutamiento.

Configuraciones a Nivel RuleSet

A nivel RuleSet, las fechas effectiveBegin y effectiveEnd controlan cuándo se activa todo el conjunto de reglas:

• Te permite preparar cambios de enrutamiento con anticipación
• Desplegar nuevas reglas de enrutamiento a producción pero hacer que se activen automáticamente en una fecha y hora futura específica
• Particularmente valioso para actualizaciones programadas, go-lives o cambios de cumplimiento regulatorio

Componentes de Reglas Individuales

Cada regla individual tiene una bandera disabled y una sección constraint:

• Bandera disabled: Cuando es true, la regla se omite completamente
• Sección constraint: Actúa como un filtro determinando a qué mensajes se aplica la regla

Campos Constraint

• Source: Qué Business Service o Business Process debe haber enviado el mensaje
• Importante durante pruebas: cuando usas Testing Service, debes poblar el campo Source para que coincida con el constraint
• Schema Category: La versión HL7 (como "2.5")
• DocType: La estructura del mensaje (como "ADT_A01")
• Document Name: El evento específico

Habilitación de Condiciones a Nivel de Campo

Requisito crítico para usar condiciones "when" que hacen referencia a campos HL7:

• Debes especificar la Schema Category y DocType en el constraint
• Sin esta información, el motor de enrutamiento no puede analizar la estructura del mensaje para acceder a campos individuales
• Tu condición fallará si estos no están especificados

Acciones de Reglas de Enrutamiento

• Send: Enruta el mensaje a uno o más componentes destino
• Una sola acción Send puede tener múltiples destinos
• Puede incluir una transformación, aplicando un DTL para convertir la estructura del mensaje antes de enviar
• Para diferentes transformaciones a diferentes destinos, usa acciones Send separadas
• Return: Crítico para controlar el flujo de ejecución de reglas
• Cuando se ejecuta, no se evalúan reglas subsiguientes para ese mensaje
• Permite reglas de manejo de excepciones en la parte superior que procesan casos especiales y retornan
• Sin Return, todas las reglas se evalúan y múltiples acciones Send podrían dispararse
• Continue: Indica explícitamente que el procesamiento debe continuar a la siguiente regla
• Este es el comportamiento predeterminado cuando no hay Return presente
• Hace que la lógica de reglas sea más legible y mantenible