ISO 11073-91064:2009

INTERNATIONAL ISO
STANDARD 11073-91064
First edition
2009-05-01
Health informatics — Standard
communication protocol —
Part 91064:
Computer-assisted electrocardiography
Informatique de santé — Communication entre dispositifs médicaux sur
le site des soins —
Partie 91064: Protocole de communication standard pour
l'électrocardiographie assistée par ordinateur

Reference number
©
ISO 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2009 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 1
4 Abbreviations . 3
5 Definition of the data contents and format . 4
5.1 General considerations. 4
5.2 Specifications for the data structure . 5
5.3 Pointer section – Section 0. 8
5.4 Header information – Patient data/ECG acquisition data – Section 1. 10
5.5 Huffman tables – Section 2. 23
5.6 ECG lead definition – Section 3. 24
5.7 QRS locations, reference beat subtraction zones and protected areas – Section 4 . 30
5.8 Encoded type 0 reference beat data – Section 5 . 32
5.9 Rhythm data – Section 6 . 34
5.10 Global measurements – Section 7 . 36
5.11 Storage of full text interpretive statements – Section 8 . 41
5.12 Storing manufacturer specific interpretive statements and data related to the overreading
trail – Section 9 . 43
5.13 Lead measurement block – Section 10.43
5.14 Storage of the universal ECG interpretive statement codes – Section 11. 46
6 Minimum requirements for encoding and compression of the ECG signal data. 48
6.1 Scope and field of application. 48
6.2 Introduction . 48
6.3 ECG compression methodology. 49
6.4 Main results from investigations on ECG data compression in the SCP-ECG Project. 50
6.5 Minimum requirements for ECG data compression. 51
Annex A (normative) Encoding of alphanumeric ECG data in a multilingual environment . 53
Annex B (normative) Definition of compliance with the SCP ECG standard. 66
Annex C (normative) Methodology and conformance testing of the recommended ECG signal
compression technique. 74
Annex D (informative) Definition of a minimum set of control and query messages for the
interchange of ECG data. 106
Annex E (informative) Standard low-level ECG-Cart to host protocol. 121
Annex F (informative) Universal ECG interpretation statements codes. 132
Annex G (informative) Glossary. 154
Bibliography . 156

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 11073-91064 was prepared by Technical Committee ISO/TC 215, Health informatics.
iv © ISO 2009 – All rights reserved

