Electrocardiography is one of the most important non-invasive diagnostic methods, which can be performed at a low cost and allows the early recognition of coronary heart disease. In today’s distributed healthcare environment, ECG data are commonly acquired, stored and analysed using different formats and software platforms. Various alternatives used for the management and exchange of ECG data still exist. Medical informatics will fully exploit the benefits from its research only when data can be openly shared and interpreted. There is an increasing need to develop cross-platform solutions to support biomedical training, decision-making and telemedicine applications [1].

There is a need to harmonise the representation of digital ECG data originating from the full spectrum of devices along with annotations for events, and to include necessary associated information, such as patient identification, interpretation and other clinical data. The following hierarchical structure is proposed to address such concerns. In this paper terms written in bold prints (i.e. bold and italic) represent either XML element or attribute names. Element names are made of concatenated words with the first letter of each word capitalised ("upperCamelCase"). Attribute names satisfy the same rule except for the first word ("lowerCamelCase").

Each patient record starts with a root element ECGRecord , which is uniquely identified by its attribute studyID . The StudyDate and StudyTime elements represent the latest time record of the study of the ECG recording. Diagnosis contains a text version of the latest diagnostic interpretation of the ECG,while MedicalHistory is a description of the medical history of a patient's clinical problems and diagnoses. There are two main components for each record: one PatientDemographic element and one-or-more Record elements. The tree diagram of the ECGRecord element is given in Figure 1.

Figure 1. The tree diagram of ecgML element ECGRecord

PatientDemographics contains information of general interest concerning the person from whom the recording is obtained, such as demographic data (e.g. patientID , Name , etc.) and contact information (e.g. Address , etc.). This component is required in each record.

Record , shown in Figure 2, represents the physical storage for the basic content of an ECG recording. The AcquisitionDate and AcquisitionTime elements specify date and time the record was taken. investigatorID and siteID are used to identify the responsible person and institution for the recording. There are three main components: zero-or-one RecordingDevice , zero-or-one ClinicalProtocol , and one-or-more RecordDate .

Figure 2. The tree diagram of ecgML element Record

RecordingDevice describes the device that generated the data, while ClinicalProtocol may include information relating to a patient’s clinical report. RecordData is a key ecgML element. There can be multiple RecordData elements within a file, which are identified by their Channel element names. The DICOM lead labelling format is recommended for this purpose[6]. RecordData includes three main sub-components: Waveforms , Annotations and Measurements . The corresponding tree diagrams are illustrated in Figure 3, Figure 4 and Figure 5.

Figure 3. The tree diagram of ecgML element RecordData

Figure 4. The tree diagram of ecgML element Waveform

Figure 5. The tree diagram of ecgML element Annotations

Based on the FDA-recommended PlotGroup format [14], Waveforms are represented by a series of values along two dimensions X, Y ( XValues and YValues ). Annotations would typically be used to describe events specific to the corresponding channel. It defines a time point or interval, which can be used for performing the measurements. This consists of a collection of PointNotation and WaveNotation elements.The Measurements element contains a list of Values (i. e. the measurements of each recorded channel). Each Values element may be associated with a label and a measurement unit .

As mentioned earlier, the FDA, together with a number of other institutions, has developed and published an XML vocabulary [13] [14] to represent collected time-series data. However, there are some significant differences between the FDA proposal and ecgML. The FDA proposal is intended to represent collected biological data, including ECG, electroencephalogram (EEG), or other time series data such as temperature, pressure and oxygen saturation. The main goal is to facilitate the submission of the biological data and to make sure that accuracy and consistency of the measurements made from the collected biological data is achieved. It is important for the FDA to view the biological data in an appropriate way. Thus, the data model (specified in a DTD) includes some presentation information, including elements such as MinorTickInterval, MajorTickInterval and LogScale. On the other hand, ecgML is specific to ECG signals. There are some elements directly related to ECG waveforms, e.g. the elements Pwave , QRSwave and Twave . The purpose of ecgML is to develop an open and transparent way of representing, exchanging and mining ECG data. Therefore, ecgML not only consists of some important components, which may be used to perform knowledge discovery in ECG data (e.g. ClinicalProtocol , Diagnosis and Measurements ) but also follows the principal of separating content and presentation information, which will exhibit great advantages when using ecgML in combination with inter-media transformations (see below).

A series of tools are being developed to assist users in exploiting ecgML-based applications. These include an XML-based ECG record generator, ECG parser and ECG viewer. The generator will automatically produce XML-based ECG records from existing ECG databases, e.g. the MIT-BIH database [2]. The ECG parser allows the user reading the ECG records and access their contents and structure, whereas the ECG viewer provides onscreen display of the corresponding waveform data, shown in Figure 6. It shows all annotation information of the individual waveform. The hierarchical structure of the XML-based ECG record, including every elements and attribute is displayed on the left hand side. It can be expanded and shrunk at any level. The right hand side shows an individual part of the ECG waveform chosen from the ecgML structure. The viewer graphically locates boundaries (i.e. beginning, peak, and end) of the P, QRS and T waveforms for each selected QRS complex.

Figure 6. Screenshot of ECG viewer

Based on advantages of XML technologies, ecgML has the ability to present a system-, application- and format-independent solution for representation and exchange of ECG data. Moreover, a distinct separation of content and presentation (among other components such as links and semantic) exhibits a remarkable advantage over existing systems where information is merged and intertwined with its representation format. Figure 7 exemplifies a scenario where the raw ECG data is kept in an ecgML data file and therefore independently from possible presentation information. Various XSL Transformations (XSLT) (stored as XSL files and applied on the fly, transparent to the user) convert the ecgML source into user- and/or application-specific data formats, such as Moving Picture Experts Group (MPEG) (audio), MatLab (text) and SVG/Portable Network Graphics (PNG) (graphics). The centralised storage of the ECG record and dynamic creation of data representations avoids redundancy.

Figure 7. Dynamic transformation of ecgML data

The data and metadata contained in an ecgML record may be useful to improve pattern recognition in ECG applications. It would also aid the implementation of automated decision support models such as case-based reasoning. The proposed ecgML may also be significant for problems such as future proof storage, context-sensitive (textual) search of patterns in ECG data, and its native inclusion into medical guidelines. Figure 8 illustrates the utilisation of map files to convert "raw" ecgML files into different tabular data, which will be imported into data mining systems for further analysis.

Figure 8. Converting XML into Tabular data using map files

ecgML will enable the seamless integration of ECG data into Electronic Patient Records and medical guidelines. This protocol can support data exchange between different ECG acquisition and visualisation devices. The accompanying application comfortably supports medical tasks such as pattern recognition and identification of relevant wave markers. The advantages of separating content from presentation information has proven very successful, where ECG data stored in the ecgML can be delivered in customised output format to suit different devices and applications. Thus, ecgML is a useful tool to facilitate the representation, exchange and interpretation of ECG information. Further research will address the following issues.