Implementation of integrated heterogeneous electronic electrocardiography data into Maharaj Nakorn Chiang Mai Hospital Information System

Abstract

Electrocardiography is one of the most important non-invasive diagnostic tools for diagnosing coronary heart disease. The electrocardiography information system in Maharaj Nakorn Chiang Mai Hospital required a massive manual labor effort. In this article, we propose an approach toward the integration of heterogeneous electrocardiography data and the implementation of an integrated electrocardiography information system into the existing Hospital Information System. The system integrates different electrocardiography formats into a consistent electrocardiography rendering by using Java software. The interface acts as middleware to seamlessly integrate different electrocardiography formats. Instead of using a common electrocardiography protocol, we applied a central format based on Java classes for mapping different electrocardiography formats which contains a specific parser for each electrocardiography format to acquire the same information. Our observations showed that the new system improved the effectiveness of data management, work flow, and data quality; increased the availability of information; and finally improved quality of care.

Introduction

Electrocardiography (ECG) is one of the most commonly used non-invasive diagnostic tools at Maharaj Nakorn Chiang Mai Hospital, a university hospital in the Faculty of Medicine, Chiang Mai University, Chiang Mai, Thailand. ECG is used in various work locations such as the outpatients department (OPD), emergency room (ER), cardiac center, intensive care unit, cardiac care unit, operating room, and patient wards. Over 100 ECGs are printed per day but only some ECG records are manually scanned into the digital Hospital Information System (HIS).

Normally, a printed ECG is carried by the patient during their hospital visit. At the end of the day, ECGs are collected to scan to PDF files and saved in the HIS, and the original files are kept in a storage room. This system results in a high cost for paper (over 1 million baht per year), requires substantial storage space, has a risk of the paper being lost or damaged, increases the difficulty of data retrieval, provides poor quality of ECG visualization from the scanned document, and stores non-machine-readable data.

Digital ECG is a rapidly developing field, and the trend is to use digital formats instead of paper ECGs. However, the ECG data structure has been developed within different formats and this leads to a major challenge in how to exchange ECG information. Some researchers have published work detailing their success in implementing heterogeneous ECG integration.^1,2 However, their interfaces could not be used for exchanging across other hospital platforms. Later on, the concept of a uniform ECG format was developed to use as an interoperable system.

Several Standards Development Organizations tried to develop standards to solve this problem, but they still could not perfectly cover the complexity of data, and the heterogeneity of standards remains an obstacle for system integration. The four most widely known ECG formats are the Standard Communications Protocol for computer-assisted electrocardiography (SCP-ECG); HL7 annotated ECG (HL7 aECG); Digital Imaging and Communication in Medicine (DICOM) Waveform Supplement 30; and Medical waveform Format Encoding Rules (MFER).

The SCP-ECG input format is one of the most widely used in research and projects^3–5 because it is approved as an international standard and there are many available parsing tools. The SCP-ECG is a binary encoded format. Other formats are XML-based proposals that provide more human-readable files which are more easily indexed and merged into the HIS, but are more costly because of the time taken in parsing structures. Binary encoded formats produce smaller files but increase the difficulty for developing applications. A newer approach uses ontologies to provide semantic interoperability across different ECG formats. This approach has been tested by several research groups;^6,7 however, it does not yet cover pathological aspects or multiple lead ECGs.

Indeed, hospitals also face the challenge of how to manage several different digital ECG formats with different visualization requirements. In our hospital setting, three digital ECG formats have been used without digital visualization. Therefore, applying a combination approach might enhance the efficacy of system interoperability. Some research groups have applied this idea by using the SCP-ECG as an input file in conjunction with a query mapping ontology.^8,9

In order to find the most suitable solution for our specific architecture, we considered the approach suggested by Trigo et al. ³ to narrow down the choices. Finally, we decided to use an XML-based proposal in conjunction with terms from an ontology because all ECG inputs are received in XML format and we require an ECG data mapping for managing the interoperability problem.

Objectives

1. To implement an electronic ECG management system.

2. To integrate heterogeneous ECG formats.

