T2.2: Creates Routing Rules

Resumen

El editor de reglas de enrutamiento en InterSystems HealthConnect proporciona una interfaz poderosa para crear lógica compleja de enrutamiento de mensajes.

Estructura de RuleSet

• RuleSet: Contenedor para todas las reglas de enrutamiento asociadas con un Message Router Business Process particular
• Para cada mensaje, el RuleSet evalúa cada regla en orden secuencial
• Concepto crítico: Todas las reglas se evalúan para cada mensaje a menos que una acción return detenga la evaluación

Nota del Editor de Examen

Desde abril de 2025, el examen todavía usa la interfaz antigua del editor de reglas basada en ZEN:

• Acceda al editor antiguo haciendo clic en el botón en la esquina superior derecha
• Familiarícese con la apariencia y funcionalidad del editor antiguo para la preparación del examen
• La lógica de regla subyacente permanece igual

Propiedades de RuleSet

• Fechas effectiveBegin/effectiveEnd: Controlan cuándo el RuleSet se vuelve activo
• Permite múltiples RuleSets para el mismo Message Router con fechas de transición
• Útil para actualizaciones o migraciones planificadas
• Solo se evaluará el RuleSet cuyas fechas efectivas incluyan la fecha/hora actual

Componentes de Regla

Las reglas individuales consisten en tres componentes principales:

• Restricciones (Constraints): Actúan como filtros para determinar si la regla debe evaluarse
• Condiciones when: Definen criterios específicos que deben cumplirse
• Acciones: Especifican qué hacer cuando se cumplen las condiciones

Resumen

Las reglas de enrutamiento necesitan acceder al contenido de mensajes HL7 para tomar decisiones inteligentes de enrutamiento basadas en información de paciente, tipo de mensaje, o cualquier otro dato en el mensaje.

Dos Sintaxis para Acceso a Campos

El editor de expresiones proporciona dos sintaxis primarias:

• HL7.{PropertyPath}: Enfoque tradicional más antiguo comúnmente visto en preguntas de examen
• Document.{PropertyPath}: Alternativa más nueva
• Ambas sintaxis proporcionan funcionalidad equivalente para acceder campos de mensaje

Restricciones Requeridas

Antes de usar cualquiera de las sintaxis para acceder contenido de mensaje en condiciones when:

• Restricción docCategory: Especifica la versión HL7 (como "2.5")
• Restricción docName: Especifica la estructura de mensaje (como "ADT_A01")
• Estas restricciones son prerrequisitos que indican al editor de reglas qué estructura de mensaje esperar
• Habilita acceso a campos y completado de código en el editor de expresiones

Interfaz de Selector de Campos

El editor de expresiones incluye una interfaz de selector de campos:

• Navegar visualmente la estructura del mensaje
• Seleccionar el campo específico que desea acceder
• Ejemplo: Navegar a través de PIDgrp, seleccionar segmento PID, luego campo de nombre de paciente
• El selector genera sintaxis de ruta de propiedad virtual apropiada automáticamente

Rutas de Propiedades Virtuales

Use notación de punto para navegar la estructura jerárquica:

• PIDgrp.PID:18: Accede campo 18 del segmento PID dentro del grupo PID
• PIDgrp.PV1grp.PV1:18: Navega a través de grupos de segmentos anidados
• Comprender la estructura de mensaje es esencial para construir rutas de propiedades correctas

Resumen

La relación entre las restricciones de regla y la capacidad de completado de código del editor de expresiones es un concepto crítico que aparece frecuentemente en el examen de certificación.

Propósito Dual de Restricciones

Las restricciones en reglas de enrutamiento sirven propósitos duales:

• Filtro: Determinar a qué mensajes aplica la regla
• Habilitar completado de código: Permitir que el editor de expresiones comprenda la estructura del mensaje

Cómo las Restricciones Habilitan el Completado de Código

