T2.5: Creates Custom Schemas

Limitaciones del Schema Estándar

Los schemas HL7 estándar de InterSystems proporcionan cobertura completa para mensajes HL7 definidos por ANSI. Sin embargo, las implementaciones del mundo real frecuentemente requieren extensiones más allá del estándar. Las instituciones de salud agregan segmentos Z para transportar datos propietarios, vendors extienden mensajes con información específica de aplicaciones, y los sitios locales crean tablas de códigos personalizadas para datos específicos de instalaciones. Los schemas estándar no incluyen estas extensiones locales.

Extensión vs Reemplazo

Los custom schemas extienden schemas estándar en lugar de reemplazarlos. Cuando crea un custom schema basado en el schema 2.5 de InterSystems, su custom schema hereda todas las definiciones de 2.5 más sus adiciones. Esto es crítico: no está recreando el schema completo, está solo agregando extensiones. InterSystems IRIS consulta primero su custom schema para definiciones y retrocede al schema base si no se encuentra nada.

Casos de Uso Comunes

Segmentos Z son el caso de uso más común. Por ejemplo, una institución podría definir un segmento ZPD para transportar demografía adicional de pacientes más allá de lo que PID puede contener. Otro sitio podría crear un segmento ZCO para información de consentimiento. Estos segmentos Z siguen convenciones de nombramiento HL7 (comenzando con 'Z') pero no existen en schemas estándar.

Tablas personalizadas representan otro escenario. Los estándares HL7 definen muchas tablas de códigos estándar (género, tipo de identificador de paciente, etc.), pero los sitios frecuentemente necesitan tablas adicionales para valores específicos de instituciones. Los custom schemas pueden definir estas tablas locales.

Extensiones de vendors ocurren cuando los sistemas de software extienden mensajes estándar con campos adicionales. Por ejemplo, un sistema EMR vendor podría agregar campos propietarios a OBX o agregar campos al final de segmentos estándar. Los custom schemas documentan estas extensiones y permiten que HealthConnect valide correctamente mensajes extendidos.

Importancia para el Examen

Entender cuándo crear custom schemas es tan importante como saber cómo crearlos. El examen puede presentar escenarios describiendo discrepancias de mensajes y preguntarle si se necesita un custom schema. Los indicadores clave son referencias a segmentos Z, tablas de códigos específicas del sitio, campos adicionales más allá de las definiciones estándar, o mensajes de vendors que no validan contra schemas estándar.

Arquitectura de Herencia

Los custom schemas en InterSystems IRIS se construyen usando una arquitectura de herencia. En lugar de recrear todas las definiciones de segmentos, tipos de datos y estructuras de mensajes desde cero, su custom schema hereda de uno de los schemas HL7 estándar de InterSystems. Esta herencia significa que su custom schema obtiene automáticamente todas las capacidades del schema base sin necesidad de definirlas explícitamente.

Seleccionando el Schema Base Correcto

El schema base que selecciona debe coincidir con la versión HL7 de los mensajes con los que está trabajando principalmente. Si su institución envía y recibe mensajes HL7 v2.5, su custom schema debería heredar del schema 2.5 de InterSystems. Si trabaja principalmente con v2.7.1, herede de 2.7.1. Esta coincidencia asegura que todas las definiciones estándar se alinean con su versión de mensaje.

Escenarios de Versión Mixta

En ambientes con versiones HL7 mixtas, típicamente crea el custom schema basado en la versión más reciente que necesita soportar, luego usa configuraciones específicas de Business Service para manejar mensajes de versión anterior. HealthConnect puede procesar mensajes 2.3 incluso cuando su custom schema se basa en 2.5, aunque la validación será menos estricta para las estructuras de mensajes más antiguos.

Valores Base Disponibles

InterSystems proporciona schemas base para todas las versiones principales de HL7: 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1 y 2.8. Al crear un custom schema, debe especificar uno de estos exactamente. El valor que ingresa debe coincidir con el nombre del schema base de InterSystems. Por ejemplo, especifique "2.5" para heredar del schema 2.5 de InterSystems.

