2.4 ECG Format
2.4.1 SCP ECG
format for over a decade [3]. Currently, although most of electrocardiograph manufactures claim that they have been supporting SCP-ECG format, the files output from commercial electrocardiographs still can only be interpreted by their proprietary viewers. Since there is a vast amount of these so called SCP-ECG data, they are valuable not only as patient’s records, but also as raw data for researchers. Hence, in this study, we try to develop programs to decode the SCP-ECG files generated by the commercial electrocardiographs, transform them into standard formats and store the results in the designed database.
SCP-ECG can manage textual annotations and binary signals in several defined sections obtained from short-term ECG recordings. In addition, it also uses some compressing algorithm to reduce the size of stored raw data. Some signal characteristics specified in the SCP-ECG format such as filter specifications, sampling rates, and annotation are limited to 12-lead ECG recording and the format cannot be used for other types of electrocardiac recording, such as Holter ECG. However, SCP-ECG is supported by most major manufacturers of ECG equipments. Therefore, it is one of the recommended file formats for ECG databases [4]. An SCP-ECG (CEN/TC251/N02-015, prEN 1064:2002) document can be divided into eight chapters:
z Chapter 1: Scope: The category of this protocol.
z Chapter 2: Normative References: This protocol incorporates many references, which were listed in this chapter.
z Chapter 3: Terms and Definitions.
z Chapter 4: Abbreviations.
z Chapter 5: Definition of the data contents and format. It’s the core
component of this protocol, which can be divided into different sections. Sections related to this study will be described in the following paragraphs in detail.
z Chapter 6: Minimum requirements for encoding and compression of the ECG signal data.
z Chapter 7: Definition of a minimum set of control and query messages for the interchange of ECG data.
z Chapter 8: Standard low-level ECG-Cart to host protocol.
2.4.1.1 SCP Chapter 1: Scope
This standard contains the two-way remote transmission protocol between digital electrocardiographs (ECG carts) and various kinds of computer hosts. Common conventions for ECG information interchange of cart-to-cart or cart-to-host are described in here. All ECG data to be transmitted, such as ECG signal data, specific patient data (administrative, demographic, recording etc.), measurement, annotation and interpretation results are defined in this protocol. This standard specified the content and structure of the ECG information to be interchanged. A logical link for ECG communication between two systems can be established under this protocol.
2.4.1.2 SCP Chapter 5: Definition of the data contents and formats
¾ 5.1 General considerations
The data record is divided into different sections. The contents and formats of these sections are defined in the protocol (standard communication protocol, SCP). Sections are numbered from 0 (the Pointer Section) to 32767.
All indexes or pointers (except section 0, Pointer Section) to a field are
defined in bytes and are ones-based (start at 1). Consecutive bytes are numbered from left to right (starting with 1). Bits of a byte are read from right to left (0 = LSB, 7 = MSB).
¾ 5.2 Specifications for the data structure
All sections should start on an odd index (even offset) boundary. It means that all sections should have an even number of bytes. Any section with an odd number of bytes must add one padding byte at the end with zero value (NULL). There can be odd numbers or even numbers of bytes in the data blocks of a section. Padding occurs only at the end of a section if needed. All sections are given section identification (ID) numbers. Section ID numbers 0-11 are defined in SCP-ECG protocol currently. ID numbers from 12 to 127 and above 1024 are reserved for future use. Numbers 128-1023 are provided as manufacturer specific sections. No specific rules are defined for these sections. Only the section ID header structure is required to follow the specification. There are no rules specified for the section data part. That is the major reason why a manufacturer’s SCP format is not compatible to the other’s SCP format.
All SCP-ECG files must contain section 0 and section 1, which are mandatory. Section 0 is the pointer section and pointers to the start of each following sections are recorded in this section. Section 1 contains header information, which includes data related to the patient (e.g. patient ID, name, sex, age, etc.). Sections 2-11 are optional.
A global overview of the SCP-ECG record structure is shown in Table 2.1. An ECG record starts with a 6-byte recode header, which contains a
there are section 0, section X and then final section. Overview of the SCP-ECG record is shown in Figure 2.13.
Table 2.1: Global overview of the SCP-ECG data structure IDs Status
Section
Content
- Mandatory 2 Bytes Checksum: CRC-CCITT - Mandatory 4 Bytes Size of The Entire Record 0 Mandatory Pointer to Data Areas In The Record 1 Mandatory Header Information-Patient Data /
ECG Acquisition Data
2 Optional Huffman Tables
3 Optional ECG Lead Definitions
4 Optional QRS Locations
5 Optional Encoded Reference Beat
6 Optional “Residual Signal” After Reference Beat Subtraction Or Encoded Rhythm Data
7 Optional Global Measurements
8 Optional Textual Diagnosis From The “Interpretive” Device 9 Optional Manufacturer Specific Diagnostic And Overreading
Data From The “Interpretive” Device 10 Optional Lead Measurements Results
11 Optional Universal Statement Codes Resulting From The Interpretation
12-127 Reserved Reserved for Future Use
128-1023 Optional Manufacturer Specific Sections 1024-65535 Reserved Reserved For Future Use
CRC Section 0
2 120 + var
Record Length
4
Final Section
var
... ...
Section X
var
CRC Domain
Record Length Domain
Figure 2.13: Overview of the SCP-ECG Record
The SCP files obtained from the local hospital in this study contain five sections: section 0, section 1, section 7, section 8, and manufacturer specific section 128. This study will focus mainly on these sections. The sequential order of the sections of a record is free, except section 0 which follows the record header (CRC and record length) immediately. Each section contains 2 parts:
1). A Section ID Header 2). A Section Data Part
Section ID Header is made up of 16 bytes. Bytes definition of Section ID Header is shown in the Table 2.2. The overview of the section lay-out is shown in Figure 2.14.
Table 2.2: Bytes definition of Section ID Header Bytes Contents
1-2 16 bit CRC-CCITT
3-4 Section ID number
5-8 Section length(in bytes)
9 Version Number of the Section 10 Version Number of the Protocol 11-16 Reserved(except section 0 *)
* Bytes 11-16 of the section 0 ID header shall contain "SCPECG"
Section ID Header Section Data Part
CRC Section ID
No. Length Section Ver. No.
Protocol Ver. No.
16 var = (section length) - 16
2 2 4 1 1
Reserved
6
Figure 2.14: Section lay-out overview
¾ 5.3 Pointer section - Section 0
The purpose of section 0 is to store the index and length of all sections.
This section starts with a “Section ID Header” consisting of 16 bytes, as defined above. Bytes 11-16 should contain the string: "SCPECG" (SCP file obtained in this research does not have this string).
Data part of Pointer section consists of several pointer fields for which several rules must be followed:
1). No matter whether a section is used, the pointer fields of section 0-11 must be defined.
2). Manufacturer specific section must have its corresponding pointer field in section 0.
3). The first pointer field is section 0.
Each pointer field is made up of 10 bytes, containing three parts:
Section ID, Section Length, and Section Index:
1). Section ID: 2 bytes, value: 0-32767.
2). Section Length: 4 bytes, value: unsigned 4 byte integer.
3). Section Index: 4 bytes, value: unsigned 4 byte integer, which is calculated relative to the start of the record.
Since sections 2-11 of the record are optional, if not exist, the length is set as 0 and the index is set as NULL (0). The index of section 0 is always set to 7 (following CRC: 2 bytes and Record Length: 4 bytes). The pointer fields in section 0 shall be arranged in sequential order, but the real block of each section may not need to follow this order. The overview of the pointer section data part is shown in Figure 2.15.
....
Pointer field Section 0 Mandatory
Section ID Nr.
Section Length
Index to Section 16
2 4 4
Pointer field Section 1 Mandatory
... ...
Pointer field Section 11 Mandatory
Pointer field Section 128
Optional
Figure 2.15: Pointer section data part overview
¾ 5.4 Header information - Patient data / ECG acquisition data - Section 1 Section 1 contains detailed information related to patient demographic and ECG administrative data. It also starts from a Section ID Header of 16 bytes. Following the header, there is the Section Data Part (see Figure 2.14), which contains many header fields arranged one by one, until the header terminator and padding byte (if needed). Figure 2.16 shows the overview of Header section data part.
Header Field
Field Tag
Field Length
Field Value
1 2 var
... ...
Header Field
Header Terminator
Padding byte (if needed)1
Tag 255
1
Length 0
2
Figure 2.16: Overview of the Header section data part
Header Field is made up of three parts:
1). Field Tag: 1 binary byte 2). Field Length: 2 binary bytes 3). Field Value: variable bytes
There are 255 field types can be defined in Field Tag (0-254). Tag 255 (FF in Hex) is used as terminator. Tags 200-254 are reserved for individual
Length defines the actual length of the Field Value. The tag and length bytes (first 3 bytes of field) are not included in the Field Length. Maximum length of the field is 65535 bytes (real length is indicated by a 2-byte unsigned integer). However, except for free text items, the maximum length should not exceed 64 bytes. Table 2.3 shows the maximum and reasonable length of free text fields.
Table 2.3: Maximum and reasonable length of free text fields
Section TAG CONTENTS Instanc
e > 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 40 *
1 13 Diagnosis or Referral Indication yes 80 * 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 80 *
1 31 ECG Sequence Number - 12
1 35 Free-text Medical History yes 80
* Multiple instances are allowed for these fields, each with 40 or 80 characters.
Most tags can only appear once except for the following five kinds of tags:
1). Tag 10: Drugs
2). Tag 13: Diagnosis or referral indication 3). Tag 30: Free text
4). Tag 32: History diagnostic codes 5). Tag 35: Free-text Medical History
When transmitting ECG data between ECG management systems, the uniqueness of patient and record is an important issue. In SCP protocol, some data are transmitted through section 1 of the SCP record for this purpose.
There are 35 tags defined in section 1 for patient demographic data (such as medical history, drug history and clinical data etc.) and ECG administrative data (such as ECG acquiring device, settings, recording location, and time stamping etc.). Although a lot of parameters (tags) are defined in section 1, most ECG equipments only send a subset of parameters. There is some flexibility reserved for ECG interoperability. Four parameters are mandatory in an SCP record:
1). Tag 2: Patient ID (primary key in this study) 2). Tag 14: ID of the Acquiring Device
3). Tag 25: Date of Acquisition 4). Tag 26: Time of Acquisition
Additional 6 parameters are highly recommended by SCP-ECG Working Group for strengthen the identifying uniqueness of the patient and acquiring time:
5). Tag 0: Patient Last Name
7). Tag 5: Patient Date of Birth 8). Tag 8: Patient Sex
9). Tag 15: ID of the Analyzing Device 10). Tag 34: Date Time Zone
There are 256 Tags can be used in header section data part (0-254 is general field tag, Tag255 is Terminator). Detailed rules and explanations for Tag0-35 and Tag255 are defined in SCP Protocol.
¾ 5.5 Huffman tables - Section 2
SCP protocol recommends Huffman method to encode and compress data. The coding rules and Huffman code tables are defined in section 2. The default Huffman table is shown in Table 2.4. The data part of SCP section 2 should have the content like the following [24]:
byte(s) Content Entry Comment
1-2 Number of Huffman tables 19999 Default Huffman table is used
Table 2.4: Default Huffman table number of bits
No.
entire code prefix
table mode
base value prefix code (in bits)
store binary as
1 1 1 1 0 0 0d
2 3 3 1 1 100 1d
3 3 3 1 -1 101 5d
4 4 4 1 2 1100 3d
5 4 4 1 -2 1101 11d
6 5 5 1 3 11100 7d
7 5 5 1 -3 11101 23d
8 6 6 1 4 111100 15d
9 6 6 1 -4 111101 47d
10 7 7 1 5 1111100 31d
11 7 7 1 -5 1111101 95d
12 8 8 1 6 11111100 63d
13 8 8 1 -6 11111101 191d
14 9 9 1 7 111111100 127d
15 9 9 1 -7 111111101 383d
16 10 10 1 8 1111111100 255d
17 10 10 1 -8 1111111101 767d
18 18 10 1 8 bit orig. 1111111110 511d
19 26 10 1 16 bit orig. 1111111111 1023d
¾ 5.6 ECG lead definition - Section 3
¾ 5.7 QRS locations, reference beat subtraction zones and protected areas - Section 4
¾ 5.8 Encoded type 0 reference beat data - Section 5
¾ 5.9 Rhythm data - Section 6
¾ 5.10 Global measurements - Section 7
¾ 5.11 Storage of full text interpretive statements - Section 8
This section contains free text of the diagnostic interpretation of the ECG. The section is made up of a Section ID Header and a Section Data Part.
The data portion of this section includes a data header followed by multiple statements. Table 2.5 and Table 2.6 show the contents and formats of the data header and the statement data respectively.
Table 2.5: Contents of data header Byte Contents
Binary: Confirmed/Non-confirmed report:
Value Type
0 Original report (not overread)
1 Confirmed report
1
2 Overread report, but not confirmed 2-3 Binary: Year (Full integer notation, as in 1990).
4 Binary: Month (range 01 to 12; 01 = January).
5 Binary: Day (range 01 to 31).
6 Binary: Hours (range 00 to 23).
7 Binary: Minutes (range 00 to 59).
8 Binary: Seconds (range 00 to 59).
9 Binary: Number of statements in this section.
Table 2.6: Contents of statement data Byte Contents
1 Binary: Statement sequence number, starting with 1.
2-3 Binary: Statement field length (number of bytes in the statement, starting with the first byte following, and including the NULL terminator).
4-*** Statement body: text terminated by NULL.
A character set should be defined for transmitting data between equipments and interpreted correctly by a receiver. The encoding rules of the alphanumeric ECG data are defined in SCP standard ANNEX A. The byte values are represented as two decimal numbers in the form of column/row as defined in the ISO Standards. The value can be calculated as (column*16) + row, e.g. 01/12 corresponds to the value 28 (1C hex). Figure 2.17 represents the byte encoding space.
0
column
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
r o w
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
C0 GL C1 GR
SPACE
DELETE
These two values are never used in 94 character set.
Figure 2.17: Ranges of the byte encoding space
C0 and C1 are "control character" sets, while GL and GR are "graphic character" sets. For GL, byte 02/00 is always defined as SPACE, and byte 07/15 (normally DELETE) is never used. The 16-by-16 array of columns and rows are numbered from 00 to 15, which contain 256 code positions. Columns 00 to 07 contain 128 character positions which are in one-to-one relation, corresponding to the characters of the 7-bit set of the ASCII table [25], which
Table 2.7: ASCII table
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI
1 DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
2 Space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | } ~ DEL
The interchange of text data (such as Section 8) may require some formatting information. Format effectors were defined in the C0 control set for this purpose, which are shown in Table 2.8.
Table 2.8: Formatting effectors
Category Abbreviatio Name Codes
Format effector BS BACKSPACE 00/08
Format effector HT HORIZONTAL TAB 00/09
Format effector LF LINE FEED 00/10
Format effector VT VERTICAL TAB 00/11
Format effector FF FORM FEED 00/12
Format effector CR CARRIAGE RETURN 00/13
Code extension ESC ESCAPE 01/11
The default character set for SCP-ECG is shown in Figure 2.18.
ISO 646 No designation in C1
The left-handed part of ISO 8859-1 (ASCII)
C0 C1 GR
G1 GL
G0
The right-handed part of ISO 8859-1 (Latin 1)
Use 8-bit environment
Designation also invokes.
Figure 2.18: The default character set for SCP-ECG
The overview of the data part of section 8 is shown in Figure 2.19.
Header 9
Statement 1 var
Statement 2 var
....
Hour Min. Sec.
1 1
1 Year
2
Month Day
1 1
Sequence
number Length Statement field
var 2
1 1
Confirmed Date Time Number of statements
4 3 1
Text NULL 1 var
Figure 2.19: Overview of the data part of the section 8
¾ 5.12 Storing manufacturer specific interpretive statements and data related to the overreading trail - Section 9
¾ 5.13 Lead measurement block - Section 10
¾ 5.14 Storage of the universal ECG interpretive statement codes - Section 11