• Restricción docCategory: Indica al editor de reglas qué versión HL7 (2.3.1, 2.5, 2.7, etc.)
• Restricción docName: Especifica la estructura exacta de mensaje (ADT_A01, ORM_O01, ORU_R01, etc.)
• Con ambas definidas, el editor de expresiones sabe:
• Qué campos, segmentos y grupos de segmentos están disponibles
• Puede proporcionar sugerencias apropiadas de completado de código
• Puede validar su sintaxis de acceso a campos

Sin Restricciones

Si intenta usar sintaxis HL7.{} sin docCategory y docName:

• El editor de expresiones no sabe qué estructura de mensaje esperar
• No puede proporcionar completado de código o validación
• Puede llevar a errores en tiempo de ejecución al acceder campos
• Las restricciones proporcionan contexto para la interfaz de selector de campos y rutas de propiedades virtuales correctas

Relevancia para el Examen

• Aparece frecuentemente en preguntas de examen con combinaciones específicas de restricciones
• docCategory y docName son prerrequisitos para sintaxis de campos de mensaje HL7
• Si el acceso a campos no funciona, verifique si las restricciones apropiadas están definidas

Resumen

La sintaxis HL7.{} con llaves está diseñada para acceder valores de campo específicos únicos en condiciones de reglas de enrutamiento.

Acceso a Campo Único

Esta sintaxis retorna el valor de una ocurrencia de campo particular:

• Permite comparaciones directas usando operadores estándar: equals (=), not equals (!=), greater than (>), less than (<)
• Ejemplo: `HL7.{MSH:MessageType.TriggerEvent} = "A01"` verifica si el evento disparador es igual a "A01"

Campos y Segmentos Repetidos

Al trabajar con elementos repetidos, especifique qué ocurrencia desea:

• Ejemplo: `HL7.{NK1(1):Name(1).familylastname.familyname} = "Kennedy"`
• Accede primera ocurrencia del segmento NK1 (Next of Kin)
• Luego primera ocurrencia del campo Name dentro de ese segmento
• Finalmente el componente family last name
• Los números de ocurrencia entre paréntesis son requeridos para elementos repetidos

Sintaxis de Navegación

• Sintaxis de dos puntos: El número de campo sigue dos puntos (ej., :18 para campo 18)
• Notación de punto: Números de componente o nombres de campo siguen puntos
• Comprender el schema HL7 es esencial para construir rutas de propiedades correctas
• El schema indica qué segmentos/campos pueden repetirse y qué componentes contiene cada campo

Casos de Uso

Más apropiado al verificar un valor específico en una ubicación específica:

• Clase de paciente: `PV1:2 = "I"` para paciente interno
• Facilidad receptora: `MSH:6` coincide con un código de facilidad específico
• Las capacidades de comparación directa hacen esta sintaxis eficiente y legible

Resumen

La sintaxis HL7.() con paréntesis está diseñada específicamente para trabajar con segmentos repetidos y campos repetidos donde desea buscar a través de todas las ocurrencias en lugar de acceder una instancia específica.

Cuándo Usar Esta Sintaxis

Particularmente poderosa cuando:

• No sabe qué ocurrencia contiene el valor que está buscando
• Desea coincidir contra cualquier ocurrencia que cumpla sus criterios

Formato de Valor Retornado

Cuando usa la sintaxis HL7.():

• El valor retornado es una colección de todos los valores coincidentes concatenados juntos
• Cada valor envuelto en ángulos
• Ejemplo: Paciente tiene tres Next of Kin con apellidos "Kennedy", "Smith" y "Jones"
• Expresión `HL7.(NK1():Name().familylastname.familyname)` retorna ``

Uso del Operador Contains

Porque el valor retornado es una cadena delimitada con ángulos:

• No puede usar el operador equals (=) simple
• Debe usar el operador Contains
• Ejemplo: `HL7.(NK1():Name().familylastname.familyname) Contains ""`
• Retorna verdadero si cualquier Next of Kin tiene "Kennedy" como apellido
• Independientemente de qué ocurrencia o cuántas totales están presentes

Casos de Uso Comunes

Esencial para escenarios con elementos repetidos:

• Múltiples OBX: Resultados de observación
• Múltiples NK1: Next of kin
• Múltiples segmentos de seguro: IN1/IN2
• Campos repetidos: Múltiples identificadores de paciente, números de teléfono
• Buscar eficientemente a través de todas las ocurrencias en una sola condición

Resumen

La acción foreach en reglas de enrutamiento proporciona capacidades sofisticadas de iteración sobre segmentos repetidos dentro de mensajes HL7.

Casos de Uso

Particularmente valiosa al procesar:

• Resultados de laboratorio (mensajes ORU con múltiples segmentos OBX)
• Tipos de mensaje donde necesita lógica de enrutamiento diferente para diferentes ocurrencias del mismo tipo de segmento

Cómo Funciona foreach

• Crea un bucle que itera sobre cada ocurrencia de un segmento repetido especificado
• Ejemplo: `foreach OBX` ejecuta una vez por cada segmento OBX en el mensaje
• Dentro del bucle, define condiciones que examinan cada segmento individualmente
• Realiza diferentes acciones basadas en lo que se encuentra en esa ocurrencia particular

Diferencia Crítica de Sintaxis

Dentro de bucles foreach, use sintaxis de acceso a campo diferente:

• Use Segment.{field} en lugar de HL7.{field}
• El contexto del bucle está enfocado en la ocurrencia actual del segmento
• La referencia de segmento se refiere a ese segmento de iteración específico
• Ejemplo: Dentro de `foreach OBX`, use `Segment.{3}` para acceder campo 3 (Observation Identifier)

Aplicaciones Prácticas

• Dividir mensajes ORU: Múltiples segmentos OBX en mensajes separados para diferentes departamentos
• Enrutar resultados de pruebas: Resultados específicos a sistemas especializados, otros a EMR general
• Aplicar transformaciones: Diferentes transformaciones a diferentes tipos de observación
• Mejora significativamente la flexibilidad de enrutamiento más allá de la sintaxis tradicional

Resumen

La acción send es el mecanismo fundamental de enrutamiento en reglas de enrutamiento, dirigiendo mensajes desde el Business Service a través del Message Router a Business Processes o Business Operations destino.

Cómo Funciona Send

• Cada acción send especifica uno o más componentes destino por sus nombres de configuración de producción
• Cuando se ejecuta, crea una copia del mensaje y la reenvía a cada destino especificado
• Habilita distribución de mensajes a múltiples sistemas o rutas de procesamiento

Múltiples Destinos

Una sola acción send puede especificar múltiples destinos separados por comas:

• Eficiente al enviar el mismo mensaje a varios destinos
• Ejemplo: Enviar mensaje ADT de admisión tanto al sistema de facturación como al sistema de gestión de camas
• Todos los destinos reciben contenido de mensaje idéntico
• Adecuado para escenarios de difusión donde múltiples sistemas necesitan la misma información

Integración de Transformación

La acción send puede incluir opcionalmente un parámetro de transformación:

• Especifica una clase DTL (Data Transformation Language) para aplicar antes de enviar
• El DTL se ejecuta y crea una versión transformada del mensaje
• La versión transformada es lo que se envía al(los) destino(s)
• Permite modificar la estructura del mensaje basado en decisiones de enrutamiento sin Business Processes de transformación separados

Diferentes Transformaciones a Diferentes Destinos

Cuando se necesitan diferentes versiones transformadas:

• Use múltiples acciones send dentro de la misma regla (o en reglas diferentes)
• Ejemplo: Un send transforma a versión 2.3.1 para sistema heredado, otro transforma a versión 2.5 para sistema moderno
• Cada acción send se ejecuta independientemente con su transformación y destinos especificados
• Proporciona máxima flexibilidad de enrutamiento

