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 uate 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, uated 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 as in the DICOM message. The DICOMDIR file, as in the DICOM, is replaced with the pointer section for ease of access, to the supposed table of contents of the message.

The third field is reserved for keeping the version number of the standard being implemented. This is necessary because all standards must evolve, as the applications they support change too. In recognition of this, the standard should include a field for its version ID in all messages. New transactions or data elements will be added to operational environments of the standard, as a result of changes in the standard or due to changes in the local implementation as permitted within the standard. It is important that these changes are implemented at a site without requiring all communicating  applications to upgrade simultaneously.

This way, new fields can easily be added first to the sending or source system, and the receiving system will ignore the new fields until it has been updated to use them. This file-set feature of the DICOM message can be used to allow for inclusion of multiple classes, i.e. one file for each class. This is beneficial when working with different ECGs. The SCP format however does not allow for different types of ECGs.

Each file in the file set will contain a file ID in its header section. This will be used as a reference to that file in the pointer section. The file would comprise of modules, which in turn will maintain data elements in a tree structure as in the DICOM message. Each data element will comprise of an identifier value (or tag), a value length field and a value field (see figure 2). This hierarchical structure facilitates with the implementation.

For data compression and encoding of the ECG waveform, SCP-ECGs’ data compression technique seems like the best option available, since it provides high compression ratios and data integrity is being kept intact. If optimized Huffman tables are used, depending on the noise spectrum, they can result in only marginal compression effects and much higher compression ratios.

For safe and secure transmission of data, HL7’s transfer protocol should be ideally used for file transfer over a network,as it uses the 7th layer (application layer) of the OSI model, using TCP/IP protocol. The application level deals primarily with the semantics or data-content specification of the transaction set or message. It uses LLP for secure transmission over less robust connections. The TCP/IP protocol has features to help with error, flow and congestion control. It also helps ensure the data integrity, confidentiality and authenticity of the packet being interchanged (see figure 3).

Conclusion:

The existing prominent market standards have high flexibility with too many manufacturer specific implementation options and some ambiguity within the text. Many implementation details are left to the ingenuity and innovation of manufacturers, who must take into account of their knowledge of the clinical environment and effective user interfaces. This gives rise to differences in understanding and also results in a difference in implementation. It results in decreased interoperability amongst the different manufacturers, even when using the same standard.

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.

One solution, as proposed in this article, is the implementation of a single ECG waveform standard in medical institutes universally. This can only happen if a recognized medical body takes up the challenge to strictly implement one ECG standard worldwide. Currently manufacturers affirm their compliance with a particular standard, without describing their respective level of conformance in the conformance statement.

We do realize that the main obstacle to the implementation of this standard is the market leader companies whose main aim is the protection of their own market and creation of a more extended market for their ECG management system. Secondly the conversion of the large number of existing ECGdevices and ECG management systems to cover a different file format and protocol, entails a high cost. It is necessary to take into account of these obstacles if we really wish to promote standardization in the ECG file format and data exchange.  

References
[1]https://www.leadtools.com/SDK/Medical/Medical-DICOM-DataSet.htm

[2] Michael Onken, et al. Standardized exchange of medical signals
using DICOM waveforms OFFIS, Oldenburg, Germany

[3] Chr. Zywietz, R. Fischer/ February 2003. How to implement SCP

(Part I & II), Version of the document 1.3, Hannover.
[4] F Chiarugi, et al. Developing Manufacturer-Independent Components for ECG Viewing and for Data Exchange with ECG devices:Can the SCP-ECG Standard Help? In: CMI-HTA, Institute of Computer Science – FORTH, Heraklion, Crete, Greece.

[5] https://www.openecg.net

[6] Barry Smith, Werner Ceuster/August 2006, Studies in Health Technology and Informatics, 2006; 124: 133138 Presented at Medical Informatics Europe, Maastricht

[7] C Zywietz, et al. Communication and Storage of Compressed Resting and Exercise ECGs Using the Revised SCP-ECG Standards: In: Biosignal Processing, Medical School Hannover, Germany.  

Like

Dislike

Be a part of Elets Collaborative Initiatives. Join Us for Upcoming Events and explore business opportunities. Like us on Facebook , connect with us on LinkedIn and follow us on Twitter , Instagram.