--- { "title": "[Vídeo] Primeros Resultados de FHIR Schema: Evgenii Mukha en FHIR DevDays 2025", "description": "A pesar de compartir las mismas especificaciones, los validadores FHIR discrepan en casos extremos. FHIR Schema resuelve esto con un formato inspirado en JSON Schema y un algoritmo simple y universal. Conozca los aprendizajes de Aidbox, la validación sin instantánea y la hoja de ruta.", "date": "2025-12-15", "author": "Evgeny Mukha", "reading-time": "20 minutes", "tags": [ "Video", "FHIR Tools" ] } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- {% embed url="https://youtu.be/h7QILlzkkfY" %} Esta publicación forma parte de una serie sobre las sesiones de Health Samurai en HL7 FHIR DevDays 2025. En este artículo, «[FHIR Schema](/articles/type-schema-a-pragmatic-approach-to-build-fhir-sdk) First Year Results: Ecosystem Evolution and Dev‑UX», Evgenii Mukha, ingeniero de software en Health Samurai, comparte las lecciones aprendidas tras un año ejecutando un nuevo motor de validación FHIR en producción. **Lo que aprenderá:** - Por qué los validadores FHIR existentes discrepan ante los mismos datos y qué implica esto para la interoperabilidad. - Qué es FHIR Schema y en qué se diferencia de las StructureDefinitions en bruto. - Cómo el algoritmo de validación sin instantánea permite comprobaciones multi‑perfil y ajustes en tiempo de ejecución. - Qué aprendió el equipo del uso en el mundo real y hacia dónde se dirige **FHIR Schema** a continuación. ## El problema: validación inconsistente La charla comienza con un caso extremo sencillo pero revelador: un recurso Patient que contiene una extensión primitiva con valores nulos que debería violar una restricción `el-1` de [FHIRPath](/articles/unlocking-fhirpath-power-a-deep-dive-into-static-type-analysis-for-robust-tooling). Distintos servidores públicos lo gestionan de maneras completamente diferentes, desde recortar silenciosamente el valor hasta aceptarlo o notificar errores no relacionados. Esto ilustra que la validación, que debería ser un pilar de la interoperabilidad, se comporta de forma impredecible entre implementaciones. El problema de fondo no son solo los errores, sino una especificación de validación poco precisa, con detalles clave sobre el segmentado (*slicing*), la terminología y los casos extremos dispersos en conversaciones de Zulip y tickets de JIRA, en lugar de recogidos en un documento claro orientado a los implementadores. Los autores de motores carecen de una guía precisa comparable a la que existe para FHIRPath, lo que dificulta alcanzar una compatibilidad completa. ## El enfoque de FHIR Schema FHIR Schema se presenta como una forma de ofrecer a los implementadores una representación compartida e independiente del lenguaje para las restricciones de validación, junto con un algoritmo de validación preciso. Se deriva de las StructureDefinitions en lugar de reemplazarlas, y consta de tres partes principales: un transpilador que convierte las StructureDefinitions en archivos de esquema, un formato de esquema JSON/YAML que representa las restricciones como un árbol, y un algoritmo de validación con una suite de pruebas asociada. El objetivo es que los motores de validación en diferentes pilas tecnológicas reutilicen la misma representación de esquema en lugar de inventar sus propios modelos internos. Esto debería hacer que el comportamiento sea más predecible y reducir las divergencias entre servidores. ![](image-1.avif) ## Esquema en forma de árbol y validación sin instantánea Mientras que las StructureDefinitions enumeran los elementos como una tabla plana, FHIR Schema los organiza en un árbol explícito que refleja los datos FHIR reales. Los elementos definen las claves posibles, los arrays son ciudadanos de primera clase, los enlaces de terminología y los elementos polimórficos se modelan directamente, y los campos requeridos o excluidos se representan sin necesidad de inferirlos a partir de la cardinalidad. El segmentado (*slicing*) se expresa mediante comparadores que determinan si un elemento pertenece a un segmento, en función de criterios como enlaces, patrones o validez de perfiles. El algoritmo de validación construye un conjunto de esquemas relevantes (recurso base, perfiles y ancestros), comprueba los invariantes de nivel superior y recorre el árbol del recurso aplicando comprobaciones a nivel de nodo y reglas de segmentado. Al funcionar sin instantáneas preconstruidas, admite cambios en tiempo de ejecución de las restricciones, validación simultánea frente a múltiples perfiles y descubrimiento de perfiles mediante la comprobación de qué esquemas se ajustan a los datos existentes. ## Aprendizajes en producción y hoja de ruta Tras un año de uso en producción en [**Aidbox**](https://www.health-samurai.io/fhir-server), han emergido varias lecciones: la transpilación debe ser sin estado y reproducible; los grupos de segmentado deben tener un ámbito único cuando se aplican múltiples perfiles; y se requiere un modelo de notificación de errores más claro para que las herramientas y las suites de pruebas puedan comparar resultados de forma fiable. Estos puntos demuestran que estandarizar el formato y el algoritmo es solo parte del trabajo: la semántica de los errores también importa. De cara al futuro, el equipo tiene previsto abrir su suite de pruebas, publicar implementaciones de referencia en JavaScript y Clojure, y publicar una especificación versionada con una forma más «similar a FHIR», junto con un grupo de trabajo centrado en los implementadores de validadores. El objetivo es pasar de un único motor con pruebas internas a un ecosistema más amplio de motores compatibles y casos de prueba compartidos. ## Por qué esto importa para los equipos FHIR Para las organizaciones que desarrollan o integran [servidores FHIR](https://www.health-samurai.io/fhir-server) y validadores, FHIR Schema ofrece un camino más claro hacia una validación consistente. Los autores de motores obtienen un formato y un algoritmo implementables en lugar de tener que reproducir el comportamiento mediante ingeniería inversa de una única implementación de referencia. Los equipos tienen más posibilidades de obtener resultados de aprobado/fallido consistentes entre servidores y acceden a escenarios avanzados como la [validación de múltiples perfiles](/blog/recursive-validation-in-fhir-profiles) y el ajuste de restricciones en tiempo de ejecución. Esto hace que los sistemas basados en FHIR sean más fáciles de depurar y más predecibles en escenarios de interoperabilidad reales. ## Recursos Vea la presentación completa de Evgenii en FHIR DevDays 2025 y la lista de reproducción completa de Health Samurai: [**Ver el vídeo completo**](https://youtu.be/h7QILlzkkfY) [**Lista de reproducción completa en YouTube**](https://youtu.be/h7QILlzkkfY) Conéctese con Evgenii en [**LinkedIn**](https://www.linkedin.com/in/evgeny-mukha-192293228/) o a través del flujo de Zulip de FHIR Schema. Explore estos recursos de FHIR Schema:[ **Borrador de especificación**](https://fhir-schema.github.io/fhir-schema/)[ **Playground**](https://fhir-validator.aidbox.app/)[ **Volcado de paquete transpilado**](https://console.cloud.google.com/storage/browser/fhir-schema-registry/1.0.0)[ **Implementación de referencia (CLJ)**](https://github.com/fhir-clj/fhir-schema)[ **Implementación de referencia (JS)**](https://github.com/fhir-schema/fhir-schema/tree/main/fhirschema-js) Véase también: [Type Schema: Construcción de SDKs FHIR](/blog/type-schema-a-pragmatic-approach-to-build-fhir-sdk).