Los Holter registran uno o dos días de electrocardiograma continuo mientras el paciente hace vida normal. Durante años cada fabricante usó su propio formato, lo que dificultaba reunir datos de sistemas distintos. El formato estándar de salida Holter de ISHNE nació para resolver ese problema.
De Dónde Viene el Formato
Lo definió un grupo de trabajo de la International Society for Holter and Noninvasive Electrocardiology (ISHNE) tras varias reuniones con fabricantes de Holter, y Fabio Badilini lo publicó en Annals of Noninvasive Electrocardiology en 1998 con el objetivo declarado de equilibrar sencillez y flexibilidad. El Telemetric and Holter ECG Warehouse (THEW) de la Universidad de Rochester distribuye conjuntos de datos Holter para investigación en este formato, uno de los motivos por los que hoy se siguen encontrando archivos ISHNE.
Estructura del Archivo
Un registro ISHNE es un único archivo binario formado por cinco partes consecutivas:
- Número mágico (8 bytes): el texto ASCII
ISHNE1.0.
- Checksum (2 bytes): un valor CRC-CCITT que cubre la cabecera.
- Cabecera fija (512 bytes) con todos los campos descriptivos.
- Bloque de longitud variable: texto ASCII libre para comentarios, cuyo tamaño se declara en la cabecera.
- Bloque ECG: las muestras propiamente dichas.
Como 8 + 2 + 512 = 522, el bloque variable empieza normalmente en el byte 522 y el bloque ECG en 522 más el tamaño del bloque variable. La cabecera también guarda ambos desplazamientos de forma explícita, y el visor comprueba que coinciden.
La Cabecera Fija
La cabecera empieza con cuatro enteros de 4 bytes: tamaño del bloque variable, tamaño del ECG en muestras, desplazamiento del bloque variable y desplazamiento del bloque ECG. Después vienen la versión del archivo, el nombre, los apellidos y el identificador del sujeto, los códigos de sexo y raza, y tres fechas —nacimiento, registro y creación del archivo—, cada una como tres enteros cortos en orden europeo día-mes-año, seguidas de la hora de inicio en horas, minutos y segundos.
A continuación está la descripción de la señal: el número de derivaciones guardadas y tres tablas de doce valores. La especificación de derivación codifica su tipo (1 bipolar genérica, 2 a 4 bipolares X, Y y Z, 5 a 10 las derivaciones de miembros I a aVF, 11 a 16 las precordiales V1 a V6, 17 a 19 las derivaciones ES, AS y AI). La calidad de derivación va desde 1, buena calidad permanente, pasando por ruido intermitente o frecuente (2 y 3), hasta desconexión del electrodo por debajo o por encima del 10% (4 y 5). La resolución de amplitud indica cuántos nanovoltios representa una unidad digital. Las posiciones sin usar valen -9. La cabecera termina con el código de marcapasos (de 0, ninguno, a 5, bicameral bipolar), el tipo de grabadora, la frecuencia de muestreo en hercios y las zonas propietaria, de copyright y reservada.
El Checksum
Los dos bytes que siguen al número mágico contienen un checksum CRC-CCITT (polinomio x16+x12+x5+1, valor inicial 0xFFFF), un algoritmo tomado del estándar SCP-ECG. Cubre la cabecera desde el desplazamiento 10 hasta el byte anterior al bloque ECG, incluido el bloque de comentarios. Algunos programas nunca lo calculan, así que el visor informa de una discrepancia como aviso y sigue leyendo.
Cómo se Guardan las Muestras
El bloque ECG contiene enteros de 16 bits con signo en little-endian, multiplexados: una muestra de la derivación 1, una de la 2 y así hasta la derivación N, y luego la siguiente muestra de la derivación 1. Todas las derivaciones comparten frecuencia de muestreo, no hay compresión y el valor físico es el entero guardado multiplicado por la resolución de la derivación. Solo se contemplan registros continuos. El artículo original menciona una propuesta para reservar -32768 como indicador de fallo de electrodo, pero nunca fue una regla, así que el visor cuenta las muestras en ambos extremos y deja que las interpretes tú.
Sin compresión, los archivos son grandes pero fáciles de recorrer. Las cuentas del propio artículo: 24 horas de tres derivaciones ocupan unos 66 MB a 128 Hz, 103 MB a 200 Hz y 206 MB a 400 Hz. Por eso este visor nunca carga en memoria el bloque ECG completo.
El Archivo de Anotaciones
La versión 1.0 dejó fuera las anotaciones de latidos. Un formato complementario publicado por el proyecto THEW cubre ese hueco: número mágico ANN 1.0, exactamente la misma cabecera que el archivo ECG, la posición de la primera anotación en muestras (4 bytes) y después registros de 4 bytes. Cada registro contiene una etiqueta principal (N normal, V extrasístole ventricular, S latido prematuro o ectópico supraventricular, C pulso de calibración, B latido con bloqueo de rama, P estimulación, X artefacto, ! timeout, U desconocido), una etiqueta secundaria y las muestras transcurridas desde la anotación anterior como entero sin signo de 16 bits. Los huecos de más de 65.535 muestras se salvan con registros de timeout.
Como se guardan distancias y no instantes absolutos, un registro corrupto desplaza todos los latidos posteriores. Por eso el visor comprueba que las anotaciones no van más allá del final del ECG y que ambas cabeceras coinciden.
ISHNE Frente a EDF, WFDB, SCP-ECG y DICOM
- EDF y EDF+ usan una cabecera de texto, registros de datos de longitud fija y una frecuencia por señal, con las anotaciones de EDF+ dentro del mismo archivo. ISHNE es más limitado: solo ECG, una frecuencia y anotaciones en un segundo archivo.
- WFDB, el formato de PhysioNet, divide un registro en una cabecera de texto, archivos de señal con varias codificaciones y archivos de anotaciones aparte con un juego de etiquetas más rico.
- SCP-ECG está orientado sobre todo a ECG de reposo cortos, organizados en secciones con compresión opcional.
- Los objetos de forma de onda DICOM incrustan las muestras de ECG en un conjunto de datos DICOM con todo el contexto de paciente y estudio, pensado para archivos hospitalarios.
Ambigüedades en Archivos Reales
La más frecuente afecta al campo de tamaño del ECG: unos programas guardan las muestras por derivación y otros el total de todas las derivaciones. El visor prueba ambas interpretaciones frente al tamaño del archivo y te dice cuál encaja. Otros problemas habituales son checksums que nunca se calcularon, posiciones de derivación sin usar que no valen -9 y registros cortados por una transferencia interrumpida.
Tres Escenarios Prácticos
Intercambio de datos de investigación. Un grupo recibe registros Holter de un repositorio de datos o de un centro colaborador. Antes de programar el análisis, un investigador confirma derivaciones, frecuencia de muestreo y duración, comprueba que hay anotaciones verosímiles y exporta la tabla de derivaciones para el diccionario de datos.
Revisar una exportación antes de enviarla a analizar. Un técnico de Holter verifica que la duración está completa, que ninguna derivación aparece como desconectada o muy saturada y que los campos de nombre ya no contienen datos identificativos que el acuerdo de cesión obliga a eliminar.
Depurar un conversor. Quien programa un exportador ISHNE ve señalados los errores típicos: un checksum calculado sobre el rango de bytes equivocado, un tamaño de bloque variable que no cuadra con el desplazamiento del ECG, un tamaño de ECG que no encaja con ninguna interpretación o distancias de anotación más largas que el registro. Las muestras escritas con el orden de bytes equivocado se ven al momento como ruido y estadísticas inverosímiles.
Cuándo No Usar Esta Herramienta
No la uses para leer un Holter con fines clínicos: no detecta latidos, no clasifica arritmias, no mide el segmento ST ni genera un informe Holter, y sus cifras de VFC valen lo que valgan las anotaciones cargadas. La VFC de un fragmento corto no es comparable con los valores de 24 horas descritos en 1996 por el Task Force de la Sociedad Europea de Cardiología y la North American Society of Pacing and Electrophysiology. Para diagnosticar usa software Holter certificado; para cientos de archivos, una librería de scripts.
