Holter monitors record one or two days of continuous electrocardiogram while a patient goes about normal life. For years every manufacturer stored those recordings in its own proprietary format, which made it hard for researchers to pool data from different systems. The ISHNE Holter Standard Output File Format was created to solve that problem.
Where the Format Comes From
The format was defined by a task force of the International Society for Holter and Noninvasive Electrocardiology (ISHNE) after meetings with Holter manufacturers, and published by Fabio Badilini in the Annals of Noninvasive Electrocardiology in 1998, with the stated aim of balancing simplicity and flexibility. The Telemetric and Holter ECG Warehouse (THEW) at the University of Rochester distributes research Holter datasets in this format, one of the main reasons researchers still meet ISHNE files today.
File Layout
An ISHNE recording is a single binary file made of five consecutive parts:
- Magic number (8 bytes): the ASCII text
ISHNE1.0.
- Checksum (2 bytes): a CRC-CCITT value covering the header.
- Fixed header (512 bytes) with all the descriptive fields.
- Variable-length block: free ASCII text for comments, whose size is declared in the header.
- ECG block: the samples themselves.
Because 8 + 2 + 512 = 522, the variable block normally starts at byte 522 and the ECG block at 522 plus the size of the variable block. The header also stores both offsets explicitly, and this viewer checks that they agree.
The Fixed Header
The header begins with four 4-byte integers: variable block size, ECG size in samples, offset of the variable block and offset of the ECG block. Then come the file version, the subject's first name, last name and ID, sex and race codes, and three dates — birth, recording and file creation — each stored as three short integers in European day-month-year order, followed by the start time as hour, minute and second.
The signal description follows: the number of stored leads and three arrays of twelve values. The lead specification codes the lead type (1 generic bipolar, 2 to 4 bipolar X, Y and Z, 5 to 10 the limb leads I to aVF, 11 to 16 the precordial leads V1 to V6, 17 to 19 the ES, AS and AI leads). The lead quality goes from 1, good quality permanently, through intermittent or frequent noise (2 and 3) to lead disconnection below or above 10% (4 and 5). The amplitude resolution gives how many nanovolts one digital unit represents. Unused slots are set to -9. The header ends with a pacemaker code (0 none to 5 dual chamber bipolar), the recorder type, the sampling rate in hertz and proprietary, copyright and reserved areas.
The Checksum
The two bytes after the magic number hold a CRC-CCITT checksum (polynomial x16+x12+x5+1, preset 0xFFFF), an algorithm taken from the SCP-ECG standard. It covers the header from offset 10 up to the byte before the ECG block, including the comment block. Some writers never compute it, so this viewer reports a mismatch as a warning and keeps reading.
How the Samples Are Stored
The ECG block contains signed 16-bit little-endian integers, multiplexed: one sample of lead 1, one of lead 2 and so on up to lead N, then the next sample of lead 1. All leads share one sampling rate, there is no compression, and a physical value is simply the stored integer multiplied by the lead's resolution. Only continuous recordings are covered. The original paper mentions a proposal to reserve -32768 as a lead-fault flag, but it was never a rule, so the viewer counts samples at both extremes and leaves the interpretation to you.
No compression means large but easily seekable files. The paper's own arithmetic: 24 hours of three leads take about 66 MB at 128 Hz, 103 MB at 200 Hz and 206 MB at 400 Hz. That is why this viewer never loads the whole ECG block into memory.
The Annotation File
Version 1.0 left beat annotations out. A companion format published by the THEW project fills the gap: magic number ANN 1.0, exactly the same header as the ECG file, a 4-byte position of the first annotation in samples, then 4-byte records. Each record holds a primary label (N normal, V premature ventricular contraction, S supraventricular premature or ectopic beat, C calibration pulse, B bundle branch block beat, P pace, X artefact, ! timeout, U unknown), a secondary label, and the samples elapsed since the previous annotation as an unsigned 16-bit value. Gaps longer than 65,535 samples are bridged with timeout records.
Because records store distances rather than absolute times, one corrupted record shifts every later beat. That is why the viewer checks that the annotations do not run past the end of the ECG and that both headers match.
ISHNE Compared With EDF, WFDB, SCP-ECG and DICOM
- EDF and EDF+ use a text header, fixed-length data records and a sample rate per signal, with EDF+ annotations inside the same file. ISHNE is narrower: ECG only, one rate, annotations in a second file.
- WFDB, PhysioNet's format, splits a record into a text header, signal files in several encodings and separate annotation files with a richer label set.
- SCP-ECG is aimed mainly at short resting ECGs, organised in sections with optional compression.
- DICOM waveform objects embed ECG samples in a DICOM dataset with full patient and study context, suited to hospital archives.
Ambiguities in Real Files
The most frequent concerns the ECG size field: some writers store samples per lead, others the total across all leads. The viewer tests both against the file size and tells you which matches. Other recurring issues are checksums that were never computed, unused lead slots not set to -9, and recordings cut short by an interrupted transfer.
Three Practical Scenarios
Research data exchange. A group receives Holter recordings from a data warehouse or partner centre. Before writing analysis code, an investigator confirms lead configuration, sampling rate and duration, checks that annotation files are present and plausible, and exports the leads table for the data dictionary.
Checking an export before sending it for analysis. A Holter technician verifies that the duration is complete, that no lead is flagged as disconnected or heavily saturated, and that the name fields no longer contain identifying data the sharing agreement says must be removed.
Debugging a converter. An engineer writing an ISHNE exporter gets pointed straight at typical mistakes: a checksum over the wrong byte range, a variable-block size that does not match the ECG offset, an ECG size matching neither interpretation, or annotation distances longer than the recording. Samples in the wrong byte order show up at once as noise and implausible lead statistics.
When Not to Use This Tool
Do not use it to read a Holter for clinical purposes: it does not detect beats, classify arrhythmias, measure ST segments or produce a Holter report, and its HRV figures are only as good as the annotations you load. HRV from a short excerpt is not comparable with the 24-hour values described by the 1996 Task Force of the European Society of Cardiology and the North American Society of Pacing and Electrophysiology. For diagnosis use certified Holter software; for hundreds of files, a scripting library.
