Validación determinística para agentes FHIR®

TL;DR. Pedirle a un LLM que valide un recurso FHIR contra CL Core es como pedirle a un compilador que sea probabilístico: el modelo no puede ser la fuente de verdad. Fhiron MCP separa ese contrato. El LLM compone y el motor valida contra la versión resuelta en runtime. La API devuelve ValidateResponse con hallazgos estructurados en español; no convierte por sí sola una validación en evidencia de cumplimiento legal.

1. El problema: alucinación FHIR no se ve a primera vista

Un LLM moderno produce JSON FHIR sintácticamente impecable. Pídele una MedicationRequest para paracetamol 500 mg cada 8 horas, válida para un EHR chileno, y te entrega algo así:

{
  "resourceType": "MedicationRequest",
  "status": "active",
  "medicationCodeableConcept": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "322236009",
        "display": "Paracetamol 500 mg comprimido"
      }
    ]
  },
  "subject": { "reference": "Patient/123" },
  "encounter": { "reference": "Encounter/abc" },
  "dosageInstruction": [
    {
      "text": "1 comprimido cada 8 horas",
      "timing": { "repeat": { "frequency": 1, "period": 8, "periodUnit": "hr" } },
      "doseAndRate": [
        {
          "doseQuantity": {
            "value": 500,
            "unit": "mg",
            "system": "http://unitsofmeasure.org",
            "code": "mg"
          }
        }
      ]
    }
  ]
}

A primera vista parece correcto. En realidad falla en cinco lugares distintos:

Falta intent: cardinalidad 1..1 en FHIR R4. Sin él, el consumidor no puede distinguir una receta firmada (order) de una propuesta del modelo (proposal) o un protocolo precargado (plan). El LLM lo omitió porque el ejemplo de su training data lo daba por contexto.
Falta category: los HIS chilenos usan category para diferenciar receta ambulatoria, intrahospitalaria, controlada. Sin él, el dispensador no sabe el flujo.
El code SNOMED es plausible, pero no es la terminología con la que el ecosistema chileno intercambia fármacos. La convención operativa usa el ATC de la WHO (http://www.whocc.no/atc); la TFC del ISP aún no tiene canónico oficial publicado. CL Core no define un perfil de MedicationRequest, así que aquí no hay un binding del IG que rechace el recurso, pero el mismo patrón de error sí rompe bindings reales en otros recursos: Encounter.class exige el CodeSystem canónico v3-ActCode (AMB · IMP · EMER · HH) y un system propio no pasa la validación.
encounter.reference apunta a un Encounter que no está en el Bundle ni contained. El validador la marca como referencia no resoluble.
El doseQuantity está correcto sintácticamente, pero falta route (oral, IV, IM, etc.). En Chile la receta dispensable requiere ruta declarada.

Ninguno de estos errores es atrapado por una validación sintáctica de JSON. Tampoco por un schema FHIR R4 base, varios son constraints de cardinalidad/binding que solo aparecen cuando el recurso pasa por el motor con CL Core 1.9.4 cargado, más los catálogos terminológicos oficiales (ATC, CIE-10). Esto es lo que llamamos alucinación FHIR: producción que parece correcta, pasa el ojo humano, pasa el linter sintáctico, y se cae en producción cuando el EHR destino la rechaza con un mensaje opaco en inglés.

2. Por qué validación probabilística no aplica aquí

Un LLM es, por construcción, un sistema de muestreo sobre una distribución de probabilidad. Tres cosas lo descalifican como validador de un estándar clínico: No es reproducible. Aun con temperature: 0, dos despliegues con cuantización distinta, dos versiones del modelo, o dos providers detrás de la misma API pueden dar respuestas levemente distintas. Para validación esto es un dealbreaker: el veredicto no puede depender de la prosa generada por el modelo. Confunde lookalikes. Los LLMs son extraordinariamente buenos generando texto que se parece al que ya vieron. Para datos clínicos esto es exactamente lo que no quieres: el modelo produce mg/dl como unidad cuando UCUM, que es case-sensitive, exige mg/dL, o invierte los slices de un identificador porque la mayoría de ejemplos de internet están en otro formato. El error está en la apariencia, no en la estructura. No tiene fuente de verdad. El estándar CL Core v1.9.4 es un paquete NPM con artefactos versionados. Existe una versión exacta de CorePacienteCl. El LLM no carga ese paquete; carga una mezcla difusa de las miles de versiones que vio durante entrenamiento. Pedirle que sea autoridad sobre un perfil específico es pedirle que recuerde algo que nunca tuvo. La conclusión no es que los LLMs sean malos. Es que validar un estándar es un trabajo determinístico, y la herramienta para trabajos determinísticos es código determinístico.

3. Arquitectura: separar composición de verificación

Fhiron MCP implementa una frontera explícita de tool-use:

┌──────────────┐         ┌──────────────────┐         ┌─────────────────┐
│              │  tool   │                  │  HTTP   │                 │
│     LLM      ├────────>│   MCP Connector  ├────────>│   Motor Fhiron  │
│  (compone)   │  call   │   (intermedia)   │         │  (HAPI 8.8.0 +  │
│              │<────────│                  │<────────│   CL Core 1.9.4)│
└──────────────┘ result  └──────────────────┘         └─────────────────┘

El LLM nunca evalúa si un recurso cumple un perfil. Cuando necesita esa respuesta, llama a fhiron_validate con el JSON que produjo. El connector reenvía el recurso al motor y entrega su ValidateResponse como tool_result. El modelo entonces tiene tres caminos:

El motor dijo OK: continuar la conversación.
El motor reportó issues: leer issues[], identificar el path que falló, corregir el recurso y llamar de nuevo.
El motor no pudo procesar el input (JSON malformado, recurso truncado): reformular.

Esta separación tiene una propiedad clave: el modelo nunca tiene la última palabra sobre validación. Puede componer mil veces, pero el veredicto lo entrega el motor con artefactos publicados; la respuesta informa la versión CL Core efectivamente resuelta.

4. Las herramientas que cruzan la frontera

@fhiron/mcp-connector expone diez tools al LLM, agrupadas por intención (Validar / Explorar / Reparar). Las tools remotas no persisten el recurso, pero sí consumen cuota y generan metadatos; los hints MCP no deben interpretarse como ausencia de esos efectos operacionales.

Tool	Qué hace	Determinístico
`fhiron_validate`	Valida un recurso contra la versión CL Core resuelta y devuelve `ValidateResponse`	Sí, motor HAPI
`fhiron_validate_file`	Igual que `fhiron_validate`, leyendo el recurso desde un `.json` local	Sí, motor HAPI
`fhiron_validate_bundle`	Valida un Bundle entry-by-entry y devuelve matriz pass/fail	Sí, motor HAPI
`fhiron_lint`	Linter offline para reglas estructurales `cl-*`	Sí, reglas estáticas
`fhiron_score_endpoint`	Escanea un endpoint FHIR público y devuelve FHIR Score 0–100	Sí, métricas calculadas
`fhiron_compare_profiles`	Diff entre validar contra FHIR R4 base vs CL Core	Sí, motor HAPI x2
`fhiron_get_example`	Devuelve un ejemplo válido del perfil pedido (precargado)	Sí, payload constante
`fhiron_search_terminology`	Busca en CodeSystems chilenos cargados localmente	Sí, lookup
`fhiron_explain_code`	Explica un código de error de validación en español	Sí, diccionario
`fhiron_apply_fix`	Aplica un quickFix mecánico al recurso (RFC 6901)	Sí, transformación pura

Las tools locales son transformaciones determinísticas. Las tools remotas usan un motor versionado, pero también dependen de su configuración, catálogos y estado operacional. La respuesta informa la versión resuelta para hacer esa dependencia explícita.

5. Garantías que se ganan al hacer este corte

Resultado trazable. Bajo la misma versión y configuración, el motor aplica las mismas reglas. No se promete igualdad byte-a-byte entre despliegues: terminologías, mensajes y disponibilidad pueden cambiar. Reintentos conscientes. Reintentar puede ser necesario ante fallas transitorias, pero cada validación procesada consume cuota, registra metadatos y puede disparar un webhook. El cliente debe usar backoff y un máximo acotado. Metadatos operacionales. Una validación procesada registra tenant, tipo de recurso, resultado, conteos, duración, perfil y versión. No se persisten el body, un hash del recurso ni la respuesta completa, por lo que este registro no se presenta como una reproducción probatoria del payload. Sin alucinación de perfiles. Fhiron trabaja con StructureDefinitions, CodeSystems, ValueSets y NamingSystems publicados oficialmente. Si CL Core no cubre un caso de uso, la plataforma no inventa un perfil propio que parezca oficial; el alcance se declara como una limitación. Errores en español. Inspect traduce los hallazgos del motor y los combina con issues locales estructurados. Cuando HAPI reporta el perfil, la respuesta conserva esa referencia.

6. Comparación uno-a-uno

Mismo agente, misma tarea: producir una MedicationRequest chilena válida (paracetamol 500 mg / 8 h, ruta oral, ambulatoria). Dos arquitecturas distintas.

Dimensión	Validación pura por LLM	Fhiron MCP (LLM + motor)
Input idéntico → reglas versionadas	No garantizado	Sí, con versión/configuración explícitas
Cobertura de CL Core	”Lo que recordó el modelo”	Artefactos oficiales cargados en el motor
Binding terminológico (ATC · TFC · LOINC · SNOMED CT ES)	“Lo que recordó el modelo”	$validate-code contra el CodeSystem cargado
Mensajes de error en español	”Lo que produzca el modelo”	Generados por el motor con referencia al perfil
Metadatos operacionales	Depende del provider	Sí, sin body clínico ni respuesta completa
Riesgo de inventar perfil/extensión	Alto	Bloqueado por construcción (regla canónico-only)
Persistencia de datos clínicos en Inspect	Depende del provider	El body no se persiste; sí se guardan metadatos
Costo marginal por validación	Tokens del LLM	HTTP a motor local
Latencia	Variable según modelo	Medida en cada validación remota

Lo que se gana con la mediación no es solo correctness. Es la posibilidad de hacer afirmaciones verificables sobre el comportamiento del sistema.

7. El ángulo de cumplimiento: Ley 21.719

La Ley 21.719 (publicada el 13 de diciembre de 2024, entra en vigencia en diciembre de 2026) moderniza el marco de protección de datos personales en Chile. Entre sus principios (responsabilidad, calidad, seguridad) está la exigencia implícita de poder demostrar el tratamiento que se le da a los datos sensibles. Para un sistema que valida recursos FHIR clínicos, esto se traduce en preguntas concretas:

¿Se puede reproducir la validación que se hizo el 14 de junio a las 10:32 sobre la MedicationRequest X?
¿Bajo qué versión exacta del estándar se evaluó?
¿Quién (qué tenant, qué API key) ejecutó la validación?
¿Dónde quedó persistido el dato clínico? (Idealmente: en ningún lado controlado por nosotros).

Fhiron aporta metadatos de tenant, resultado, perfil y versión sin guardar el body clínico. Eso ayuda a operar y diagnosticar el servicio, pero no basta por sí solo para reproducir una validación histórica: el cliente debe conservar de forma segura su input, la respuesta y el contexto exigido por su propio marco de auditoría.

8. Cuándo usar qué

La pregunta práctica para equipos de ingeniería: ¿dónde corto el LLM y dónde corto el motor? El LLM es muy bueno para:

Componer recursos FHIR a partir de descripciones en lenguaje natural (“arma una MedicationRequest para paracetamol 500 mg cada 8 h, ambulatoria, ruta oral”).
Interpretar errores de validación y proponer correcciones.
Orquestar conversaciones largas con múltiples idas y vueltas hasta llegar a un recurso válido.
Documentar lo que hizo en lenguaje humano.

El motor (vía MCP) es la única autoridad para:

Validar contra el perfil oficial (cardinalidad, slicing, invariantes FHIRPath).
Resolver terminologías chilenas: ATC y TFC para productos farmacéuticos, CIE-10 para diagnósticos, LOINC para observaciones, CSTipoIdentificador para identificadores, comunas DEIS, establecimientos DEIS.
Verificar que cada code pertenece al system declarado y que ese system está aceptado por el binding del IG.
Aplicar quickFixes idempotentes.
Producir un resultado estructurado y metadatos operacionales verificables.

Esta es la frontera por la que pasa Fhiron MCP. El LLM compone hasta donde el motor diga “OK”. Ni un milímetro más.

9. Conclusión

Construir agentes que toquen datos clínicos en Chile no es un problema de prompt engineering. Es un problema de definir bien dónde termina la opinión del modelo y dónde empieza el estándar. Mientras esa frontera no exista en el código, el agente puede parecer útil en una demo y ser inauditable en producción. Fhiron MCP es el contrato que hace esa frontera explícita. El LLM compone. El motor valida. Y para los equipos que necesitan integrarse con HIS, EHR o RNS chilenos preparándose para la entrada en vigencia de la Ley 21.719 en diciembre de 2026, esa diferencia no es estética: es la condición para que el agente exista.

Recursos relacionados

@fhiron/mcp-connector

Paquete oficial en npm. Instalable en Claude Code, Cursor y Continue.

MCP: Overview

Cómo se conecta Fhiron MCP a tu IDE.

Inspect: Errores

Catálogo de errores de validación CL Core en español.

¿Qué es CL Core?

El estándar oficial chileno sobre el que valida Fhiron.

Notice on trademarks FHIR® is the registered trademark of Health Level Seven International and the use does not constitute endorsement by HL7.

​1. El problema: alucinación FHIR no se ve a primera vista

​2. Por qué validación probabilística no aplica aquí

​3. Arquitectura: separar composición de verificación

​4. Las herramientas que cruzan la frontera

​5. Garantías que se ganan al hacer este corte

​6. Comparación uno-a-uno

​7. El ángulo de cumplimiento: Ley 21.719

​8. Cuándo usar qué

​9. Conclusión

​Recursos relacionados

@fhiron/mcp-connector

MCP: Overview

Inspect: Errores

¿Qué es CL Core?

1. El problema: alucinación FHIR no se ve a primera vista

2. Por qué validación probabilística no aplica aquí

3. Arquitectura: separar composición de verificación

4. Las herramientas que cruzan la frontera

5. Garantías que se ganan al hacer este corte

6. Comparación uno-a-uno

7. El ángulo de cumplimiento: Ley 21.719

8. Cuándo usar qué

9. Conclusión

Recursos relacionados