3. To integrate the ECG management system into Maharaj Nakorn Chiang Mai HIS.

4. To discuss advantages and disadvantages discerned from the implementation process in a real scenario.

Materials and methods

The new ECG work flow runs differently from the old system by transferring an ECG XML file from the cardiograph to save it directly in the hospital server. Each ECG is identified by patient hospital number and finally displayed individually within the HIS.

The ECG system was divided into two sub-systems: the Recording system and the Viewing system. The Recording system was designed to collect and convert the various ECG data, link patient demographic data to the ECG, and send the data to be stored in the database. The Recording system runs on a personal computer (PC) connected to the ECG. The Viewing system was designed to retrieve ECG data from the database, link patient demographic data to the ECG, and visualize the ECG with zoom, print, and PDF export options. The Viewing system runs on all client PCs within the HIS.

Figure 1 shows the system design. The system receives three different ECG file formats from Philips PageWriter, GE MAC 800, and CardiofaxM cardiographs. Each ECG requires software from respective companies for communicating between the cardiograph and a PC. We could not implement the communicating protocol directly because the protocol is commercial, but we negotiated to use it for academic purposes without distributing it to other vendors. However, we determined the requirement from our system is that a company needs to support software which can send ECG data via local area network (LAN) cable to store as an XML file in a local directory in a PC. Philips PageWriter requires an Internet Information Services (IIS) system for transferring data. GE MAC 800 and GE E4L require a share folder. We connected a cardiograph and a PC with a LAN cable and set Internet and network protocols.

Figure 1.

System infrastructure.

When ECG signals are ready, the user pushes the transfer button from the cardiograph. The ECG XML file is transferred via a LAN cable using File Transfer Protocol (FTP) over a Transport Control Protocol (TCP)-based network from the cardiograph to be stored in a local directory of a dedicated PC. The communication between the cardiograph and the dedicated PC was commercially designed by the individual ECG companies. At this point, our editing system starts managing the XML file.

Java software called “ECG Recorder” is running on a PC and monitoring the ECG directory. When an XML file is transferred from the cardiograph to a PC, the software reads the file and parses it into XML structure. Only ECG signals from Philips PageWriter are compressed with Philips Healthcare’s Sierra ECG format XLI Compression. ¹⁰ We used the Sierra ECG Tools ¹¹ to decompress and parse data. However, the code was written for ECG XML format (v 1.03). We needed to edit the code to be compatible with ECG XML format (v 1.04). The ECG signals from the other two cardiographs are stored as integer arrays.

Different ECG formats have different infrastructures and contain different values. Only some relevant data are displayed in the ECG. These data are categorized into four groups: hospital number; ECG parameters including heart rate, RR interval, PR interval, QRS duration, QT interval, QT interval corrected by using Bazett’s formula (QTCB), QT interval corrected by using Fridericia’s formula (QTCF), P axis, QRS axis, and T axis; ECG finding including abnormal finding, interpretation, and severity; and ECG signals (from the 12 leads).

The hospital number is the primary key to retrieve patient information from the HIS. Before the ECG is recorded, a hospital number must be entered in the cardiograph. After the ECG is measured, the cardiograph generates an XML file including the hospital number. After the XML file is transferred to a dedicated PC, the editing system which is running on the PC identifies the ECG by using the hospital number and requests the corresponding patient demographic data which are then attached to the ECG. We developed a web service using Simple Object Access Protocol (SOAP) form exchanging patient demographic information. The ECG Recorder software creates a SOAP message containing the patient’s hospital number to the HIS web service Application Programming Interface (API). The server searches for patient information by hospital number and sends this information back to the ECG Recorder software. The API returns standard patient information such as name, date of birth, and address. All information is rendered using Java Graphics2D. Patient information, ECG parameters, ECG interpretation, and ECG findings are drawn as a string, and the ECG signals are drawn as a line graph. The Java Graphics2D provides high-quality 2D graphics for drawing the ECG signal. It supports antialiased rendering which makes the ECG graph smooth and also supports a transform technique which provides a scaling function without pixelation. We designed the ECG appearance as close as possible to a traditional ECG pattern in order to make the user feel comfortable and for ease of use. The ECG appearance is shown in Figure 2.

