hl7.fhir.cl.clcore versión 1.9.4 (el paquete NPM publicado por HL7 Chile) como Implementation Guide canónico. Los recursos FHIR que envíes a la API de Inspect se validan contra los perfiles, CodeSystems y ValueSets definidos en ese paquete.
Recursos cubiertos por Fhiron Inspect
CL Core 1.9.4 publica 16 perfiles sobre 14 tipos de recurso (Observation tiene dos: general y signos vitales) más el tipo de datoAddress. Fhiron implementa reglas locales (offline, gratuitas) para los 14 tipos de recurso más usados en integraciones chilenas, que no coinciden uno a uno con los que CL Core perfila. La validación contra HAPI con el IG cargado cubre el resto del IG. El MCP además expone una skill con operating contract, routing por intent y playbooks por flujo. Ver Skill CL Core (agent behavior).
La columna Perfil CL Core dice contra qué se valida cada tipo. Donde aparece sin perfil en CL Core, el recurso se valida contra FHIR R4 base más las reglas locales de Fhiron; sigue siendo validación real, pero no hay restricción chilena publicada que aplicar.
Perfiles de CL Core sin reglas locales
CL Core perfila cinco tipos más que Fhiron todavía no cubre con reglas locales. Se validan igual contra su perfil en el motor, solo que sin los chequeos offline del linter.
Además, CL Core perfila el tipo de dato
Address con cl-address, que aplica a cualquier recurso que lleve una dirección.
Las reglas transversales cubren bindings y estructuras que cruzan todos los recursos: cl-system-02 (URI absoluta en identifier.system), cl-meta-01 (canonical HTTPS en meta.profile), cl-ref-01 (formato ResourceType/id en references), cl-date-01 (ISO-8601), cl-narrative-01 (status narrativo). El identificador nacional dentro de CorePacienteCl se chequea con cl-run-01 … cl-run-04 (formato, dígito verificador módulo 11, system canónico del Registro Civil).
Catálogos chilenos
Fhiron indexa los catálogos oficiales como recursos consultables:- Comunas DEIS (decreto 817): código, nombre y región.
- Establecimientos DEIS: código, razón social y tipo.
- TFC: terapéutico farmacológico chileno.
- CIE-10: clasificación de diagnósticos.
- ATC: clasificación anatómico-terapéutico-química (WHOCC), terminología internacional para fármacos.
- CSTipoIdentificador: RUN, pasaporte, DNI extranjero, identificador interno.
fhiron_search_terminology y como resources fhiron://catalogs/{system}.
Qué se expande contra catálogo y qué no
No todas las terminologías se comportan igual dentro del motor, y la diferencia importa cuando interpretas unOperationOutcome.
Publicadas en el motor. El catálogo está cargado, así que el código se
expande y se valida contra él. Un código que no existe en el catálogo es un
error, no una advertencia.
Estándares internacionales que no distribuimos. SNOMED CT, LOINC, CIE-10 y
ATC se licencian por institución y no se redistribuyen desde nuestro servidor.
El motor verifica que la URI canónica sea la correcta y que el código tenga la
forma esperada, y degrada el hallazgo a advertencia en vez de afirmar
conformidad del concepto.
Esa degradación es deliberada: un validador que dice verificar SNOMED sin tener
el catálogo cargado te está entregando un falso positivo. Preferimos decirte
exactamente qué se verificó y qué no.
TFC no aparece en ninguna de las dos listas. No existe una fuente oficial
publicada y versionada de la Terminología Farmacéutica Chilena, así que el
motor no la carga ni la reconoce como sistema válido. Para medicamentos usa
ATC (
http://www.whocc.no/atc).MINSAL EIS v0.2.0: terminología paralela
Además de CL Core, Fhiron soporta el Estándar de Interoperabilidad de Salud (EIS) v0.2.0 publicado por la Unidad de Interoperabilidad del MINSAL. Es un IG paralelo (no reemplaza CL Core) que aporta terminología oficial bajo el namespacehttps://interoperabilidad.minsal.cl/fhir/ig/eis/. MINSAL publicó 0.2.0 el 2026-08-05 reestructurando casi por completo el IG: renombró todas las URLs canónicas respecto a 0.1.0 y, a diferencia de 0.1.0, ahora también incluye 13 StructureDefinitions (perfiles, extensiones y modelos lógicos), no solo terminología. Las URIs EIS se citan según la publicación del MINSAL; aún no existe un paquete NPM oficial con copia local verificable en el repo, por lo que pueden volver a ajustarse cuando el MINSAL formalice su distribución:
- eis-comunas-cs (346 comunas oficiales DEIS)
- eis-PrevisiondeSalud-CS (FONASA, ISAPRE, CAPREDENA, DIPRECA, SISAE/SISAN/SISAF)
- eis-EspecialidadesySubespecialidadesMedicas-CS, eis-especialidades-odontologicas-cs, eis-especialidades-farmaceuticas-cs, eis-especialidades-bioquimicas-cs
- eis-PueblosOriginarios-CS, eis-EstadoCivil-CS, eis-religion-cs
- eis-establecimientos-nivel-complejidad-cs
- eis-GruposdeOcupaciones-CS + eis-OcupacionesDesagregadas-CS (DEIS)
- 39 CodeSystems + 42 ValueSets + 13 StructureDefinitions en total
Procedencia: las URIs del namespace EIS se citan según la publicación de MINSAL y quedan pendientes de snapshot local de verificación. Mientras no exista esa copia local, se tratan como brecha registrada en la auditoría de cobertura canónica.
Cuándo usar CL Core vs EIS
Cuando un concepto tiene cobertura en ambos (ej. comunas), recomendamos CL Core como default y EIS para conceptos no cubiertos en CL Core (previsión, estado civil, pueblos originarios, nivel atención).
Ambas canonicals coexisten sin colisión. Inspect acepta payloads con cualquiera de las dos.