Beneficios de la Herencia

Este modelo de herencia proporciona varios beneficios. Primero, reduce drásticamente la cantidad de trabajo al crear custom schemas - solo define adiciones y cambios. Segundo, cuando InterSystems actualiza los schemas base (para correcciones o aclaraciones), sus custom schemas heredan automáticamente esas mejoras. Tercero, la herencia hace que los custom schemas sean más mantenibles - cambios a extensiones están claramente separados de definiciones estándar.

Accediendo al Editor de Schema

El Schema Editor se accede a través del Management Portal navegando a la sección HL7 v2, seleccionando Schema Structures en el menú de navegación, y haciendo clic en New. Esta herramienta basada en web proporciona una interfaz completa para definir custom schemas sin requerir edición de archivos XML o herramientas externas.

Configuración Inicial del Schema

Al crear un nuevo custom schema, el primer paso implica especificar configuraciones básicas del schema. El nombre del schema es un identificador único que usará en toda su configuración de HealthConnect. Elija un nombre descriptivo que refleje el propósito del schema - por ejemplo, "HospitalXYZ_Extensions" o "EPICCustom_25". Este nombre aparecerá en menús desplegables al configurar Business Services y es cómo referencia el schema en configuración.

Selección de Schema Base

La configuración Base especifica de qué schema estándar de InterSystems hereda su custom schema. Como se discutió en la sección anterior, esto debe coincidir con su versión HL7 primaria. El menú desplegable proporciona todos los schemas base disponibles. Seleccionar el base correcto es crítico - si selecciona 2.3 pero sus mensajes son 2.5, las validaciones fallarán debido a diferencias de estructura entre versiones.

Documentación y Metadatos

El campo Descripción proporciona espacio para documentar el propósito del schema, qué extensiones contiene y cualquier otra información pertinente. Mientras técnicamente es opcional, una descripción detallada es invaluable para mantenimiento futuro. Cuando otro desarrollador necesita modificar el schema o resolver problemas de validación, la descripción proporciona contexto esencial.

Configuración Inicial vs Definición Continua

El editor de schema separa la configuración inicial (nombre, base, descripción) de la definición continua de extensiones (segmentos Z, tablas, modificaciones de mensajes). Después de establecer las propiedades básicas del schema, las secciones subsiguientes del editor le permiten agregar y modificar estructuras de schema específicas.

Convenciones de Nombramiento de Segmentos Z

Los segmentos Z siguen la convención de nombramiento HL7 de comenzar con la letra 'Z', indicando extensiones definidas localmente. Los nombres comunes incluyen ZPD (Z-Patient Demographics), ZPI (Z-Patient Insurance), ZCO (Z-Consent), ZOB (Z-Observations), etc. Al nombrar segmentos Z, elija nombres que sean mnemotécnicamente significativos para su organización mientras sigan la convención Z*.

Estructura de Definición de Campo

Cada campo en un segmento Z requiere varios atributos específicos. El número de secuencia determina la posición del campo dentro del segmento, comenzando en 1. Los campos deben numerarse secuencialmente sin espacios - no puede tener los campos 1, 2 y 4 omitiendo 3.

Selección de Tipo de Dato

El tipo de dato especifica qué tipo de dato HL7 ocupa el campo. Use tipos de dato HL7 estándar en lugar de inventar nuevos. Los tipos comunes incluyen:

• ST (String): Datos de texto general
• NM (Numeric): Valores numéricos
• DT (Date): Fechas en formato YYYYMMDD
• TM (Time): Tiempos en formato HHMMSS
• CE (Coded Element): Pares código/texto de tablas de códigos
• CX (Extended Composite ID): Identificadores complejos con asignación de autoridad
• XPN (Extended Person Name): Nombres estructurados con apellidos, nombres, títulos

Tipos de Dato Simples vs Complejos

Los tipos de dato simples como ST y NM contienen valores únicos. Los tipos complejos como CE y CX contienen múltiples componentes. Por ejemplo, CE contiene identificador, texto, sistema de codificación, identificador alternativo, texto alternativo y sistema de codificación alternativo. No necesita definir estos componentes en su custom schema - son heredados del schema base. Simplemente especifique que el campo es tipo CE, y IRIS aplica automáticamente la estructura de componente CE.