Introduction
The electrocardiogram (ECG) is a recording of voltage changes transmitted to the body surface by electrical
events in the heart muscle, providing direct evidence of cardiac rhythm and conduction, and indirect evidence
of certain aspects of myocardial anatomy, blood supply and function. During its propagation to the surface,
extracardiac tissues may intervene and influence the ECG.
Electrocardiography has been used for many years as a key, non-invasive method in the diagnosis and early
detection of coronary heart disease, which is the leading cause of mortality in western countries. In 1993, it
was estimated that more than 100 million standard ECGs are recorded yearly in the European Community
(EC) for routine diagnostic and screening purposes at an estimated cost of more than 1,2 billion € per year.
Almost all newer electrocardiographs nowadays use digital recording, interpretation and communication
techniques. These stand-alone, microcomputer based machines can be connected to each other, and to
larger minicomputer-based management servers for long-term storage and serial comparison. To this end,
various manufacturers have used different techniques.
It is in the general public interest for users not to be restricted in their options by incompatible technical
features and services of different systems. ECG processing is increasingly being integrated with various other
data processing in health care. This evolution shall have considerable impact on the storage and
communication of ECG data. There are many different end-users who for different purposes (support of
patient care, management, research and education) want to obtain a copy of the signal data, of the
interpretive report and/or measurement results. Being one of the very first systems for medical decision
support, computerized ECG interpretation stretches from departments of cardiology in hospitals, to general
practitioners in primary care and health care centres. In life-threatening acute myocardial infarction, ECGs are
being used in ambulances by paramedical personnel to assess the necessity for administering thrombolytic
agents, with long-distance monitoring whenever possible.
To enable the exchange of information between various systems it was of utmost importance that a standard
communications protocol for computer-aided electrocardiography (SCP-ECG) had to be established, as
defined in this document. The primary aim of this document is to specify a data format for transferring ECG
reports and data from any vendor's computerized ECG recorder to any other vendor's central ECG
management system. The same standard should also allow standardized transfer of digitized ECG data and
results between various computer systems.
Under the standard communication protocol (SCP) the contents and format of the ECG waveform data and
the measurements from ECG devices of different manufacturers are not expected to be identical. As a result,
the determination of the suitability of a device and/or system for any particular application remains with the
user/purchaser. The following possible uses of ECG records require special attention:
⎯ serial comparison of ECGs and interpretations;
⎯ plot formats of ECGs;
⎯ maintaining audit trail of edits;
⎯ bi-directional communication and remote query.
The user is cautioned to make sure that the data contents and format of the waveform data, measurements,
and the interpretive statements meet his or her specific needs. If more than one type of ECG device and/or
database management system are interconnected, the user is also advised to verify with the manufacturers
that the data from different systems are compatible with each other and with the user’s needs.
In order to understand this document, the reader needs some basic understanding of electrocardiology,
electrocardiography and signal processing.
This part of ISO 11073 relates to the conventional recording of the electrocardiogram, i.e. the so-called
standard 12-lead electrocardiogram and the vectorcardiogram (VCG). Initially, the electrical connections used
for recording the ECG were made to the limbs only. These connections to the right arm (RA), left arm (LA), left
leg (LL) and right leg (RL) were introduced by Einthoven. The electrical variations detected by these leads are
algebraically combined to form the bipolar leads I, II and III. Lead I, for example, records the difference
between the voltages of the electrodes placed on the left arm and the right arm. The unipolar
electrocardiographic leads (aVR, aVL, aVF and the precordial leads V1 to V6) were introduced much later,
starting in 1933. In these leads, potentials are recorded at one location with respect to a level which does not
vary significantly in electrical activity during cardiac contraction. The “augmented” limb lead potentials are
recorded with reference to the average potential of (L+F), (R+F) and (L+R) respectively. The unipolar chest
(RA+RL+LL)
leads are recorded with reference to the average potential of which is called the Wilson “central
terminal” (CT). In vectorcardiography, recordings are made of three mutually perpendicular leads, running
parallel to one of the rectilinear coordinate axes of the body. The axes are the X-axis going right to left, the Y-
axis with a top to bottom orientation and the Z or front to back axis.
In some research centres, so-called body surface maps are obtained by placing many (from 24 to 124 or even
more) closely-spaced electrodes around the torso. This part of ISO 11073 has not been designed to handle
exchanges of such recordings, although future extensions could be made to this end. This part of ISO 11073
has also not been designed to exchange specialized recordings of intracardiac potentials or of the so-called
Holter or other long-term ECG recordings made for monitoring cardiac rhythm. This part of ISO 11073 also
does not address exercise ECG recordings.
ECG computer processing can be reduced to three principal stages:
1) data acquisition, encoding, transmission and storage;
2) pattern recognition and feature extraction, i.e. ECG measurement;
3) diagnostic classification.
In each of these stages there are important needs for standardization and quality assurance testing. The
scope of this part of ISO 11073 is confined to the first of these three stages.
The various data sections that shall be transmitted by means of the standard ECG communications protocol
are defined in Clause 5. Minimum requirements for data encoding and compression are defined in Clause 6.
The compliance categories defined in Annex B provide users and manufacturers of ECG devices and/or
systems with a relatively simple codification of SCP-ECG related features and information content that may be
provided by a specific device. Two data format categories have been defined based on information content as
in Table 1.
Table 1 — Data format categories for compliance specifications
Category Data sections required Content description
I 0, 1, [2], 3, 6, (7), (8), (10) Demographics, and ECG rhythm data (uncompressed or with
lossless compression)
II 0, 1, [2], 3, 4, 5, 6, (7), (8), (10) Demographics, ECG rhythm data (uncompressed, with lossless
compression or with high compression), and reference beats
NOTE 1 Square brackets [ ] indicate that data section 2 is required if Huffman encoding has been used.
NOTE 2 Parentheses ( ) indicate that these data sections are optional for export.