Figure 2.

ECG paper.

The ECG Recorder software contains several functions, including a clear button to delete a current ECG signal in case of poor quality; a print button to directly print ECG signals (set to A4 paper size, landscape orientation, and data fit to a pager as default properties); and a save button to save the ECG data to a database in a server. A nurse screens the ECG signal quality, patient identity, and hospital number before saving data. The system prevents submitting data if there is no registration place, which means a patient who does not have a hospital service is not allowed to record an ECG.

After a user clicks the save button to save the ECG data, the ECG Recorder software prepares the ECG information. The original ECG format is preserved and compressed by Base64 encoding scheme. The ECG Recorder software creates a new ECG XML file. The whole encrypted data are inserted into a “content” tag of the ECG XML file. The ECG XML file is like an envelope which covers the original ECG as a letter. The ECG XML also contains some information such as name and address on the front of the envelope.

ECG XML structure

• <?xml version="1.0" encoding="UTF-8"?>

• <txn>329400</txn>

• <typ>ipd</typ>

• <dtm_record>2013-03-26 14:16:45</dtm_record>

• <dtm_add>2013-04-29 11:58:09</dtm_add>

• <sender_id>2803589</sender_id>

• <version>1.0</version>

• <encoding>UTF-8</encoding>

• <content>

</content>

</ecg>

The ECG XML content is sent to the server within SOAP to the HIS web service API. The server receives data, compresses the ECG XML file with Base64 encoding scheme, and stores it in a server directory. After the ECG XML file is stored successfully, the server sends a message back to the PC for notifying the status. The status is “COMPLETE” when a file is stored completely. It is “ERROR” when a file is stored incompletely. It is “REPEATED” when the same file is already stored.

On the HIS client computer, there is Java ECG Viewer software which provides functions for viewing ECGs. The software renders the ECG signal using a Java Graphics2D class. We used the Apache Batik Java Scalable Vector Graphics (SVG) toolkit ¹² to convert ECG data to SVG files and convert SVG files to PDF files.

ECG software infrastructure

The system is designed to receive and convert heterogeneous ECG data formats including Philips, GE, and E4L XML schema. The system compresses data and sends them to the server using a common Transmission Control Protocol/Internet Protocol (TCP/IP) network transport protocol. The system unpacks data, draws an ECG graph, and exports to other graphic image formats such as PDF and PNG files.

The basic principles of the ECG software architecture are divided into six elements:

1. Java class loader.

2. XML file receiving monitor.

3. XML parser.

4. ECG renderer.

5. ECG packer and ECG unpacker.

6. Image converter.

The main software for the ECG recording system and viewing system is stored in the server, and the class loader software is distributed on the client computers. When a user starts the class loader software, the class loader in the client PC dynamically loads all necessary classes from the server indicating that the software is temporarily running on the client computers and is then deleted after the software is terminated. The graphic components show and provide options for users to use other elements. The XML file receiving monitor is designed to monitor the creation of an ECG XML file in a PC. Because of commercial reasons, we could not implement direct communication between a cardiograph and a PC. We used a Java basic Input/Output to watch for directory changes. When the XML file is successfully created, this element transfers the data input stream to the XML parser.

The XML parser contains three inner classes. Each class contains a specific XML parser for each ECG data format. Only the ECG format from Philips requires Base64 decoding scheme and Lempel–Ziv–Welch (LWZ) decompression methods. The XML parser extracts information from the data and temporarily stores it as a string and integer array inside each specific XML parser object. When all information is completely retrieved, the XML parser triggers the ECG renderer to draw the patient information, ECG parameters, and an ECG graph. When the ECG XML file is sent for storing into the database, the ECG packer compresses the file using Base64 encoding, inserting the compressed file into a new XML file with essential parameters. On the server side, the ECG packer compresses the file again using Base64 encoding. When the ECG XML file transfers data from the server to the client, the ECG unpacker decompresses the file by applying a reverse process of the ECG packer. The Image converter converts the graphics from the ECG renderer into a PDF or PNG file for printing, private usage, and rendering in the ECG viewer on the web service.

