5 How to Create an SCP-ECG Record

The following text will give a brief overview on how to build up an SCP-ECG record by describing the creation and filling of the sections according to the standard.

5.1 CRC-Checksum

This CRC checksum has to be built according to the CCITT standard over the entire record excluding the two checksum bytes.

5.2 Record length

The record length is the number of bytes of the entire SCP-ECG record including the two-checksum bytes. The length is to be given in four unsigned bytes.

Note: The SCP standard does allow for a binary multi-byte sequence in ascending order of significance (the least significant byte is transmitted first, the most significant byte last).

5.3 Section 0 (Pointer section)

The pointer section represents essentially the table of contents of the SCP-ECG record under consideration.

As mentioned before, the standard allows for high flexibility in data acquisition and data formatting, as well as in providing measurement and interpretation results.

To allow the interchange of SCP records from different sources (e.g. devices from different manufacturers), within each record itself details of its structure must be given.

The pointer section is therefore a useful means to identify what the content of a transmitted SCP record will be.

5.4 Section 1 (Header)

The header section is structured in up to 35 different tags.

The header section carries the following essential information:

• Patient ID (Names, ID number, age, date of birth, height, weight, sex, ...).
• Drugs and referral information.
• Acquiring and Analysing device information.
• An ECG sequence number, in case of repeated recordings.
• ...
• ...
• ...
• Free text medical history.

For details the reader is referred to clause 5.4 of the SCP standard document.

5.5 Section 2 (Huffman tables/Encoding of ECG data)

Within this section information is contained about which way the ECG data are encoded as part of this specific SCP-ECG record (section 5 and section 6).

Section 2 is not mandatory and when present it states that the ECG signal in section 5 and 6 (if they exist) was also Huffman coded (entropy encoded).

The following options exists:

• No ECG data are contained at all;
• Original ECG raw data are provided;
• There either the original binary data or Huffman encoded data are stored - for more details see text on sections five and six.

Which of these options holds for the SCP record under consideration is specified by the settings in a few bytes of this section 2 (see clause 5.5 of the SCP standard).

ECG raw data are provided in section 6 and Huffman tables for entropy dependent encoding may be used according to the settings in section 2 as described above. This type of encoding allows the transmission of the original ECG data (lossless compression) by dense bit packing. Data are "mapped" to Huffman codes according to the frequency of their occurrence.

Huffman codes are typically designed on the basis of the signal statistics.

Research performed during development of the SCP compression has shown that compression efficiency is not significantly reduced if a standard set of Huffman codes ("Default Huffman table") is used for all of the usually acquired ECGs.

5.6 Section 3 (ECG lead definition)

The SCP standard allows an SCP-ECG record to include data from 1, .., 255 leads. The standard contains a code list for all common leads as well as for specific lead sets.

This specification also contains information about whether leads are recorded simultaneously or sequentially. Finally, in section 3 the length of the recording for each of the leads is contained by specifying the starting and ending sample number.

The standard specifies that the lead data are sequentially ordered.

For details the reader is referred to clause 5.6 of the SCP standard document.

====================================================================

Intermediate summary

Considering the explanations given so far it is possible to build the record length information (by means of the CRC check) and, by using sections 0, 1, (2), 3 and 6, a fully interoperable SCP-ECG record. Apart from all demographic patient information, this record would contain the device and recording ID and the ECG raw data without any processing of the ECG signal itself. Only if some compression by Huffman entropy encoding is desired do the data need to be processed accordingly.

• Filling sections 4, 5, 7, and all others requires gradually increasing more ECG analysis.
• For filling section 4 an algorithm for ECG beat detection and beat typing is required.
• For filling section 7 additionally a measurement algorithm is necessary.
• For filling section 8 additionally a diagnostic classification algorithm must be applied.
• Filling section 10 requires that the measurement algorithm also provides detailed measurements per lead.
• And filling section 11 requires an algorithm that maps the diagnostic classification statements onto the codes given in informative appendix D of the SCP standard document.

Please note: If a well designed format checker is implemented on the SCP record receiver site and if the record "identifying" information (sections 0, 1, 2) is correct, SCP records will be "understandable" and representable by any system regardless of which options for data encoding have been selected.

====================================================================

====================================================================

SCP-ECG data compression options

To understand better the explanations for sections 4, 5 and 6 we will now briefly describe the three ECG data compression methods proposed within this standard.

The first method is to compress the original binary raw data by Huffman entropy encoding as mentioned in section 2. This encoding procedure removes to some extent the empty bits within the ECG samples. The ECG data compression will be low (often less than.2:1).

