EN 1064:2020

SLOVENSKI STANDARD
01-november-2020
Nadomešča:
SIST EN 1064:2005+A1:2008
Zdravstvena informatika - Standardni komunikacijski protokol - Računalniško
podprta elektrokardiografija
Health informatics - Standard communication protocol - Computer-assisted
electrocardiography
Medizinische Informatik - Standardkommunikationsprotokoll - Computergestützte
Elektrokardiographie; Englische Fassung EN 1064:2005+A1:2007
Informatique de Santé - Protocole de Communication Standard pour
L'Electrocardiographie Assistée par Ordinateur
Ta slovenski standard je istoveten z: EN 1064:2020
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 1064
EUROPEAN STANDARD
NORME EUROPÉENNE
August 2020
EUROPÄISCHE NORM
ICS 35.240.80 Supersedes EN 1064:2005+A1:2007
English Version
Health informatics - Standard communication protocol -
Computer-assisted electrocardiography
Informatique de santé - Protocole de communication Medizinische Informatik -
standard - Électrocardiographie assistée par Standardkommunikationsprotokoll -
ordinateur Computergestützte Elektrokardiographie
This European Standard was approved by CEN on 22 June 2020.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 1064:2020 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 9
2 Normative references . 9
3 Terms and definitions . 9
4 Symbols and abbreviated terms . 11
5 Definition of the data contents and format . 12
5.1 General considerations . 12
5.2 Specifications for the data structure . 13
5.3 Pointer section – Section 0 . 18
5.4 Header information - Patient data / ECG metadata – Section 1 . 20
5.5 Huffman tables – Section 2 . 36
5.6 ECG leads definition – Section 3 . 38
5.7 Reserved for legacy SCP-ECG versions – Section 4 . 47
5.8 Encoded type 0 reference beat data – Section 5 . 49
5.9 Short-term ECG Rhythm data – Section 6. 52
5.10 Global ECG measurements – Section 7 . 54
5.11 Storage of full text interpretive statements – Section 8 . 68
5.12 Storage of manufacturer specific interpretive statements and data related to the
overreading trail – Section 9 . 69
5.13 Per-lead ECG measurements – Section 10 . 69
5.14 Storage of the universal ECG interpretive statement codes – Section 11 . 78
5.15 Long-term ECG rhythm data – Section 12 . 82
5.16 Stress tests, Drug trials and Protocol based ECG recordings Metadata – Section 13 . 87
5.17 Selected ECG Sequences Repository – Section 14 . 98
5.18 Beat-by-Beat ECG measurements and annotations – Section 15 . 102
5.19 Selected ECG beats measurements and annotations – Section 16 . 117
5.20 Pacemaker Spikes measurements and annotations – Section 17 . 126
5.21 Additional ECG annotations – Section 18 . 140
Annex A (normative) Supplementary information and additional encoding specifications . 147
Annex B (informative)  Universal ECG interpretation statements codes . 155
Annex C (informative) Definition of compliance with the SCP ECG standard . 181
Annex D (Informative) Methodology of the recommended ECG signal compression technique . 190
Annex E (informative) Cross-references to other ECG standards . 226
Annex F (informative) Implementation Recommendations . 229
Annex G (informative) Glossary . 231
Annex H (informative) Revision History . 233
Bibliography . 236