ECG noise are caused from many sources such as alternating current (AC), static electricity, improper electrode contact, and motion artifacts. Other research proposes various algorithms for ECG noise filtering; however, we did not apply any of these because it was already filtered by the cardiograph and applying a double filter might distort ECG signals. We have implemented a smoothing option to improve readability of the ECG waveform. However, smoothing an entire ECG signal will obscure a QRS complex, so we also implemented an algorithm to detect a possible QRS complex.

We used a JTable (Java library) to organize ECG records. The text field above the table is used to filter an ECG list by a sequence of date and time string characters. When a user clicks on the date, an ECG will appear in the left panel.

After receiving data from a server by using SOAP, the ECG Viewer software applies Base64 decoding and gets output as a string. The string is parsed into an XML document and rendered as an ECG image. The ECG image is drawn using Java Graphics2D class and also saved as a temporary image file. When a user grabs and moves an ECG image, the panel redraws by rendering an image file synchronizing it to the moving direction. The software does not redraw the whole graph by using Java Graphics2D but reuses the previous image. This technique reduces rendering resources and shortens painting time while keeping the same rendering quality.

When a user performs a right click, holds it, and drags to create a square, the square represents an area of interest that a user would like to magnify. After releasing the click, the ECG Viewer program redraws the area of interest using Java Graphics2D. This might take a few seconds depending on the scale. Redrawing only focuses on a square area instead of redrawing the whole graph. This shortens drawing time and decreases the usage of stack memory. We could not reuse an image file for the scaling option because the image is not scalable. The scaling of an image file will cause a pixelation problem. We also limit the maximum number of scaling because of a memory stack overflow problem.

A single copy of the ECG Viewer and Recorder software is uploaded to a server and each client computer uses JRunner software to load the most recent version of code via TCP/IP. This helps solve distribution, maintenance, update, and authorization problems with clients.

Results

The Web Ontology Language (OWL)^6,13 has been used to build ontologies to support interoperability between ECG formats. We did not use OWL for our approach because our system is not used for extracting information for clinical research. However, we still partially applied the ontology concept by using Java abstract classes as a common controlled vocabulary. The abstract class acts as a template providing uniform variables and methods. The abstract class inherits commonly used state and behavior into three different subclasses representing each ECG format. The subclasses are specifically designed by overwriting the internal methods to retrieve data from differently named elements in each ECG format and to store this information into uniform variables.

Table 1 shows the ECG terms used for mapping three different ECG formats into specific elements by using Java classes.

Table 1.

The summary of vocabulary mapping in three ECG formats.

Abstract class	Philips XML	GE MAC 800	E4L
Hospital number	patientid	id	HN
Age	age	–	–
Medical signature	mdsignatureline	fullTestStatus	–
ECG finding	statement	statement	AutomaticTypification
Record date	date	acquisitionDateTime	MeasurementTime
Record time	time	acquisitionDateTime	MeasurementTime
Paper speed	timegain	writerSpeed	SamplingInterval
Speed unit	unit	writerSpeed	unit
Amplification	overallgain	frontalLeadGain	SamplingResolution
Amplification unit	unit	frontalLeadGain	unit
Severity	severity	–	–
Heart rate	heartrate	ventricularRate	HR
RR interval	rrint	RR_Interval	avg RR
PR interval	print	PR_Interval	PR int.
QRS duration	qrsdur	QRS_Duration	QRS dur.
QT interval	qtint	QT_Interval	QT int.
QTCB	qtcb	QT_Corrected	Qtc int.
QTCF	qtcf	–	–
P axis	pfrontaxis	P_Axis	P axis
QRS axis	qrsfrontaxis	R_Axis	QRS axis
T axis	tfrontaxis	T_Axis	T axis
Waveform data	Base64 encoding scheme with XLI compression	Array of integer	Array of integer