Longitud de Campo y Opcionalidad

La longitud especifica la longitud máxima del campo en caracteres. Para campos de texto como ST, especifique una longitud razonable basada en requisitos de negocio. Para campos de longitud fija como DT (siempre 8 caracteres) o TM (6-14 caracteres), especifique el máximo esperado.

Opcionalidad determina si el campo debe estar presente. "Required" significa que el campo debe aparecer en cada instancia del segmento. "Optional" significa que el campo puede estar presente o ausente. "Conditional" indica que el campo es requerido bajo ciertas condiciones (documentadas en la descripción del campo).

Importancia para el Examen

Las preguntas de examen pueden presentar una definición de segmento Z y preguntarle sobre tipos de dato apropiados para campos específicos, o pueden preguntar qué opcionalidad debe tener un campo según requisitos de negocio. Entender tipos de dato HL7 y cuándo usar cada uno es conocimiento esencial.

Separación de Definición y Uso

Un malentendido común es asumir que definir un segmento Z automáticamente lo hace disponible en mensajes. Esto es incorrecto. Definir un segmento Z crea la estructura del segmento (cuáles campos contiene y sus tipos de dato), pero no especifica dónde aparece ese segmento en los mensajes. Esto requiere un segundo paso: modificar estructuras de tipo de mensaje.

Modificando Tipos de Mensaje

Los tipos de mensaje HL7 (ADT_A01, ORU_R01, ORM_O01, etc.) definen qué segmentos aparecen en qué orden. Para usar su segmento Z recién definido, debe modificar los tipos de mensaje apropiados para incluirlo. Por ejemplo, si creó un segmento ZPD para demografía adicional de paciente, modifique ADT_A01 para incluir ZPD en su secuencia de segmentos.

Posicionamiento de Segmento

Al agregar un segmento Z a un tipo de mensaje, especifique dónde aparece en la secuencia de mensajes. Los segmentos Z típicamente se agregan al final de grupos de segmentos relacionados. Por ejemplo, ZPD seguiría después del segmento PID estándar, ya que ambos contienen demografía de paciente. ZOB seguiría después de segmentos OBX estándar, ya que ambos contienen observaciones.

Opcionalidad y Repetición

Al agregar el segmento a la estructura de mensaje, configure si es Required u Optional. Si el segmento debe aparecer en cada mensaje de ese tipo, márquelo como Required. Si puede o no aparecer, márquelo como Optional. La configuración de opcionalidad en la estructura de mensaje es independiente de la opcionalidad de campo dentro del segmento.

También configure si el segmento puede repetir. Si pueden aparecer múltiples instancias del segmento Z en un solo mensaje (por ejemplo, múltiples segmentos ZOB para diferentes observaciones), habilite la repetición. Si solo puede aparecer una instancia, deshabilite la repetición.

Escenario de Examen

Las preguntas de examen frecuentemente prueban la comprensión de este proceso de dos pasos. Una pregunta podría afirmar, "Definiste un segmento ZCO pero no aparece en mensajes ADT_A01. ¿Cuál es el problema?" La respuesta correcta es que debe modificar la estructura de mensaje ADT_A01 para incluir el segmento ZCO - definir el segmento solo no es suficiente.

Rol de Message Schema Category

La configuración Message Schema Category en Business Services determina qué schema HL7 usa IRIS para parsear, validar y procesar mensajes entrantes. Por defecto, esta configuración apunta a schemas HL7 estándar de InterSystems (2.5, 2.7, etc.). Para usar un custom schema, cambie esta configuración al nombre de su custom schema.

Especificando el Nombre del Custom Schema

El valor que ingresa debe coincidir exactamente con el nombre que asignó cuando creó el custom schema en el Schema Editor. Si nombró su custom schema "HospitalXYZ_Extensions", ingrese "HospitalXYZ_Extensions" (respetando mayúsculas y minúsculas). No ingrese el schema base (como "2.5") - eso haría que el Business Service use el schema estándar en lugar de su custom schema.