European foreword
This document (EN 1064:2020) has been prepared by Technical Committee CEN/TC 251 “Health
informatics”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2021, and conflicting national standards shall
be withdrawn at the latest by February 2021.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 1064:2005+A1:2007.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
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 morphology.
Electrocardiography has been used for many years, and is increasingly used as a key, non-invasive and
low cost method in the diagnosis and early detection of coronary heart disease, which is the leading cause
of mortality worldwide [56] . Of the 56.9 million global deaths in 2016, 40.5 million (71.3 %) were due
to non-communicable diseases (NCDs) and 17.9 million (31 %) were due to cardiovascular diseases
(CVDs). Out of these 17.9 million cardiovascular deaths, ischaemic heart disease was responsible for 9.4
million and strokes were responsible for 5.8 million deaths. More than 3 million of these 17.9 million CVD
deaths occurred before the age of 60. The percentage of premature deaths from CVDs ranges from 8.8 %
in high-income countries to 26 % in low-income countries [56].
In 2018, it was estimated that, worldwide, approximatively 3 million ECGs are recorded every day [41].
The Mayo Clinic, for example, nowadays performs about 240,000 standard ECG recordings per year [57].
According to Research And Markets, the Global Electrocardiography Devices (ECG) Market accounted for
$5,122 million in 2018 and is expected to reach $9,738 million by 2027 [58]. The factors driving this
market include the increasing geriatric population, rising incidences of lifestyle diseases, technological
advancements in diagnostic ECG devices, and high growth rate in developing countries.
Almost all newer electrocardiographs nowadays use digital recording, interpretation and communication
techniques, and there is an increasing number of portable and even wearable (mobile) ECG devices that
are now used instead of the traditional ECG cart. These stand-alone, microprocessor based machines and
devices can be connected to each other, to a host computer, to the internet or to a hospital information
system for reporting, long-term storage in the Medical Electronic Record 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 and devices. ECG processing is increasingly being integrated
with various other types of data processing in health care. This evolution will 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, drug trials and/or drug 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 ever developed 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 and to home care. In life-threatening acute myocardial infarction,
ECGs are now used in ambulances by paramedical personnel to assess the necessity for administering
thrombolytic agents or to alert cathlabs to prepare for a coronary intervention, with long-distance
monitoring whenever possible, and in self-care situations to detect ischemia or life threatening
arrhythmias as early as possible [31].
To facilitate the exchange of information between various systems, it was of utmost importance that a
standard communications protocol for computer-aided electrocardiography (SCP-ECG) was established,
as defined in this document. Its aim is to specify a data format for transferring ECG signals, metadata and
reports from any vendor's computerized ECG device to any other's vendor central ECG management
system. The same standard should also allow standardized transfer of digitised ECG data and results
between various computer and information systems, Electronic Medical Records, and ECG data
repositories.
Figures in square brackets refer to the Bibliography.
Under this standard communications protocol (SCP-ECG), the contents and format of the ECG waveform
data, metadata 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;
— printout formats of ECGs;
— maintaining an audit trail of edits and annotations;
— integration into an electronic medical record;
— integration into clinical information systems and data repositories.
The users are cautioned to make sure that the data contents and format of the waveform data, metadata,
measurements, and the interpretive statements meet their specific needs. If more than one type of ECG
device and/or ECG management system is interconnected, the user is also advised to verify with the
manufacturers that the data from different systems and devices are compatible with each other and with
the user’s needs.
In order to understand this document, the reader needs some basic knowledge of electrocardiology,
electrocardiography and signal processing.
This document not only relates to the conventional recording of the electrocardiogram, i.e. the so-called
standard 12-lead electrocardiogram and the vectorcardiogram (VCG), but also to other types of ECG such
as Holter ECG, physiologic monitoring ECG, stress ECG, intracardiac ECG, home care ECG monitoring and
wearable self-care ECG devices. Initially, the electric connections used for recording the ECG were made
to the limbs only. These connections to the right arm (RA), left arm (LA) and left leg (LL) were introduced
by Einthoven. The electrical variations detected by these electrode connections 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 (VR, VL, VF 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 (aVR, aVL, aVF) are
recorded with reference to the average potential of (L+F), (R+F) and (L+R) respectively, where R, L and
F refer to the RA, LA and LL electrodes. The unipolar chest leads are recorded with reference to the
average potential of (RA+RL+LL)/3 which is called the Wilson “central terminal” (CT). In
vectorcardiography, recordings are made from three mutually orthogonal 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 12-Lead stress ECG recordings, the limb
electrodes are placed on the torso to reduce limb movement artefacts. The same electrode positions apply
to some Holter, emergency and home care recordings, both to limit movement artefacts and undressing.
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 document has not been designed to handle
exchange of such recordings, although future extensions could be made to this end. The standard has also
not been designed to exchange specialized recordings of intracardiac potentials (electrograms) recorded
in the EP (Electrophysiology) laboratories or by cardiac implantable electronic devices (CIED), viz
pacemakers, implantable cardioverter-defibrillators (ICDs) and cardiac resynchronization therapy (CRT)
devices, although it could also be used to this intent.
ECG computer processing can be reduced to 3 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 document is confined to the first of these three stages. Quality assurance of ECG
measurement and diagnostic classification have been addressed by the CSE Working Party (see [32] and
[44] to [50]) and to some extent by IEC 60601-2-25:2011 [4]. The latter also addresses the issue of
quality assurance testing of the signal acquisition hardware and filtering.
The various data sections that shall be transmitted by means of the standard ECG communications
protocol are defined in Clause 5 of this document.
The selection and definition of ECG specific high-level syntaxes and query languages for transfer of
messages and data between devices or between devices and hosts or host-to-hosts, using for example
Bluetooth, TCP/IP, FTP, USB, Filesystem, HL7, etc., are beyond the scope of this document.
The main goal of the SCP-ECG standard is to address ECG data and related metadata structuring,
semantics and syntax, with the objective of facilitating interoperability and thus to support and promote
the exchange of the relevant information for ECG diagnosis. Indeed, as recommended by the
ACC/AHA/ACP-ASIM task force: “Electrocardiogram readers should understand the importance of
comparing a current tracing to previous tracings in order to make correct diagnoses. All abnormal
tracings should be compared with available previous tracings. The accuracy of some diagnoses may be
considerably enhanced by reviewing previous tracings.” [33]. It is thus of utmost importance to provide
a storage format enabling any device or computer program performing the analysis and interpretation of
a current ECG to perform a reliable re-analysis of the previous ECGs. For assessing serial changes between
ECG measurements it is necessary that the measurements are computed in the same way on each
recording in order to avoid any bias.
The binary encoding of ECG data within SCP-ECG and the included content self-control capabilities allow
for an efficient encoding, an encapsulation of all ECG-related parameters, and a small memory footprint
compliant with mHealth scenarios for an early detection of cardiac diseases, anywhere and anytime [31],
[39]. These features not only provide an advantage in data transmission and archiving, but also when the
data need to be encrypted (for protecting the data and the confidentiality), or signed (protection against
changes).
The present version of the SCP-ECG standard has been significantly amended, with the objective to
provide means to support the storage and interchange of almost all existing ECG recording modalities,
processing results, annotations and diagnoses, as well as precisely defined metadata enabling the
harmonization with other standards in health informatics. The main changes are summarized hereafter.
The ECG data and related metadata addressed in this document are now structured into 18 sections.
Sections 0 to 11 already existed in the previous versions of SCP-ECG and, although they have been
significantly updated, they remain almost backwards compatible with SCP-ECG V1.x and V2.x, except for
other than UTF-8 text strings encoding and beat subtraction or bimodal compression schemes which are
no longer supported. Starting with SCP-ECG V3.0, only lossless compression (difference and Huffman
encoding) of the long-term rhythm data (section 6) and of the reference beat type 0 data (section 5) are
now allowed. In addition, to simplify encoding, the present standard recommends to store all ECG signal
data uncompressed as a series of fixed length, signed integers and to reserve difference data calculation
and Huffman encoding for mobile and/or wearable devices, when they are intended to be used in poorly
served areas with limited wireless connectivity such as GPRS, where significant lossless data reduction
strategies are still of importance. Converting legacy SCP-ECG V1.x and V2.x files into SCP-ECG V3.0
compliant files would thus only require to convert non UTF-8 text strings into UTF-8 and to store ECG

2 Impacted by IEC/CD 80601-2-86 under development
signal data, if any, uncompressed. Sections 12 to 18, which are new, have been introduced to support the
storage of continuous, long-term ECG recordings, of selected sequences of stress tests, drug trials and
protocol-based ECG recordings, and the related metadata, measurements and annotations
All over the document, emphasis has been put on cross-referencing and providing a semantic mapping
between the terminology and the methodologies used in SCP-ECG and the ISO/IEEE 11073-10102
Annotated ECG (aECG) [9] and 11073-10101 Nomenclature (Vital signs) [8] standards and on levering
the ambiguities and inaccuracies of some of these other than SCP-ECG standards.
In section 1, SCP-ECG Drugs coding (Tag 10), Medical History codes (Tag 32) and Electrode configuration
Codes (Tag 33) have been significantly updated to take account of the evolution of the medical needs, and
two new tags have been introduced, respectively aimed at describing Implanted Cardiac Devices (Tag 36,
based on the NASPE/BPEG coding systems [28], [29]) and at specifying drugs according to the WHO
Anatomical Therapeutic Chemical Classification System (ATC code [43], Tag 37).
Section 4, formerly used to store QRS locations to allow beat subtraction for computing a “residual signal”,
has been deprecated and shall no longer be implemented. But Section 4 is still mentioned in the present
document to support decoding and conversion of legacy SCP-ECG version 1.x and 2.x files into SCP-ECG
version V3.0 files.
The global and per-lead measurements sections have been significantly extended. The terminology used
and the measurements and annotations provided have been harmonized with the aECG standard [9] and
with the different recommendations and consensus papers (viz the need for introducing new
measurements describing the early repolarization patterns) found in the scientific literature.
All measurements have been precisely defined, with the aim of unifying the way ECG measurements are
performed and of serving as a reference for scientific work. Manufacturers using methods other than
those recommended in SCP-ECG Version 3.0 are requested to specify the method they are using in the
physician's guide.
Section 11, which aims to contain the most recent interpretation and overreading data, now allows three
different coding schemes (in addition to free text): (1) according to the Universal Statement Codes and
Coding Rules defined in Annex B: (2) based on the categorized AHA statement codes [21]; (3) according
to the CDISC (Controlled Terminology. Clinical Data Interchange Standards Consortium) code [30].
The three different coding schemes may coexist, i.e. an interpretive statement encoded according to the
SCP-ECG Universal Statement Codes and Coding Rules may concomitantly also be encoded according to
the AHA and/or the CDISC code specifications.
Emphasis has also been put on extending and harmonizing the SCP-ECG Universal Statement Codes
defined in Annex A with the AHA and CDISC statement codes and specifications, and with aECG [9] and
DICOM [19].
Starting with version V3.0, in addition to the short duration resting ECG (section 6) and the corresponding
type 0 reference beat (section 5), the standard now provides means of storing long-term ECG rhythm data
in section 12, e.g. up to 40 days continuous recording of 3-Lead ECG signals sampled at 200 samples/sec
with a 16 bit resolution, in section 14 several selected short to medium duration ECG sequences, and, in
section 13, the related metadata and reference beats (or pointers to selected reference beats). These two
additional sections have been included to support protocol-based ECG recordings, viz stress tests and
drug trials procedures.
The format of section 12 is very similar to the ISHNE format [26]. In order to preserve random access to
the record’s segments, no compression or encoding is allowed in this section.
In addition to the full set of global measurements (section 7) and the per-lead measurements (section 10)
of the type 0 reference beat, starting with version V3.0 the standard now allows the storage, in section
15, of several pre-defined global and per-lead beat measurements and annotations, for all or for only
some computed or selected beats of the analysed signals (long-term and/or long-term ECGs stored in
sections 12 and 14 and/or in section 6). The beats may have been selected one by one by a physician or
by a beat typing algorithm (reference beats of different types, etc.), or may refer to the entire set of beats
from one or more selected time windows within the long-term ECG stored in section 12 or in the long-
term ECGs stored in sections 6 or 14.
In another scenario, one may choose to select and store the measurements and annotations for K
preselected, not necessarily consecutive beats, in as much Measurement Blocks (MB) as there are
selected beats, for thorough QT studies for example. To facilitate comparison with reference beats
measurements, the standard also allows saving, in separate MBs, the measurements and annotations
performed on the reference beats stored in sections 5 & 13.
Section 16 provides a solution for storing a different set of measurements and annotations than those
stored in section 15 and is thus complementary to section 15. Its structure and format are much the same
as for section 15, except that there is no provision for specifying analysis time windows and that there
are no reserved fields for systematically storing the PP and RR intervals (the latter can nevertheless be
stored, if need be, as optional additional measurements).
Section 16 is the preferred section for storing selected ECG beat measurements and annotations, if no
beat-by-beat measurements and annotations are required (section 15 is not present).
Section 17 has been designed to include support for pre-defining and storing (much like the way used for
storing beat-by-beat ECG measurements in section 15) large sets of global and/or per-lead spike
measurements and annotations, spike-by-spike in one or more spike measurements array(s), one
measurement array per analyzed ECG sequence (full long-term ECG record, selected ECG sequence) or
reference beat.
Section 18 “Additional ECG annotations” provides a solution for storing any type of manually or
automatically produced annotation which has not been stored in a systematic way in sections 7, 8, 10, 11
and 15 to 17, viz the onset (and end) of a bigeminal rhythm or atrial fibrillation, the identification of a
pacemaker spike that was not listed in section 17, measurements that were not foreseen in sections 15
and 16 (or a few measurements like QT intervals in drug studies in case neither section 15 nor section 16
have been implemented), manual annotation of complex cases with different types of aberrant QRS
complexes (LBBB aberrancy, etc.) and P waves (AV dissociation, etc.), noise annotations in a given lead,
etc.
1 Scope
This document specifies the common conventions required for the interchange of specific patient data
(demographic, recording conditions .), ECG signal data and metadata, ECG measurements and ECG
annotations, and ECG interpretation results.
This document specifies the content and structure of the information which is to be interchanged
between digital ECG electrocardiographs/devices and computer ECG management systems, as well as
other computer or information systems (cloud, etc.) where ECG data can be stored.
This document defines the way to describe and encode standard and medium to long-term
electrocardiogram waveforms measured in physiological laboratories, hospital wards, clinics and
primary care medical check-ups, ambulatory and home care. It covers electrocardiograms such as 12-
lead, 15-lead, 18-lead, Cabrera lead, Nehb lead, Frank lead, XYZ lead, Holter ECGs and exercise ECGs that
are recorded, measured and analysed by equipment such as electrocardiographs, patient monitors,
wearable devices. It also covers intracardiac electrograms recorded by implantable devices as well as the
analysis results of ECG analysis and interpretation systems and software that are compatible with SCP-
ECG.
ECG waveforms and data that are not in the scope of this technical specification include real-time ECG
waveform encoding and analysis used for physiological monitors, and intra-cardiac or extra cardiac ECG
mapping.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 10646, Information technology — Universal Coded Character Set (UCS)
ISO/IEEE 11073-10101:— , Health informatics — Point-of-care medical device communication —
Part 10101: Nomenclature
ISO/IEEE 11073-10102:2014, Health informatics — Point-of-care medical device communication —
Part 10102: Nomenclature — Annotated ECG
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
acquiring cardiograph / acquiring device
cardiograph/device recording the original ECG signal

Under preparation. Stage at time of publication: ISO/IEEE FDIS 11073-10101:2020
3.2
analysis Time Window
defines the time interval (starting date and time and duration) that will be used to select an ECG excerpt
that will be analysed by a computer program and/or by a health professional viz a cardiologist
3.3
confirming
process whereby a trained and experienced health professional signs off the stored interpretation report
and/or the stored measurement values and annotations of an ECG in order to confirm the computer-
generated (or already overread) interpretation report and/or measurement values and annotations
Note 1 to entry: The confirmed ECG interpretation report 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 (see references [32] and [44] to [50])
3.5
ECG excerpt
portion of a continuous ECG recording that has been either visually selected by a health professional or
by a computer based algorithm or according to a predefined protocol (viz a 10 s excerpt every hour)
3.6
interpretive device
device (cardiograph, wearable equipment, smartphone, computer, cloud, etc.) analysing and interpreting
the ECG signal
3.7
message
textual body of information
3.8
overreading
process whereby a fully trained cardiologist, or a physician of equivalent standing with cardiology
training, reviews the computer-generated interpretation and/or some of the measurement values and
annotations of an ECG in order to detect any obvious errors, including those of omission, and hence makes
changes to the text of the report and/or to the measurement values and annotations
Note 1 to entry: in some clinical settings, the process of overreading is performed in two steps. The ECG is first
over-read by a less skilled health professional, e.g. a cardiologist trainee, and is then over-read and confirmed by a
fully trained cardiologist.
Note 2 to entry: if an over-read of an ECG interpretation report is signed off (i.e. confirmed, see Clause 3.3) by the
over-reader, then it should be clinically acceptable for diagnosis and treatment.
Note 3 to entry: it should be remembered that an over-reader provides a personal opinion in either verifying or
altering a computer generated interpretation and/or measurement or annotation. One over-reader may disagree
with another in the same way as one medical professional may disagree with another in making a clinical diagnosis.
3.9
record
entire data file which is transmitted, including the ECG data and associated information, such as patient
identification, demographic and other clinical data, measurements, annotations, interpretation results,
etc.
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
rhythm data
full original ECG data, or the decompressed and reconstructed ECG data if lossless compression is used
Note1 to entry: Rhythm data are typically 10 s in length for a standard 12-Lead ECG (stored in sections 6 and/or
14), but may last several minutes for stress tests, a few hours for drug trials and up to 7 days for Holter recordings
(stored in section 12).
3.12
section
aggregate of data elements related to one aspect of the electrocardiographic recording, measurement,
annotation or interpretation
3.13
universal statement codes
ECG interpretation codes described in Annex B of this document
Note1 to entry: See glossary in Annex G for other technical terms related to this part of EN 1064.
4 Symbols and abbreviated terms
AAMI American Association for the Advancement of Medical Instrumentation
AC Alternating Current
AHA American Heart Association
AIM Advanced Informatics for Medicine Programs of the European Commission Directorate
General XIII
ANSI American National Standards Institute
ASCII American Standard Code for Information Interchange
AVM Amplitude Value Multiplier (see 5.8.3)
CEN Comité Européen de Normalisation - European Committee for Standardization
CIED Cardiac Implantable Electronic Device
CRC Cyclic Redundancy Check
CRT Implanted Cardiac Resynchronization Therapy device
CSE Common Standards for quantitative Electrocardiography
DG Directorate General (of the European Commission)
EU European Union
ECG Electrocardiogram
EN Europäische Norm (European Standard)
ENV Europäische Norm Vorausgabe (European Pre-standard)
ICD Implanted Cardioverter Defibrillator
ID Identification
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
ISO International Organization for Standardization
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
UTF-8 Universal Coded Character Set + Transformation Format – 8-bit (specified in
ISO/IEC 10646)
VCG Vectorcardiogram
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 document.
5.1.2 All text data (character strings) shall be stored in the 8-bit Universal Character Set
Transformation Format of ISO/IEC 10646 (also known as UTF-8)
5.1.3 All character strings shall be encoded in UTF-8 and NULL terminated
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 Endianness: binary values spanning more than 1 byte shall be transmitted and/or stored
according to the little endian mode, i.e. in ascending order of significance (the least significant byte is
transmitted and/or stored 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
5.1.9 ECG samples are indexed and numbered starting with sample number 1. Sample index 0 is not
used in the present document. Sample indexes are stored as ones-based 16-bit or 32–bit unsigned
integers. 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 document refers to an ECG complex which 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 (obtained by averaging the waveforms of a set of beats of the same
type), a “Median Beat” (obtained by computing the median of the waveforms of a set of beats of the same
type), 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 “reference Beat type” used in this document refers
to any one of an ordered list of reference beats, starting with reference beat type 0 (zero). Reference beat
type 0 (sometimes also called “dominant beat”) is, in general, the primary heart beat excepting
extrasystole or artefact. It is used for the calculation of the full set of global measurements and the per-
lead measurements stored in sections 7 (Clause 5.10) and 10 (Clause 5.13) and is, by definition, the
reference beat used for the so-called contour interpretation of the ECG. 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 standard electrocardiographs, but it may take several minutes for stress tests and up to several
days for Holter recordings.
Reference Beat type 0 data in 5.8 and the reference beats defined in 5.16 are intended to be used for
(re)analysis and for display.
A description of these terms and of the recommended lossless data compression methodology, including
numerical examples and the methods for conformance testing are given in Annex C and Annex D.
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 KiB (kibibyte) = 1 024 bytes; 1 GiB (gibibyte) = 1 073 741 824 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 otherwise
containing an odd number of bytes. Padding bytes shall always be set to NULL (0x00). 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. Starting with version V3.0, section ID numbers 0
through 18 are currently defined in the SCP-ECG protocol, numbers 19 through 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.5, 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, 5, 7 to 11, 15 to 18 (see section format in 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 (Short-term ECG Rhythm Data) or Section 12 (Long-term ECG Rhythm Data) or
Section 14 (Selected ECG sequences repository). Section 13 (Stress tests, Drug trials and Protocol based
ECG recordings Metadata) is compulsory when Section 14 (Selected ECG Sequences Repository) is
present. No other consistency checking among the presence of different sections is assumed. Specifically,
if any of 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 C.6, 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 SCP-ECG record overview:

Figure 1 — SCP-ECG record overview
NOTE The length of Section 0 is equal to (16 + 10(n +1)) + 10m, where n = 18 is the number of sections currently
described in this version of the protocol and m is the number of additional, manufacturer specific sections (if any)
contained in the SCP-ECG record.
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 a 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
...