1st Workshop: Bridging the Interoperability Gap in ECG Devices 10-12 October 2002, KNOSSOS Royal Village, Hersonissos, Greece

Breakout Session I: Adoption of ECG Standards

Chairmen: G. van Herpen, Erasmus University & Prof. P.W. Macfarlane, UK

WG Table 2: Current Implementations and Use of Standards.

Breakout Session II: Bridging the Interoperability Gap

Chairman: JJ Schmidt, CH

WG Table 1: Manufacturers' view points

Reporters: C. Malossi, I & Chr. Zywietz, D

Objectives of the breakout sessions

The aim of this breakout session was a discussion with the manufacturers to identify barriers and bottle necks in implementation and use of ECG Communication Standards, in particular of the SCP ECG standard.

Participants

Klein, Gunar; Karoliska Institut, Sweden
Voros, Jozsel; Meditech Ltd., Hungary
Wagner, Janos; Meditech Ltd, Hungary
Oelmaier, Hubert; Zimmer Elektromedizin GmbH, Germany
Catarsi, Fabrizio; CAEN SpA-Aurelia Spa, Italy
Kroon, Frits; Cardio Control, Nl
Kaiser, Willi; GE Medical Systems Information Technologies, Germany
Fischer, Ronald; Medical School Hannover, Germany
Schmid, Johann-Jacob: Schiller AG, Switzerland
Malossi, Cesare; Elettronica Trentina, Italy
Costi, Magda; ESAOTE, Italy
Zhou, Sophia; Philips Medical Systems, USA
Macfarlane, Peter; University of Glasgow, UK
Zywietz, Christoph; BIOSIGNA, Germany

As can be seen from this list there were manufacturers from Hungary, Germany, Italy, the Netherlands, USA-Germany, Switzerland. It should be noted that also representatives of leading companies like W. Kaiser for General Electric Medical Systems Information Technologies, from Schiller Switzerland, from the major Italian companies like Elettronica Trentina and ESAOTE and from the Philips Medical Systems Group were present.

The discussion was started with a role call where the participants introduced themselves (most of them were development engineers), and their companies. Then an inventory was made which of the companies did implemented version of the SCP standard. It turned out that the majority of the manufacturers did have implementations of the SCP protocol version 1 and are in part working on implementation of version 1.3. The SCP protocol has been implemented by Cardio Control, Elettronica Trentina, General Electric/Marquette/Hellige and Zimmer Elektromedizin. Caen and Meditech are working on it but do have specific requirements (e. g. one lead real time transmission for pace maker monitoring).

Use of SCP

It turned out that despite some implementation work in almost all companies the SCP ECG standard was regularly used only by Elettronica Trentina and Schiller.

During the discussion the following major reasons for the rare applications were given:

• There is not yet a real infrastructure for interconnecting ECG devices to departmental or hospital information systems. The major manufacturers provide often there own ECG data base management systems. Between their ECG devices and their data base management systems proprietary protocols are applied. It is extremely costly to change these systems to a new standard because sometimes very large data bases would need a conversion or a new incompatibility between the old and the new ECG data would occur.
• A second reason is that so far the customers of ECG equipment do not require the SCP standard communication interface. The customers are either not aware of the existence of this standard and or they do not jet have any relevant information technology infrastructure, e. g. for generation of a real electronic patient health record.
• Some of the manufacturers expressed clearly that as long as they could not earn additional money by providing the SCP ECG protocol, in other words, as long as they can not expect return of investment from the market, they will not put any further effort into implementation of newer versions etc. (Please note representative of all major manufacturers have spent a lot of time in developing and improving the SCP ECG standard itself by collaborating with the European CEN group and with a specific AAMI committee).

OpenECG transmission interfaces

It was then questioned whether besides the proprietary communication interfaces other standard interfaces for provision of ECG waveform data would be available or could be built into the devices. The answer in most of the cases was negative for the same reason as mentioned above: If there is no return of investment manufacturers will not change their devices.

However, agreement could be reached on the following items:

• Everyone is aware and accepts that in the long term perspective the electronic health record must be realized.
• Therefore agreement on a standard interchange format is necessary.
• Essentially the SCP ECG interchange format is suitable for communicating ECG data.
• There will most probably be other communication mechanisms then the enhanced X-modem protocol as specified within the SCP standard version 1.0 and version 1.3.

Based on the fundamental agreement on the necessity of interchange of ECG data the possibility for establishing interoperability were discussed. It turned out that a harmonization of the various proprietary protocols and of various SCP implementations should be reached. Also briefly discussed was in this context that there are at present several standardization proposals on the market, e. g. the DICOM waveform specification (DICOM supplement 30), the coming European standard for a File Exchange Format (FEF Standard) and the XML standardization proposal initiated by the American Food and Drug Administration for ECG waveform interchange.

After some discussion the participants agreed to specify application scenarios for their devices. Based on these scenarios the requirements regarding the data identification, data formats, processing of data and storage and retrieval requirements could be specified.

Also the aspect of using ECG devices in telemedicine applications of different types was stressed, e. g. whether just an ECG is to be transmitted from a remote location and should be overread or evaluated by a cardiologist or whether an ECG recording is taken in a monitoring environment and to be transmitted continuously to a monitoring station at another location.

It was agreed that each manufacturer will send in to the OpenECG consortium (in particular to the chair person of this discussion) the characteristic scenarios for their devices or device families. It was further agreed that it should be tried to reduce the number of compliance levels of the SCP ECG standard.

Furthermore,the manufacturers are very interested in tools for testing implementations and in obtaining viewers for SCP ECG data.

Conclusions

The major conclusions from the two breakout sessions are:

• The majority of manufacturers present knows about the SCP ECG standard and many of them have done implementation work.
• Manufacturers which do have long standing ECG data base management systems are hesitant to change their ECG communication to the SCP Standard for reasons of compatibility with the old data which might have been stored for many years.
• Manufacturers will change their systems only if there are strong demands from the market which would finally guaranty the return of investment for the SCP ECG implementation.
• For the SCP ECG standard essentially the interchange format has not been disputed, however the transmission mechanisms will be subject to follow the evolution of the technological changes.
• The discussion group agreed that the number of compliance levels within the SCP standard should be reduced.
• It was agreed that after the workshop the manufacturers will be contacted and asked for information for application profiles. As soon as this information is gathered in another meeting, the discussion shall be continued and work shall be done to come up with ideally only one compliance level which would make possible the interchange of ECG records from any manufacturer.