Resumen

Comprender el flujo de evaluación de reglas y la acción return es crítico para crear reglas de enrutamiento eficientes y evitar comportamiento de enrutamiento no deseado.

Evaluación de Reglas Predeterminada

• Cuando un mensaje entra a un Message Router, el RuleSet evalúa cada regla en orden secuencial
• Por defecto, todas las reglas se ejecutarán a menos que se detengan explícitamente
• La acción return proporciona el mecanismo para detener la evaluación de reglas

Cuándo Usar Return

Particularmente importante cuando tiene reglas que deben ser mutuamente exclusivas:

• Reglas separadas para enrutar diferentes tipos de mensaje a diferentes destinos
• Use return después de enrutar exitosamente un mensaje ADT
• Asegura que las reglas diseñadas para mensajes ORU no lo procesen también
• Sin return, tanto la regla específica de ADT como las reglas subsiguientes se ejecutarían
• Podría causar envíos duplicados o enrutamiento no deseado

Return vs Continue

• Acción Continue: Permite que la evaluación de reglas proceda a la siguiente regla
• Apropiado cuando múltiples reglas potencialmente deben procesar el mismo mensaje
• La ausencia de cualquier acción de control de flujo tiene el mismo efecto
• Acción Return: Detiene inmediatamente toda evaluación de reglas para el mensaje actual
• Incluso si hay más reglas en el RuleSet

Comportamiento de Cláusula When

Dentro de una sola regla con múltiples cláusulas when:

• Solo la primera cláusula when coincidente se ejecuta
• Si when1 coincide y se ejecuta, when2 y otherwise se omiten
• Incluso si la condición de when2 también sería verdadera
• Esto es independiente de la acción return
• Return controla si la evaluación continúa a la siguiente regla
• La coincidencia de cláusula when controla qué acciones se ejecutan dentro de la regla actual

Resumen

La solución de problemas de reglas de enrutamiento requiere análisis sistemático de cómo las restricciones, condiciones y acciones interactúan.

Problemas de Desajuste de Restricciones

Uno de los problemas más comunes - las restricciones de la regla no coinciden con las propiedades del mensaje entrante:

• Restricción Source: Verificar que coincida con el nombre real del Business Service que envía el mensaje
• Restricción docCategory: Debe coincidir con Message Schema Category configurado en Business Service
• Restricción docName: Debe coincidir con estructura de mensaje real siendo procesada
• Si alguna restricción no coincide, la regla se omite completamente

Trampa del Testing Service

Un escenario de examen particularmente tramposo:

• Cuando prueba usando la interfaz de prueba incorporada, el mensaje viene del "Testing Service" virtual
• No de su Business Service real
• Si la regla tiene restricción Source especificando nombre de Business Service real, la regla no coincidirá durante pruebas
• Aunque coincidiría en producción
• Puede causar confusión cuando la regla parece no funcionar durante pruebas

Problemas de Acceso a Campos

Frecuentemente provienen de restricciones faltantes o incorrectas:

• La sintaxis HL7.{} requiere restricciones tanto docCategory como docName
• Sin ellas, el editor de expresiones no puede determinar la estructura del mensaje
• Si docName no coincide con la estructura real del mensaje, el acceso a campos falla en tiempo de ejecución
• La estructura del mensaje no coincide con lo que la regla espera

Orden de Reglas y Colocación de Return

Afecta significativamente el comportamiento de enrutamiento:

• Si una regla anterior coincide y ejecuta return, todas las reglas subsiguientes se omiten
• Independientemente de si hubieran coincidido
• Cuando los mensajes no se enrutan como se espera, verifique reglas anteriores con return
• Revise el orden de reglas en el RuleSet
• Verifique que la colocación de acción return asegure que el flujo de evaluación coincida con la intención