vi © ISO 2009 – All rights reserved

A further category may be added in future versions in order to fulfil the specific needs of ECG devices used in
other applications (such as telemedicine or homecare).
All devices stating an SCP-ECG data format category shall import at minimum data sections 0, 1, 3, 6, 7 and
8. All categories may have additional sections added (e.g. 9, 10, 11). Manufacturer-specific data shall be
optionally included only in manufacturer-specific fields, bytes and data blocks that have been defined in the
document. Reserved, unspecified and undefined fields, bytes or data blocks shall not be used for
manufacturer-specific data.
For a particular device, an SCP-ECG compliance statement lists data format category(ies) for export
(i.e. acquiring and making available an SCP-ECG record) and import (i.e. accepting, and making available to a
user, an SCP-ECG record). A device may also state its ability to transfer (i.e. making available an SCP-ECG
record without changing its data format, for example, exporting a record that was previously imported). (These
terms are precisely defined in Annex B for the purpose of this part of ISO 11073).
The selection and definition of ECG-specific high-level syntaxes for transfer of messages and data host-to-
hosts, such as EDIFACT or ASN.1, are beyond the scope of this part of ISO 11073.

INTERNATIONAL STANDARD ISO 11073-91064:2009(E)

Health informatics — Standard communication protocol —
Part 91064:
Computer-assisted electrocardiography
1 Scope
This part of ISO 11073 specifies the common conventions required for the cart-to-host as well as cart-to-cart
interchange of specific patient data (demographic, recording, .), ECG signal data, ECG measurement and
ECG interpretation results.
This part of ISO 11073 specifies the content and structure of the information that is to be interchanged
between digital ECG carts and computer ECG management systems, as well as other computer systems
where ECG data can be stored.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 646, Information technology — ISO 7-bit coded character set for information interchange
ISO/IEC 2022:1994, Information technology — Character code structure and extension techniques
ISO/IEC 4873, Information technology — ISO 8-bit code for information interchange — Structure and rules for
implementation
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1
JIS X 0201-1976, Code for Information Interchange
JIS X 0208-1997, Code of the Japanese Graphic Character Set for Information Interchange
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
acquiring cardiograph
cardiograph recording the original ECG signal
3.2
bimodal compression
use of low pass filtering and sample decimation outside of a protected zone containing the QRS complex, with
no decimation or filtering within the protected zone, indicated by 5.9.3 byte 6
3.3
confirming
process whereby a trained and experienced cardiologist reviews the computer-generated (or overread)
interpretation of an ECG in order to confirm the computer-generated (or overread) interpretation or to make
the final changes to the interpretation text
NOTE The confirmed ECG is the final clinically acceptable version for diagnosis and treatment.
3.4
CSE Project
project supported by DG XII of the European Commission aiming at the development of Common Standards
for (Quantitative) Electrocardiography
3.5
downsampling factor
decimation factor
factor that gives the reduction of samples in data sections where the sampling rate is reduced with reference
to the original sampling rate.
NOTE This applies for bimodal data compression.
EXAMPLE Original sampling rate 500 S/s (equivalent to a sample interval of 2 ms) is reduced to 125 S/s (equivalent
to a sample interval of 8 ms). The downsampling factor is then 4.
3.6
interpretive device
device (cart, computer) analysing the ECG signal
3.7
message
textual body of information
3.8
overreading
process whereby a cardiologist or a cardiology fellow reviews the computer-generated interpretation of an
ECG in order to verify the accuracy or to make changes to the interpretation text
NOTE An overread ECG is generally not the final clinically acceptable version for diagnosis and treatment. Usually,
the overreading process precedes the confirming process.
3.9
record
entire data file to be transmitted, including the ECG data and associated information, such as patient
identification, demographic and other clinical data
3.10
reference beat
reference/representative ECG cycle computed through any (but not specified) algorithm comprising the P,
QRS and the ST-T waves
3.11
residual data
remaining original ECG data after “proper” subtraction of the reference beat where the adjective “proper”
refers to accurate beat alignment
3.12
rhythm data
full original ECG data, or the decompressed and reconstructed ECG data at reduced resolution
NOTE Rhythm data is typically 10 s in length.
2 © ISO 2009 – All rights reserved