The second method takes advantage of the intersample correlation by computing first or second order sample differences. Subsequently these differences may be Huffman encoded. Compression ratios of 3..4 may be achieved.

Please note: neither of the above described compression procedures require any specific ECG waveform analysis and both enable the exact reconstruction of the ECG signal lossless compression!

The third method requires some analysis of the ECG signal, in particular the beat localization and beat typing. In most cases the ECG is a quasi-stationary time series with repetitive ECG cycles. In this situation it is possible to calculate a so called "reference beat" as the median or average of the most frequent ECG cycles.

It is then possible to subtract this reference beat at all locations where a beat has been detected within the ECG record (a precise beat alignment is necessary). As a result the residual data record has only very small amplitudes in all samples. By then computing second differences and performing Huffman encoding, compression ratios of more than 30 may be obtained.

Measurements and diagnostic classification are performed on the reference beat. This reference beat is for reconstruction of a raw data ECG record stored with redundancy reduction only (in section 5). The residual data are sample decimated and somewhat truncated outside the region of the detected (and subtracted) QRS complex. The text and figures below from ANNEX C of the standard illustrate this method of data compression. In extensive studies during the European AIM R&D project "Standard Communication Protocol for Standard Computerized Electrocardiography" the details of this compression method were investigated. The results showed that even small clinically relevant details (e.g. distinction between atrial fibrillation and flutter) can be preserved.

For illustration of the high compression method, the following figures are taken from ANNEX C of the standard document:

Principles of "HIGH" SCP-ECG data compression

Original ECG - "raw data"

1. Locate a reference point inside all ECG complexes, e.g. the time of QRSmax or any other marker

   ==> Fiducials for Reference Beat subtraction (see fc1 to fc7 in figure below)

2. Identify ECG complex types, i.e. normal type, different extrasystoles

   ==> QRS-type 0, 1, etc.

Reference Beat 0

1. Compute the "Reference Beat Type 0", e.g. representative Average Cycle, Median Cycle, Modal Beat, ...
2. Identify the wave onsets and offsets of the Reference Beat 0

   ==> length of the Reference Beat 0 to be subtracted

   ==> pointers for QRS data segments p (see figure C.3, C.4) to be protected from filtering and decimation.

Residual Record

Subtract the Reference Beat Type 0 from all ECG complexes of type 0 using the fiducial locations

Compressed data

1. Low pass filtering of the residual record (excluding the protected areas p)
2. Sample decimation 2 ms -> 8 ms (excluding the protected areas p)
3. Compute 2nd successive differences on all the resulting data.

Residual Record

Encoding

The second successive differences are then Huffman encoded - see numerical examples in Annex C of the standard.

Minimum requirements for ECG data encoding and compression

Based upon the results from the investigations in the SCP-ECG Project the following quantization and error limits have been chosen as standard for digital ECG encoding and compression:

• If reference beat subtraction is used for data compression, all leads of an ECG record shall be recorded simultaneously.
• Digitization: SR > 500 samples/s; LSB < 5 microV
• Reference Beat: SR > 500 samples/s; LSB < 5 microV
• Residual Record: Truncation Error < ±15 microV
• Residual Record: Sampling Interval < 8 ms
• Reconstruction Error: RMS < 10 microV
• Absolute Error: < 100 microV in a single sample outside P-QRS-T
• Absolute Error within QRS: < 15 microV in a single sample

Decompression of SCP-ECG data

For decompression of the ECG data the steps of compression are generally performed backwards. If "high compression" is used, the steps (a) and (b) described below have to be performed on the Residual Record and the Representative Beat 0. Steps (c) and (d) apply to the Residual Record only, whereas (e) and (f) apply to both the Representative Beat 0 and the Residual Record.

The steps of decompression are:

1. Decoding with Huffman tables.
2. Reconstitution of the data from the first or second differences.
3. Reconstitution of decimated samples.
4. Low pass filtering of the reconstructed Residual Record outside protected areas.
5. Multiplication with AVM (the amplitude value modifier).
6. In case of high compression: addition of the Representative Beat 0 to the Residual Record at all complex type 0 locations. For this the stored pointers fc(k), SB(k) and SE(k) of the Residual Record and fcM of the Reference Beat 0 shall be used.

====================================================================

5.7 Section 4 (QRS locations)

The section has been introduced to store QRS locations and beat annotation information.

Section 4 contains for each beat:

