1 Introducción

Perfuse mueve mensajes clínicos entre sistemas que nunca fueron diseñados para comunicarse entre sí. Un laboratorio envía resultados en HL7 v2; el sistema de gestión de prácticas los espera con posiciones de campo diferentes, un identificador de paciente diferente y un acuse de recibo dentro de cinco segundos. Algo tiene que estar en el medio, y ese algo es un motor de integración.

Este manual describe lo que Perfuse hace, cada opción que acepta y —donde una decisión no es obvia— por qué funciona de esa manera.

1.1 Para qué sirve Perfuse

Una interfaz única entre dos sistemas clínicos suele costar decenas de miles, con un 15% al 20% más cada año en mantenimiento. Gran parte de ese costo no es el trabajo; es que el trabajo requiere alguien que haya trabajado con HL7 antes, y la mayoría de las prácticas no emplean a uno.

Perfuse está diseñado sobre la suposición de que la persona que lo configura tiene un problema que resolver y no tiene experiencia previa con HL7. Esa suposición se muestra en lugares específicos:

• Todo es configurable desde la interfaz web. Una característica accesible solo desde una terminal o un archivo editado a mano se considera un defecto, no una elección de diseño.
• Los mensajes se pueden rastrear paso a paso, mostrando qué leyó cada paso, qué cambió, qué omitió y por qué.
• Se puede generar tráfico de prueba que coincide con la forma de una fuente real sin contener ninguno de sus datos.
• Un canal se puede proponer a partir de un solo mensaje de muestra, con una declaración explícita de lo que el mensaje de muestra no puede decir.
• Antes de reemplazar un motor existente, su salida y la de Perfuse se pueden comparar mensaje por mensaje, con las diferencias agrupadas por campo.

1.2 Qué hay en él

Todo lo siguiente está en el mismo binario. Cada línea nombra el capítulo que lo cubre.

• Formatos. HL7 v2, FHIR R4, R4B y R5, DICOM, X12 (837, 835, 270/271, 276/277, 834, 278, 275), C-CDA y CDA, HL7 v3, NCPDP Telecommunication y SCRIPT, SMART Health Links y Cards, delimitados y sin procesar. Consulte formatos de mensaje.
• Conectores. 28 tipos de fuentes y 32 tipos de destinos, entre ellos MLLP, archivos, SFTP, bases de datos, DICOM, Kafka, AMQP 1.0, MQTT, IBM MQ y almacenamiento y mensajería de AWS, Azure y Google Cloud. Consulte la referencia de fuentes y la referencia de destinos.
• Cambiar mensajes. Filtros, once pasos de transformación declarativos, JavaScript (incluido el dialecto de Mirth) y Lua, tablas de asignación compartidas y conjuntos de códigos, y sugerencias de asignación. Consulte filtrado y transformación.
• Entregarlos. Una cola ordenada y duradera por destino, reintentos, cartas muertas que conservan el mensaje y acuse de recibo enviado después de la entrega. Consulte entrega y acuse de recibo.
• Verificar su funcionamiento. Paneles de control, paneles de control de equipo, un mapa de flujo, once tipos de alerta, métricas, seguimiento y un almacén de mensajes que encuentra los mensajes de un paciente en varios formatos. Consulte alertas, almacén de mensajes y depuración.
• Cambiar una interfaz en vivo de manera segura. Modo de sombra, contratos de alimentación, pruebas de canal y comparación de motor. Consulte pruebas.
• Dejar Mirth. Canales de Mirth, Open Integration Engine y BridgeLink explicados, traducidos y exportados de nuevo. Consulte migración.
• Pagadores y salud pública. Las cuatro API de CMS-0057, Da Vinci CRD, DTR, PAS, PDex y Plan-Net, CARIN Blue Button, un servicio de decisión opcional, eCR y ELR. Da Vinci CRD, DTR y PAS responden tanto a sus versiones 2.2.x como a sus versiones 2.1.0. Consulte CMS-0057.
• Quién puede hacer qué. SAML, OpenID Connect, LDAP, contraseñas, SCIM, TLS mutuo, seis roles, grupos de canales con un rol en cada uno, inquilinos, un servidor de autorización SMART, TEFCA y UDAP, y un registro de auditoría. Consulte seguridad.
• Ejecutarlo. Un binario estático para Linux, macOS y Windows, como un servicio, con una vista de flota de varios servidores. Consulte operaciones, la interfaz web, la línea de comandos y opciones de servidor.

1.3 Estándares y versiones

Qué versión de cada estándar implementa Perfuse y cómo se verificó. "Verificado" nombra la herramienta o referencia externa que juzgó el resultado; donde nada externo lo ha juzgado, dice así. Los resultados son de datos de prueba, no de un sitio de producción.

1.3.1 Mensajes y documentos

1.3.2 Guías de implementación de FHIR

1.3.3 Perfiles nacionales y europeos

Comprobado mediante la conversión de mensajes HL7 v2 publicados o inventados y la validación de cada recurso; los resultados completos y las razones de cada fallo se encuentran en la carpeta conformance/national del repositorio.

Ninguno de esto es una certificación. Perfuse no ha sido certificado por ONC, CMS, gematik, Nictiz, NHS England o cualquier otra entidad.

1.4 Qué reemplaza

Perfuse cubre el terreno ocupado por Mirth Connect y puede importar exportaciones de canales de Mirth directamente. El capítulo sobre migración describe qué se traduce limpiamente, qué necesita una decisión y cómo probar el resultado antes de cambiar.

Las diferencias que importan en el uso diario son depuración y silencio. En Mirth, ver qué hizo un transformador con un mensaje generalmente significa volver a implementar el canal con registro agregado. En Perfuse, cualquier mensaje grabado se puede reproducir a través de la configuración actual y inspeccionar paso a paso, sin tocar el canal en ejecución. Y donde una alerta de Mirth sobre "no hay tráfico" es un umbral fijo que es inútil en cualquier fuente que esté en silencio por la noche, Perfuse aprende qué aspecto tiene una semana normal para cada fuente y alerta en consecuencia.

1.5 Cómo leer este manual

Los primeros capítulos son conceptuales y vale la pena leerlos en orden: canales, flujo de mensaje, luego transformación. Todo lo demás se puede leer según sea necesario.

Los capítulos de referencia cerca del final enumeran cada clave de configuración, su tipo, si es requerida y su valor predeterminado. Esos capítulos se generan a partir de la fuente, por lo que no pueden describir una opción que no exista ni omitir una que sí exista. Si una clave aparece en un archivo de configuración y no en el índice, no es una clave de Perfuse.

1.6 Convenciones

La configuración es YAML. La mayoría de las claves son snake_case en el cable — max_message_size, idle_timeout — y este manual siempre proporciona la forma del cable, porque eso es lo que se escribe. Hay una excepción de larga data, dataType en un canal, que es camelCase; se documenta de esa manera en la referencia del canal y se acepta solo con ese deletreo.

Las referencias de campo en HL7 utilizan la notación habitual: PID-5 es el quinto campo del segmento PID, PID-5.1 su primer componente y PID-3(2) la segunda repetición del tercer campo. Una ruta escrita sin una repetición se dirige a todas las repeticiones (ver paths).

Las duraciones se escriben como un número y una unidad — 30s, 5m, 2h. Un número sin unidad no es una duración y se rechazará en lugar de adivinarse.

2 Introducción

Perfuse es un binario único con una interfaz web integrada. No hay un servidor de aplicaciones que instalar, no hay una base de datos que provisionar y no hay una consola de administración separada.

2.1 Ejecución

perfuse serve -channels ./channels -db ./perfuse.db -addr 0.0.0.0:8443 \
  -tls-cert ./cert.pem -tls-key ./key.pem

-channels es un directorio de archivos YAML, uno por canal. -db es un archivo SQLite que contiene mensajes grabados, usuarios y registros de auditoría; se crea si no existe.

Al iniciar por primera vez sin usuarios configurados, se crea una cuenta de administrador y su contraseña se escribe en el registro una vez. Esa contraseña no se puede recuperar después.

2.2 El primer canal

Un canal necesita un nombre, una fuente y al menos un destino. El más pequeño y útil recibe HL7 sobre MLLP y escribe cada mensaje en un archivo:

name: first-feed
dataType: hl7
source:
  type: mllp
  listen: "0.0.0.0:6661"
destinations:
  - name: to-disk
    type: file
    file:
      root: /var/spool/perfuse
      dir: incoming

Guarde eso como channels/first-feed.yaml y se recoge sin reiniciar.

Tres cosas sobre ese archivo son dignas de mención, porque son la forma de cada canal:

• El bloque de fuente es plano para MLLP. listen se sienta directamente en source, no dentro de un bloque source.mllp. Los transportes que necesitan más que una dirección — HTTP, SOAP, DICOM — tienen su propio sub-bloque, y esos se enumeran en la referencia de fuente.
• Un destino de archivo necesita tanto root como dir. root es el límite que las rutas se resuelven contra y no pueden escapar; dir es donde aterrizan los mensajes dentro de él.
• No hay transformación y no hay filtro. Ambos son opcionales, y un canal con ninguno simplemente pasa los mensajes.

2.3 Construir un canal desde la interfaz

Todo lo anterior se puede hacer desde la interfaz web en su lugar, y para un primer canal, esa es la mejor ruta porque el formulario no le permitirá producir un archivo que no se cargue.

El constructor ofrece tres formas de entrada:

1. Desde un mensaje que alguien le envió. Pegue la muestra que el laboratorio o el proveedor envió por correo electrónico. Perfuse lo lee y propone un canal, junto con tres listas separadas: lo que muestra la muestra, lo que se ha adivinado y lo que ninguna muestra puede decirle. Esto se describe en pruebas.
2. Desde algo que ya funciona. Un conjunto de canales completos que solo necesitan sus direcciones llenas.
3. Desde nada. Un formulario en blanco. Disponible, pero es el más lento de los tres y el más fácil de equivocar.

2.4 Verificar que funcione antes de conectar nada

Se pueden hacer dos cosas antes de que exista el sistema de envío.

Enviar un mensaje a mano desde la interfaz — el remitente de mensajes acepta texto pegado y informa qué le sucedió, incluyendo qué destinos lo aceptaron y qué hizo cada transformación.

O generar tráfico de prueba. Si el canal ha manejado algún mensaje en absoluto, Perfuse puede aprender su forma y producir más mensajes como ellos, en las mismas proporciones, sin contenido original. Vea pruebas.

2.5 Qué hacer a continuación

• Canales explica qué es un canal y cómo encajan sus partes.
• Flujo de mensaje sigue un mensaje desde su llegada hasta su entrega, lo que es la forma más rápida de entender dónde poner un cambio.
• Alertas vale la pena configurar antes de que un flujo se ponga en vivo en lugar de después del primer incidente.

3 La Interfaz Web

Perfuse está diseñado con la suposición de que todo es posible desde el navegador, y una función que solo se puede acceder editando un archivo se trata como un defecto. Este capítulo es un recorrido por lo que hay detrás de cada parte de la navegación, organizado de la misma manera que la interfaz: por la pregunta que estás haciendo.

La barra lleva Panel de control y Canales directamente, porque esos son donde la mayoría de las sesiones comienzan y terminan. Todo lo demás está agrupado, y los grupos están nombrados según preguntas en lugar de subsistemas — no vas al "subsistema de auditoría", vas y descubres quién cambió algo.

3.1 Leyendo el encabezado

Hay cinco cosas en el encabezado que son fáciles de pasar por alto.

Cada vista tiene una dirección. La barra de direcciones sigue a la vista — #/channels, #/messages, #/settings — por lo que una recarga vuelve a ella, un marcador la abre, un enlace enviado a un colega lo lleva a ella, y el botón de retroceso se mueve entre vistas en lugar de salir de la consola. Una dirección que nombra una vista por encima de su rol abre el panel de instrumentos en su lugar.

Búsqueda, o ⌘K. Busca en canales, ajustes, mensajes y el manual, lo que significa que es más rápido que navegar — particularmente para un ajuste cuyo nombre solo recuerdas a medias.

Tema. Tres de ellos: Medianoche, Oscuro y Claro. Medianoche es casi negro y es lo que una pantalla de pared en una sala de servidores suele querer; Oscuro es un gris neutral más suave; Claro es para una laptop junto a una ventana. La elección se almacena en el navegador en lugar de en la cuenta, porque un tema es una propiedad de dónde se sienta alguien, no de quién es — el mismo operador quiere Medianoche en la pared y Claro en un tren. La preferencia de la máquina se consulta una vez, para elegir un valor predeterminado sensato la primera vez.

Idioma. La consola está disponible en inglés (orden de fecha del Reino Unido o de EE. UU.), alemán, francés, holandés, español, italiano, portugués, polaco, sueco, danés, noruego o finlandés, con fechas y números escritos de la manera que lo hace esa región. La elección se mantiene en el navegador y se utiliza el idioma del propio navegador hasta que se realice una elección. Las traducciones fueron realizadas por máquina y aún no han sido revisadas por hablantes nativos; el inglés es la referencia y el selector lo indica. El código, los mensajes, las cargas, los nombres de los canales y cualquier cosa escrita nunca se traducen. El manual se publica en los mismos idiomas en https://perfuse.health/manual/<language>/ (el propio Manual de este servidor es el inglés).

Manual. El documento que estás leyendo, servido por el servidor en ejecución. Es el mismo archivo que el binario puede escribir en el disco, por lo que siempre describe la versión que tienes frente a ti en lugar de la última versión lanzada.

3.2 Monitor — si está funcionando y qué sucedió

3.2.1 Panel de control

El estado de cada canal, el rendimiento y cualquier problema actual. Esta es la pantalla que debes dejar abierta.

3.2.2 Mensajes

Cada mensaje que llegó, en qué se transformó, por destino, y qué le sucedió. Se puede buscar, incluyendo mediante una expresión de filtro, por lo que "muéstrame los que provienen de este remitente que fueron rechazados" es una consulta en lugar de una tarde.

Un mensaje se puede reproducir desde aquí y volver a procesar a través de la *configuración actual* en lugar de la que estaba en vivo en el momento — lo que es cómo se confirma que una solución funciona contra el tráfico que la rompió. Vea el almacén de mensajes para saber qué se conserva y durante cuánto tiempo.

3.2.3 Cola

Qué está esperando ser entregado y por qué. Una cola que no se está drenando es la advertencia temprana más útil que produce un motor de integración, y vale la pena emparejarla con una regla de alerta para que nadie tenga que estar vigilando. Vea entrega.

3.2.4 Alertas

Qué se ha activado y cuáles son las reglas. Las reglas se editan aquí en lugar de en un archivo. Vea alertas.

3.2.5 Métricas

Rendimiento, latencia y tasas de error con el tiempo. Útil para preguntas de capacidad y, con más frecuencia, para paquetes de junta — lo que explica por qué el logotipo del sitio aparece en él si se ha subido uno.

3.2.6 SQL en FHIR

SQL en vistas de FHIR: elija un ejemplo o una vista guardada, o escríbala, ejecútela sobre el almacén de FHIR de este servidor (todos los pacientes o uno) o sobre recursos pegados, vea las filas con sus tipos y descargue CSV, NDJSON o Parquet. Guardar la mantiene para el punto final de FHIR $sql-run. Véase formatos de mensaje.

3.2.7 Medidas de calidad

Medidas de calidad digitales: elija un ejemplo o una Medida en el almacén de FHIR, o escríbala con criterios de FHIRPath. Elija un período de medición y un informe (resumen, resumen con listas de pacientes o un paciente) y evalúelo sobre el almacén de FHIR o recursos pegados. La pantalla muestra el recuento y los pacientes de cada población, la puntuación y las estratificaciones. Descargar MeasureReport guarda el resultado de FHIR, y Guardar en el almacén de FHIR mantiene la Medida para Measure/$evaluate-measure. Las Medidas en CQL son rechazadas: Perfuse no tiene un motor de CQL. Véase medidas de calidad digitales.

3.2.8 Mapa de flujo

Una imagen de cómo se mueven los mensajes en realidad: qué fuentes alimentan qué canales y qué destinos alcanzan.

Su valor no es decorativo. Cada propiedad acumula un canal que nadie recuerda haber encargado y un destino que nadie se dio cuenta de que todavía estaba recibiendo, y ambos son visibles aquí de una manera que no lo son en una lista de archivos de canales.

3.2.9 Paneles de dashboards

Un panel de control para cada tipo de persona que vigila las interfaces: Operaciones, Conexiones, Analista de interfaz, Autorización previa, Imágenes, Ciclo de ingresos, Laboratorio, Privacidad y seguridad, y un resumen de Departamento en palabras llanas. Los azulejos muestran recuentos, estados y tiempos, nunca un mensaje o un paciente, por lo que un panel de control puede ir a un gerente o una pantalla de pared sin ampliar quién ve los datos del paciente.

Cada persona abre en el panel de dashboard su grupo de directorio o función asignada. -dashboards dashboards.yaml los asigna:

groups: {PACS-Admins: imaging, Network-Team: connections}
roles: {viewer: manager}

Un grupo gana sobre un rol, y cualquier persona no emparejada se abre en Operaciones. Organizar azulejos oculta y reordena los azulejos, el selector de canal los filtra, y Guardar como mi vista lo mantiene como su propio panel de control hasta Restablecer.

Exportar a Grafana descarga el panel de control como JSON de Grafana sobre /metrics, con una variable de fuente de datos y un filtro de canal, para cualquier persona que necesite más que una configuración ligera. Los azulejos sin métrica detrás de ellos se dejan fuera, y la descripción de la exportación los nombra.

El azulejo de Conexiones verifica cada destino en capas de red. Busca el nombre, abre una conexión TCP, completa TLS donde se utiliza, y lee la última entrega y falla del destino desde el tráfico real. Cada falla dice qué significa, por ejemplo "rechazado: el motor del socio probablemente está detenido", "tiempo de espera: un firewall o un túnel de VPN que está abajo", o "un certificado de una autoridad que este servidor no confía". Nada se envía al socio, con una excepción: un registro de inmunización que no ha tenido tráfico durante siete días se le pide su prueba de conectividad de CDC connectivityTest, que no envía nada. Con -vpn tunnels.yaml el azulejo de túneles de VPN junto a él lee el estado de cada túnel de socio de AWS Site-to-Site VPN, una conexión de Azure VPN Gateway o strongSwan en este host, para que se pueda distinguir un tiempo de espera de un túnel que está abajo. También compara la configuración de IKE y IPsec de ambos lados, ya que la nube informa la nuestra y el archivo enumera la de ellos, y dice dónde no pueden estar de acuerdo. Hoja de conexión descarga la configuración de un socio lado a lado como Markdown para enviarla; nunca mantiene una clave precompartida. Las cifras que un panel de control necesita que no se han registrado aún se enumeran bajo No medido aún en lugar de dibujarse como azulejos vacíos.

Los paneles de dashboard del departamento calculan sus propias cifras en el servidor, y cada uno dice qué ventana y fuente cubre:

• Autorización previa: solicitudes de PAS decididas dentro de las 72 horas (expedidas) o 7 días (estándar) de CMS-0057, decididas con retraso, en espera y vencidas ahora, con el tiempo medio para decidir. También cómo se respondieron los servicios solicitados (aprobados, modificados, denegados, pendientes), como cada uno se encuentra ahora, en un plazo de 30 días.
• Imágenes: objetos recibidos por C-STORE por modalidad, y aquellos que no se entregaron. También el retraso de enrutamiento por canal (la mediana y el percentil 95), consultas C-FIND y fallos por canal de consulta, e informes de imágenes (un ORU cuyo OBR-24 es una sección de imágenes, o un MDM) que no llegaron a cada destino.
• Ciclo de ingresos: conjuntos de transacciones 999 aceptados, aceptados con errores y rechazados, y reclamaciones 277CA aceptadas y rechazadas (A3, A4, A6, A7, A8). También reclamaciones 835 coincidentes con el número de cuenta de paciente con 837 enviados a través de este servidor, y las razones de rechazo más comunes.
• Laboratorio: tiempo de entrega de resultados, desde la recepción hasta el reconocimiento del último destino, y resultados críticos (OBX-8 HH, LL, AA, > o <) que no llegaron a cada destino.
• Privacidad y seguridad: quién abrió mensajes, buscó pacientes o leyó autorizaciones previas en la consola durante 7 días, desde el registro de auditoría (abrir un mensaje se audita como message.read). También cada token de API en vivo y cuándo se utilizó por última vez; un token no utilizado durante 90 días se marca.

3.2.10 Compartir lo que un flujo realmente contiene

Perfil de este flujo informa qué llega en realidad: qué eventos de activación, qué campos están poblados y con qué frecuencia, qué formas toman los valores y qué códigos utiliza realmente el remitente. Esa última es generalmente el hecho más útil en él.

Un perfil se puede descargar y enviar a alguien más. Necesita un nombre y — obligatorio — qué sistema produjo el flujo, porque la pregunta que un desconocido hace de un perfil compartido es si describe su sistema, y un campo opcional haría que "Desconocido" sea la respuesta más común en cualquier colección compartida.

No lleva datos de paciente, y eso se verifica en lugar de asumirlo. Un perfil es estadístico: recuentos, tasas, longitudes, formas. Los valores se mantienen solo para campos que el estándar define como tablas de códigos, porque un valor de tabla de códigos no es identificable. Los valores de identificador nunca se enumeran.

Dos cosas se derivan de que sea una promesa en lugar de una esperanza. El servidor reconstruye el perfil a partir de los mensajes almacenados cuando lo exporta, en lugar de enviar el que se muestra en la pantalla — así que lo que sale del edificio fue ensamblado por el perfilador, que tiene una prueba que demuestra esta propiedad, y no por un navegador. Y la exportación se niega rotundamente si un perfil enumera valores para un campo que no es una tabla de códigos, nombrando el campo pero no los valores.

Un perfil que llega de otro lugar se verifica de la misma manera al entrar, por una razón diferente: fue producido por alguien cuyo cuidado es desconocido, y mostrar los identificadores de los pacientes sería una divulgación de este servidor. Importar uno no cambia nada — un perfil describe una fuente de alimentación, y qué hacer al respecto es una decisión separada.

3.3 Construir — cambiar lo que hace un canal y probarlo antes de que esté en vivo

3.3.1 Canales

El constructor de canales. Fuentes, destinos, filtros, transformaciones, scripts y pruebas, con el YAML generado mostrado junto al formulario mientras se trabaja — así que el archivo nunca es un misterio, y cualquier persona que prefiera el archivo puede leer a lo largo.

Consulte channels para saber qué son las partes y transformation para saber qué hacen los pasos.

3.3.2 Scripts

Un banco de trabajo para scripts, separado del constructor porque escribir un script y conectar un script son actividades diferentes.

Se ofrecen los siete ranuras — filtro, transformador, preprocesador, postprocesador, escritor, ciclo de vida y lector — y elegir la ranura correcta es importante, porque la ranura decide qué recibe el script y qué se espera que devuelva. Verificar un script como el tipo incorrecto no es una solución alternativa; compila algo diferente.

JavaScript, Lua y WebAssembly están disponibles. Consulte transformation.

3.3.3 Contratos

Expectativas sobre el aspecto que debe tener una fuente de datos, creadas y verificadas aquí, así como desde el perfuse contract. Consulte la línea de comandos.

3.3.4 Tablas

Tablas de búsqueda y conjuntos de códigos: los mapeos que convierten los códigos de un sistema en los de otro. Editables aquí para que agregar un código no sea una implementación.

3.3.5 Asistente de mapeo de inteligencia artificial

Propone asignaciones de campos con una puntuación de confianza para cada una, y se abstiene en lugar de adivinar. A pesar del nombre, no utiliza ningún modelo de lenguaje y no realiza ninguna llamada de red: las sugerencias provienen de reglas, nombres de campos y el contenido de la muestra, en este servidor. También propone un canal a partir de un mensaje de muestra único, y establece explícitamente qué no puede decirle la muestra. Esa segunda parte es la que lo hace confiable — una propuesta que pareciera completa invitaría a creer cosas que el mensaje nunca dijo.

3.3.6 Área de pruebas

Un bloc de notas para mensajes y transformaciones. Pegue un mensaje, aplique pasos, vea el resultado.

Nada se envía a ninguna parte una vez que la página se ha cargado, lo que es la razón por la que existe en esta forma: es seguro pegar algo real en ella, con la comprensión de que se queda en el navegador.

3.3.7 Sombra

Ejecuta tráfico a través de una configuración candidata junto con la configuración en vivo y informa las diferencias, para que un cambio pueda ser evidenciado antes de ser considerado confiable. La misma idea que perfuse compare, aplicada a un cambio en lugar de a una migración. Consulte pruebas.

3.4 Intercambio — los estándares que este servidor habla con otras organizaciones

3.4.1 Laboratorio de FHIR

Convierta HL7 v2 a FHIR, valide un recurso e inspeccione el resultado. Las muestras cubren admisiones, resultados de laboratorio, citas, notas clínicas, inmunizaciones y una visita informable. La validación incluye US Core, que es el perfil contra el que se escribe la regulación estadounidense, por lo que esto responde a "¿es lo que nos enviaron realmente conforme?" sin adoptar nada.

Informe de caso de salud pública construye el eCR eICR que un destino de informe de caso enviaría para el mensaje. Muestra qué código de activación hizo que la visita fuera informable, qué marcó el informe como faltante y el documento en sí. Un mensaje con nada informable obtiene la razón en su lugar. Nada se envía desde aquí.

3.4.2 Suscripciones

Suscripciones de FHIR y si sus notificaciones están llegando: eventos, aceptados, en espera y la última razón por la que uno fue rechazado. Las suscripciones se crean mediante clientes de FHIR a través de la API de FHIR, no desde esta página, y las credenciales que proporcionaron al servidor nunca se muestran. Consulte formatos de mensaje.

3.4.3 Documentos

Documentos clínicos — CDA y la forma imprimible de un documento. Útil cuando lo que se intercambia es un resumen de alta en lugar de un mensaje.

3.4.4 Compartir documentos

El registro y repositorio IHE XDS.b iniciado con -xds: cuántos documentos, pacientes y conjuntos de envío contiene y cuántos fueron reemplazados; las direcciones del repositorio, registro, puerta de enlace XCA y MHD; una búsqueda de los documentos de un paciente en este registro o en otro de la comunidad (un registro ITI-18 o una puerta de enlace ITI-38, con un token para ello); y la publicación de un documento CDA a mano, con el tipo de instalación y el entorno de práctica que un documento no especifica. Vea formatos de mensaje.

3.4.5 Direct

Mensajería segura directa. Las direcciones Direct de este servidor enumeran todas las direcciones que un canal envía o recibe, con su certificado, cuando expira, los anclajes que confía y cualquier problema (un archivo que falta, un certificado expirado). El Libro de direcciones mantiene a los corresponsales y los certificados a los que se cifra su correo: pegue uno de su HISP, o Guarde con el certificado desde DNS; un certificado que no es para la dirección o su dominio es rechazado. Buscar un certificado en DNS pregunta sin guardar. Vea formatos de mensaje.

3.4.6 Enlaces de salud

Enlaces y tarjetas de salud SMART, para *Matar el portapapeles* de CMS. Recibir un enlace de salud SMART lee el enlace o código QR que un paciente muestra al llegar, verifica las tarjetas de salud dentro y lo envía a un canal. Compartir un registro de visita crea un enlace que este servidor hospeda, opcionalmente con un código de acceso, y un código QR para el paciente; Usar su resumen de paciente lo llena con el resumen de paciente internacional (ver formatos de mensaje) de la tienda FHIR de este servidor. Enlaces que hospeda este servidor los enumera con la frecuencia con la que cada uno se recuperó, cuándo caduca y los intentos de código de acceso restantes, y revoca uno. Verificar una tarjeta de salud SMART verifica la firma y el emisor de una tarjeta por sí solo. Consulte CMS-0057 para las opciones del servidor que necesita.

3.4.7 Imágenes

El archivo que mantiene este servidor cuando se ejecuta con -dicomweb-archive: recuentos de estudios, series, instancias y espacio utilizado, la dirección DICOMweb y el bloque de fuente de datos para un visor OHIF, y una búsqueda de estudio por nombre de paciente, ID, acceso y fecha realizada con la misma solicitud QIDO-RS que hace un visor. Un estudio se abre a sus series e instancias, y una instancia se descarga como un archivo DICOM. Nada se representa: Perfuse mueve las imágenes y un visor las muestra. Sin un archivo, la pantalla indica cómo activar one. Vea DICOMweb.

3.4.8 TEFCA

El registro de auditoría para el intercambio a través de una Red de Información de Salud Calificada, y las reglas de propósito de uso que lo rigen.

Dos transportes, en etapas genuinamente diferentes, y la pantalla dice cuál es cuál. Una bandera que cubra ambos estaría mal en cualquier dirección en la que se redondeara.

Se implementa FHIR facilitado y nunca ha hablado con un QHIN real. Sigue el Procedimiento Operativo Estándar de Sequoia Project vigente desde el 8 de marzo de 2026: descubrir los metadatos de UDAP del socio, verificarlos, registrar dinámicamente, obtener un token de acceso que lleva el propósito de uso y consultar. UDAP es una infraestructura de clave pública sobre OAuth 2.0 — una comunidad de confianza emite certificados X.509 a sus miembros, y un miembro se autentica firmando JWT con la clave privada y adjuntando la cadena de certificados.

La capa de seguridad se verifica contra la implementación de alguien más, que es la única verificación que vale la pena aquí. Un registro firmado por esta compilación se envió a un servidor de referencia en vivo y se rechazó con unapproved_software_statement — Untrusted: Certificate is not a member of community. Para producir esa respuesta, el servidor decodificó la solicitud, analizó la declaración de software como un JWT, verificó su firma, recorrió la cadena de certificados y tomó una decisión sobre la membresía. Es la diferencia entre ser rechazado en la puerta y recibir una carta ilegible.

Lo que queda no se puede hacer desde aquí. El certificado que prueba la membresía de la comunidad sale del proceso de incorporación de QHIN y no es algo que el software produzca. Hasta que exista uno, ningún intercambio con un socio real se completa.

Cómo pregunta un canal. Un destino de tipo tefca pregunta al conjunto de socios FHIR facilitado en Configuración, TEFCA (tefca.partnerFHIRBase) para cada mensaje de paciente: por identificador cuando el mensaje tiene uno (PID-3, o un identificador de paciente FHIR), de lo contrario por apellido con fecha de nacimiento, y nunca solo por nombre, porque una mala coincidencia con un nombre devuelve el registro de otra persona sin error. El destino establece el propósito de uso (tratamiento, pago, operaciones, salud pública, acceso individual); un propósito que el participante no declara se rechaza antes de que se envíe nada. Los propósitos se envían como códigos de propósito de intercambio TEFCA (T-TRTMNT, T-PYMNT, T-HCO, T-PH, T-IAS, sistema urn:oid:2.16.840.1.113883.3.7204.1.5.2.1), o con tefca.purposeCodes: hl7 como códigos de propósito de uso HL7 para comunidades que utilizan esos. El paquete encontrado es la respuesta del destino y se puede entregar a otro canal con results_to. Cada consulta, incluidas las rechazadas, está en el registro en esta pantalla, que nombra al socio.

Todo el camino, desde el descubrimiento hasta un token que el servidor FHIR del socio acepta, se prueba contra el servidor de referencia udap-dotnet (ver verificación).

No se implementa el intercambio de QHIN a QHIN más antiguo basado en los perfiles de IHE. Se rechaza un intento con un error que lo dice, y el rechazo se audita como un fallo. Eso es deliberado en lugar de estar pendiente de una limpieza: un intercambio simulado que informa de éxito pondría entradas en el registro de auditoría para intercambios que nunca sucedieron, y un registro que no está de acuerdo con lo que sucedió es peor que ninguno, porque el registro es lo que se cree.

En todo, los puntos de conexión utilizados para el intercambio provienen de la parte firmada de los metadatos de un socio, nunca del cuerpo del documento. Verificar una firma y luego leer los puntos de conexión de la copia no firmada sería una forma elaborada de confiar en la red: un atacante capaz de reescribir la respuesta deja el elemento firmado solo, apunta el punto de conexión del token a su propio servidor y recopila aserciones de cliente de todos los que verificaron la firma y luego ignoraron lo que cubría.

Se requiere un paquete de anclaje de confianza y su ausencia se rechaza al inicio. Comprobar los metadatos firmados de un socio contra el certificado que llegó dentro de él solo demuestra que una parte realizó ambos — un error que esta base de código ha cometido antes, en SAML, donde el verificador prefirió el certificado incrustado y autenticó a un atacante como administrador mientras todas las pruebas pasaban. Incluya los intermediarios en el paquete: un servidor UDAP solo necesita enviar su certificado hoja, y el servidor de referencia público hace exactamente eso.

3.5 Pagadores — reclamaciones, autorización previa, medicamentos y reglas del pagador de CMS

3.5.1 Reclamaciones y autenticación

Construya un anexo de reclamaciones X12 275 en el formulario 006020 que adopta el CMS-0053-F, a partir de un C-CDA pegado o un PDF, TIFF o JPEG subido, y véalo leer de nuevo. Lea un 275 y descargue el documento interior. Convierta una decisión X12 278 en una respuesta de reclamación Da Vinci PAS ClaimResponse. Nada en esta página se almacena o envía. Vea formatos de mensaje para saber de qué se construye el 275 y qué no hace.

3.5.2 Medicamentos

El formulario de medicamentos cargado con -formulary, y las dos normas NCPDP respondidas desde él. Formulario enumera los planes y los medicamentos con su nivel y requisitos, y dónde se encuentran la API de formulario de medicamentos Da Vinci US pública y los puntos de conexión NCPDP. Verificación de precios (RTPB) asigna un precio a un medicamento para un miembro como lo haría una solicitud de beneficio de prescripción en tiempo real de un prescriptor: el estado de cobertura, las restricciones en palabras con sus códigos, la participación del miembro y la del plan, y las alternativas más baratas. Autorización previa (ePA) envía una iniciación de SCRIPT al punto de conexión propio de este servidor, muestra el conjunto de preguntas como un formulario, envía las respuestas y muestra la decisión; a continuación, cada caso con su estado y si se ha notificado al prescriptor, las respuestas del caso, un botón para enviar nuevamente una decisión no enviada y las cifras de medicamentos que propone el CMS-0062-P. Véase CMS-0057.

3.5.3 CMS-0057

El lado del pagador de la regla de interoperabilidad y autorización previa de CMS, como cinco herramientas:

• Las cuatro API: si Patient Access, Provider Access, Payer-to-Payer y Prior Authorization están listas en esta instancia, y qué es lo que cada una todavía necesita.
• Cola de revisor: las solicitudes de PAS que esperan a una persona, primero las más próximas, con los documentos enviados para cada una; aprobar, denegar o certificar menos unidades. Consulte la cola de revisor.
• Reclamaciones a CARIN BB: un 837 y su 835 convertidos en paquetes de botón azul CARIN.
• Autorización previa a PDex: una respuesta de PAS convertida en una autorización previa de PDex.
• Métricas de autorización previa: la página de métricas de autorización previa pública anual, vista previa a partir de un CSV de decisiones.

Las conversiones no almacenan nada y no envían nada.

3.5.4 Red alineada con CMS

Preparación para el Marco de Interoperabilidad de CMS: cada uno de sus 26 criterios, agrupados como los agrupa CMS, con lo que proporciona Perfuse, whether se encuentra aquí, la configuración que lo activa y qué debe hacer la organización. Los recuentos en la parte superior filtran la lista. Vea CMS-0057.

3.6 Administrar — quién puede hacer qué, y cómo se configura este servidor

3.6.1 Usuarios

Cuentas, roles (monitor, viewer, operator, editor, admin) y grupos de canales. Los grupos de canales de cada persona se editan en el lugar en la lista; vacío significa todos los canales, y lab=editor, adt da un rol diferente en un grupo. Un administrador limitado a algunos grupos solo ve a las personas de esos grupos. El encabezado muestra sus propios grupos junto a su rol cuando tiene alguno. Vea seguridad.

Credenciales de máquina también están aquí. Un token es para una máquina en lugar de una persona: no caduca y no se ve afectado por nadie que cierre la sesión, lo que es lo que un servidor que sondea a su vecino necesita. Solo se almacena un hash, por lo que un token se muestra una vez cuando se crea y no se puede recuperar — una base de datos robada no produce un token utilizable. Darle el rol más bajo que haga el trabajo.

Con MCP activado, la sección también muestra la dirección a la que se conecta un agente de inteligencia artificial, una configuración de cliente para copiar y cada herramienta con el rol que necesita; emitir un token con Dejar que un agente de inteligencia artificial actúe con él le da el ámbito mcp:write. Vea seguridad.

3.6.2 Inquilinos

En un servidor compartido, la lista de organizaciones del operador de la plataforma: cada una con su recuento de canales y tamaño almacenado junto a sus límites (canales, mensajes por minuto, almacenamiento), que se establecen en el lugar. Solo se muestra al rol de la plataforma. Vea seguridad para saber qué hace cada límite.

3.6.3 Certificados

Los certificados TLS en uso y cuándo caducan. Las fechas de caducidad son el punto: un certificado que caducó un domingo es una clase de interrupción que es completamente prevenible y rutinariamente no se previene.

3.6.4 Actividad

Quién cambió qué, y cuándo. Cada cambio de configuración se registra, lo que es lo que hace que "empezó a fallar el martes" sea respondible.

3.6.5 Protección de datos

Las solicitudes de una persona bajo el GDPR y el GDPR del Reino Unido, las retenciones legales, el registro de eliminación, la retención y el registro de actividades de procesamiento; solo administradores. Consulte protección de datos.

3.6.6 Flota

Cada instancia de Perfuse en una página.

Mirth vende esto como un producto separado; aquí es un archivo de configuración y un token de solo lectura. La razón por la que vale la pena tenerlo es estrecha e importante: un servidor muerto no se parece a uno silencioso. El panel de un instancia única no puede decirle que un segundo sitio dejó de informar, y una vista de flota puede.

3.6.7 Migrar

Coloque una exportación de canal de Mirth u OIE y vea cuántos de sus canales funcionarían aquí sin cambios. El mismo análisis que perfuse explain y perfuse translate, sin necesidad de una terminal. Consulte migración.

3.6.8 Configuraciones

Cada configuración que tiene el servidor, con un control para cada una — incluyendo aquellas que tradicionalmente solo viven en un archivo. Cada una indica si tiene efecto de inmediato o necesita un reinicio, y si se ha establecido explícitamente o está en su valor predeterminado.

La configuración cubre cada opción de perfuse serve que activa una función: el punto de conexión FHIR y su versión, las API de pagadores, PAS y las reglas CRD, el puente X12 278, eCR, el servidor de autorización SMART, TLS y firma, métricas, flota y VPN. Están agrupados como FHIR, Pagadores, Salud pública, SMART, Seguridad, etc. Cada uno también se muestra con la bandera que corresponde.

Reiniciar desde la consola. Una configuración marcada como *Requiere reinicio* se guarda de inmediato, pero solo se lee cuando el servidor se inicia. Mientras alguna espera, un banner en la parte superior de la configuración los enumera con un botón Reiniciar el servidor (el editor de inicio de sesión y los archivos de configuración ofrecen el mismo botón después de guardar). Pide confirmación primero, porque cada canal se detiene durante unos segundos: cada uno finaliza el mensaje que está manejando, como lo hace cuando el servicio se detiene, y los remitentes vuelven a enviar lo que llega mientras tanto. La consola espera a que el servidor responda de nuevo y lee la configuración de nuevo. Solo un administrador puede reiniciar, y cada reinicio se registra en el registro de actividad como server.restart.

En Linux y macOS, el proceso se reemplaza con una copia fresca del mismo programa y argumentos, manteniendo su ID de proceso, por lo que systemd, launchd o un tiempo de ejecución de contenedor no ve nada suceder. En Windows, el servidor se inicia de nuevo dentro del mismo proceso, que mantiene un servicio de Windows bajo el administrador de servicios. Si el servidor no ha respondido después de dos minutos, la consola lo indica; la razón está en el registro del servidor.

Bandera y archivo de configuración. La primera vez que el servidor se inicia, las banderas que se le dieron se escriben en el archivo de configuración. A partir de entonces, el archivo tiene prioridad sobre las banderas, por lo que cambiar una configuración se hace en la consola (o en el archivo), no editando la línea de comandos del servicio. Una bandera que el archivo no menciona aún se registra cuando el servidor se inicia con ella. Quitar una bandera de la línea de comandos más tarde no desactiva su función: desactívala en la configuración.

SNMP tiene un panel debajo de la configuración: si el agente está respondiendo y en qué dirección, las redes que responde, cuántas trampas de alerta se enviaron o fallaron, y Descargar el MIB para el OID base en uso. Los valores se establecen en Monitoreo, SNMP.

Marcas también están aquí: un sitio puede establecer el nombre del producto, un eslogan, un color de acento y cargar un logotipo. El logotipo luego aparece en el encabezado, en la página de inicio de sesión, en el panel y en las pantallas de informes. Si no se carga ninguno, nada se sustituye — una instalación sin marca permanece sin marca en lugar de adquirir decoración.

3.7 Qué significan los colores

Cuatro registros, y cada uno dice algo diferente. La distinción vale la pena porque es la diferencia entre una pantalla que se puede leer a primera vista y una donde todo compite por la atención.

Texto plano es un hecho sobre cómo funciona Perfuse. La mayoría de la interfaz. Nada se colorea para indicar que es importante.

Verde significa que algo tuvo éxito hace un momento, porque de algo que usted hizo. Aparece después de una acción y no persiste.

Ámbar es una advertencia: vale la pena saber antes de actuar, y no es un error. Una función que no está activada, una configuración cuyos cambios se auditan, una conversión que aproxima en lugar de reproducir, un transporte que Perfuse maneja pero no puede verificar completamente. Ámbar es el color de "lea esto antes de continuar".

Rojo significa que algo está mal en este momento. Un valor que fue rechazado, una solicitud que falló, un certificado que ha caducado, una alerta crítica que se está disparando. Nada más lo usa.

Esa última regla es por qué una pantalla no se abre en rojo. Rojo es el único color que lleva una instrucción — detener, y puede ser algo que usted hizo — y una pantalla que lo gasta en decoración no tiene nada que decir cuando la entrada realmente está mal. Esto no siempre fue cierto: la pantalla de usuarios solía abrir con "el servidor envió una respuesta que no se podía leer" en cada instalación que no había configurado claves de paso, y la pantalla de configuración marcaba los valores auditados en el mismo color que uno rechazado. Una prueba en web/src/RedMeansWrong.test.ts ahora falla si una frase que describe algo ausente o aproximado se le da un estilo rojo.

Dentro de una caja de código, el vocabulario es diferente. Allí, rojo es un tipo de token — un nombre de segmento de HL7, un elemento de XML — y no lleva ningún juicio en absoluto.

4 Canales

Un canal es un flujo de mensajes: somewhere they come from, cambios opcionales y uno o más lugares a donde van. Es la unidad de configuración, la unidad de monitoreo y la unidad de implementación. Todo lo demás en Perfuse existe para servir a los canales.

4.1 Anatomía

Un archivo de canal tiene estas partes, en el orden en que surten efecto:

Además de varios que se aplican en todo el canal: scripts, shadow, contract, tables, attachments, group y enabled. Cada uno se encuentra en la referencia del canal.

4.2 Un origen, muchos destinos

Esta asimetría es deliberada y vale la pena entenderla desde el principio, porque es la fuente de confusión más común al venir de un motor diferente.

Un canal tiene exactamente un origen. Si los mensajes provienen de dos lugares, eso son dos canales. Intentar expresarlo como un canal produce una configuración en la que una falla en cualquier transporte se ve igual desde afuera, y donde el tráfico de las dos fuentes se mezcla en las estadísticas — así que una caída en uno se oculta por el otro.

Un canal tiene cualquier número de destinos, y son independientes. Una falla en uno no detiene a los demás, y cada uno tiene su propia cola, su propia política de reintento y su propio registro de entrega. Un mensaje que llegó a tres de cuatro destinos se registra como exactamente eso, no como un éxito o una falla.

4.3 Los destinos no son una cadena

Cada destino recibe el mensaje tal como estaba después de las transformaciones del canal. Un destino no recibe la salida del destino anterior.

Esto importa cuando un destino tiene sus propias transformaciones, lo que puede suceder. Esas se aplican solo a la copia de ese destino. Un error común es poner un cambio en el primer destino y esperar que el segundo lo vea.

Si genuinamente necesita una cadena — la salida de un flujo alimentando a otro — use un destino de canal, que envía a otro canal por nombre. Eso es explícito, aparece en el historial del mensaje como dos canales y se puede monitorear como dos cosas, lo que una cadena oculta no puede.

4.4 Nombramiento

El nombre es la identidad del canal en todas partes: en el archivo, en el almacén de mensajes, en las alertas, en el registro de auditoría y en la URL. Cambiarlo no es un cambio de nombre; es un nuevo canal, y la historia del antiguo canal se mantiene bajo el nombre antiguo.

group es separado y existe para organizar la interfaz. Un grupo no tiene efecto en el comportamiento, y agrupar canales no hace que compartan nada.

4.5 Habilitar y deshabilitar

enabled: false detiene un canal sin eliminarlo. Su configuración, historia y estadísticas se mantienen.

Un canal deshabilitado no es uno pausado. Su origen no está escuchando, así que un remitente que intenta conectarse obtiene una conexión rechazada en lugar de una conexión colgada. Para MLLP, ese es el comportamiento correcto — el remitente se pondrá en cola y reintenta — pero significa que el registro de errores del remitente se llenará, así que un canal deshabilitado no es un sustituto para organizar una interrupción con quien está enviando.

4.6 Dónde viven los canales

Un archivo YAML por canal, en el directorio dado por -channels. El nombre del archivo no es el nombre del canal; la clave name es. Se recomienda encarecidamente mantenerlos iguales, y nada los obliga.

Los archivos se vuelven a leer sin reiniciar. Un archivo que no se analiza se informa y la versión previamente cargada sigue funcionando, así que un error de sintaxis no puede sacar un flujo de trabajo del aire.

4.7 Cifrar el propio oyente de un canal

Un canal que escucha en un puerto es su propio servidor, y su TLS es separado del TLS en la interfaz web de Perfuse. Configurar uno no configura el otro. Para una fuente HTTP, los ajustes están bajo TLS y límites en la fuente.

Activar TLS solicita un certificado y una clave privada. Requerir un certificado de cliente lo convierte en TLS mutuo: el remitente debe presentar uno firmado por una autoridad que usted nombre, lo que es autenticación, por lo que un oyente con ella activada no necesita un token compartido — aunque tener ambos no es incorrecto.

La autoridad se solicita solo una vez que se solicita un certificado de cliente, y se omite del archivo hasta entonces. Un canal que nombra una autoridad que nunca se consulta se lee como si los remitentes estuvieran siendo verificados cuando no lo están.

Un oyente MLLP tiene los mismos ajustes bajo Cifrar este oyente, con una diferencia digna de mención: en MLLP, un certificado de cliente es la única autenticación disponible. No hay token ni encabezado, por lo que un oyente sin uno acepta mensajes de cualquier host que pueda llegar al puerto.

Dos límites se encuentran junto a él. Dejar de leer después de una duración, porque un remitente que abre una conexión y deja de escribir de otra manera mantiene la conexión abierta. Y mensaje más grande aceptado, en bytes, porque cero significa sin límite y el límite es entonces la memoria — un remitente que publica un gigabyte es rechazado en lugar de absorbido.

4.8 Validación

Un canal se verifica cuando se carga, y las verificaciones son rechazos en lugar de advertencias donde la alternativa sería un canal que se ejecuta y hace algo incorrecto.

Ejemplos de cosas rechazadas directamente: un destino sin tipo, una transformación que se dirige a una ruta que no puede existir en el tipo de datos declarado, un modo de reconocimiento que el transporte de origen no puede entregar, y una receta de la lista II con recargas.

La distinción que Perfuse intenta mantener es que cualquier cosa que produzca un resultado incorrecto plausible se rechaza, y cualquier cosa que sea inusual se permite y se informa. Un canal que no puede estar incorrecto es más valioso que un canal que comienza.

5 Flujo de mensaje

Este capítulo sigue un mensaje desde el momento en que llega hasta el momento en que se entrega o se abandona. Conocer este orden es la forma más rápida de determinar dónde pertenece un cambio y por qué algo no está sucediendo.

5.1 El orden de los eventos

1. Llegada. La fuente acepta los bytes. Para un transporte de flujo, esto incluye la desenmarcación — encontrar dónde termina un mensaje y comienza el siguiente.
2. Analizar. Los bytes se convierten en un árbol según el tipo de datos (dataType) del canal. Un mensaje que no se puede analizar se detiene aquí y se registra como un error de análisis.
3. Registrar. El mensaje se escribe en el almacén de mensajes tal como se recibió, antes de que algo lo modifique. Esto es lo que hace posible la reproducción y el procesamiento nuevamente.
4. Filtrar. Si el canal tiene un filtro (filter), decide si aceptar el mensaje. Un mensaje rechazado se registra como filtrado, lo que es un resultado normal y no un error.
5. Transformar. Las transformaciones (transformations) del canal se ejecutan en orden, cada una contra el resultado de la última.
6. Distribuir. Cada destino recibe una copia del mensaje transformado, aplica sus propias transformaciones si las tiene, y entrega.
7. Registrar el resultado. Por destino: entregado, en cola, fallido o filtrado.
8. Confirmar. Si la fuente espera una confirmación, se genera y se envía. Por defecto, esto sucede aquí, después de la entrega — véase a continuación.

5.2 Cuándo se envía el reconocimiento

Este es el ajuste más importante en un canal, porque decide qué se le promete al remitente. Es ack.when, y tiene dos valores.

on_delivery es el valor predeterminado. El reconocimiento se envía solo después de que todos los destinos habilitados hayan aceptado el mensaje. Un reconocimiento positivo significa, por lo tanto, que los datos realmente llegaron a algún lugar, lo que es la afirmación más fuerte que un motor en el medio puede hacer honestamente.

on_receipt reconoce tan pronto como el mensaje se analiza y se coloca en cola, antes de que se haya escrito ningún destino.

Perfuse utiliza on_delivery de forma predeterminada porque prometer la entrega y luego perder el mensaje es peor que ser lento. Bajo on_receipt, un mensaje que se ha reconocido aún puede perderse si el proceso muere con trabajo en cola — el remitente cree que está entregado, nada upstream lo volverá a enviar, y el único registro de que existió está en el propio almacén de Perfuse.

5.3 Cuándo elegir en recepción

El caso para ello es real, y se trata de los tiempos de espera. Un remitente MLLP que no recibe un reconocimiento en unos pocos segundos normalmente lo vuelve a enviar, por lo que un destino lento bajo on_delivery produce duplicados en lugar de retrasos. Si un destino es un archivo lento o un sistema que no está disponible regularmente, on_delivery acopla el tiempo de espera del remitente al peor caso de ese destino.

El intercambio es explícito: on_receipt transfiere el riesgo de duplicados a pérdida. Elegirlo significa aceptar que un mensaje confirmado puede perderse en caso de fallo, y es recomendable emparejarlo con alertas de profundidad de cola para que se note si una cola ha dejado de drenar. Consulte alertas.

5.4 Dónde se registra el mensaje

Antes del filtro, y por lo tanto antes de cualquier transformación. Tres consecuencias:

• Un mensaje que el filtro rechazó sigue estando en el almacén. Puedes ver qué llegó y confirmar que el filtro estaba en lo correcto.
• La reproducción y el procesamiento nuevamente siempre comienzan desde lo que realmente llegó, no desde una versión parcialmente transformada.
• Un cambio en las transformaciones puede probarse contra tráfico histórico real, porque el original sigue estando allí. Consulta testing.

La forma transformada también se registra, por destino, junto con el resultado. Así que la tienda contiene lo que llegó, lo que se envió y qué sucedió — que es lo que una investigación necesita.

5.5 Falla en cada etapa

La asimetría importante: una falla de análisis es permanente y una falla de entrega generalmente no lo es. Reintentar un mensaje que no se puede analizar nunca ayudará, así que no se reintenta. Reintentar un destino no accesible generalmente sí ayudará, así que se reintenta.

5.6 Orden

Dentro de un destino, los mensajes se entregan en el orden en que llegaron, y un mensaje que falla y entra en la cola mantiene su lugar — los mensajes posteriores esperan detrás de él en lugar de adelantarlo.

Este es el valor predeterminado correcto para los datos clínicos, donde una admisión seguida de un alta entregada en el orden incorrecto es peor que si ambos se retrasan. También significa que un mensaje dañado puede bloquear una cola, lo que explica por qué la profundidad de la cola vale la pena alertar sobre ella.

Entre destinos no hay garantía de orden, porque son independientes. Dos destinos no necesariamente recibirán el mismo mensaje al mismo tiempo, y uno rápido puede estar varios mensajes por delante de uno lento.

5.7 Concurrencia

Una fuente puede manejar varias conexiones al mismo tiempo, limitadas por max_connections. Los mensajes de diferentes conexiones se procesan de forma concurrente.

Esto significa que el orden de llegada de dos mensajes enviados simultáneamente a través de dos conexiones no está definido y no puede estarlo — llegaron genuinamente al mismo tiempo. Un remitente que necesita orden debe usar una conexión, lo que es lo que la mayoría de ellos hace.

6 Transformación

Las transformaciones cambian un mensaje. Son una lista, se ejecutan en orden y cada una ve el resultado de la anterior.

Las transformaciones de Perfuse son declarativas: cada paso nombra una operación y el campo al que se aplica. No hay lenguaje de scripting en la ruta ordinaria. Esta es una limitación deliberada y la justificación se encuentra en why not a script a continuación.

6.1 Los pasos

Cada paso también acepta description, que aparece en la traza y en la interfaz, y when, que hace que el paso sea condicional.

Un paso se escribe como el nombre de la operación con su propio bloque:

transformations:
  - description: Our record number, not theirs
    set:
      path: PID-3.4
      value: RIVERSIDE
  - copy:
      from: PID-19
      to: PID-3.1
      default: UNKNOWN
  - map:
      path: PID-8
      table:
        M: Male
        F: Female

6.2 Borrar, eliminar y la diferencia

clear deja el campo presente y vacío. remove lo elimina por completo.

Para HL7 esta distinción es real y llega al receptor. Un campo vacío dice "tengo este campo y no tiene valor". Un campo ausente no dice nada en absoluto. Algunos sistemas receptores tratan el primero como una instrucción para borrar su valor almacenado y el segundo como una instrucción para dejarlo solo — lo que es la diferencia entre eliminar una alergia registrada de un paciente y no mencionarla.

Si no sabes qué es lo que el receptor quiere, pregunta. Adivinar tiene un cincuenta por ciento de posibilidades de destruir silenciosamente los datos en el lado lejano.

6.3 Condiciones

when toma una expresión y el paso se ejecuta solo si es verdadera:

  - when: MSH-9.2 == "A08"
    set:
      path: EVN-1
      value: A08

Un paso cuya condición es falsa se registra como omitido, y esto se informa por separado de un paso que se ejecutó y no cambió nada. Esa distinción es el propósito del depurador paso a paso y se cubre en depuración: una condición falsa y un campo ausente parecen idénticos desde afuera y significan cosas opuestas.

6.4 Rutas

Una ruta se dirige a un campo: PID-5 es el quinto campo de PID, PID-5.1 su primer componente, PID-3(2) la segunda repetición de PID-3 y OBX(3)-5 el quinto campo del tercer segmento OBX.

Dos comportamientos dignos de conocer:

• set crea la ruta que se dirige, incluida la estructura intermedia. Esto es conveniente y significa que set nunca puede demostrar que un campo estaba ausente, ya que después del paso existe. Para probar qué sucede cuando un campo está ausente, use copy desde una ruta que no esté allí.
• Una ruta sin índice se dirige a todas las repeticiones y ocurrencias, al igual que en un filtro (donde PID-3.5 == "SS" es verdadero cuando alguna repetición es). En un mensaje con cinco segmentos OBX, set en OBX-5 cambia los cinco, y set en PID-3.4 cambia cada identificador en PID-3, incluido el número nacional. Para cambiar uno, proporcione su índice: PID-3(1).4, OBX(2)-5.

6.5 Errores

La mayoría de los pasos no tienen nada que falle. Establecer un valor, borrar un campo o copiar desde una ruta ausente con un valor predeterminado están definidos para todas las entradas.

date es la excepción, porque un valor que no es una fecha que reconoce no tiene una conversión correcta. Toma on_error:

• fail — el valor predeterminado. El mensaje se detiene y se registra como un fallo de transformación.
• keep — deja el valor original solo.
• clear — vacía el campo.

El valor predeterminado es fail porque una marca de tiempo que no se convierte silenciosamente es peor que un mensaje que no llegó. Una fecha en el formato incorrecto generalmente todavía parece una fecha, por lo que pasa la validación del receptor y aterriza en el registro como el día incorrecto.

keep es legítimo cuando el receptor tolera ambos formatos, y cuando se usa, la traza marca el cambio como deliberado para que no se lea como un paso que falló silenciosamente.

6.6 El orden es importante, y la traza lo muestra

Cada paso ve la salida del paso anterior. Dos consecuencias que atrapan a las personas:

• Un map después de un case ve el valor convertido por el caso, por lo que las claves de su tabla deben coincidir con la forma convertida. Una tabla de M/F después de un paso en minúsculas no coincide con nada, silenciosamente, porque un valor que no está en la tabla se deja solo.
• Un copy desde un campo que un paso posterior elimina todavía funciona, porque se ejecutó primero. El inverso no.

Ambos son visibles en la vista paso a paso, que muestra el mensaje completo después de cada paso en lugar de solo el cambio. Vea depuración.

6.7 Sugiriendo asignaciones y qué hacer con una sugerencia

El Asignador de inteligencia artificial propone asignaciones entre un conjunto de campos de origen y un conjunto de objetivos. Su comportamiento definitorio es que se abstiene: por debajo de su umbral de confianza, se abstiene en lugar de adivinar, porque una asignación equivocada confiada en un sistema clínico es peor que ninguna asignación en absoluto.

6.7.1 Dale algo de qué estar seguro

Un nombre por sí solo es una evidencia débil, incluso cuando coincide exactamente. PatientMRN contra PatientMRN puntúa 68, que se abstiene en el umbral predeterminado de 70.

The engine knows what an HL7 path means — it will tell you PID-7 is Date/Time of Birth and score your field name against that rather than against the string PID-7, which shares no characters with anything. A locally defined Z segment means whatever your site decided, so nothing is claimed about it.

Eso obtiene una asignación la mayor parte del camino. Para terminarla, proporcione ambas mitades:

• Valores de ejemplo para un campo de origen, después de un signo igual: ZPI-1 = MRN00412, MRN00998
• El tipo de valor que un objetivo mantiene, de la misma manera: PID-3.1 = mrn. Los tipos son mrn, npi, ssn, phone, date y email.

Con esos, el motor puede ver que los valores coinciden con el tipo del objetivo, y una sugerencia se basa en más que un nombre.

6.7.2 La aprobación es una asignación a la vez

Cada sugerencia tiene su propia casilla de aprobación. No hay una opción para "aceptar todo lo que supere el 80%", deliberadamente: el motor ya ha utilizado la confianza para decidir si ofrece la asignación y lo que queda es un juicio sobre este campo en esta fuente. Un número no es ese juicio.

Una abstención no se puede aprobar en absoluto. No tiene casilla, ni siquiera deshabilitada, y la pantalla dice que el motor no lo sabe. Si usted conoce la respuesta, asígnela manualmente — eso es un acto diferente al de estar de acuerdo con una sugerencia.

Una sugerencia por debajo de su umbral se muestra sin casilla tampoco, marcada como por debajo de él. Vale la pena leer — un casi acierto es a menudo la asignación que se deseaba, y ocultarlo dejaría preguntándose si el motor lo consideró — pero no es aprobable, porque su umbral es la línea que dibujó.

6.7.3 Dos cosas que hacer con lo que aprobó

Agregarlos a un canal convierte cada asignación en un paso de copia. Esto solo funciona donde la fuente es una ruta en el mensaje, como ZPI-1, porque un paso copia de un lugar en un mensaje a otro. Los pasos van al archivo del canal y surten efecto cuando se vuelve a cargar — nada cambia en el tráfico hasta entonces. La descripción de cada paso registra la confianza con la que se sugirió y que una persona lo aprobó, lo que lo hace responsable seis meses después.

Descargar como receta es la respuesta correcta para el caso más común: una asignación desde un nombre de columna, una clave JSON o un nombre de campo propio de un proveedor. Esas son asignaciones reales, y un canal no puede leer ese campo directamente, por lo que un paso no puede expresarlo. La receta registra las asignaciones aprobadas y se puede compartir.

6.8 ¿Por qué no un script

Mirth coloca un transformador de JavaScript en el centro de cada canal, y es el diseño más flexible disponible. Perfuse ofrece scripting — véase la clave scripts en la referencia del canal — pero no lo convierte en el camino ordinario, por tres razones que provienen de lo que sale mal en la práctica.

Un paso declarativo se puede inspeccionar. Perfuse puede decirle que un paso lee PID-5 y escribe PID-8, antes de ejecutarlo, y por lo tanto puede mostrar una traza a nivel de campo, advertir que un paso se dirige a una ruta que el tipo de datos declarado no puede contener y generar una reproducción por paso.

Un paso declarativo se puede razonar mediante la interfaz. El constructor puede ofrecer los campos que existen en el tráfico de este canal y un cambio en un paso se puede verificar contra mensajes históricos reales antes de guardarlo.

Y un paso declarativo no puede hacer algo no relacionado con el mensaje. Un script puede llamar a la red, leer el sistema de archivos o depender del momento del día. Cuando un canal que funcionó durante dos años comienza a producir una salida incorrecta, la causa que está fuera del mensaje es el caso más difícil de diagnosticar, y eliminar la posibilidad vale más que la flexibilidad que cuesta.

Donde una transformación genuina no se puede expresar de forma declarativa, use un script y acepte que la traza lo mostrará como un paso opaco.

6.9 Qué se permite que haga un script

Un script se le niega todo lo que esté fuera del mensaje a menos que se le conceda, y las concesiones están en la sección Scripts del constructor. Esto es deliberadamente diferente a Mirth, que da a cada script todos ellos — así que allí, un transformador puede comenzar a leer el sistema de archivos después de una copia y pegado.

Hay tres.

Lectura y escritura de archivos requiere que nombre los directorios que puede usar, y un canal que otorga acceso a archivos sin ellos se rechaza al cargar. Ese requisito es toda la diferencia entre el acceso a archivos y el acceso a archivos sin restricciones: otorgar acceso a archivos sin directorios una vez alcanzó todo el sistema de archivos, incluida la base de datos de Perfuse, que contiene hashes de contraseñas, la contraseña de la cuenta de servicio LDAP y el secreto del cliente OIDC. Crear un canal solo requiere el rol de editor, por lo que la escalada se completó en el momento en que un administrador inició el canal.

Consulta a una base de datos utiliza las conexiones configuradas en el canal. Un script con esto puede leer cualquier cosa que esas credenciales puedan.

Enrutamiento de mensajes a otros canales permite que un script envíe un mensaje a otro canal, lo que es cómo se hace posible un bucle entre dos canales.

Otorgar una capacidad a un canal sin scripts no hace nada, y el archivo generado omite el bloque completo en ese caso.

6.10 Manejo de una fecha que no coincide con su formato

Un paso de fecha convierte de un formato a otro, y la pregunta interesante es qué sucede cuando un valor no coincide con el formato que afirma.

El valor predeterminado es detener el mensaje, y es el valor predeterminado correcto: una marca de tiempo que no se convierte silenciosamente es aceptada en la corriente descendente y luego se lee incorrectamente, lo que es peor que un mensaje que falló ruidosamente y está sentado donde alguien puede verlo.

Dejar el valor como está lo pasa en su formato original. La corriente descendente ve entonces dos formatos en un campo, lo que es el fallo que el paso existía para prevenir — pero es la elección correcta donde el campo es opcional y un socio lo envía de forma inconsistente.

Vaciar el campo es honesto y mejor que un formato incorrecto, pero un receptor que requiere el campo rechaza el mensaje en su lugar.

6.11 Los lenguajes de scripting

Tres son aceptados, y cuál elegir depende en gran medida de si se está migrando. El valor se coloca en la clave language de un script:

JavaScript es el predeterminado, y un script sin marca se trata como JavaScript. Está aquí como una obligación de compatibilidad más que como una preferencia: los scripts de Mirth son JavaScript y un sitio que se mueve a través tiene miles de líneas de código. Esto incluye el soporte para E4X, una extensión obsoleta del lenguaje que los scripts de Mirth utilizan para XML y que debe traducirse antes de que algo se pueda analizar.

Lua (lua) es la mejor opción para aquellos que no están migrando. Un tiempo de ejecución más pequeño, sin cadena de prototipos para malversar y tablas con índices enteros que coinciden con la dirección de segmentos y campos de una manera más natural que la de JavaScript. Su biblioteca estándar es lo suficientemente pequeña como para enumerarla, lo que hace que su sandbox sea más fácil de confiar.

WebAssembly (wasm) no es un lenguaje, sino un módulo compilado, y el campo quiere los bytes de un archivo .wasm en lugar del código fuente. Úselo cuando la transformación ya existe en un lenguaje compilado o cuando es lo suficientemente pesado como para que el costo de tiempo de ejecución sea importante.

Su contrato es deliberadamente el más simple disponible: un módulo lee el mensaje en la entrada estándar y escribe su resultado en la salida estándar. Bytes de entrada, bytes de salida — lo que hace cada cadena de herramientas y lo que alguien que prueba un módulo en su propia línea de comandos ya tiene. La alternativa era una función exportada sobre memoria lineal, que es más rápida y requiere que cada autor de módulo esté de acuerdo sobre la asignación, la codificación de cadena y quién libera qué; para algo que se ejecuta una vez por mensaje, ese intercambio no vale la pena.

Cualquier cosa que un módulo escriba en el error estándar se convierte en líneas de registro, por lo que puede explicarse a sí mismo de la misma manera que un script que llama a logger.

6.11.1 Qué significa la salida

Las reglas son las mismas para los tres lenguajes en lugar de nuevas reglas por tiempo de ejecución, por lo que el comportamiento observable de un script — qué puede ver, qué puede hacer, cuánto tiempo puede tomar, qué significa un veredicto de filtro — se define una vez.

Para un transformador, preprocesador o escritor, una salida vacía significa que el mensaje no ha cambiado. Caer al final de un script deja el mensaje solo; tratar una salida vacía como "el mensaje ahora está vacío" descartaría tráfico por una cuestión técnica.

Los módulos WebAssembly se compilan cuando se carga el canal, no en el primer mensaje. La compilación no es gratuita — un módulo construido a partir de un lenguaje que trae su propio tiempo de ejecución puede tomar cientos de milisegundos — y pagar ese costo en el momento de la carga significa que el primer mensaje a través de un canal no es misteriosamente más lento que el resto.

6.12 Tablas de mapeo compartidas

La otra mitad del mismo problema: los códigos de sexo y las clases de pacientes de un sitio se traducen de manera idéntica en cada canal que los toca, y una tabla dentro de un canal es una tabla que solo ese canal puede usar.

# codes.codeset.yaml
tables:
  - name: sex-to-lab
    describes: the hospital's sex codes into the numeric codes the lab expects
    decided_by: Dave, during the 2019 migration
    decided_on: 2019-04-11
    source: the lab's interface specification, version 3
    entries:
      - from: M
        to: "1"
      - from: U
        to: "9"
        why: the lab has no 'unknown', and 9 is its 'not stated'

# in the channel
tables:
  - codes.codeset.yaml
transformations:
  - map:
      path: PID-8
      use: sex-to-lab

La procedencia es el punto. La mayoría de lo que hace que una interfaz sea difícil de mantener es que nadie sabe *por qué* un mapeo es de una determinada manera, y la persona que lo sabía se ha ido. Un mapeo con una razón puede ser debatido; uno sin razón se convierte en algo que nadie se atreve a cambiar y nadie se atreve a eliminar.

Las tablas se crean y modifican en Build → Tablas así como en el archivo. Guardar una tabla que está en vigor reinicia los canales en ejecución que cargan su archivo, por lo que el siguiente mensaje lo utiliza; un borrador no reinicia nada.

6.12.1 Versiones y fechas efectivas

Una tabla puede mantener varias ediciones bajo un mismo nombre, cada una con su propia version. La edición que utiliza un mensaje se elige cuando el mensaje llega: de las ediciones aprobadas cuyas fechas cubren ese día (UTC), la que comenzó más recientemente. Así, un cambio de código acordado para el primer día del próximo mes se ingresa ahora y se aplica automáticamente.

tables:
  - name: sex-to-lab
    version: "3"
    effective_from: 2026-11-01   # optional; empty means from the start
    effective_until: 2027-10-31  # optional; the last day it applies
    source_system: urn:local:hospital-sex
    target_system: http://terminology.hl7.org/CodeSystem/v2-0001
    entries: [...]

• status es approved (el predeterminado), draft (utilizado por nada) o retired

(conservado para el registro, utilizado por nada).

• Dos ediciones de un nombre con la misma versión, o dos ediciones aprobadas

que comienzan el mismo día, son rechazadas cuando se carga el archivo.

• Guardar una nueva versión sin fecha de inicio mientras otra está aprobada la fecha

desde hoy, por lo que reemplaza la que está en vigor. Una que solo había comenzado hoy es retirada, ya que dos ediciones que comienzan el mismo día dejan sin regla.

• Un paso de mapa utiliza su propio default y strict cuando el paso los establece;

de lo contrario, se utilizan los de la tabla.

• En la pantalla de Tablas, Mostrar versiones enumera cada edición con su estado,

quién la guardó y quién la aprobó, y Comparar con la versión en vigor muestra qué agrega, elimina y cambia una edición.

6.12.2 Firma

Con Configuración → Datos → Tablas de asignación "Los cambios en una tabla de asignación requieren la aprobación de una segunda persona" (data.tableApproval) activado, cada guardar es un borrador, y la persona que lo guardó no puede aprobarlo: alguna otra persona lo hace, opcionalmente dando el día en que entra en vigor. Una edición aprobada no se puede editar en el lugar; Nueva versión desde esta copia en la siguiente versión. Aprobar, retirar y eliminar un borrador se escriben en el registro de auditoría, y aprobar reinicia los canales en ejecución que cargan el archivo.

6.12.3 Valores sin tabla de mapeo

Cada valor que una paso de mapa buscó y no encontró se cuenta, por tabla, con los canales por los que pasó y cuándo se vio por primera y última vez. La pantalla de Tablas los enumera, en orden de frecuencia. Map it abre la tabla con ese valor ya agregado como fila; Dismiss lo elimina hasta que se vuelva a ver. Los valores más largos de 64 caracteres no se registran (no son códigos), y la lista mantiene lo que se vio dentro del período de retención de mensajes. La lista se mantiene en terminology.db junto a la base de datos principal.

6.12.4 Sistemas de códigos

Los sistemas de códigos publicados se pueden importar desde los archivos de sus propios editores, bajo Sistemas de códigos en la pantalla de Tablas (administradores) o con POST /api/terminology/import?format=… y el archivo como cuerpo:

Ninguno viene con Perfuse: LOINC, SNOMED CT, RxNorm y CPT cada uno tienen su propia licencia, y la pantalla pide al importador que confirme que la organización la posee (registrada con la importación). Los códigos importados se utilizan de tres maneras:

• una tabla que nombra source_system o target_system tiene sus entradas verificadas cuando

se guarda, y los códigos que no están en el sistema se enumeran en la edición;

• Buscar un código busca por código o por palabras en el nombre;
• el servidor FHIR responde CodeSystem/$lookup y CodeSystem/$validate-code

para ellos (ver las opciones del servidor FHIR). Los códigos ICD-10-CM se aceptan con o sin el punto.

Ediciones y clasificaciones nacionales. Una edición de SNOMED CT se importa desde su paquete RF2 completo: conceptos con su estado real, cada descripción activa, y los conjuntos de referencia de lenguaje. La edición se encuentra desde el paquete (el módulo nacional con la mayoría de los conceptos; edition lo nombra en su lugar) y se convierte en la URI de versión. language elige el término preferido de cada concepto (sv, da, nl, de, fr, en-GB, en-US ...; inglés de lo contrario), y se mantienen como designaciones el término preferido y el nombre completamente especificado de cada lenguaje: $lookup los devuelve, y su displayLanguage elige uno (de-CH se retrotrae a de). Las ediciones que Perfuse nombra (Internacional, Reino Unido, Alemania, Países Bajos, Suecia, Dinamarca, Bélgica, Irlanda, Noruega, Suiza, Estonia, España) se enumeran en GET /api/terminology/editions, los IDs de módulo no verificados contra una fuente publicada marcada como tal; cualquier otra edición se importa también, nombrada por su módulo.

Los archivos ClaML se leen en UTF-8, ISO-8859-1, ISO-8859-15 o Windows-1252, según su declaración XML. El título de cada categoría es su rúbrica preferida (términos anidados incluidos); un modificador (un quinto carácter para el sitio de una fractura, por ejemplo) hace que los códigos que agrega, con el título del modificador después del de la categoría, a menos que la categoría lo excluya; blocks=true importa capítulos y bloques también. Las columnas de la tabulación ICD-11 se encuentran por nombre, ya que su orden ha cambiado entre lanzamientos, y los guiones que muestran la profundidad se eliminan de los títulos. Un archivo delimitado toma delimiter (, ; | o tab), encoding (utf-8, iso-8859-1, iso-8859-15, windows-1252) y noHeader=true, con columnas numeradas desde 1. La consola ofrece ajustes para los archivos de la 5ª edición del ICD-10 del Reino Unido y OPCS-4 (TRUD), la tabla de etiquetas CIM-10 FR de Francia (ATIH) y una exportación ICD-10-BE; no todos los editores documentan sus columnas, así que compruébelas contra el encabezado del archivo.

Fechas efectivas. effective=YYYY-MM-DD importa una versión ahora y la utiliza a partir de ese día (ICD-10-GM, por ejemplo, cada 1 de enero): hasta entonces, una búsqueda que no nombra versión se responde con la versión ya en vigor, y la pantalla muestra la fecha.

ICD-11 de la OMS. Con un cliente registrado en icd.who.int (Configuración → Datos → Sistemas de códigos, serve -icd11-client-id y -icd11-client-secret; -icd11-release, 2025-01 por defecto), los códigos ICD-11 que no se importan se buscan en la API ICD de la OMS (codeinfo, luego el título de la entidad) y se mantienen durante un día. Un código postcoordinado (NC72.2&XK9K) se verifica completo, por lo que una combinación ICD-11 que no se permite se rechaza, y sus nombres de visualización cada parte ("Fractura del cuello del fémur (Derecha)").

ICD-11 sin enviar códigos. La OMS publica la misma API como un contenedor (whoicd/icd-api, gratuito, Intel y Arm). Ejecútelo en su propia red y proporcione su dirección (serve -icd11-url http://icd-api.local, o Dirección de la API de ICD en la misma configuración); no se necesita cliente y ningún código sale de su red. Probado contra ese contenedor (version 2.6.0, lanzamiento 2025-01 en inglés y francés).

7 Filtrado

Un filtro decide qué mensajes acepta un canal. Es una expresión en el canal, evaluada después de que el mensaje se haya analizado y registrado, antes de cualquier transformación.

filter: MSH-9.1 == "ADT" && MSH-9.2 in ("A01", "A03", "A08")

Un mensaje que el filtro rechaza se registra con el resultado filtrado. Eso es un resultado normal, no un error, y no genera una alerta ni produce un acuse de recibo negativo.

7.1 Filtrado no es lo mismo que fallido

Esta distinción es importante porque confundirlos puede ocultar un problema real.

Un mensaje filtrado fue correctamente rechazado: no era para este canal. Un mensaje fallido fue uno que este canal debería haber manejado y no pudo. Si ambos se registraran de la misma manera, un canal que comienza a fallar en todos los mensajes parecería exactamente como un canal que está filtrando la mayoría de su tráfico, lo que es el estado normal de muchos canales.

Por lo tanto, las estadísticas los cuentan por separado, las reglas de alertas los tratan de manera diferente y la interfaz los muestra en diferentes colores. Un aumento en los mensajes filtrados puede significar que el remitente ha comenzado a enviar algo nuevo; un aumento en los fallos significa que algo está roto.

7.2 Qué puede leer un filtro

Cualquier campo en el mensaje analizado, por los mismos caminos que utilizan las transformaciones. El filtro se ejecuta antes de las transformaciones, por lo que ve el mensaje tal como llegó — no como se enviará.

Ese orden es deliberado. Un filtro que lea valores post-transformación estaría decidiendo si aceptar un mensaje en función de los cambios realizados sobre la suposición de que fue aceptado, lo que es circular y produce canales cuyo comportamiento depende del orden de dos cosas que parecen independientes.

7.3 Expresiones

Comparaciones: ==, !=, y para números <, <=, >, >=.

Pertenencia: in ("A01", "A03"), que es más claro que una cadena de || y es la forma que produce el constructor.

Combinación: &&, ||, y paréntesis. Negación con !.

Ausencia: una ruta que no está presente se compara desigualmente con cualquier valor, incluida la cadena vacía. Para probar la ausencia explícitamente, compárela con absent. Esto es importante porque un campo ausente y un campo vacío son diferentes, como se describe en transformation, y un filtro que los trata de la misma manera aceptará mensajes que se escribió para excluir.

7.4 Un error en el filtro es una negativa

Si el filtro en sí mismo no puede evaluarse — una expresión malformada que pasó la validación, o una comparación que no se puede realizar — el mensaje se rechaza y el error se registra en su contra.

Rechazar en lugar de aceptar es la opción más segura de las dos, pero ninguna de las dos es buena, y el resultado se registra de manera diferente a una negativa de filtro ordinaria para que pueda activar una alerta. Un filtro que está generando errores en todos los mensajes está silenciosamente descartando toda la fuente de datos, y no debe parecer un filtro que esté funcionando.

7.5 Filtrar en la fuente cuando se pueda

Un filtro se ejecuta después de que el mensaje ha cruzado la red y sido analizado. Algunas fuentes pueden filtrar antes y más barato:

• Una fuente de corredor toma un selector, que filtra en el corredor. Los mensajes que este canal no quiere nunca cruzan la red en absoluto. En una cola compartida, esa es la diferencia entre leer cien mensajes al día y cien mil.
• Una fuente de base de datos decide qué devuelve su consulta.
• Un patrón de fuente de archivo decide qué archivos recoge.

Filtrar en la fuente es una decisión de rendimiento, no de corrección, y tiene un costo: un mensaje filtrado en el corredor nunca se registra en Perfuse, por lo que no aparece en el almacén de mensajes y no se puede inspeccionar más tarde. Si necesita poder demostrar qué envió el remitente, filtre aquí en lugar de allí.

7.6 Probar un filtro

Un filtro se puede verificar con tráfico histórico real antes de guardarlo. La interfaz informa cuántos de los últimos N mensajes registrados el filtro aceptaría, rechazaría y generaría errores — lo que es la forma más rápida de descubrir que una expresión que parece correcta no acepta nada.

La traza también muestra, por mensaje, qué campos leyó el filtro y qué valores encontró. Un filtro que rechaza todo de manera inesperada generalmente está leyendo un camino que no existe en esta fuente de datos, y la traza lo nombra.

8 Formatos de mensaje

El dataType de un canal decide cómo los bytes se convierten en un mensaje. Afecta el análisis, qué significan los caminos, cómo se escribe el mensaje nuevamente y qué transformaciones son válidas.

8.1 HL7 v2

El valor predeterminado, y lo que la mayoría de los ejemplos de este manual utilizan. Segmentos terminados por retorno de carro, campos por |, componentes por ^, repeticiones por ~.

Dos cosas sobre la codificación son dignas de conocer porque causan fallos silenciosos.

Los delimitadores no son fijos. Se declaran en MSH-1 y MSH-2 de cada mensaje, y Perfuse los lee desde allí en lugar de asumir tuberías. Un remitente que utiliza un separador de campo diferente se analiza correctamente.

La consecuencia es que un mensaje cuyos separadores han sido reemplazados — la mayoría de las veces por un procesador de texto o cliente de correo electrónico que sustituye por caracteres con apariencia tipográfica similar — se analiza perfectamente en campos que están todos mal. No se produce ningún error. Esta es la razón por la que el lector de ejemplo descrito en testing informa sobre el carácter de separador que encontró y se niega a expresar confianza cuando es inusual.

8.2 HL7 v3 y CDA

XML en lugar de delimitado. Las rutas son rutas de elementos y atributos en lugar de posiciones de campo.

En v3, un valor es casi siempre un atributo en lugar de texto de elemento. Una comparación que solo lee el texto de elemento informa que dos documentos son idénticos cuando la fecha de nacimiento, el género y todos los identificadores difieren. La comparación de Perfuse lee ambos, y esta es la razón: la alternativa tiene éxito silenciosamente.

Las opciones de hl7v3 están en la referencia de formato.

8.3 X12

Segmentos terminados por ~ convencionalmente, con delimitadores declarados en el segmento ISA. Al igual que HL7, se leen desde el mensaje en lugar de asumirlos.

La estructura de X12 es sobres dentro de sobres —intercambio, grupo funcional, conjunto de transacciones— y un solo intercambio puede contener muchas transacciones.

Por defecto, un intercambio es un mensaje. Todo el archivo obtiene un registro, un resultado y una fila en la interfaz, sin importar cuántas transacciones contenga.

8.3.1 El X12 XML de Mirth

Mirth Connect y Open Integration Engine muestran X12 como XML: una raíz X12Transaction (o EDIMessage cuando la entrada no comienza con ISA) que transporta los delimitadores como atributos, y un elemento por segmento y elemento llamado ISA.01, NM1.03.1, etc. Los canales y receptores construidos para Mirth leen y escriben esa forma. Perfuse lee y escribe la misma:

• x12: { arrives_as: xml } en un canal X12 toma ese XML y lo maneja como el X12 que representa (la elección Llega como del constructor);
• x12_as: xml en un destino envía el X12 como ese XML (la elección Enviar como X12 XML de Mirth del constructor);
• perfuse x12 xml [file] y perfuse x12 from-xml [file] convierten en la línea de comandos.

El formato se escribió a partir de la salida observada y el formato publicado de Open Integration Engine 4.6, y se verifica contra él: 25 intercambios generados y 4 ejemplos conservados salen byte por byte como los escribe OIE, y viceversa (ver verificación). Un DOCTYPE se rechaza, como en todos los XML que lee Perfuse.

8.3.2 Dividir un intercambio

Establecer split hace que cada conjunto de transacciones sea un mensaje por derecho propio, con su propio registro, sus propias métricas y su propia fila. Un operador que busca una reclamación encuentra una reclamación en lugar de un archivo de cuatrocientas.

Está desactivado por defecto porque activarlo multiplica todo lo que está aguas abajo —recuentos de mensajes, filas, umbrales de alerta— y un umbral ajustado para archivos que de repente cuenta reclamaciones no significa lo que solía significar. Eso debería ser una decisión que alguien tomó en lugar de un valor predeterminado que heredó.

8.3.3 Cuando los recuentos no suman

X12 declara sus propios recuentos —cuántos segmentos, cuántas transacciones— y la clave envelope dice qué hacer cuando no coinciden con lo que realmente está presente. Esos recuentos son el único mecanismo que tiene X12 para detectar que la mitad de un archivo de reclamaciones ha llegado.

warn existe para una situación real: el software de algunos socios ha generado recuentos incorrectos durante años en archivos de lo contrario completos, y un sitio que tiene que procesar esos necesita una forma de decirlo en voz alta en la configuración en lugar de desactivar la validación en general.

8.3.4 Transacciones que Perfuse lee como datos estructurados

Cualquier intercambio X12 puede ser enrutado, filtrado y dirigido por ruta. Estas transacciones se analizan además en campos con nombre, por lo que un canal puede preguntar qué decidió un pagador en lugar de qué elemento se encuentra en la posición cuatro.

Perfuse también construye la consulta de elegibilidad 270 y la solicitud de estado de reclamación 276, bajo Pagadores → Reclamaciones y autenticación o a través de POST /api/x12/eligibility/build y /api/x12/claimstatus/build. Ambas son las versiones HIPAA 5010 (005010X279A1, 005010X212), leídas y verificadas antes de ser mostradas, y ninguna se envía desde esa página: entregar una es el trabajo de un canal, donde se encuentran el socio comercial y sus credenciales.

8.3.5 Elegibilidad, y la regla de contenido de datos CAQH CORE

Un 271 es una lista de segmentos EB, cada uno un solo hecho: cobertura activa, o un copago de $25 para el tipo de servicio 30 en la red, o $800 del deducible individual restante. El lector los ensambla en la respuesta que quiere una recepción - "cobertura activa bajo Gold PPO 2000; copago en la red $25; deducible individual restante en la red $800" - y nombra un rechazo (un segmento AAA) en palabras, con lo que el pagador dice que hacer a continuación.

También verifica la respuesta contra la regla de contenido de datos de elegibilidad y beneficios CAQH CORE: para una consulta sobre cobertura de plan de beneficios de salud (servicio tipo 30), una respuesta activa debe llevar fechas del plan, el nombre del plan, copago, coseguro, deducible y deducible restante tanto dentro como fuera de la red, y los tipos de servicios básicos (1, 33, 35, 47, 48, 50, 86, 88, 98, AL, MH, UC). Cada uno se enumera como cumplido o faltante. Esta es la interpretación de Perfuse de la regla, útil para "¿por qué este pagador nunca nos dice el deducible?" - no es una certificación CORE, que los proveedores de pruebas autorizados por CAQH llevan a cabo.

8.3.6 Autorización previa

Perfuse implementa la autorización previa dos veces, a propósito.

El lado FHIR es lo que CMS-0057-F requiere que los pagadores expongan a partir del 1 de enero de 2027. El 278 es lo que los pagadores aceptan hoy, y la regla no lo reemplaza — Da Vinci PAS es en la práctica un mapeo sobre esta transacción, porque un 278 es lo que un sistema de gestión de utilidad habla. Un motor que solo lee la mitad FHIR puede hablar con los sistemas que existirán y no con los que existen.

Una respuesta 278 lleva el número de autorización, y ese es el campo para el que existe toda la transacción. Sin él, un servicio certificado no es facturable: la reclamación se envía sin número de autorización y se deniega por la falta de uno, lo que se lee aguas abajo como una denegación clínica.

Una denegación y una negativa a considerar no son lo mismo

Esta es la confusión más costosa en la transacción, y Perfuse informa sobre las dos por separado.

Ambos se leen como "no aprobado" para cualquiera que escanee, y las acciones correctas son opuestas. Apelar algo que nadie dictaminó no logra nada; volver a presentar un rechazo produce el mismo rechazo. El resultado analizado nombra qué sucedió — denied contra not-considered — y AAA04 lleva el propio consejo del pagador sobre si la solicitud es recuperable en absoluto.

La certificación parcial se informa como partially-certified en lugar de integrarse en la aprobación. Hay un número de autorización para facturar, así que cuenta como aprobado, pero la cantidad certificada no es la cantidad solicitada — y una práctica que reserva seis sesiones contra tres aprobadas lo descubre en la cuarta reclamación.

Un código de acción que Perfuse no reconoce se informa como unknown, no como pendiente. Pendiente se lee como "esperar", y esperar es la acción incorrecta para la mayoría de lo que podría ser un código no reconocido.

Un canal puede enrutarse en la decisión directamente:

filter: HCR-1 == "A3"

Converting entre los dos

Perfuse convierte un 278 analizado en una respuesta de reclamación Da Vinci PAS ClaimResponse, e informa sobre cada juicio que la conversión necesitó en lugar de solo el resultado. La conversión sigue tres reglas:

• No se actualiza ninguna decisión. La certificación parcial permanece parcial, y una solicitud que el pagador se negó a considerar no se convierte en una denegación. Ambas reducciones están disponibles en el mapeo obvio y ambas son incorrectas en la dirección costosa.
• No se inventa nada para llenar un campo requerido. Un evento certificado sin número de autorización se informa como tal, no se le da uno plausible — un número fabricado produce una reclamación que se deniega más tarde por una razón que nadie puede rastrear.
• Se utiliza una decisión llevada solo al nivel de línea. Un pagador que responde por servicio puede dejar el evento sin una decisión propia; leer solo el nivel de evento informaría que está pendiente, y una práctica espera una respuesta que ya tiene mientras la aprobación caduca. Donde las líneas no están de acuerdo, gana la menos favorable, porque un evento con una línea rechazada no es una aprobación.

Reducir a un vocabulario de tres estados — aprobado, denegado, pendiente — está disponible y es explícito sobre lo que descarta. Reducir una negativa a considerar produce "denegado" y dice en palabras que la acción correcta es una resubmisión corregida en lugar de una apelación.

Verificado contra PAS 2.2.1, no solo contra sí mismo

El ClaimResponse está diseñado según el perfil Da Vinci PAS 2.2.1 y se verificó con el validador oficial de HL7 cargado con el paquete PAS publicado. La primera versión solo había sido verificada por las propias pruebas de Perfuse, y el validador la rechazó con seis u ocho errores por recurso. Cada uno de ellos es algo que el punto de conexión PAS de un pagador también habría rechazado:

La salida corregida se valida sin errores para una certificación, una denegación y un pendiente. Las advertencias que permanecen son el validador diciendo que no puede cargar los sistemas de códigos X12, que X12 licencia. El número de autorización se lleva en reviewAction.number, donde el ejemplo propio de la guía lo pone, y en preAuthRef cuando la respuesta solo tiene uno.

El validador no es parte de make check, porque necesita Java y una descarga de la guía y sus dependencias. Lo que encontró se mantiene en una prueba en su lugar: cada regla que aplicó se afirma, por lo que un cambio que vuelve a introducir uno de esos errores falla.

La vista Reclamaciones y autenticación convierte una 278 pegada y muestra las decisiones, las notas y el recurso.

8.3.7 Adjuntos, y por qué necesitan un manejo especial

CMS-0053-F hace que el 275 sea un estándar HIPAA para adjuntos de reclamaciones, con cumplimiento requerido para el 26 de mayo de 2028. Lleva un documento — una nota operativa, un informe de imágenes, un formulario escaneado — vinculado a la reclamación que respalda.

El 277 es la otra mitad de la misma conversación. Un pagador recibe una reclamación, decide que necesita documentación, y envía un 277 solicitándola; el proveedor responde con un 275.

Un canal puede enrutarse en el código de estado directamente, porque STC01 es un compuesto y su segundo componente es el estado. Escrito en forma canónica, porque un componente se dirige con un punto y las dos notaciones no se pueden mezclar — STC-1.2 es elemento 1, componente 2:

filter: STC-1.2 in ("227", "233", "252", "287")

Esos son los códigos que inequívocamente significan que se quiere un documento. La categoría categoría en STC-1.1 no se utiliza deliberadamente por sí sola: R4 significa una solicitud de documentación en algunas guías de implementación y "reenviado a otro lugar" en otras, por lo que un filtro en la categoría sola pondría reclamaciones finalizadas en la cola para que alguien las persiga.

Dos identificadores deciden si un adjunto se asocia alguna vez con su reclamación, y ambos se informan: el número de control de adjunto, que el proveedor puso en la reclamación original para decir que se proporcionaría documentación, y el número de seguimiento, que coincide con la solicitud del pagador. Un adjunto que llega con ninguno de los dos se archiva y nunca se conecta a nada, mientras la reclamación envejece.

El formulario 006020, que es el que adopta la regla

CMS-0053-F adopta la versión 006020, y su 275 difiere del formulario 005010 de dos maneras que importan.

• La carga útil está en BDS, no en BIN. BDS01 nombra un filtro, ASC o B64. BDS02 es la longitud y BDS03 los datos.
• La carga útil es una entidad MIME, con encabezados que dicen qué es el documento y un cuerpo base64. Con B64 la entidad en sí es base64 también.

Perfuse desenvuelve la entidad y informa del documento que contiene, con su tipo de contenido y nombre de archivo. Los bytes que informa son exactamente los que el remitente envolvió. Una entidad que no se puede desenvolver deja la carga útil sin procesar, con una nota que explica por qué.

Construir un 275. Perfuse también construye adjuntos 006020X314: uno no solicitado para acompañar una reclamación, o una respuesta a una solicitud 277 de un pagador. La diferencia está en BGN01 02 frente a 11, y si TRN02 lleva el PWK06 de la reclamación o el TRN02 de la 277. Cada intercambio construido se analiza nuevamente antes de devolverlo, y la respuesta indica si el documento que contiene es el mismo que se introdujo.

La estructura proviene de las dos guías de acompañamiento publicadas para 006020X314: la guía esMD de CMS y la de UnitedHealthcare. No proviene del informe técnico X12, que X12 licencia y que este proyecto no posee.

• Donde las dos guías están de acuerdo, Perfuse las sigue.
• Donde difieren, satisface ambas si puede. CAT02 es HL para un documento HL7, que esMD utiliza, y IA para una imagen, que UnitedHealthcare utiliza.
• De lo contrario, envía el segmento opcional solo cuando se le da el valor: el identificador de reclamación REF*X1 de esMD y la fecha de servicio DTP*472 de UnitedHealthcare.

No hay validación contra el informe técnico. La guía de acompañamiento del socio gobierna.

8.3.8 Firmas electrónicas en adjuntos

CMS-0053-F también adopta un estándar de firma, en 45 CFR 162.2002(e): la Guía de implementación de HL7 para CDA Release 2, Firmas digitales y delegación de derechos, Release 1. Se aplica a las firmas que se ponen en la información de adjunto cuando se envía en una transacción de adjunto de HIPAA, a partir del 26 de mayo de 2028. Un pagador no puede pedir más de lo que establece la guía.

Perfuse firma un C-CDA de esa manera en su camino hacia un 275, y verifica las firmas de cada C-CDA en un 275 que lee.

• Qué se firma. Todo el documento excepto sus participantes legalAuthenticator y authenticator, para que cada firmante posterior deje intactas las firmas anteriores. La firma indica esto con una transformación de filtro XPath 2.0 que cualquier biblioteca de firma XML puede evaluar.
• Dónde va. En Base64 en sdtc:signatureText en el participante que firma, con una descripción de texto plano de una línea. El firmante es el autenticador legal del documento si tiene uno no firmado, de lo contrario es un nuevo authenticator.
• Qué establece. El certificado del firmante, la hora en UTC, un rol de la taxonomía de proveedores NUCC y un propósito de ASTM E1762. El propósito predeterminado es *Firma del autor* para un autenticador legal y *Firma de coautor* de lo contrario, como en el ejemplo de la guía.
• Cuánto dura. La guía pide XAdES-X-L, que lleva todo lo que un pagador necesita para verificar la firma años después sin llegar a la red. Eso es la ruta de certificación, una respuesta OCSP o CRL del CA, y dos sellos de tiempo de una autoridad de sellado de tiempo. Perfuse obtiene los datos de revocación de las direcciones en el certificado y los sellos de tiempo de -tsa-url.

Si algo de eso no está disponible, la firma todavía se crea y es válida. El resultado nombra la forma XAdES que alcanzó y dice qué lo detuvo antes de llegar a X-L: por ejemplo, un certificado auto-firmado (no hay CA para preguntar) o no hay autoridad de sellado de tiempo.

La clave es -signing-cert y -signing-key. Coloque los certificados CA después del certificado del firmante en el mismo archivo para que la ruta viaje con la firma. Para una firma que signifique lo que significa DSDR, el certificado debe nombrar al clínico, con su NPI, en lugar del servidor. La firma es una acción de administrador, como firmar cualquier documento.

La guía no nombra un espacio de nombres para sus propios elementos. Perfuse coloca digitalSignature, authorizedSigner y SignaturePurpose en urn:hl7-org:sdtc. También establece el propósito como un tipo de compromiso XAdES con el OID ASTM, que las herramientas XAdES entienden. La delegación de derechos, donde un delegado firma con una aserción SAML del firmante autorizado, no se produce, y una recibida se informa como no verificada.

El NPI del proveedor se verifica contra su dígito de verificación. Un pagador coincide un adjunto con su reclamación en parte con ese número, y un número mal escrito deja el adjunto sin coincidencia mientras la reclamación se deniega por falta de documentación.

La vista Reclamaciones y autenticación construye un 275 a partir de un C-CDA pegado o un archivo cargado, opcionalmente firmando el C-CDA, y lee uno con los hallazgos de cada firma. Nada en esa página envía nada: el intercambio se devuelve para ser entregado a través de un canal, que es donde pertenece el socio, las credenciales y el registro de auditoría.

8.3.9 Segmentos binarios

Un segmento BIN lleva bytes sin procesar, y los bytes sin procesar contienen delimitadores. Cada segmento X12 ordinario termina en el terminador de segmento, por lo que un analizador ordinario encuentra segmentos buscando un byte; un adjunto no se puede encontrar de esa manera. Un PDF que contiene un ~ se cortaría en piezas, y cada pieza es un segmento estructuralmente válido — por lo que el documento se trunca, cada segmento después de él está desalineado, y nada informa un error.

Perfuse lee el recuento de bytes que el segmento declara y toma exactamente esos bytes. Dos consecuencias dignas de conocer:

• Una longitud declarada que no coincide con los datos es rechazada, nombrando ambos números. La pregunta útil es si el recuento del remitente era incorrecto o si el archivo se truncó durante el tránsito, y solo los dos números responden a ello.
• BDS, el segmento binario 006020, mantiene su recuento en BDS02 y sus datos en BDS03. Fue rechazado hasta que se pudo confirmar a partir de una fuente publicada en lugar de recordarlo, y dos fuentes ahora lo confirman: la tabla BDS de la guía de esMD de CMS y la guía de UnitedHealthcare.

La guía esMD propia muestra un intercambio que declara 16 bytes para la misma carga útil de 53 bytes que su tabla cuenta correctamente como 53. Perfuse rechaza esa muestra, como debería. Una prueba mantiene tanto el ejemplo de la tabla como el error tipográfico de la muestra, por lo que un cambio en cualquier dirección es notado.

8.4 FHIR

8.4.1 En lo que se convierte un mensaje HL7 v2

El tipo de mensaje decide qué se produce, y cada conversión informa los juicios que necesitó como notas junto al paquete.

Cualquier otra cosa produce el Paciente y una advertencia que nombra el tipo que no se asignó.

Programación. Una reserva, una reprogramación, una cancelación y un no-show aterrizan en la misma Cita. Su identidad proviene de los números de la cita en SCH-1 y SCH-2, nunca del mensaje, por lo que una cancelación actualiza la reserva. La alternativa sería una segunda cita cancelada junto a una cita activa, lo que muestra al paciente reservado en un espacio que ya no existe.

• Estado. El estado de relleno en SCH-25 decide, y el evento de activación se utiliza solo cuando está vacío.
• Espacios bloqueados. Un espacio bloqueado no es una cita con un paciente y no produce ninguna.
• Hora de inicio. Se lee desde AIS, AIG, AIL o AIP primero, luego SCH-11, porque la versión 2.5 lo movió y las fuentes no se movieron todas con ella.
• Duraciones. Una duración en una unidad que Perfuse no reconoce se deja fuera, no se adivina.

Documentos. Las notas de texto (TX, FT, ST) mantienen sus saltos de línea, incluidas las líneas en blanco, porque una repetición en blanco en una nota es un salto de párrafo.

• Documentos incrustados. Un PDF, TIFF o JPEG (ED) incrustado se transporta byte por byte. El base64 no válido se rechaza en lugar de pasarse.
• Tipos. El tipo de documento en TXA-2 se mantiene como se envió y, donde hay un equivalente claro, se asigna el código LOINC que utiliza US Core.
• Firma. Una nota que nadie ha firmado es preliminary, y T11 hace que el documento sea entered-in-error.
• Sin contenido. Una notificación sin contenido (T01, T03 y otros eventos con números impares) no produce un DocumentReference. FHIR requiere contenido, y un archivo adjunto vacío parecería una nota mientras no dice nada.

Esto es lo que pide el criterio 14 del Marco de interoperabilidad de CMS: notas de gráficos y documentos clínicos devueltos como archivos adjuntos de FHIR.

Inmunizaciones. Una dosis nunca se informa como administrada cuando el mensaje dice lo contrario.

• Dosis rechazadas. Una dosis rechazada o no administrada (RXA-20 RE o NA) es not-done, con la razón de RXA-18.
• Eliminaciones. Una eliminada (RXA-21 D) es entered-in-error.
• Registros históricos. Un registro transcrito desde otro lugar (RXA-9 diferente a 00) no es una fuente primaria.
• Cantidades desconocidas. Una cantidad de 999 significa desconocida, no 999.
• Rutas y sitios. Cada dosis toma la ruta y el sitio del RXR después de ella, por lo que un mensaje con dos dosis no da a la segunda la ruta de la primera.

Entrada incómoda. Cada una de estas se informa en las notas en lugar de decidirse silenciosamente:

• Identificadores. PID-2 y PID-4, retirados después de la v2.7 pero aún enviados, se mantienen como PID-3. CX.7 y CX.8 se convierten en

Identifier.period. Una autoridad de asignación que lleva un OID ISO (AUSHIC&2.16.840.1.113883.3.879&ISO) se convierte en urn:oid:. Un código de tipo fuera de la tabla HL7 0203 se mantiene como texto, no etiquetado como tal.

• Fusiones. MRG en un evento de fusión (A40 y sus similares) envía también el registro retirado, inactivo, con Patient.link en ambos sentidos. En cualquier

otro evento, como un A08, no se fusiona nada y una advertencia indica que el identificador anterior sigue estando activo.

• Tiempos. Una hora de nacimiento en PID-7 se envía a la extensión patient-birthTime. Una marca de tiempo sin desplazamiento toma la zona horaria configurada,

de lo contrario, el desplazamiento en MSH-7 (v2 supone la hora local del remitente), de lo contrario, UTC. Una hora de nacimiento es la excepción: sin desplazamiento de cualquiera de los tres, se omite en lugar de etiquetarse como UTC, porque un desplazamiento incorrecto puede mover un nacimiento a otro día. birthDate se mantiene, y una advertencia indica que la hora se ha eliminado y que establecer una zona horaria para la fuente la mantiene.

• Resultados. Las repeticiones de un resultado de texto se unen con saltos de línea. Un resultado ED, o uno codificado cuyo valor es claramente Base64, se convierte en un

DocumentReference que la Observación señala en derivedFrom, ya que una Observación R4 no tiene un valor de adjunto. Un comparador SN de = se elimina como redundante; <> mantiene el texto, porque ninguna cantidad puede decir "no igual".

• Visitas. Un A08 con una fecha de alta (PV1-45) es un encuentro terminado. Una clase de paciente que falta o es desconocida es el sabor nulo UNK,

porque R4 requiere una clase.

• Segmentos Z se nombran en una advertencia, ya que no hay un mapa estándar para ellos.

• Names. When the sender splits a family name (XPN.1, XCN.2) into its parts - a surname prefix and a surname, the person's

own and a partner's, as Dutch and Flemish names are sent - family is the whole name and the parts go in HL7's family-name extensions (humanname-own-prefix, -own-name, -partner-prefix, -partner-name).

• Procedures. PR1 becomes a Procedure with status unknown, since an ADT does not say whether it was done or planned; the

anaesthetist (PR1-8) and surgeon (PR1-11) are performers with SNOMED CT roles. An OPS code also gets its SNOMED CT category from its chapter, by HL7 Deutschland's OPS-SNOMED-Category map, which ISiK requires.

8.4.2 Lo que agrega un sitio: el script de paquete

Un perfil nacional a menudo quiere lo que un mensaje HL7 v2 no lleva: el número IK de un hospital o el código ODS, qué nivel de contacto es una visita (ISiK), si un nombre dado es un nombre o una inicial (el nl-core holandés). Perfuse no adivina esos. El destino fhir tiene un bundle_script donde un sitio escribe ellos: JavaScript ejecutado en cada Bundle convertido, como bundle, antes de que se valide y envíe. Lo que el script deja es lo que se envía, comprobado como cualquier conversión, y un script que lanza una excepción falla el mensaje como cualquier transformador. La consola lo tiene debajo de *Agregar lo que sus sistemas saben* del destino.

destinations:
  - name: kis
    type: fhir
    fhir:
      url: https://fhir.klinikum.example/fhir
      version: "4.0.1"
      identifier_systems: {KLINIKUM-MUSTERSTADT: "https://fhir.klinikum-musterstadt.example/sid/patientennummer"}
      bundle_script: |
        bundle.entry.forEach(function (e) {
          if (e.resource.resourceType === "Organization" && e.resource.name === "KLINIKUM-MUSTERSTADT") {
            e.resource.identifier = [{system: "http://fhir.de/sid/arge-ik/iknr", value: "260326822"}];
          }
        });

perfuse fhir convert -bundle-script FILE ejecuta el mismo script, por lo que un sitio puede probarlo en sus propios mensajes primero. Dos ejemplos que funcionan están en el repositorio: examples/isik/bundle-script.js (IKNR, Kontaktebene, número de paciente de tipo MR, Diagnosetyp) y examples/nictiz/bundle-script.js (nombres y letras iniciales). Con ellos, los mensajes alemanes e holandeses inventados en conformance/national van de 18 a 42 de 47 recursos válidos contra ISiK y de 12 a 18 de 24 contra nl-core; lo que queda está en los mensajes o en el servidor de terminología, y se enumera allí.

El paquete pasa por el modelo de Perfuse en su camino de regreso, por lo que los cambios de un script se verifican y se escriben en la versión FHIR del destino. Los miembros que el modelo no tiene campo para se conservan como el script los escribió, dentro de los tipos de datos también.

8.4.3 Núcleo de EE. UU. 9.0.0 y USCDI v6

-us-core (y claim_us_core en un destino fhir) coloca un perfil US Core en meta.profile, pero solo en un recurso que ha sido verificado contra ese perfil y se ha encontrado que cumple. Uno que no cumple es aún convertido y enviado sin la reclamación, y una nota da la razón, como "US Core requiere un tipo de encuentro, y este Encuentro no tiene ninguno". Las verificaciones se transcriben desde US Core 9.0.0, la versión que el proceso de avance de normas 2026 de ONC aprueba para USCDI v6. Cubren Paciente, Encuentro, la observación y el informe de diagnóstico de laboratorio, Specimen, Practicante, Organización, Ubicación, Inmunización, DocumentReference, la condición y la alergia de diagnóstico de encuentro y la intolerancia.

Lo que el convertidor lleva, por clase de datos de USCDI v6:

No se transportan porque los mensajes v2 de estos tipos no los contienen o Perfuse no los asigna: Medicamentos, Procedimientos, Metas y Preferencias, Evaluaciones de estado de salud, Plan de atención, Historia de salud familiar, Dispositivos médicos (UDI), Información de seguro de salud, Signos vitales como un perfil distinto y Procedencia.

8.4.4 R4 en ambos sentidos

Un servidor FHIR que declara R4 acepta R4. Eso no era cierto de los Encuentros hasta esta versión. El servidor convirtió lo que sirvió a R4, pero leyó lo que recibió como si ya estuviera en su forma interna, por lo que un Encuentro R4 se rechazó con un 400. Lo mismo sucedió con cada paquete que la propia conversión de ADT de Perfuse produjo, porque cada uno lleva Encounter.class, que R4 escribe como un solo codificado.

Se descubrió la primera vez que algo publicó una ADT convertida en el propio servidor R4 de Perfuse. Una prueba ahora lo hace para cada tipo de mensaje asignado, y otra verifica que todo lo escrito como R4 se lea sin cambios.

8.4.5 Resumen Internacional de Paciente

GET /fhir/Patient/{id}/$summary, o GET /fhir/Patient/$summary?identifier=system|value, devuelve un Resumen Internacional de Paciente (HL7 IPS 2.0.0): un paquete de documento FHIR document cuya Composición enumera los problemas activos del paciente, alergias, medicamentos, inmunizaciones, resultados, signos vitales, procedimientos, dispositivos, enfermedades pasadas, historial social y planes de atención, cada uno con una narrativa legible. Es el registro breve que un clínico que nunca ha conocido al paciente lee primero, y el resumen que el Espacio Europeo de Datos de Salud intercambia entre países a partir de 2029.

Se construye a partir de lo que almacena la tienda FHIR, y nada se inventa:

• Los registros marcados como entered-in-error se omiten.
• Una condición resuelta se coloca bajo enfermedad pasada, no problemas.
• Una orden de medicamento que se detuvo o completó es historia, no un medicamento actual.
• Las tres secciones que requiere el IPS (problemas, alergias, medicamentos) siempre están presentes. Cuando una de ellas no tiene nada, la sección

lleva el motivo codificado unavailable y dice que el servidor no tiene información, "lo que no significa que no la haya". Una lista de alergias vacía nunca debe leerse como "no se conocen alergias".

• Los profesionales, organizaciones, medicamentos y ubicaciones a los que se refieren las entradas se incluyen, para que el documento se pueda leer por sí solo.

Access follows $everything: a token limited to one patient gets a 403 for another, and an identifier that matches two patients is refused rather than guessed. Only the IPS profile is built; asking for another profile is refused. The document Perfuse produces from its test records validates against the IPS 2.0.0 Bundle profile with the HL7 validator, with no errors. A record built from real feeds can still fail where the feed's own codes do (a display name the code system does not use, for example), because the summary passes the data on as it was received.

Intercambio → Enlaces de salud → Compartir llena el contenido con un resumen de paciente: escriba el id de FHIR del paciente y elija Usar su resumen de paciente, luego léalo y cree el enlace. Construirlo se audita como fhir.summary.

8.4.6 Resúmenes de transferencia para cuidados postagudos (PACIO)

When a patient leaves hospital for a nursing home, a rehabilitation unit or home health, the hospital's EHR sends a C-CDA: a transfer summary, a discharge summary or a CCD. Perfuse turns that document into the transfer summary PACIO's Transitions of Care guide describes (hl7.fhir.us.pacio-toc 1.0.0): one FHIR R4 document Bundle, US Core 8.0.1 inside, that the receiving facility's system can file without anyone reading XML.

• Cada una de las quince secciones de la guía está presente, cada una con su propio texto, en el orden de la guía: directivas anticipadas, alergias, salud conductual, estado funcional, inmunizaciones, instrucciones de alta, dispositivos médicos, medicamentos, plan de atención, problemas, procedimientos, motivo de derivación, resultados, historia social y signos vitales.
• Una sección que el documento no tenía se dice que está faltante, nunca se llenó. Sale vacía, con el motivo codificado unavailable y la oración "El documento de envío no tenía sección ...". Una sección de alergias vacía no debe leerse como "no se conocen alergias".
• Una sección que se transporta como texto solo mantiene su texto y no obtiene entradas. La prosa no se convierte en datos codificados. Estado funcional, salud conductual (la sección de estado mental de C-CDA), directivas anticipadas, dispositivos médicos, plan de atención, instrucciones de alta, motivo de derivación e historia social se envían de esta manera hoy; las notas lo indican para cada una.
• Las entradas codificadas se convierten en recursos por las mismas reglas que la conversión ordinaria: alergias (US Core AllergyIntolerance), problemas y diagnósticos de alta (US Core Condition, lista de problemas o diagnóstico de encuentro), procedimientos, inmunizaciones, resultados, signos vitales y medicamentos como una lista de medicamentos PACIO de MedicationStatements (104204-3, lista de medicamentos de alta, de una sección de medicamentos de alta; 104202-7, lista de medicamentos activos, de lo contrario).
• Signos vitales en la forma de FHIR. Una presión sistólica y una presión diastólica tomadas juntas se convierten en un panel de presión arterial (85354-9) con dos componentes, y un código más específico (peso corporal medido, 3141-9) también lleva el código de los perfiles de signos vitales de FHIR (29463-7), además del original.
• Quién y de dónde. El autor del documento se convierte en el autor de la Composición (un Practitioner, con el NPI cuando su dígito de verificación es válido), su custodio el custodio de la Organización, su encuentro que abarca la estancia que resume el resumen. Un documento sin persona como autor, o sin custodio, es rechazado: la guía requiere ambos, y Perfuse no pondrá un nombre en un registro clínico que nadie dio.
• La negación mantiene su significado. "No se conocen alergias" (una alergia negada a cualquier sustancia) se envía como SNOMED CT 716186003; una alergia negada a un medicamento es rechazada, porque FHIR no puede decirlo y el recurso diría lo contrario; un problema negado es refuted.

Tres formas de hacer uno:

• A channel: a cda destination with write: transfer posts each document's transfer summary to the FHIR server's

Bundle endpoint (url), or writes <document>.transfer.json to dir. In the channel builder: Emit › A PACIO transfer summary.

• The command line: perfuse fhir transfer [-authority OID=URI] [-out dir] <document.xml>....
• The console: Documents, turn on Also make a PACIO transfer summary, and read the document.

Verificado con el validador FHIR oficial contra el perfil de paquete TOC 1.0.0, en los ejemplos de C-CDA de HL7 (un resumen de transferencia, un resumen de alta y un CCD). El único error que informa está en la guía: cada signo vital coincide con ambas entradas de rebanada simple-observation y vital-signs del paquete, por lo que no puede evitarse mediante ningún remitente. Todavía no se ha realizado: convertir las entradas de las secciones de solo texto (estado funcional, estado mental, plan de cuidado, dispositivos) en recursos codificados, y la referencia de documento TOC de la guía que indexa un resumen de transferencia almacenado.

8.4.7 Suscripciones

Con -fhir-subscriptions, el punto de conexión FHIR envía notificaciones cuando se crea o cambia un Encuentro o una Cita. Sigue la guía de trabajo de suscripciones R5 Backport IG para R4, que es lo que utiliza el marco de interoperabilidad de CMS y la hoja de ruta de FHIR de TEFCA para notificaciones de citas y encuentros.

Un cliente crea una Subscription con el nombre de un tema y, opcionalmente, un filtro como Encounter?patient=Patient/123. Los temas se enumeran en la declaración de capacidad:

Un filtro que nombra cualquier otra cosa es rechazado, no ignorado. Un filtro ignorado es una suscripción que notifica sobre todos los pacientes cuando el cliente solicitó uno.

Las propiedades que rodean la implementación:

• An acknowledged change is never a lost notification. The notification is recorded in the same database transaction as the change it describes, and delivered from there, so it survives a restart. A test writes an Encounter, starts a new server on the same database, and checks the notification arrives.
• Notifications arrive in order, and gaps are visible. Event 2 is not sent before event 1 is accepted, and each notification carries the running count, so a receiver can tell when it has missed one.
• The server decides when a subscription is active. A new subscription is requested, and becomes active only when the endpoint accepts a handshake. A client that asks for active gets requested. A refused handshake is tried again four times over about fifteen seconds before the subscription is an error: it goes out the moment the subscription is stored, often before the client that created it is listening.
• A full-resource notification carries the version that changed. A discharge notification carries the discharge, not whatever the Encounter had become by the time delivery succeeded.
• Failure is bounded. A refused delivery is retried with a growing delay. After ten consecutive failures the subscription goes to error: later changes are counted but not queued, and updating the subscription resumes delivery from the oldest held notification. The count then shows how many were missed.

Lo que un cliente puede hacer que haga el servidor está limitado deliberadamente:

• Los puntos de conexión deben ser https a menos que el operador pase -fhir-subscriptions-allow-http, que es para un receptor de prueba.
• La política de salida se aplica cuando se crea una suscripción, de nuevo en cada entrega y en la dirección que cada conexión alcanza realmente (por lo que un nombre que cambia lo que resuelve entre la comprobación y la conexión sigue siendo rechazado); no se siguen las redirecciones.
• La carga útil predeterminada es id-only, que dice qué cambió y permite al receptor recuperarlo con sus propias credenciales.
• Nada de lo que un receptor envía de vuelta se muestra a nadie, solo su código de estado.

Está desactivado a menos que se solicite, porque una vez activado, un cliente FHIR puede hacer que este servidor envíe datos de paciente a una URL elegida por el cliente. Necesita un punto de conexión R4 que acepte escrituras y se niega a iniciar de lo contrario.

No implementado, para que nadie tenga que descubrirlo por intentarlo:

• canales distintos de rest-hook
• latidos cardíacos
• notificaciones de eliminación
• las operaciones $status y $events

La vista Suscripciones muestra el tema, filtro y punto de conexión de cada suscripción, cuántos eventos ha tenido, cuántos se han aceptado y cuántos están esperando, y el último motivo por el que uno fue rechazado. Los valores de encabezado y la cadena de consulta del punto de conexión se retienen, porque ahí es donde viven las credenciales del suscriptor.

8.5 Estándar de telecomunicaciones NCPDP

Reclamaciones de farmacia. Encabezado de ancho fijo seguido de segmentos variables.

Dos detalles que importan, ambos fáciles de equivocar y producir resultados plausibles:

El encabezado tiene exactamente 56 bytes y un ancho fijo. Un encabezado corto no se puede detectar solo por la longitud, porque un encabezado truncado más los segmentos siguientes supera los 56 bytes. La detección se realiza porque un encabezado correcto nunca contiene un byte separador, por lo que se escanea el encabezado en busca de uno y se rechaza un mensaje que lo contenga con el número de bytes que le falta.

0x1E y 0x1C son marcadores de inicio de grupo y campo, no separadores. Tratarlos como separadores desplaza cada campo un lugar a la izquierda, y la mayoría de los valores resultantes siguen siendo plausibles: una cantidad aterriza donde se esperaba un suministro diario y ambos son números.

Los canales NCPDP y SCRIPT están excluidos del encuadre MLLP, y esto se aplica en lugar de aconsejarse. Una reclamación legítima contiene 0x1C, que es el byte de fin de bloque de MLLP, por lo que enmarcar una reclamación la truncaría en el primer marcador de campo.

8.6 NCPDP SCRIPT

Recetas electrónicas, en XML. El paquete interno se llama eprescribe porque script estaba tomado por el motor de JavaScript.

La principal preocupación de seguridad es la bandera de sustitución, y se lee al revés de la intuición: en el cable, 0 significa que la sustitución está permitida y 1 significa dispensar según lo escrito.

Una bandera de sustitución ausente se rechaza en lugar de ser valorada por defecto. Ambos valores posibles por defecto llegan al paciente: uno puede dispensar un genérico donde el prescriptor requirió la marca, el otro evita una sustitución que el prescriptor permitió, por lo que no hay una suposición segura y el mensaje se detiene.

Una receta de la Lista II con recargas se rechaza, y el constructor no produce una.

Los rechazos y advertencias se mantienen como listas separadas en lugar de una lista con etiquetas de gravedad, porque un lector que tenga que verificar un campo de gravedad para saber si se envió el mensaje eventualmente no lo verificará.

La autorización previa electrónica (PAInitiationRequest, PARequest, PAAppealRequest, PACancelRequest) y el beneficio de prescripción en tiempo real se responden en el lado del pagador en /ncpdp/script y /ncpdp/rtpb, a partir del formulario de medicamentos; véase CMS-0057.

8.7 DICOM

Imágenes. Perfuse puede recibir objetos DICOM, consultar un archivo remoto y almacenar en uno, a través de los servicios de red clásicos de DICOM o a través de DICOMweb, y puede mantener un archivo propio para los visores.

DICOM no es un formato de mensaje en el mismo sentido que los demás: los objetos son grandes, y el apretón de manos de la asociación es más importante que el análisis de la carga útil. Los títulos called_ae y calling_ae son la razón más común por la que falla una primera conexión, y el fallo parece un problema de red en lugar de uno de configuración.

8.7.1 Lo que acepta un oyente C-STORE

Dejar abierto, un oyente DICOM acepta cualquier cosa de cualquier persona que pueda llegar al puerto. Cuatro configuraciones bajo Lo que acepta este oyente reducen eso, y la primera es la que vale la pena entender.

Solo aceptar estos títulos AE que llaman es la restricción. El título AE *llamado* —el que está junto a la dirección— es el nombre que un remitente marca, por lo que identifica a este oyente en lugar del remitente, y no es una restricción. Cualquiera que pueda llegar al puerto puede usar el título AE llamado correcto, porque se publica para ellos. Sin una lista de llamadores permitidos, cualquier host en la red puede empujar imágenes a un canal clínico.

Solo aceptar estas clases SOP y solo aceptar estas sintaxis de transferencia toman UID separados por comas. Vacío acepta todo tipo de objeto y negocia cualquier compresión que ofrezca el remitente, lo que incluye tipos que los destinos de este canal no pueden manejar. Rechazar en la asociación es más claro para el remitente que aceptar el objeto y fallar después.

Objeto más grande aceptado está en bytes, y cero significa sin límite. Las imágenes de toda la diapositiva y las series largas pueden alcanzar gigabytes, por lo que el límite es de otro modo la memoria.

8.7.2 DICOMweb

DICOMweb es DICOM sobre HTTP: QIDO-RS busca, WADO-RS y WADO-URI recuperan, STOW-RS almacena. Los visores del navegador como OHIF solo hablan DICOMweb, al igual que los servicios de imágenes en la nube (Google Cloud Healthcare, Azure Health Data Services, AWS HealthImaging). Perfuse lo utiliza en tres lugares.

El archivo de imágenes. Inicie el servidor con -dicomweb-archive DIR (Configuración › Datos › Archivo de imágenes) y mantendrá los objetos en esa carpeta, indexados en SQLite, y los servirá en /dicomweb en la dirección del propio consola: QIDO-RS en los niveles de estudio, série y instancia, WADO-RS para objetos, metadatos, fotogramas y datos bulk, WADO-URI en /dicomweb/wado, y STOW-RS. La lectura toma el rol de visor y el almacenamiento el rol de operador, con una sesión o un token de API; cada lectura y almacenamiento se registra en Actividad como dicomweb.read o dicomweb.store. Una cuenta limitada a un inquilino o a grupos de canales es rechazada, porque el archivo pertenece a todo el servidor. Los objetos se mantienen exactamente como se reciben, por lo que lo que un visor recupera es byte a byte lo que se almacenó. Los fotogramas se devuelven en la sintaxis de transferencia en la que se almacenaron; una solicitud que necesitaría transcoding responde con 406 en lugar de una imagen convertida.

Una búsqueda en un atributo que el archivo no indexa responde 400 en lugar de ignorar la condición y devolver más estudios de los solicitados. Indexado: nombre del paciente (comodines y coincidencia difusa con fuzzymatching=true), ID del paciente, fecha de nacimiento, sexo, fecha y hora del estudio (rangos), número de acceso, ID del estudio, descripción, médico remitente, estudio, series y UID de instancia SOP (listas), modalidad, parte del cuerpo, número y descripción de la serie, clase SOP, número de instancia, filas, columnas y número de fotogramas.

La fuente. type: dicomweb escucha STOW-RS, en /dicom-web/studies por defecto (la ruta que utilizan Orthanc y dcm4chee), y envía cada objeto a través del canal como un mensaje DICOM. El canal necesita dataType: dicom. Establezca un token de portador o un nombre de usuario y contraseña: sin uno, cualquier persona que pueda llegar al puerto puede enviar imágenes al canal. La respuesta enumera cada objeto como almacenado o fallido, con la razón de falla DICOM, para que el remitente sepa qué debe volver a enviar.

name: imaging-from-viewers
dataType: dicom
source:
  type: dicomweb
  dicomweb:
    listen: 0.0.0.0:8043
    token: ${STOW_TOKEN}
    tls: { enabled: true, cert_file: /etc/perfuse/imaging.crt, key_file: /etc/perfuse/imaging.key }
destinations:
  - name: archive
    type: dicomweb
    dicomweb:
      url: https://perfuse.example/dicomweb
      token: ${ARCHIVE_TOKEN}

El destino se encuentra en entrega, bajo archivos DICOMweb.

Apuntar OHIF al archivo

Utilice una fuente de datos DICOMweb con qidoRoot y wadoRoot establecidos en la dirección del archivo (la pantalla Imágenes la muestra, con el bloque de fuente de datos completo para copiar), wadoUriRoot a esa dirección seguida de /wado, imageRendering y thumbnailRendering a wadors, y supportsFuzzyMatching en true. Un visor en otro origen necesita ese origen en -dicomweb-cors (Orígenes de navegador permitidos para llamarlo), y sus solicitudes necesitan un token de API en el encabezado Authorization, porque un navegador en otro origen no envía la cookie de sesión de la consola. Servir OHIF desde el mismo origen a través de un proxy inverso evita ambos.

Probado contra Orthanc con su complemento DICOMweb, en ambos sentidos: el destino almacena en Orthanc, y el cliente DICOMweb de Orthanc busca en el archivo de Perfuse y recupera un estudio idéntico al almacenado. OHIF 3 enumera los estudios del archivo y muestra sus fotogramas con la configuración anterior. OHIF y varios otros clientes envían type= sin comillas en los encabezados Accept y Content-Type, lo que RFC 2045 no permite; Perfuse lo acepta.

8.8 Compartir documentos IHE: XDS.b, XCA, XDR, MHD, PIXm y PDQm

Documentos clínicos compartidos entre organizaciones de la manera en que los intercambios de información de salud, Carequality y eHealth Exchange lo hacen: un repositorio los mantiene, un registro indexa sus metadatos y una comunidad responde a las consultas de otras comunidades a través de un portal. Inicie el servidor con -xds REPOSITORY-OID (Configuración › Datos › Compartir documentos) y será las tres cosas, en la base de datos de este servidor, en estas direcciones, cada una aceptando un token de API como token de portador (el rol de visor para consultar y recuperar, el rol de operador para enviar; la mayoría de los dominios de afinidad agregan TLS mutuo al frente):

Las transacciones SOAP son SOAP 1.2 con WS-Addressing, y MTOM/XOP donde viajan los documentos (un documento en línea como base64 también es aceptado). Una transacción fallida se responde con un RegistryResponse que lleva los códigos de error de IHE, no una falla SOAP: XDSDuplicateUniqueIdInRegistry, XDSNonIdenticalHash, XDSPatientIdDoesNotMatch, XDSMissingDocument, XDSRegistryMetadataError (con el campo que falta), XDSStoredQueryMissingParam, XDSUnknownStoredQuery, XDSUnknownRepositoryId, XDSUnknownCommunity y UnresolvedReferenceException. Un reemplazo (RPLC, XFRM_RPLC) deprecia el documento que reemplaza, que luego solo responde a las consultas que solicitan documentos obsoletos; APND, XFRM y signs se mantienen como asociaciones. El hash y el tamaño se calculan en el repositorio y se verifican contra lo que dice la presentación. Los documentos y metadatos bajo demanda (ITI-57) no están soportados, y una presentación que los solicita es rechazada con la razón.

MHD es el mismo registro en FHIR: un documento proporcionado a través de MHD se encuentra mediante ITI-18 y a través de XCA, y uno proporcionado a través de XDS.b se encuentra mediante ITI-67. El id de un DocumentReference es el UUID de la entrada, su masterIdentifier el uniqueId, y la url de su adjunto la dirección ITI-68 del documento. Los pacientes se resuelven al identificador del dominio de afinidad desde la tienda FHIR: el primer identificador cuyo sistema es urn:oid:, o el Patient que se lleva en el Bundle. PIXm responde con cada otro identificador del Patient con el dado (sourceIdentifier=system|value, estrecho por targetSystem), y 404 para uno que no conoce; PDQm busca por identificador, nombre, fecha de nacimiento, género, dirección y telecom.

Publicación. Un destino xds de un canal publica cada documento clínico que recibe, un documento CDA o uno transportado en un mensaje HL7 v2, en cualquier repositorio XDS.b con ITI-41. Los metadatos se leen del documento: el paciente (el identificador en patient_domain, la autoridad de asignación del dominio de afinidad), título, tipo (como typeCode y, a menos que esté establecido, classCode), tiempos de creación y servicio, autor, confidencialidad, idioma y formato (cuerpo estructurado C-CDA 2.1 o 1.1, XDS-SD, o mimeTypeSufficient, desde sus plantillas); y completado desde lo que un documento no dice: el source_id del remitente, el facility_type y practice_setting que cada registro requiere. La respuesta del Registro del repositorio decide la entrega: un error en un PartialSuccess es una entrega fallida con los códigos de error del registro.

destinations:
  - name: hie
    type: xds
    xds:
      url: https://hie.example/xds/repository
      source_id: 1.2.840.114350.1.13.99
      patient_domain: 1.2.840.114350.1.13.99.2.7.5.737384.14
      facility_type: { code: "225732001", scheme: 2.16.840.1.113883.6.96, display: Community hospital }
      practice_setting: { code: "394802001", scheme: 2.16.840.1.113883.6.96, display: General medicine }
      tls: { enabled: true, cert_file: /etc/perfuse/hie.crt, key_file: /etc/perfuse/hie.key }

XDR. Agrega direct_from (tu dirección Direct) y direct_to (las de los destinatarios) y el mismo destino envía XDR como transporte de Direct, como lo describe el proyecto Direct *XDR y XDM para mensajería Direct*: un bloque de direcciones Direct (urn:direct:addressing) en el encabezado SOAP nombra al remitente y destinatarios, y el intendedRecipient de la presentación nombra a cada destinatario (||^^Internet^address). Apunta url al punto de conexión XDR del destinatario o un HISP que acepte XDR. XDR viaja sobre TLS, usualmente con un certificado de cliente (tls), y no es S/MIME. Una fuente direct también acepta XDR (ver Direct a continuación).

    xds:
      url: https://xdr.hisp.example/xdr
      source_id: 1.2.840.114350.1.13.99
      patient_domain: 1.2.840.114350.1.13.99.2.7.5.737384.14
      facility_type: { code: "225732001", scheme: 2.16.840.1.113883.6.96, display: Community hospital }
      practice_setting: { code: "394802001", scheme: 2.16.840.1.113883.6.96, display: General medicine }
      direct_from: referrals@direct.hospital.example
      direct_to: ["intake@direct.clinic.example"]
      tls: { enabled: true, cert_file: /etc/perfuse/xdr.crt, key_file: /etc/perfuse/xdr.key }

PIX y PDQ en HL7 versión 3. Con el índice de pacientes en (-mpi), /pixv3 es un administrador de PIX y /pdqv3 un proveedor de PDQ sobre SOAP 1.2, para los hospitales y centros de intercambio que aún utilizan los perfiles de v3 de IHE. Una fuente alimenta a los pacientes con ITI-44 (registro agregado PRPA_IN201301UV02, revisado PRPA_IN201302UV02, duplicados resueltos PRPA_IN201304UV02): el primer identificador del paciente es su registro, los demás y los de asOtherIDs son identificadores que lleva, y una fusión combina el identificador del registro anterior con el que sobrevive, como lo hace un A40 de HL7 v2. ITI-45 (PRPA_IN201309UV02) responde con los demás identificadores de la persona que posee uno, limitado por dataSource, en Patient.id; el identificador consultado solo se devuelve en la consulta repetida. ITI-47 (PRPA_IN201305UV02) coincide con los datos demográficos (nombre, género, hora de nacimiento, identificador, dirección, telecom) con el comparador de índice propio, minimumDegreeMatch como puntuación sobre 100, otherIDsScopingOrganization limitando los dominios, y initialQuantity paginando la respuesta: el resto se proporciona con QUQI_IN000003UV01 durante diez minutos, o se descarta con su cancelación. Las respuestas siguen los casos de las transacciones: un paciente desconocido o dominio es AE con error 204 y la ubicación del parámetro, un paciente conocido con nada en los dominios solicitados es NF. v3 nombra una autoridad solo por OID, por lo que un identificador cuyo sistema es una URL sin OID detrás (algunos números nacionales) se omite en las respuestas v3 y se proporciona a través de FHIR; establezca el sistema de identificador de empresa en un OID (urn:oid:..., en la configuración del índice) para que aparezca el EUID y el custodio. El rol de visualizador consulta y el rol de operador alimenta; cada transacción se audita con un identificador, nunca con un nombre. Un mensaje v3 sin procesar publicado como application/xml se responde del mismo modo, lo cual es útil para pruebas manuales.

Intercambio › Compartir documentos muestra lo que mantiene el registro y dónde se puede acceder, encuentra los documentos de un paciente en este registro o en otro (el ITI-18 de un registro o el ITI-38 de una puerta de enlace), descarga uno y publica un documento CDA a mano con los metadatos que un destino le daría.

Verificado contra la herramienta XDS 7.13.0 de NIST, la implementación de referencia de IHE: ITI-41, ITI-18 y ITI-43 de Perfuse contra su simulador de Registro/Repositorio (aceptado sin errores de validación, el documento recuperado es idéntico byte a byte), y su simulador de Puerta de Enlace de Inicio que consulta y recupera de la Puerta de Enlace de Respuesta de Perfuse a través de XCA, sin errores en su registro. Cada mensaje SOAP que escribe Perfuse es válido contra los esquemas ebXML Registry 3.0 y XDS.b, y el DocumentReference y SubmissionSet de MHD contra IHE MHD 4.2.2 con el validador FHIR de HL7. XDR desde un destino xds con un bloque de direccionamiento Direct fue aceptado por el simulador de Recipiente de Documentos de la herramienta, cuya validación de metadatos encontró el único defecto descrito en docs/verification.md, y por el validador XDR de ONC SITE, la lista de verificación XDR Direct (h)(2) la prueba de certificación aplica. Las respuestas PIX y PDQ v3 son válidas contra los esquemas HL7 V3 de IHE (NE2008 multicacheschemas), y las respuestas de muestra de IHE (el feed ITI-44, combinar, consulta ITI-45, consulta ITI-47, continuación y cancelación) se responden como muestran sus respuestas publicadas. Todavía no se ha verificado contra una implementación independiente de PIX o PDQ v3, Gazelle o un Connectathon.

8.9 Mensajería segura directa

Direct es la forma en que los proveedores de EE. UU. se envían mutuamente referencias, resúmenes y resultados por correo electrónico seguro: cada mensaje está firmado con el certificado del remitente y cifrado para el certificado del destinatario (S/MIME), y viaja entre los proveedores de servicios de información de salud (HISPs) que emiten las direcciones y responden de ellas. Perfuse es el sistema de borde junto a su HISP, no un HISP: el HISP emite su dirección, su certificado y su clave, y usted mantiene su paquete de confianza (como el de DirectTrust). Sigue la Declaración de aplicabilidad de Direct para el transporte de salud seguro 1.2, la Guía de implementación para la notificación de entrega, IHE XDM (Anexo 15 de ITI TF-1) para documentos con metadatos, la Guía de implementación de descubrimiento de certificados para Direct Project (DNS y LDAP), y XDR y XDM para el mensajería Direct.

Sending. A direct destination signs each message as your address (SHA-256, RSA), encrypts it to every recipient's certificate and your own (AES-256-CBC, RSA key transport), and submits it to the HISP by SMTP with STARTTLS required. The message travels as an attachment named by its content (document.xml, message.hl7, resource.json), or, with xdm: true, a CDA document travels as an IHE XDM package (IHE_XDM/SUBSET01/METADATA.XML with the document and its hash and size, plus INDEX.HTM and README.TXT) that receiving EHRs import with its metadata. Recipient certificates come from the Direct address book (below), then from DNS, where Direct publishes them as CERT records (RFC 4398): under the address with its @ made a dot, else under its domain; then from the recipient domain's LDAP directory, which its _ldap._tcp SRV record names (or ldap: host:port; ldap: off never asks one): each naming context is searched anonymously for an entry whose mail is the address, then the domain, and its userSMIMECertificate or userCertificate read. A certificate is used only when it is for the address or its domain, has not expired, and chains to one of your anchors, fetching any intermediate issuer its Authority Information Access extension names; and it is refused when its issuer's revocation list (from its CRL distribution point, signed by that issuer) lists it. A list that cannot be fetched does not stop delivery. A recipient with no such certificate is a failed delivery, never plain e-mail. to and subject take field references such as {PV1-8.1}, and request_mdn asks the recipient for a delivery notification.

destinations:
  - name: referrals
    type: direct
    direct:
      address: referrals@direct.hospital.example
      cert_file: /etc/perfuse/direct/referrals.crt   # with its chain after it
      key_file: /etc/perfuse/direct/referrals.key
      anchors_file: /etc/perfuse/direct/anchors.pem
      to: ["intake@direct.clinic.example"]
      subject: "Referral for {PID-5.1}"
      text: "Please see the attached summary."
      xdm: true
      xdm_source_id: 1.2.840.114350.1.13.99
      smtp_host: smtp.hisp.example:587
      username: referrals
      password: ${DIRECT_HISP_PASSWORD}
      request_mdn: true

Recepción. Una fuente direct es el servidor SMTP al que el HISP entrega el correo de su dirección. Acepta correo solo para esa dirección (cualquier otra cosa se rechaza en RCPT), requiere STARTTLS cuando se proporciona un certificado, y abre cada mensaje antes de que nada lo lea: lo descifra con su clave, verifica la firma contra sus anclajes y comprueba que el certificado de firma es para la dirección From o su dominio. Un mensaje que no está cifrado S/MIME, está firmado por un remitente en el que no confía o está firmado por un certificado para alguien más es rechazado en DATA con el motivo, por lo que el HISP lo mantiene y lo informa al remitente; Perfuse nunca acepta lo que luego descarta. Cada documento de un paquete XDM se convierte en un mensaje (comprobado contra los hashes en sus metadatos); de lo contrario, cada archivo adjunto se convierte en uno, o el texto cuando no hay ninguno. Con smtp_host establecido, cada mensaje que se recibe se responde con una notificación firmada y cifrada de "procesado" (MDN), y las notificaciones que llegan para lo que envió se registran.

source:
  type: direct
  direct:
    address: intake@direct.clinic.example
    cert_file: /etc/perfuse/direct/intake.crt
    key_file: /etc/perfuse/direct/intake.key
    anchors_file: /etc/perfuse/direct/anchors.pem
    listen: 0.0.0.0:2525
    tls_cert: /etc/perfuse/tls/server.crt
    tls_key: /etc/perfuse/tls/server.key
    smtp_host: smtp.hisp.example:587

Desde la bandeja de entrada del HISP. Un HISP que mantiene el correo en lugar de entregarlo da a la dirección una bandeja de entrada IMAP: imap la lee (TLS o STARTTLS, cada sondeo una sesión fresca), abre cada mensaje como arriba, mueve lo que se tomó a move_to (o lo elimina) y lo que no se pudo abrir a error_folder, por lo que nada se lee dos veces. listen puede entonces dejarse fuera. Un HISP cuyo servidor de correo tiene un certificado privado se confía con tls.ca_file (su certificado, o el de su autoridad) y tls.server_name; la verificación no se puede desactivar.

    imap:
      host: imap.hisp.example
      username: intake@direct.clinic.example
      password: ${DIRECT_MAILBOX_PASSWORD}
      move_to: Processed

XDR. xdr acepta XDR en /xdr en su propia dirección HTTPS, como un HISP envía Direct que se convierte a SOAP o un socio envía punto a punto: una solicitud ITI-41 Proporcionar y registrar cuyos documentos se convierten en un mensaje. Una presentación cuyo bloque de direcciones Direct nombra otra dirección es rechazada, y una que el canal no acepta se responde con una respuesta de registro de fallo que indica por qué. client_ca_file requiere un certificado de cliente de esas autoridades. XDR está protegido por TLS, no por S/MIME, por lo que una fuente que solo acepta XDR necesita la dirección pero no su certificado, clave o anclajes. Cada documento se convierte en un mensaje del tipo de datos del canal dataType: los documentos CDA necesitan raw (pasados tal como están) o hl7v3, ya que el valor predeterminado, hl7, espera HL7 v2 y los rechaza.

    xdr:
      listen: 0.0.0.0:8445
      tls_cert: /etc/perfuse/tls/server.crt
      tls_key: /etc/perfuse/tls/server.key
      client_ca_file: /etc/perfuse/direct/hisp-clients.pem

Exchange › Direct enumera las direcciones Direct que sus canales envían y reciben, con sus certificados, fechas de vencimiento y anclajes; mantiene el libro de direcciones de los corresponsales (nombre, organización, notas y certificado, pegado desde su HISP o encontrado en DNS o LDAP, y rechazado cuando no es para esa dirección o dominio); y busca los certificados de una dirección en DNS o LDAP sin guardarlos. El libro es el directorio direct-certs junto a la base de datos, un archivo PEM por dirección o dominio, que un destino lee a menos que especifique su propio recipient_certs_dir.

Verificado contra OpenSSL 4.0's cms y smime en ambos sentidos: lo que Perfuse firma y cifra OpenSSL verifica y descifra (PKCS#1 v1.5 y transporte de claves OAEP), y Perfuse abre lo que OpenSSL firma y cifra (AES-128 y AES-256). Un mensaje creado con openssl smime y entregado a través de SMTP es recibido, abierto y almacenado por un canal, y uno que Perfuse envía un mensaje a otro a través de un sustituto de HISP, que responde con un MDN que el remitente abre. Los certificados se encuentran en OpenLDAP 2.4 (vinculados a la dirección y al dominio, escritos por el propio ldapadd de OpenLDAP); un mensaje Direct se lee desde una bandeja de correo IMAP de GreenMail y se abre, y uno que no es Direct se mueve a la carpeta de errores; XDR desde un destino xds es tomado por una fuente direct y se rechaza cuando está dirigido a alguien más, y es aceptado por el kit de herramientas de Document Recipient de NIST XDS y el validador de XDR de ONC SITE; la herramienta de prueba de borde de XDR Direct de SITE envió ambos mensajes de metadatos mínimos y completos a una fuente direct, que los tomó. Contra la herramienta de descubrimiento de certificados Direct de ONC, un destino Direct elige el certificado correcto, o ninguno, en todos los 18 casos de descubrimiento (D1 a D18: certificados caducados, revocados y emitidos por AIA, prioridad y peso de SRV, un directorio inaccesible). Una fuente Direct lee un mensaje desde el propio HISP de SITE (Apache James) a través de IMAP con STARTTLS. Todavía no se ha probado: intercambio de SMTP con el HISP de SITE (AWS retiene el correo saliente en el puerto 25 para nuevas cuentas) o con un HISP acreditado.

8.10 SQL en vistas FHIR

Una ViewDefinition (HL7 SQL en FHIR v2) convierte cada recurso FHIR de un tipo en filas de columnas con nombre, cada columna una expresión FHIRPath, para que los datos FHIR puedan leerse como tablas por DuckDB, Athena, Spark, un almacén de datos o una hoja de cálculo. Perfuse ejecuta estas vistas con su propio motor FHIRPath: column, select anidado, forEach, forEachOrNull, repeat y unionAll, where, constant (cada tipo de valor[x]), columnas collection, %rowIndex, y las claves de unión getResourceKey() y getReferenceKey(type).

{
  "resourceType": "ViewDefinition",
  "name": "blood_pressure",
  "resource": "Observation",
  "constant": [{ "name": "systolic", "valueCode": "8480-6" }],
  "where": [{ "path": "code.coding.exists(system = 'http://loinc.org' and code = '85354-9')" }],
  "select": [{ "column": [
    { "name": "id", "path": "getResourceKey()", "type": "id" },
    { "name": "patient_id", "path": "subject.getReferenceKey(Patient)", "type": "id" },
    { "name": "systolic", "path": "component.where(code.coding.code = %systolic).value.ofType(Quantity).value.first()", "type": "decimal" }
  ]}]
}

Monitorizar › SQL en FHIR ejecuta una vista sobre el almacén FHIR de este servidor (un paciente o todos) o sobre recursos pegados (NDJSON desde una exportación masiva, un Bundle, una matriz JSON), muestra las filas y las descarga como CSV, NDJSON o Parquet. Comienza con cinco vistas de ejemplo (demografía del paciente, observaciones con un valor, presión arterial, condiciones, encuentros) y guarda vistas en el directorio views junto a la base de datos, un archivo JSON cada uno.

El punto de conexión FHIR responde a la especificación $sql-run a nivel de sistema, mediante GET o POST, para una ViewDefinition sujeto dada en línea (subjectResource), por subjectReference (ViewDefinition/<name>, una vista guardada) o por subjectCanonical (la url de una vista guardada), con _format (csv, ndjson (el valor predeterminado), json o parquet), header, patient, _since, _limit y resource para ejecutar sobre recursos enviados con la solicitud en lugar del almacén. Es una lectura: un token SMART necesita ámbito de lectura para el tipo de recurso de la vista, un token vinculado a un paciente obtiene las filas de ese paciente solo, y los ámbitos granulares reducen los recursos leídos, como lo hacen en una búsqueda. Más de un millón de filas necesita _limit, patient o _since.

perfuse sof -view v.json [-format csv|ndjson|json|parquet] [-o out] files... ejecuta una vista sobre archivos FHIR sin un servidor: los archivos NDJSON de una exportación masiva, Bundles o matrices.

perfuse sof -view blood_pressure.json -format parquet -o bp.parquet export/Observation.ndjson
duckdb -c "SELECT patient_id, avg(systolic) FROM 'bp.parquet' GROUP BY 1"

Los archivos Parquet tienen un grupo de filas y páginas PLAIN sin comprimir; los booleanos son BOOLEAN, los tipos de enteros INT64, los decimales DOUBLE y todo lo demás cadenas UTF-8 (una columna de colección como su JSON).

Verificado con la suite de pruebas oficial SQL en FHIR (las 144 pruebas del repositorio sql-on-fhir.js tests/, ejecutadas en cada compilación: todas pasan), y la salida Parquet leída de nuevo por DuckDB 1.5.6 con los tipos y valores correctos. No compatible: Bibliotecas SQLQuery y SQLView (SQL sobre las tablas de las vistas), $sql-export, _format=fhir y los parámetros source y group; cada uno se rechaza con el motivo.

8.11 Medidas de calidad digitales

Una medida de calidad digital cuenta los pacientes en cada población de una FHIR Measure sobre un período de medición (población inicial, denominador, exclusiones y excepciones del denominador, numerador, exclusiones y excepciones del numerador) y puntuación del resultado. La respuesta es un FHIR MeasureReport, con forma como la guía Da Vinci Data Exchange para Medidas de Calidad (DEQM) solicita. Este es el camino que siguen los programas eCQM de CMS y los programas de HEDIS digitales de NCQA.

En Perfuse, los criterios de población son FHIRPath ("language": "text/fhirpath"), ejecutados por el mismo motor que SQL en FHIR. Cada criterio se evalúa una vez por paciente. Su enfoque es un conjunto de registros del paciente (el compartimiento del paciente), y tiene estas variables: %subject (el paciente), %periodStart y %periodEnd (el período, como fechas) y %"Measurement Period". Un criterio da como resultado verdadero o falso; un solo valor que existe cuenta como verdadero.

{
  "code": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/measure-population", "code": "numerator" }] },
  "criteria": {
    "language": "text/fhirpath",
    "expression": "entry.resource.ofType(Observation).where(code.coding.where(system = 'http://loinc.org' and code = '4548-4').exists() and effective.ofType(dateTime) >= %periodStart and effective.ofType(dateTime) <= %periodEnd).exists()"
  }
}

Las poblaciones se anidan como especifica la especificación de Medida. Un paciente está en el denominador solo si está en la población inicial. Una exclusión del denominador saca al paciente antes de que se juzgue el numerador. Una excepción del denominador cuenta solo para un paciente que no esté en el numerador. La puntuación de una proporción es (numerador - exclusiones del numerador) / (denominador - exclusiones - excepciones); la de una razón es numerador / denominador; un grupo de cohortes tiene recuentos y no tiene puntuación. Los estratificadores de un solo criterio dividen cada población por su valor (sexo, por ejemplo).

Perfuse no tiene un motor CQL. Las medidas eCQMs de CMS y las medidas digitales HEDIS publicadas están escritas en CQL, por lo que no se pueden ejecutar tal como están. Una Medida cuyos criterios son CQL se rechaza con ese motivo. Escriba la lógica como FHIRPath en su lugar. La puntuación de variables continuas, los estratificadores multicomponentes y los sujetos de Grupo o Practicante se rechazan de la misma manera.

Monitorizar › Medidas de calidad evalúa una medida sobre el almacén de FHIR de este servidor o sobre recursos pegados, para un período. Ofrece tres informes: un resumen, un resumen con los pacientes en cada población, o uno por paciente. La pantalla muestra las poblaciones, la puntuación y las estratificaciones, y descarga el MeasureReport. Comienza con tres ejemplos: presión arterial bajo control, diabetes con una prueba de HbA1c y pacientes vistos en el período. Son ilustrativos, escritos para este manual, y no son medidas eCQMs de CMS ni HEDIS. Guardar en el almacén de FHIR verifica la Medida y la almacena como un recurso Measure.

El punto de conexión de FHIR responde a Measure/[id]/$evaluate-measure y Measure/$evaluate-measure?measure=<url>, mediante GET o mediante POST de un recurso Parameters. Parámetros:

• periodStart y periodEnd: obligatorios. Una fecha significa todo el día.
• reportType: summary, subject o subject-list.
• subject: Patient/<id>.
• reporter: Organization/<id>. Cuando está ausente, el informe contiene una Organización nombrada por serve -measure-reporter.
• measure: una Medida enviada en línea, como parámetro de POST.

El informe se devuelve, no se almacena. La operación es una lectura, por lo que un token SMART necesita acceso de lectura a Medida y a Paciente. Un token vinculado a un paciente obtiene un informe individual sobre ese paciente y no sobre otro.

perfuse measure -measure m.json -period-start 2026-01-01 -period-end 2026-12-31 [-type summary|subject|subject-list] [-subject Patient/ID] [-o out] files... evalúa una medida sobre archivos FHIR (un NDJSON de exportación masiva, paquetes, matrices) sin un servidor. -measure example:example-bp-control ejecuta un ejemplo enviado, y -examples los enumera.

Verificado. El validador HL7 FHIR verifica las Medidas enviadas contra FHIR R4, sin errores. Verifica un resumen, un individual y un informe de Medida de tipo subject-list contra los perfiles de resumen, individual y subject-list DEQM 5.0.0, también sin errores. No verificado: equivalencia con cualquier eCQM publicado, ya que ninguno se puede ejecutar aquí sin CQL.

8.12 El índice de pacientes (MPI)

Un índice de pacientes maestros enlaza los registros que cada sistema mantiene para una persona (el MRN del hospital, el de la clínica, el del laboratorio) en un identificador de empresa único, el EUID. Está desactivado hasta que alguien decida mantener uno, porque es una tabla de nombres de pacientes, fechas de nacimiento e identificadores: active Configuración → Datos → Índice de pacientes (o serve -mpi) y reinicie. Vive en mpi.db al lado de la base de datos principal.

Alimentarlo. Agregue un destino de tipo mpi (El índice de pacientes en el constructor) a los canales que transportan registros. Lee el PID de cada mensaje HL7 v2, o un paciente FHIR en un canal sin procesar. El identificador del registro es la repetición PID-3 de tipo MR (id_type lo cambia); los demás, y PID-19, se convierten en sus otros identificadores. Una autoridad de asignación con un identificador universal (PID-3.4.2 con tipo ISO) se convierte en urn:oid:...; una con solo un espacio de nombres se mapea mediante authorities, o se convierte en urn:perfuse:aa:<namespace>. Un A40, A34, A18 o A39 combina la persona que posee el identificador de MRG-1 con la persona que posee PID-3 (no_merge los ignora).

destinations:
  - name: index
    type: mpi
    mpi:
      authorities: { HOSP: "urn:oid:1.2.840.114350.1.13.1" }

Coincidencia. Un nuevo registro se vincula en este orden:

1. Identificadores de confianza. Un registro que comparte un identificador de un sistema listado como de confianza (un identificador nacional, un número de empresa) es la misma persona, sin puntuación. Nunca se liste un sistema que una familia comparta, como el número de suscriptor de un pagador.
2. Puntuación. De lo contrario, las personas cuyos registros podrían coincidir se encuentran mediante bloqueo (el mismo apellido sonoro y año de nacimiento, la misma fecha de nacimiento o el mismo número de teléfono) y se puntúan con pesos de Fellegi-Sunter sobre el nombre de familia y el nombre dado (Jaro-Winkler y Soundex, acentos y puntuación ignorados, nombres intercambiados detectados), fecha de nacimiento (un día y mes intercambiados es un acuerdo parcial), sexo, código postal, teléfono y dirección. Solo los campos que ambos registros tienen cuentan. La puntuación es la evidencia encontrada como una parte de la evidencia posible. El bloqueo utiliza cinco claves, por lo que un error no oculta a una persona: sonido del apellido y año de nacimiento, fecha de nacimiento, teléfono, sonidos de ambos nombres (en cualquier orden) y código postal con el sonido del nombre dado.
3. Decisión. Por defecto, nada se vincula solo por la puntuación. Un registro que obtiene una puntuación igual o superior al umbral de revisión (60%) se convierte en una nueva persona y la posible coincidencia espera en la cola de revisión; aquellos que están en o por encima del umbral automático (90%) con el apellido de familia y la fecha de nacimiento que coinciden ambos se marcan como *seguros*. Vincular a dos personas en una (una superposición) coloca los resultados de un paciente en la tabla de otro, por lo que el vinculación automática es un interruptor que activa un administrador (Vincular coincidencias seguras sin preguntar a nadie) una vez que la cola ha mostrado que los seguros son correctos. Con él activado, una coincidencia segura se vincula cuando no hay una segunda persona que obtenga una puntuación tan alta. Por debajo del umbral de revisión, el registro es una nueva persona.

Números nacionales. El número de la NHS (y el CHI de Escocia y el número de Salud y Cuidado de Irlanda del Norte), el PPSN y el IHI de Irlanda, el KVNR de Alemania, el SVNR de Austria, el número de la AHV de Suiza, el BSN de los Países Bajos, el número de registro nacional de Bélgica, el matrícula de Luxemburgo, el INS (NIR y NIA) de Francia, el código fiscal de Italia, el DNI/NIE y el CIP-SNS de España, el número del SNS de Portugal, los números personales nórdicos (Suecia, Dinamarca, Noruega con su número D, Finlandia, Islandia), los códigos bálticos, el PESEL de Polonia, los números de nacimiento checo y eslovaco, y los números húngaro, rumano, búlgaro, croata, esloveno y griego son conocidos por el índice. Cada uno se almacena de una manera: bajo su sistema de esquema, espacios y puntos eliminados, por lo que el número de la NHS enviado como urn:oid:2.16.840.1.113883.2.1.4.1|999 000 0018 por un sistema y como https://fhir.nhs.uk/Id/nhs-number|9990000018 por otro es un identificador. Una repetición de HL7 v2 PID-3 cuyo tipo de identificador es NN y un código de país de tres letras (NNDEU, NNNLD) se lee como el número principal de ese país, y el tipo NH de la autoridad NHS como el número de la NHS. Se prueba el dígito de verificación de cada número: uno que falla se mantiene en su registro, se informa (enmascarado) en la respuesta y nunca se utiliza para vincular o encontrar a alguien, ya que un dígito mal escrito generalmente hace que el número de otra persona sea incorrecto. El CPR de Dinamarca se verifica solo para su fecha, porque los números emitidos desde 2007 no necesitan pasar el módulo 11 antiguo.

La lista de configuración muestra cada esquema con su formato, su verificación y el sistema en el que se almacena. Los sistemas tomados de la guía de FHIR del país (UK Core, fhir.de, Nictiz, CH Core, ANS, HL7 Italia, MedCom, los registros OID sueco, noruego y finlandés) se marcan como tales; los demás son valores predeterminados que se pueden cambiar al valor nacional, lo que un sitio puede hacer por esquema (el antiguo aún se reconoce). Confiar en un esquema es un tick. Los números nacionales se muestran completos a los editores y, de forma predeterminada, enmascarados (los últimos caracteres) a todos los demás; Quién ve los números completos cambia eso, hasta los espectadores o hasta los administradores solamente. Donde la ley de un país limita el uso de un número (Référentiel INS de Francia, PPSN de Irlanda, número de registro nacional de Bélgica, §290 SGB V de Alemania), la configuración lo indica. GET /api/mpi/schemes enumera los esquemas y POST /api/mpi/check verifica un número sin almacenarlo. FHIR $match y PIXm responden a los clientes autorizados con números completos.

Una fecha escrita con el día o el mes primero (08/15/1972) se mantiene como se escribió y no coincide con una fecha con el año primero: los pedidos de EE. UU. y Europa no están de acuerdo, y adivinarlo vincularía a las personas equivocadas.

La pantalla del índice de pacientes (Build) muestra los recuentos, encuentra personas por nombre, número, EUID o fecha de nacimiento, y abre cada persona: sus registros, cada identificador y el historial de lo que les sucedió y quién lo hizo. Los editores deciden las revisiones (La misma persona las vincula; Personas diferentes las mantiene separadas para siempre), mueven un registro a otra persona, sacan un registro (No esta persona), y fusionan dos personas. Los administradores establecen los umbrales, los sistemas de identificadores de confianza, los números nacionales y el sistema de EUID. Cada búsqueda y cada persona leída se escribe en el registro de auditoría.

Responder a otros. POST /fhir/Patient/$match (la operación FHIR, como IHE PDQm ITI-119 la utiliza) toma un Paciente y devuelve las personas que podrían serlo, primero las mejores, cada una un Paciente cuyo id es el EUID, con cada identificador, search.score, y la extensión de grado de coincidencia (certain, probable, possible); onlyCertainMatches y count son honrados. PIXm (/mhd/Patient/$ihe-pix, ITI-83) responde desde el índice: cada identificador de cada registro vinculado a la persona, y el EUID. Lo mismo hacen PIX y PDQ en HL7 v3 (/pixv3, /pdqv3; véase el documento de intercambio de IHE), que también lo alimentan.

La API es /api/mpi (resumen y búsqueda), /api/mpi/persons/{euid}, /api/mpi/find, /api/mpi/reviews, /api/mpi/records (registro, enlace, desenlace), /api/mpi/merge y /api/mpi/settings.

Pesos. Los pesos Fellegi-Sunter predeterminados provienen de la literatura de vinculación de registros para datos de registro hospitalario. Estimar desde nuestros registros (en la configuración, administradores; POST /api/mpi/estimate) los ajusta a su propio índice del sitio con maximización de expectativa, sin necesidad de pares revisados: m (acuerdo entre coincidencias verdaderas) de los pares que bloquean, u (acuerdo por casualidad) de 20.000 pares extraídos al azar, ya que los pares bloqueados coinciden en nombres y fechas por construcción. La estimación se muestra junto a los pesos en uso y no cambia nada hasta que se utiliza y se guarda. Un campo comparado en demasiados pares mantiene su valor predeterminado. La estimación supone que los campos son independientes dado la clase, lo que no es del todo cierto, por lo que se debe tratar un gran cambio con sospecha.

Medido. En el conjunto de datos FEBRL 3 (5.000 registros sintéticos de 2.000 personas, los duplicados con errores de escritura, campos intercambiados, valores perdidos y apodos; PERFUSE_TEST_FEBRL), registrado en orden de archivo con un revisor que responde cada par en cola correctamente:

Nunca se vinculó un registro a la persona equivocada, y ninguna de las 2.000 personas nuevas se puso en cola innecesariamente. Los que se perdieron difieren en casi todos los campos (una fecha de nacimiento y una dirección ambas mal escritas, por ejemplo) y tienen una puntuación por debajo del umbral de revisión. FEBRL es sintético y tiene pocos nombres iguales; un índice real tiene más, por lo que su cola de revisión será más larga, y estos números son un piso de cuidado, no una promesa.

8.13 Delimitado

CSV y sus parientes. Las opciones están en la fuente en el constructor, y la referencia de formato enumera las claves de archivo.

Las rutas dirigen columnas. Una columna con nombre está disponible cuando se declara una fila de encabezado o se dan los nombres; de lo contrario, las columnas son posicionales.

8.13.1 Nombrar las columnas

Hay dos formas, y son exclusivas. O la primera fila del archivo las nombra — la primera fila nombra las columnas — o las enumera usted mismo, en orden. Declarar un encabezado significa que la fila no se trata como datos.

Si ninguna de las opciones se establece, las columnas solo se pueden dirigir por posición, por lo que un filtro escrito contra un nombre no tiene nada que coincida. Activar el encabezado elimina la lista de nombres en lugar de mantener ambas: con un encabezado, los nombres provienen del archivo, por lo que una lista que queda atrás sería ignorada, y un canal que lee como si hubiera elegido los nombres cuando el archivo los eligió es más difícil de depurar que uno que se niega.

8.13.2 Lo que ve un filtro o un script

Un documento delimitado se convierte en muchos mensajes, por lo que esto debe establecerse antes de escribir cualquiera de los dos.

Con división activada, todo se ejecuta por fila. Los pasos declarativos, el filtro y el script de transformación ven una fila, y una ruta significa *la columna de esta* fila. Un filtro que rechaza una fila rechaza solo esa fila, y el recuento recibido es de filas en lugar de documentos.

Con la división desactivada, el mensaje es el documento completo y una escritura que cruza filas se rechaza en lugar de aplicarse a la primera. Ese rechazo es deliberado: escribir silenciosamente en la fila uno es el comportamiento que produce un archivo que parece transformado y no lo es.

8.13.3 Los tres que cambian lo que cuenta como un error

Aceptar filas con el número incorrecto de columnas está desactivado por defecto. Una fila con demasiadas o demasiado pocas columnas es entonces un error, lo que es lo que atrapa un archivo cuya forma cambió sin previo aviso. Activarlo acepta la fila y deja las columnas perdidas vacías.

Recortar espacios alrededor de cada valor arregla el caso común de un valor relleno a un ancho de columna. Deje esta opción desactivada donde los espacios finales son significativos, lo que ocasionalmente sucede en un identificador.

Mantener líneas en blanco como filas está desactivado por defecto y generalmente debe estarlo. Activarlo, una línea en blanco se convierte en una fila de columnas vacías, lo que solo importa cuando un recuento debe coincidir exactamente con el archivo.

8.14 Crudo

No se realiza ningún análisis. El mensaje es una secuencia de bytes.

Utilice esto cuando el contenido no es algo que Perfuse comprenda y no necesita serlo: un PDF que se mueve entre sistemas, un formato propietario, un documento ya formado que se reenvía sin cambios.

El costo es que nada que dependa de la estructura funciona — ninguna transformación a nivel de campo, ningún filtro en un campo, ninguna comparación a nivel de campo en el verificador de paridad. Un canal crudo es una tubería, y es honesto al respecto.

8.15 Elegir

Si el mensaje es HL7 v2, use hl7, incluso si solo tiene la intención de reenviarlo sin cambios. El análisis le proporciona la traza, las estadísticas a nivel de campo, la capacidad de filtrar más adelante y la capacidad de comparar. raw en contenido analizable no aporta nada y pierde todo eso.

Use raw cuando el análisis fallaría o sería una mentira sobre el contenido.

8.16 Enlaces y tarjetas de salud SMART

El *Kill the Clipboard* de CMS pide a los proveedores que acepten los registros de un paciente desde un código QR en el check-in, y que devuelvan el registro de la visita de la misma manera. El código QR contiene un enlace de salud SMART (shlink:/...): una dirección, una clave de 256 bits y, opcionalmente, una etiqueta, una fecha de caducidad y una bandera de contraseña. Intercambio → Enlaces de salud lee uno.

Recepción. Pegue el enlace o escanéelo con la cámara donde el navegador pueda (Chrome y Edge). Perfuse recupera el manifiesto, descifra cada archivo con la clave del enlace, resume cualquier paquete FHIR - quién es el paciente, cuántos recursos de cada tipo - y verifica cualquier *tarjeta de salud inteligente* dentro contra la clave publicada de su emisor. *Entregar al canal* entrega el contenido FHIR a un canal como un mensaje, que es cómo llega al registro electrónico de salud. La recuperación se mantiene en la política de salida en el momento de la conexión, se rechaza el HTTP plano y la respuesta de un servidor que no es un servidor de manifiesto nunca se muestra, porque la dirección provino de un código QR de un desconocido.

Compartir. *Compartir* cifra un paquete FHIR, lo hospeda y muestra el enlace y su código QR una vez. El servidor mantiene el texto cifrado y no la clave - no puede abrir lo que hospeda, y no puede mostrar el enlace nuevamente. Un código de acceso se hash; diez intentos incorrectos deshabilitan el enlace. Los enlaces caducan después de 30 días por defecto, se pueden revocar y enumeran con qué frecuencia y por quién se recuperaron. Inicie el servidor con -public-url configurado en la dirección https que los teléfonos de los pacientes alcanzan; la URL del manifiesto que construye debe ajustarse a los 128 caracteres de la especificación.

Verificar una tarjeta. *Verificar una tarjeta* toma un código QR numérico shc:/ (un bloque o varios), un archivo .smart-health-card o un JWS, y dice si la firma coincide con la clave del emisor.

8.17 UN/EDIFACT

dataType: edifact lee intercambios UN/EDIFACT (ISO 9735): ORDERS, INVOIC, DESADV, IFTSTA y el resto, incluidos los mensajes de reclamaciones de atención médica y laboratorio europeos. El consejo de cadena de servicio (UNA) se respeta, con el carácter de liberación y, para la versión de sintaxis 4, el separador de repetición; los grupos funcionales (UNG/UNE) son opcionales. El intercambio se entrega exactamente como lo escribió el remitente.

name: supplier-orders
dataType: edifact
edifact:
  envelope: require      # require (default), warn, or ignore
  split: false           # true: one interchange per message
  acknowledge: contrl    # none (default) or contrl
filter: 'UNB-2.1 == "5412345000013"'
source:
  type: as2              # or http, sftp, file, email ...
  # ...
destinations:
  - name: orders
    type: file
    dir: /data/orders
    filter: 'UNH-2.1 == "ORDERS"'

El sobre. El recuento de segmentos y la referencia de UNT, el recuento de mensajes y la referencia de UNE, y el recuento y la referencia de UNZ se comparan con lo que contiene el intercambio. Con require, el valor predeterminado, una discrepancia rechaza el intercambio (es cómo muestra una transferencia cortada); warn lo acepta y registra una advertencia; ignore no lo verifica.

Rutas, para los filtros de canal y destino, cuentan elementos y componentes de 1 en el orden en que se escribe el segmento, como lo numeran las guías de implementación: BGM-2 (el número de documento), BGM-1.1, NAD(2)-2.1 (la parte del segundo NAD), LIN-3(2).1 (una repetición), UNB-2.1 (el remitente), UNH-2.1 (el tipo de mensaje). Una ruta sin ocurrencia se dirige a todos.

División entrega un intercambio por mensaje, cada uno con el UNB original (y encabezado de grupo) y tráileres que cuentan como uno, por lo que un pedido puede ser filtrado, buscado y reintento por su cuenta. Los filtros de destino ven cada pieza. Un destino de archivo nombra archivos por tipo de mensaje (ORDERS_INVOIC-20261017.edi), y ${control_id} es la referencia de intercambio.

CONTRL. Con acknowledge: contrl, un remitente que publica sobre HTTP recibe una respuesta con sintaxis y informe de servicio CONTRL: acción UCI 7 cuando el intercambio fue leído y entregado, 4 cuando fue rechazado o no pudo ser deliverado (HTTP 400 o 502 entonces). No se puede combinar con split, ya que un CONTRL responde a todo el intercambio. A través de AS2, el recibo del socio es el acuse de recibo.

No se ofrece: los directorios de mensajes (que segmentos ORDERS D.96A permite), por lo que se verifica la estructura, no el contenido; las transformaciones, que reescribirían un documento de un socio; y los scripts de filtro o transformador (un preprocesador se ejecuta, antes de analizar). Verificado contra pydifact 0.1.8, un analizador independiente, en ambos sentidos.

9 Reconocimientos

Un reconocimiento informa al remitente qué sucedió. Para HL7 v2 sobre MLLP es un mensaje ACK; el remitente no enviará el siguiente mensaje hasta que llegue, y generalmente lo reenviará si no lo hace.

Equivocarse en los reconocimientos es la forma más común en que una integración pierde silenciosamente datos, porque un remitente que está siendo reconocido no tiene razón para quejarse.

9.1 Temporización

Cubierto en flujo de mensaje, y el resumen es: ack.when es on_delivery por defecto, lo que significa que el reconocimiento se envía solo después de que todos los destinos habilitados hayan aceptado el mensaje. on_receipt lo envía tan pronto como el mensaje se analiza y se coloca en cola.

9.2 Lo que envía Perfuse

Un AA cuando el mensaje se aceptó, un AE cuando se rechazó por una razón que el remitente podría actuar, y un AR cuando se rechazó por una razón que el remitente no puede.

La distinción entre AE y AR es quién tiene que hacer algo. AE significa que el mensaje tenía un problema - un campo que no se podría analizar como una fecha, un segmento requerido que falta - y el remitente puede corregirlo y reenviarlo. AR significa que Perfuse no podría aceptarlo independientemente del contenido, lo que generalmente significa un problema de configuración o disponibilidad en este extremo. Un remitente que reenvía después de un AR obtendrá la misma respuesta.

9.3 Identificar este motor

ack.application y ack.facility poblán MSH-3 y MSH-4 del acuse de recibo.

Cuando ambos están vacíos, el acuse de recibo refleja el receptor original: utiliza lo que el mensaje entrante tenía en MSH-5 y MSH-6. Eso es lo que la mayoría de los remitentes esperan, y es el valor predeterminado por esa razón.

Establézcalos explícitamente cuando el remitente los valide, o cuando varias instancias de Perfuse manejen la misma fuente y necesite saber cuál respondió.

9.4 El evento de activación

ack.include_trigger_event envía ACK^A01 en lugar de un simple ACK.

Algunos receptores lo requieren y otros lo rechazan, lo que explica por qué es una opción explícita sin un valor predeterminado inteligente. Si un remitente se niega a aceptar sus acuses de recibo y el contenido parece correcto, esta es la primera cosa que debe intentar.

9.5 Los acuses de recibo negativos no son fallos que ocultar

Un NACK tratado como un éxito es una de las configuraciones incorrectas más dañinas posibles, y es lo suficientemente común como para merecer ser nombrada. Ocurre cuando un destino envía un acuse de recibo negativo y el lado emisor registra la *transmisión* como exitosa porque los bytes se enviaron y algo regresó.

Perfuse lee el acuse de recibo que recibe de un destino MLLP y registra el resultado en consecuencia. Un AE o AR de un sistema downstream es un fallo de entrega, se reintenta según la política del destino y cuenta hacia la tasa de fallos que activa las alertas.

9.6 Tiempo de espera

Esperar un acuse de recibo está limitado. Cuando no llega a tiempo, la entrega es un fallo y se coloca en cola para reintento.

Un tiempo de espera no es lo mismo que un rechazo y se registra de manera diferente. Un rechazo significa que el lado lejano consideró el mensaje y lo rechazó; un tiempo de espera significa que no sabe si se procesó. Esa distinción decide si un reintento es seguro: reintenta después de un rechazo es inútil, y reintenta después de un tiempo de espera arriesga un duplicado. Perfuse reintenta después de un tiempo de espera, porque un mensaje clínico perdido es generalmente peor que un duplicado, y el sistema receptor es generalmente capaz de detectar un ID de control de mensaje repetido.

Si ese intercambio es correcto para una fuente determinada es un juicio, y vale la pena hacerlo deliberadamente para cualquier cosa donde un duplicado tenga una consecuencia clínica — una orden, una administración de medicación — en lugar de aceptar el valor predeterminado silenciosamente.

9.7 Fuentes que no reconocen

No todos los transportes tienen el concepto. Una fuente de archivo no tiene dónde enviar un acuse de recibo; una fuente de corredor reconoce al corredor en lugar del remitente original; una fuente HTTP responde con un código de estado.

Donde la fuente no puede entregar el modo de acuse de recibo que un canal solicita, el canal se rechaza en la carga en lugar de iniciar y no reconocer silenciosamente. Un canal que cree que está reconociendo y no lo está es peor que uno que no inicia.

9.8 Acuses de recibo X12

Todo lo anterior se refiere a HL7 v2. X12 tiene sus propios acuses de recibo, y a diferencia de v2, están desactivados por defecto: un ajuste vacío significa ninguno.

Ese valor predeterminado es el seguro, porque un socio comercial que no espera un acuse de recibo y lo recibe puede tratarlo como un intercambio no solicitado. La clave acknowledge en un canal X12 puede tener uno de cuatro valores:

Qué acuse de recibo enviar es una propiedad de la relación de socio comercial en lugar del mensaje, por lo que debe configurarse y no puede inferirse. Un 999 sustituye a un 997 para transacciones HIPAA, pero muchos socios — especialmente conexiones de pagador más antiguas — están configurados para esperar un 997 y tratarán un 999 como un archivo no reconocido.

9.9 Acuses de recibo HL7 v3

Un canal HL7 v3 envía un acuse de recibo de forma predeterminada, lo que es lo opuesto a X12 y vale la pena saber.

La razón es el transporte más que el estándar: una interacción v3 generalmente llega a través de una conexión síncrona con la aplicación de envío esperando una respuesta, y un remitente que no recibe nada generalmente lo intentará de nuevo. Esa es la forma en que un paciente se registra tres veces.

Desactivarlo es posible y debe hacerse explícitamente — "no establecido" y "establecido en falso" son deliberadamente diferentes, por lo que el valor predeterminado se mantiene a menos que alguien haya dicho lo contrario.

10 Entrega, Cola y Reintento

Un destino que no se puede alcanzar es el caso normal, no la excepción. Los sistemas se reinician, las redes se caen y un motor de interfaz de hospital no está disponible durante su propia ventana de mantenimiento. La entrega se basa en eso.

10.1 Cola por destino

Cada destino tiene su propia cola. Un destino que está fallando no afecta a los demás, y cada uno tiene su propia profundidad, edad y estado de reintento.

La cola es por destino más que por canal porque la falla es por destino. Una cola a nivel de canal retendría la entrega a tres sistemas que funcionan porque un cuarto está caído, y las dos situaciones — un destino no disponible, los cuatro destinos no disponibles — se verían iguales en las estadísticas.

10.2 Configuración de la cola

queue on a destination:

Las dos últimas estaban faltando en esta tabla y en el constructor, y son la pareja que evita que se llene un disco. Una cola sin ninguna de las dos crece hasta que el sistema de archivos está lleno, y esa falla llega como algo no relacionado que se rompe — una escritura que falla en algún lugar completamente diferente — en lugar de como un problema de cola.

El retardo crece entre intentos hasta max_backoff. Creciente en lugar de fijo, porque un destino que está caído generalmente está caído durante minutos más que segundos, y reintenta cada segundo durante diez minutos produce varias centenas de entradas de registro que entierran la que importa.

10.3 Se mantiene el orden

Dentro de un destino, los mensajes se entregan en orden de llegada, y un mensaje que falla mantiene su lugar. Los mensajes posteriores esperan detrás de él en lugar de adelantarlo.

Este es el valor predeterminado correcto para los datos clínicos — una admisión y una alta aplicadas en el orden incorrecto es peor que ambas siendo tardías — y tiene una consecuencia digna de comprender: un mensaje que siempre falla mantendrá todo detrás de él.

Esa es la razón por la que la profundidad de la cola y la edad de la cola son condiciones de alerta separadas. Una cola profunda que se está drenando es un sistema ocupado. Una cola cuyo mensaje más antiguo sigue envejeciendo está atascada, y los tipos de alerta queue-depth, queue-age y queue-stuck las distinguen.

10.4 Cuando la cola está deshabilitada

Con queue.enabled falso, una entrega fallida es una entrega fallida. Se registra y no se reintenta.

Esa es la elección correcta cuando los datos tardíos son peores que no tener datos — una pantalla en tiempo real, un sistema de paging, cualquier cosa donde un mensaje entregado cuarenta minutos después del evento sería engañoso más que simplemente retrasado.

Es la elección incorrecta para cualquier cosa que vaya a un registro, donde el mensaje es igual de válido una hora después.

10.5 Reintento versus cola

Hay dos mecanismos y operan a diferentes niveles.

retry en un destino gobierna los intentos inmediatos dentro de una entrega — una conexión que falla se intenta de nuevo después de una breve pausa, sin salir del camino de entrega. Esto maneja fallos transitorios: una conexión caída, un rechazo momentáneo.

queue gobierna lo que sucede una vez que los intentos inmediatos se agotan. El mensaje sale del camino de entrega y se reintenta más tarde en un horario más largo.

Ambos existen porque los dos fallos son diferentes. Un restablecimiento de conexión en el primer intento generalmente desaparece en el segundo, y pasar por la cola para ello agregaría minutos de latencia a un fallo que duró milisegundos. Un destino que ha sido apagado para mantenimiento no volverá dentro de tres intentos inmediatos, y golpearlo es inútil.

10.6 Qué cuenta un punto final HTTP como entregado

Un destino HTTP tiene tres configuraciones que deciden si un mensaje se trata como enviado, y las tres están en el destino en el constructor.

Status codes that mean delivered. Empty means any 2xx. Some endpoints answer 202 Accepted for something they have not processed yet, and some answer 200 with an error in the body — the second is what *Treat as failed if the reply contains* is for. Setting an explicit list is worth doing when a partner has told you which code means what, because the alternative is discovering the difference from a message that was never delivered and never queued.

Seguir redirecciones. Desactivado por defecto, y deliberadamente. Una redirección puede apuntar a un host diferente, por lo que seguir una redirección envía el mensaje a algún lugar que nadie ha configurado y informa de éxito.

Token de portador. Enviado como un encabezado Authorization. Se almacena con el canal y nunca se muestra de nuevo, por lo que dejar la casilla vacía al editar un canal existente mantiene el token ya guardado en lugar de borrarlo.

10.7 Nombrar y podar una carpeta de archivo

Un destino de archivo agrega a un archivo por día y tipo de mensaje por defecto (20261012-ADT_A01.hl7), enmarcado en MLLP para que el archivo se reproduzca con perfuse send. Cuatro configuraciones en el destino cambian eso.

Nombre de archivo (file_name) hace un archivo por mensaje en su lugar, nombrado desde ${date}, ${timestamp}, ${control_id}, ${message_type} y ${destination}. Un nombre que ya está tomado (el mismo ID de control dos veces) obtiene un sufijo único en lugar de sobrescribir el mensaje allí.

Agregar (append: true) escribe cada mensaje en el archivo que Nombre de archivo nombra, por lo que ${date}.hl7 es un archivo por día para cada tipo.

Sufijo al escribir (temp_suffix, un archivo por mensaje solo) predeterminado es .part y se elimina mediante un cambio de nombre una vez que el archivo esté completo. Quien recolecta estos archivos no debe recoger uno escrito a medias, y un cambio de nombre dentro de una carpeta es atómico. Cambie solo si el recolector filtra en una extensión diferente.

Eliminar después (retain_hours) poda archivos en la carpeta que tengan más de la cantidad de horas dada, verificada como máximo cada diez minutos mientras llegan mensajes. Solo se eliminan archivos simples directamente en la carpeta, nunca una subcarpeta. Vacío o cero los mantiene para siempre, que es el valor predeterminado y es una decisión en lugar de una omisión — pero un archivo que nadie poda llena el disco, y un disco lleno detiene el canal en lugar del archivo.

10.8 Enviar a un servidor FHIR

Tres configuraciones deciden cuánto se comprueba antes de que un paquete salga.

Reclamar la conformidad de US Core agrega el perfil a cada recurso. Solo reclame cuando el recurso lleve lo que el perfil requiere, porque un receptor puede validar contra la reclamación y rechazar un paquete que de otra manera habría sido aceptado.

Validar antes de enviar comprueba cada recurso aquí en lugar de aprender del receptor. Un rechazo en el extremo lejano le dice menos, más tarde, y a menudo solo en un registro que no puede leer.

Tratar advertencias como rechazos solo tiene efecto cuando la validación está activada, y el control no está disponible hasta que lo esté. Es lo suficientemente estricto como para detener un paquete que un receptor aceptaría, por lo que pertenece a una fuente que se está implementando en lugar de una en servicio.

10.8.1 Servicios FHIR alojados

Un destino fhir tiene un bloque auth que inicia sesión en los servicios alojados, donde un token de portador pegado deja de funcionar dentro de una hora:

fhir:
  url: https://healthlake.us-east-1.amazonaws.com/datastore/<id>/r4/
  auth: {type: aws, access_key_id: ${AWS_ACCESS_KEY_ID}, secret_access_key: ${AWS_SECRET_ACCESS_KEY}}

aws firma cada solicitud para AWS HealthLake con Signature Version 4, con la región leída desde la URL. azure obtiene un token de Microsoft Entra ID para Azure Health Data Services desde tenant_id, client_id y client_secret - un registro de aplicación que tiene el rol de contribuyente de datos FHIR - con la URL del servicio FHIR como su audiencia. client_credentials hace lo mismo contra cualquier URL de token token_url de OAuth 2.0. Los tokens se reutilizan hasta un minuto antes de que expiren. Las mismas opciones están bajo el Inicio de sesión del servicio alojado del destino en el constructor de canales.

10.8.2 Informes de casos de salud pública

Active Informar condiciones informables a salud pública en un destino de FHIR y enviará informes de casos en lugar de paquetes. Cada mensaje se verifica para un código de activación de condición informable: un diagnóstico, una prueba de laboratorio o un resultado codificado. Si lo tiene, el mensaje se convierte en un eICR 2.1.2 de HL7 eCR, envuelto en un mensaje eCR y publicado en la URL $process-message. Si no lo tiene, no se envía nada y no falla; el destino cuenta como no informable.

fhir:
  url: https://ecr.agency.example/fhir
  ecr:
    rctc: /etc/perfuse/rctc.json
    source: https://fhir.springfield-general.example/fhir
    facility: {name: Springfield General Hospital, phone: +1-217-555-0100, city: Springfield, state: IL}

rctc es el conjunto de códigos de activación de condiciones informables, como un conjunto de valores de FHIR o el paquete eRSD. Necesita una licencia de UMLS, por lo que no está incluido; sin ella, se utiliza una muestra de prueba integrada corta, solo para pruebas. source es donde la agencia envía su respuesta de informabilidad. La instalación es necesaria porque eCR solicita su teléfono y dirección, y un mensaje v2 no tiene ninguno.

Un informe dice qué es lo que falta en el mensaje en lugar de inventarlo, y cada brecha se registra. Intente un mensaje en el panel Informe de caso de salud pública del laboratorio de FHIR antes de apuntar una fuente en vivo a una agencia.

10.8.3 Resultados de laboratorio a salud pública: ELR

perfuse elr -config elr.yaml results.hl7 convierte los resultados de un laboratorio en mensajes ELR HL7 2.5.1 que reciben los departamentos de salud estatales, uno para cada mensaje con un resultado informable, y solo las órdenes que llevan uno: un recuento sanguíneo completo junto a una prueba de SARS-CoV-2 positiva no es asunto de salud pública. Los códigos de activación son los mismos que los de informes de casos, el RCTC que carga o el ejemplo integrado.

ELR nombra a todos por OID o número CLIA, que ninguna fuente de laboratorio lleva para el remitente y el receptor, por lo que provienen del archivo:

sending_application: {namespace: Perfuse, id: 2.16.840.1.113883.19.5.9, type: ISO}
sending_facility: {namespace: Springfield Lab, id: 2.16.840.1.113883.19.5, type: ISO}
receiving_application: {namespace: ELR, id: 2.16.840.1.113883.19.6.1, type: ISO}
receiving_facility: {namespace: State DOH, id: 2.16.840.1.113883.19.6, type: ISO}
processing: T
ordering_facility: {name: Springfield Clinic, phone: "+1 217 555 0100", line: 1 Main St, city: Springfield, state: IL, postalCode: "62701"}
performing_lab: {name: Springfield Lab, line: 2 Lab Rd, city: Springfield, state: IL, postalCode: "62701"}
performing_lab_clia: 14D0000000
placer_authority: {namespace: SPRINGFIELD-EHR, id: 2.16.840.1.113883.19.5.1, type: ISO}
filler_authority: {namespace: SPRINGFIELD-LAB, id: 2.16.840.1.113883.19.5.2, type: ISO}

La instalación que ordena, el laboratorio que realiza y las autoridades que asignan se utilizan solo donde el mensaje del laboratorio los deja fuera, y cada uso es una nota. Lo que solo sabe el laboratorio nunca se rellena: un resultado sin tipo de especimen va con SPM-4 vacío y una nota que lo dice, porque un especimen adivinado en un informe a salud pública es peor que una brecha que el estado puede preguntar. Comience con processing: T mientras el equipo de incorporación del estado prueba la fuente.

Lo que el laboratorio hizo bien se mantiene como se envió. Una orden secundaria (un panel de susceptibilidad o una prueba de reflejo cuyo OBR-29 nombra a su padre y que no tiene ORC propio) se envía tal como se recibió, sin ORC ni especimen inventado, y una orden secundaria sin resultado informable tiene el de su padre, ya que una susceptibilidad no significa nada sin la cultura a la que pertenece. Una nota después del PID se mantiene con el paciente, y ORC-14, el número de teléfono de llamada, se copia de OBR-17 cuando el laboratorio solo lo puso allí. Todos los 28 mensajes de ejemplo que ONC publica para su herramienta de certificación ELR salen válidos sin errores.

MSH-2 se escribe como ^~\&#, los cinco caracteres que requiere la errata de ELR Release 1 y que verifica la herramienta de certificación de ONC. Si la guía de su estado muestra los cuatro anteriores, agregue encoding_characters: "^~\\&" al archivo.

Para enviarlos desde un canal en lugar de desde la línea de comandos, dé al destino que alcanza el estado un bloque elr que nombra el mismo archivo. Cada resultado de laboratorio se reorganiza en el camino, y uno con nada informable no se envía en absoluto, lo que se cuenta como delivered, no fallido: el estado solicitó resultados informables solo.

destinations:
  - name: state-elr
    type: mllp                 # or http, sftp, file: whatever the state's onboarding team gives you
    address: elr.health.state.example:6661
    tls: {enabled: true}
    elr:
      config: elr.yaml         # beside this channel file
      rctc: rctc.json          # optional; the built-in sample is for testing only

El bloque se aplica en un canal de HL7 v2, a destinos que entregan el mensaje en sí (mllp, http, tcp, archivo, sftp, ftp, S3, Azure Blob, soap, los corredores de mensajes o otro canal); el canal se niega a cargar de lo contrario, y cuando el archivo está faltante o carece de la instalación de envío, la aplicación receptora o la instalación receptora. Las notas se escriben en el registro con el ID de control del mensaje.

El archivo ELR es el compañero del canal, no un canal: perfuse check y la pantalla de canales lo omiten en lugar de informar un Canal que no se puede cargar. En el constructor de canales, las mismas dos configuraciones están bajo el destino, en Informe de laboratorio (ELR 2.5.1); el campo de códigos de activación se abre una vez que se nombra un archivo ELR, y guardar se niega a un archivo que no esté junto al canal.

10.8.4 Archivos DICOMweb

type: dicomweb almacena cada objeto con STOW-RS: Orthanc, dcm4chee, los servicios de imágenes en la nube o el propio archivo de un servidor Perfuse. Proporcione la raíz del servicio (https://pacs.example/dicom-web); /studies se agrega, y una URL que ya termina en /studies se rechaza en lugar de publicar en /studies/studies. Autentíquese con token (un token de portador) o username y password; headers agrega otros, como el encabezado de proyecto de un servicio en la nube. El canal necesita dataType: dicom.

La respuesta del servidor decide el resultado, no solo su código de estado. Un objeto que la respuesta enumera como fallido es una entrega fallida con la razón de falla de DICOM, y también lo es un 202 que no enumera nada como almacenado: el servidor tomó la solicitud y no mantuvo nada de ella. El tiempo de espera predeterminado es de dos minutos, porque una serie grande es lenta.

10.8.5 Repositorios de documentos (IHE XDS.b)

type: xds publica cada documento clínico en un repositorio XDS.b con ITI-41 Provide and Register: un documento CDA, o uno que lleva un mensaje HL7 v2 (MDM, ORU). Los metadatos provienen del documento y de la configuración del destino (source_id, patient_domain, facility_type, practice_setting), y la respuesta del registro del repositorio decide la entrega. Vea Compartir documentos de IHE.

10.8.6 Registros de inmunización

Cada registro de inmunización estatal (IIS) de EE. UU. acepta mensajes de HL7 2.5.1 en la misma interfaz de SOAP, la publicada por los CDC en 2011 (namespace urn:cdc:iisb:2011). Tiene dos operaciones: connectivityTest, que prueba el punto final, y submitSingleMessage, que lleva el mensaje. Un VXU^V04 informa un disparo y regresa como un ACK; un QBP^Q11 solicita el historial y el pronóstico de un paciente y regresa como un RSP^K11.

Elija Registro de inmunización (Servicio web IIS CDC) como el servicio de un destino SOAP, o escriba profile: cdc-iis:

destinations:
  - name: state-registry
    type: soap
    soap:
      profile: cdc-iis
      url: https://iis.state.example/iis-ws/cdc
      username: clinic-submitter       # the registry account for this submitter
      password: "..."
      facility_id: FAC-1234            # optional in the WSDL; many registries require it
    queue: {enabled: true}

Perfuse construye el sobre, por lo que no hay cuerpo que escribir. El nombre de usuario y la contraseña van dentro de la solicitud, donde los CDC WSDL los colocan, no en la autenticación HTTP. La versión es SOAP 1.2, la vinculación de WSDL, a menos que establezca version: "1.1" para un registro cuya guía solicita eso. Donde un registro requiere un certificado de cliente, configure la configuración de tls del destino como para cualquier llamada de HTTPS.

La confirmación del registro decide si el mensaje se entregó, no el estado de HTTP. Un registro responde a un disparo rechazado con HTTP 200 y un AR dentro, por lo que un destino que confiaba en el estado informaría una inmunización perdida como entregada.

warnings_are_errors: true (Tratar advertencias como fallos) hace que cada AE espere a una persona. La respuesta, que los scripts de respuesta y un llamador HTTP que espera en el canal leen, es el mensaje HL7 del registro: el ACK, o el RSP con el historial y el pronóstico. examples/iis contiene tres canales para empezar: VXU desde un EHR sobre MLLP, consultas QBP sobre HTTP y un sustituto local para un registro.

El panel de Conexiones le pide a un registro su connectivityTest cuando no se ha enviado nada durante siete días. Esa operación existe para este propósito y no envía nada, así que es la única comprobación de nivel de aplicación que realiza Perfuse. Demuestra la dirección, TLS y el enlace SOAP, no el nombre de usuario y la contraseña; solo una solicitud real de envío prueba esas.

Un origen SOAP puede responder de la misma manera: Responder como un registro de inmunización, o profile: cdc-iis en el origen. Repite connectivityTest, toma el mensaje de submitSingleMessage, devuelve el acuse de recibo del canal en return y sirve el WSDL de los CDC en ?wsdl. Un nombre de usuario y una contraseña, cuando se establecen, se verifican contra los de la solicitud, y un par incorrecto obtiene la SecurityFault del WSDL. Un mensaje que el canal rechaza se devuelve como un NAK, nunca como una falla, como dice la guía de los CDC. Úselo como un doble de prueba, o para recibir envíos de la manera en que lo hace un registro.

No cubierto: las partes específicas del estado de la incorporación. Cada registro tiene su propio punto de conexión, proceso de cuenta y perfil local de la guía 2.5.1 (campos RXA y OBX requeridos, elegibilidad VFC, códigos de rechazo). Esos son el contenido de los mensajes, que las transformaciones del canal dan forma; ningún punto de conexión del estado está integrado. Perfuse se ha probado contra sí mismo y contra respuestas de registro grabadas, no contra un registro del estado en vivo.

10.9 Cuando el transporte dice sí y el mensaje no llegó

"¿Llegó esto?" a menudo no es una pregunta que el transporte pueda responder. Un receptor MLLP devuelve un acuse de recibo de aplicación cuyo significado está en su texto. Un receptor HTTP devuelve 200 con un documento de error. En ambos casos, el transporte tuvo éxito y el mensaje no llegó.

Inspeccionar la respuesta en un destino toma un script dado la respuesta del receptor. Devuelve falso, o lanza, y la entrega se marca como fallida — lo que significa que se reintenta, se coloca en cola y aparece en el recuento de fallos en lugar de ser contado silenciosamente como entregado.

Se ofrece solo en destinos que reciben una respuesta. En uno que no puede, se rechaza en la carga en lugar de dejarlo nunca ejecutarse.

10.10 Qué significa el resultado de una entrega

Estos se registran por destino por mensaje, así que un mensaje que llegó a tres de cuatro destinos se registra como exactamente eso. No hay un "éxito" a nivel de canal, porque no significaría nada.

10.11 Entrega lenta

Un destino que está aceptando mensajes pero tarda mucho en hacerlo es un problema distinto de uno que está fallando, y es fácil perderlo porque cada resultado es un éxito.

El tipo de alerta slow-delivery existe para esto. Vale la pena configurarlo en cualquier cosa donde el acuse de recibo del remitente espere la entrega, porque un destino cuyo tiempo de respuesta ha aumentado silenciosamente eventualmente cruzará el tiempo de espera del remitente y comenzará a producir reenvíos — y en ese punto el síntoma aparece en el sistema aguas arriba, en un sistema que puede que no administre.

10.12 Escribir en una base de datos

type: database ejecuta una instrucción por mensaje con valores enlazados desde el mensaje.

Los marcadores de posición son del propio controlador — $1 para postgres, ? para mysql y sqlite, @p1 para sqlserver — y Perfuse no los reescribe. Eso es deliberado: una capa de traducción que obtuviera un marcador de posición incorrecto enlazaría el nombre de un paciente con la columna incorrecta, y el resultado parecería datos válidos en lugar de un error.

Una instrucción escrita en el dialecto incorrecto se rechaza cuando se guarda, nombrando el estilo que el controlador quiere. Antes de que existiera esta comprobación, el error surgía como syntax error at or near "," del servidor cuando llegaba un mensaje, que nombra una instrucción que escribió y así lo envía a buscar un error tipográfico en lugar de al dialecto.

destinations:
  - name: warehouse
    type: database
    database:
      driver: postgres
      dsn: ${WAREHOUSE_DSN}
      statement: INSERT INTO messages (mrn, family_name, birth_date) VALUES ($1, $2, $3)
      params:
        - PID-3.1
        - PID-5.1
        - PID-7

Un parámetro entre comillas es una constante en lugar de una ruta, que es cómo un canal escribe su propio nombre o un código de sistema de origen en una fila junto con los datos del mensaje.

Los valores siempre se enlazan como parámetros. Una referencia ${...} dentro de la instrucción se rechaza: un nombre que contiene una comilla simple rompería la instrucción, y un valor hostil la reescribiría.

10.13 Enviar a un socket sin procesar

type: tcp escribe en un socket con un marco que elige, que es lo que normalmente quiere un dispositivo o un instrumento de laboratorio. MLLP es uno de los marcos entre varios; este destino ofrece los demás.

destinations:
  - name: instrument
    type: tcp
    tcp:
      address: instrument.lab:9100
      framing: delimited
      delimiter: \r
      expect_reply: true
      timeout: 30s

El marco no tiene un valor predeterminado, deliberadamente. Escribir con el marco incorrecto no falla. El extremo lejano lee mensajes divididos en los lugares incorrectos, o espera un terminador que nunca llega, y el síntoma aparece en el sistema de recepción en lugar de aquí.

Solo se aceptan los ajustes que utiliza el marco elegido. Una longitud de registro en una secuencia delimitada se rechaza en lugar de ignorarse, porque un ajuste que se ignora silenciosamente es uno que alguien cree que está en efecto.

expect_reply cambia lo que significa entregado. Sin él, el éxito significa que los bytes alcanzaron el búfer de envío del sistema operativo — lo que un peer que se estrelló un momento después nunca leyó.

10.14 Amazon S3, SQS y SNS

Un canal puede leer desde una cola SQS o un prefijo de bucket S3, y entregar a SQS, SNS o S3. Los cinco son HTTP firmados con ninguna SDK de AWS en el binario, y los cinco toman los mismos ajustes de acceso: region, access_key_id, secret_access_key (escribir ${AWS_SECRET_ACCESS_KEY} para leer la variable de entorno), un session_token opcional, y endpoint para LocalStack, MinIO o un punto final de VPC. Bajo Canales → Nuevo canal, elija *Leemos desde una cola Amazon SQS*, *Recopilamos objetos desde un bucket Amazon S3* , o los tipos de destino SQS, SNS y S3.

Nada se confirma a AWS hasta que el canal lo ha manejado. Un mensaje SQS se elimina después y de lo contrario vuelve a aparecer cuando tiempo de espera de visibilidad termina, así que una política de reenvío de una cola es lo que mueve uno que sigue fallando a una cola de carta muerta. Un objeto S3 se mueve a processed/ después, o a error/ si no se pudo manejar, así que un archivo malo no detiene al resto.

En una cola o tema FIFO, los mensajes se agrupan por paciente de forma predeterminada - SQS mantiene el orden dentro de un grupo y en ninguna otra parte - y desduplicados por contenido, así que un reintento no se entrega dos veces.

Un archivo S3 se puede escribir directamente en Glacier con storage_class, y como líneas JSON para Amazon Athena con format: ndjson; perfuse athena imprime la tabla. La referencia tiene todos los ajustes.

10.15 AMQP 1.0 y Azure

AMQP 1.0 es lo que hablan Azure Service Bus y Event Hubs, y RabbitMQ 4, ActiveMQ y Artemis además de sus otros protocolos. Un origen amqp recibe de una cola o una suscripción y acepta cada mensaje solo una vez que el canal lo ha procesado; uno que no se pudo procesar se libera como una entrega fallida, por lo que el broker lo vuelve a entregar y, pasado el límite de la cola, lo envía a la carpeta de mensajes muertos. Un destino amqp informa de éxito solo cuando el broker acepta el mensaje. Para Service Bus: addr es <namespace>.servicebus.windows.net:5671 con tls, username es el nombre de la política de acceso compartido, password es su clave y address es el nombre de la cola, o <topic>/subscriptions/<name> para recibir.

Azure Blob Storage: un destino azure_blob escribe un blob por mensaje en el nivel de acceso elegido - Hot, Cool, Cold o Archive - y un origen azure_blob recoge blobs de un prefijo, moviéndolos a processed/ o error/ como el origen S3 hace. Prefiera un token SAS tlimitado al contenedor sobre la clave de la cuenta.

10.16 MQTT

Un origen mqtt se suscribe a un filtro de tema (+ coincide con un nivel, # con todos los niveles debajo) en cualquier broker MQTT 3.1.1: Mosquitto, EMQX, HiveMQ, AWS IoT Core, Azure Event Grid. En QoS 1, el predeterminado, cada mensaje se confirma solo una vez que el canal lo ha manejado. MQTT no tiene forma de rechazar un solo mensaje, así que uno que no se pudo manejar se deja sin confirmar y la conexión se hace nuevamente; el broker mantiene la sesión bajo la id de cliente (perfuse-<channel> a menos que client_id diga lo contrario) y lo envía nuevamente, primero en la cola. QoS 0 es como máximo una vez: cualquier cosa enviada mientras Perfuse está abajo se pierde. Un destino mqtt publica y, en QoS 1, informa de éxito cuando el broker tiene el mensaje.

source:
  type: mqtt
  mqtt:
    addr: broker.hospital.local:8883
    topic: hl7/+/adt
    username: perfuse
    password: ${MQTT_PASSWORD}
    tls: {enabled: true, ca_file: /etc/perfuse/broker-ca.pem}

AWS IoT Core quiere un certificado de cliente: proporcione tls.cert_file y tls.key_file.

10.17 IBM MQ

ibm_mq lee y escribe colas de IBM MQ a través de la API de mensajería REST del administrador de colas (mqweb), que IBM MQ 9.1.5 y posteriores envían en cada plataforma, incluyendo z/OS, por lo que no se instala ningún cliente de MQ junto con Perfuse. El usuario necesita el rol MQWebUser y la autoridad de poner, obtener y examinar la cola. Un origen examina el primer mensaje, se lo pasa al canal y lo elimina por su id de mensaje solo una vez que se procesó; un mensaje que falla se mantiene al principio de la cola. Ejecute un lector por cola. Un destino coloca mensajes persistentes (a menos que non_persistent), con el id de control de HL7 como el id de correlación.

destinations:
  - name: to-mainframe
    type: ibm_mq
    ibm_mq:
      url: https://mq.hospital.local:9443
      queue_manager: QM1
      queue: HL7.ADT.OUT
      username: perfuse
      password: ${IBM_MQ_PASSWORD}
      tls: {enabled: true, ca_file: /etc/perfuse/mq-ca.pem}

api_version es v3 para MQ 9.3 y posteriores (el valor predeterminado), v2 para 9.1.5 a 9.2. Un administrador de colas con un canal AMQP también se puede alcanzar con el conector amqp.

10.18 Google Cloud Pub/Sub y Cloud Storage

Un origen pubsub extrae de una suscripción y reconoce cada mensaje una vez procesado; uno que falla se devuelve de inmediato (su plazo de reconocimiento establecido en cero), con el resto de su lote, por lo que Pub/Sub lo entrega de nuevo y, pasado la política de carta muerta de la suscripción, lo envía a la carpeta de mensajes muertos. Un destino pubsub publica con el tipo de mensaje de HL7 y el id de control como atributos; order_by: patient establece la clave de ordenación a partir de PID-3.1, por lo que una suscripción con ordenación de mensajes mantiene los mensajes de cada paciente en orden.

Un destino gcs escribe un objeto por mensaje, con un nombre como una clave de S3, en la clase de almacenamiento elegida (STANDARD, NEARLINE, COLDLINE, ARCHIVE). Un origen gcs recoge objetos de un prefijo y los mueve a processed/ o error/ como lo hace el origen de S3.

Ambos se conectan como una cuenta de servicio: credentials_file es su clave JSON. Déjelo vacío en Google Cloud (una VM, GKE o Cloud Run) para usar la cuenta de servicio adjunta allí. endpoint nombra un emulador (el emulador de Pub/Sub, fake-gcs-server), que no requiere credenciales.

source:
  type: pubsub
  pubsub:
    project: hospital-integration
    subscription: adt-to-perfuse
    credentials_file: /etc/perfuse/gcp-key.json

10.19 Leyendo una bandeja de entrada (IMAP y POP3)

Una fuente de email lee una bandeja de entrada y convierte lo que encuentra en mensajes: cada archivo adjunto (take: attachments, el valor predeterminado, restringido por patrones attachment_names), el texto del correo electrónico (take: body), o el correo electrónico completo (take: raw) para que un script pueda desmontarlo. Los laboratorios, centros de imagen y pequeñas prácticas aún envían resultados de esta manera.

Cada comprobación se conecta, lee el correo no leído más antiguo primero y se desconecta. A través de IMAP, un correo electrónico se recupera sin marcarlo como leído, se le pasa al canal y solo una vez que todos los mensajes de él se aceptaron se mueve a move_to (Procesado), se marca como leído (after_read: flag) o se elimina. El correo que falló o que no se tomó (un remitente fuera de allowed_senders, sin adjunto que coincida con attachment_names, más grande que max_message_size), se mueve a error_folder (Error) con la razón en el registro. Ambas carpetas se crean cuando faltan. POP3 no tiene carpetas ni marcas, por lo que elimina: las eliminaciones se confirman con el QUIT al final de la comprobación, por lo que una sesión que se interrumpe no elimina nada y un correo electrónico procesado puede leerse de nuevo (nunca se pierde). El correo de POP3 que no se toma permanece en el servidor y se informa una vez.

La conexión es una contraseña (${MAIL_PASSWORD}; una contraseña de aplicación para Gmail) u OAuth 2.0 a través de SASL XOAUTH2, que Microsoft 365 requiere (ha desactivado la conexión con contraseña) y Gmail prefiere:

source:
  type: email
  email:
    host: outlook.office365.com        # imap.gmail.com, pop.gmail.com, or your server
    username: results-feed@hospital.example
    oauth:
      provider: microsoft              # microsoft, google or custom (with token_url)
      tenant: hospital.onmicrosoft.com
      client_id: 00000000-0000-0000-0000-000000000000
      client_secret: ${MAIL_CLIENT_SECRET}
    attachment_names: ["*.hl7"]
    allowed_senders: [lab.example, results@partner.example]

Con client_secret y sin refresh_token, se utiliza el acceso de aplicación de Microsoft 365 (la concesión de credenciales de cliente, ámbito https://outlook.office365.com/.default): un administrador registra la aplicación, le otorga acceso a IMAP.AccessAsApp y la limita a la única bandeja de entrada con un principal de servicio de Exchange. Con un refresh_token (el consentimiento de una persona), se utiliza el ámbito delegado IMAP.AccessAsUser.All o POP.AccessAsUser.All y se mantiene un token de actualización rotado durante la vida del proceso. Gmail necesita un refresh_token: Google no ofrece acceso de aplicación a una bandeja de entrada.

allowed_senders acepta direcciones y dominios. La línea De un correo electrónico se puede falsificar, por lo que mantiene alejados los accidentes y el correo electrónico extraviado, no a un atacante; una fuente que debe ser de confianza pertenece a Direct (S/MIME firmado), SFTP o una VPN. security es tls (993 o 995, el valor predeterminado), starttls (143 o 110) o none, que solo se permite a localhost. Las comprobaciones están separadas por al menos 10 segundos (60 por defecto), porque los servicios de correo electrónico limitan las cuentas que verifican más rápido.

Probado contra GreenMail 2.1.3 (IMAPS, IMAP, POP3S y POP3: se deniega la conexión con una contraseña incorrecta, recuperación sin marcar como leído, MOVER, marca, eliminar, un correo electrónico demasiado grande se rechaza antes de que se lea) y contra el IMAP de Gmail con una contraseña de aplicación (crear una carpeta, agregar, recuperar, MOVER, eliminar). Se probó OAuth contra un punto final de token de reemplazo solo: no contra Microsoft o Google.

10.20 AS2

AS2 (RFC 4130) es cómo muchos pagadores, casas de compensación y proveedores intercambian EDI: un POST de HTTP cuyo cuerpo está firmado con el certificado del remitente y cifrado para el receptor, respondido con un recibo (un MDN) que nombra un resumen de lo que llegó. El S/MIME es el mismo código que utiliza el mensajería Direct. Ambos extremos están en el constructor de canales: Los socios comerciales nos envían EDI a través de AS2 como un origen, Un socio comercial a través de AS2 como un destino.

# receive: partners post here
source:
  type: as2
  as2:
    listen: ":4080"            # path /as2 by default
    id: HOSPITAL-AS2           # our AS2 identifier (AS2-To)
    cert_file: as2/ours.crt    # partners encrypt to this
    key_file: as2/ours.key     # and receipts are signed with it
    tls: { enabled: true, cert_file: tls.crt, key_file: tls.key }
    partners:
      - id: PAYER-AS2
        cert_file: as2/payer.crt
dataType: x12

# send
destinations:
  - name: payer
    type: as2
    as2:
      url: https://as2.payer.example/as2
      from: HOSPITAL-AS2
      to: PAYER-AS2
      cert_file: as2/ours.crt
      key_file: as2/ours.key
      partner_cert_file: as2/payer.crt
      file_name: "${control_id}.x12"

Recepción. Un mensaje a cualquier otro AS2-To, o de un remitente que no esté en partners, es rechazado con 403 y sin recibo. El mensaje de un partner debe estar firmado y cifrado a menos que su entrada establezca allow_unsigned o allow_unencrypted. La carga útil se descifra, se verifica su firma contra el certificado del partner (los partners suelen intercambiar certificados auto-firmados, lo que está bien: el certificado es la confianza), y se le entrega al canal según lo que dice su formato de mensaje. El partner recibe el recibo que solicitó: en la respuesta, o publicado en su URL Receipt-Delivery-Option; firmado cuando lo solicitó. Un mensaje que falla recibe un recibo que nombra el motivo (decryption-failed, authentication-failed, insufficient-message-security, unexpected-processing-error).

Envío. Cada mensaje está firmado (SHA-256) y cifrado (AES-256-CBC). Con receipt: sync, el valor predeterminado, se considera entregado solo cuando el recibo verifica contra partner_cert_file, dice processed, y lleva el mismo resumen (MIC) que lo que se envió; anything else es una entrega fallida y se reintenta. receipt: async solicita el recibo en receipt_url, que debe ser una fuente AS2 en este servidor que enumere al partner: el mensaje se considera entregado una vez que el partner acepta la solicitud, y un recibo que posteriormente no esté de acuerdo se registra como un error. receipt: none solicita nada. unsigned, unencrypted y unsigned_receipt relajan cada parte para un acuerdo que lo diga; username y password agregan autenticación básica HTTP para pasarelas que lo requieren. El tipo de contenido sigue el formato del canal (application/edi-x12 para X12) a menos que content_type establezca uno.

Triple DES, AES-128 y AES-192 se leen así como AES-256, ya que los partners todavía los envían, y también se lee el streaming BER (longitudes indefinidas) que escriben las pasarelas de Java.

Compresión (RFC 5402). Un mensaje comprimido se lee de cualquier manera que se haya construido: comprimido antes de firmar o cifrar, o un mensaje firmado comprimido en su totalidad. El resumen (MIC) del recibo sigue el RFC: sobre lo que se firmó cuando está firmado, sobre el contenido sin comprimir cuando no lo está. Un mensaje que se expandiría más allá de diez veces el max_message_size de la fuente se rechaza con decompression-failed, para que unos pocos kilobytes no puedan reclamar gigabytes de memoria. Un destino se comprime con compress: true, antes de firmar y cifrar, como lo hacen la mayoría de las pasarelas; pregúntele al partner primero.

Un mensaje enviado dos veces. Un partner que nunca recibió nuestro recibo envía el mensaje nuevamente con el mismo Message-ID (RFC 4130 sección 7.5). La fuente recuerda cada Message-ID de los partners para duplicate_window (predeterminado 720h, 30 días; al menos una hora) y responde a una reenvío con un recibo processed sin pasarla nuevamente. El registro se mantiene en la base de datos, para que un reinicio no lo olvide. Un mensaje cuyo procesamiento falló no se recuerda, para que el reintento del partner se realice. Las copias que llegan al mismo momento esperan una a la otra, y solo la primera se pasa. Si el registro no se puede leer, el mensaje se rechaza con unexpected-processing-error y el partner reintenta más tarde, en lugar de arriesgarse a una copia adicional. Un mensaje sin Message-ID no se puede reconocer y se registra como tal.

La interoperabilidad se prueba contra pyas2lib 1.4.3 en ambos sentidos, con Triple DES y AES-256, comprimidos y no, con recibos sincrónicos firmados incluidos.

10.21 OpenPGP

Los pagadores, las casas de compensación y las agencias estatales a menudo toman y envían archivos solo bajo OpenPGP. Un bloque pgp en una fuente abre lo que llega; uno en un destino protege lo que sale. Ambos están en el constructor de canales: Mensajes cifrados con Open PGP bajo la fuente, Cifrar con OpenPGP en cada destino.

source:
  type: sftp
  sftp: { host: sftp.payer.example, user: hospital, key_file: keys/id_ed25519, dir: outbound }
  pgp:
    decrypt_with: keys/our-secret.asc      # our secret key, armored or binary
    passphrase: ${PGP_PASSPHRASE}
    verify_with: [keys/payer.asc]          # the senders' public keys
    require_signature: true
destinations:
  - name: claims
    type: sftp
    sftp: { host: sftp.payer.example, user: hospital, key_file: keys/id_ed25519, dir: inbound,
            file_name: "${date}-${control_id}.x12.pgp" }
    pgp:
      encrypt_to: [keys/payer.asc]
      sign_with: keys/our-secret.asc
      passphrase: ${PGP_PASSPHRASE}

Los archivos de claves se leen relativos al archivo del canal y se leen y desbloquean cuando se carga el canal: una clave faltante o una frase de contraseña incorrecta detiene el canal allí, no en el primer archivo.

• En una fuente, todo el archivo, objeto, archivo adjunto de correo electrónico o cuerpo de la solicitud se

abre primero y luego se divide en mensajes, para que un lote cifrado como un archivo funcione. Uno que no se puede abrir se rechaza: una fuente de archivo lo mueve a su carpeta de error, un remitente HTTP responde 400 con la razón. require_signature rechaza un mensaje que no esté firmado por uno de verify_with; allow_unencrypted acepta uno que solo esté firmado; pass_plain deja que un mensaje que no sea PGP en absoluto pase sin cambios, para una carpeta que recibe ambos.

• En un destino, lo que se habría entregado se cifra (con cualquiera de

encrypt_to) y se firma (con sign_with), después de cada otro paso. Un destino de archivo, SFTP, FTP, S3, Azure Blob o GCS todavía nombra el archivo a partir del mensaje sin formato, para que ${control_id} funcione, y cualquier estructura está dentro del cifrado. armor: true escribe texto .asc en lugar de binario; no_compress desactiva la compresión; file_name es el nombre que se transporta dentro del mensaje.

Los mensajes se escriben con AES-256 en el formato RFC 4880 que los receptores más antiguos leen, y el formato RFC 9580 más nuevo se lee también. La criptografía es ProtonMail/go-crypto; Perfuse no implementa primitivos. La interoperabilidad se prueba contra GnuPG en ambos sentidos: gpg descifra y verifica lo que escribe Perfuse, y Perfuse abre y verifica lo que escribe gpg.

10.22 Entrega a otro canal

Un destino de canal entrega el mensaje a otro canal por nombre. El canal receptor lo trata como cualquier otra llegada: lo registra, lo filtra, lo transforma y lo distribuye.

Esta es la forma compatible de construir una cadena. Está deliberadamente visible — dos canales, dos conjuntos de estadísticas, dos entradas en el historial de mensajes — porque una cadena oculta dentro de un canal es una cadena que nadie puede supervisar.

El mensaje se entrega en memoria en lugar de a través de una red, por lo que no hay estructura, no hay reconocimiento y no hay tiempo de espera entre los dos.

10.23 Qué sucede cuando se mata el proceso

La pregunta que cualquier persona que haya ejecutado un motor de interfaz hace primero, y la que rara vez se responde, porque la respuesta honesta suele ser vergonzosa.

Se respondió matando el proceso con SIGKILL a mitad de un lote — lo que es lo que una falla de energía, una matanza por falta de memoria y un reinicio de hipervisor parecen desde adentro — y contando lo que sobrevivió contra lo que se había prometido.

La propiedad que se prueba no es "nada se pierde". Eso no es alcanzable y afirmarlo sería una mentira. Es la promesa más estrecha que un remitente realmente confía en: un mensaje que fue positivamente confirmado es un mensaje que llegó.

Con ack.when: on_delivery, que es el valor predeterminado, cada destino se escribe antes de que se envíe el acuse de recibo, por lo que un AA es una declaración sobre el destino en lugar de sobre una cola. Un mensaje eliminado antes de su acuse de recibo puede perderse, y eso es correcto: el remitente nunca se le prometió nada y lo enviará de nuevo.

10.23.1 Confirmación de entrega

Cinco ejecuciones, asesinadas después de 5, 25, 40, 75 y 110 mensajes de 120.

La promesa se mantuvo en cada punto de eliminación, y nada se duplicó. Una duplicación habría sido aceptable y una pérdida no: un A08 reenviado es una molestia que los receptores absorben, y un resultado de laboratorio que nunca llegó silenciosamente es un evento de seguridad del paciente.

10.23.2 Confirmación de recepción

on_receipt responde tan pronto como el mensaje se coloca en la cola, antes de que se haya escrito algún destino. Este capítulo siempre ha dicho que un mensaje confirmado aún puede perderse de esta manera. Aquí está el tamaño de ello.

Esencialmente todo lo que está en vuelo. La configuración no es un defecto y hay fuentes donde es la elección correcta, pero debe elegirse sabiendo que un bloqueo descarta lo que ha sido confirmado y no escrito, y que esto es casi todo de un estallido.

Nada se recupera al reiniciar, porque perfuse run no tiene un almacenamiento duradero. Un destino que no debe perder mensajes durante una interrupción necesita queue.enabled, que necesita la base de datos que proporciona perfuse serve — y perfuse run ahora rechaza ese canal en lugar de iniciarlo sin la cola.

10.23.3 Un remitente que muere a mitad de camino de un mensaje

El más peligroso de estos errores, porque un mensaje HL7 truncado suele seguir analizando. Los segmentos antes del corte son completos y bien formados, por lo que un receptor no tiene forma de saber que llegaron los segmentos PID y PV1 y no llegaron los segmentos OBX que transportan los resultados.

Se abrió un marco, se envió seis décimas partes de un mensaje y la conexión se restableció en lugar de cerrarse. El mensaje parcial no se entregó, el oyente sobrevivió y un mensaje bien formado enviado inmediatamente después se aceptó de manera normal, por lo que el fragmento no se llevó al siguiente mensaje tampoco.

El registro de conexión ahora informa cuántos bytes de un marco sin terminar se abandonaron, para cada modo de falla en lugar de solo un cierre ordenado. Anteriormente, un remitente bloqueado, un proceso asesinado y un cable arrancado todos registraron messages=0 y nada más, lo que no puede distinguir una comprobación de salud vacía de un resultado de laboratorio tirado nueve décimas partes del camino.

10.23.4 Un disco lleno

Se detecta y registra el agotamiento de espacio en lugar de tragarse. Hay dos cosas sobre ello que vale la pena saber.

El remitente no recibe un rechazo inmediato. La entrega se reintenta según el horario habitual — un segundo, dos, cuatro, ocho — y el acuse de recibo negativo llega unos quince segundos después. Un remitente cuyo propio tiempo de espera es más corto que ese ve una conexión bloqueada en lugar de un AE, y concluirá que la red es la culpable en lugar del disco.

Y un volumen que informa de cero bytes libres aún puede aceptar pequeños apéndices durante un tiempo, porque agregar un par de cientos de bytes a un archivo cuyo último bloque tiene espacio no necesita una nueva asignación. El primer fallo de escritura es posterior al momento en que el disco se llenó.

10.23.5 Lo que no se probó

Un directorio de destino que pierde el permiso de escritura. No se puede inyectar con chmod: el motor mantiene el archivo de salida abierto y cambiar el modo de un archivo no afecta a un descriptor que ya se ha abierto contra él. Probarlo adecuadamente requiere que el volumen se vuelva a montar de solo lectura o se elimine debajo del proceso, lo que no se ha hecho. Se nombra aquí en lugar de omitirlo, porque una brecha que nadie menciona se lee como una brecha que nadie buscó.

11 Alertas

Nada fuera de Perfuse le dirá que una fuente ha dejado de funcionar. El remitente está siendo confirmado y está satisfecho; el receptor no tiene forma de saber que se envió un mensaje. Las alertas son lo único que se encuentra entre una interfaz rota y alguien que se da cuenta semanas después.

11.1 Los tipos de alertas

Los últimos cuatro vigilan el acceso a los datos de los pacientes y se describen a continuación.

11.2 El silencio es lo más difícil de detectar

Un canal que ha dejado de recibir mensajes no produce errores. No hay nada que contar. Es por esto que existe no-traffic y por lo que no es suficiente por sí solo.

no-traffic es un umbral fijo: alertar si nada ha llegado durante, por ejemplo, dos horas. En un flujo que genuinamente nunca se detiene, funciona. En un flujo de laboratorio de una clínica es inútil — el flujo está en silencio todas las noches y todos los fines de semana, por lo que un umbral de dos horas envía una página a alguien a la 1 am todas las noches, y un umbral lo suficientemente largo como para sobrevivir al fin de semana no notará una interrupción el martes por la mañana hasta el martes por la tarde.

No hay un solo número que sea ambos. Eso no es un problema de ajuste; es que la pregunta "¿ha detenido este flujo" no puede ser respondida por una constante cuando el flujo normal varía por un factor de cien a lo largo de la semana.

11.3 Detección consciente del ritmo

below-rhythm compara el tráfico actual con lo que este canal normalmente hace en esta hora de este día de la semana.

Perfuse aprende la semana de cada canal a partir de su propia historia registrada: 168 cubos horarios, comenzando el lunes para que una semana laboral sea contigua. Para cada cubo, mantiene una mediana, un valor bajo y un valor alto, un piso y cuántas observaciones se basa.

El umbral es una parte del normal, que por defecto es 0.8 (80 por ciento en la consola) — alertar cuando el tráfico cae por debajo de cuatro quintos de lo que es normal para esta hora.

11.3.1 Mediana, no media

Un solo flujo de retraso de cuarenta mil mensajes contra un normal de trescientos mueve la media lo suficiente como para que el flujo pueda ir completamente en silencio después sin caer nunca por debajo de ella. La mediana no se ve afectada por una hora extraordinaria, que es exactamente la propiedad necesaria.

11.3.2 El piso es un percentil, no el mínimo

Si el ritmo de un canal es lo suficientemente confiable como para alertar se decide por su extremo bajo, no por su extremo alto. Una alerta de escasez se dispara cuando el tráfico es *bajo*, por lo que solo el extremo bajo puede decir si producirá falsos positivos. Una versión temprana de esto comparó el alto con la mediana y se equivocó en ambos sentidos al mismo tiempo: descalificó un flujo perfectamente estable durante un mes después de un retraso y aprobó un flujo genuinamente errático que oscilaba entre dos y novecientos mensajes en la misma hora porque su alto era solo tres veces su mediana.

El piso es el percentil vigésimo en lugar del mínimo, porque el mínimo es arrastrado a cero por un solo feriado bancario. Y el percentil no se interpola — cada número en una alerta a las dos de la mañana debe ser una cuenta que el flujo realmente produjo, no un promedio de dos cuentas que no produjo.

11.3.3 Dirá cuándo no puede decir

Un canal con ninguna historia en absoluto se omite por completo en lugar de ser tratado como uno que se ha detenido. Un nuevo canal no debe parecer uno roto.

Donde la historia es demasiado delgada o demasiado errática para respaldar un juicio, la regla se niega a disparar en lugar de adivinar. "No puedo decir honestamente" es una respuesta de primera clase aquí, y se prefiere a una alerta que está en lo correcto ligeramente más a menudo que la casualidad.

11.4 Configuración de alertas

Desde la interfaz, bajo Alertas, por canal o en todos ellos. Cada regla tiene un tipo, un umbral y dónde enviar la alerta. Las reglas se guardan en alerts.yaml junto a la base de datos (o el archivo -alerts nombra) y surten efecto de inmediato; hasta el primer guardado, las reglas integradas se aplican. El archivo también se puede editar manualmente: el cambio se recoge dentro de treinta segundos, y un archivo que ya no se carga se informa en el registro y se mantienen las reglas en vigor.

Vale la pena hacer antes de que un flujo se ponga en vivo en lugar de después del primer incidente. El conjunto específico que vale la pena tener en cualquier flujo clínico:

1. below-rhythm — el flujo se ha detenido cuando no debería estar en silencio.
2. error-rate — los mensajes están llegando y fallando.
3. queue-age — algo está atascado en lugar de simplemente estar ocupado.
4. channel-down — el canal no se está ejecutando en absoluto.

El primero es el que atrapa el fallo que nadie más informará.

11.5 Vigilando el acceso a los datos de los pacientes

Una violación rara vez se anuncia. Parece un flujo que lleva más de lo habitual, tráfico a las tres de la mañana en un canal que solo funciona durante las horas de oficina, un destino que nadie configuró, o una persona que abre paciente tras paciente. Perfuse vigila estos cuatro, activados por defecto (serve -watch-access=false los desactiva), e informa lo que ve a través de las reglas de alerta anteriores, por lo que está configurado, confirmado y entregado como cualquier otra alerta.

• Explosiones (phi-volume). La tasa de cada canal se compara con su propia historia en la misma hora del día, por lo que una mañana ocupada no es noticia. El umbral es un múltiplo de la tasa habitual, tres por defecto. Una explosión suele ser un retraso que se libera después de un tiempo de inactividad, y también es lo que los registros extraídos a través de un flujo parecen.
• Tráfico nocturno en un canal diurno (phi-after-hours). Un canal se considera diurno cuando menos del 2 por ciento de lo que ha transportado cayó fuera de las 07:00 a 19:00, en la zona horaria del servidor.
• Un nuevo destino (phi-new-destination). La dirección es lo que el destino nombra: un host y un puerto, una URL, una carpeta. Renombrar un destino no es noticia; apuntar a un nuevo host es. Las direcciones a las que cada canal ha enviado se mantienen en access-watch.json junto a la base de datos, por lo que un destino cambiado mientras el servidor estaba inactivo aún se informa.
• Lecturas masivas (phi-bulk-reads). Contadas desde el registro de auditoría: mensajes abiertos, pacientes buscados o consultados (PDQm, PIXm, búsqueda de identidad), documentos e imágenes leídos (XDS, MHD, DICOMweb), autorizaciones previas leídas, resúmenes y vistas ejecutadas. Leer el mismo registro nuevamente no cuenta dos veces. El umbral es cuántos registros diferentes en un minuto, diez por defecto, por una cuenta desde una dirección.

Nada se juzga para un canal hasta que haya transportado 200 mensajes, porque "inusual" no significa nada sin un patrón. El patrón se aprende de las últimas dos semanas de la tienda de mensajes cuando el servidor comienza, por lo que un reinicio no hace que cada canal sea nuevo de nuevo. Cualquier cosa vista se mantiene durante quince minutos, luego la alerta se borra.

Solo vigila e informa. Nunca retiene un mensaje ni rechaza una lectura: estas son heurísticas, y un flujo detenido porque una suposición estaba mal es un problema clínico. Cada alerta dice qué se vio y qué podría ser inocentemente, porque la mayoría de ellas serán inocentes.

Los administradores ven lo que el monitor ha aprendido en la pantalla de alertas, bajo Vigilando el acceso a los datos de los pacientes: el patrón de cada canal (todavía aprendiendo, solo diurno o diurno y nocturno), cuántos destinos conoce y todo lo visto en los últimos quince minutos, incluyendo lo que está por debajo del umbral de una regla.

11.6 Dónde van las alertas

Las alertas se pueden enviar como JSON a un webhook (-alert-webhook: Slack, Teams, Mattermost, PagerDuty, Alertmanager o cualquier cosa que acepte un POST), se pueden enviar como trampas SNMPv2 a administradores de SNMP (-snmp-traps, véase SNMP), o se pueden escribir en el registro para que un colector lo recopile. No hay entrega de correo electrónico propia: apunte el webhook a un relé si las alertas deben llegar como correo electrónico.

Una alerta que solo se escribe en un registro que nadie lee no está alertando. Si Perfuse es la única cosa que notará un flujo detenido, la alerta tiene que llegar a una persona.

12 La Tienda de Mensajes

Cada mensaje que Perfuse recibe se registra, tal como se recibió, antes de que nada lo modifique. Lo mismo sucede con lo que se envió a cada destino y lo que le sucedió. La tienda es un archivo SQLite dado por -db.

12.1 Qué se mantiene

Por mensaje: los bytes brutos tal como llegaron, cuándo llegaron, qué canal, el tipo de mensaje analizado y el evento de activación, y el resultado del filtro.

Por destino por mensaje: los bytes que se enviaron, el resultado, el tiempo que se tardó y cualquier error o acuse de recibo negativo recibido.

Esta es la forma que necesita una investigación. "¿Qué nos enviaron", "¿qué les enviamos" y "¿qué dijeron sobre ello" son tres preguntas diferentes y cada una de ellas se hace.

12.2 Búsqueda

Por canal, por rango de tiempo, por resultado, por tipo de mensaje y evento de activación, y por valor de campo.

La búsqueda de campos funciona en el mensaje analizado, por lo que buscar un número de registro lo encuentra dondequiera que viva ese campo en el mensaje, en lugar de coincidir con los dígitos en cualquier lugar del texto. Una búsqueda de texto para 12345 en un mensaje que contiene una cantidad de 12345 encuentra un mensaje que no tiene nada que ver con el paciente que está buscando.

12.3 Repetición y reprocesamiento

Debido a que se mantiene el original, un mensaje se puede ejecutar a través de la configuración actual nuevamente.

Seguimiento toma un mensaje grabado y muestra qué haría el canal con él ahora, sin enviar nada. Cubierto en depuración.

Reprocesar lo vuelve a ejecutar realmente, incluyendo la entrega. Esto es lo que corrige un lote de mensajes que fallaron porque un destino estaba mal configurado: corrija la configuración, seleccione los mensajes afectados, reprocese.

12.4 Caducidad

Un seguimiento de un mensaje antiguo contra la configuración actual está respondiendo a una hipótesis: ¿qué *sucedería* ahora. Eso es lo que normalmente se desea, pero no siempre — si está investigando qué salió mal el martes pasado, el canal puede haber cambiado desde entonces.

Perfuse detecta esto y lo indica. Un seguimiento de un mensaje que llegó antes de que el canal se editara por última vez se marca como tal, para que la respuesta no se confunda con una reconstrucción de lo que realmente sucedió.

12.5 Retención

La tienda crece. cleanup.periodDays controla cuánto tiempo se mantienen los mensajes.

Dos cosas que sopesar. Los mensajes clínicos pueden estar sujetos a requisitos de retención que son más largos que cualquier cosa que elegiría por razones operativas, y la tienda no es el sistema de registro — el sistema receptor es. La copia de Perfuse existe para diagnosticar y reprocesar, y ambas necesidades disminuyen bruscamente después de unas semanas.

La retención también decide cuánta historia tiene el aprendiz de ritmo para trabajar. Vea alertas: una ventana de retención más corta que unas semanas deja que no pueda distinguir un domingo tranquilo de una alimentación detenida.

12.6 La tienda contiene datos clínicos

Esta es la parte de Perfuse que contiene información de pacientes, y debe tratarse como tal: en almacenamiento cifrado, respaldado como datos clínicos y controlado de acceso. Vea seguridad.

Los mensajes de prueba generados descritos en pruebas existen en parte para que estos datos no tengan que salir del entorno para reproducir un problema en otro lugar.

13 Depuración

La pregunta es casi siempre la misma: este mensaje llegó, algo salió mal, ¿dónde cambió? Perfuse responde mostrando cada paso al reproducir un mensaje grabado a través de la configuración actual.

Nada se envía mientras se realiza un seguimiento. El canal sigue funcionando sin cambios y no se necesita volver a implementar.

13.1 Seguimiento de un mensaje

Seleccione cualquier mensaje grabado y realice un seguimiento. El resultado muestra, en orden:

• Qué leyó el filtro. Qué campos examinó y qué valores encontró. Un filtro que rechaza todo generalmente lee una ruta que no existe en esta fuente, y esto lo nombra.
• Cada transformación. Qué cambió, de qué a qué.
• Qué decidió cada destino. Si aceptaría el mensaje y por qué no si no lo haría.
• La salida. El mensaje tal como cada destino lo enviaría.

13.2 Paso a paso

La vista paso a paso ejecuta cada transformación por separado y captura una instantánea del mensaje completo después de cada una. Una barra numerada de pasos, coloreada según lo que sucedió, y el mensaje tal como estaba en cada punto.

El mensaje completo en lugar de solo el cambio, porque el cambio a menudo no está donde está el problema — un paso que modificó correctamente el campo al que apuntaba, en un mensaje donde un paso anterior ya había colocado lo incorrecto allí, parece perfectamente correcto en aislamiento.

13.3 Cuatro resultados y la distinción que importa

no-effect y skipped se informan por separado, y este es el punto de toda la característica.

Desde afuera son idénticos: el mensaje es el mismo después de cualquiera de los dos. Significan cosas opuestas. skipped significa que la condición funcionó como se escribió y este mensaje no era uno al que se aplicaba — generalmente correcto. no-effect significa que el paso se ejecutó y no encontró nada que hacer, lo que generalmente significa que está dirigido a un campo que no está allí.

Un motor que informa ambos como "nada sucedió" te deja sin poder distinguir una condición funcional de una ruta rota, y esa es la falla de transformación más común que existe.

13.4 Prueba de un cambio antes de guardarlo

El constructor puede ejecutar una configuración candidata contra tráfico grabado y informar qué diferiría. Esta es la forma más segura de cambiar un canal en vivo: realice la edición, vea qué efecto tiene en los últimos cientos de mensajes reales y luego guarde.

También es la forma de descubrir que un cambio que parece obviamente correcto afecta mensajes que no había pensado — un paso condicionado a un evento de activación, en una fuente que resulta llevar cuatro.

13.5 Qué no puede decirte el seguimiento

Ejecuta la configuración actual. Si el canal se ha editado desde que llegó el mensaje, el seguimiento es hipotético en lugar de una reconstrucción, y Perfuse lo marca como tal en lugar de dejar que la distinción pase silenciosamente.

Tampoco ejercita el transporte. Un seguimiento muestra qué se enviaría, no si el destino lo aceptaría — un mensaje correcto y un destino que rechaza conexiones producen un seguimiento limpio y una entrega fallida. Esos son visibles en el registro de entrega en su lugar.

13.6 Scripts

Un script es un paso opaco en el seguimiento. Perfuse puede mostrar qué se introdujo y qué salió, y no puede mostrar qué sucedió en el medio o qué campos se leyeron.

Este es el costo concreto de utilizar un script en lugar de pasos declarativos, y vale la pena sopesarlo al elegir. Consulte transformation.

14 Pruebas

El consejo estándar para probar una interfaz es construir mensajes de muestra que reflejen su propio entorno — los códigos de su laboratorio, su mezcla de casos, los hábitos de su remitente — y quitar los datos de paciente a mano. Eso es lento, y hacerlo de manera incompleta es el resultado normal.

Perfuse ofrece tres cosas en su lugar: tráfico generado que coincide con la forma de una fuente sin su contenido, un canal propuesto a partir de una muestra que alguien le envió, y una comparación con el motor que está reemplazando.

14.1 Tráfico de prueba generado

Si un canal ha manejado mensajes, Perfuse puede producir más mensajes similares a ellos.

¿Qué es fiel:

• Desencadenar eventos en las proporciones realmente observadas, con al menos uno de cada uno para que un evento raro aún aparezca.
• Campos poblados a las tasas que realmente son — por lo que el caso en el que un campo está *ausente* se prueba, que es el caso que rompe las cosas.
• Repeticiones donde ocurren repeticiones, estructura compuesta donde ocurre.
• Códigos extraídos de las tablas de códigos realmente vistas.

¿Qué no es fiel, y esto se establece en lugar de implicar: coherencia clínica. Un paciente generado tiene un número de registro no relacionado, una cadena con forma de nombre y un diagnóstico sin relación con la observación. Estos mensajes ejercitan una interfaz. No son un conjunto de pruebas clínicas y no se pueden utilizar para validar la lógica clínica.

14.1.1 ¿Por qué no contiene datos reales

El argumento es estructural en lugar de una afirmación sobre el esfuerzo. La única entrada del generador es el perfil de tráfico del canal, y un perfil contiene tasas de llenado, formas, longitudes, recuentos de repeticiones y frecuencias de segmentos. No contiene valores.

La única excepción son los campos de tablas de códigos, y un código no identifica a nadie.

Esta es una garantía más fuerte que la desidentificación de mensajes reales, que es un proceso que se puede realizar de manera incompleta y generalmente se hace. Aquí no hay camino por el cual un nombre podría llegar a la salida, porque el nombre nunca estuvo en la entrada.

Cada mensaje generado se analiza antes de devolverlo — un corpus no analizable enviaría a alguien a buscar un error en su interfaz que en realidad es un error en el generador — y cada uno está marcado T en MSH-11, con una aplicación y facilidad de envío sintéticas a propósito.

14.2 Construir un canal a partir de una muestra

Pegue el mensaje que un laboratorio, hospital o proveedor le envió por correo electrónico y Perfuse propone un canal para él. No es necesario que nada esté en ejecución primero.

Maneja lo que la gente realmente pega: varios mensajes en un bloque, cualquier terminación de línea, encuadre MLLP que sobrevivió a la copia y la nota de cobertura sobre el mensaje. Rechazar una muestra porque llegó con terminaciones de línea de Windows sería un obstáculo en lugar de una verificación.

14.2.1 Tres listas

La propuesta viene con lo que la muestra muestra, lo que se ha adivinado y lo que la muestra no puede decirle — tres listas separadas, con igual peso en la interfaz.

Están separadas porque un lector que no puede decir cuál es cuál tiene que verificar todo o confiar en todo, y ambas opciones son peores que saber dónde buscar.

A partir de un solo mensaje, los límites se nombran específicamente en lugar de de manera general: qué campos son opcionales, qué segmentos se repiten, qué códigos existen más allá de los que están aquí, si el remitente alguna vez envía un evento de disparo diferente. Una advertencia general es algo que la gente pasa por alto.

La confianza es una palabra — baja, moderada, razonable — nunca un porcentaje. Un porcentaje implica un cálculo, y esto es un juicio sobre la cantidad de muestras que hay.

Los segmentos Z se llaman por su nombre, porque un segmento local es la cosa que no menciona ninguna especificación y es la razón más común por la que un canal construido a partir de una plantilla estándar no funciona.

14.2.2 La advertencia de separador

Si el separador de campos de la muestra no es el usual |, eso aparece primero, y la confianza disminuye a baja.

La razón es un fallo silencioso genuino. HL7 toma su separador de campos del mensaje en sí, por lo que una muestra cuyas tuberías han sido reemplazadas por similares tipográficos — lo que hace un procesador de texto — se analiza perfectamente en campos que están todos mal. No hay errores en ninguna parte.

Rechazar dicha muestra sería incorrecto, porque un remitente puede legítimamente utilizar otro separador. Por lo tanto, se marca, se nombra el carácter y se sugiere solicitar un archivo de texto plano.

14.3 Comparación con el motor antiguo

Antes de mover una fuente de datos en vivo, la pregunta es si Perfuse produce la misma salida que la cosa que ha estado funcionando durante años. Nada de la calidad del diseño responde a eso. Consulte migración.

14.4 Verificando contra la cosa real, en contenedores

Tres comprobaciones se ejecutan contra implementaciones reales en lugar de contra la propia idea de Perfuse de un protocolo. Estas viven fuera de make check porque necesitan un entorno de ejecución de contenedores, y una comprobación que necesita Docker es una comprobación que la gente deja de ejecutar.

scripts/interop-up.sh inicia todos ellos e imprime lo que cada uno desbloquea.

Cada uno salta en lugar de fallar cuando su contenedor está ausente, por lo que make check pasa en una máquina con no Docker.

Por qué esto está separado del resto de la suite. Cada otra prueba de estas características tenía ambas mitades escritas aquí: un documento que este código base firmó, leído por el código que lo firmó. Eso es acuerdo con uno mismo, y vale menos de lo que parece.

El canonizador SAML es el caso que prueba el punto. Llevaba mil líneas de pruebas, cinco de ellas específicamente sobre la canonización, y todas pasaron mientras ningún proveedor de identidad real podría haber firmado a nadie — la forma canónica que una firma cubre se calculó con prefijos de namespace eliminados, y la única forma de encontrar eso fue entregarle un documento que Perfuse no había escrito.

Dos de las ocho comprobaciones encontraron defectos directamente, y una tercera provocó una mejora real. Tres no encontraron nada mal. Esa proporción es el argumento para mantener todos ellos: una comprobación que pasa ha dicho algo que no se podría haber sabido de otra manera, y no había forma de saber de antemano cuáles serían.

Un patrón que vale la pena nombrar, porque apareció en ambos defectos: la aceptación no es verificación. HAPI aceptó el sistema de identificador malformado y lo almacenó; el defecto solo apareció al leer el recurso de nuevo. Un receptor que tolera algo no es evidencia de que esté bien, solo de que este receptor fue indulgente.

Dos afirmaciones capturadas se comprometieron, en internal/saml/testdata/keycloak-assertion.xml y entra-response.xml, con pruebas sobre ambas — para que esa regresión particular se capture sin un contenedor.

Ambos son necesarios en lugar de que uno sea de repuesto. Keycloak prefija su aserción y firma, Entra no, y esos son los dos casos opuestos en la canonización — que es precisamente donde estaba el defecto. Una prueba afirma cada documento todavía cubre su propio caso, porque una captura de reemplazo que sucedió que estuviera prefijada reduciría silenciosamente la cobertura sin fallar nada. La lección general no se generaliza tan barato: para cualquier otra cosa, el contenedor es la comprobación.

14.5 Diagnosticar una prueba que falla una vez y nunca más

Una prueba que falla en una ejecución completa y pasa sola dieciséis veces no es una prueba inestable. Es una prueba que compartió algo con la ejecución, y la forma de descubrir qué es medir la cosa compartida en lugar de la prueba.

Existen dos instrumentos para esto, y ambos están destinados a ejecutarse junto con una suite completa:

./scripts/e2e-watchdog.sh /tmp/watchdog.log     # the HTTP server and the shared session
./scripts/e2e-mllp-probe.py /tmp/mllp.log       # the fixture channel's listener

Cada uno descubre los puertos de la ejecución desde el archivo de estado de configuración propio y muestrea cada 500 milisegundos hasta que el servidor sale. Registra cada muestra en lugar de solo los fallos, lo que los hace útiles: un error se muestra en una ejecución donde nada falló, por lo que una falla que aparece una vez en tres ejecuciones se vuelve medible en cada una.

Establezca PERFUSE_E2E_KEEP=1 para mantener el directorio temporal, que contiene la base de datos tal como se dejó y el registro del servidor para toda la ejecución. El registro del servidor suele ser la respuesta. En un caso investigado, registró que un canal se detuvo y su oyente se volvió a enlazar 421 milisegundos después, y la conexión rechazada del sonda cayó dentro de esa ventana.

Lea la traza en lugar de error-context.md, que ha estado vacío en más de una ocasión donde la traza contenía el mensaje real.

Copia los artefactos antes de volver a ejecutar algo. Una ejecución que pasa borra test-results, por lo que la traza del error que está investigando desaparece en el momento en que intenta reproducirlo. Una vez perdido, la pregunta que habría respondido no puede ser respondida.

Detenga los contenedores de interoperabilidad primero. Deténgalos antes de una ejecución completa del navegador y arráncelos con ./scripts/interop-up.sh después si todavía los necesita.

Ocho contenedores ocupan alrededor de 9,8 GB de memoria, y en una máquina sin mucho más que eso, queda muy poca memoria para los procesos de Chromium, node y la cadena de herramientas de Go juntos. Lo que produce no es un error de memoria agotada, sino un renderizador que deja de programarse: una traza registrada muestra un intervalo de 60,2 segundos sin cuadros, durante el cual Playwright esperó a que un botón se volviera "visible, habilitado y estable" y no pudo obtener dos cuadros de animación consecutivos para comparar. El servidor estuvo saludable durante todo el tiempo, la solicitud más lenta en toda la ejecución fue de 154 milisegundos.

Ese error se lee como un defecto en la prueba que resultó que se estaba ejecutando. Vale la pena conocer su forma: todas las solicitudes rápidas, la página visualmente congelada, el bucle de reintento nunca alcanza una segunda iteración, y todo pasa en aislamiento.

Solo una ejecución a la vez. La suite comparte un servidor, una sesión iniciada en web/e2e/.auth/admin.json y un archivo de estado que nombra el proceso del servidor. Nada de eso es por ejecución, por lo que una segunda ejecución que comienza mientras la primera se ejecuta sobrescribe el archivo de estado, y el desmontaje que termina primero mata el servidor de la otra ejecución y elimina su sesión.

Eso es lo que parece, nada como la causa. Produjo una racha de 279 fallos cuyo primer mensaje fue ENOENT: no such file or directory, open './e2e/.auth/admin.json', una racha que se detuvo temprano informando 217 aprobados, y dos pruebas fallidas con bind: address already in use — ninguno de los cuales sugiere dos ejecuciones luchando. La suite ahora toma un bloqueo y se niega a iniciar, nombrando el proceso que lo mantiene. Un bloqueo dejado por una ejecución interrumpida se toma en lugar de bloquear para siempre, porque una medida de seguridad que bloquea la suite es algo que alguien elimina junto con la seguridad.

Una trampa relacionada, ahora arreglada: dos especificaciones nombraron sus puertos de escucha directamente, por lo que un servidor dejado atrás por una ejecución interrumpida los hizo fallar en algo con lo que no tenían nada que ver. Ahora se piden puertos al sistema operativo.

No responda a ninguno de esto con reintentos. Una prueba que pasa en el segundo intento encontró una carrera real y la ocultó, y playwright.config.ts establece retries: 0 por esa razón.

Una advertencia: muestrear cada 100 milisegundos generó veinte procesos por segundo, estiró una ejecución en un cincuenta por ciento, y falló dos pruebas en tiempos de espera que no tenían nada malo. Un instrumento que cambia lo que mide produce hallazgos sobre sí mismo.

14.6 Lo que todavía necesita infraestructura real

Varias partes de Perfuse están implementadas y nunca se han ejercitado contra lo real. Se enumeran aquí en lugar de dejar que se descubran:

• SMB contra una compartición de Windows real — el código del protocolo está completo y probado para seguridad de ruta y manejo de argumentos, pero ninguna prueba abre un socket a un servidor unido a un dominio.
• Un puerto serie real.
• El importador de Mirth contra XML real producido por Mirth. Probado contra Mirth 4.5.2 en un contenedor, y el hallazgo fue sobre este repositorio: el único fixture de migración aquí fue escrito a mano y Mirth no lo carga — almacena el canal como inválido y descarta todos los conectores. Lo que se decidió es que los atributos version que Mirth real escribe en cada elemento se analizan en el mismo canal, por lo que no son un peligro; lo que no se decidió es todo lo demás que contiene una exportación real.
• SAML contra un proveedor de identidad comercial alojado. Keycloak está verificado; un proveedor prueba que una implementación coincide con un proveedor.
• Una reclamación de NCPDP a través de un conmutador de farmacia real.
• Un mensaje de SCRIPT a través de Surescripts, donde la certificación es un proceso comercial en lugar de técnico.

Las características de este capítulo y el siguiente existen para que pueda recopilar sus propias pruebas en lugar de tomar la palabra de alguien.

14.7 Medido contra corpora de conformidad públicos

Una suite de pruebas cuyos fixtures se escribieron aquí prueba el acuerdo con uno mismo. Estos son los datos de otras personas.

14.7.1 FHIR R4, los ejemplos de la especificación

Todos los 2.912 archivos de ejemplo publicados con la especificación FHIR R4 — cada ejemplo que los autores del estándar escribieron.

No se validó incorrectamente ningún recurso. Cada fallo es un rechazo explícito que nombra el tipo que no puede leer — 672 ValueSet, 80 ConceptMap y un Parameters. Un validador que pasa silenciosamente lo que no entiende es peor que uno que lo dice.

El corpus encontró un defecto, que es la razón para ejecutarlo. La validación de un paquete imprimió "La validación de paquetes desde un archivo no es compatible todavía" y continuó. Eso fue falso en ambos sentidos: los paquetes cuyas entradas casualmente eran tipos que el analizador podía contener ya estaban siendo validados, y un paquete que era genuinamente inválido produjo la misma línea, no contó nada y salió cero — incluyendo bajo -strict, que existe para que esto pueda bloquear una compilación. Cuarenta y dos de los propios paquetes de la especificación estaban siendo omitidos.

Los paquetes ahora se validan entrada por entrada, con tres resultados mantenidos aparte: una entrada que está mal falla y nombra el campo, una entrada de un tipo que esta compilación no puede leer se cuenta como omitida y se informa, y un paquete que lleva ningún cuerpo de recurso no es ninguno. El mismo corpus pasó de 2.100 recursos comprobados a 13.723.

14.7.2 HL7 v2, el corpus de pruebas HAPI

Los arreglos de mensaje de HAPI, la implementación de referencia de Java HL7 v2 — material deliberadamente incómodo que incluye payloads codificados en uu, delimitadores escapados y grupos repetidos.

59 mensajes, 59 analizados, nada rechazado. Siete tipos de mensaje en un corpus que cualquier sistema individual describiría como una sola cosa, que es el punto perfuse profile existe para hacer.

14.7.3 Lo que no se ha ejecutado

DICOM contra un conjunto de conformance público, y X12 contra un corpus publicado. Ninguno de los dos se ha realizado, y no se debe inferir ninguno de los dos de los dos anteriores.

15 Migración desde Mirth

Se necesitan dos cosas para reemplazar un motor de trabajo: los canales tienen que cruzar, y alguien tiene que poder mostrar que el reemplazo produce la misma salida. Perfuse hace lo primero importando las propias exportaciones de Mirth, y lo segundo comparando los dos motores en su propio tráfico.

Todo en este capítulo se aplica igualmente al Open Integration Engine y BridgeLink. Mirth Connect dejó de ser de código abierto en la versión 4.6 en marzo de 2025; OIE (alojado por la Eclipse Foundation) y BridgeLink (Innovar Healthcare) son las bifurcaciones que continúan la línea de código abierto, y ambos escriben los mismos formatos de exportación. El importador se prueba contra los tres, a continuación.

15.1 Importación de canales

Perfuse lee cada exportación que escriben estos motores:

Apunte perfuse translate a cualquiera de ellos, o suéltelo en Administrar → Migrar:

perfuse translate -o ./channels server-backup.xml

Una biblioteca de plantillas de código se convierte en lib/<library>.js junto a los canales, y cada canal de Mirth que tenga habilitada la biblioteca obtiene scripts.include: [lib/<library>.js] — por lo que un transformador que llama a una función de sitio como formatMRN() todavía la encuentra. Un canal para el que la biblioteca no esté habilitada no la incluye, porque sus scripts no podían verla en Mirth either. Se omiten los fragmentos de arrastrar y soltar: Mirth solo los pega en un paso a mano, por lo que no son código que se ejecuta por sí solo. En el navegador, importar un canal guarda las bibliotecas que incluye primero.

Un Channel Writer nombra el canal al que entrega por id. En un grupo o una copia de seguridad, el destino está en el mismo documento, por lo que se convierte en un destino de channel que nombra ese canal; desde una exportación de un solo canal se informa para que lo complete. Los scripts globales del servidor no tienen un equivalente en Perfuse y se informan en lugar de eliminarse.

El informe dice, por canal, si se tradujo limpiamente, se tradujo con advertencias o no se pudo leer.

El titular es una fracción con su denominador — "37 de 40 listos" — porque "37 listos" no le dice nada sobre lo que todavía tiene que hacer.

Un canal que no se pudo leer es un problema diferente de uno que no se pudo traducir. El primero significa que el XML en sí no se analiza y generalmente es una exportación truncada o parcial; el segundo significa que el contenido del canal tiene algo sin un equivalente en Perfuse. La importación los separa.

15.2 Lo que se traduce y lo que necesita una decisión

Las fuentes, destinos, filtros y los pasos de transformador ordinarios se traducen directamente. Los conectores que se traducen: TCP/MLLP (y TCP raw con su enmarcado), HTTP, Archivo, Base de datos, JavaScript, DICOM, Servicio web (SOAP), SMTP y Lector/Escritor de canal. JMS y el Escritor de documento no se traducen, y se informan como bloqueadores.

Un paso de Asignador que establece una variable la coloca en el mapa que su ámbito nombra — channelMap por defecto — exactamente como Mirth lo hace, así que los pasos posteriores que la leen con $('name') la encuentran.

Los transformadores de JavaScript no lo hacen, en general. Los canales de Mirth comúnmente contienen un código sustancial en un transformador, y no hay una conversión automática de JavaScript arbitrario a pasos declarativos. El importador informa sobre estos en lugar de intentar una traducción que podría estar sutilmente equivocada: un transformador mal traducido es peor que uno marcado para un humano, porque se ejecutará.

Donde un script genuinamente tiene que permanecer como script, Perfuse puede ejecutarlo — véase la clave scripts en la referencia de canal — a costa de la traza de nivel de paso descrita en depuración.

15.3 Lo que el importador ha sido probado

Cinco motores, cada uno creando sus propios documentos: Mirth 4.5.2, OIE 4.5.2, 4.6.0 y 4.7.0, y BridgeLink 26.9.0. scripts/mirth-engine-corpus.sh compila un pequeño programa contra los jars de cada motor y tiene su propio serializador que escribe tres canales ordinarios — una fuente MLLP con un mapeador, un script que llama a una biblioteca de plantillas de código y un filtro; una fuente HTTP a una base de datos; una votación de archivo sobre MLLP — más la biblioteca y un grupo de canales. Carga en el motor en ejecución y descarga la copia de seguridad del servidor del motor. Los resultados se confirman en internal/mirth/testdata/engines/, y la suite de pruebas mantiene al importador en cada uno de ellos en cada compilación: cada copia de seguridad se lee, se traduce, se carga y el canal ADT se ejecuta con dos mensajes para verificar que la biblioteca rellena el número de registro y el filtro descarta el resultado.

Las propias exportaciones de Perfuse van en la otra dirección — los canales de Perfuse importados en cada motor en ejecución y se verificó que el motor no los almacenó como inválidos. Los cinco aceptan cada transporte que Perfuse exporta. Open Integration Engine 4.7.0 agregó dos configuraciones de HTTP sin equivalente aquí: un remitente HTTP vinculado a una dirección local elegida se informa como una advertencia, y un límite de encabezado de solicitud de escucha de HTTP solo cuando supera el 1 MB que Perfuse acepta.

La primera ejecución contra este corpus encontró cuatro defectos, todos corregidos: el traductor rechazó fuentes HTTP y de archivo como "solo se admite MLLP" mucho después de que Perfuse tuviera ambos; leyó la dirección de un remitente HTTP de un campo que ninguno de los motores escribe; tradujo el tamaño del búfer de socket de Mirth como un límite de mensaje de 64 KB; y una variable de un mapeador se convirtió en una variable global de JavaScript que $('mrn') nunca vio, por lo que la biblioteca rellenó una cadena vacía.

The single-channel fixture that started this was also exported by Mirth 4.5.2, authored by Mirth itself rather than written here. That distinction earned its place: the only fixture in this repository used to be hand-written, and a real Mirth will not load it — the API accepts the POST and then stores the channel as This channel is invalid. Verify all required extensions are loaded correctly, with every destination connector discarded.

Escribir uno a mano nunca iba a funcionar, y la razón vale la pena saber si está produciendo exportaciones propias. El serializador de Mirth ignora los elementos que no reconoce, por lo que un nombre de elemento incorrecto no produce ningún error en absoluto — el conector simplemente no está allí después.

scripts/mirth-author-channel.sh construye uno utilizando las clases de modelo de Mirth y su propio serializador, luego lo publica en un servidor en ejecución y falla si el servidor lo rechaza. El importador de Perfuse lee el resultado: nombre, transporte de origen y destinos todos sobreviven.

15.4 Probar que coincide

Esta es la parte que decide si ocurre una migración, y necesita evidencia en lugar de confianza.

Perfuse compara su propia salida con la del antiguo motor, mensaje por mensaje, en su tráfico. Lo que necesita son pares: el mensaje tal como llegó, y el mensaje que el antiguo motor produjo a partir de él. Ambos están en la propia tienda de mensajes de Mirth y se pueden exportar desde su navegador de mensajes.

15.4.1 Cuatro números, no una tasa de aprobación

Son cuatro números porque significan cuatro cosas diferentes y colapsarlos oculta los que necesitan una decisión.

Idéntico significa byte por byte, no equivalente. Una prueba más débil permitiría diferencias en el orden de segmentos o separadores finales, y esas son exactamente lo que un sistema descendente quisquilloso rechaza.

Las diferencias cosméticas se cuentan por separado en lugar de incorporarse en la columna buena. Realmente no llevan información, por lo que tratarlos como fallos enterraría los hallazgos reales bajo miles de nada — pero no son idénticos tampoco, y un receptor que realice su propia análisis estricto puede no estar de acuerdo.

"No se ejecutaría" es separado de "difiere" porque generalmente es una brecha de configuración que el importador no pudo llenar, no una decisión de mapeo. Si todo está en esa columna, el veredicto lo dice y le dice que mire la configuración antes de leer cualquier otra cosa.

15.4.2 Las diferencias se agrupan por campo

Una ejecución de más de cincuenta mil mensajes que informa cuatro mil diferencias no le ha dicho nada que pueda actuar. La misma ejecución que informa que PID-8 difiere en cada mensaje porque el antiguo motor escribió Male donde Perfuse escribe M le ha dicho exactamente una cosa que decidir.

Entonces cada hallazgo es un campo, con un recuento, y dice si la diferencia es sistemática — el mismo par de valores cada vez — o si el contenido del campo difiere.

Esa distinción es la cosa más útil en el informe. Un par de valores distintos en cuatro mil mensajes es una sola decisión de mapeo. Cuatro mil pares distintos es el contenido que difiere, que es un problema diferente y mucho peor, y los dos no deben leer igual.

Los hallazgos se ordenan por la cantidad de mensajes que afectan, por lo que la causa única más grande es la primera.

15.4.3 El veredicto no redondea

Proporciona recuentos exactos: 49.993 de 50.000, no "más del 99%". Los siete son el punto de ejecutarlo.

Está escrito para ser citable en una solicitud de cambio, porque es donde termina el número.

15.5 Una secuencia sugerida

1. Importe los canales y resuelva cualquier problema informado como ilegible.
2. Para cada canal, revise las advertencias. La mayoría serán scripts.
3. Exporte varios miles de pares de mensajes de Mirth para el canal más ocupado y ejecute la comparación.
4. Trabaje en los resultados. Los sistemáticos son una decisión cada uno.
5. Vuelva a ejecutar hasta que las únicas diferencias sean las que ha decidido que son correctas.
6. Ejecute Perfuse en sombra junto con Mirth en tráfico en vivo, sin entregar en ningún lugar, y compare de nuevo durante un período que incluya un fin de semana y un fin de mes.
7. Cambie a un canal, no a todos.

15.6 Lo que solo se ejecuta en el software de un proveedor

La pantalla de migración responde a una segunda pregunta, y vale la pena preguntar antes de tener alguna opinión sobre Perfuse: ¿cuánta de su lógica de integración solo se puede ejecutar en el software que tiene.

Cada canal obtiene un veredicto de Portabilidad, de la misma exploración que produce las notas de migración. Se ejecuta contra una exportación de canal, por lo que no necesita nada instalado y no cambia nada.

15.6.1 La distinción es el punto principal

La mayoría del Java en los scripts de Mirth no es de bloqueo. SimpleDateFormat, HashMap, Apache Commons — todo funciona alrededor de un motor de JavaScript de 2009, todo es ordinario, todo tiene equivalentes directos. Un canal con trescientas referencias de ese tipo es completamente portable, y una herramienta que informara "300 referencias de Java, está atrapado" estaría mintiendo.

El bloqueo es específicamente las llamadas que necesitan el servidor del proveedor: com.mirth.connect.* y jars del proveedor. Cinco de esos y está atrapado. Quinientos del otro tipo y está libre.

Entonces, el veredicto comienza con el número que importa y dice en la misma oración que el número más grande no es ese. Donde hay llamadas del proveedor, se enumeran por nombre — un recuento es una afirmación, y una lista es algo que su propio ingeniero puede ir y verificar.

Se mantiene una tercera categoría por separado: capacidad que existe pero no desde un script. Iniciar un canal desde JavaScript no tiene equivalente aquí, y hay un punto final de API que hace exactamente lo mismo. Llamar a eso bloqueo exageraría el resultado.

15.6.2 Llamadas a Java que se ejecutan sin cambios

La mayoría de esas clases de Java se ejecutan tal como están escritas. Perfuse no tiene un tiempo de ejecución de Java, por lo que estas son clases de JavaScript con los mismos nombres y métodos, suficientes para la forma en que los scripts de canal los utilizan; importPackage(java.util) y importClass(...) los traen al alcance por sus nombres cortos, como en Rhino (los Date, Map, Set, Math, String y Boolean de JavaScript nunca se reemplazan: los de Java todavía están allí por nombre completo). El informe de migración cuenta cada una de estas llamadas como ya soportadas.

Se comportan como Java donde los scripts dependen de él: Integer.parseInt("x") lanza NumberFormatException, String.replaceAll y split toman expresiones regulares mientras que replace es literal, los mapas clave las cadenas por valor, TreeMap y TreeSet iteran en orden, y SimpleDateFormat.parse devuelve una fecha getTime() funciona en ella. Un método que un script llama que el equivalente carece falla en esa línea, nombrándolo; cualquier otra clase de Java falla por nombre, como antes. BigDecimal es un doble aquí, por lo que no mantiene la aritmética decimal exacta de Java: verifique los scripts que lo utilizan para el dinero.

15.6.3 Los scripts externos se informan como desconocidos

Un paso que ejecuta un archivo de script externo hace referencia a una ruta en el servidor antiguo, y el archivo no está en la exportación. Nada se puede decir sobre lo que contiene, por lo que se cuenta como desconocido en lugar de asumirlo de una manera u otra. Recupere esos archivos antes de concluir cualquier cosa — en ambos sentidos.

15.6.4 El propio bloqueo de Perfuse, declarado en el mismo aliento

Esta sección sería deshonesta sin ello.

Perfuse es Apache 2.0, que es irrevocable para el código ya publicado. Puede bifurcar lo que existe hoy y nadie puede retirar eso. Los canales son archivos YAML y los scripts son JavaScript ordinario, por lo que no hay superficie de propiedad para llamar — el sabor de Java de Mirth es estructuralmente inaccesible aquí, que es el único lugar donde una limitación es genuinamente una característica.

Lo que eso no promete: que una versión futura permanezca abierta, que exista un servicio alojado a un precio que le guste, o que migrar desde Perfuse cueste nada. Mover cualquier capa de integración significa volver a probar cada canal contra tráfico real. Lo que está eligiendo es si los artefactos que construye son legibles y portátiles, y si la salida depende de una licencia que alguien más controla.

15.6.5 Configuración del paso 6

La sección Shadow inicia una comparación. Elija el canal que se está ejecutando, elija el candidato para comparar desde la lista y comience.

Tres cosas sobre ello valen la pena saber antes de confiar en los números.

El candidato se elige de una lista, no se escribe. Una sombra nombra un archivo de canal y un nombre que no se resuelve hace que el canal *en vivo* sea inválido: Perfuse rechaza un canal en su totalidad cuando algo a lo que hace referencia está roto. Así que un error tipográfico no produce una advertencia, hace que el canal en ejecución desaparezca.

La participación es un porcentaje. Redúzcala solo en una fuente ocupada y conozca su costo: la muestra reduce el trabajo y la confianza en la misma proporción, y el mensaje que habría mostrado la diferencia es el inusual.

Campos para ignorar suele ser necesario. Un canal que estampa una marca de tiempo o un número de secuencia es diferente en cada mensaje, lo que informa una tasa de diferencia del 100% y no le dice nada. MSH-7 y MSH-10 son el par común.

Una comparación se escribe en el archivo de canal tan pronto como se inicia y comienza a observar cuando el canal se carga nuevamente: la pantalla lo indica en lugar de afirmar que ya está en ejecución. Detener una comparación deja el canal candidato en su lugar, porque el candidato es la cosa que se supone que debe estar en vivo.

El paso 6 es el que no se puede acortar. Las diferencias que importan suelen estar en el tráfico que solo aparece ocasionalmente: un evento de disparo raro, un lote de fin de mes, un remitente que se comporta de manera diferente a medianoche, y una muestra tomada durante una tarde no los contendrá.

15.7 Volver en el otro sentido

Un canal se puede exportar como un archivo de canal de Mirth, desde el navegador: Canales, luego A Mirth en el canal que desee.

Esto existe porque la objeción a reemplazar un motor de trabajo rara vez es si el reemplazo es bueno. Es lo que sucede si la decisión resulta ser incorrecta, y una exportación que vuelve por donde vino es la respuesta más barata a eso.

Lea lo que el diálogo le dice antes de tomar el archivo. El formato de Mirth no tiene dónde poner un filtro de Perfuse, una cadena de transformación, un contrato o una comparación de sombra, así que un canal exportado hace menos que el que vino. Los transportes y sus direcciones se convierten; la lógica no. Cada pérdida se enumera por nombre antes de que se ofrezca el archivo, y la misma lista se incluye en la descripción del canal para que quien lo importe también lo vea.

Un canal que Mirth no puede expresar se rechaza en lugar de aproximarse. Un destino S3 no tiene equivalente en Mirth, y un canal que se importó limpiamente mientras se entregaba en algún lugar que no sea el bucket sería peor que no tener archivo en absoluto. El rechazo nombra el destino en falta.

Las definiciones de conector no se escriben a partir de una lectura del formato de Mirth. scripts/mirth-dump-connector-templates.sh tiene el serializador propio de Mirth que produce los valores predeterminados para cada clase de conector, y Perfuse sustituye valores en esos documentos: rechazando cualquier configuración que el modelo no contenga ya. Esto importa porque de cómo Mirth responde a un canal que no puede analizar: no rechaza la importación. Almacena un canal cuya descripción ha sido reemplazada con "Este canal es inválido. Verifique que todas las extensiones requeridas estén cargadas correctamente" y cuyos destinos han sido descartados silenciosamente. Un exportador verificado contra su propia salida en lugar de contra un servidor pasa todas las pruebas mientras produce documentos que se descartan, lo cual es exactamente lo que sucedió aquí antes de que las exportaciones se probaran contra un Mirth en ejecución.

Lo que cruza hoy: MLLP y TCP en ambos sentidos, HTTP en ambos sentidos, lectura y escritura de archivos, lectura y escritura de bases de datos, DICOM en ambos sentidos, y destinos SMTP, SOAP y JavaScript. Cada par se verifica mediante la importación a un Mirth 4.5.2 real y comprobando que el servidor no reemplazó silenciosamente el canal.

16 CMS-0057 para pagadores

La regla final de interoperabilidad y autorización previa de CMS (CMS-0057-F) requiere que los pagadores afectados: las organizaciones de Medicare Advantage, los programas de Medicaid y CHIP estatales y sus planes de atención administrada, y los emisores de QHP en los intercambios federales, ejecuten cuatro API de FHIR a partir del 1 de enero de 2027, y publiquen las métricas de autorización previa en su sitio web público cada año a partir de 2026.

Perfuse proporciona las cuatro API en su punto de conexión FHIR y las conversiones que las llenan: reclamaciones adjudicadas como CARIN Blue Button, autorizaciones previas como Da Vinci PDex, y las métricas anuales en el diseño de la plantilla propia de CMS. La vista CMS-0057, bajo Intercambio, dice cuál de las cuatro esta instancia puede responder y qué cada una todavía necesita, y realiza las tres conversiones en el navegador.

Los medicamentos están fuera del alcance en todo momento, ya que lo están en las disposiciones de autorización previa de la regla: no hay reclamaciones de farmacia, no hay formularios, y una fila de métricas que nombra un medicamento se rechaza en lugar de contarse.

16.1 Las cuatro API

La API de acceso de paciente no necesita ninguna operación propia: es la lectura y búsqueda ordinarias del punto final de FHIR, protegidas por SMART, con recursos CARIN y PDex en el almacén. La búsqueda de ExplanationOfBenefit admite los parámetros con nombres CARIN — patient, identifier, type, service-date, billable-period-start, provider, insurer, coverage — y Coverage admite subscriber-id, identifier y payor.

16.1.1 Dos versiones de las guías: 2.1.0 y 2.2.x

CMS-0057-F recomienda CRD, DTR y PAS 2.0.1 y 2.1.0. Las versiones 2.0.1 se basan en US Core 3.1.1, que expiró el 1 de enero de 2026, por lo que la versión 2.1.0 es la versión que probablemente hable un sistema de registros electrónicos de salud construido para la regla; las versiones más recientes son CRD 2.2.1, DTR 2.2.0 y PAS 2.2.1. Perfuse responde en ambas. Determina qué versión habla el llamador, primero la más específica:

1. desde la solicitud: la extensión CDS Hooks de CRD davinci-crd.requestedVersion ("2.1"), o la versión en un perfil de Da Vinci que una entrada DTR o PAS reclama (profile-pas-request-bundle|2.1.0);
2. desde el registro del llamador: davinci_version: "2.1" en un cliente SMART (-smart-clients) o un cliente CDS (-cds-clients);
3. desde el servidor: serve -davinci-version 2.1; el valor predeterminado es 2.2.

clients:
  - issuer: https://ehr.example.org
    jwks_url: https://ehr.example.org/.well-known/jwks.json
    davinci_version: "2.1"

Cada respuesta se decide y mantiene en la forma 2.2.x y se reescribe para un llamador 2.1.0 cuando se envía, por lo que las reglas, la cola de revisión, el enlace X12 278 y las métricas son las mismas para ambas. La reescritura cubre lo que las versiones deletrean de manera diferente: CRD 2.1.0 no tiene indeterminate (Perfuse dice condicional, con la razón) y no tiene categoría en un detalle de cobertura; DTR 2.1.0 nombra el paquete PackageBundle y deja la QuestionnaireResponse a la aplicación; PAS 2.1.0 responde con un solo Bundle en $inquire y carece de las extensiones del revisor y la transmisión. La lista completa y la comprobación con cada ejemplo de la guía 2.1.0 se encuentra en conformance/davinci21. Una notificación PAS sigue -davinci-version, ya que una suscripción no especifica qué versión lee su propietario.

16.2 Requisitos y documentación de cobertura: CRD y DTR

La API de Autorización Previa en la práctica son tres guías de Da Vinci juntas. CRD informa al clínico, mientras que la orden aún es un borrador, si está cubierto, si necesita autorización previa y qué documentación se requiere. DTR entrega al EHR el cuestionario que recopila esa documentación. PAS envía la solicitud y devuelve la decisión. Perfuse sirve como pagador para las tres.

-crd-rules rules.yaml sirve CRD a través de CDS Hooks en /cds-services: los seis hooks de CRD, order-sign, order-select, order-dispatch, appointment-book, encounter-start y encounter-discharge, cada uno con una pre-carga para la Cobertura activa del paciente. Los dos hooks de encuentro también pre-cargan el encuentro y responden sobre el encuentro en sí, coincidiendo con su tipo y tipo de servicio, al igual que appointment-book responde sobre una cita. Las reglas son la política del pagador, mantenidas en un archivo porque cambian sin lanzamientos de software:

payer: Springfield Health Plan
rules:
  - description: Home oxygen equipment
    codes: [E0424, E0431]
    covered: covered            # covered, not-covered, conditional
    pa: auth-needed             # no-auth, auth-needed, satisfied, performpa, conditional
    documentation: [clinical]
    questionnaire: https://www.springfield-health-plan.example/fhir/Questionnaire/home-oxygen

Cada pedido recibe una actualización de systemActions que lleva la extensión de información de cobertura de CRD, que el EHR almacena en el pedido y más tarde envía con la autorización previa, y una tarjeta que el clínico lee. Un pedido cuyo código no tiene regla se responde como conditional, nunca se asume que esté cubierto; una solicitud sin cobertura en absoluto recibe una tarjeta que lo indica. examples/crd/ tiene un archivo de reglas y un cuestionario coincidente.

Una regla también puede llevar el resto de lo que CRD permite que un pagador diga:

• billing_codes: los códigos para facturar bajo.
• details: límites y costos, como allowed-period o in-network-copay.
• contact: quién llamar.
• expiry_days: cuánto tiempo mantiene la respuesta.
• depends_on: códigos de otras órdenes de las que depende la respuesta, para que el EHR pregunte de nuevo si cambian.
• doc_purpose: para qué es la documentación (withclaim, withorder, retain-doc). withpa se rechaza, porque la propia invariante crd-ci-q4 de CRD 2.2.1 la rechaza.

Lo que el EHR no prefetched, Perfuse lee del fhirServer del EHR con el token que envió. Si eso falla, la respuesta es indeterminate con la razón technical de CRD, nunca una suposición. Una Cobertura que ha finalizado o no está activa se responde como not-covered, no-active-coverage.

members: fhir en el archivo de reglas resuelve la cobertura contra los registros propios del pagador en el almacén de FHIR de este servidor (inícielo con -fhir), los mismos registros que $member-match lee:

• un paciente que no es miembro recibe no-member-found;
• un miembro cuya cobertura no coincide recibe coverage-not-found;
• una autorización previa ya aprobada allí para el servicio (un ClaimResponse con un preAuthRef) hace que la respuesta sea satisfied,

con ese número.

Discovery declara davinci-crd.version y una opción de configuración coverage-info. Cuando un cliente desactiva la opción, la respuesta está vacía. Los JWT de EHR se verifican como los define CDS Hooks, con iss, aud, exp, iat y jti y sin sub, y se rechaza un jti repetido.

Las llamadas se autenticarán con el JWT que un EHR firma para cada llamada, desde un emisor nombrado en -cds-clients con su URL de JWKS - que es cómo CDS Hooks lo describe - o con un token de API de Perfuse. El descubrimiento es abierto, como requiere CDS Hooks.

DTR: cargue los cuestionarios en el punto de conexión de FHIR, y POST /fhir/Questionnaire/$questionnaire-package los devuelve como paquetes de DTR, con las bibliotecas de CQL que nombran. La solicitud puede nombrar el cuestionario, o enviar la orden y dejar que su información de cobertura diga cuál.

Intentándolo: Payers → Claims & auth → Coverage requirements (CRD) envía una orden a las reglas de este servidor, o a la URL del servicio de CDS de un pagador, y muestra las tarjetas y la información de cobertura.

16.3 Reclamaciones como CARIN Blue Button

perfuse cms0057 carinbb empareja cada reclamación en un 837 con su pago en un 835, por el número de cuenta de paciente que el 835 está obligado a devolver, y escribe una transacción de FHIR para cada una: la ExplanationOfBenefit con el Patient, Coverage, Organizations y Practitioners que referencia.

perfuse cms0057 carinbb -system https://fhir.your-plan.org/identifier -network innetwork \
    claims.837 remittance.835

El perfil sigue la reclamación: las reclamaciones profesionales (837P) se convierten en C4BB-ExplanationOfBenefit-Professional-NonClinician, y las institucionales (837I) en pacientes internos o externos según el tipo de factura. Cada entrada es un PUT con un id tomado de los identificadores de origen, por lo que cargar la misma reclamación dos veces la actualiza en lugar de crear una segunda copia.

Tres cosas no están en ninguno de los archivos X12, y cada una se maneja diciendo que no están en lugar de adivinar:

• El sistema de identificador. CARIN requiere que el identificador de miembro nombre el espacio de nombres del pagador. Se requiere -system; no hay un valor predeterminado, porque un valor predeterminado daría a todos los pagadores que utilizan Perfuse el mismo espacio de nombres.
• El estado de la red. Ninguna de las transacciones indica si el proveedor de facturación está en la red, y decide lo que paga el miembro. Sin -network, el estado de pago de beneficio es other y las notas de conversión explican por qué.
• Una reclamación que el 835 no menciona. Una ExplanationOfBenefit de CARIN es una reclamación adjudicada. Sin el 835, no hay número de reclamación del pagador, no hay pago y no hay responsabilidad del miembro, por lo que la reclamación se informa como omitida y no se convierte.

Los diagnósticos se escriben con su punto decimal (J02.9, no J029), porque así es como el sistema de código los publica y un servidor de terminología preguntado sobre la otra ortografía dice que no existe. El identificador de miembro de un dependiente es el del suscriptor, que es lo que lleva el 837, y las notas lo dicen. Un NPI cuyo dígito de verificación es incorrecto se informa antes de que US Core lo rechace.

16.4 Autorizaciones previas como PDex

perfuse cms0057 priorauth convierte una respuesta de reclamación Da Vinci PAS — o el paquete de respuesta PAS que la transporta — en una explicación de beneficio de autorización previa PDex, que es lo que sirven las tres APIs de datos.

perfuse cms0057 priorauth pas-response.json pas-claim.json

La reclamación PAS es opcional y casi siempre es necesaria. Una explicación de beneficio debe indicar qué cobertura se tomó la decisión y solo la solicitud lleva eso; sin ella, la conversión se detiene y lo indica. La acción de revisión — aprobada, denegada, pendiente, con su número de autorización y motivo — se mueve de la extensión de PAS a la de PDex, y el tipo de servicio X12 mantiene su código bajo el URI que PDex lo enlaza.

16.5 Las APIs de acceso de proveedor y de pago a pago

Con -fhir-payer-apis el punto de conexión FHIR responde a tres operaciones más:

• POST /fhir/Patient/$member-match — coincidencia de miembros HRex. Los identificadores de cobertura se reducen a unos pocos candidatos, y el apellido y la fecha de nacimiento deben coincidir; un nombre dado se compara por inicial, y el género solo cuando ambos lados lo indican. Más de un candidato sobreviviente no es una coincidencia, y la respuesta es 422 en lugar de una suposición, porque una suposición revela las reclamaciones de un desconocido. Se requiere un consentimiento activo que permita la divulgación, ya que la API de pago a pago es opt-in para el miembro; -fhir-member-match-without-consent lo desactiva para pruebas.
• GET o POST /fhir/Group/{id}/$davinci-data-export — la exportación masiva de Da Vinci de los miembros actuales de un Grupo. exportType elige la audiencia: hl7.fhir.us.davinci-pdex#provider-download o #provider-delta para el acceso de proveedor, #payertopayer para el pago a pago.
• GET /fhir/Group/{id}/$export — la exportación de datos masivos estándar del Grupo, tratada como acceso de proveedor.

Las exportaciones aplican las exclusiones de la regla en el camino. Las reclamaciones pierden el pago y todos los montos de costos compartidos y reembolso, y mantienen los servicios, códigos, fechas y proveedores; el perfil CARIN se elimina de meta.profile porque el recurso ya no cumple con él. El pago a pago también deja fuera las autorizaciones previas denegadas. Los miembros que tienen un consentimiento activo de opt-out de acceso de proveedor PDex se dejan fuera de una exportación de proveedor, y el registro recoge cuántos. El parámetro patient solo puede reducirse a miembros del Grupo; nombrar a cualquier otra persona se rechaza.

El acceso a la exportación de un Grupo se decide por la autenticación del punto de conexión. Los ámbitos de SMART dicen qué tipos de recurso puede leer un token, no qué Grupo, por lo que cada proveedor necesita un token que pueda llegar solo a su propia lista de atribución. Un token de API se puede limitar a Grupos cuando se crea — perfuse token create -label riverside-provider-access -fhir-groups riverside-attributed, o el campo Limitar a Grupos de FHIR en Users → Machine credentials — y en el punto de conexión de FHIR puede leer esos Grupos, ejecutar $davinci-data-export o $export en ellos y recuperar lo que produjo la exportación, y nada más. Un Grupo de otro proveedor responde no encontrado en lugar de prohibido, por lo que un token no aprende qué otras listas de atribución existen; cualquier otra solicitud, incluida la coincidencia de miembros y la búsqueda ordinaria, se rechaza. El límite se aplica a los tokens de API; un token de un emisor de SMART no lleva un límite de Grupo. Cuando SMART está configurado también, los tokens de API se rechazan a menos que Settings → FHIR → Accept Perfuse API tokens beside SMART tokens esté activado (ver Seguridad, *Quién puede llamar al punto de conexión de FHIR*); un token limitado a Grupo de un proveedor necesita esto.

16.6 Un directorio de proveedores: Plan-Net

CMS-0057 también solicita a los pagadores un directorio de proveedores, y el punto de conexión FHIR sirve uno a Da Vinci Plan-Net 1.1.0 sin opción para activarlo: carga a los Practitioners, PractitionerRoles, Organizations, OrganizationAffiliations, Locations, HealthcareServices, InsurancePlans y Endpoints, y las aplicaciones de los miembros pueden buscarlos. Cada parámetro de búsqueda de Plan-Net está indexado - un rol de red y servicio, un área de cobertura de un plan, una organización participante de una afiliación, una organización partof - junto con las cadenas de inclusión y reversas (_has) que las consultas de la guía utilizan, y la CapabilityStatement enumera los perfiles de Plan-Net.

La suite Plan-Net de Inferno pasa 199 pruebas. Las 10 que falla son cadenas hacia adelante donde el kit toma su valor de búsqueda del primer Organization que ha visto en lugar de uno al que los recursos buscados se refieren; eso se informa al kit (su problema 34), y el servidor responde correctamente esas consultas cuando se le da un valor que los datos contienen.

16.7 Métricas de autorización previa

perfuse cms0057 metrics lee un CSV de decisiones exportadas del sistema de gestión de utilización y produce la página pública que CMS requiere, en el diseño de su *Informe y plantilla de métricas de autorización previa*.

perfuse cms0057 metrics -year 2025 -org "Springfield Health Plan" -services services.csv \
    decisions.csv > prior-authorization-metrics-2025.html

Las columnas se encuentran por encabezado: priority, received, decided y decision son obligatorias, y request_id, line_of_business, extended, appealed, appeal_decision, service_code y service_description se leen cuando están presentes. Una solicitud pertenece al año en que se decidió; una que aún está pendiente se enumera como excluida, nunca contada. Cada fila que no se puede leer se informa con su número de línea.

La aritmética sigue la plantilla: para solicitudes estándar y expeditas por separado, la participación aprobada y denegada, aprobada y denegada dentro del plazo de decisión, aprobada después de que se extendió el tiempo de revisión, y aprobada después de apelación — de apelaciones, no de solicitudes — con el tiempo medio y mediano desde la recepción hasta la decisión. Una mediana inferior a un día se escribe en horas en lugar de redondearse a "0 días", que la plantilla solicita explícitamente. Las solicitudes aprobadas parcialmente se cuentan como aprobadas, ya que la plantilla no tiene categoría para ellas, y la página indica cuántas hubo. Las métricas se informan por línea de negocio, que es el nivel que CMS requiere.

La página es autocontenida, no tiene script, ni hoja de estilo externa ni fuente, porque se publica en un sitio web público por quien lo mantiene, y cualquier cosa que cargue desde otro lugar es algo más que puede fallar o rastrear a un visitante. -format csv y -format json dan los mismos números para otros usos. Sin -services, la página lleva un aviso de que la lista de artículos y servicios que requieren autorización previa está falta, porque CMS lo requiere en la misma página.

16.8 Medicamentos: el formulario, el Beneficio de Receta en Tiempo Real y la autorización previa electrónica

CMS-0062-P (propuesto el 14 de abril de 2026) introduciría medicamentos en la autorización previa: los pagadores afectados admitirían la autorización previa electrónica de NCPDP SCRIPT, el estándar de formularios y beneficios de NCPDP y el beneficio de prescripción en tiempo real de NCPDP a partir del 1 de octubre de 2027, decidirían las solicitudes de medicamentos dentro de las 24 horas (expedidas) y 72 horas (estándar), darían una razón específica para cada denegación, y informarían métricas de medicamentos a partir de 2028. Medicare Part D ya requiere SCRIPT ePA. Un archivo, el formulario, responde a todo esto:

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -formulary formulary.yaml

examples/formulary/formulary.yaml es un ejemplo cuyos medicamentos son conceptos reales de RxNorm con NDCs de RxNorm para ellos (comprobados contra RxNav). Un archivo nombra al pagador, sus planes (cada uno con la formularios que utiliza, sus identificadores de grupo y sus participaciones en costos por beneficio de farmacia y nivel) y sus formularios. Cada medicamento es un SCD o SBD de RxNorm con su grupo de RxNorm (el SCDG o SBDG que requiere la API de Formulario de Medicamentos), sus NDCs, un nivel, y sus límites: prior_authorization, step_therapy, quantity_limit (una cantidad en un número determinado de días, y un máximo diario), not_covered, alternatives (códigos de RxNorm, con el más preferido primero), notes, y questionnaire, la URL canónica del cuestionario FHIR que solicita una autorización previa. cost_30_day es el costo del plan para un suministro de 30 días, que es un porcentaje de la coparticipación; sin él, la coparticipación se cita como un porcentaje, nunca como una cantidad inventada. Todo el archivo se comprueba cuando se carga, y se lista cada problema de una vez. Un miembro se encuentra por la lista members del archivo, por grupo, o a través de la tienda FHIR: una Coverage cuyo subscriberId es el ID del miembro y cuya class de tipo plan es el ID del plan. Payers › Drugs muestra el formulario, precios de un medicamento y ejecuta una autorización previa de principio a fin.

16.8.1 La API de formulario de medicamentos Da Vinci US

Publicado en /formulary/fhir como Formulario de Medicamentos de Da Vinci US 2.1.0: cada plan es un PayerInsurancePlan, cada formulario es un Formulary (ambos InsurancePlan), cada medicamento es un FormularyDrug (MedicationKnowledge) y cada entrada es un FormularyItem (Basic). Las búsquedas de la guía se sirven (Basic?code=formulary-item&formulary=...&drug-tier=...&pharmacy-benefit-type=...&period=..., subject:MedicationKnowledge.code, InsurancePlan?formulary-coverage=..., coverage-type, MedicationKnowledge?code=...&doseform=...) con _include=Basic:subject, Basic:formulary y InsurancePlan:formulary-coverage. Es público, sin credenciales, como requiere CMS de un formuario de un pagador: se sirve desde una tienda propia, en memoria, que contiene el formulario y nada más, por lo que estar abierto no puede llegar a un registro de paciente. Es de solo lectura. Un medicamento excluido no se publica, ya que la API enumera lo que cubre un formulario; RTPB y ePA aún responden como no cubierto. Verificado con el validador HL7 FHIR contra el paquete 2.1.0 de la guía con terminología comprobada: cada recurso generado a partir del ejemplo no tiene errores.

16.8.2 Beneficio de Receta en Tiempo Real

POST /ncpdp/rtpb toma un RTPBRequest (NCPDP RTPB v13) con un token de API del rol de operador y responde con un RTPBResponse del formulario: el estado de cobertura, el estado del formulario, la participación estimada del miembro y la del plan, y las restricciones de cobertura, con hasta cinco alternativas cubiertas con el mismo precio. Los códigos de restricción y el estado al que cada uno se asigna siguen las Recomendaciones de implementación de RTPB de NCPDP: 75 autorización previa requerida, 608 terapia de paso, 76 límites del plan excedidos, 7X días de suministro superados al límite del plan (un medicamento no disponible por correo, por ejemplo), 70 no cubierto, todos *cubiertos con restricciones* (CR) excepto 70 (NC). Un miembro con una autorización previa aprobada en archivo obtiene CC y AB8, como solicita la guía de Surescripts, para que el prescriptor no sea enviado a solicitar nuevamente. Una solicitud que no se puede preciar es NotProcessed con un código de rechazo de NCPDP: 52 para un miembro no encontrado, E7 y 19 para una cantidad o días de suministro faltantes. El beneficio de farmacia se lee desde la solicitud: un llenado superior a 34 días es un suministro de tres meses, y el tipo de farmacia M es por correo.

16.8.3 Autorización previa electrónica (NCPDP SCRIPT)

POST /ncpdp/script toma PAInitiationRequest, PARequest, PAAppealRequest y PACancelRequest con un token de API del rol de operador, y responde a cada uno con su respuesta:

El conjunto de preguntas es el cuestionario FHIR del medicamento de la tienda FHIR, el mismo que DTR completa: un booleano se convierte en una elección de sí/no, una elección en una elección, un número en numérico, una fecha en fecha, y cualquier otra cosa en texto libre; los grupos se aplanan en orden, y enableWhen no se transporta, ya que SCRIPT ramifica por elección y no por condición. Un medicamento sin cuestionario se le hacen tres preguntas de texto libre: el diagnóstico, qué se intentó, y por qué este medicamento. Un PARequest se convierte en una solicitud de PAS de Da Vinci: un Claim para el medicamento (RxNorm y NDC), la MedicationRequest que solicita, el paciente, el prescriptor, el pagador y la cobertura, y las respuestas como un QuestionnaireResponse, con cualquier adjunto como DocumentReference. Luego se decide como se decide cada autorización previa en este servidor: el archivo de reglas, un servicio de decisión (-pas-decider-url), o la cola de revisores, donde se marca Medicamento y se mantiene en los plazos del medicamento. Un servicio de decisión ve una solicitud de medicamento exactamente como ve una solicitud de un cliente de PAS de un sistema de registros electrónicos de salud. Recomendamos Vaglio, el motor de decisión de código abierto (PolyForm Shield) de BioDream, que tiene políticas de medicamentos con terapia de paso; el motor de un pagador se conecta a través de la misma -pas-decider-url, y no se necesita ninguno para que el archivo de reglas y los revisores decidan.

Una decisión tomada después de que se respondió la solicitud (una del revisor, una apelación) se envía al prescriptor como una respuesta no solicitada PAResponse o PAAppealResponse, enrutada al canal nombrado por -epa-reply-channel, que la entrega a la red. Sin uno, o cuando la entrega falla, el caso dice que el prescriptor no ha sido informado y la pantalla la envía nuevamente.

Payers › Drugs › Prior authorization envía los mensajes que el sistema de un prescriptor enviaría a este servidor (iniciar, responder las preguntas, ver la decisión), enumera cada caso con lo que se le informó al prescriptor, y muestra las cifras del medicamento que propone CMS-0062-P: solicitudes aprobadas, denegadas y pendientes, apeladas y aprobadas o denegadas en apelación, la media y mediana de horas desde la solicitud hasta la decisión, y cuántas se decidieron tarde. Los medicamentos de beneficio médico solicitados a través de PAS (un código HCPCS J con una MedicationRequest, o un artículo codificado en RxNorm o NDC) se cuentan como medicamentos en las cifras de PAS también.

Lo que esto se basa en, expuesto claramente. Los esquemas y guías de implementación de NCPDP están licenciados. Los nombres de los elementos y el orden que se siguen aquí son los de las guías de acompañamiento públicas de Surescripts ePA y RTPB, y sus ejemplos, y las recomendaciones públicas de RTPB de NCPDP. Dos elementos que el material público nunca muestra están escritos en el patrón SCRIPT utilizado en otros lugares y deben verificarse contra una copia licenciada antes de la certificación: Closed/ReasonCode y Denied/DenialReason. Ningún mensaje ha sido verificado contra el XSD de NCPDP o la certificación de una red. El archivo de Formulario y Beneficio de NCPDP no se produce: su diseño completo está en la guía licenciada de NCPDP, y un archivo parcial sería rechazado por la red que lo carga.

16.9 Qué se verificó y contra qué

Las salidas de CARIN y PDex se validaron con el validador oficial de HL7 FHIR, cargado con los paquetes publicados (hl7.fhir.us.carin-bb#2.2.0, hl7.fhir.us.davinci-pdex#2.2.0): reclamaciones profesionales, de pacientes internados y externados y dos decisiones de PAS, sin errores. Las entradas de PDex fueron los propios ejemplos de la guía de PAS en lugar de las formas escritas aquí para estar de acuerdo con el convertidor. El validador encontró cinco defectos en la primera ejecución — entre ellos que CARIN requiere la versión del perfil en meta.profile y la versión del sistema de codificación de tipo de reclamación en reclamaciones institucionales — y cada uno está corregido y cubierto por una prueba.

La construcción de esto encontró un defecto más antiguo que él: el almacen de FHIR eliminaba cada elemento que su modelo interno no declaraba, por lo que una ExplanationOfBenefit perdía sus elementos, diagnósticos, adjudicación y pago en el camino. El almacen ahora mantiene lo que lleva cada recurso, y una prueba carga una reclamación de CARIN a través del servidor y la lee completa nuevamente.

La salida de CRD - el pedido actualizado y la respuesta de CDS Hooks contra el modelo lógico propio de CRD - y la salida del paquete de DTR se validan en el validador oficial de HL7 contra CRD 2.2.1 y DTR 2.2.0 sin errores.

DTR aquí es el lado del pagador de 2.2.0. $questionnaire-package toma los cuestionarios nombrados, aquellos que CRD nombró en un pedido, o la identificación de la afirmación de cobertura que CRD devolvió (context, mientras el mismo proceso está sirviendo a CRD), y devuelve cada uno como un paquete de bundle con una QuestionnaireResponse para rellenar, las Bibliotecas que su CQL necesita y sus dependencias. Los conjuntos de valores que sus respuestas utilizan viajan en el paquete cuando se cargan (PUT /fhir/ValueSet/{id}), y $expand enumera sus códigos. $log-questionnaire-errors escribe lo que una aplicación DTR informa al registro del servidor.

Cuestionarios adaptativos: escriba todo el cuestionario una vez, con la extensión questionnaireAdaptive de SDC y enableWhen en las preguntas que solo se aplican a veces. El paquete le da a la aplicación un shell vacío, y cada llamada a $next-question agrega la siguiente pregunta que se aplica a las respuestas hasta ahora, hasta que no hay nada más que preguntar y la respuesta se marca como completada. El orden y la ramificación son las reglas propias del pagador; las preguntas que no se aplican nunca se muestran.

Iniciar sesión como cliente: los clientes DTR y PAS llegan al pagador con los Servicios de backend SMART - un JWT firmado intercambiado por un token en el servidor de autorización del pagador. Apunte Perfuse a ese servidor con -smart-issuer (y -smart-jwks si su dirección no se resuelve desde Perfuse), y pase -smart-backend-services para que el documento de descubrimiento diga que sí. La suite DTR de Inferno pasa por este camino con Keycloak como servidor de autorización.

Perfuse puede ser ese servidor de autorización en sí mismo: serve -fhir -smart-clients clients.yaml emite tokens de Servicios de backend en /auth/token a los clientes enumerados, cada uno con las claves públicas que firma sus afirmaciones y los ámbitos del sistema que puede ser concedido, y el punto de conexión de FHIR los acepta. No se necesita un servidor de identidad separado para los clientes de máquina a máquina de un pagador.

Con -smart-users users.yaml también, los miembros y los clínicos inician sesión allí para autorizar aplicaciones, lo que necesita la API de Acceso de Pacientes: la aplicación envía a la persona a /auth/authorize, inician sesión, un clínico elige al paciente y ambos ven lo que la aplicación solicita y pueden desmarcar cualquier parte de ello. Un miembro solo recibe su propio registro, independientemente de lo que la aplicación solicite. Cada persona en el archivo nombra el recurso de FHIR que es, Patient/… o Practitioner/…, y un hash de contraseña de perfuse smart hash; la contraseña en sí nunca se escribe.

Las personas pueden iniciar sesión en el proveedor de identidad de la organización en su lugar: -smart-oidc oidc.yaml lo nombra (emisor, id de cliente y dónde está el secreto), y la página de inicio de sesión ofrece "Iniciar sesión con" él junto a la contraseña. Cada persona está vinculada por el sujeto del proveedor, oidc_subject en el archivo de usuarios, para que el archivo aún decida quién puede autorizar aplicaciones y qué recurso de FHIR es; una cuenta vinculada a nadie es rechazada. Los códigos, los tokens de actualización y las revocaciones se mantienen en la base de datos, para que un reinicio no desconecta a nadie.

Usuarios → Aplicaciones SMART en la consola enumera las aplicaciones registradas y las personas, y las agrega, edita y elimina. Cada guardar es verificado como los archivos en el inicio, escritos en ellos y utilizados de inmediato. Una aplicación confidencial guardada sin secreto se le asigna uno, muestra una vez; una contraseña se establece allí y nunca se muestra nuevamente. Eliminar una aplicación, o una persona, detiene los tokens de acceso ya emitidos para ella o concedidos por ellos de inmediato, no cuando expiren, y sus tokens de actualización con ellos.

Los ámbitos pueden ser granulares, como define SMART App Launch 2 y US Core: patient/Observation.rs?category=laboratory solo lee las Observaciones que encontraría esa búsqueda. Una concesión que se filtra para un tipo aplica su filtro a cada búsqueda y cada lectura de ese tipo; una concesión no filtrada para el tipo, o para *, levanta el filtro. Un filtro que no se puede leer no concede nada en lugar de todo.

16.10 Decidiendo solicitudes de autorización previa: PAS

serve -fhir -pas -crd-rules rules.yaml responde a Da Vinci PAS 2.2.1 en POST /fhir/Claim/$submit y POST /fhir/Claim/$inquire. Las decisiones provienen del mismo archivo de reglas que las respuestas de CRD, por lo que el orden en que se le informa a un clínico que necesita autorización se decide mediante la regla que así lo indicó:

  - description: Physical therapy
    codes: ["PT"]                       # matched on the item's productOrService, then the code of the order it requests
    system: https://codesystem.x12.org/005010/1365
    covered: covered
    pa: auth-needed
    pa_decision: approve                # approve, deny or pend; empty: not-covered is denied, no-auth approved, the rest pended
    details:
      - {code: allowed-quantity, value: "6"}   # asked for more, it is certified for six (A6, with the authorised detail)
  - description: MRI
    codes: ["62"]
    pa_decision: approve
    pa_alternative: {system: "https://codesystem.x12.org/005010/1365", code: "4"}  # approved as an X-ray instead (an added item)
  - description: Surgery
    codes: ["2"]
    pa: auth-needed                     # pended for a reviewer, asking for:
    questionnaire: https://payer.example.org/Questionnaire/surgery   # a DTR questionnaire
    pa_attachments: ["18776-5"]         # and documents, by LOINC attachment code

Cada elemento recibe una acción de revisión X12: A1 certificado, A3 no certificado, A4 pendiente, A6 modificado, C cancelado (tipo de certificación 3). Una línea que no nombra ningún servicio no se decide pero se responde con un error (X12 901 AG, correcto y vuelva a presentar). La respuesta repite lo que una respuesta 278 repite — números de seguimiento de elementos, las fechas de servicio solicitadas, las fechas del encuentro, los identificadores de transmisión con el remitente y el receptor intercambiados — y da a cada línea el número de referencia de administración del pagador. Un servicio que ninguna regla nombra se pende, nunca se aprueba: una decisión que nadie escribió es una decisión para una persona.

Solicitudes pendientes esperan a un revisor, que responde con POST /fhir/Claim/$decide:

{"resourceType": "Parameters", "parameter": [
  {"name": "claimResponse", "valueString": "<the ClaimResponse id>"},
  {"name": "decision", "valueCode": "approve"},
  {"name": "reason", "valueString": "Reviewed with the plan of care."},
  {"name": "reviewer", "valueString": "<the reviewer's NPI>"}]}

decision también puede ser modify: certificado, pero no como se solicitó, con quantity (valueDecimal, las unidades certificadas) y/o alternative (valueCoding, el servicio aprobado en su lugar). La respuesta entonces dice A6 Modificado, con el detalle certificado o el alternativo como un elemento agregado, y un número de autorización. item (valueInteger, repetible) limita la decisión a algunas líneas. La decisión se convierte en una nueva versión de la respuesta, marcada como revisada por una persona, y con -fhir-subscriptions se entrega en el tema PAS (PASSubscriptionTopic, filtrado por org-identifier, el identificador de la organización solicitante) como el paquete de respuesta PAS completo, en la misma transacción que lo registra. $inquire devuelve la respuesta actual a cada solicitud que el proveedor realizó sobre ese miembro; una consulta de otro proveedor no encuentra nada. $decide necesita un alcance de escritura; $inquire es de lectura.

Las solicitudes y cada versión de sus respuestas se mantienen en pas_requests y pas_responses en la base de datos del servidor.

16.10.1 La cola del revisor

En la consola web, Payers → CMS-0057 → Cola de revisor lista las solicitudes pendientes próximas a vencerse primero: una solicitud urgente (Claim.priority stat) vence 72 horas después de su llegada, una estándar en 7 días. Seleccionar una muestra al afiliado, al proveedor, cada servicio con las unidades solicitadas y su estado, lo que se solicitó en la respuesta y cada documento recibido para ello, con documentos de texto plano mostrados en línea. Un editor registra la decisión allí: aprobar, denegar o modificar (unidades certificadas, o otro servicio aprobado en su lugar), con un motivo y el NPI del revisor. Una modificación debe certificar menos unidades de las solicitadas; tantas o más es una aprobación y se rechaza como modificación. Un servicio aprobado en su lugar comienza en el sistema de códigos del solicitado. Es la misma decisión que toma $decide, por lo que la suscripción del proveedor la entrega. Leer una solicitud y decidir sobre ella se escriben ambos en el registro de auditoría.

Monitor → Team dashboards → Prior authorization muestra, para los últimos 30 días, cuántas solicitudes estándar y urgentes se decidieron dentro de los plazos de CMS-0057, se decidieron con retraso, todavía están esperando a tiempo y vencidas ahora, con el tiempo medio para decidir, y cómo se respondieron los servicios solicitados: aprobados, modificados, denegados o todavía pendientes. Estos dos mosaicos se leen de las solicitudes en sí, por lo que no están en la exportación de Grafana del panel, que dice que no en su descripción.

16.10.2 Recibir los documentos que solicita una solicitud pendiente

Una respuesta pendiente solicita documentos con una Tarea y una Solicitud de Comunicación por documento. Un cuestionario se solicita como PAS lo describe: una Solicitud de Comunicación con el único código LOINC 102089-0, bajo el número de seguimiento de la línea que es para (itemTraceNumber, que el ClaimResponse eco; una línea enviada sin uno se le da uno). Ese número de seguimiento es el contexto de DTR: $questionnaire-package con solo context establecido en él devuelve el cuestionario. El proveedor envía lo que se solicitó con Da Vinci CDex $submit-attachment (POST /fhir/$submit-attachment): el TrackingId es el número de seguimiento de la solicitud (el primer identificador del ClaimResponse, que también es el de la Tarea), o un identificador de Solicitud de Comunicación, AttachTo es preauthorization, y MemberId debe ser el miembro de la solicitud. Cada DocumentReference o QuestionnaireResponse de la adjunta se mantiene con la solicitud y se muestra a su revisor; un documento que llega decide nada.

16.10.3 Decidir en un sistema de gestión de utilización X12

La mayoría de los pagadores deciden las autorizaciones previas en un sistema de gestión de utilización que habla X12 278. Con -pas-278-url, Perfuse es la interfaz de FHIR de ese sistema: cada $submit se envía como una solicitud 278 (005010X217), y cada elemento es un evento de paciente. Cada uno lleva lo que PAS nombra para ello: el tipo de revisión (extension-serviceItemRequestType, UM01: servicios de salud, admisión o atención especializada), el tipo de certificación (extension-certificationType, UM02), el tipo de servicio, el lugar de servicio (UM04), el nivel de servicio (extension-levelOfServiceCode, UM06: electivo, urgente o de emergencia; una prioridad stat se utiliza en lugar de urgente), la fecha, las fechas de admisión y alta de una revisión de admisión, los diagnósticos, el proveedor del equipo de atención que realizará el servicio y el procedimiento y la cantidad, como un servicio profesional (SV1) o, en una reclamación institucional, una línea de servicio de hospital (SV2). El código de acción y el número de autorización de la respuesta 278 se convierten en la acción de revisión del elemento: certificado, en parte o modificado, denegado, pendiente, cancelado o no considerado (pendiente para un revisor, con los motivos de rechazo). Las reglas locales no se consultan.

perfuse serve -fhir -pas -pas-278-url https://um.example/x12/278 -pas-278-receiver ACMEUM \
  -pas-278-token-env UM_TOKEN

Un sistema de UM que pende primero y decide después publica su respuesta posterior 278 en POST /fhir/Claim/$decide-278; cada evento se asocia con su solicitud mediante el número de seguimiento que Perfuse envió, y se decide como $decide lo decidiría. Si no se puede alcanzar el sistema de UM o responde con algo que no es una respuesta 278, cada elemento se pone en espera para un revisor y al proveedor solo se le informa de eso; la razón se encuentra en el registro del servidor.

Consultas que el sistema UM responde

La $inquire de un proveedor debe encontrar una autorización sin importar cómo se solicitó: por fax, a través del portal del pagador, por teléfono o en un 278 que otro remitente envió. Perfuse solo mantiene las solicitudes que llegaron a través de él; el sistema de gestión de utilización (UM) mantiene todas. Así, con un sistema UM que responde en tiempo real (cada transporte excepto sftp), cada $inquire también se envía allí como una consulta de autorización 278 (005010X215: BHT02 28, el miembro, el proveedor, el número de autorización del insurance.preAuthRef del reclamo cuando existe, y las fechas de eventos desde billablePeriod o las fechas de servicio de los artículos, de lo contrario un año a cada lado de la fecha actual). Cada autorización que la respuesta contiene y que Perfuse no tiene (coincidiendo con los números de seguimiento que envió y los números de autorización que ya dio) regresa como un paquete de respuesta de consulta de reclamo adicional: la decisión del sistema UM para cada línea de servicio, el número y período de autorización, y una nota que indica dónde se encontró. No se crea un reclamo para una autorización que nadie presentó en FHIR: su ClaimResponse.request lleva una razón de ausencia de datos, como permite el perfil de PAS. Una consulta solo lee; nada en los propios registros de Perfuse cambia. Si el sistema UM está caído o responde con un TA1 o 999, el proveedor recibe lo que Perfuse mantiene, y el estado del enlace indica por qué. La forma sigue las guías de acompañamiento de la consulta 278 que publican UnitedHealthcare, Cigna y Blue Cross Blue Shield de Massachusetts; no se ha probado contra un sistema UM real.

Cómo los 278s llegan al sistema UM

La guía de conectividad del sistema UM dice cómo toma los 278, y -pas-278-transport (Configuración, Pagadores, Enlace de gestión de utilización) lo sigue:

Un certificado de cliente es -pas-278-cert y -pas-278-key; -pas-278-ca confía en la autoridad de certificación del pagador. OAuth es -pas-278-oauth-token-url, -pas-278-oauth-client-id y el secreto, obtenido con la concesión de credenciales de cliente y mantenido hasta un minuto antes de que expire. Las contraseñas, tokens y secretos nunca son indicadores: cada uno se nombra mediante una variable de entorno (-pas-278-password-env, -pas-278-token-env, -pas-278-oauth-secret-env, -pas-278-sftp-password-env), o se escribe en la pantalla de configuración, donde se mantiene en el archivo de configuración (legible solo por la cuenta del servidor) y nunca se muestra nuevamente.

UM_PASSWORD=... perfuse serve -fhir -pas -pas-278-transport core-soap \
  -pas-278-url https://um.example/CORE/RealTime -pas-278-receiver ACMEUM \
  -pas-278-user perfuse -pas-278-password-env UM_PASSWORD

Sobre SFTP, cada solicitud se mantiene pendiente hasta que llega su respuesta: la respuesta 278 decide los artículos, y Perfuse coloca un 999 que lo acepta en la carpeta de salida. Un archivo que no se puede leer permanece en la carpeta de entrada para que lo revise una persona y se ofrece nuevamente en la próxima lectura.

Cuando el sistema UM no puede leer una solicitud

Un sistema UM que no puede leer un 278 responde con un TA1 (el sobre) o un 999 (la transacción) en lugar de una decisión. Perfuse lee cuál y qué dice, mantiene pendiente cada artículo ("la gestión de la utilización no pudo leer la solicitud"), y lo registra. La cola del pagador, CMS-0057, Reviewer muestra el enlace: qué se envió en los últimos siete días, cada intercambio por su número de control, y qué sucedió con él (respondido; reconocido, respuesta a venir; rechazado, con el segmento, elemento y código del 999; no alcanzado). Cada intercambio tiene su propio número de control, uno más que el último, que es lo que un TA1 o 999 nombra cuando responde.

16.10.4 Decidir sobre la evidencia clínica, con un servicio de decisión

Un archivo de reglas decide por código de servicio: un código no necesita autorización, no está cubierto o va a un revisor. Si este paciente cumple con los criterios para él es una pregunta diferente, respondida desde las condiciones, respuestas de cuestionarios y documentos que el proveedor envió con la solicitud. Con -pas-decider-url, cada elemento que las reglas dejan a un revisor se envía primero a un servicio de decisión, como Vaglio, que lee el mismo paquete de solicitud PAS a través del paquete pas publicado de Perfuse. Un Vaglio público, en solicitudes inventadas solo, se ejecuta junto a la instancia de prueba de Perfuse en https://vaglio.perfuse.health:8443 (inicie sesión como demo, contraseña try-vaglio-demo; puede ver todo y no cambiar nada): cada decisión allí tiene su prueba, una carta en lenguaje plano y un recibo que cualquier persona puede verificar.

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -pas-decider-url https://vaglio.example/api/pas/decide \
  -pas-decider-token-env VAGLIO_TOKEN

La URL debe ser https, o http plano a esta máquina (localhost, 127.0.0.1), porque lleva el registro del paciente y el token. Vaglio mismo responde solo en https; cuando utiliza un certificado de su propia autoridad, pase esa autoridad con -pas-decider-ca DATA/tls/ca.crt (o cualquier autoridad interna del pagador del que proviene el certificado del servicio). El servicio recibe el paquete de solicitud como lo envió el proveedor, POST <url>?item=<sequence> (application/fhir+json), y responde {"decision": "approve" | "deny" | "pend", "why": "...", "requested": ["..."]}, o 404 cuando no decide nada para ese elemento, lo que deja la respuesta de las reglas en pie. why es la nota de proceso de la respuesta y es obligatoria para una denegación, que de lo contrario se pendiente; requested se dice al proveedor como la información que una solicitud pendiente necesita. Un pendiente también puede llevar "questionnaire": "<canonical>" y "attachments": ["<LOINC>", ...], que se solicitan en la tarea CDex y las solicitudes de comunicación de la respuesta junto con cualquier cuestionario DTR o adjuntos que la regla solicite (el cuestionario de la regla gana, ya que una tarea solicita uno; un código que no tiene la forma de LOINC se descarta y se registra). Una regla que aprueba o deniega es la política de cobertura del pagador y no se envía al servicio. Un fallo, un tiempo de espera o una respuesta que no es una de las tres decisiones pendiente el elemento para un revisor, con la razón en el registro del servidor: nada aquí convierte un fallo en una aprobación. No se puede combinar con -pas-278-url, donde el sistema UM responde cada elemento.

Consejo antes de enviar. Con -crd-advisor-url junto a -crd-rules, CRD también pregunta a un servicio de decisión qué le diría a una solicitud de autorización previa para cada orden que la necesite, según el estado actual del registro, y muestra la respuesta como una tarjeta más: "Antes de enviar: una solicitud para esto necesitaría: ...", o "sería aprobada", con lo que aún se necesita, el cuestionario que lo solicita y qué lo aprobaría. Vaglio responde en /api/pas/advise, con el mismo token y autoridad que antes:

perfuse serve -fhir -pas -crd-rules payer-rules.yaml \
  -crd-advisor-url https://vaglio.example/api/pas/advise -crd-advisor-token-env VAGLIO_TOKEN

CRD envía POST <url> con {"service": {"system": "...", "code": "..."}, "resources": [ ... ]}, los recursos siendo el prefetch del gancho (el paciente primero, la cobertura omitida), y lee {"decides": true, "answer": "approve" | "pend" | "deny", "summary": "...", "missing": [...], "questionnaire": "...", "toApprove": [[...]], "policyTitle": "..."}. Es un consejo y no cambia nada: la información de cobertura, las otras tarjetas y la decisión de PAS son lo que dicen las reglas. Espera como máximo tres segundos, y no hay respuesta, un error o "decides": false deja la respuesta exactamente como está sin ella. Perfuse nunca necesita un servicio de decisión.

La solicitud lleva X-PAS-Request-Id, el id por el que se conoce la respuesta. Un servicio con sus propios revisores que pendiente un elemento puede enviar su decisión más tarde como la de cualquier revisor: Claim/$decide con ese id como claimResponse, la secuencia del elemento y la decisión y razón. La suscripción del proveedor lo entrega como si se hubiera hecho en la cola del revisor.

Una suscripción con contenido id-only informa al proveedor qué respuesta cambió sin decir qué es: el enfoque de la notificación es Bundle/<id>. GET /fhir/Bundle/<id> devuelve el paquete de respuesta PAS más reciente, GET /fhir/Bundle/<id>/_history/<n> la versión que envió una notificación, y GET /fhir/ClaimResponse/<id> la ClaimResponse sola. Un token vinculado a un paciente se le dice que no existen, como para cualquier registro fuera de su paciente.

Verificado con la suite oficial de Inferno PAS Server v2.2.1 (ver verificación). No se envía, aunque PAS marca must-support: ClaimResponse.adjudication con una acción de revisión, ClaimResponse.extension:authorizedProvider y ClaimResponse.item.extension:communicatedDiagnosis, porque las extensiones que necesitan no están permitidas allí por su propio contexto en PAS 2.2.1 y el validador rechaza una respuesta que las lleva; y request.extension:DataAbsentReason, porque Perfuse siempre conoce la solicitud. Los 278 enviados a un sistema de gestión de la utilización (arriba) se verifican contra los propios ejemplos de solicitud de PAS 2.2.1, los ejemplos de esMD 278 publicados por CMS y un verificador de 278 escrito a partir de guías de acompañamiento públicas, y cada transporte contra un sistema UM de reemplazo escrito a partir de las reglas de conectividad de CAQH (ver verificación); aún no contra un sistema UM real o una cámara de compensación, y no certificado por CORE. No implementado: adjuntos enviados con CDex.

Un archivo de reglas se verifica contra las invariantes propias de CRD cuando se carga: un cuestionario necesita documentación, un servicio que no está cubierto no puede necesitar autorización, satisfied pertenece a un caso y no a una regla, y cualquier cosa condicional debe dar una razón.

No verificado: las exportaciones y la coincidencia de miembros contra la implementación de otro pagador, las métricas contra las cifras publicadas de un pagador, y CRD contra un cliente CDS Hooks real de un sistema de registros electrónicos de salud.

16.11 Enviar solicitudes de autorización previa a un pagador (para proveedores)

Todo lo anterior responde a solicitudes, como un pagador. El lado de un proveedor es al revés: una aplicación de registro electrónico de salud o una aplicación de registro de tratamiento construye un paquete de solicitud de Da Vinci PAS, y algo tiene que enviarlo al pagador, mantener la respuesta y pasarla. Un destino pas hace eso.

name: prior-auth-out
dataType: raw
source:
  type: http
  http:
    listen: 127.0.0.1:8095
    path: /pas
destinations:
  - name: acme-health
    type: pas
    pas:
      payer: https://pas.acme-health.example/fhir
      bearer_token: ${ACME_PAS_TOKEN}     # or auth: { type: client_credentials, token_url, client_id, client_secret }
      results_to: pas-answers             # optional: a channel that takes each answer back to the EHR

Cada mensaje debe ser una solicitud completa de PAS en un canal sin procesar. Perfuse la publica sin cambios en {payer}/Claim/$submit: el pagador decide sobre la Solicitud de Reclamo junto con el paciente, la cobertura y los recursos de apoyo en el Paquete, y una Solicitud de Reclamo reconstruida a partir de un resumen perdería estos. Fuera de esta máquina, la dirección del pagador debe ser https.

Una decisión es una solicitud entregada, sea lo que sea. Una aprobación, una denegación y una pendiente son todas registradas y ninguna se vuelve a intentar, porque volver a intentar una denegación presenta la misma solicitud dos veces. Lo que falla la entrega, y se vuelve a intentar, es un pagador que no decidió: un estado de error, un OperationOutcome (su texto es el error) o una ClaimResponse cuyo resultado es error. La decisión se lee artículo por artículo desde los códigos de acción de revisión de PAS (X12 306: A1 aprobado, A2 parcialmente, A3 denegado, A4 pendiente, A6 modificado); una respuesta sin código se enumera como "sin código de decisión" en lugar de tomarse como una aprobación. Una denegación sin razón en ningún lugar se rechaza por no cumplir con CMS-0057.

La respuesta del pagador es la respuesta del destino, por lo que Inspeccionar la respuesta puede juzgarla, y results_to la pasa a otro canal. Cada solicitud se enumera en CMS-0057, Solicitudes enviadas a pagadores: cuándo se envió, el paciente, el servicio, la decisión y la referencia del pagador (preAuthRef), que una consulta posterior nombra. La lista se mantiene en prior-auth.json junto a la base de datos (como máximo 10,000 solicitudes; las decididas más antiguas van primero, una pendiente nunca lo hace), y cada inquilino solo ve el suyo.

Verificado contra la implementación de referencia de pagador de HL7 Da Vinci PAS (imagen de docker hlseven/davinci-prior-auth): una solicitud enviada a través de un canal en ejecución se pende por ella con su referencia, y la respuesta se muestra en la pantalla (ver verificación). Todavía no se ha intentado contra un pagador de producción. No construido: seguir una solicitud pendiente con $inquire, o recibir la respuesta posterior del pagador por suscripción; un canal puede hacer cualquiera de estas cosas hoy con un destino http o fhir.

16.12 Redes Aligned de CMS

El Marco de Interoperabilidad de CMS (Ecosistema de Tecnología de Salud de CMS) solicita a las redes de datos de salud que se autoevalúen con respecto a 26 criterios y sean incluidas como Redes Alineadas con CMS; los registros electrónicos de salud (EHR), los proveedores, los pagadores y las aplicaciones se conectan a ellas. Los criterios 13 a 16 han estado en vigor desde el 4 de julio de 2026: APIs de FHIR en US Core con un CapabilityStatement completo y datos en bloque, documentos como adjuntos de FHIR legibles por humanos, notificaciones de citas y encuentros mediante suscripción de FHIR, y un localizador de registros.

Administrar › Red Alineada con CMS enumera cada criterio con lo que Perfuse proporciona para él y dónde se encuentra este servidor, leído desde lo que está activado aquí:

Lo que los cuatro en vigor necesitan de este servidor:

La pantalla es una hoja de trabajo para la autoevaluación, no una certificación: CMS revisa las redes que sospecha no cumplen con los criterios, y el texto del marco es la autoridad. No se ha construido hoy: consultas de brechas de calidad abiertas (criterio 8), una consulta de un pagador para los datos de encuentro de una reclamación (9), informes de métricas de consultas al Directorio Nacional de Proveedores (19), verificación de proveedores contra ese directorio (6), lectura de licencias de conducir móviles o tarjetas de seguro digitales (3, 23), y aplicación de una política de consentimiento general en cada lectura (5). La verificación de identidad IAL2 es del servicio de identidad; Perfuse acepta los tokens del que elija.

17 Seguridad

Perfuse maneja datos clínicos. Este capítulo es lo que hace al respecto y lo que deja a usted.

17.1 Seguridad de transporte

TLS en la interfaz web se configura con -tls-cert y -tls-key. Sin ellos, la interfaz es HTTP plano, lo que es aceptable en una dirección de bucle de retorno para una primera mirada y en ningún otro lugar — lleva credenciales y contenido de mensaje, ambos legibles en el cable.

TLS en los transportes de canal es por fuente y por destino, bajo un bloque tls. Los ajustes disponibles están en las referencias de fuente y destino.

insecure_skip_verify acepta cualquier certificado. Existe porque los sistemas hospitalarios presentan rutinariamente certificados que no se pueden verificar, y rechazar la conexión significaría rechazar la integración. Está nombrado para ser conspicuo, y usarlo significa que la conexión está cifrada pero no autenticada — tiene protección contra la interceptación pasiva y ninguna contra un servidor interposición.

17.2 Autenticación y roles

Los usuarios se almacenan en la base de datos. Cada uno tiene uno de cinco roles, y cada rol incluye todo lo que está en los roles anteriores:

Un sexto rol, Plataforma, pertenece a quien ejecuta un servidor compartido: crea inquilinos y establece sus límites, y no tiene canales propios.

Monitor es para un escritorio de ayuda o para una pantalla de operaciones en una pared: todo lo necesario para ver que una fuente de alimentación se ha detenido, y nada que nombre a un paciente. El visor puede leer el contenido del mensaje, que es datos clínicos; es un rol de baja privilegio para *configuración*, no para privacidad. El operador separa la reparación de una entrega fallida por la noche del cambio de lo que hace una fuente de alimentación: la persona que reenvía no necesita poder reescribir el canal.

17.2.1 Contraseñas incorrectas repetidas

Las contraseñas incorrectas y los intentos de inicio de sesión de passkey fallidos se cuentan por la dirección desde la que proviene la conexión, y después de unos pocos seguidos, esa dirección espera antes de poder intentarlo nuevamente (la respuesta es 429, con Retry-After). Las cuentas no se bloquean por nombre, porque eso permitiría que cualquier persona bloqueara a un administrador a propósito.

La dirección es la propia de la conexión, nunca una que una solicitud afirma en X-Forwarded-For, que escribe el remitente. Detrás de un proxy inverso en la misma máquina, Perfuse utiliza la última entrada X-Forwarded-For en su lugar, la que agregó el proxy, para que cada cliente siga siendo contado por separado. Un proxy en otra máquina alcanza Perfuse desde una dirección, y todos sus clientes comparten un recuento: limita la tasa de inicio de sesión en ese proxy también.

17.2.2 Grupos de canales

Una persona (o un token de API) se puede limitar a algunos grupos de canales: entonces solo ve y actúa en los canales cuyo group es uno de los suyos. Este es el arreglo de un grupo hospitalario en un servidor, donde los analistas de cada instalación se encargan de sus propios flujos de datos y un equipo central, sin límites, se encarga de todos ellos. Rhapsody lo llama un locker.

El límite se aplica en todas partes al mismo tiempo, porque se aplica a la solicitud en lugar de ser recordado por cada pantalla: la lista de canales, el panel de instrumentos y el mapa de flujo, los mensajes y su búsqueda, los recuentos y gráficos, la cola, las alertas, las métricas, los certificados, los contratos y el uso de conjuntos de códigos. Un canal fuera de los grupos de una persona no existe para ellos; pedirlo por nombre responde *no encontrado*, por lo que su nombre no se confirma tampoco. Un canal sin grupo se ve solo por personas sin límite.

Guardar un canal lo mantiene dentro de los grupos de la persona: no pueden crear un canal en otro grupo, o mover uno fuera del suyo. Lo que cada instalación comparte - tablas de códigos, bibliotecas de scripts, decisiones de autorización previa - pueden leer pero no cambiar. Las cifras del servidor (autorización previa, uso de tokens, túneles) se muestran solo a personas sin límite, y también se muestran las métricas y alertas sobre todo el servidor en lugar de un canal.

Un administrador limitado a grupos es el administrador propio de una instalación. Administran las personas y los tokens de sus grupos, inician y detienen sus canales y borran sus colas. Un colega que agregan obtiene sus grupos a menos que nombre algunos de ellos, no pueden dar un grupo que no tengan, y nunca ven ni cambian a nadie sin límite. Todo lo demás que un administrador puede hacer cambia todo el servidor - configuración, inicio de sesión, reinicio, reglas de alertas, marca, flota, el servidor SMART - y se les niega.

Los grupos se establecen en Usuarios (y para tokens en Tokens), como una lista separada por comas. Cada cambio se registra en el registro de actividad y tiene efecto en la próxima solicitud de la persona.

Un rol diferente en cada grupo

Una persona puede tener un rol diferente en cada uno de sus grupos: lab=editor, adt en Usuarios edita los canales del laboratorio y tiene el rol elegido junto a él - digamos visor - en los de admisiones. Ve los canales de ambos grupos en cada pantalla. Guardar, iniciar o reenviar uno en un grupo donde su rol es demasiado bajo se niega con el rol que tiene allí; no pretende que el canal esté perdido, ya que puede verlo. Su rol en la parte superior de la pantalla es el más fuerte que tiene, lo que abre las pantallas que ese rol utiliza, y cada acción en esas pantallas sigue estando limitada a los grupos donde lo tiene.

Solo las personas limitadas a grupos de canales pueden tener uno. Alguien que ve todos los canales tiene un rol, porque "editor de los canales del laboratorio" para una persona sin límite sería editor de todo lo que pertenece a ningún grupo, y de las páginas del servidor. Un administrador de instalación puede dar un rol por grupo solo en los grupos que administra, y nunca por encima de su propio rol allí.

17.3 Quién puede llamar al punto final de FHIR

El punto final de FHIR (serve -fhir) verifica uno de dos tipos de token:

• Tokens de API de Perfuse, creados en Usuarios → Credenciales de máquina o con perfuse token create. Cada uno lleva un rol y puede estar

limitado a Grupos de FHIR. Este es el valor predeterminado cuando no se configura un servidor de autorización SMART.

• Tokens de acceso SMART, del propio servidor de autorización de Perfuse (-smart-clients) o de uno externo (-smart-issuer). Cada

uno lleva ámbitos y el punto de conexión mantiene cada solicitud a ellos.

Con SMART configurado, solo se aceptan tokens SMART, por lo que cada llamador se ajusta a sus ámbitos. Un token de API tiene un rol y no tiene ámbitos: un token de visor puede leer el registro de cada paciente. Un pagador que activó SMART para limitar cada aplicación a lo que se le otorgó no debe tener una forma de entrada que no esté limitada.

Algunos sitios necesitan ambos, lo mismo - una fuente de reclamaciones interna que mantenga un token de API y no tenga un cliente SMART, además de aplicaciones de miembros que se conectan a través de SMART. Para ellos, Configuración → FHIR → Aceptar tokens de API de Perfuse además de tokens SMART (-fhir-api-tokens al iniciar) permite que los tokens de API también se utilicen. Está desactivado por defecto, tiene efecto en la próxima solicitud en cualquier dirección y el cambio se escribe en el registro de auditoría. Un token se distingue por su forma: un token SMART es un JWT firmado y un token de API nunca lo es, por lo que uno nunca se verifica como el otro. Donde sea posible, proporcione a dicho sistema un cliente de servicios de backend SMART con solo los alcances del sistema que necesite.

17.3.1 Un punto final de FHIR abierto a desconocidos

Un servidor de prueba público proporciona credenciales que pueden escribir, porque probar la autorización previa o las suscripciones requiere escrituras. Dos límites evitan que un cliente lo estropee para todos, ambos bajo Settings → FHIR y ambos desactivados de forma predeterminada:

• Escribe un minuto desde un cliente (-fhir-writes-per-minute): crea, actualiza y elimina desde una dirección de cliente. Por encima de él, una escritura se responde con 429 y Retry-After: 60. Las lecturas y búsquedas, incluidas las búsquedas por POST, nunca se cuentan.
• La mayoría de los recursos mantenidos (-fhir-max-resources): más allá de él, los nuevos recursos se rechazan con 507, mientras que las actualizaciones y eliminaciones aún funcionan.

El punto final de un hospital propio no necesita ninguno de los dos.

17.4 Agentes de inteligencia artificial: el servidor MCP

Con Configuración › Seguridad › Agentes de inteligencia artificial (MCP) activado (o serve -mcp), Perfuse sirve el Protocolo de contexto de modelo en /mcp, para que un agente de inteligencia artificial como Claude, ChatGPT o un asistente de IDE pueda preguntarle qué está sucediendo. Está desactivado por defecto y desactivarlo detiene a cada agente en su próxima llamada.

Un agente se conecta con un token de API desde Administrar › Usuarios › Credenciales de máquina como un token de portador, nunca con una sesión de navegador de una persona (que se rechaza, por lo que un agente nunca actúa con el acceso completo de una persona). Una configuración de cliente se parece a:

{ "mcpServers": { "perfuse": { "type": "http", "url": "https://perfuse.example/mcp",
    "headers": { "Authorization": "Bearer <token>" } } } }

Cada herramienta es respondida por la misma ruta o búsqueda de FHIR que utiliza la pantalla de una persona, llamada con el token del agente, por lo que el rol del token, los grupos de canales y el inquilino deciden qué ve, exactamente como lo hacen en la consola; y fhir_search obtiene el acceso propio del token en el punto de conexión de FHIR (que puede rechazar tokens de API por completo; véase la sección de FHIR anterior). A un agente solo se le ofrece las herramientas que su token puede utilizar. La lectura es el valor predeterminado: una herramienta que cambia algo también necesita el alcance mcp:write del token ("Dejar que un agente de inteligencia artificial actúe con él" al emitir el token), por lo que un token emitido para un agente de informes no puede ser hablado para actuar por una solicitud. Las respuestas de un token de monitor tienen los contenidos de los mensajes eliminados, independientemente de lo que devuelva una ruta.

Cada llamada está en Actividad como mcp.tool con el nombre del token, la herramienta, sus argumentos y el resultado (ok, refused, invalid, rate-limited o el estado HTTP); mcp.connect registra qué cliente se conectó. Cada token puede realizar 60 llamadas de herramienta por minuto (Llamadas de herramienta por minuto desde un token); por encima de ese límite, una llamada se responde con un error que el agente puede leer y no se realiza nada. Una solicitud desde una página de navegador en otro origen se rechaza, lo que MCP solicita a un servidor para detener el reenlace de DNS. El transporte es Streamable HTTP de MCP, respondido como JSON sin flujo de eventos; se aceptan las versiones del protocolo 2025-06-18, 2025-03-26 y 2024-11-05. Los mensajes y los recursos de FHIR contienen datos de pacientes: las respuestas de un agente van a cualquier modelo en el que se ejecuta, así que proporcione un token a un agente solo donde ese modelo esté autorizado a verlos y proporcione el rol más bajo que realice el trabajo.

17.5 Una cuenta de demostración

serve -demo-account demo:PASSWORD crea una cuenta compartida para un servidor de demostración pública, y la página de inicio de sesión muestra su nombre de usuario y contraseña con un botón que inicia sesión con ellos. La cuenta es un espectador, por lo que puede ver todo y no cambiar nada. A diferencia de cualquier otro espectador, también puede abrir las pantallas de los administradores (usuarios, tokens de máquina, configuración, protección de datos, los pares de la flota), de solo lectura: una demostración se juzga por sus pantallas. Las lee como un espectador lee canales, con cada credencial mostrada como establecida o no, nunca su valor, y cada cambio rechazado. También puede presionar las comprobaciones que no cambian nada y no alcanzan nada fuera del servidor: una comprobación de script y la validación y análisis del editor de canales. No puede cambiar su contraseña ni agregar una passkey, porque el primer visitante que haga cualquiera de las dos cosas bloquearía a todos los demás. Cada inicio lo restaura como un espectador con la contraseña publicada. La contraseña debe tener al menos 12 caracteres, como cualquier otra. Solo úsela en un servidor que contenga datos de prueba: cualquier persona que lea la página de inicio de sesión puede leer cada mensaje en el servidor.

17.6 Auditoría

Los cambios de configuración, los inicios de sesión y el acceso al contenido de los mensajes se registran con quién, qué y cuándo.

El registro de auditoría está en la misma base de datos que los mensajes. Esto es conveniente y es una limitación: alguien que pueda modificar la base de datos puede modificar el registro de auditoría. Si sus requisitos incluyen una auditoría con evidencia de manipulación, el registro necesita enviarse a algún lugar de solo agregar, y la salida de registro de Perfuse es la forma de hacerlo.

17.7 Secretos en la configuración

Las contraseñas, los códigos y las claves aparecen en la configuración del canal, lo que significa que están en los archivos YAML.

Dos consecuencias. Los archivos necesitan permisos de sistema de archivos que reflejen su contenido, y si están en control de versiones — lo que de otro modo se recomienda — el repositorio contiene credenciales y debe ser tratado en consecuencia.

Donde un valor es un secreto, la interfaz lo representa como un secreto y la API no lo devuelve una vez guardado. Eso lo protege de ser leído sobre el hombro de alguien o filtrado en una captura de pantalla. No protege el archivo.

17.8 Lo que está en la base de datos

El almacén de mensajes mantiene los mensajes tal como se recibieron, lo que para una fuente clínica significa datos identificables de pacientes. Debe estar en almacenamiento cifrado, respaldado como datos clínicos con la retención que implica, y controlado de acceso a nivel de sistema de archivos, así como a través de los propios roles de Perfuse.

cleanup.periodDays limita cuánto tiempo se mantiene. Consulte el almacén de mensajes para la tensión entre eso y tener suficiente historial para alertas con conciencia de ritmo.

17.9 Protección de datos (GDPR y GDPR del Reino Unido)

La pantalla Protección de datos (Administrar, solo administradores) responde a las solicitudes de una persona bajo el GDPR y el GDPR del Reino Unido. No decide nada en nombre del controlador: si una solicitud debe ser concedida y si se aplica una exención es la decisión del controlador, registrada con la solicitud.

Encontrar lo que se posee. Una persona se nombra mediante identificadores: system|value (un número del NHS, un MRN con su autoridad asignadora) o un número por sí solo. Con un índice de pacientes, esos se amplían a cada número de cada registro vinculado a la misma persona, por lo que una solicitud que cita un número de hospital encuentra los registros archivados bajo los demás. Ver lo que se posee busca entonces en cada tienda que mantiene datos de pacientes:

Lo que no puede alcanzar lo dice: trazas enviadas a un recolector (-trace-endpoint), el registro de auditoría (conservado: es el registro de quién hizo qué, incluida esta solicitud), y copias de seguridad.

Solicitudes. Una solicitud se registra con su tipo (acceso, Artículo 15; portabilidad, Artículo 20; eliminación, Artículo 17; restricción, Artículo 18), quién es de acuerdo con los registros del controlador, los identificadores y una nota (cómo se confirmó la identidad, una extensión y su razón). Debe responderse dentro de un mes después de la recepción (Artículo 12(3)); una solicitud vencida se muestra en rojo.

• Acceso y portabilidad: Descargar la copia proporciona un zip: cada mensaje tal como se recibió con su registro, cada recurso FHIR con cada versión almacenada, solicitudes de autorización previa y sus respuestas, y los registros del índice de pacientes, en formato JSON en todo, con un archivo README que explica qué es cada parte. Marcar como respondido cierra la solicitud.
• Borrado: un segundo administrador aprueba el borrado (quien lo registró no puede hacerlo). Borrar ahora elimina todo lo encontrado: mensajes completos (registro, cuerpo, entregas, identificadores, adjuntos que no utiliza ningún otro mensaje), entregas en cola (no se envían), los recursos FHIR con su historial, solicitudes de autorización previa con sus respuestas, adjuntos y números de seguimiento, y la persona en el índice de pacientes con cada registro vinculado y su historial (un evento registra que se produjo un borrado y quién lo realizó).
• Restricción: se registra como una retención legal, por lo que nada se borra o caduca mientras dure.
• Rechazar cierra una solicitud con su motivo, que debe ser comunicado a la persona.

Una solicitud cerrada solo mantiene los últimos caracteres de los números de la persona: permanece como registro de una respuesta sin ser otra copia de ellos. Cada paso se registra en el registro de auditoría con los números enmascarados.

Retenciones legales. Una retención nombra a una persona por identificadores, con su motivo y una fecha de finalización opcional. Mientras esté en vigor, un borrado se rechaza directamente, y la ventana de retención del almacén de mensajes preserva los mensajes de la persona (registros y cuerpos) hasta que se levante la retención.

Copias de seguridad y registro de borrados. Una copia de seguridad realizada antes de un borrado aún contiene lo que se borró hasta que caduca. Cada borrado se escribe en un registro: cuándo, por quién, aprobado por quién, cuánto se eliminó de cada almacén y los identificadores de la persona como hashes SHA-256 salados en lugar de en claro. Después de restaurar una copia de seguridad, Aplicar borrados nuevamente hash los identificadores que los almacenes restaurados contienen con la sal de cada entrada y borra a cada persona que el registro nombra. Los números cortos se pueden encontrar desde sus hashes intentando cada valor, por lo que el registro es en sí mismo datos personales y se mantiene con la protección propia de la base de datos.

Retención. La pantalla enumera cuánto tiempo se mantiene cada tipo de registro aquí y qué lo cambia: registros y cuerpos de mensajes por sus ventanas de retención, la cola hasta que se entrega o se elimina, el almacén FHIR, solicitudes de autorización previa y el índice de pacientes hasta que se borran (los registros clínicos no se eliminan según un calendario), el registro de auditoría se mantiene.

Registro de procesamiento (Artículo 30). Registro de procesamiento descarga, como Markdown o CSV, lo que este servidor conoce de él: el controlador, el oficial de protección de datos y dónde se almacenan los datos (Configuración → Datos → Protección de datos), la retención de cada tipo de registro y una actividad de procesamiento por canal con lo que recibe, de dónde, a qué destinos y los hosts a los que envía. Los propósitos, bases legales y categorías de sujeto de datos se dejan para que el controlador los complete, y se indica que así es. Una celda de CSV que comienza con =, +, - o @ se escribe con una comilla simple al principio, para que una hoja de cálculo no la ejecute.

Dónde se almacenan los datos. Dónde se almacenan los datos (Configuración → Datos → Protección de datos) establece, en palabras que un regulador puede verificar, dónde se ejecutan el servidor, su base de datos y sus copias de seguridad; la pantalla de protección de datos y el registro lo muestran. Un borrador de acuerdo de procesamiento de datos para organizaciones que BioDream hospeda se encuentra en docs/legal/dpa-template.md; es un borrador para un abogado, no asesoramiento legal.

La API es /api/privacy (resumen), /api/privacy/find, /api/privacy/requests (y /{id}/approve, /{id}/export, /{id}/erase, /{id}/close), /api/privacy/holds, /api/privacy/reapply y /api/privacy/register.

17.10 Inquilinos

Un inquilino es un límite de aislamiento: los canales, mensajes, usuarios y configuraciones pertenecen a uno, y nada cruza.

Esto existe para un proveedor de servicios que ejecuta fuentes de alimentación para varias prácticas. No lo utilice para separar departamentos dentro de una organización que necesitan ver el tráfico entre sí: el aislamiento es real y no hay vista entre inquilinos. Para eso, utilice grupos de canales (anteriormente), que dividen a las personas de una organización mientras permiten que un equipo central vea todo.

17.10.1 Límites

Un operador de plataforma establece los límites de cada inquilino en Tenants, para que un cliente no pueda saturar el resto de un servidor compartido. Deje un límite vacío para que no haya ninguno.

• Canales: cuántos canales puede tener el inquilino. Crear uno más es rechazado, con el recuento y el límite.
• Mensajes por minuto: cuántos mensajes pueden recibir juntos sus canales en un minuto.
• Almacenamiento: cuánto contenido de mensaje almacenado puede mantener, en megabytes.

Ninguno de ellos pierde un mensaje. Por encima de la tasa o el límite de almacenamiento, un mensaje recibido se rechaza de la misma manera que un receptor ocupado rechaza uno, antes de que se almacene o entregue nada: MLLP no recibe acuse de recibo (no es un rechazo, que algunos remitentes toman como "no reenvíe"), HTTP recibe 429 con Retry-After, SOAP recibe 503, DICOM recibe un estado que se puede reintentar, y una cola, cubeta o archivo se deja donde estaba. El remitente vuelve a enviar, como hace cada motor de interfaz y EHR. Nada que ya esté almacenado se elimina para hacer espacio. Un límite aumentado entra en vigor dentro de un minuto, y cada cambio de límites se registra en el registro de actividad.

17.11 Datos de prueba

Los mensajes generados descritos en testing existen en parte como un control de privacidad. Reproducir un problema en otro lugar, enviar un ejemplo a un proveedor o poblar un entorno de prueba son todas cosas que de otra manera se realizan con mensajes reales.

La salida del generador no contiene datos de paciente por construcción en lugar de por redacción. Prefiéralo a los mensajes reales despojados a mano, que es un proceso que se puede realizar de manera incompleta y generalmente se hace.

17.12 Inicio de sesión único

Tres mecanismos, y cuentas locales junto con todos ellos.

OpenID Connect (-oidc), un directorio sobre LDAP (-ldap) y SAML 2.0 (-saml). Cada uno se configura desde Administrar → Inicio de sesión y se escribe en el archivo que el indicador nombra, para que la pantalla y el archivo sean dos vistas de una cosa en lugar de dos lugares para mantener en sincronía.

Las cuentas locales siempre están disponibles y no se pueden desactivar. Eso es deliberado: un motor de integración local cuya única forma de entrada es un proveedor de identidad se vuelve inaccesible exactamente cuando el proveedor de identidad es inaccesible, y una interfaz clínica no es un buen lugar para aprender eso. La pantalla de inicio de sesión le indica cuántos administradores locales existen antes de animarlo a depender de cualquier otra cosa.

17.12.1 Qué decide un mapeo de grupo

Los tres mapean grupos desde el directorio a roles de Perfuse, y alguien en grupos que coinciden con más de uno obtiene el más privilegiado. Esa es la única dirección segura para resolverlo — la alternativa es que una persona pierda el acceso al que tiene derecho porque también está en un grupo menor.

Cualquiera de los seis roles se puede otorgar: monitor, espectador, operador, editor, administrador y plataforma.

Un grupo también puede limitarse a algunos grupos de canales, en la segunda casilla de su fila (channel_groups en el archivo). Una vez que cualquier grupo nombra uno, cada inicio de sesión establece los grupos de canales de la persona desde los grupos que otorgaron su función: alguien en un grupo que edita los canales del laboratorio y en otro que ve cada canal es un editor de los canales del laboratorio y nada más. El rol más fuerte nunca se une al alcance más amplio, porque ningún grupo otorga eso. Un grupo con una casilla vacía otorga cada canal. Mientras ningún grupo nombra ninguno, el inicio de sesión deja los grupos de canales como los estableció un administrador en Usuarios.

Cuando cada grupo al que pertenece una persona coincide con los nombres de los grupos de canales, cada grupo de canales obtiene el rol más fuerte entre los grupos que lo nombran: con Lab-Interfaces (editor, laboratorio) y Clinical-IT (visor, laboratorio y admisiones), la persona edita los canales del laboratorio y ve los de admisiones, como si se hubiera configurado manualmente. Cuando uno de sus grupos otorga todos los canales, no hay lista para mantener un rol por grupo, y se aplica la regla anterior.

roles:
  editor: [Lab-Interfaces]
  operator: [Night-Desk]
  viewer: [Clinical-IT]
  channel_groups:
    Lab-Interfaces: [lab, pathology]
    Night-Desk: [adt]

Este es el archivo OpenID Connect y SAML. El archivo del directorio asigna cada grupo a un rol (roles: {Lab-Interfaces: editor}), y channel_groups se encuentra junto a roles allí.

Un mapeo que no otorga nada a nadie se rechaza en lugar de guardarse. Una configuración que autentica a las personas y las rechaza a todas parece idéntica a un producto roto desde afuera: el viaje de ida y vuelta se completa y todos son rechazados sin explicación.

Crear una cuenta en el primer inicio de sesión está desactivado de forma predeterminada. Con esto desactivado, alguien debe existir en Perfuse antes de que puedan iniciar sesión, por lo que el directorio decide quiénes son y Perfuse decide quién está permitido.

17.12.2 SAML, específicamente

Las partes que vale la pena conocer antes de configurarlo:

• Solo el certificado que configura es de confianza. Un certificado transportado dentro de una respuesta nunca se utiliza. Un atacante que pueda enviar un documento también puede poner su propio certificado en él, y un verificador que lo lee es uno al que cualquiera puede autenticar como cualquiera.
• Una respuesta debe responder a un inicio de sesión que inició este servidor. Perfuse recuerda la solicitud que envió y rechaza una respuesta que nombra cualquier otra cosa, o que nombra una solicitud que ya ha respondido. Sin esta comprobación, una respuesta válida es un token de portador para quien la posee: alguien inicia sesión como ellos mismos, mantiene la respuesta y la publica en su navegador, y entonces estás dentro de su cuenta con el registro de auditoría que registra su nombre.
• Los inicios de sesión iniciados en el proveedor de identidad están desactivados de forma predeterminada. Active *Aceptar inicios de sesión iniciados en el proveedor de identidad* solo si necesita un mosaico de portal, y sabiendo que es lo que hace posible lo anterior.
• El atributo de grupo no tiene un valor predeterminado y es obligatorio. Entra envía groups, Okta envía lo que se configuró para la aplicación, ADFS envía una URI de reclamación. Una suposición produciría un inicio de sesión que funciona y no otorga nada a nadie. Si un inicio de sesión se rechaza por no tener rol, el registro del servidor nombra los atributos que llegaron — que es generalmente toda la respuesta.
• La URL de respuesta debe coincidir exactamente con lo registrado en el proveedor. Una respuesta dice dónde estaba destinada y una dirigida a otro lugar se rechaza, porque aceptarla significaría aceptar una respuesta destinada a un servicio diferente.

17.12.3 Qué envía cada proveedor

El atributo de grupo es donde los inicios de sesión van mal, y los tres proveedores comunes lo nombran de manera diferente.

Una URI de reclamación puede ingresarse por su segmento final: escribir groups encuentra http://schemas.microsoft.com/ws/2008/06/identity/claims/groups. Un nombre que simplemente termina con la palabra no coincide — excluded_groups no es groups.

La membresía de grupo que llega como un solo valor separado por comas se trata como un solo nombre de grupo y no coincide con nada. Esa es la lectura correcta del estándar, y dividir por comas significaría que un grupo que legítimamente contiene uno se convirtió silenciosamente en dos. Si eso es lo que su proveedor envía, cambie allí.

Probar en la pantalla de inicio de sesión comprueba todo lo que se puede comprobar sin una persona: la configuración, el certificado y si se puede construir una solicitud de inicio de sesión. Dice claramente que no puede probar que alguien pueda iniciar sesión, porque eso necesita una aserción real sobre una persona real y la única forma de obtener una es que lo intenten.

17.13 Cuentas aprovisionadas por el proveedor de identidad: SCIM

Con -scim (Configuración → Inicio de sesión → Cuentas automáticas), un proveedor de identidad como Okta, Microsoft Entra ID o Google Workspace crea, actualiza y elimina cuentas de Perfuse por sí mismo en /scim/v2/Users, por lo que una persona que deja la organización pierde acceso cuando su cuenta de directorio se deshabilita, no cuando alguien lo recuerda. El proveedor se autentica con un token de API que tiene el rol de administrador, creado bajo Usuarios → Credenciales de máquina, enviado como un token de portador.

• Deshabilitar una cuenta termina sus sesiones de inmediato, y el servidor verifica que ninguna sobrevivió antes de responder. Un proveedor nunca se le informa que una cuenta fue deshabilitada cuando no lo fue, porque un proveedor no vuelve a intentar lo que se le dijo que tuvo éxito.
• Un eliminar deshabilita primero, luego elimina, por lo que un fallo a mitad de camino deja una cuenta con la que nadie puede iniciar sesión. Se mantiene el historial de auditoría de una cuenta eliminada.
• El rol proviene de los grupos o roles de la persona, coincidiendo por nombre: un grupo cuyo nombre contiene *admin*, *editor*, *operador*, *espectador* (o *solo lectura*) o *monitor* otorga ese rol, por lo que APP-Perfuse-Editor y Perfuse Operators funcionan como están nombrados. Cualquier otra cosa obtiene -scim-default-role, espectador a menos que se establezca de otra manera. La plataforma nunca se puede otorgar de esta manera.
• No hay contraseñas. Una cuenta creada por SCIM inicia sesión a través del proveedor de identidad; una segunda contraseña que nadie conoce en la parte superior sobreviviría a una deshabilitación allí.
• /scim/v2/ServiceProviderConfig dice qué está soportado: crear, leer, reemplazar, parchear y eliminar de Usuarios, y filtros de hasta 200 resultados. Las operaciones por lotes, la ordenación y las etiquetas ETags no están.

17.14 Qué no hace Perfuse

No cifra la base de datos en reposo. Utilice cifrado de sistema de archivos o volumen.

No administra sus propios certificados ni los renueva. Apúntelo a archivos y administre esos archivos con lo que ya utiliza.

SAML ha sido verificado contra dos proveedores independientes, cada uno con un inicio de sesión de navegador real, una aserción real y una sesión real: Keycloak 26 y Microsoft Entra. Dos asuntos son más de dos veces más que uno, porque los dos discrepan de una manera que resultó ser fundamental — Keycloak escribe su aserción con prefijos de namespace y Entra escribe los mismos elementos sin ellos, y el único defecto que tiene esta área ha sido en el manejo de prefijos.

Comience leyendo los metadatos de su proveedor. Configuración, luego Inicio de sesión, luego la pestaña SAML: proporcione la URL de metadatos o pegue el documento, y la dirección de inicio de sesión y el certificado de firma se rellenarán automáticamente. Cada proveedor de SAML publica uno de estos — Okta, Entra, AWS IAM Identity Center, Keycloak, ADFS — y es la diferencia entre configurar un proveedor y transcribir uno. Hacerlo manualmente significa encontrar el certificado dentro del XML, eliminar los saltos de línea del base64 y envolverlo en encabezados PEM, donde un solo espacio extra produce un error de firma que no dice nada sobre el formato.

Lo que se devuelve se describe en lugar de volcar: el sujeto de cada certificado, vencimiento y huella digital SHA-256, para que pueda verificarlo contra lo que muestra la consola del propio proveedor. Un certificado caducado se llama caducado en lugar de dejarlo como una fecha para comparar visualmente. Nada se guarda al leer — aplicarlo al formulario es un clic separado, porque un documento que alguien pegó no es aún una decisión sobre qué confiar.

Una URL de metadatos se recupera solo sobre https, y la dirección se verifica contra la misma política que rige los destinos del canal, por lo que esto no se puede utilizar para hacer que el servidor lea credenciales de instancia de nube. Las redirecciones no se siguen, porque una dirección permitida que redirige a una bloqueada pasaría directamente por esa verificación.

Si está configurando Entra, cinco cosas no coincidirán con lo que muestran los ejemplos. No envía ninguna reclamación de correo electrónico en absoluto. Su NameID es un identificador opaco en lugar de una dirección. No envía ninguna reclamación de grupos a menos que la aplicación esté configurada explícitamente para emitirla, por lo que un mapeo de roles escrito contra grupos rechaza cada inicio de sesión. Cuando se emiten grupos, son GUID de objeto en lugar de nombres, a menos que su inquilino se sincronice desde Active Directory local. Y sus nombres de reclamación viven bajo schemas.microsoft.com/identity donde la mayoría de la documentación muestra schemas.xmlsoap.org. Perfuse maneja los cinco; se enumeran porque los cuatro primeros de lo contrario parecerían errores en Perfuse cuando son Entra siendo Entra.

Esa distinción no es teórica aquí. La primera aserción real de Keycloak falló directamente, porque la forma canónica que cubre la firma se estaba computando con prefijos de namespace eliminados. Ningún proveedor de identidad real podría haber iniciado sesión a alguien, y las cinco pruebas de canonización del paquete pasaron en todo momento — cada una de ellas firmada y verificada con el mismo código, por lo que solo demostraron que estaba de acuerdo consigo mismo. Si es el primero en apuntar un proveedor diferente a esto, espere encontrar algo, y el registro del servidor nombrará la etapa que falló.

18 Operaciones

18.1 Implementación

Un binario y dos rutas: un directorio de archivos de canal y un archivo de base de datos. No se requiere un servidor de aplicaciones, una capa web separada ni un agente de mensajes.

perfuse serve -channels ./channels -db ./perfuse.db -addr 0.0.0.0:8443 \
  -tls-cert ./cert.pem -tls-key ./key.pem

Ejécutelo bajo lo que supervisa los servicios en el host — systemd, launchd, un tiempo de ejecución de contenedor. Espera ser reiniciado si sale.

18.2 Dónde puede ir los datos (residencia de datos)

serve -residency (Configuración → Datos → Dónde pueden ir los datos) nombra las regiones de nube a las que los datos de este servidor pueden ser enviados o leídos: áreas (eea, uk, ch) y códigos de región (eu-central-1, uksouth, europe-west2), separados por comas. eea es las regiones de AWS, Azure y Google Cloud en el Área Económica Europea (Frankfurt, Irlanda, París, Estocolmo, Milán, España; Países Bajos, Alemania, Francia, Suecia, Noruega, Italia, Polonia, España; Bélgica, Países Bajos, Alemania, Italia, Francia, Finlandia, España, Polonia), uk las de Reino Unido, ch las de Suiza.

Con esto configurado, un canal se rechaza cuando se guarda y cuando se carga, si un conector nombra una región fuera de la lista: una fuente o destino S3, SQS o SNS region (o su endpoint, cuando es un hostname de AWS), o cualquier destino cuya dirección es un hostname de AWS que lleva una región (sqs.us-east-1.amazonaws.com, una URL de API Gateway). El servidor se niega a iniciarse con un colector de trazas o un webhook de alerta en otra región. Un conector apuntando a un host que no nombra región (el propio sistema de un hospital, MinIO en la red del sitio) no se juzga: el registro de procesamiento en la pantalla de protección de datos enumera todos los hosts a los que cada canal envía, para que el controlador lo verifique. El panel y la pantalla de protección de datos indican dónde puede ir los datos.

Alojamiento en la UE y el Reino Unido. deploy/hosted contiene OpenTofu (o Terraform) para un servidor alojado por organización en Frankfurt, Irlanda o Londres: el servidor, su base de datos PostgreSQL y copias de seguridad, un bucket de copias de seguridad, registros y registros de sesiones de soporte, todo cifrado con una clave en la región, nada replicado a otra región, soporte a través del administrador de sesiones solo, y Perfuse ejecutado con -residency. Su archivo README dice qué construye, qué no cubre, qué se ha verificado (validado y planeado contra una cuenta real; no aplicado todavía) y qué cuesta a precio de lista en cada región.

18.3 Configuración como archivos

Los canales son archivos, lo que significa que pueden estar en control de versiones, revisados antes de la implementación y diferenciados después de un incidente.

Los archivos se vuelven a leer sin reiniciar. Un archivo que no se analiza se informa y la versión previamente cargada sigue funcionando, así que un error de sintaxis no puede sacar un flujo de trabajo del aire.

18.4 Copia de seguridad

Dos cosas que respaldar, y tienen características diferentes.

El directorio del canal es pequeño, cambia raramente y es lo que necesita para reconstruir el servicio. Respalde como configuración; el control de versiones suele ser suficiente.

La base de datos contiene mensajes, usuarios e historial de auditoría. Es grande, cambia constantemente y contiene datos clínicos, por lo que necesita respaldarse como datos clínicos, con la retención y el cifrado que implica. Perderla no detiene el servicio, pero pierde la capacidad de investigar cualquier cosa que ya haya sucedido y la historia en la que se basa el aprendizaje de ritmo.

18.5 Comportamiento de reinicio

Al reiniciar, se cargan los canales y las fuentes comienzan a escuchar. Las entregas en cola se reanudan.

La cosa que hay que entender es qué sucede con el trabajo en vuelo. Bajo el reconocimiento de entrega predeterminado on_delivery, un mensaje que no había sido reconocido aún no es reconocido, por lo que el remitente lo reenviará, lo cual es el resultado correcto. Bajo on_receipt, un mensaje que fue reconocido pero no entregado aún está en la cola y se reanuda; si la cola está deshabilitada, se pierde. Vea flujo de mensaje.

18.6 Actualización

Reemplace el binario y reinicie. El esquema de la base de datos se migra automáticamente hacia adelante al iniciar.

Las migraciones solo son hacia adelante. No hay degradación, por lo que una reversión a un binario anterior después de que el esquema haya cambiado requiere la base de datos anterior. Tome una copia antes de actualizar, esta es la única precaución operativa que vale la pena ser disciplinada.

18.7 Supervisión

La alerta desde dentro de Perfuse se cubre en alerta y es lo que le dirá que una fuente ha dejado de funcionar.

Desde fuera, supervise el proceso, el disco donde se encuentra la base de datos y si la interfaz web responde. La base de datos crece y un disco lleno detiene la grabación de mensajes, lo que es un modo de fallo sin otra advertencia.

18.7.1 SNMP

Para herramientas de monitoreo que hablan SNMP (Nagios, Zabbix, PRTG, SolarWinds, LibreNMS), Perfuse ejecuta un agente SNMPv2c de solo lectura y envía una trampa cuando se dispara o resuelve una alerta. Configúrelo en Settings → Monitoring → SNMP, o con indicadores:

perfuse serve -snmp-listen :161 -snmp-community 'long-random-community' -snmp-allow 10.0.5.0/24 \
  -snmp-traps nms.example.org,10.0.5.9:1162

• El agente responde a GET, GETNEXT y GETBULK, y solo desde las redes en -snmp-allow: la comunidad v2c es una contraseña enviada en texto claro, por lo que nunca está abierta a todos. Una comunidad de menos de 6 caracteres, o public/private, detiene el servidor al inicio.
• Sirve el grupo del sistema (sysDescr, sysUpTime, sysName desde la etiqueta de la flota, sysContact, sysLocation), totales bajo BASE.1 (canales, en ejecución, rotos, recibidos, entregados, fallidos, en cola) y una tabla de canales bajo BASE.2.1 (nombre, en ejecución o detenido, recibidos, entregados, fallidos, en cola, edad del mensaje en cola más antiguo). Los números son los que muestra el panel y /metrics.
• Las trampas van a cada administrador en -snmp-traps: BASE.0.1 una alerta se disparó, BASE.0.2 se resolvió, llevando el tipo de alerta, gravedad, canal, destino y resumen. Nunca contenido de mensaje. Una alerta confirmada no envía trampa.
• BASE es 1.3.6.1.4.1.8072.9999.9999.16 (espacio experimental de Net-SNMP) a menos que -snmp-base-oid lo coloque bajo su propio número de empresa. Descargar el MIB en la página de configuración (o GET /api/snmp/mib) da un MIB para la base en uso; el mismo panel dice si el agente está respondiendo y cuántas trampas se fueron.

18.7.2 Un inventario de cada interfaz

-inventory interfaces.md (Configuración → Monitoreo → Inventario) escribe un documento Markdown que enumera cada canal - su formato, si se ejecuta, qué recibe de y a qué envía - seguido de la descripción de cada canal, y lo reescribe cada -inventory-every (un día por defecto). Está destinado a ser confirmado junto con los archivos de canal, o entregado a un auditor, y leído sin que la aplicación esté en ejecución.

18.8 Capacidad

El límite de rendimiento de Perfuse no se ha medido en hardware real bajo tráfico real, y este manual no imprimirá un número que no pueda respaldar.

Lo que se puede decir: la arquitectura es una goroutine por conexión con colas por destino, por lo que el rendimiento se escala con los destinos en lugar de serializarse a través de un trabajador; la grabación de mensajes es una escritura SQLite por mensaje, lo que hace que el disco sea la restricción más probable; y el almacén de mensajes crece linealmente con el tráfico, por lo que la retención es la configuración que gobierna el uso de disco a largo plazo.

Si está dimensionando esto para una gran fuente de datos, mézclelo con su propio tráfico utilizando el corpus de prueba generado descrito en testing. Esa es la respuesta honesta, y también es una mejor respuesta que un número de alguien más en su hardware.

18.9 Donde esta instalación se bloqueó

La actividad lleva un panel, visible para los administradores, que muestra qué Perfuse se ha negado a hacer — agrupado por mensaje, el más frecuente primero — y cuánto ha avanzado la instalación hacia un canal de trabajo.

Existe porque todas las demás afirmaciones sobre si este software es fácil de usar provienen de las personas que lo escribieron. Una negativa no: alguien quería algo, el servidor dijo que no, y ninguna de las partes estaba adivinando. Es la única evidencia en el producto que no proviene de BioDream LLC.

El embudo nombra el paso que aún no ha sucedido en lugar de dejar que se comparen los timestamps. El estado que vale la pena vigilar es los mensajes llegan y ninguno ha sido entregado a un destino — un canal puede tomar tráfico durante semanas y no entregar ninguno, y desde cualquier otra pantalla parece que está funcionando.

Nada de lo que alguien escribió se registra. La tabla mantiene la ruta de la solicitud con identificadores reemplazados por {id}, el estado y la oración del propio servidor. Un mensaje de validación nombra un campo y una regla, que es la parte útil; el valor que rompió la regla es muy a menudo datos de paciente, y una tabla de esos sería una responsabilidad peor que la fricción que midió.

Dos exclusiones deliberadas. Un 5xx es un error en este software y ya se registra como tal — mezclar los dos enterraría los casos en los que alguien no podía averiguar qué escribir bajo los casos en los que nada de lo que escribieron habría ayudado. Y una sesión expirada produce una serie de 401 que no dicen nada sobre la usabilidad y ahogarían todos los hallazgos que sí.

Leer el informe también recorta la tabla a sus cinco mil filas más recientes. Las negativas son respuestas 4xx, por lo que crece lentamente, y la lectura es un momento natural para ordenar: no hay temporizador y nada que se ejecute cuando nadie esté mirando.

GET /api/friction devuelve lo mismo para cualquiera que prefiera leerlo como JSON.

18.10 Registros

Perfuse registra en la salida estándar, que es donde un supervisor o un tiempo de ejecución de contenedor lo recopilará.

El detalle a nivel de mensaje va al almacén de mensajes en lugar del registro, deliberadamente. Una línea de registro por mensaje en una fuente de datos ocupada es ruido que oculta las líneas que importan, y el almacén es searchable de maneras que un archivo de registro no lo es.

El registro lleva lo que el almacén no puede: inicio y cierre, resultados de carga de configuración, cambios de estado de canal y errores que no se pueden atribuir a un mensaje específico.

18.11 Ejecutar dos instancias

Dos o más servidores pueden ejecutarse como un clúster: cuando el que ejecuta un flujo se detiene, otro lo toma dentro de unos pocos segundos, y el siguiente intento del remitente lo alcanza. Comparten una base de datos PostgreSQL en lugar de que cada uno mantenga un archivo SQLite , y acuerdan entre ellos, a través de ella, quién ejecuta qué.

perfuse serve -db 'postgres://perfuse:SECRET@db.hospital.internal/perfuse?sslmode=verify-full' \
  -cluster active-passive -node-name perfuse-01 -node-address https://perfuse-01.hospital.internal:8443 \
  -data /var/lib/perfuse

Inicie cada servidor de la misma manera con su propio nombre y dirección. La cuenta de la base de datos necesita crear tablas y, una vez, la extensión citext (o un administrador ejecuta CREATE EXTENSION citext primero). Cada servidor mantiene sus propios archivos en -data: su registro, su id de nodo y sus copias de la configuración.

Dos formas de compartir el trabajo.

• active-passive: el líder ejecuta cada canal y cada trabajo que debe ejecutarse una vez (notificaciones de suscripción de FHIR). Los

demás esperan. El más simple de razonar, y lo que un sitio con un servidor ocupado y uno de respaldo quiere.

• active-active: los canales se distribuyen entre los servidores en vivo, más o menos uniformemente. Un servidor que se detiene pasa sus canales

al resto; uno que se une toma su parte a medida que los canales están libres, uno a la vez. Los canales que se enrutan entre sí (un destino de canal) se ejecutan en un servidor y se mueven juntos, porque el enrutamiento ocurre dentro de un servidor. Un administrador puede mover un canal a mano desde Monitorear → Flota; permanece donde se colocó mientras ese servidor viva.

Quién ejecuta qué, y ningún momento con dos. Cada pieza de trabajo es un contrato de arrendamiento en la base de datos, renovado cada quinta parte de -cluster-lease (15 s por defecto). Un servidor que no puede renovarlo (se estrelló, su red falló, la base de datos es inaccesible) detiene ese trabajo por sí solo una vez que su propio reloj dice que el contrato de arrendamiento está a punto de terminar, con un tercio del contrato de arrendamiento de margen. Otro servidor toma el contrato de arrendamiento solo después de que su propio reloj haya visto que el contador del contrato de arrendamiento se ha mantenido quieto durante todo el contrato de arrendamiento. No se compara ningún reloj con otro, por lo que los relojes de los servidores y la base de datos no necesitan estar de acuerdo; solo necesitan funcionar a una velocidad similar, lo que hace cada reloj. Entre el antiguo titular que se detiene y el nuevo que comienza, hay una breve brecha con nadie escuchando, que un remitente ve como una conexión rechazada y vuelve a intentarlo; nunca hay un momento con dos escuchando en un flujo o dos trabajadores drenando una cola.

Un servidor que se apaga limpiamente, o un administrador que elige Retroceder en el líder, entrega de inmediato en lugar de después del contrato de arrendamiento.

Qué comparte cada servidor. Los mensajes, la cola de entrega, las cuentas y las sesiones, el registro de auditoría, el almacenamiento de FHIR, las tablas de terminología y el índice de pacientes están en la base de datos, por lo que cualquier servidor que ejecute un canal encuentra la cola que el último dejó. Los archivos de canal, el archivo de configuración, las reglas de alerta, los archivos de inicio de sesión único, el logotipo, los certificados Direct y las vistas guardadas se mantienen iguales en cada servidor a través de la base de datos: cada uno mantiene su propia copia en su propio disco, un cambio en cualquier servidor (en la consola, a mano, por un git pull) alcanza a los demás dentro de dos segundos, y un canal cambiado en otro servidor se reinicia con su nuevo archivo. El mismo archivo cambiado en dos servidores al mismo tiempo mantiene la versión que alcanzó la base de datos primero, y el otro al lado como NAME.conflict-SERVER. La configuración que solo se aplica en un reinicio (la base de datos de mensajes, los puertos que la consola escucha) se aplica en cada servidor en su próximo reinicio, y el registro lo dice. Lo que nombra algo en una máquina permanece en la línea de comandos del servidor y fuera del archivo compartido: el certificado y la clave (-tls-cert, -tls-key), la dirección de escucha de SNMP y el nombre del servidor en las trazas. La configuración los muestra como establecidos en cada servidor.

Iniciar y detener. Iniciar o detener un canal en cualquier servidor se aplica al clúster: el servidor que lo ejecuta lo inicia o detiene dentro de un segundo, y la respuesta dice qué servidor es ese.

El equilibrador de carga delante. La dirección de un flujo debe llegar al servidor que lo ejecuta. Apunte al remitente a una dirección virtual (un equilibrador de carga, una IP flotante, un nombre de DNS con un TTL corto) y haga que el equilibrador de carga verifique /readyz?channel=NAME, que responde 200 solo en el servidor que ejecuta ese canal, y 503 en los demás. Para la consola, /readyz es 200 en cada servidor vivo; /readyz?role=leader solo en el líder.

En un AWS Network Load Balancer, utilice un grupo de destino por alimentación con una comprobación de estado HTTPS en /readyz?channel=NAME, un intervalo de 5 segundos y un umbral de 2, y active la distribución de carga entre zonas. Con ella desactivada, el nodo del equilibrador de carga en una zona donde no se ejecuta ningún servidor de la alimentación solo ve objetivos no saludables, los envía de todos modos y un remitente que se resolvió a ese nodo espera hasta que la alimentación regrese a su zona (95 segundos en una prueba). Establezca el retraso de desregistración en 0, ya que un servidor que deja de ejecutar una alimentación no tiene nada que drenar.

Lo que se probó. Dos servidores en PostgreSQL 16, un remitente que transmite 300 mensajes, reenviando hasta que se respondan, y el servidor que ejecuta la alimentación se mata con SIGKILL dos veces (la primera, y luego la segunda después de que la primera regresara). Cada mensaje reconocido llegó al receptor, en ambas formas intentadas: entregado antes del reconocimiento y encolado en el almacén compartido mientras el receptor lo rechazaba (185 mensajes reconocidos esperaban en la cola en el momento del cese; el superviviente los entregó todos). El tiempo de conmutación por error tomó de 3 a 4 segundos en un contrato de arrendamiento de 3 segundos. Es posible un duplicado y se vio una vez en 600: un mensaje que el servidor moribundo entregó y no pudo reconocer, que el remitente reenvió. Las propias pruebas del coordinador cubren un bloqueo, un servidor desconectado de la base de datos mientras se ejecuta, degradación, propagación, movimientos y configuración compartida con conflictos. Se ejecutan en CI contra PostgreSQL con el detector de carreras, con la suite completa.

Lo mismo se hizo luego en AWS: dos servidores Linux (ARM) y un Windows Server 2022 en tres zonas de disponibilidad, Amazon RDS PostgreSQL 16 sobre TLS con el certificado verificado (sslmode=verify-full), un equilibrador de carga de red interno al frente y remitentes que reenvían hasta que se respondan:

|---|---|---|---|---| | Activo-pasivo, el servidor que ejecuta el flujo de datos asesinado dos veces (Linux, luego Windows), receptor que se niega en medio | 2,000 | 0 | 0 | 15 s | | Un líder Linux cortado de la base de datos (cortafuegos), su proceso dejado en ejecución | 3,000 | 0 | 1 | 16 s | | Un líder Windows cortado de la base de datos | 3,000 | 0 | 0 | 20 s | | El líder asesinado mientras el reloj de un servidor se ejecutaba 2 minutos rápido y otro 90 segundos lento | 2,000 | 0 | 0 | 18 s | | Activo-activo, cuatro flujos de datos sobre tres servidores, uno asesinado y vuelto a iniciar | 6,000 | 0 | 2 | 24 s |

Con el contrato de arrendamiento predeterminado de 15 segundos, un servidor desconectado de la base de datos detuvo su alimentación 10 segundos después de su última renovación, y el siguiente servidor la inició 6 a 8 segundos después de eso: nunca ambos al mismo tiempo. Los relojes sesgados no cambiaron nada, ya que no se compara ningún reloj con otro.

Todavía no. Un clúster sirve a una organización: -cluster con -multi-tenant se rechaza. Los oyentes se mueven con su canal, así que el equilibrador de carga es del sitio para proporcionarlo.

Un servidor solo sigue funcionando como siempre, en SQLite, sin clúster en absoluto.

18.12 Más de un servidor

Un sitio con dos instancias tiene una pregunta que ninguna consola individual puede responder: ¿está todo en ejecución? Mirth cobra por la respuesta. Esta es la vista de la flota.

Una instancia se nombra como el lugar donde se busca. Se sondrea a los demás y muestra cada canal en cada servidor en una tabla, con un resumen a través de todos ellos.

18.12.1 Agregar un par

Configuración → Flota, o PUT /api/fleet/peers. Un par necesita un nombre, una URL y un token emitido por el par mismo.

El nombre es obligatorio y no es la URL, porque una URL no es algo que alguien reconozca a las tres de la mañana.

El token debe crearse en el par, bajo Usuarios, y debe tener un alcance de visualizador. Agregar un par sin uno se rechaza, con esas instrucciones, en lugar de ser aceptado y luego fallar silenciosamente en cada sondeo. Leer el estado de salud de otra instancia es el privilegio más pequeño que existe, y es el único que necesita la vista de flota.

18.12.2 Controlar un par, que está apagado

allow_control permite iniciar y detener los canales de ese par desde aquí. Está desactivado por default y cada uso es auditado por nombre.

Los dos privilegios están separados deliberadamente. Leer el estado de salud de otro servidor es menor; detener sus canales durante una transfusión no lo es, y el segundo nunca debe llegar silenciosamente adjunto al primero.

18.12.3 Lo que dice el informe

Cada servidor informa el número total de canales, cuántos están en ejecución, detenidos o con errores, la profundidad de la cola y la edad del mensaje en espera más antiguo, cuántas alertas están activadas, y si se está drenando para apagar.

Las cuentas de rollup cuentan los servidores de tres maneras: accesibles, inaccesibles y indeterminados. La tercera cubre a los pares cuya salud nadie conoce: no se ha sondeado aún, se niega al token o está ejecutando una versión que esta no puede leer. Se mantiene separada de los inaccesibles porque "no podemos decir" no es lo mismo que "está caído", y combinar los dos es cómo una página de flota comienza a mentir.

Por la misma razón, el resumen lleva knownFrom: cuántas instancias se leyeron realmente los números del canal y la cola. Doce canales en ejecución en una flota significan algo diferente cuando dos de cinco servidores no respondieron, y el total solo no puede decirlo.

Un par inaccesible dice por qué en términos que un operador puede actuar. Una conexión rechazada se informa como un host que está arriba con nada escuchando en ese puerto, lo que es un problema diferente a un host que no responde en absoluto.

18.12.4 Desfase de reloj

El resumen informa la mayor diferencia entre los relojes de los servidores en él. Vale la pena un número propio: correlacionar un incidente a través de dos instancias cuyos relojes no están de acuerdo por cuatro minutos produce una secuencia de eventos que no sucedió.

18.12.5 Lo que un par aprende sobre usted

Recuentos y tasas. El informe que una instancia da a otra no lleva identificadores de mensajes, no detalles a nivel de canal y no datos de pacientes de ningún tipo.

Eso es lo que evita que una vista de flota sea una centralización de datos clínicos: la instancia que agrega aprende cuántos canales están en ejecución y nada en absoluto sobre lo que fluyó a través de ellos. Si desea los mensajes, abre la consola propia del servidor, donde el registro de auditoría registra que lo hizo.

18.12.6 Un par apuntando a sí mismo

Rechazado. Una instancia que sondea su propia dirección a través de su propia pila HTTP aparece dos veces en su propia vista de flota y cuenta dos veces cada canal que tiene.

18.12.7 TLS en redes internas

insecure_skip_verify acepta el certificado de un par sin verificarlo. Existe porque la infraestructura hospitalaria se ejecuta en autoridades de certificación privadas, y rechazar trabajar en absoluto empujaría a las personas hacia HTTP plano, que es peor. Está nombrado para que no pueda confundirse con una buena idea.

19 La línea de comandos

Todo lo que Perfuse hace a un sistema en ejecución es accesible desde la interfaz web, y eso es deliberado: una característica que necesita una terminal se trata como un defecto en lugar de una elección de diseño. Los comandos aquí son para el trabajo que sucede *alrededor* de un sistema en ejecución — antes de que exista, mientras decide si confiar en él, y cuando necesita entregar algo a alguien más.

Varios de ellos nunca tocan un servidor en absoluto. perfuse explain, perfuse profile, perfuse deident y perfuse translate leen archivos y escriben archivos, por lo que son útiles en una laptop contra un patrimonio que todavía funciona enteramente con algo más.

Ejecute cualquier comando con -h para sus indicadores. Este capítulo dice para qué es cada uno.

19.1 Canalizando canales

19.1.1 perfuse serve

Ejecuta la interfaz web y la API, y por defecto ejecuta los canales también. Este es el comando que utiliza una instalación.

Toda opción que acepta se enumera en Opciones del servidor, generado desde el programa. Se niega a servir HTTP plano a cualquier cosa excepto loopback a menos que se pase -insecure. Eso no es una configuración de cortesía: el tráfico clínico y una cookie de sesión sobre una conexión de LAN sin cifrar es un evento informable, y la bandera existe para que decir sí sea una decisión que alguien tomó en lugar de un valor predeterminado que heredó. Consulte seguridad.

19.1.2 perfuse run

Ejecuta canales desde YAML sin interfaz web y sin base de datos. Útil en un contenedor que debe hacer exactamente una cosa, y útil cuando desea ver el comportamiento de un canal sin que nada más esté ejecutándose.

19.1.3 perfuse check

Valida las definiciones de canales e imprime lo que hacen, sin ejecutarlos. La segunda mitad es el punto: un canal que se carga no es necesariamente el canal que se pretendía, y leer un resumen en inglés plano de lo que un archivo hará detecta un error que la validación no puede ver.

Sale con un código de error distinto de cero en caso de error, por lo que pertenece a cualquier comprobación de su configuración antes de que llegue a un servidor. -quiet no imprime nada en caso de éxito, para ese uso.

-allow-metadata-egress permite destinos apuntando a direcciones de metadatos de instancias en la nube. Esas direcciones contienen las credenciales de la propia máquina, por lo que un canal que pueda ser convencido para enviar allí es una fuga de credenciales; la comprobación las rechaza a menos que usted diga lo contrario.

19.1.4 perfuse test

Ejecuta pruebas escritas contra definiciones de canales. Una prueba envía un mensaje a través del filtro real, las transformaciones reales y los scripts reales del canal, en el orden real, con solo la red reemplazada — así que lo que pasa aquí es lo que el canal hace.

Las pruebas viven en *_test.yaml o *.test.yaml junto a los canales. Consulte pruebas.

19.2 Migración desde otro motor

Estos tres son los que se deben ejecutar primero, antes de decidir nada. Consulte migración.

19.2.1 perfuse explain

Lee exportaciones de Mirth, Open Integration Engine y BridgeLink — un canal, un grupo de canales o una copia de seguridad completa del servidor — y describe qué hace cada canal y qué bloquearía una migración. No cambia nada y no necesita una instalación de Perfuse, lo que lo convierte en el primer paso más barato posible: apúntelo a una exportación de su propiedad y lea lo que regresa.

-strict sale con un código de error distinto de cero si algo está bloqueado, por lo que puede controlar una tubería. -json emite los mismos hallazgos para una máquina.

19.2.2 perfuse translate

Convierte exportaciones de Mirth, Open Integration Engine y BridgeLink en archivos de canales de Perfuse: un canal, un grupo de canales, una exportación de biblioteca de plantillas de código o una copia de seguridad completa del servidor.

perfuse translate -o ./channels server-backup.xml

Las bibliotecas de plantillas de código se escriben en lib/ junto a los canales, y cada canal de Mirth incluye una biblioteca habilitada para ella. Consulte migración.

Nada se descarta silenciosamente. Cada parte de un canal es traducida, transportada como un script que se ejecuta sin cambios o informada como necesitada de un humano. La tercera categoría es la honesta — un traductor que produjera un archivo limpio para cada entrada estaría ocultando las decisiones que más necesita tomar.

19.2.3 perfuse compare

Ejecuta el mismo tráfico a través de dos motores y informa dónde no están de acuerdo, agrupados por campo.

Este es el comando que responde a "¿por qué debería confiar en esto con datos de pacientes?", y responde con evidencia que ha recopilado en lugar de una afirmación hecha aquí. Es el último paso recomendado antes de cambiar y el primer paso recomendado en cualquier argumento sobre si Perfuse está listo.

19.3 Comprender una fuente de datos

19.3.1 perfil de perfuse

Lee los mensajes e informa qué hay en ellos en realidad: qué campos siempre están poblados, cuáles nunca lo están, los conjuntos de valores reales de los campos codificados, los recuentos de repetición y qué segmentos Z aparecen.

Los valores solo se informan para los campos cuyos valores forman un conjunto de código pequeño, por lo que un perfil de tráfico real no se convierte en un archivo lleno de datos de pacientes.

Guardar un perfil y compararlo más tarde es cómo se descubre que un remitente cambió algo:

perfuse perfil -guardar last-month.json corpus/ perfuse perfil -contra last-month.json new/

19.3.2 contrato de perfuse

Convierte la salida de esa reflexión en algo ejecutable. Un contrato dice cómo debe lucir una fuente de datos, para que el día que cambie se le informe, en lugar de enterarse semanas después de un receptor que se detuvo — los mensajes siguen siendo válidos HL7 cuando un campo desaparece, por lo que nada más lo nota.

perfuse contrato promocionar -o adt.contrato.yaml corpus/ perfuse contrato verificar adt.contrato.yaml today/

promote genera un punto de partida, no una respuesta. Léalo y elimine la mayoría de él: cada línea registra si se midió o decidió, lo que le dice qué líneas mantener.

19.4 Producción de mensajes

19.4.1 perfuse generar

Produce mensajes sintéticos HL7 v2. Todo es inventado — nombres obviamente ficticios, identificadores secuenciales, direcciones inventadas — por lo que la salida es segura para comprometer, enviar por correo y adjuntar a un ticket.

Puede enviar directamente a un canal en lugar de escribir un archivo, lo que es la forma más rápida de probar que un oyente funciona:

perfuse generar -n 100 -enviar 127.0.0.1:6661

19.4.2 perfuse desidentificar

Lee los mensajes reales y escribe un corpus que mantiene su estructura, sus códigos y sus intervalos, y nada de lo que identifica a un paciente. Esta es la diferencia entre poder enviar a alguien una reproducción y no.

No es la misma herramienta que perfuse generate y la distinción importa. Los mensajes generados se inventan y, por lo tanto, son seguros pero poco realistas; un corpus desidentificado se *deriva del tráfico real*, por lo que reproduce las rarezas que realmente rompen las interfaces.

Dos propiedades que vale la pena comprender antes de usarlo:

• La misma sal siempre produce el mismo corpus, por lo que un corpus compartido se puede regenerar en lugar de archivarse.
• Mantenga la sal en secreto. Los seudónimos se derivan de valores reales, por lo que cualquier persona que tenga la sal puede confirmar una suposición sobre a quién se refiere un registro.

19.5 Mover mensajes a mano

19.5.1 perfuse escuchar

Acepta HL7 v2 sobre MLLP y lo confirma. Un receptor que existe durante el tiempo que lo necesite, para probar que un remitente puede llegar a esta máquina en absoluto.

19.5.2 enviar perfuse

Envía mensajes HL7 v2 sobre MLLP desde archivos.

19.6 FHIR

19.6.1 perfuse fhir

Convierte HL7 v2 a FHIR, valida FHIR o lo sirve, dependiendo del subcomando.

El subcomando de validación es útil por sí solo: le dirá si un recurso que alguien le envió satisface US Core, que es el perfil contra el que se escribe la regulación estadounidense. Ser capaz de responder a eso sin adoptar un motor es el punto.

19.6.2 perfuse x12

Converts X12 (or other delimited EDI) to the XML Mirth Connect and Open Integration Engine write for it, and back: perfuse x12 xml FILE and perfuse x12 from-xml FILE, standard input when no file is given. The output is what OIE 4.6 writes, byte for byte, so it can be compared with what a Mirth server produced or fed to a system built against it. A channel does the same with x12.arrives_as: xml and a destination's x12_as: xml; see X12.

19.6.3 perfuse sof

Ejecuta un SQL en FHIR ViewDefinition sobre archivos FHIR (el NDJSON de una exportación masiva, Bundles o matrices JSON; - para stdin) y escribe la tabla: -view FILE (requerido), -format csv|ndjson|json|parquet (csv por defecto), -header=false, y -o FILE (requerido para Parquet). Vea SQL on FHIR views.

19.6.4 perfuse measure

Evalúa una medida de calidad con criterios FHIRPath sobre archivos FHIR (el NDJSON de una exportación masiva, Bundles o matrices JSON; - para stdin) y escribe el MeasureReport. Indicadores:

• -measure FILE, o -measure example:ID para un ejemplo enviado: obligatorio. -examples enumera los ejemplos.
• -period-start y -period-end: obligatorio.
• -type summary|subject|subject-list.
• -subject Patient/ID.
• -reporter NAME.
• -o FILE.

Consulte medidas de calidad digitales.

19.6.5 Indicadores FHIR en perfuse serve

La tienda mantiene documentos así como recursos: un documento, una colección o un paquete de mensaje Bundle enviado a /fhir/Bundle/{id} se mantiene entero, se lee con cada entrada en la versión servida y se encuentra por type, identifier, timestamp y composition. Una transacción enviada allí se mantiene como un registro y no se aplica; un POST a /fhir aplica uno.

Las respuestas son JSON a menos que el cliente solicite XML (Accept: application/fhir+xml, o _format=xml). Perfuse lee solo JSON: un cuerpo enviado como XML obtiene 415. Un paquete de documentos POSTeado a /fhir se mantiene cuando este servidor mantiene, por identificador, el paciente y el encuentro que su Composición nombra, y se rechaza con 422 de lo contrario. Una lectura binaria con Accept establecida en su propio tipo de contenido responde con el contenido en sí.

19.7 Configuración y operación

19.7.1 perfuse init

Crea el diseño de directorios, un canal de ejemplo y una definición de servicio para el sistema operativo en el que se ejecuta. Nada existente se reemplaza a menos que se pase -force.

perfuse init -dir /opt/perfuse -service systemd

19.7.2 perfuse service

Registra Perfuse como un servicio de Windows, lo elimina o informa si está instalado y en ejecución. Solo para Windows; en Linux, el equivalente es el archivo de unidad que perfuse init puede escribir para usted. Consulte operaciones.

19.7.3 perfuse token

Emite credenciales para máquinas en lugar de personas. Un token no caduca y no se ve afectado por que alguien cierre la sesión, lo que es lo que un servidor que sondea a su vecino necesita y lo que una sesión del navegador deliberadamente no es.

perfuse token create -db perfuse.db -label fleet-from-site-a -role viewer perfuse token list -db perfuse.db perfuse token revoke -db perfuse.db -label fleet-from-site-a

Solo se almacena el hash, por lo que un token se muestra una vez cuando se crea y no se puede recuperar después. Un token robado de la base de datos, por lo tanto, no produce un token utilizable. Asigne a un token el rol más bajo que haga el trabajo: una flota de vistas necesita viewer y nada que solo lea debe contener nada más.

-fhir-groups riverside-attributed,riverside-north limita un token a esos grupos FHIR, para una exportación de acceso de proveedor CMS-0057: en el punto de conexión FHIR puede leer esos grupos y exportarlos, y nada más. Consulte CMS-0057 para pagadores.

19.7.4 Perfuse athena

Imprime la tabla CREATE EXTERNAL TABLE de Amazon Athena para un archivo S3 escrito con format: ndjson, utilizando la proyección de partición en la parte dt=YYYY-MM-DD de la clave, para que no tenga que ejecutarse ningún rastreador a medida que se agregan días.

Perfuse athena -bucket hospital-archive -destination archive

Se imprime en lugar de ejecutarse, porque crear una tabla requiere permisos de Athena y Glue que este programa no debe tener.

19.7.5 Perfuse sbom

Enumera todo lo que se vincula al binario, leído desde la propia compilación en lugar de desde go.mod — por lo que describe el binario que se encuentra frente a usted y no lo que alguien solicitó una vez.

-json emite CycloneDX y -spdx emite etiqueta-valor SPDX, que es lo que normalmente solicita una revisión de adquisiciones o seguridad. El código del navegador incrustado en el binario se incluye, porque un revisor que coincide con un binario contra avisos necesita saber que contiene una aplicación React.

19.7.6 Perfuse versión

Imprime la versión y el commit desde el que se construyó. Vale la pena incluir en un ticket: "la versión actual" no es una versión, y dos máquinas que se instalaron con una semana de diferencia a menudo no ejecutan la misma compilación.

20 Opciones del servidor

Toda opción que perfuse serve acepta, generada a partir del propio programa, por lo que esta lista no puede nombrar una opción que no exista o dejar una fuera. La mayoría también son una configuración en la interfaz web, nombrada en la última columna: un valor guardado allí gana sobre la marca en el siguiente inicio, y la marca sigue siendo la forma de establecerlo desde una definición de servicio. La dirección de escucha, la base de datos y el directorio del canal permanecen como marcas solo, porque dicen dónde encuentra el servidor lo que estaría editando.

Los secretos nunca son marcas. Una opción que necesita una contraseña o un token nombra una variable de entorno que la contiene.

20.1 Todas las opciones

21 Referencia de canal

Cada clave que puede aparecer en el nivel superior de un archivo de canal. Estas se extraen de la fuente, por lo que este capítulo no puede describir una opción que no exista o omitir una que sí exista.

21.1 Canal

Un canal es un flujo de mensajes configurado: somewhere los mensajes llegan, un filtro opcional y uno o más lugares a donde van.

Definido como Channel en internal/config.

21.1.1 nombre

El nombre identifica el canal en los registros y métricas.

Requerido y único.

21.1.2 grupo

El grupo es a lo que pertenece este canal, para organizar una lista que ha crecido demasiado para leer.

Cosmético a cinco canales y estructural a doscientos: los canales de un sitio se dividen por el sistema con el que hablan, o por el equipo que los posee, y una lista plana de doscientos nombres es inutilizable sin importar lo bueno que sea el resto de la interfaz.

Una cadena simple en lugar de un objeto de grupo con su propio archivo, porque un grupo no tiene comportamiento. En el momento en que tiene un archivo, adquiere configuraciones, y las configuraciones en un grupo significan que el comportamiento de un canal depende de algo que no está escrito en el canal - lo que es la propiedad que hace que la configuración de Mirth sea difícil de razonar.

21.1.3 adjuntos

Adjuntos mueve las grandes cargas útiles fuera del mensaje y las vuelve a poner antes de la entrega.

Opt-in por canal: una fuente de mensajes ADT simples no tiene nada que extraer y no debe pagar por la maquinaria.

21.1.4 delimitado

Delimitado configura un canal delimitado.

Solo significativo cuando el tipo de datos es delimitado.

21.1.5 tablas

Tablas nombres archivos de tablas de mapeo compartidas que una transformación puede referenciar por nombre.

Compartidas porque el dominio de impuestos es en gran parte re-derivar un mapeo que alguien ya derivó: los códigos de sexo y las clases de pacientes de un sitio se traducen de manera idéntica en cada canal que los toca, y una tabla dentro de un canal es una tabla que solo ese canal puede usar.

21.1.6 habilitado

Habilitado predeterminado es true.

Un canal deshabilitado se carga y se valida pero no se inicia, por lo que un archivo que está temporalmente fuera es aún verificado por CI.

21.1.7 tipo de dato

El tipo de dato es el formato de los mensajes que este canal recibe.

Por defecto es hl7, por lo que todos los canales escritos antes de que esto existiera siguen funcionando.

21.1.8 x12

X12 contiene la configuración que solo tiene sentido en un canal X12.

Establecerlo en cualquier otro tipo se rechaza en lugar de ignorarse.

21.1.9 script

Script configura un canal NCPDP SCRIPT.

Sus pasos viven aquí en lugar de en las transformaciones de nivel superior para la misma razón por la que los formatos no v2 lo hacen: los tipos de pasos difieren por formato, por lo que una clave significaría cosas diferentes dependiendo del tipo de dato.

21.1.10 dicom

Imágenes configura los pasos de transformación con nombre de un canal DICOM.

Se llama Imágenes en lugar de DICOM porque Origen y Destino ya tienen un campo DICOM y tres campos con el mismo nombre en diferentes niveles es cómo alguien establece el incorrecto. La clave yaml es dicom, que es lo que una persona que escribe el archivo espera, y el nombre de Go es el que evita un error en el sitio de llamada.

21.1.11 filtro

Filtro es una expresión que debe cumplirse para que un mensaje se reenvíe.

Un mensaje que no coincide sigue siendo reconocido: el remitente no hizo nada mal, simplemente no estamos interesados.

21.1.12 transformaciones

Las transformaciones son cambios declarativos aplicados a los mensajes aceptados, en orden, antes de que se ejecute cualquier script.

Esta es la capa destinada a realizar el trabajo ordinario: cada paso se valida cuando se carga el archivo, aparece en una diferencia y puede ser revisado por alguien que no lee JavaScript.

21.1.13 scripts

Scripts contiene JavaScript para los casos en que los pasos declarativos no pueden expresarse, y es donde se colocan sin cambios los scripts propios de un canal Mirth.

Un canal con un script se marca como tal en la interfaz, porque su comportamiento no se puede establecer leyendo la configuración.

21.1.14 sombra

Sombra ejecuta una versión candidata de este canal al lado y informa sobre las diferencias.

Nada de lo que hace puede llegar a un receptor.

22 Referencia de origen

Cada forma en que un canal puede recibir mensajes y cada clave que cada uno acepta. Un canal tiene exactamente una fuente.

22.1 Fuente AMQP

AMQPSource recibe de una cola o suscripción.

Un mensaje se acepta solo después de que el canal lo ha procesado. Uno que no se pudo procesar se libera como una entrega fallida, por lo que el broker lo vuelve a entregar y, en Service Bus, más allá del recuento máximo de entregas de la cola, lo envía a la carpeta de elementos muertos.

Definido como AMQPSource en internal/config.

22.1.1 prefetch

Prefetch es la cantidad de mensajes que el broker puede enviar por adelantado.

Por defecto es 10. Aún se procesan uno a la vez, en orden.

22.1.2 reconnect

Reconnect es la espera después de una conexión perdida.

Defaults to 5s.

22.2 Fuente AS2

AS2Source recibe AS2 (RFC 4130): EDI publicado sobre HTTP, firmado y cifrado con S/MIME, respondido con un recibo (un MDN) que lleva un resumen de lo que llegó.

La carga útil es lo que el canal procesa; X12 y EDIFACT son los habituales.

Definido como AS2Source en internal/config.

22.2.1 path

Path es la ruta de URL a la que los socios publican.

Default /as2.

22.2.2 tls

TLS sirve HTTPS.

La mayoría de los socios lo requieren en su acuerdo, además de S/MIME.

22.2.3 id

ID es nuestro identificador AS2, que los socios envían en AS2-To.

Un mensaje a cualquier otro se rechaza.

22.2.4 partners

Los socios son quienes pueden enviar mensajes aquí.

Un mensaje de cualquier otra persona es rechazado.

22.2.5 ventana_duplicado

DuplicateWindow es el tiempo durante el que se recuerda el Message-ID de un socio, para que un mensaje enviado nuevamente (el socio nunca recibió nuestro recibo y lo volvió a intentar) sea respondido con un recibo y no se pase dos veces (RFC 4130 sección 7.5).

Default 30 days.

22.3 Origen de blobs de Azure

AzureBlobSource recoge blobs de un prefijo de contenedor.

Definido como AzureBlobSource en internal/config.

22.3.1 mover_a

MoveTo es donde se mueve un blob tratado.

Predeterminado es procesado/.

22.3.2 prefijo_de_error

ErrorPrefix es donde se mueve un blob que no se puede tratar, para que no bloquee el resto.

Predeterminado es error/.

22.3.3 intervalo_de_sondeo

PollInterval entre listados.

Defaults to 30s.

22.3.4 tamaño_máximo_de_objeto

MaxObjectSize rechaza un blob más grande, que se queda donde está.

Predeterminado es 16 MiB.

22.4 Origen de corredor

BrokerSource lee mensajes de un corredor de mensajes.

Lector JMS de Mirth, alcanzado a través de STOMP porque JMS es una API de Java en lugar de un protocolo. Consulte internal/stomp para saber por qué STOMP y no OpenWire.

Definido como BrokerSource en internal/config.

22.4.1 addr

Addr es el host y el puerto del broker.

Requerido. 61613 es el puerto STOMP habitual.

22.4.2 destino

Destino es la cola o tema de la que se lee.

Required.

Los brokers escriben estos de manera diferente - /queue/name en ActiveMQ, un nombre sin adornos en RabbitMQ - por lo que se pasa sin cambios en lugar de ensamblarse aquí. Adivinar significaría trabajar en contra de un broker y silenciosamente leer nada en otro.

22.4.3 inicio de sesión

Inicio de sesión y código de autorización autenticados.

La mayoría de los brokers rechazan una conexión anónima.

22.4.4 código de autorización

Inicio de sesión y código de autorización autenticados.

La mayoría de los brokers rechazan una conexión anónima.

22.4.5 host

Host es el host virtual.

Predeterminado en el host de la dirección.

22.4.6 selector

Selector filtra mensajes en el broker.

Un selector JMS, pasado sin interpretar. Filtrar en el broker en lugar de aquí significa que los mensajes que este canal no quiere nunca cruzan la red - lo que en una cola compartida es la diferencia entre leer cien mensajes al día y cien mil.

22.4.7 id_de_suscripción

ID de suscripción nombra la suscripción.

Predeterminado en el nombre del canal.

Nombrado en lugar de generado, porque una suscripción duradera se identifica por él: uno generado crearía una nueva suscripción en cada reinicio y dejaría las antiguas acumulando mensajes que nadie lee.

22.4.8 latido

Latido mantiene la conexión viva.

Predeterminado en treinta segundos.

Activado por defecto aquí, a diferencia del valor predeterminado del propio cliente, porque una fuente mantiene una conexión abierta durante semanas. Sin latidos, una conexión a través de un firewall que ha eliminado silenciosamente la ruta parece perfectamente saludable desde este extremo y los mensajes simplemente dejan de llegar, sin nada registrado.

22.4.9 reconnect

Reconexión es el tiempo que se espera antes de volver a conectarse después de un fallo.

Predeterminado en cinco segundos.

22.4.10 tiempo de espera

Límites de tiempo de espera al conectar.

Predeterminado en treinta segundos.

22.5 Fuente de consulta DICOM

DICOMQuerySource sondea un archivo con C-FIND y emite un mensaje por cada nuevo estudio.

Mirth no tiene un conector equivalente. Su soporte DICOM es un listener y un remitente: puede recibir imágenes que se le envían y reenviarlas, y eso es todo. Pedir a un archivo qué contiene ha sido solicitado en sus foros desde 2015.

Lo que lo hace valioso no es la consulta, sino la automatización: una prefetch que se ejecuta a las tres de la mañana, una reconciliación que nota que el archivo falta un estudio que el RIS dice que existe, una lista de trabajo construida a partir de lo que se escaneó realmente en lugar de lo que se ordenó. Esos son trabajos que los sitios actualmente realizan con un script programado fuera del motor, lo que significa que son invisibles para él: no hay reintentos, no hay alertas, no hay historial de mensajes.

Definido como DICOMQuerySource en internal/config.

22.5.1 dirección

La dirección es el host y el puerto del archivo.

Required.

Nombrado para coincidir con el destino DICOM en lugar de abreviado. Los dos fueron "dirección" y "addr" durante una tarde, lo que es el tipo de inconsistencia que alguien que escribe un archivo de canal a mano se equivoca una vez y luego desconfía de todo el formato.

22.5.2 called_ae

CalledAE es el título AE del archivo.

Requerido en la práctica: la mayoría de los archivos rechazan una asociación dirigida a cualquier otra cosa, y ese rechazo se lee como una interrupción en lugar de como un error de configuración.

22.5.3 calling_ae

CallingAE es el título AE que presenta Perfuse.

Los archivos comúnmente lo utilizan para el control de acceso.

22.5.4 nivel

Nivel es el nivel de consulta: PACIENTE, ESTUDIO, SERIE o IMAGEN.

Predeterminado en ESTUDIO.

ESTUDIO es el predeterminado porque es lo que casi todas las consultas útiles desean y porque las alternativas sorprenden a las personas: el nivel IMAGEN contra una CT grande devuelve una respuesta por rebanada, lo que es cientos por estudio.

22.5.5 coincidencia

Coincidencia son las claves de consulta.

Un valor filtra; un valor vacío pide que se devuelva el campo.

Las claves están nombradas en lugar de numeradas - "PatientID" en lugar de "0010,0020" - porque un archivo de canal se lee por personas, y un número de etiqueta en un archivo de configuración es una búsqueda que cada lector debe realizar.

22.5.6 devolver

Los campos de devolver son los campos que se deben regresar sin filtrarlos.

Separado de la coincidencia con un valor vacío, aunque codifiquen de manera idéntica, porque la intención es diferente y un lector puede ver qué claves están restringiendo la búsqueda y cuáles se están recopilando.

22.5.7 intervalo

El intervalo es con qué frecuencia se realiza la consulta.

Required.

22.5.8 ventana

La ventana es cuánto tiempo atrás busca cada consulta, como un rango de fechas de estudio.

Cero deshabilita completamente el filtrado por fechas.

Una ventana es lo que mantiene esto limitado. Sin una, cada consulta le pide al archivo todo lo que ha tenido alguna vez y luego descarta lo que ha visto antes, lo que funciona en un archivo de prueba y es antisocial contra uno real que contiene millones de estudios.

22.5.9 superposición

La superposición vuelve a consultar este período ya consultado.

El valor predeterminado es de una hora.

Necesario en lugar de cauteloso. Un estudio puede estar registrado con la fecha de ayer, nuestro reloj y el del archivo no necesitan coincidir, y un límite de consulta que coincide exactamente con una llegada lo pierde. La superposición vuelve a preguntar, y la comprobación de lo ya visto evita el duplicado, así que el costo de la superposición es una consulta ligeramente más grande y el costo de no superponer es un estudio perdido en silencio.

22.5.10 límite

El límite limita las coincidencias aceptadas de una sola consulta.

Defaults to 500.

Un límite en lugar de no tener límite porque una clave de coincidencia mal escrita convierte esto en "dame todo", y el primer síntoma de eso contra un archivo real es que el administrador del archivo pregunta quién lo está bombardeando.

22.5.11 tiempo de espera

El tiempo de espera limita una sola consulta.

El valor predeterminado es de dos minutos.

22.5.12 emitir_en_la_primera_consulta

EmitOnFirstPoll envía mensajes para todo lo que encuentra la primera consulta.

El valor predeterminado es falso.

Falso es importante. Apuntar esto a un archivo que ya contiene un millón de estudios y hacer que emita un mensaje para cada uno no es una primera ejecución útil, y es el tipo de error que se nota en el flujo descendente en lugar de aquí. La primera consulta registra lo que existe y no emite nada; la segunda consulta en adelante informa lo que es nuevo.

22.6 Fuente DICOM

DICOMSource recibe objetos de imagen como proveedor de la clase de servicio C-STORE.

Lo que un hospital apunta a una modalidad o un PACS. Mirth llama a esto el oyente DICOM y solo hace C-STORE, así que esto es paridad en lugar de un subconjunto.

Definido como DICOMSource en internal/config.

22.6.1 listen

Listen es la dirección en la que se sirve.

Requerido. 104 es el puerto DICOM registrado; 11112 es el alternativo común donde no es posible vincular un puerto con privilegios.

22.6.2 ae_title

AETitle es el nombre que se le da a este punto de conexión.

Fuertemente recomendado en lugar de requerido, y advertido cuando está ausente. El control de acceso de un sitio en un punto de conexión DICOM es frecuentemente el título AE, por lo que un punto de conexión que acepta cualquier título acepta cualquier cosa que pueda llegar a él.

22.6.3 allowed_calling_ae

AllowedCallingAE enumera los títulos AE permitidos para conectarse.

Vacío acepta cualquier llamador.

Este es el control de acceso que realmente tiene DICOM. Un PACS se configura rutinariamente para aceptar un título de llamada nombrado y rechazar todo lo demás, y este extremo no tenía equivalente: se verificaba el título llamado - que es el nombre que el llamador marca, así que cualquier persona puede enviarlo correctamente - mientras que quién estaba llamando se registraba en el registro y se ignoraba de otra manera.

Vacío todavía acepta cualquier cosa, porque una modalidad que nadie ha enumerado es el estado normal de una instalación inicial y rechazar por defecto rompería cada implementación en el día uno. En su lugar, advierte, y la advertencia nombra los títulos que se han conectado para que alguien pueda rellenar esto desde lo que realmente llegó.

22.6.4 sop_classes

SOPClasses restringe los tipos de objetos que se aceptan.

Vacío acepta cualquier cosa.

Vacío es un valor predeterminado razonable aquí porque este motor relaya objetos en lugar de interpretarlos, por lo que rechazar una clase desconocida rechazaría imágenes válidas sin beneficio.

22.6.5 transfer_syntaxes

TransferSyntaxes restringe los codificados que se aceptan, en orden de preferencia.

Vacío acepta los tres sin comprimir.

22.6.6 max_object_bytes

MaxObjectBytes limita un objeto recibido.

Cero aplica un valor predeterminado.

22.6.7 idle_timeout

IdleTimeout cierra una asociación que ha guardado silencio.

Cero significa nunca, que generalmente es correcto: una modalidad mantiene una asociación abierta entre estudios.

22.6.8 tls

TLS cifra las asociaciones entrantes y puede requerir un certificado de cliente.

Vale la pena decirlo claramente: Mirth necesita su extensión de administrador de SSL de pago para esto, y las bifurcaciones de la comunidad no pueden enviarlo en absoluto. DICOM lleva nombres de pacientes en sus metadatos, por lo que este es uno de los lugares donde ser una reescritura en lugar de una bifurcación es una ventaja real en lugar de una estilística.

22.7 Fuente Mweb DICO

DICOMwebSource acepta solicitudes STOW-RS.

Definido como DICOMwebSource en internal/config.

22.7.1 listen

Listen es la dirección en la que se sirve.

Required.

22.7.2 path

La ruta es la raíz del servicio.

Los objetos se aceptan en Path/estudios y Path/estudios/{uid}. De forma predeterminada es /dicom-web, que es lo que utilizan Orthanc y dcm4chee, por lo que un remitente configurado para cualquiera de ellos solo necesita cambiar el host.

22.7.3 token

El token, cuando se establece, es requerido como un token de portador.

El nombre de usuario y la contraseña requieren autenticación básica de HTTP.

22.7.4 nombre de usuario

El token, cuando se establece, es requerido como un token de portador.

El nombre de usuario y la contraseña requieren autenticación básica de HTTP.

22.7.5 contraseña

El token, cuando se establece, es requerido como un token de portador.

El nombre de usuario y la contraseña requieren autenticación básica de HTTP.

22.8 Fuente de base de datos

DatabaseSource lee filas de una base de datos y convierte cada una en un mensaje.

Esta es la forma en que comienzan muchas interfaces de hospital. Un sistema de departamento no tiene capacidad HL7, por lo que alguien escribe filas en una tabla de espera y el motor de interfaz la sondea. No es glamoroso y está en todas partes.

También es la forma más común en que un canal de Mirth se bloquea, y la razón es casi siempre la misma: una fila que no se puede procesar se lee, falla y se vuelve a leer, para siempre, porque nada la marcó. El canal parece estar vivo. La cola parece vacía. Nada se mueve, y cada mensaje detrás de la fila mala espera a una fila que nunca tendrá éxito.

La mayor parte del diseño aquí se trata de eso.

Definido como DatabaseSource en internal/config.

22.8.1 controlador

El controlador nombra la base de datos.

See SupportedDrivers.

22.8.2 dsn

DSN es la cadena de conexión.

Prefiera una referencia de variable de entorno sobre un literal, porque esto normalmente contiene una contraseña y los canales están diseñados para vivir en git.

22.8.3 consulta

La consulta selecciona las filas que están esperando ser enviadas.

Required.

Debe ser un SELECT. Una consulta que realice escrituras silenciosas se ejecutaría en un calendario sin registro de qué cambió.

22.8.4 después_de_la_consulta

AfterQuery marca una fila como procesada y se ejecuta con la clave de la fila vinculada a ella.

Strongly recommended.

Sin ella, cada consulta de actualización vuelve a leer cada fila que la consulta aún coincide, por lo que la consulta en sí debe excluir las filas procesadas de alguna otra manera. Si ninguna de las anteriores es cierta, el canal vuelve a enviar las mismas filas indefinidamente, lo que es una tormenta de duplicados en lugar de un bloqueo y es peor.

22.8.5 columna_clave

KeyColumn identifica una fila para AfterQuery, cuarentena y eliminación de duplicados.

Requerido cuando AfterQuery está establecido.

22.8.6 plantilla

La plantilla construye un mensaje a partir de una fila.

Se requiere uno de estos o Column.

Las referencias de columna utilizan ${nombre_de_columna}. Las columnas que faltan son un error al cargar en lugar de una cadena vacía en un mensaje clínico.

22.8.7 tamaño_de_lote

BatchSize limita las filas tomadas por consulta de actualización.

Defaults to 100.

Esto está limitado porque una primera consulta de actualización no limitada contra una tabla que alguien ha estado llenando durante un año leería todo en memoria y luego lo enviaría todo, lo que es cómo una migración inunda un receptor en vivo.

22.8.8 intentos_máximos

MaxAttempts es la cantidad de veces que una sola fila puede fallar antes de ser puesta en cuarentena y la consulta de actualización continúa.

Defaults to 3.

Este es el ajuste que evita el bloqueo. Volver a intentarlo indefinidamente no es resistencia; es una mala fila que detiene una alimentación de hospital.

22.8.9 tiempo_de_espera_de_la_consulta

QueryTimeout limita una sola consulta de actualización.

Defaults to 30s.

22.9 Fuente directa

DirectSource recibe correo Direct que el HISP entrega: un listener SMTP para el correo de esta dirección.

Cada mensaje se descifra, se verifica su firma contra los anclajes y su firmante contra From, y se pasa su contenido: los documentos de un paquete XDM, de lo contrario cada archivo adjunto, de lo contrario el texto.

Definido como DirectSource en internal/config.