3.13
section
aggregate of data elements related to one aspect of the electrocardiographic recording, measurement or
interpretation
3.14
universal statement codes
ECG interpretation codes
See Annex F.
NOTE See Glossary in Annex G for other technical terms related to this part of ISO 11073.
4 Abbreviations
AAMI American Association for the Advancement of Medical Instrumentation
AC Alternating current
AHA American Heart Association
AIM Advanced Informatics for Medicine Programmes of the European Commission Directorate
General XIII
ANSI American National Standards Institute
ASCII American Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation One
AVM Amplitude Value Multiplier (see 5.8.3)
BS Backspace (control character)
CCITT International Telegraph and Telephone Consultative Committee
CEN Comité Européen de Normalisation/European Committee for Standardization
CR Carriage return (control character)
CRC Cyclic redundancy check
CSE Common standards for quantitative electrocardiography
DG Directorate General (of the European Commission)
EC European Community
ECG Electrocardiogram
ECU European currency unit (€)
EDIFACT Electronic Data Interchange for Administration, Commerce and Transport
EN Europäische Norm (European Standard)
ENV Europäische Norm Vorausgabe (European Pre-standard)
ESC Escape (control character)
FF Form feed (control character)
HT Horizontal Tab (control character)
ICD International Classification of Diseases
ID Identification
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
IMIA International Medical Informatics Association
ISO International Organization for Standardization
JIS Japanese Industrial Standard
LF Line feed (control character)
LSB Least significant bit
MSB Most significant bit
RMS Root mean square
SCP Standard Communications Protocol
SCP-ECG Standard Communications Protocol for Computerized Electrocardiography
TC Technical Committee
VCG Vectorcardiogram
VT Vertical tab (control character)
5 Definition of the data contents and format
5.1 General considerations
5.1.1 The data record which is to be interchanged shall be divided into different sections. The contents and
format of each of these sections are defined in this part of ISO 11073.
5.1.2 All text data (character strings) shall comply to the limited conformance requirements of
ISO/IEC 2022, described in Annex A. Latin-1 (ISO/IEC 8859-1) shall be the default character set.
5.1.3 All character strings shall be NULL terminated (not part of ISO/IEC 2022).
5.1.4 For all signed binary values 2's-complement coding shall be applied.
5.1.5 All single and multiple byte binary values are regarded as unsigned integers, if not otherwise
specified.
5.1.6 Binary values spanning more than 1 byte shall be transmitted in ascending order of significance (the
least significant byte is transmitted first, the most significant byte last).
5.1.7 Consecutive bytes are numbered from left to right (starting with 1). Bits of a byte are numbered from
right to left (0 = LSB, 7 = MSB).
5.1.8 The first byte in the record (i.e. the first byte of the checksum) is defined as Byte 1.
4 © ISO 2009 – All rights reserved