Alcance de la Configuración

La configuración Message Schema Category se aplica a todos los mensajes recibidos por ese Business Service específico. Si tiene múltiples Business Services recibiendo mensajes de diferentes sistemas externos, cada uno puede usar diferentes custom schemas. Un Business Service podría usar "VendorA_Extensions" mientras otro usa "VendorB_Extensions", permitiendo validación apropiada para extensiones específicas de vendors.

Herencia y Capacidades

Cuando un Business Service usa un custom schema, los mensajes entrantes obtienen las capacidades completas tanto del custom schema como del schema base heredado. Si su custom schema se basa en 2.5 y define segmentos Z, los mensajes se validan contra todos los segmentos estándar 2.5 más sus segmentos Z. No pierde ninguna funcionalidad del schema base - solo agrega capacidades adicionales.

Error de Configuración Común

Un error común es crear un custom schema pero olvidar actualizar la configuración Message Schema Category en el Business Service. El custom schema existe pero nunca se usa porque el Business Service todavía apunta al schema estándar. Los síntomas incluyen fallas de validación en segmentos Z (reportados como segmentos no reconocidos) o incapacidad para parsear campos extendidos. La solución es verificar que Message Schema Category esté configurado con su nombre de custom schema.

Importancia para el Examen

Las preguntas de examen pueden presentar escenarios donde existe un custom schema pero los mensajes no se validan correctamente. La causa raíz frecuentemente es una configuración incorrecta de Message Schema Category. Recordar verificar esta configuración es esencial tanto para el examen como para la resolución de problemas en el mundo real.

Necesidad de Portabilidad

Los custom schemas se desarrollan típicamente en entornos de desarrollo, se prueban en entornos de prueba y finalmente se despliegan en producción. La capacidad de exportar e importar custom schemas es esencial para mover definiciones de schema a través de esta tubería de desarrollo sin recreación manual.

Proceso de Exportación

Para exportar un custom schema, navegue a HL7 v2 → Schema Structures en el Management Portal, seleccione el custom schema de la lista y haga clic en Export. IRIS genera un archivo XML que contiene la definición completa del schema, incluyendo el nombre del schema, schema base, todas las definiciones de segmento Z, modificaciones de mensajes, definiciones de tablas y otros metadatos del schema.

Formato de Archivo XML

El archivo XML exportado es legible por humanos y representa toda la estructura del schema en un formato que IRIS puede reimportar. Este formato XML es el mecanismo estándar de InterSystems para portabilidad de schema. El XML contiene toda la información necesaria para recrear el schema idénticamente en otra instancia de IRIS.

Proceso de Importación

Para importar un custom schema a otra instancia de IRIS, navegue a HL7 v2 → Schema Structures → Import, seleccione el archivo XML exportado y cárguelo. IRIS parsea el XML y crea el custom schema con todas sus definiciones. Si ya existe un schema con el mismo nombre, IRIS pide confirmación antes de sobrescribirlo.

Migración Dev → Test → Producción

El flujo de trabajo típico implica desarrollar y refinar el custom schema en desarrollo, exportarlo a XML y verificarlo en control de versión. Para promover a test, importe el archivo XML en el entorno de test. Después de la validación de pruebas, importe el mismo archivo XML en producción. Este proceso asegura consistencia entre entornos - el schema en producción es idéntico al schema probado en test.

Beneficios de Control de Versión

Almacenar archivos XML de schema exportados en sistemas de control de versión (Git, SVN, etc.) proporciona varios beneficios. Puede rastrear cambios en definiciones de schema a lo largo del tiempo, revertir a versiones anteriores si surge un problema y colaborar con otros desarrolladores en cambios de schema. El formato XML basado en texto funciona bien con herramientas de diff y fusión.

Importancia para el Examen

El examen puede hacer preguntas sobre cómo mover custom schemas entre entornos o cómo implementar control de versión para schemas. Entender el proceso de exportación/importación y su formato de archivo XML es conocimiento esencial.