EN 1064:2005+A1:2007

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:2005+A1:2007SIST EN 1064:2005+A1:2008en35.240.80ICS:SLOVENSKI
STANDARDSIST EN 1064:2005+A1:200801-maj-2008

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 1064:2005+A1
March 2007 ICS 35.240.80 Supersedes EN 1064:2005English 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 and includes Amendment 1 approved by CEN on 15 January 2007.
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 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 Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, 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 © 2007 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 1064:2005+A1:2007: E

Encoding of alphanumeric ECG data in a multilingual environment.72 Annex B (normative)
Definition of compliance with the SCP ECG standard.88 Annex C (normative)
Methodology and conformance testing of the recommended ECG signal compression technique.97

Definition of a minimum set of control and query messages for the interchange of ECG data.133 Annex E (informative)
Standard low-level ECG-Cart to host protocol.148 Annex F (informative)
Universal ECG interpretation statements codes.161 Annex G (informative)
Glossary.184 Bibliography.186

All devices stating a 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, a SCP-ECG compliance statement lists Data Format Category(ies) for export
(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, 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 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) 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 name, patient 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

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

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

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 1 10 Drugs yes 401) 1 13 Diagnosis or Referral Indication yes 801) 1 14 Acquiring Device Identification Number - 40 1 15 Analyzing Device ID Number - 40 1 16 Acquiring Institution Description - 40 1 17 Analyzing Institution Description - 40 1 18 Acquiring Department Description - 40 1 19 Analyzing Department Description - 40 1 20 Referring Physician - 60 1 21 Latest Confirming Physician - 60 1 22 Technician Description - 40 1 23 Room Description - 40 1 30 Free Text Field yes 801) 1 31 ECG Sequence Number - 12 1 35 Free-text Medical History yes 801)
NOTE 1 Multiple instances are allowed for these fields, each with 40 or 80 characters, NULL terminated.

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 3 below: Table 3 — 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) HeaderFieldFieldTagFieldLengthFieldValue12var.
.....HeaderFieldHeaderTerminatorPadding byte(if needed)1)Tag2551Length02

3 Binary: Units of age as defined below:
Value Unit
0 Unspecified
1 Years
2 Months
3 Weeks
4 Days
5 Hours If all 3 bytes are zero, then age is not specified.

3 Binary: Month (range 01 to 12; 01 = January).
4 Binary: Day (range 01 to 31). If all 4 bytes are zero, then date-of-birth is not specified. 6 3 Height (Binary) This field has the following format: Byte Conte
...