Documentation Index
Fetch the complete documentation index at: https://docs.fhiron.cl/llms.txt
Use this file to discover all available pages before exploring further.
Cada plan incluye una cantidad definida de validaciones por mes. La regla es transparente y consistente entre los tres canales: Bridge UI, API REST y MCP connector.
Resumen rápido
| Acción | Cuesta |
|---|
| Validar un recurso (Patient, Encounter, MedicationRequest…) | 1 validación |
| Validar un Bundle de N entries | N validaciones |
| Validar el mismo recurso dos veces | 2 validaciones |
| Comparar el mismo recurso contra FHIR® R4 y CL Core | 2 validaciones |
| Linter local en el editor | 0 |
| Buscar terminología (DEIS · TFC · CIE-10 · identificadores) | 0 |
| Pedir un ejemplo CL Core válido | 0 |
| Aplicar un quick-fix sobre tu JSON | 0 |
| Escanear un endpoint FHIR público (FHIR Score) | 0 |
| Pedir explicación pedagógica de un código de error | 0 |
Por canal
Las tres rutas para validar contra CL Core pasan por el mismo endpoint POST /api/validate y descuentan idéntico de la cuota:
| Canal | Cómo se invoca |
|---|
| Bridge UI (dashboard web) | Pegando el JSON en el editor |
| API REST | POST /api/validate con X-API-Key |
| MCP connector | Tu agente IA llama fhiron_validate |
@fhiron/mcp-connector expone 10 tools. Cada una tiene un costo claro:
| Tool | Costo | Comentario |
|---|
fhiron_validate | 1 validación | El caso default cuando le pides al agente “valida esto”. |
fhiron_validate_file | 1 validación | Igual que fhiron_validate pero leyendo un .json del filesystem. |
fhiron_validate_bundle | 1 validación por entry validada (cap 50 por defecto, configurable hasta 200) | El cap protege la cuota cuando un Bundle tiene cientos de entries. |
fhiron_compare_profiles | 2 validaciones | Valida en paralelo contra el perfil R4 base y contra CL Core. |
fhiron_lint | 0 | Reglas locales cl-* ejecutándose en el connector. Sin red. |
fhiron_apply_fix | 0 | Aplica un parche RFC 6901 sobre tu JSON. Sin red. |
fhiron_get_example | 0 | Devuelve un ejemplo CL Core vendorizado en el connector. |
fhiron_search_terminology | 0 | Búsqueda en catálogos vendorizados (DEIS, TFC, CIE-10, identificadores). |
fhiron_explain_code | 0 | Catálogo cl-*/hapi-*/mcp-* vendorizado. |
fhiron_score_endpoint | 0 | Lee el CapabilityStatement de un endpoint público y calcula score local. |
Bundle: el caso que más confunde
Un Bundle en FHIR puede contener cientos o miles de recursos. Fhiron valida cada entry contra su propio perfil. Por eso:
- Bundle con 12 entries → 12 validaciones.
- Bundle con 200 entries → 200 validaciones.
- Bundle con 5 000 entries → 5 000 validaciones (en MCP requiere subir explícitamente el
max_server_calls).
Para evitar consumir la cuota sin querer, fhiron_validate_bundle por defecto valida hasta 50 entries por llamada. Si necesitas más, pídele al agente “valida hasta 200 entries” — el modelo le pasa max_server_calls: 200 (límite duro 200 por llamada).
Pipelines de IA con datasets grandes
Si tu agente IA está iterando sobre cientos o miles de recursos para validar un dataset, ten en cuenta:
- Cada iteración del agente que llame
fhiron_validate cuenta 1 validación.
- Si el agente vuelve a validar el mismo recurso después de aplicar un quick-fix, cuenta 1 más.
- El linter local (
fhiron_lint) es la tool gratuita y determinística para descartar errores estructurales antes de gastar cuota. Pídele al agente “valida con lint primero, después en servidor solo si pasa el lint”.
Esa práctica baja drásticamente el consumo. Las reglas locales cl-* cubren la mayoría de los errores de migración inicial (campos required ausentes, ValueSets mal pegados, fechas no ISO-8601).
Qué pasa al agotar la cuota
Cuando se agota la cuota mensual del plan:
- La API responde HTTP
429 con un cuerpo JSON describiendo la cuota agotada.
- Los headers
X-RateLimit-* indican el detalle:
X-RateLimit-Limit — cuota mensual del plan (ej: 10000).X-RateLimit-Remaining — validaciones restantes (0 cuando se agotó).X-RateLimit-Reset — timestamp Unix del próximo reseteo.
- En el dashboard recibes un aviso por email cuando llegas al 80% del límite.
La cuota se reinicia el primer día de cada mes calendario.
Lo que no cuenta como validación
Para mantener la regla limpia, esto no descuenta del plan:
- Listar las API keys del tenant.
- Consultar el dashboard de uso (
/dashboard).
- Recibir webhooks de billing.
- Que tu IDE descargue un esquema CL Core a través del MCP.
- El handshake inicial del MCP connector con el servidor.
Cada POST /api/validate exitoso incluye:
HTTP/1.1 200 OK
X-RateLimit-Limit: 10000
X-RateLimit-Remaining: 9847
X-RateLimit-Reset: 1748737200
Resumen para tu plan
| Plan | Validaciones / mes | Caso típico |
|---|
| Free | 100 | Probar el conector y validar recursos puntuales en el editor. |
| Basic | 1 000 | Dev individual o equipo chico iterando contra CL Core. |
| Pro | 10 000 | Equipo mediano con CI/CD que valida en cada commit. |
| Team | 50 000 | Producto en producción con tráfico real de varios sistemas. |
| Enterprise | A convenir | Volumen alto sostenido o batch de IA contra datasets enormes. |
Preguntas frecuentes
¿Validar y volver a validar el mismo recurso cuesta dos validaciones?
Sí. Cada llamada al motor cuenta. Si solo necesitas confirmar que un cambio menor no rompió nada, usa fhiron_lint primero (gratuito) y reserva la validación de servidor para el final.
¿El MCP cuenta distinto que la API REST?
No. Ambos llegan al mismo /api/validate y descuentan idéntico. La diferencia es que el MCP, además, expone tools locales (fhiron_lint, fhiron_apply_fix, etc.) que no descuentan.
¿Hay descuentos por volumen?
Los planes mayores ya incluyen un costo por validación más bajo (Team es ~5x más barato por validación que Basic). Para volúmenes Enterprise el descuento se negocia por contrato.
¿Pierdo validaciones no usadas al fin de mes?
Sí. La cuota se reinicia el primer día de cada mes calendario, no acumula.
¿Qué pasa si mi agente IA valida 10 000 recursos de un dataset por error?
Si tu plan tiene cuota suficiente, se descuentan y listo. Si no, recibes HTTP 429 y el agente puede actuar (avisarte, parar, o esperar). Para batch grande planeado conviene un plan Team o Enterprise — y siempre pasar primero por fhiron_lint para no malgastar cuota en errores estructurales.
Más sobre planes
