| Ruta | Mensaje |
|---|
¿Migrando desde HL7 v2? Usa el Conversor HL7 v2 a FHIR.
Pega tu recurso FHIR R4 en JSON en la casilla de entrada, o sube un archivo .json. También puedes soltar un archivo directamente sobre el área de texto.
Haz clic en Validar. La herramienta analiza el JSON y lo comprueba contra la estructura R4 de ese tipo de recurso — campos obligatorios, cardinalidad, formatos de tipo de dato y value sets obligatorios.
Revisa la tabla de problemas, que enumera cada error y advertencia con su ruta de elemento (por ejemplo Patient.birthDate) y, cuando es posible, una sugerencia de corrección.
Para los Bundle, cada recurso contenido se valida y los problemas se informan con su ruta completa dentro del Bundle. Usa los botones de ejemplo para ver patrones de error comunes.
Comprueba los tipos de recurso FHIR R4 más comunes en busca de campos obligatorios, cardinalidad de valor único o repetido y tipos de datos primitivos correctos, atrapando los errores estructurales que rompen la interoperabilidad antes de enviar un recurso a un servidor.
Los campos codificados como Observation.status y Bundle.type se comprueban contra sus value sets obligatorios, de modo que un estado inválido como "done" en lugar de "final" se señala con la lista de códigos permitidos.
Cada problema apunta al elemento exacto donde ocurre, usando una ruta familiar de estilo FHIRPath como MedicationRequest.intent, para que vayas directo al problema en lugar de buscar entre JSON anidado.
Pega un Bundle y el recurso de cada entrada se valida de forma independiente, con los problemas informados en su ruta completa dentro del Bundle, lo que es esencial al depurar payloads de transacción y colección.
A diferencia del validador oficial, que necesita un entorno Java y configuración de servidor, este se ejecuta por completo en tu navegador. Ningún payload FHIR, que con frecuencia contiene información médica protegida, se sube nunca.
Los recursos FHIR llevan habitualmente nombres de pacientes, identificadores y datos clínicos. Los validadores en servidor suben ese payload, lo que es un riesgo de cumplimiento. Este validador se ejecuta por completo en el cliente, así que la información médica protegida permanece en tu dispositivo mientras depuras un recurso.
El validador de referencia de HL7 es potente pero requiere instalar Java y configurar paquetes. Para el caso común de "¿es este recurso estructuralmente válido?", una herramienta de navegador que devuelve una respuesta en milisegundos elimina toda esa fricción, lo que importa cuando iteras sobre una integración.
La sanidad se mueve de HL7 v2 a FHIR, y los ingenieros que hacen ese trabajo necesitan respuesta rápida sobre los recursos que producen. Este validador se combina con el Conversor HL7 v2 a FHIR para que conviertas y luego compruebes el resultado de inmediato, todo en un flujo privado.
En lugar de un muro de jerga de esquemas, los problemas se presentan como una tabla legible con severidad, ruta de elemento y un mensaje en lenguaje claro más una sugerencia de corrección cuando aplica, para que incluso desarrolladores nuevos en FHIR puedan actuar sobre los resultados.
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.
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?
resourceType. Sin él, no se puede comprobar nada más.status como code; un Bundle requiere type. Que falte un campo obligatorio es un error grave.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.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.
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.
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.
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.
El flujo más habitual sigue a una conversión v2 a FHIR: tras mapear un mensaje ADT^A01 sintético a un Patient y un Encounter con el Conversor HL7 v2 a FHIR, pega el JSON resultante directamente en este validador para confirmar que la salida del conversor es estructuralmente correcta — campos obligatorios presentes, fechas en formato ISO-8601, códigos de estado tomados del value set correcto — antes de que llegue a un servidor FHIR de pruebas.
Un segundo flujo es depurar un rechazo del servidor. Cuando un endpoint FHIR devuelve un error 400 genérico para una Observation sintética, pegar el mismo JSON aquí suele localizar la causa en segundos — normalmente un elemento code ausente, un valor de status como "done" en lugar del "final" requerido, o un effectiveDateTime escrito en un formato no ISO.
Un tercero es validar una importación por lotes antes de ejecutarla. Un Bundle de transacción montado a mano a partir de varias entradas Patient y Observation sintéticas puede pegarse entero; el validador recorre cada entrada e informa de la que falla — por ejemplo, la entrada 3 sin su Observation.status — en su ruta exacta, así que el único registro roto de un lote de veinte no hay que buscarlo a prueba y error.
Las comprobaciones estructurales, de cardinalidad, de tipo de dato y de value set están implementadas para ocho tipos de recurso. Cualquier otro tipo se analiza igualmente, pero solo recibe una comprobación básica de presencia de resourceType:
| Tipo de recurso | Qué se comprueba |
|---|---|
| Patient | Estructura de nombre, identificador y value set de género |
| Observation | Status y code obligatorios, formatos de fecha efectiva |
| DiagnosticReport | Status, code y referencias a resultados |
| Bundle | Value set obligatorio de type, validación recursiva de entradas |
| Encounter | Status y class obligatorios |
| Condition | Binding del value set de clinical-status |
| MedicationRequest | Value sets obligatorios de status e intent |
| Practitioner | Estructura de nombre e identificador |
Solo se acepta entrada en JSON, en línea con cómo intercambian datos la mayoría de las integraciones FHIR R4 actuales; no se analizan recursos en XML.
Un recurso Patient u Observation lleva habitualmente un nombre, un número de historia clínica y detalle clínico — información sanitaria protegida bajo HIPAA. Subir ese JSON a un validador en servidor, por bien intencionado que sea, crea el tipo de riesgo de intercambio de datos que normalmente exigiría un acuerdo de asociado comercial. Como este validador se ejecuta por completo en el motor JavaScript del navegador, un ingeniero de integración puede pegar un recurso real (no solo sintético) mientras depura una interfaz en producción y saber que la PHI que contiene nunca salió de su máquina — sin llamadas de red, sin registro, nada que declarar en una revisión de seguridad.
Este validador es una etapa de un flujo de migración v2 a FHIR más amplio. Convierte un mensaje HL7 v2 en bruto con el Conversor HL7 v2 a FHIR, y luego valida el recurso resultante aquí antes de que llegue a un servidor. Si el mensaje v2 original necesita antes una inspección más detallada — por ejemplo para confirmar qué segmentos y campos leyó realmente el conversor — el Visor HL7 renderiza el mismo mensaje como un árbol estructurado y nombrado. Encadenar las tres herramientas convierte "¿funciona mi recurso FHIR mapeado?" en una comprobación rápida, privada y en tres pasos.
No. El recurso se analiza y valida por completo en tu navegador. Los recursos FHIR a menudo contienen información médica protegida como nombres de pacientes y detalles clínicos, así que mantener todo en el cliente evita un riesgo de cumplimiento. Puedes confirmar que no hay subida mirando la pestaña de red de tu navegador al validar.
Valida contra FHIR R4, la versión más desplegada y el objetivo de la mayoría de las integraciones actuales. Las comprobaciones cubren campos obligatorios, cardinalidad, formatos de tipo de dato primitivo y bindings de value set obligatorios para los tipos de recurso soportados.
El validador soporta los tipos más comunes, incluidos Patient, Observation, DiagnosticReport, Bundle, Encounter, Condition, MedicationRequest y Practitioner. Otros tipos de recurso se aceptan pero reciben solo una comprobación básica de resourceType, con una nota de que la validación más profunda no aplica.
Un error significa que el recurso viola una regla y un servidor FHIR probablemente lo rechazaría — un campo obligatorio que falta, un tipo de dato erróneo o un código fuera de un value set obligatorio. Una advertencia señala algo sospechoso pero técnicamente permitido, como un CodeableConcept sin coding ni text. Los errores son bloqueantes; las advertencias son avisos para revisar.
Sí. Cuando validas un Bundle, cada recurso contenido en sus entradas también se valida. Los problemas se informan con su ruta completa dentro del Bundle, por ejemplo Bundle.entry[2].resource.Observation.status, para que localices un problema en un payload grande con precisión.
El validador oficial de HL7 es la herramienta autorizada para pruebas formales de conformidad, pero requiere un entorno Java y configuración. Esta herramienta es una comprobación estructural rápida en el navegador para el caso común, sin configuración y con total privacidad. Usa esta para iterar rápido y el validador oficial para la certificación formal contra una guía de implementación.
Tras convertir un mensaje HL7 v2 a FHIR, puedes pegar aquí el recurso resultante para confirmar que es estructuralmente válido antes de enviarlo a un servidor. La herramienta enlaza con el Conversor HL7 v2 a FHIR para que te muevas entre conversión y validación en un flujo privado.
Sí, completamente gratuito sin registro, sin límites de subida y sin anuncios. La validación estructural, las comprobaciones de value set, el informe de errores a nivel de ruta y la validación recursiva de Bundle están todas disponibles sin coste, con cada operación ejecutándose de forma privada en tu navegador.
No. Comprueba la estructura FHIR R4 base, la cardinalidad y los value sets para los tipos de recurso soportados, no un perfil como US Core o una extensión nacional. Un recurso puede superar las comprobaciones de este validador y aun así fallar un perfil US Core que exija elementos must-support adicionales o bindings de value set más estrictos. Úsalo como primera comprobación rápida, y un validador consciente de perfiles para la conformidad formal con una guía de implementación.
La herramienta igualmente analiza el JSON y comprueba que resourceType esté presente y la estructura sea JSON válido, pero no ejecuta las comprobaciones más profundas de campos obligatorios, cardinalidad o value sets reservadas a los ocho tipos totalmente soportados. La tabla de problemas indica cuándo un tipo de recurso cae en esta categoría de comprobación básica, para que no trates un resultado limpio como una validación completa.
Un Bundle FHIR empaqueta recursos en un solo JSON. Conoce los nueve tipos, la estructura de entry, fullUrl y request, y cuándo se usa cada uno.
Leer más →
Abre un .ndjson de una exportación masiva FHIR sin pelearte con el editor: qué es NDJSON, qué hacer con una línea rota y cómo leer los ficheros por tipo.
Leer más →
Referencias relativas, absolutas, urn:uuid y contained en FHIR: cómo se resuelven, cómo las reescribe una transacción y por qué las no resueltas rompen todo.
Leer más →
Checklist práctico para inspeccionar un Bundle FHIR que te han enviado: qué mirar primero, cómo seguir las referencias y cómo detectar las no resueltas.
Leer más →
Resuelve fallos de bundles de transacción FHIR: direccionamiento urn:uuid y fullUrl, semántica de entry.request, referencias sin resolver y orden de entradas.
Leer más →
Cómo funciona FHIR Bulk Data: la petición $export, el sondeo asíncrono, el manifiesto de salida y por qué se devuelven ficheros NDJSON y no un Bundle gigante.
Leer más →
Convierte un Bundle FHIR en un CSV limpio: por qué aplanar es difícil, unir o expandir repeticiones, elegir columnas y abrirlo en Excel sin estropearlo.
Leer más →
Introducción práctica a FHIR para TI sanitaria: qué son los recursos, cómo funciona R4, y cómo se compara con HL7 v2 antes de validar y enviarlos.
Leer más →