ECG: electrocardiography; QTCB: QT interval corrected by using Bazett’s formula; QTCF: QT interval corrected by using Fridericia’s formula.

System implementation was conducted in two phases. The first phase was to implement the ECG recording system by distributing the cardiographs to the pilot areas and training staff. The second phase was to implement the ECG Viewer system, which had three options: viewing an ECG using Java ECG Viewer software within HIS; viewing an ECG using Internet Explorer (IE) within HIS; and viewing an ECG using another web browser without HIS but still within the hospital intranet. The first option enables a user to get full functionality of ECG Viewer but requires upgrading HIS and installing a Java Development Kit (JDK). Due to implementation and security issues, the hospital information technology (IT) committee allows installation of JDK only on those PCs which communicate directly with the cardiograph and the server. Alternatively, we developed a parallel ECG viewing system with C++ programming language to use in client computers. Also, an option to use the ECG viewing system on a web browser is provided in case the C++ software does not work. The ECG viewer on the web browser does not require installation of any additional software and is ready to use after the HIS is upgraded; however, the viewer can only be used to render in IE because the HIS is developed under Microsoft Visual Fox Pro which limits web execution only to IE. Unfortunately, IE (version 8) does not support SVG; therefore, we needed to convert SVG to a PNG file and render it in IE. The PNG file decreases the functionality of scaling, so if a user wants to have full functionality of scaling, he or she needs to use the third option. With this option, a user executes a viewer outside HIS but still within the hospital intranet. We created a web link within the hospital website to the viewer which can be executed in other web browsers which support SVG technology. Full functionality of scaling is possible, but the smoothing function is not available for the second and third options.

Despite reducing the cost of using ECG paper, the new system created new costs such as electricity, systems maintenance, computers, and networks. The overall cost of using the new system is more than the old system; however, we achieved many benefits in the effectiveness of data management, improvement of work flow, improvement of data quality, increased availability of information, and improvement in quality of care.

Regarding the effectiveness of data management, the old paper-based system was cumbersome and inefficient, as well as requiring large storage areas. The new automated system means data can be accessed quickly and accurately, and ECGs can be printed when necessary, still maintaining the original quality. Furthermore, the ECG data are more secure as they no longer require patients to carry their own ECGs throughout their hospital visit. This also improves work flow for both doctors and nurses because the information is secure and immediately available. Doctors can easily compare current and previous ECGs and can consult with other staff remotely. Nurses no longer need to scan and file ECGs at the end of each day. By using SVG, there is an immediate improvement in data quality because images can be scaled without signal distortion. This is important if the ECG wave needs to be precisely measured for critical diagnosis. The new system has enormous benefits with the increased availability of the electronic information. In addition to the accessibility improvements mentioned above for an individual patient, a large volume of electronic data is now available for further investigation and analysis in the field of cardiology research. All of these system improvements ultimately lead to improvements in the quality of care provided to patients, both in the short term and the long term.

In designing the new system, we needed to consider a range of security issues, including authentication, authorization, change control and management, communication network accessibility, integrity of data, security auditing systems, encryption, and human issues. Regarding these human issues, we had a group meeting to discuss patient confidentiality and privacy concerns in relation to our hospital’s patient data protection policy.

Discussion

