Pega un Bundle FHIR, un recurso individual o el NDJSON de una exportación Bulk Data en la casilla de entrada. También puedes subir o soltar un archivo .json o .ndjson. El formato se detecta automáticamente, así que no tienes que indicar cuál de ellos tienes delante.
Lee la línea de resumen. Indica cuántos recursos se han encontrado, qué formato se ha detectado y un recuento por tipo de recurso, además de cualquier problema de análisis con el número de línea donde se produjo.
Usa la pestaña de árbol para navegar. Filtra por tipo de recurso o busca en todos los valores, despliega un recurso para ver sus campos y haz clic en una referencia como Patient/pt-1 para saltar directamente al recurso al que apunta.
Cambia a la pestaña de tabla para aplanar un tipo de recurso en filas y columnas. Elige si los valores repetidos se unen con punto y coma o se expanden a una fila cada uno, alterna entre columnas preseleccionadas y todas las columnas, y descarga el resultado en CSV.
Acepta un recurso Bundle, un recurso suelto que no viene envuelto en ningún Bundle y NDJSON procedente de una exportación FHIR Bulk Data, donde cada línea es un recurso independiente. También acepta un array JSON de recursos, que es lo que obtienes al colapsar una exportación NDJSON con una herramienta como jq.
Cada referencia de los datos se indexa y se casa contra los recursos que has aportado, tanto si está escrita como Patient/123, como un urn:uuid que apunta al fullUrl de una entrada, o como una URL absoluta terminada en el mismo tipo e id. Las referencias resueltas se vuelven clicables; las que apuntan fuera de tus datos se muestran como no resueltas en lugar de descartarse en silencio.
Los índices de array se colapsan, de modo que todos los valores de un campo repetido caen en una única columna. Por defecto cada recurso es una fila y las repeticiones se unen con punto y coma; en modo expandido cada repetición pasa a ser su propia fila, y las columnas de valor único se repiten hacia abajo para que cada fila siga siendo legible por sí sola.
Nueve tipos de recurso habituales tienen columnas curadas, filtradas a las rutas que realmente aparecen en tus datos, así que nunca ves una columna entera de celdas vacías. Cualquier otro tipo de recurso obtiene columnas derivadas de las rutas más pobladas de lo que has pegado, y un solo interruptor revela todas las rutas descubiertas.
Solo la porción visible de las filas de la tabla se mantiene en el DOM, así que una tabla de miles de filas se desplaza sin bloquear la pestaña. La entrada está limitada a 25 MB y 20.000 recursos, y cuando se alcanza un límite la herramienta indica exactamente cuántos recursos se han descartado en lugar de truncar en silencio.
Un Bundle FHIR real es información de pacientes: nombres, identificadores, diagnósticos, medicación. Aquí todo se analiza localmente y nada se sube. Las referencias se resuelven contra los recursos que tú has aportado y jamás se piden a un servidor, así que ninguna parte de tu payload se escapa a través de una petición en segundo plano.
Cuando te llega un Bundle necesitas saber qué hay dentro y necesitas llevarte una parte a una hoja de cálculo. El árbol responde a lo primero y la tabla aplanada a lo segundo, ambas desde un único análisis, así que no acabas pegando el mismo payload en dos herramientas distintas.
Las exportaciones FHIR Bulk Data llegan como archivos NDJSON con miles de recursos por archivo, que es justo el caso en el que abrir el archivo a mano deja de ser realista. Esta herramienta lee NDJSON directamente, informa del número de línea de cualquier registro roto y conserva todas las líneas buenas en lugar de tumbar el archivo entero.
Las columnas curadas hacen legible la primera vista, pero siempre puedes cambiar a todas las rutas descubiertas, elegir tú las columnas y ver las referencias no resueltas y los problemas de análisis expuestos de forma explícita. La herramienta aspira a ser una lente rápida sobre tus datos, nunca un filtro con opinión propia que decide en silencio qué importa.
Un Bundle es el sobre de FHIR. En lugar de describir un hecho clínico, es un contenedor que transporta otros recursos, y el campo type te dice por qué se agruparon. Un searchset es la respuesta a una consulta contra un servidor FHIR. Un transaction es un conjunto de cambios que deben aplicarse juntos, y cada entrada lleva un request que indica si hay que hacer POST, PUT o DELETE. Un collection es simplemente una bolsa de recursos sin semántica de procesamiento. Un document es una composición fija y firmada. Las entradas viven bajo entry, cada una un objeto con un fullUrl opcional y un resource.
Los recursos de un Bundle no son filas independientes: forman un grafo. Una Observation apunta a su subject, un Encounter apunta al paciente y al proveedor del servicio, una Condition apunta a ambos. Ese puntero es una referencia, y FHIR permite escribirla de varias maneras. La más familiar es la referencia relativa del estilo Patient/pt-1, que nombra un tipo de recurso y un id. Dentro de los Bundle de tipo transaction, donde los recursos todavía no tienen id asignado por el servidor, las entradas se direccionan mediante un fullUrl con un valor urn:uuid:, y las referencias apuntan a ese urn. Las referencias también pueden ser URLs absolutas en un servidor al que quizá ni siquiera tengas acceso.
Este explorador construye una tabla de búsqueda a partir de todos los recursos que has aportado, indexada por su Type/id, por su id suelto, por su fullUrl y por el Type/id final de ese fullUrl. Después casa cada referencia de los datos contra esa tabla. Cuando hay coincidencia, la referencia se convierte en un enlace en el que puedes hacer clic, y el recurso destino registra que está referenciado desde el origen, de modo que puedes recorrer el grafo en ambos sentidos. Cuando no hay coincidencia — porque la referencia apunta a un recurso alojado en un servidor, o a una entrada que no se incluyó en la exportación — se informa como no resuelta. Esa distinción importa: una referencia no resuelta suele ser precisamente el fallo que estás persiguiendo, y una herramienta que la escondiera estaría escondiéndote el problema.
Y algo esencial: la resolución ocurre únicamente contra los datos que has pegado. Un Bundle es información sanitaria protegida, y una herramienta que dereferenciara https://ehr.example.org/fhir/Patient/123 para enseñarte una etiqueta más bonita estaría transmitiendo el contenido de tu payload a un tercero. Aquí no se realiza ninguna petición de red.
Los recursos FHIR son árboles profundamente anidados y las hojas de cálculo son rejillas planas. Convertir lo uno en lo otro siempre implica un intercambio, y la pregunta honesta es cuál estás aceptando. Piensa en un Patient con dos nombres de pila. En el JSON original los valores están en name[0].given[0] y name[0].given[1]. Un aplanado literal crearía dos columnas para esas dos posiciones — y una tercera en cuanto un paciente tenga un nombre intermedio, y una cuarta para el siguiente caso límite. Los recursos reales tienen alrededor de cuarenta rutas hoja, así que ese enfoque produce cientos de columnas dispersas y una hoja de cálculo que nadie puede usar.
Esta herramienta toma el otro camino: los índices de array se colapsan, así que ambos nombres de pila pertenecen a la columna name.given. Los valores se unen entonces en una sola celda, separados por punto y coma, o se expanden para que cada uno ocupe su propia fila. El modo unido mantiene la promesa de que una fila equivale a un recurso, que es lo que quieres al contar pacientes o al pivotar por género. El modo expandido mantiene la promesa de que una celda contiene un valor, que es lo que quieres cuando cada repetición es en sí misma la unidad de análisis — los componentes de una Observation de tensión arterial, o los codings de un diagnóstico. En modo expandido, las columnas de valor único se repiten hacia abajo por las filas generadas para que cada fila siga describiéndose a sí misma, en lugar de dejar el id del paciente en blanco en todas menos la primera.
Nueve tipos de recurso que dominan los bundles reales — Patient, Observation, Condition, Encounter, MedicationRequest, Procedure, AllergyIntolerance, Immunization y DiagnosticReport — tienen conjuntos de columnas escogidos a mano que cubren los campos que la gente analiza de verdad. Esos presets se filtran después contra tus datos, así que si ninguno de tus Patient lleva address no verás columnas de dirección vacías. Para cualquier otro tipo de recurso, y para un tipo curado cuyo preset no encuentre nada, las columnas se derivan de tus datos: se cuenta cada ruta hoja entre los recursos de ese tipo y se muestran las doce rutas más pobladas. Así, un ResearchStudy o un Coverage siguen produciendo una tabla razonable sin que nadie tenga que mantener a mano un preset para los ciento cincuenta y pico tipos de recurso de la especificación.
Algunas claves se excluyen deliberadamente del aplanado porque añaden ruido en lugar de señal:
meta, con sus versionId, lastUpdated y perfiles, que rara vez interesa en un análisis tabular.text y el XHTML que lleva incrustado, que llenaría una celda con marcado.extension, cuyas rutas dependen de la guía de implementación y explotan el número de columnas.Si necesitas cualquiera de esas partes, la vista de árbol te muestra el recurso tal y como lo aportaste, sin recortes.
Cuando un servidor FHIR exporta una población entera en lugar de responder a una consulta, usa la especificación Bulk Data, y la salida no es un Bundle en absoluto. Es NDJSON: JSON delimitado por saltos de línea, un recurso completo por línea, normalmente un archivo por tipo de recurso. El formato existe porque una exportación de un millón de pacientes no puede sostenerse en memoria como un único documento JSON, y cada línea puede procesarse de forma independiente. Esa misma propiedad es la que permite a esta herramienta informar de una línea malformada por su número y conservar todas las demás, en vez de descartar una exportación completa porque un registro esté roto.
Es un explorador de solo lectura. No comprueba si tus recursos son conformes a FHIR — para eso está el Validador de Recursos FHIR, que verifica campos obligatorios, cardinalidad, tipos de datos y bindings de value set contra R4. No edita recursos ni los envía a ningún sitio. Y lee JSON, no XML, en línea con la forma en que se intercambia la inmensa mayoría del tráfico FHIR actual. Si tus datos nacieron como HL7 v2, el Conversor HL7 v2 a FHIR los convierte primero, y el resultado puede explorarse aquí.
No. El archivo se lee y se analiza por completo en tu navegador, y ninguna parte de él viaja por la red. Aquí esto importa más que en la mayoría de herramientas porque un Bundle suele contener información sanitaria protegida. Las referencias se resuelven únicamente contra los recursos que has aportado: la herramienta nunca pide un recurso referenciado a un servidor, lo que transmitiría tus datos. Puedes confirmarlo mirando la pestaña de red de tu navegador mientras exploras un bundle.
Cuatro, todos detectados automáticamente: un recurso Bundle, un recurso suelto que no viene envuelto en un Bundle, NDJSON donde cada línea es un recurso independiente, y un array JSON de recursos. Los dos últimos cubren las exportaciones FHIR Bulk Data y el resultado de colapsar una exportación así con una herramienta como jq.
Esa línea se informa como problema con su número de línea, y todas las demás se analizan igualmente. Una exportación masiva de miles de registros no se descarta porque uno esté malformado. Lo mismo aplica a una entrada de Bundle que no lleve un recurso utilizable: se omite con una advertencia y el resto del bundle se explora con normalidad.
Por defecto cada recurso se convierte en una fila y los valores repetidos se unen con punto y coma, así que un paciente con dos nombres de pila muestra Ada;Augusta en una sola celda. Al cambiar al modo expandido, cada valor repetido obtiene su propia fila y las columnas de valor único se repiten hacia abajo para que cada fila siga describiéndose a sí misma. Ningún modo descarta datos: se diferencian en si quieres una fila por recurso o un valor por celda.
Los tipos de recurso habituales arrancan con un conjunto curado de columnas para que la primera vista sea legible, y ese conjunto se filtra a las rutas que realmente aparecen en tus datos. Cambia el selector de columnas a mostrar todas y aparecerá cada ruta hoja descubierta. El bloque meta, el bloque narrativo text y las extensiones quedan fuera del aplanado por ruido; la vista de árbol muestra el recurso tal y como lo aportaste.
Lo deriva. Se cuenta cada ruta hoja entre los recursos de ese tipo presentes en tus datos, y las doce rutas más pobladas pasan a ser las columnas. Un ResearchStudy, un Coverage o un perfil propio siguen produciendo por tanto una tabla usable, y en cualquier momento puedes cambiar a todas las columnas.
Hasta cierto punto, y es explícita sobre ese punto. La entrada está limitada a 25 MB y 20.000 recursos. Cuando se alcanza un límite, el resumen indica cuántos recursos se han descartado en vez de truncar en silencio, así que nunca confundes una vista parcial con una completa. Las filas de la tabla se renderizan en una ventana móvil, de modo que desplazarse por miles de filas sigue siendo fluido.
Porque apuntan a algo que no está presente en los datos que has aportado, típicamente un recurso alojado en un servidor o una entrada que falta en la exportación. Se muestran en lugar de ocultarse porque una referencia no resuelta es con frecuencia el problema real que estás investigando, como un bundle de transaction que olvidó incluir un Practitioner referenciado.
No, y es una frontera deliberada. Esta herramienta responde a qué hay en el bundle y cómo me lo llevo a una hoja de cálculo. Si los recursos son conformes a FHIR R4 — campos obligatorios, cardinalidad, tipos de datos, value sets — lo responde el Validador de Recursos FHIR, que es una herramienta aparte en este mismo sitio.
Sí. Las celdas que empiezan por =, +, - o @ pueden ejecutarse como fórmulas en Excel, Google Sheets y LibreOffice, y los campos de texto de FHIR como el nombre de un paciente son influenciables por un atacante. La exportación antepone un tabulador a esas celdas para que el texto siga siendo legible pero nunca se evalúe, y aplica entrecomillado conforme a RFC 4180 en todo el archivo.
No, solo JSON. La inmensa mayoría del tráfico FHIR R4 actual se intercambia en JSON, y las exportaciones Bulk Data son JSON por especificación. Si tienes recursos en XML tendrás que convertirlos antes de explorarlos aquí.
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 JSON FHIR anidado en filas planas: rutas hoja, colapso de índices de array, una fila por recurso frente a un valor por celda y elección de columnas.
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 →