5.1.9 ECG samples are indexed and numbered starting with sample number 1. Sample index 0 is not used
in this part of ISO 11073. The sample index is a ones-based 16-bit index. The first sample starts at time 0.
The second sample is at time (0 + 2) ms in case of 500 samples/s sampling rate.
5.1.10 Sections are numbered starting from 0 (the Pointer Section) to 32 767.
5.1.11 The term “Reference Beat” used in this part of ISO 11073 refers to an ECG complex that is chosen as
representative of a class of such complexes. No specific statistical meaning is implied by this term; for
example, it may be an averaged beat, a “Median Beat”, a selected or any other representative single cycle
taken from the total ECG recording. This “Reference Beat” does include the P-wave if present (not in case of
atrial fibrillation), the ST-T segment and the T wave of this beat.
An ECG may have multiple reference beats. The term “Beat type” used in this part of ISO 11073 refers to any
one of an ordered list of reference beats, starting with reference beat type 0 (zero). Reference beat type 0 is,
by definition, the reference beat used for classification of the ECG, and for reference beat subtraction, if
reference beat subtraction is used in compression. The ordering of the list of reference beats does not imply a
temporal sequence within the rhythm data.
The term “Rhythm Data” is used to indicate the ECG recording over the entire recording time, usually 10 s in
most recorders. A description of these terms and of the recommended data compression methodology,
including numerical examples and the methods for conformance testing on the minimum requirements of data
compression and signal distortion are given in Clause 6, Annex B and Annex C.
Reference Beat type 0 data in 5.8 are intended to be used for display, (re)analysis and, if reference beat
subtraction has been used for data compression, for Rhythm Data reconstruction.
5.1.12 All indexes or pointers to a field are defined in bytes and are ones-based (start at 1) if not otherwise
specified.
5.1.13 1 KByte = 1 024 bytes.
5.2 Specifications for the data structure
5.2.1 All sections shall start on an odd index (even offset) boundary. This implies that all sections shall
contain an even number of bytes. A padding byte has to be added to the end of any section containing an odd
number of bytes. Padding bytes shall always be set to NULL. Blocks of data within a section may contain
either odd or even numbers of bytes. Padding occurs only at the end of a section if needed.
5.2.2 All sections are given identification numbers. Section ID numbers 0 to 11 are currently defined in the
SCP-ECG protocol, numbers 12 to 127, as well as numbers above 1 024 are reserved for future use.
Numbers 128 to 1 023 are for manufacturer-specific sections. The combination of the manufacturer code
(see 5.4.3.1, tag 14) and section numbers 128 to 1 023 uniquely defines the content of the manufacturer-
specific sections. There are no specific rules for the layout and format of these sections. However, use of the
structure defined in 5.2.7 is recommended.
5.2.3 Inclusion of Sections 2, 4, 5, 7 to 11 (5.2.7 and 5.2.8) is optional. Any SCP-ECG data record shall
contain Section 0 (Pointers), Section 1 (Header), Section 3 (ECG Lead Definition) and Section 6 (Rhythm
Data). No other consistency checking among the presence of different sections is assumed. Specifically, if any
of the Sections 8, 9 or 11 is present, it is not assumed that all three shall be present.
5.2.4 The ECG record starts with a 6-byte record header, consisting of a 2-byte CRC followed by a 4-byte
record length. These are defined as follows:
1) the 2-byte cyclic redundancy check (CRC) is calculated as a CRC-CCITT, the algorithm of which is
described in E.5.5, and is calculated over the entire range starting with the first byte following the
CRC and ending with the last byte in the record;
2) the 4-byte record length denotes the number of bytes in the total record, including the 6 bytes of this
record header.
5.2.5 Record overview:
Figure 1 — Record overview
5.2.6 The sequence order of the sections of a record is free, with the exception of Section 0 (zero) which
shall immediately follow the record header. However, a maximum of one instance of any section is allowed in
an SCP-ECG data record.
5.2.7 Each section consists of:
1) a Section Identification Header (Section ID Header);
2) a Section Data Part.
Any section shall start with a “Section ID Header” (16 bytes) defined below:
Bytes Contents
1 to 2 16 bit CRC-CCITT over the entire section except these 2 bytes.
3 to 4 Section ID number as defined in 5.2.2 (see also 5.3.3.1).
5 to 8 Section length in bytes including the “Section ID Header” (5.3.3.2).
9 Version number of the Section.
10 Version number of the Protocol (see 5.4.3.1 tag 14, byte 15).
11 to 16 Reserved (for data section 0 see 5.3.1).

Each section shall have a Section Protocol Version Number (see bytes 9 and 10) which may be used to
specify different levels of compatibility with the standard when this is updated in the future (see Annex B). For
data Sections 1 to 11, Section Version Numbers (byte 9) shall be the Protocol Version under which the section
was approved. For data Sections 12 to 1 023, Section Version shall refer to the manufacturer’s version for that
section, independent of the Protocol version.
5.2.8 Reserved fields shall always be set to NULL (zero).
5.2.9 Section layout overview:

Figure 2 — Section layout overview
6 © ISO 2009 – All rights reserved

5.2.10 The numbers in italic in the layout overviews (in 5.2.5, 5.2.9 and below) indicate the length in bytes of
the corresponding field or indicated block (var = variable length).
5.2.11 A global overview of the SCP-ECG data structure is presented in Table 2.
Table 2 — SCP-ECG data structure
Requirement Content
status
Required 2 BYTES - CHECKSUM - CRC - CCITT OVER THE ENTIRE RECORD
(EXCLUDING THIS WORD)
Required 4 BYTES - (UNSIGNED) SIZE OF THE ENTIRE ECG RECORD (IN BYTES)
Required (Section 0)
POINTERS TO DATA AREAS IN THE RECORD
Required (Section 1)
HEADER INFORMATION – PATIENT DATA/ECG ACQUISITION DATA
Dependent (Section 2)
HUFFMAN TABLES USED IN ENCODING OF ECG DATA (IF USED)
Required (Section 3)
ECG LEAD DEFINITION
Optional (Section 4)
QRS LOCATIONS (IF REFERENCE BEATS ARE ENCODED)
Optional (Section 5)
ENCODED REFERENCE BEAT DATA IF REFERENCE BEATS ARE STORED
Required (Section 6)
“RESIDUAL SIGNAL” IF REFERENCE BEAT SUBTRACTION AND REFERENCE BEATS STORAGE
ARE PERFORMED, OTHERWISE ENCODED RHYTHM DATA
Optional (Section 7)
GLOBAL MEASUREMENTS
Optional (Section 8)
TEXTUAL DIAGNOSIS FROM THE “INTERPRETIVE” DEVICE
Optional (Section 9)
MANUFACTURER-SPECIFIC DIAGNOSTIC AND OVERREADING DATA FROM THE
“INTERPRETIVE” DEVICE
Optional (Section 10)
LEAD MEASUREMENT RESULTS
Optional (Section 11)
UNIVERSAL STATEMENT CODES RESULTING FROM THE INTERPRETATION