• The beat type.
• Pointers to QRS onset and QRS offset of each beat.

This information is necessary for each beat of type 0 (= dominant beat type) if reference beat subtraction is performed:

• Pointers to start and end of subtraction of the reference beat.
• Fiducial point information (e.g. QRSmax).

Obviously this section must be present if "high" compression is used for encoding ECG data. If this SCP section is present it must be filled according to clause 5.7 of the SCP standard document.

5.8 Section 5 (Encoded reference beat data)

The reference beat data section contains the encoded reference beat data in lead-order and information on how the data are encoded:

• The amplitude value multiplier (AVM) must be present to reconstitute the correct amplitude values of the waveforms.
• The sample time interval contains information about the sample frequency.
• The encoding information identifies the switches between original data, first differences or second differences encoding.

When "high" compression is used for encoding ECG data this SCP section must be present and must be filled according to clause 5.8 of the SCP standard document.

5.9 Section 6 (Rhythm/Residual data)

The rhythm/residual data section contains the encoded ECG data without reference beat subtraction (rhythm data) or with reference beat subtraction (residual data) in lead-order and information of how the data are encoded:

• The amplitude value multiplier (AVM) must be present to reconstitute the correct amplitude values of the waveforms.
• The sample time interval contains information about the sample frequency.
• The encoding information identifies the switches between original data, first differences or second differences encoding.
• There is also a switch to select options for compression with or without sample decimation. (Note: As described above the data regions containing QRS complexes are only redundancy reduced and the sampling rate of the original data is maintained. The procedure of applying different sampling rates within the rhythm data section is called "bimodal compression").

If compressed or non-compressed ECG data records are to be transmitted, section 6 must be present and must be filled according to clause 5.9 of the SCP standard document.

5.10 Section 7 (Global measurements)

For filling section 7 additionally a measurement algorithm is necessary.

The global measurements section contains:

• Flag to indicate if global measurements are present for each reference beat type or for reference beat type 0 and all the complexes in the ECG signal.
• Number of pacemaker spikes.
• Average PP and RR.
• Pointers to P onset, P offset; QRS onset, QRS offset; T offset and angular measurements for P, QRS, and T for reference beats or for reference beat 0 and all the complexes according to the initial flag.
• Pacemaker measurement data and information (if any).
• Beat type information.
• Additional measurements (e.g. ventricular rate, atrial rate, QT dispersion).

The pointers to the on/offsets are to be used for the "global" interval measurements across the simultaneously acquired leads.

This SCP section is optional and is not necessary for the SCP compression.

5.11 Section 8 (Textual diagnosis)

For filling section 8 additionally a diagnostic classification algorithm must be applied.

The full textual interpretive statement section contains:

• Report status information (e.g. Not overread report or confirmed report).
• Time stamp of the report creation.
• Textual diagnosis.

This SCP section is optional and is not necessary for the SCP compression.

5.12 Section 9 (Manufacturer Specific Diagnostic)

Section 9 is introduced to store manufacturer specific diagnostic information. The structure and format of the data part of this section are manufacturer specific.

This SCP section is optional and is not necessary for the SCP compression.

5.13 Section 10 (Lead measurements)

For filling section 10 additionally a measurement algorithm is necessary, which performs measurements for each single lead.

The lead measurements section contains for each lead:

• Durations and intervals (e.g. P duration, QRS duration, R wave duration, etc.).
• Amplitudes (e.g. Q wave amplitude, R wave amplitude, etc.).
• P and T morphology.
• Manufacturer specific measurements.
• Other measurements.

If the applied measurement algorithm does not provide all measurements that are defined within the measurement section, a special code can be set to identify that the respective measurement is not computed by the program.

For more details of this SCP section see clause 5.13 of the SCP standard document.

This SCP section is optional and is not necessary for the SCP compression.

5.14 Section 11 (Universal statement codes)

This section contains the most recent interpretation and overreading data, coded according to the universal statements codes and coding rules, defined in ANNEX D of the SCP standard document. For details see clause 5.14 of the standard.

This SCP section is optional and is not necessary for the SCP compression.

Final Remark

This text is a first attempt to explain the content and structure of the SCP Interchange format in an "easy to understand" way. More parts may follow to explain in detail programming and conformance testing issues, matters relating to viewers and applications for stress test and long term (Holter) ECG recordings. Our objective is to promote SCP-ECG implementations which take advantage of the powerful flexible specification while still providing true interoperability with regard to presentation (viewing) and processing ECG records and analysis results from various sources.