Pega EDI arriba o carga un ejemplo para ver la estructura analizada.
🔒 Analizado por completo en tu navegador. No se sube ningún EDI ni PHI.
Pega un intercambio X12 — un sobre ISA/GS completo o una sola transacción ST/SE — en el cuadro de entrada, o abre un archivo .edi/.txt/.835/.837 con el botón de archivo.
El visor detecta los delimitadores desde la cabecera ISA (o usa el conjunto convencional * : ~ por defecto) y analiza al instante mientras escribes.
Consulta el resumen para ver el emisor/receptor del intercambio, el número de control, los delimitadores y un recuento de transacciones por tipo (p. ej. 837×2).
Despliega cada transacción para ver sus segmentos, cada uno desglosado en elementos nombrados y numerados, con los sub-elementos compuestos separados (por ejemplo, CLM05 mostrado como 11 : B : 1).
Carga uno de los ejemplos integrados (reclamación 837, remesa 835, elegibilidad 270) para ver la estructura sin pegar tus propios datos.
Analiza reclamaciones 837 profesionales e institucionales y avisos de remesa 835 (ERA) con la misma herramienta, además de transacciones de elegibilidad como 270/271. Los segmentos se agrupan automáticamente en sus transacciones ST/SE.
Los segmentos conocidos (CLM, SVC, CLP, CAS, NM1 y decenas más) se etiquetan con nombres legibles, y cada elemento se numera (NM101, NM102…) con los sub-elementos compuestos separados por el delimitador de componente.
Los delimitadores de elemento, componente y segmento se leen directamente de la cabecera ISA de ancho fijo, de modo que los archivos con separadores no estándar se analizan correctamente sin configuración.
El analizador señala problemas estructurales — un SE sin su ST, una transacción abierta sin SE de cierre, o un segundo ST antes de cerrar el anterior — para detectar errores de sobre rápidamente.
Todo se analiza en tu navegador sin subidas. Como la información sanitaria protegida de una reclamación nunca sale de tu máquina, el visor es seguro para depurar archivos reales de pagadores.
Los archivos de reclamación y remesa contienen habitualmente información sanitaria protegida — nombres de pacientes, números de afiliado, códigos de diagnóstico y de procedimiento. Este visor analiza todo localmente en JavaScript, así que ninguno de esos datos se sube, registra ni almacena. Eso lo hace seguro para inspeccionar un 837 o un 835 real durante una investigación de facturación sin acuerdo de asociado comercial ni riesgo de exposición, y sigue funcionando en una máquina restringida o sin conexión.
En lugar de volcar un muro de texto delimitado por barras, el visor agrupa los segmentos en sus transacciones, nombra los que importan para reclamaciones y pagos, y separa los elementos compuestos para que un valor como un código de procedimiento con modificadores sea legible de un vistazo. Es justo lo que necesitas al conciliar un 835 con el 837 que lo originó, o al rastrear por qué una cámara de compensación rechazó un archivo.
La herramienta analiza fielmente la estructura X12 y nombra los segmentos conocidos, y señala problemas a nivel de sobre — pero no pretende ser un validador completo según la guía de implementación. Obtienes una inspección rápida y precisa de los bytes reales, que es lo que requiere la mayoría de la depuración EDI del día a día, sin una falsa confianza sobre el cumplimiento a nivel de bucle.
No hay cuenta, ni límite por archivo, ni espera de subida. Pega una transacción y se analiza de inmediato; carga un ejemplo integrado para aprender la estructura. Al ser una página estática, se abre al instante y puede guardarse en marcadores para la próxima vez que un archivo necesite un vistazo rápido.
ANSI ASC X12 es el estándar de intercambio electrónico de datos que sustenta la mayoría de las transacciones administrativas sanitarias electrónicas en Estados Unidos. Cuando un proveedor factura a un pagador, la reclamación viaja como un 837; cuando el pagador responde con el detalle de pago y ajustes, vuelve como un aviso de remesa 835, también llamado ERA (aviso de remesa electrónico). Saber leer estos archivos con rapidez es una competencia clave para analistas de facturación e ingenieros de integración, y empieza por entender la estructura del sobre.
Los datos X12 se envuelven en sobres anidados. El más externo es el intercambio, abierto por un segmento ISA y cerrado por IEA. El ISA es peculiar: es un segmento de ancho fijo de 106 caracteres, y su disposición es la que indica a un analizador qué delimitadores usa el archivo. Dentro del intercambio hay uno o más grupos funcionales, cada uno abierto por GS y cerrado por GE, que agrupan transacciones del mismo tipo. Dentro de un grupo están los conjuntos de transacciones, cada uno abierto por ST y cerrado por SE. El elemento ST01 lleva el tipo de transacción — 837 para una reclamación, 835 para remesa — y ST02 lleva un número de control que el SE correspondiente repite.
Dentro de una transacción, los datos se organizan en segmentos (un identificador de segmento seguido de elementos de datos) terminados por un delimitador de segmento, convencionalmente una tilde. Los elementos dentro de un segmento se separan por un delimitador de elemento, convencionalmente un asterisco, y los elementos compuestos se dividen a su vez en componentes por un delimitador de componente, convencionalmente dos puntos. Así, un segmento como CLM*CLAIM001*150.00***11:B:1*Y*A*Y*Y~ tiene el identificador CLM, un ID de reclamación en CLM01, un importe en CLM02 y un compuesto en CLM05 cuyos componentes son 11, B y 1. Los delimitadores reales se declaran en el ISA, por eso un buen visor los lee de la cabecera en lugar de suponerlos.
Un 837 describe quién factura, para qué paciente y suscriptor, y por qué servicios. Los segmentos clave incluyen BHT (inicio de la transacción jerárquica), segmentos HL que construyen la jerarquía proveedor facturador → suscriptor → paciente, segmentos de nombre NM1 que identifican a cada parte, CLM para la reclamación en sí, HI para los códigos de diagnóstico, y líneas de servicio como SV1 (profesional) o SV2 (institucional). Leer una reclamación consiste en gran medida en seguir la jerarquía HL y emparejar cada línea de servicio con sus cargos.
Un 835 explica cómo un pagador adjudicó las reclamaciones de un pago. El segmento BPR lleva el detalle financiero y del método de pago, TRN el número de rastreo usado para reasociar el ERA con el depósito real, CLP el pago a nivel de reclamación (importe facturado frente a pagado, responsabilidad del paciente, estado de la reclamación), y SVC el pago a nivel de línea de servicio. Los ajustes aparecen en segmentos CAS, que usan códigos de grupo de ajuste (como PR para responsabilidad del paciente o CO para obligación contractual) junto con los Claim Adjustment Reason Codes (CARC) y los Remittance Advice Remark Codes (RARC) para explicar exactamente por qué el importe pagado difiere del cargo. Conciliar significa emparejar cada CLP con el CLM de la reclamación 837 de origen y confirmar que cargos, pagos y ajustes cuadran.
La mayoría de los problemas de EDI son cuestiones estructurales o de conciliación. Un rechazo de la cámara de compensación suele deberse a un sobre mal formado — un SE que falta, un número de control que no coincide entre ST y SE, o un intercambio cuyo recuento de segmentos es incorrecto. Las discrepancias de pago normalmente se reducen a leer bien los ajustes CAS: una reclamación que pagó menos de lo esperado tendrá códigos de grupo y de motivo que explican el descuento o la responsabilidad del paciente. Poder abrir el archivo en bruto, ver los segmentos nombrados y los compuestos separados, y detectar una transacción sin cerrar de un vistazo convierte una búsqueda frustrante en texto delimitado por barras en una revisión rápida y metódica.
Un analista de facturación que investiga una línea pagada parcialmente empieza por el segmento CLP, compara CLP02 (el importe facturado) con CLP04 (el importe pagado) y luego lee cada segmento CAS asociado: el primer componente es el código de grupo de ajuste — PR para responsabilidad del paciente, CO para obligación contractual, OA para otro ajuste — seguido de un código de motivo y el importe ajustado. Una línea sintética como PR*1*45.00 junto a un servicio significa que el plan asignó 45 $ de responsabilidad del paciente bajo el motivo 1 (deducible), una lectura de segundos una vez que los segmentos están separados en lugar de contados a mano.
Una segunda tarea habitual es rastrear un rechazo de la cámara de compensación hasta su causa. Al pegar el 837 en bruto en el visor aparece de inmediato un aviso estructural — un ST sin su SE correspondiente, o un número de control en SE02 que no repite el de ST02 — que suele explicar el rechazo antes de examinar un solo elemento. Lo que de otro modo sería un recuento manual de ISA13, GE02 e IEA01 se convierte en un diagnóstico instantáneo.
Un tercer escenario es confirmar una comprobación de elegibilidad. Una solicitud 270 sintética y su respuesta 271 emparejada pueden pegarse una tras otra; emparejar el número de referencia BHT03 entre ambas y luego leer los códigos de elegibilidad y beneficios del segmento EB en el 271 confirma si la cobertura del paciente estaba activa en la fecha del servicio — una base útil cuando una reclamación se deniega después por un motivo de elegibilidad.
Este visor es un inspector estructural, no un motor de adjudicación de reclamaciones ni un validador certificado según la guía de implementación TR3. No te dirá si un código de procedimiento, un puntero de diagnóstico o un valor de lugar de servicio es válido para un pagador concreto, ni calcula el reembolso esperado ni comprueba los requisitos a nivel de bucle de la guía complementaria de un pagador. Tampoco redacta ni elimina la información sanitaria protegida que contiene una reclamación — el archivo se analiza, no se modifica — así que un 837 u 835 en bruto sigue necesitando el mismo cuidado de almacenamiento y eliminación después de cerrar la pestaña. Para certificar que se cumplen los requisitos de una guía de implementación, la herramienta adecuada es un validador específico compatible con TR3; el trabajo de este visor es hacer legibles los bytes en bruto en segundos, no certificar el cumplimiento.
El 837 y el 835 son dos de varios conjuntos de transacciones X12 exigidos por HIPAA que mueven datos entre proveedores y pagadores. Saber dónde encaja una transacción concreta ayuda cuando llega un archivo sin etiquetar:
| Transacción | Dirección | Propósito | Segmentos clave |
|---|---|---|---|
| 837 | Proveedor → Pagador | Reclamación sanitaria (837P profesional, 837I institucional) | CLM, HI, SV1/SV2 |
| 835 | Pagador → Proveedor | Aviso de remesa (ERA) | CLP, CAS, SVC |
| 270/271 | Proveedor ↔ Pagador | Consulta de elegibilidad / respuesta | EQ, EB |
| 276/277 | Proveedor ↔ Pagador | Consulta de estado de reclamación / respuesta | STC |
Las definiciones completas de cada conjunto de transacciones y los identificadores de versión (como 005010X222A1 para el 837P) los mantiene ASC X12, y CMS los referencia como los estándares HIPAA adoptados.
Cada 837 lleva el nombre de un paciente, su número de afiliado y códigos de diagnóstico o procedimiento; cada 835 lleva al mismo paciente vinculado a un importe pagado. Bajo HIPAA, esos campos son información sanitaria protegida, y enviarlos a través de un servicio web de terceros normalmente requeriría un acuerdo de asociado comercial. Como este visor analiza el archivo por completo en el motor JavaScript del propio navegador — sin llamadas de red, sin ida y vuelta al servidor, nada que lea el texto pegado salvo tu propia máquina — un analista de facturación puede abrir un archivo real de un pagador en un puesto restringido o un portátil sin conexión, y la información sanitaria protegida que contiene nunca sale de ese dispositivo. Esa es la diferencia práctica entre una herramienta segura solo con datos sintéticos y una construida para manejar archivos de producción reales.
Un puntero de diagnóstico de un 837 en el segmento HI hace referencia a un código ICD-10-CM, que puedes confirmar directamente en el buscador de ICD-10-CM para comprobar que la descripción del código coincide con el servicio facturado. Si necesitas compartir un extracto de una reclamación o remesa con un compañero o un ticket de soporte, pega antes ese mismo texto en el identificador de PHI HIPAA — analiza archivos de texto plano, incluido EDI, en busca de nombres, números de afiliado y fechas expuestos antes de que nada salga de tus manos. Juntas, las tres herramientas cubren el ciclo habitual de una investigación EDI: leer la transacción, verificar los códigos a los que hace referencia y confirmar que no queda información sanitaria protegida en lo que exportes o reenvíes.
Cualquier intercambio ANSI ASC X12, con foco en transacciones sanitarias: reclamaciones 837 profesionales e institucionales, avisos de remesa 835 (ERA) y transacciones de elegibilidad como 270/271. Puedes pegar un sobre ISA/GS completo o solo una transacción ST/SE.
No. Todo el análisis ocurre localmente en tu navegador con JavaScript. El archivo que pegas o abres — incluida cualquier información sanitaria protegida que contenga — nunca se sube, guarda ni transmite a ningún servidor.
Los lee de la cabecera ISA de ancho fijo, donde se definen los delimitadores de elemento, componente y segmento. Si no hay ISA (por ejemplo al pegar un fragmento de una sola transacción), usa por defecto el asterisco, los dos puntos y la tilde convencionales.
No del todo. Analiza fielmente la estructura, nombra los segmentos conocidos, separa los elementos compuestos y señala problemas de sobre como una transacción sin cerrar — pero no realiza una validación completa de bucles y conjuntos de códigos según la guía TR3. Es una ayuda de inspección y depuración, no un validador certificado.
Sí. Al desglosar los segmentos de pago CLP y SVC y los ajustes CAS del 835, y el CLM y las líneas de servicio del 837, el visor facilita emparejar reclamaciones por número de control y ver cómo se relacionan cargos, pagos y ajustes.
Un elemento compuesto agrupa varios valores relacionados en un solo elemento, separados por el delimitador de componente. El visor los separa para que cada componente sea visible. Lo que significa cada componente depende del segmento y la posición — por ejemplo, un compuesto de lugar de servicio o un código de procedimiento con modificadores.
Sí. Una vez cargada la página, no se necesita conexión. Al ser una página estática con todo el análisis en el cliente, puedes usarla en una máquina restringida o aislada donde no se permitiría subir un archivo de reclamación.
No. Es una herramienta administrativa y de facturación para leer la estructura del EDI. No es un sistema clínico y nunca debe usarse para diagnóstico, tratamiento ni ninguna decisión de atención al paciente.
No. Analiza y nombra la estructura X12 — segmentos, elementos y compuestos — pero no busca códigos de procedimiento o diagnóstico en un catálogo oficial. Combínalo con un buscador de códigos dedicado, como un lector de ICD-10-CM, para confirmar que un código referenciado en un segmento HI o SV1 es válido y está vigente.
Revisa los segmentos CAS asociados a esa línea de servicio. Un pago de 0 $ casi siempre viene con códigos de motivo de ajuste que explican el descuento total — por ejemplo un código de grupo CO (obligación contractual) junto con un motivo de servicio no cubierto, o un importe PR (responsabilidad del paciente) igual al cargo completo. El visor muestra los segmentos CAS justo junto a las líneas CLP/SVC que ajustan, así que el motivo es visible sin cruzar una lista de códigos aparte.
Guía práctica de la reclamación X12 837 y la remesa 835 (ERA): qué contiene cada una, cómo se concilian y cómo leer los segmentos que importan.
Leer más →