5.2.12 The following remarks apply to the data areas identified above.
0 This section contains pointers to the start of each of the following sections. This section is
required.
1 This section contains information of general interest concerning the patient (e.g. patient's name,
patient's ID, age, etc.) and the ECG (acquisition date, time, etc.). This section is required.
2 This section contains all of the Huffman tables used in the encoding of rhythm (or “residual
signal”) and reference beat data. The tables shall be referenced by Sections 5 and 6 by their
numerical order in this section. Thus, when reference is made in the reference beat encoding
section to Table 2, this shall refer to the second table defined in Section 2. This section is
required, dependent upon Huffman encoding being used in the encoding of rhythm (or “residual
signal”) and of reference beat (if stored).
3 This section specifies which ECG leads are contained within the record. This section is required.
4 If reference beats are encoded, then this section shall identify the position of these reference
beats relative to the “residual” signal contained in Section 6. This section is optional.
5 Reference beats for each lead are encoded if the originating device has identified those
complexes. This section is optional.
6 This section contains the “residual” signal that remains for each lead after the reference beats
have been subtracted, or if no reference beats have been subtracted, the entire rhythm signal.
This section is required.
7 This section contains global measurements for each reference beat type or for each QRS
contained in the record and a list of possible pacemaker spikes in the record. This section is
optional.
8 This section contains the latest actual text of the diagnostic interpretation of the recorded ECG
data, including all overreadings if performed. Only the text of the most recent interpretation and
overreading shall be included in this section. No manufacturer-specific codes should be used in
the text. Mnemonic codes as listed in the Universal Statement Codes may be used if necessary.
The data contained in this section shall be consistent with the data in Section 9 and Section 11.
This section is optional.
9 This section contains the manufacturer-specific diagnostic statements of the analysing device and
overreading trails of the interpretations. The source of the analysing device and the name of the
latest confirming physician (or device) are defined in the “Header section” (Section 1). This
section is optional.
10 A set of basic measurements and manufacturer-specific measurements (if any) for each recorded
lead are presented in this section. This section is optional.
11 This section contains the most recent interpretation and overreading data, coded according to the
Universal Statement Codes and Coding rules (Annex F). The data contained in this section shall
be consistent with the data in Sections 8 and 9. This section is optional.

5.3 Pointer section – Section 0
5.3.1 The purpose of this section is to store pointers at the remaining sections in the record. All sections are
given identification numbers, as listed in 5.2.2.
5.3.2 The section starts with a “Section ID Header” as defined in 5.2.7. Bytes 11 to 16 of the Section ID
Header shall contain the six-character ASCII string: “SCPECG”.
8 © ISO 2009 – All rights reserved

5.3.3 To provide a flexible way of section management, the data part of the pointer section are defined as
follows.
⎯ One pointer field for each of Sections 0 to 11 defined by SCP-ECG protocol shall be provided in the
pointer section, whether the optional sections are present or not. For any optional section not included in
an SCP-ECG data record, the special codes defined in 5.3.3.2 and 5.3.3.3 for the pointer field shall be
used.
⎯ Manufacturer specific sections, if present, shall have a pointer field in Section 0.
⎯ The first pointer field included in this section shall be the field for Section 0 (this section).
Each pointer field contains three parts:
a) A Section Identification (see 5.3.3.1).
b) A Section Length (see 5.3.3.2).
c) An Index to the Section (see 5.3.3.3).
5.3.3.1 The Section Identification number is stored in 2 bytes containing the section number, as listed in
5.2.2. Section ID numbers 0 to 11 are currently defined in this SCP-ECG protocol, numbers 12 to 127, as well
as numbers above 1 023 are reserved for future use, numbers 128 to 1 023 are codes for manufacturer-
specific sections.
5.3.3.2 The length, in bytes, of a section (= an even number, see 5.2.1) is presented in this unsigned
4 byte integer field part. The length includes the “Section ID Header” bytes (see 5.2.7). The 4 byte integer is
necessary to allow sections to be larger than 32 KBytes. For data Sections 2 to 11 a pointer field shall be
included. If no data are transmitted for any of these sections, set the section length to 0.
5.3.3.3 An index to the first byte of a section shall be presented in this unsigned 4 byte integer field part.
The index is calculated relative to the start of the record, i.e. byte 1 of the record (first byte of the CRC). For
example, if Section 11 begins at an offset of 128 900 bytes from the beginning of the ECG record, the index to
Section 11 would be set to 128 901. The 4 byte integer is necessary to allow an SCP-ECG record to be larger
than 32 KBytes. If a section is not included in the SCP-ECG record the index shall be set to NULL (0). The
index to Section 0 shall always be set to 7, since Section 0 is always preceded by the Checksum (2 bytes)
and the Record Length (4 bytes).
5.3.3.4 The pointer fields shall be in numerical order. However, the sections themselves do not
necessarily have to follow in numerical order.
5.3.4 Pointer section data part overview:

