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.