EN 1064:2005

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health informatics - Standard communication protocol - Computer-assisted electrocardiographyþXQDOQLãNRInformatique de santé - Protocole de communication standard - Electrocardiographie assistée par ordinateurMedizinische Informatik - Standardkommunikationsprotokoll - Computergestützte ElektrokardiographieTa slovenski standard je istoveten z:EN 1064:2005SIST EN 1064:2005en35.240.80ICS:SIST ENV 1064:20031DGRPHãþDSLOVENSKI
STANDARDSIST EN 1064:200501-september-2005

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 1064
February 2005 ICS 35.240.80 Supersedes ENV 1064:1993 English version
Health informatics - Standard communication protocol - Computer-assisted electrocardiography
Informatique de santé - Protocole de communication standard - Electrocardiographie assistée par ordinateur
Medizinische Informatik - Standardkommunikationsprotokoll - Computergestützte Elektrokardiographie This European Standard was approved by CEN on 17 December 2004.
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 Central Secretariat 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 Central Secretariat has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36
B-1050 Brussels © 2005 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 1064:2005: E

Encoding of alphanumeric ECG data in a multilingual environment.69 A.1 General.69 A.2 Scope.69 A.3 References and definitions.70 A.4 Values.71 A.5 Control characters.72 A.6 Character set encoding.73 A.7 Language code.82 A.8 Method for handling unsupported character sets.82 A.9 Summary of the Escape sequences described in this annex for the encoding of free text in SCP-ECG.83 A.10 Examples of encoded text strings.84 Annex B (normative)
Definition of compliance with the SCP ECG standard.85 B.1 General.85 B.3 Testing/validation of SCP-ECG data format compatibility.91 B.4 Coding of SCP-ECG compliance.93

Methodology and conformance testing of the recommended ECG signal compression technique.95 C.1 General.95 C.2 Principles of “HIGH” SCP-ECG data compression.95 C.3 Equations for SCP-ECG data compression.98 C.4 Numerical examples for SCP-ECG data compression.123 C.5 Test set of ECGs for conformance testing.128 Annex D (informative)
Definition of a minimum set of control and query messages for the interchange of ECG data.130 D.1 General.130 D.2 Message formats.130 D.3 State diagrams.139 D.4 Message sequence examples.142 D.5 Use of advisory messages.144 Annex E (informative)
Standard low-level ECG-Cart to host protocol.145 E.1 General.145 E.2 Data link and physical functional layers.145 E.3 Physical functional layer.145 E.4 Remote connection.146 E.5 Data link functional layer.146 Annex F (informative)
Universal ECG interpretation statements codes.158 F.1 General.158 F.2 Constraints.158 F.3 Composition of the code and general syntax rules.158 F.4 Acronyms for ECG interpretive statements.162 F.5 Overreading of measurement results.177 Annex G (informative)
Glossary.181 Bibliography.183 National and international standards.183 References from the ECG standards literature.183 Specific references with respect to ECG data compression.184

(i.e. acquiring and making available a SCP-ECG record) and import (i.e. accepting, and making available to a user, a SCP-ECG record). A device may also state its ability to transfer (i.e. making available a 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 document). The selection and definition of ECG specific high-level syntaxes for transfer of messages and data between host-to-hosts, such as EDIFACT or ASN.1, are beyond the scope of this document.

GB 2312-80, Code of Chinese Graphic Character Set for Information Interchange - Primary Set JIS X 0201-1976, Code for Information Interchange JIS X 0208-1997, Code of the Japanese Graphic Character Set for Information Interchange JIS X 0212-1990, Code of the Supplementary 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 Terms specific to this document 3.1.1 acquiring cardiograph cardiograph recording the original ECG signal 3.1.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, is called bimodal compression, and is indicated by 5.9.3 byte 6 3.1.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. The confirmed ECG is the final clinically acceptable version for diagnosis and treatment

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)

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 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.

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. 5.1.9
ECG samples are indexed and numbered starting with sample number 1. Sample index 0 is not used in the present document. 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 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, 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 document 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.
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. 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 through 11 are currently defined in the SCP-ECG protocol, numbers 12 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.4, 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 to 11 (5.2.7 and 5.2.8) is optional. Any SCP-ECG data record shall contain Section 0 (Pointers), Section 1 (Header). No 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 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 a SCP-ECG data record. CRCSection 02120 + varRecord Length4Final Sectionvar.
...Section XvarCRC DomainRecord Length Domain

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.4 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 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 1 below. Section ID HeaderSection Data PartCRCSection IDNo.LengthSectionVer. No.ProtocolVer. No.16var = (section length) - 1622411Reserved6

(EXCLUDING THIS WORD) Mandatory 4 BYTES - (UNSIGNED) SIZE OF THE ENTIRE ECG RECORD (IN BYTES) Mandatory (Section 0)
POINTERS TO DATA AREAS IN THE RECORD Mandatory (Section 1)
HEADER INFORMATION - PATIENT DATA/ECG ACQUISITION DATA Optional (Section 2)
HUFFMAN TABLES USED IN ENCODING OF ECG DATA (IF USED) Optional (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 Optional (Section 6)
"RESIDUAL SIGNAL" AFTER REFERENCE BEAT SUBTRACTION IF REFERENCE BEATS ARE STORED, 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: Section Contents 0 This section contains pointers to the start of each of the following sections. This section is mandatory. 1 This section contains information of general interest concerning the patient (e.g. patient name, patient ID, age, etc.) and the ECG (acquisition date, time, etc.). This section is mandatory. 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 optional.

5.3 Pointer section – Section 0 5.3.1
The purpose of this section is to store pointers to 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”. 5.3.3
To provide a flexible way of section management, the data part of the pointer section is defined as follows:  One pointer field for each Section 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 a 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).

The Section Identification number is stored in two bytes containing the section number, as listed in 5.2.2. Section ID numbers 0 through 11 are currently defined in this SCP-ECG protocol, numbers 12 through 127, as well as numbers above 1 023 are reserved for future use, numbers 128 through 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 is 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 .Pointer fieldSection 0MandatorySection IDNr.SectionLengthIndex toSection16244Pointer fieldSection 1Mandatory.
.....Pointer fieldSection 11MandatoryPointer fieldSection 128Optional

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 Last Name 6 1 Patient First Name 7 5 Patient Date of Birth (the date of birth shall in principle be given AD) 8 8 Patient Sex 9 15 ID of the Analyzing Device 10 34 Date Time Zone
5.4.3.2
Flexibility is achieved by identifying each field by: 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”.
...