We would like to discuss the lessons learned when attempting to implement a central format–based approach into our existing HIS. Regarding the point about using standardized ECG formats as a global format, one problem observed by researchers from Spain ¹⁴ is that a global format must support every available format. They concluded that a global format is not yet suitable for exchanging ECG records with external applications but is good to provide higher cross-entity interoperability. A research group from the Netherlands ⁴ stated that they had interpretation problems from implementing different SCP-ECG versions. One research group from France ⁵ found that the SCP-ECG protocol has numerous implementation and data fields that are not mandatory and not flexible because it is under the ISO standard. They identified that the extraction of an SCP-ECG file and database insertion requires costly development and suggested an alternative solution to use XML because it is more general, flexible, and open. In accordance with this research, we have chosen to develop our own solution although there are existing commercial available software solutions to convert data to a common format. Additionally, the ECG formats in our situation are not supported by the existing solutions. Even though we could use the available software, we would have to install software and its dependencies, which is hard to distribute to all client computers in our HIS. Another problem is that the current standardized format is not totally compatible for all existing ECG formats. This problem means data conversion could result in data distortion. From the maintenance perspective, using many open-source software solutions creates more complexity and difficulty for long-term software management. Also, our current system is not designed for a cross-hospital system which is usually required for a common format. According to Maharaj Nakorn Chiang Mai Hospital procurement procedures, we could not choose what type of cardiographs we will have because they are bought within the hospital auction system. Therefore, we could not use an ECG ontology idea with full integration of a common protocol such as SCP-ECG because it could not guarantee that a new cardiograph would be fully compatible with the SCP-ECG protocol. There was no sufficient benefit to implement a common protocol because we do not currently exchange electronic medical data with other hospitals. However, we still preserved the original format of every ECG in order to support interoperable implementation in the future.

Consequently, we have chosen to use a common controlled vocabulary in our design to solve the heterogeneous ECG format problem. Our approach using class references provides flexibility to handle individual formats and easily produce a new subclass for a new ECG format within a uniform structure constrained by an abstract class. However, the structure of the abstract class is not part of an existing standard, so it cannot directly apply to other hospital settings.

Our first step was to conduct preliminary research about the current usage of ECGs in Maharaj Nakorn Chiang Mai Hospital. One-third of ECG records are performed at the OPD ECG room, ER, and cardiac center (adult and pediatric). That is why we selected the OPD ECG room and Pediatric cardiac center because of a high-impact sampling number. We initially tried wireless communication between the cardiograph and PC with the HIS wireless system but there was a problem with the security setting from the cardiograph which would not meet our patient data security policy. Then, we had to step back to use a LAN cable. We implemented the ECG recording service first and printed out ECGs on A4 paper for 2 weeks for system buffering transfer. We did not run the ECG viewing system at first because we wanted to make sure that the ECG recording service was stable and allow users to become familiar with the new ECG format and make sure that they understood the new ECG viewing system.

While we were dealing with the interoperability problems of different ECG formats, we realized that we should preserve the structure of each original ECG format. If we inserted new data into a new XML tag, this would distort a standard ECG protocol and could cause parsing problems in the future. Therefore, we came up with the envelope idea. This idea preserves a complete primary format and also provides additional information which is necessary for patient identification. Instead of using a central ECG format, we used a Java class as an interoperable tool. When we have a new ECG format, we write a new Java class for parsing the ECG, value adding to the software without influencing the main system.

During the first day of implementation, we were quite busy. The nurses performed the ECG measurements slower than usual but they quickly learned until the process was smooth. We received many complaints from other departments about the new ECG format. The complaints asked for a full set of parameters and a long ECG Lead II signal. We recorded these complaints and corrected our software.

Only the original ECG XML files are permanently stored in the database. SVG and PNG files are temporarily stored when a patient is active in the HIS. The compression of ECG XML files by Base64 encoding reduces a file size from 200 to 80 kB. For 1 year, if we have 75,000 ECG records, we will save around 9 TB of disk space. Over time, there will also be significant physical space savings as paper records become obsolete.

Overall, we are very happy with the new ECG system and we achieved our aims for the paperless ECG system. This implementation is just the beginning of the digitization and integration of hospital information from a range of health-care devices. We hope that our organization will learn and can gradually move across from a paper-based system to an electronic-based system. The next step will be the integration of all ECG devices into the ECG information system. This will be followed by the extension of the system covering other medical information such as vital signs, monitoring data, ultrasound, and echocardiography.

Conclusion

The integration of ECG data into the HIS is enhancing our data and system management. Although ECG data cannot be cross-exchanged to other hospital systems, we have initially solved the heterogeneity of ECG formats problem by using a central format based on Java classes. This project started in November 2012 and has been implemented since May 2013. We hope to extend this project to cover all ECGs in the hospital and extend it to other medical devices in the future.