A prerequisite for interoperability is standardization of message formats, protocols and storage. But different manufacturers use different standards with different scopes and standardization philosophies. This raises the disparity between existing equipments. In order to promote a multi-vendor environment, a standard format for digital ECG storage and data exchange is desirable. Currently the market has heterogeneous hardware and software platforms, which are generally integrated to some extent using costly and cumbersome propriety interfaces, which will soon become obsolete as technology advances. Thus a better method to exchange data would be eagerly welcomed.
Due to the lack of standardization in electronic communication throughout the field of medicine, there is potential to provide homology and automation in many essential systems to improve patient care. This is especially true in cardiology, where electrocardiograms (ECGs) are used to evaluate cardiac abnormalities such as arrhythmias and heart valve defects.
Whilst different standards like SCP-ECG, HL7 and DICOM, etc. for ECG representation have been established in medical institutes, there is no recognized body to adjudicate conformity to a standard. Almost all facilities make use of different criteria to accommodate their storage, viewing and printing conveniences; hence, to facilitate consistency, a standard format for digital ECG storage and data exchange would be a pragmatic step for ensuring effective intercommunication of cardiology results. Here we will be exploring the existing standards of ECG format and the viability of introducing a single standard, which can be followed universally.
Interoperability between medical devices and host systems is a key requirement to ensure standardized, readily transferable,patient medical records. A prerequisite for interoperability is standardization of message formats, protocols and storage. But different manufacturers use different standards with different scopes and standardization philosophies. This raises the disparity between existing equipments. In order to promote a multi-vendor environment, a standard format for digital ECG storage and data exchange is desirable.Currently the market has heterogeneous hardware and software platforms, which are generally integrated to some extent using costly and cumbersome propriety interfaces, which will soon become obsolete as technology advances. Thus a better method to exchange data would be eagerly welcomed. ]
Here we discuss three main ECG standards, which are implemented extensively in electrocardiography. The standards are analyzed to determine a ‘general purpose’ standard that fulfils the most common needs, such as reliable storage and transfer mechanisms as well as integration into the existing medical infrastructure. Each standard is thus, evaluated on the basis of the following parameters: a) data storage, b) data acquisition, c) data compression, d) transmission and e) ease of implementation. In the end, a standard is proposed, keeping in mind the advantages and disadvantages of the discussed standards.
Existing Standards
I. DI COM 3.0 Supplement 30
Digital Imaging and Communications in Medicine (DICOM) is a comprehensive set of standards for handling, storing, printing, and transmitting information in medical imaging, made by ACR/NEMA organization. DICOM developed the Waveform Standard (DICOM 3.0 Supplement 30), which addressed the robust interchange of waveforms. This includes ECG, electrophysiological and hemodynamic curve data, such as pressure flow signals; independent from sampling frequency, amplitude and system sensitivity. Furthermore, audio signals such as voice comments can be entered.
(i) Data storage
In DICOM, information is stored as DICOM file-sets. Each DICOM file represents a separate class of information. These files in the file set contain a collection of data elements known as the data set. Internally these data sets are maintained in a tree structure. Each data set contains elements, which comprise of a) a tag, b) a value length and c) a value field. Besides this core data, additional Meta information is stored. The waveform object carries the raw waveform sample data only; it does not specify how the waveforms are to be displayed.
(ii) Data acquisition
In order to identify a DICOM file-set and facilitate accessing the information stored in the DICOM files of the file-set, the DICOM standard has defined the Basic Directory IOD (Information Object Definition). A DICOM file-set contains one or more DICOM files. One of the files contained in the file-set is the DICOMDIR file, which contains information about other files in the file-set. Supplement 30 has defined three waveform classes: 12-lead, Resting ECG and Exercise ECG. This waveform data is organized into channels.
(iii) Data compression
DICOM uses the deflated transfer syntax, to apply a lossless ZIP compression to all data. Transfer syntax is a part of the DICOM Presentation Context, which specifies a set of encoding rules that allow applications to unambiguously negotiate the encoding techniques that they are able to support, thereby allowing these applications to communicate. It also provides a mechanism for supporting the use of Run Length Encoding (RLE) compression, which is a byte-oriented lossless compression scheme through the encapsulated format.
(iv) Transmission
Its communication protocol is an application protocol that uses Transmission Control Protocol / Internet Protocol (TCP/IP) to communicate between systems. Its Transport Layer Secure (TLS) protocol provides a means of adding security to DICOM communication. The security added, targets three main areas. They pertain to authentication, confidentiality and data integrity. Authentication is carried out using a series of challenges and responses between the ‘client’ and the ‘server’. Confidentiality is achieved by encrypting the data sent over the communication channel. Data integrity is maintained by using message authentication codes for each packet, sent across a DICOM network.
(v) Implementation
The implementation of DICOM waveforms is possible using an existing DICOM toolkit. It is an open source toolkit named ‘The OFFIS DICOM conformance testing tool.’ In summary, DICOM supports a good variety of waveform data and allows the integration of further types.
II . Standard Communication Protocol for Computer-Assisted Electrocardiography (SCP-ECG)
SCP-ECG is a standard that specifies the interchange format and a messaging procedure for standardized transmission of ECGs between various computer systems and electrocardiographs. It is a project of OpenECG.
(i) Data storage
Here all ECG files are stored in a record format. This record is divided into different sections, which in turn are divided into two parts a) ID header and b) data part. Global fields in the data structure are CRC checksum, size of record, pointer to the record, header, ECG data and various types of processing results. This format allows for a rather large number of options to store and format the ECG data.
(ii) Data acquisition
In SCP, information is stored in a record format, which has a built-in self-identification mechanism. Its pointer section gives an overview of what is within the whole record, with information from the header of each section. This information can determine the possible options for the information content of that section, and locate and access the required information from the required data field.
(iii) Data compression
SCP employs Huffman tables for entropy-dependent encoding to achieve data compression. This type of encoding allows the transmission of the original ECG data by dense bit packing. It provides a well-assessed support for lossless and lossy ECG compression and achieves compression ratios up to 20:1. It ensures that the errors in the reconstructed signal are maintained within thresholds described in the standard itself, sufficient to guarantee a correct reinterpretation of the ECG signal.
Whilst different standards like SCPECG, HL7 and DICOM, etc. for ECG representation have been established in medical institutes, there is no recognized body to adjudicate conformity to a standard. Almost all facilities make use of different criteria to accommodate their storage, viewing and printing conveniences; hence, to facilitate consistency, a standard format for digital ECG storage and data exchange would be a pragmatic step for ensuring effective intercommunication of cardiology results.
(iv) Transmission
It uses an enhanced XMODEM data transport protocol. It is an error free file transfer protocol. It breaks up the original data into a series of packets that are sent to the receiver, along with additional information, allowing the receiver to determine whether that packet was correctly received. It uses checksum method for error checking. It has disadvantages in terms of speed, performance and recovery functionalities. A physical link between the systems involved in the file transfer is necessary.
(v) Implementation
For the implementation of SCPECG, detailed implementation guides are available. OpenECG portal is one source for easy and free access to these guides.
III . Health Level 7 (HL7) Version 3
HL7 is currently the selected standard for the interfacing of clinical data in most institutions. For waveform data, only ECG is integrated into HL7 V3. The ECG is called aECG or Annotated ECG.
(i) Data Storage
It defines very simple data structures and messages for exchanging waveform data. The data acquired is stored as a collection of digital information; represented as sequence sets of numbers, using xml coding. Annotations are added. The waveform samples are organized into channels, and codes are used to identify concepts such as channel or measurement units.
(ii) Data acquisition
It defines a kind of standard format for information exchange. Many value fields inside the segments are optional. It uses OIDs (Object Identifiers). OIDS are strings of numbers separated by dots. Each number indicates a branch in a tree of identifiers. It makes use of a self-identifying and self-delimiting encoding scheme, thus each data value can be identified, extracted and decoded individually, without knowing the structure of the message.
(iii) Data compression
HL7 does not compress waveforms. Thus it does not employ any compression techniques, and transmits and operates on raw ECG data.
(iv) Transmission
HL7 uses the TCP/IP protocol for information interchange.It defines the LLP (Lower Level Protocol), which allows the exchange of messages in less robust communications such as over a RS-232 connection. The LLP defines the protocol to fragment a message and methods to prevent data loss. An HL7 message is composed of different segments. For transferring waveforms, HL7 combines OBX (observation/result) segments, separated into several messages.
(v) Implementation
HL7 V3 standards are developed as syntax-independent models. The current preferred implementation technology is XML.
Proposed Standard
Based on the storage, acquisition, encoding, transmission and implementation of the prominent market standards, a ‘general purpose’ standard has been proposed. Thus, in order to develop an effective data storage format for efficient data interchange, a hybrid design is required. For data storage, a merger of the qualities of a SCP Record and a DICOM file-set is advised. The basic message can be taken in four parts; a) CRC checksum field; b) pointer section; c) version number and d) file set (see figure 1).
The checksum field is reserved as the first field of the message format. This Cyclic Redundancy Check (CRC) using the checksum bits in this field is a simple and effective error detection technique. The second field is reserved for the pointer section. This is a useful means to identify what the contents of a transmitted message will be. The pointers will highlight the file headers of the files in the file set. This will make it easier for the manufacturer to access the information contained in these files.
The rest of the message is comprised of a file-set