Figure 3 — Pointer section data part overview
5.4 Header information – Patient data/ECG acquisition data – Section 1
5.4.1 General
The section shall start with a “Section ID Header” as defined in 5.2.7.
5.4.2 Introduction to the section data part
The following layout details the format that should be used to transmit patient demographic and ECG
administrative data as part of the standard (SCP-ECG) communications protocol for digital ECG data.
5.4.3 Basic methodology
5.4.3.1 It is recognized that, although a large number of parameters may be transmitted, most devices
will only send a subset of that number. As a result, it was agreed that the format of the patient demographic
area should be made flexible.
Each parameter shall be stored in a separate field. Including a field in this section shall be optional, with the
single provision that the following parameters (1 to 4) shall be present.
Tag Parameter
1 2 Patient ID (used as primary key in the ECG management database)
2 14 ID of the acquiring device
3 25 Date of acquisition
4 26 Time of acquisition
In addition, the SCP-ECG Working Group highly recommends the following parameters for uniquely identifying
the patient and time of acquisition.
Tag Parameter
5 0 Patient's last name
6 1 Patient's first name
7 5 Patient's date of birth (the date of birth shall in principle be given AD)
8 8 Patient's sex
9 15 ID of the analysing device
10 34 Date time zone
5.4.3.2 Flexibility is achieved by identifying each field by the following means.
a) One leading specification byte, referred to as “tag”, indicating the contents of the parameter field.
b) A 2-byte unsigned integer, referred to as “length”, containing the length of the field value in bytes,
allowing variable length text entries and use of multiple byte character sets (as the Japanese character
set). The NULL terminator character of a text string shall be included to calculate the field length. For
example, for the last name “Menuel” the length shall be listed as 7, the NULL included. A length field
value of 0 is allowed, which is equivalent to “not defined”.
c) Zero or more parameter bytes, referred to as “value”, containing the actual parameter data.
10 © ISO 2009 – All rights reserved

The field tag (1 binary byte) permits a total of 255 different field types to be defined (0 to 254; 255 is used as
terminator), of which 55 (200 to 254) are reserved for use by an individual manufacturer. Any field identified by
a value of 200 to 254 is not defined within the specification of this protocol and permits a manufacturer to
define its own set of fields.
The field length (2 binary bytes) shall contain the actual length of the field value. The tag and length bytes
(first 3 bytes of any field) are not included in the field length. The maximum possible length of each field value
is 65 535 bytes (unsigned 2 bytes). However, for practical reasons the maximum length of a field shall not
exceed 64 bytes, except for the free text items (see 5.4.3.5).
The field value, containing the actual parameter data, can be of any combination of binary bytes and text
characters.
5.4.3.3 A maximum of one instance of any field defined in 5.4.5 is allowed to be included in the “Header”
section, except for the following fields listed below:
Tag Value description Max. instances
10 Drugs no limit
13 Diagnosis or referral indication no limit
30 Free text no limit
32 History diagnostic codes no limit
35 Free-text Medical History no limit

5.4.3.4 The first 16 characters of the patient identification number shall be unique.
5.4.3.5 In order to facilitate the implementation of the protocol, a maximum field length, i.e. 64 (except for
tag 13, tag 30 and tag 35, where the limit is 80) and reasonable values for the length of the different free text
fields have been determined, as shown in Table 3.
Table 3 — Maximum and reasonable length of free text fields
Section Tag Contents Instance > once Reasonable length
1 0 Last name – 40
1 1 First name – 40
1 2 Patient identification number – 40
1 3 Second last name – 40
a
1 10 Drugs yes 40
a
1 13 Diagnosis or referral indication yes 80
1 14 Acquiring device identification number – 40
1 15 Analysing device ID number – 40
1 16 Acquiring institution description – 40
1 17 Analysing institution description – 40
1 18 Acquiring department description – 40
1 19 Analysing department description – 40
Table 3 (continued)
Section Tag Contents Instance > once Reasonable length
1 20 Referring physician – 60
1 21 Latest confirming physician – 60
1 22 Technician description – 40
1 23 Room description – 40
a
1 30 Free text field yes 80
1 31 ECG sequence number – 12
a
1 35 Free-text medical history yes 80
a
Multiple instances are allowed for these fields, each with 40 or 80 characters, NULL terminated.

5.4.4 An overview of the “Header” section data part is presented below:

NOTE Padding bytes (if any) should be set to zero. This applies to all sections, but will not be shown in all the
following diagrams.
Figure 4 — Overview of the “Header” section data part
5.4.5 For specification of the defined parameters, see Table 4.
Table 4 — Specification of the defined parameters
Tag Length Value (parameter data)
0 length Last name (text characters)
This shall also be used to transmit the entire name if the originating unit does not explicitly
determine a first name.
1 length First name (text characters)
2 length Patient ID (text characters)
3 length Second last name (text characters)
The field value may be defined as appropriate for the country or area where the ECG-
device is used. For instance in the USA
...