Common ECG data formats and Comparison

SCP,DICOM,Hl7aecg,GDFFormat and Comparison

This document describes the specific data structures of SCP, DICOM, hl7aecg, and gdf ecg signal formats, and then analyzes their respective characteristics and applicability.

I. SCP-ECG format

This format is a standard format for ECG data, including ECG data waveforms, patient information,

ECG collection information and measurement and diagnosis information.

SCP-ECG formats are divided into title (2 bytes for CRC-checksum and 4 bytes for size of ECG record) and Section0-Section11. Among them, title, section0, Section1 are mandatory, and other parts are optional.

The specific data structure is as follows:

Table 1. Structure of SCP-ECG records.

Mandatory	2 bytes-checksum-CRC-CCITT over Entire record (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 over-reading data From the "interpretive" Device
Optional	(Section 10) Lead measurement results
Optional	(Section 11) Universal statement codes resulting from the Interpretation

 

Disadvantages:

(1) only static ECG information is supported. The average ECG information is not supported, that is, the late potential information is not supported. Dynamic ECG information (Holter) and exercise ECG information (Exer-cise ECG) are not supported;

(2) Only RS232 serial transmission is supported. Binary storage is not conducive to information exchange during network transmission;

(3) The complex compression algorithm used is difficult to implement and test, and other workflows such as reservation cannot be supported.

Advantages:

(1) It is the earliest Unified Storage standard for ECG data. It contains the most comprehensive information about ECG and can meet the requirements of all routine ECG checks;

(2) The required storage space is also the smallest.

 

Ii. DICOM Format

Is a medical image format. The file format is as follows:

 

Figure 2-1 file-set and file format

 

 

 

Figure 2-2 DICOM data set and Data Element Structures

 

The preceding two figures show that DICOM file-set can contain multiple DICOM files, each DICOM file contains DICOM file meta information and DICOM data set (where dicom sop instance is in DICOM data set). Data Set contains multiple data elemet, values in each data element are encoded based on the type of VR (detailed information about VR (value representation) is described in Page8-139 in ps3.6 of DICOM Manual ), there can also be multiple items in the data element (the specific data elemet encoding example can be found in the Page43-44 of ps3.5 described in the DICOM Manual ).

Therefore, the DICOM format uses the information object model to describe object information in the real world. Every Information Entity is associated with a specific object in the real world, only a model is provided for the encoding data structure. The specific encoding method depends on the information type.

Advantages:

(1) The waveform format and inspection report format are developed, and the communication between devices is also specified;

(2) It also supports important workflow events (such as revocation and reservation requests ).

Disadvantages:

This solution is suitable for hospital information systems deployed in existing PACS systems. However, there are few PACS vendors that can manage DICOM store data. This results in a time to fully integrate ECG data management with existing PACS systems.

 

Iii. hl7aecg format

The hl7aecg format, also known as fdaxml, is the HL7 ECG annotation standard. It adopts the XML data storage format and focuses on drawing, tagging, and commenting data.

The following figure shows the entities and their relationships in the data format:

 

 

Figure 3-1 The entity-relationship model

For detailed definitions of each field in the data format design, see the format documentation FDA-EGC-xmldataformat at page 18-27, appendix E.

The fdaxml standard creates an XML tag for storing ECG data and describes the meaning of these tags in detail. The XML Scheme file is used to specify the organizational structure of elements in the data file, and the content represented by each element is described.

Advantages:

(1) Charts support real-time and recorded records;

(2) The biggest feature is the ability to accurately draw comments;

(3) It is particularly suitable for clinical drug trials;

(4) This data structure can be easily transmitted over the network.

 Disadvantages:

(1) it lost some important fields required by the ECG, such as reference doctors and department information;

(2) The HL7 information model is not widely used for communication with the image acquisition module.

 

Iv. GDF format

GDF is a common data format of biosig, which can be opened using sigviewer. In this formatFeaturesThat is, it contains many events that can store both EEG, ECG, sleep-relative, and other data, not just the format file of ECG data.

(1) General Structure of the GdF File

Table 4-1: Structure of a GDF file. NS, NT, and Nev indicate the number of channels, number of TLV elements, and the number of events, respectively,

	Description	Size [bytes]
1	Fixed Header, (header1)	256	1
2	Variable header, channel-specific Information (header 2)	256 * NS	1
3	Optional Header, tag-length-Value Structure, (header 3)	> = 4 * nt + length of each value field <= Length of header-256 * (NS + 1)	0 <= Nt <256
4	Data Section	Number_of_records times bytes per record	<= 1
5	Event table	8 + Nev * 6 {Mode 1} or 8 + Nev * 12 {Mode 3}	<= 1

 

(2) Information contained by each domain in the GdF file data structure

(1) Fixed Header, (header1 ):

Version identification

Patient Identification

Patient message (including disease, States, etc)

Recording message

Time (START, duration, etc)

Header Length/size

Patient Classification

Equipment ID

Electrode Position message

NS: Number of signals (channels)

 

(2) variable header, (header 2 ):

Label

Type of transducer/sensor

Physical dimension message

Digital dimension message

Time offset (relative sampling time delay between channels)

Pre-filter information

Samples per record

Type of data

Sensor specific information

 

(3) optional Header, (header 3)

Tag

Length

Value

 

(4) Data Section

NR samples from each channel

(Nr: number of record)

 

(5) event table

Mode

Nev

Sample-rate associated with event position

 

※Mode info: {type, POS} or {type, POs, dur, Chan}

 

Comparison and summary of the four formats:

(1) SCP-ECG standard is currently the most comprehensive ECG information standard communication protocol, but only supports static ECG information, does not support dynamic, exercise ECG information;

(2) The DICOM Format pays more attention to the exchange and transmission of medical image information with its open and Interconnected Architecture and object-oriented methods;

(3) The fdaxml format can accurately plot and annotate and describe real-time ECG information, which is suitable for clinical drug trials;

(4) the GdF format is powerful and can contain a variety of Biomedical Information except ECG, such as EEG and sleep-related events.