Use this file to discover all available pages before exploring further.
Este es el front-door para usar el MCP en Cursor, Claude Desktop, Claude Code, Windsurf o Antigravity. Cada sección muestra un prompt natural que un dev chileno escribiría en el chat, lo que hace el modelo internamente y el output esperado. Para la referencia técnica completa (signatures, costos, mapa categórico) ver Tools — Referencia.
Cuándo: ya tienes un recurso armado y necesitas confirmación contra el IG (slicing, ValueSets remotos, terminologías). Es la tool por defecto cuando el agente entiende “valida esto”.Pídele al agente:
Valida esta MedicationRequest contra CL Core 1.9.4 y aplica los quickFix que tenga.
Si quieres feedback inmediato sin gastar crédito, pide explícitamente “sólo lintea, no valides en servidor”. El modelo elige fhiron_lint y se queda offline.
Cuándo: estás iterando sobre un recurso y quieres feedback en milisegundos sin gastar cuota. Cubre las 35+ reglas cl-* para los 13 recursos más usados.Pídele al agente:
Lintea esta Encounter sin llamar al servidor — necesito ver qué falta antes de gastar crédito.
El lint es determinístico. Mismo JSON in → mismos issues out, sin temperatura del modelo. Es la base para CI/CD: corre fhiron_lint en un pre-commit hook y bloquea el push si hay errores.
Cuándo: el recurso vive en un .json del repo y no quieres pegar 200 líneas de JSON en el chat.Pídele al agente:
Valida el archivo samples/encounter-ambulatorio.json contra CL Core.
Lo que hace el modelo:
1
Verifica el sandbox
Resuelve la ruta contra FHIRON_MCP_ALLOWED_ROOT. Rechaza paths fuera del root, symlinks, archivos ≥ 5 MB y extensiones distintas de .json / .fhir.json.
2
Lee el archivo y delega
Si es un Bundle, delega a fhiron_validate_bundle. Si no, a fhiron_validate.
Para apuntar a otro directorio: export FHIRON_MCP_ALLOWED_ROOT=/ruta/a/tu/proyecto/fhir antes de iniciar el conector. La tool nunca modifica el archivo.
Cuándo: tienes un Bundle (transaction, batch, collection o document) y necesitas saber qué entries pasan y cuáles fallan. Cobra 1 crédito por entry validada, con un cap default de 50 para protegerte.Pídele al agente:
Audita este Bundle entry-por-entry y dame una matriz pass/fail agrupada por resourceType.
Lo que hace el modelo:
1
Linteo local de cada entry
Si una entry tiene errores locales, no llega al servidor (no consume crédito).
2
Validación servidor de las entries que pasan el lint
Hasta max_server_calls (default 50). El resto queda como local-only.
3
Agregación
Devuelve totales, agrupado por resourceType, y el detalle por entry.
Si tu Bundle tiene cientos de entries, sube el cap explícitamente: “valida hasta 200 entries”. El modelo le pasa max_server_calls: 200 (límite duro 200).
Cuándo: quieres evaluar la madurez FHIR de un endpoint público de tercero (proveedor, partner, organismo público) sin tener que leerte el CapabilityStatement a mano.Pídele al agente:
Dame un FHIR Score del endpoint https://api.partner-salud.cl/fhir y explícame qué le falta para llegar a A.
Lo que hace el modelo:
1
Validación SSRF
Bloquea loopback, redes privadas, link-local, metadata cloud y resuelve DNS para detectar rebind a IPs internas.
2
GET /metadata
Descarga el CapabilityStatement con cap de 10 MB.
3
Scoring sobre 5 dimensiones
fhirVersion · core resources · profiles declarados · interactions soportadas · sistemas terminológicos referenciados. 20 puntos cada una.
Cuándo: estás partiendo desde cero y necesitas un esqueleto válido CL Core para ese tipo de recurso. Devuelve el ejemplo y lo lintea defensivamente antes de entregarlo.Pídele al agente:
Dame un ejemplo de Encounter ambulatorio CL Core válido para usarlo de base.
Lo que hace el modelo:
1
fhiron_get_example('Encounter')
Devuelve un Encounter completo con class.system = v3-ActCode, subject, period ISO-8601 y narrative.
Output:
Ejemplo Encounter (CL Core v1.9.4) — pasa el linter local ✅
Cuándo: el modelo necesita un código real (comuna DEIS, establecimiento, TFC, CIE-10, identificador chileno) y tú no quieres que lo invente.Pídele al agente:
Busca el código DEIS de la comuna de Las Condes y ármame una Patient.address con esa comuna.
Sistemas disponibles: deis-comuna, deis-establecimiento, deis (combinado), tfc (incluye ATC), cie10, identificadores (CSTipoIdentificador). Todas son listas vendorizadas en el connector — sin red.
Cuándo: te apareció un código de error (cl-medreq-02, hapi-error-terminology, mcp-quota-01) y quieres contexto pedagógico antes de tocar el JSON.Pídele al agente:
Explícame cl-medreq-02 — qué significa, por qué FHIR lo exige y cómo lo arreglo.
Lo que hace el modelo:
1
fhiron_explain_code({ code: 'cl-medreq-02' })
Busca en el catálogo cl-* / hapi-* / mcp-* y devuelve why, suggestion, example y links.
Output:
📘 cl-medreq-02 — explicación
{ "code": "cl-medreq-02", "why": "MedicationRequest.intent es cardinalidad 1..1 en FHIR R4. Sin él, el sistema receptor no distingue una receta firmada (order) de una propuesta de un asistente clínico (proposal) o de un protocolo precargado (plan).", "profileUrl": "http://hl7.org/fhir/StructureDefinition/MedicationRequest", "docsUrl": "https://docs.fhiron.cl/bridge/errores#cl-medreq-02", "suggestion": "Agregar 'intent': 'order' para recetas firmadas. Para sugerencias IA usar 'proposal'; para protocolos, 'plan'.", "example": { "intent": "order" }}
La lista completa de códigos también está expuesta como recurso MCP en fhiron://errors — el modelo la consulta cuando arma respuestas largas.
Cuándo: quieres saber qué restricciones agrega CL Core sobre el perfil base de FHIR R4 para un recurso. Útil cuando estás migrando un sistema que ya valida contra R4 y necesitas cuantificar el delta. Cobra 2 créditos (una validación contra R4 + una contra CL Core).Pídele al agente:
Compara este Patient contra FHIR R4 base y CL Core. Quiero ver qué errores aparecen sólo en CL Core.
Devuelve las restricciones que sólo aparecen en CL Core — o sea, el costo de migración.
Output:
R4: 0 errores · CL Core: 2 errores · 2 son específicos de CL Core.
{ "resourceType": "Patient", "r4": { "profile": "http://hl7.org/fhir/StructureDefinition/Patient", "valid": true, "errors": [] }, "clCore": { "profile": "https://hl7chile.cl/fhir/ig/clcore/StructureDefinition/CorePacienteCl", "valid": false, "errors": [ "Patient.identifier requerido — al menos un identifier con system http://www.registrocivil.cl/run.", "Patient.address.city debe pertenecer al CodeSystem CodigoComunaDEIS (decreto 817)." ] }, "clOnlyDiff": [ "Patient.identifier requerido — al menos un identifier con system http://www.registrocivil.cl/run.", "Patient.address.city debe pertenecer al CodeSystem CodigoComunaDEIS (decreto 817)." ]}
Recursos soportados para comparación: Patient, Practitioner, Encounter, Observation, Condition, MedicationRequest. Para el resto, valida directamente con fhiron_validate.
Cuándo: un issue.quickFix te trae el parche listo (jsonPointer + replacement) y quieres aplicarlo sin escribir el patch a mano. Es idempotente — aplicar dos veces es seguro.Pídele al agente:
Toma el quickFix de cl-enc-04 y aplícalo al recurso original.
Lo que hace el modelo:
1
fhiron_apply_fix(resource, quickFix)
Aplica el RFC 6901 sobre el JSON. Si el path no existe, lo crea.
Esta tool no llama al servidor. Después de aplicar el fix, pídele al agente “valida de nuevo” para que corra fhiron_validate (1 crédito) y confirme que el recurso quedó limpio contra el IG completo.
