MCP · Empezar
Introducción
El MCP Fhiron CL Core conecta a tu asistente IA con la realidad FHIR chilena. Esta página explica qué es, para quién, qué resuelve y dónde están sus límites.
Definición
Qué es el MCP Fhiron CL Core
El MCP Fhiron es un servidor Model Context Protocol publicado en npm como @fhiron/mcp-connector. Se instala con npx y se conecta a cualquier cliente MCP-compatible (Claude Desktop, Cursor, Continue, Copilot via plugin). Una vez conectado, tu asistente IA gana acceso a un conjunto de herramientas que entienden CL Core v1.9.4, terminologías chilenas y workflows clínicos locales.
A diferencia de un cliente FHIR REST tradicional, el MCP no expone CRUD genérico contra un servidor remoto. Expone tools (validar, lintear, explicar, comparar), resources (changelog CL Core, errores frecuentes, normativa MINSAL, datasets sintéticos) y prompts (alta médica, receta retenida, LME, notificación SEREMI). Todo corre local. Tus recursos FHIR no se envían a ningún servicio externo.
El proyecto es open source, mono-foco Chile-first y español-first. La copy de mensajes, descripciones de tools y errores está en español. Es la versión instalable de Fhiron Bridge para developers que prefieren trabajar dentro de su editor en vez de pegar JSON en un dashboard.
Audiencia
Para quién es
- Developers FHIR en Chile que escriben recursos a mano y necesitan validación, autocompletado y ejemplos alineados con CL Core sin salir del editor.
- Equipos integrando un EHR o sistema legacy con estándares chilenos — migrando HL7 v2 a FHIR, mapeando identificadores nacionales, ajustándose a perfiles MINSAL.
- Estudiantes y educadores aprendiendo FHIR CL Core: el MCP funciona como tutor invisible que valida y explica en tiempo real.
- Auditores técnicos que revisan conformidad CL Core de un payload antes de certificar o aprobar un envío al EHR destino.
Límites de audiencia
Para quién NO es
Hay casos de uso donde el MCP Fhiron no es la herramienta correcta. Mejor decirlo de frente:
- No es un cliente CRUD para producción. Si necesitás crear, leer, actualizar o borrar recursos FHIR contra un servidor remoto en runtime, eso es trabajo de tu SDK o de herramientas como Postman/Insomnia.
- No es un EHR ni un repositorio clínico. No guarda historiales de pacientes ni datos clínicos reales.
- No reemplaza a un servidor FHIR. Si estás montando interoperabilidad productiva, vas a necesitar HAPI, Aidbox, AWS HealthLake o equivalente. El MCP vive antes en el flujo: cuando el dev todavía está construyendo el recurso.
Cinco problemas concretos
Qué resuelve
Estos son los cinco escenarios donde el MCP cambia el día a día de un developer FHIR en Chile:
Validación CL Core sin servidor propio
Validás un Patient, Encounter o Bundle contra los perfiles de CL Core v1.9.4 desde tu editor. No necesitás levantar un HAPI local ni mantener una instancia.
Errores en español, con referencia al perfil
Cada error del validador llega traducido y apunta al campo y al perfil exacto que falla. No tenés que leer el OperationOutcome crudo en inglés.
Sugerencias de fix mientras editás
El tool quickfix propone parches concretos para los errores más comunes (RUN sin dígito verificador, system de codificación faltante, perfil mal referenciado).
Búsqueda semántica de ejemplos chilenos
Pedís en lenguaje natural “MedicationRequest controlada con químico farmacéutico” y recibís ejemplos curados del catálogo Fhiron, no resultados genéricos de StackOverflow.
Workflows clínicos chilenos como prompts listos
Bundle de alta médica, receta retenida, licencia médica electrónica y notificación SEREMI vienen como Prompts MCP. El AI los compone respetando estructura CL Core y normativa MINSAL.
Límites técnicos
Qué NO resuelve
Tan importante como saber qué hace el MCP es saber qué deja afuera deliberadamente:
- No es un servidor FHIR ni guarda recursos. Si tu sistema necesita persistir Patient/Encounter en producción, eso lo hace tu EHR o un servidor FHIR (HAPI, Aidbox, AWS HealthLake).
- No autentica contra servidores remotos. SMART-on-FHIR no está incluido en esta versión.
- No reemplaza al SDK FHIR de tu lenguaje. Si construís recursos en Java o TypeScript, seguís usando tu SDK; el MCP te asiste, no los genera por vos.
- No es un validador certificado oficial de HL7 Chile o MINSAL. Es la mejor herramienta para developers, pero la conformidad regulatoria final la firma el organismo correspondiente.
Cómo encaja en el ecosistema
Diferencia con AWS HealthLake, Momentum y WSO2
Esto no es una comparación competitiva. Cada herramienta resuelve un problema distinto del stack FHIR. La pregunta útil es cuándo usar cuál:
| Herramienta | Rol | En qué se diferencia del MCP Fhiron |
|---|---|---|
| AWS HealthLake | Servicio FHIR managed en AWS | AWS HealthLake almacena, indexa y expone recursos FHIR R4 a escala. Es infraestructura productiva. No incluye perfiles chilenos curados ni asistencia para developers que escriben FHIR a mano. |
| Momentum FHIR Suite | Servidor FHIR comercial multi-tenant | Momentum vende capacidades de servidor FHIR completo: terminología, persistencia, subscriptions. Su foco es operación. Fhiron MCP no compite con eso; vive antes en el flujo, donde el developer todavía está escribiendo el recurso. |
| WSO2 Healthcare | API gateway con módulos FHIR | WSO2 expone, normaliza y rutea APIs FHIR entre sistemas legacy. Resuelve interoperabilidad organizacional. No tiene perfiles CL Core ni asistencia local en el editor. |
| MCP Fhiron CL Core | Asistente local-first para developers FHIR Chile | Vive en el editor, no en el datacenter. Su valor está en perfiles CL Core curados, terminologías chilenas y workflows MINSAL listos para invocar desde el chat. |
Resumen práctico: AWS HealthLake, Momentum y WSO2 son el servidor. El MCP Fhiron es el asistente que te ayuda a construir lo que vas a enviar a ese servidor. No se reemplazan, se complementan.
Sigue leyendo
Próximo paso
Si nunca trabajaste con MCP, la siguiente página explica el protocolo desde cero asumiendo que ya conocés FHIR. Si ya trabajaste con clientes MCP, podés saltar directo a la guía de instalación cuando esté disponible.