FHIR en un Párrafo
FHIR — Fast Healthcare Interoperability Resources — es el estándar moderno para intercambiar datos sanitarios, desarrollado por HL7 para sustituir los crípticos mensajes delimitados por barras de HL7 v2 por JSON (o XML) limpio y compatible con la web. En FHIR, cada pieza de información clínica es un recurso: un Patient, una Observation, un MedicationRequest, un DiagnosticReport, etc. Los recursos se referencian entre sí y pueden agruparse, y se intercambian sobre APIs RESTful ordinarias. R4 es la versión más desplegada y la que la mayoría de las integraciones tienen como objetivo hoy.
Por Qué Importa la Validación
Un servidor FHIR rechazará un recurso que no cumpla el estándar, y los errores estructurales sutiles son fáciles de cometer a mano o al transformar datos desde otro formato. Validar antes de enviar ahorra una ida y vuelta frustrante y saca a la luz los problemas mientras el contexto está fresco. La validación responde a una pregunta precisa: ¿coincide este JSON con las reglas que FHIR define para su tipo de recurso?
Qué Comprueba Este Validador
- Tipo de recurso. Todo recurso debe declarar un
resourceType. Sin él, no se puede comprobar nada más.
- Campos obligatorios. Cada tipo de recurso define campos que deben estar presentes. Una Observation, por ejemplo, requiere tanto
status como code; un Bundle requiere type. Que falte un campo obligatorio es un error grave.
- Cardinalidad. Algunos campos aparecen una vez (0..1), otros se repiten (0..*). Aportar un array donde se espera un valor único, o al revés, se señala.
- Tipos de datos. Los primitivos de FHIR tienen formatos estrictos. Una
date debe parecerse a YYYY, YYYY-MM o YYYY-MM-DD; un instant necesita una marca de tiempo completa con zona horaria. Un número donde se espera una cadena de fecha se atrapa de inmediato.
- Value sets obligatorios. Ciertos campos codificados solo pueden contener códigos específicos. Un estado de Observation "done" es inválido porque el conjunto permitido es registered, preliminary, final, etc.
Errores vs Advertencias
No todo problema es fatal. El validador separa los errores graves — un campo obligatorio que falta, un tipo de dato erróneo, un código fuera de un value set obligatorio — de las advertencias, que señalan cosas sospechosas pero técnicamente permitidas, como un CodeableConcept sin coding ni text. Trata los errores como bloqueantes y las advertencias como avisos para revisar la intención.
Bundles y Recursos Anidados
Un Bundle es un contenedor que lleva otros recursos, usado para transacciones, resultados de búsqueda, documentos y payloads de mensaje. Validar un Bundle implica validar también cada recurso contenido. Esta herramienta recurre en cada entrada e informa de los problemas con su ruta completa, de modo que un status de Observation que falta dentro de la tercera entrada de un Bundle se señala con precisión en lugar de esconderse en el anidamiento.
Errores Comunes Que el Validador Atrapa
Unos pocos errores aparecen una y otra vez, sobre todo cuando los recursos se construyen a mano o se transforman desde otro formato. Las fechas son culpables frecuentes: escribir un birthDate como "12/05/1990" en lugar de "1990-05-12" falla porque las fechas FHIR deben ser ISO-8601. Los códigos de estado son otro: teclear "done" o "complete" donde el value set espera "final" es inválido, y el validador lista los códigos permitidos para que lo corrijas. Los deslices de cardinalidad ocurren cuando un campo que debería ser un valor único se aporta como array, o un campo repetido se da como un objeto suelto. Y el error más simple de todos — olvidar la propiedad resourceType — detiene la validación antes de que nada más se pueda comprobar. Ver esto señalado con la ruta de elemento exacta convierte un vago "el servidor lo rechazó" en un problema preciso y corregible.
Los Límites de un Validador Ligero
Este validador es pragmático, no exhaustivo. Cubre los tipos de recurso comunes y las reglas estructurales que atrapan la mayoría de los errores del mundo real, pero no implementa la especificación FHIR completa, todos los perfiles, las consultas a servidores de terminología ni las restricciones de guías de implementación personalizadas. Para pruebas formales de conformidad contra una guía de implementación específica, usa el validador oficial de HL7. Para la pregunta diaria de "¿es este recurso estructuralmente sólido antes de enviarlo?", una comprobación rápida en el navegador es exactamente la herramienta adecuada, y mantiene tus datos privados al hacerlo.