- Research article
- Open Access
- Open Peer Review
XML-BSPM: an XML format for storing Body Surface Potential Map recordings
- Raymond R Bond1Email author,
- Dewar D Finlay†1,
- Chris D Nugent†1 and
- George Moore†1
https://doi.org/10.1186/1472-6947-10-28
© Bond et al; licensee BioMed Central Ltd. 2010
- Received: 15 February 2010
- Accepted: 14 May 2010
- Published: 14 May 2010
Abstract
Background
The Body Surface Potential Map (BSPM) is an electrocardiographic method, for recording and displaying the electrical activity of the heart, from a spatial perspective. The BSPM has been deemed more accurate for assessing certain cardiac pathologies when compared to the 12-lead ECG. Nevertheless, the 12-lead ECG remains the most popular ECG acquisition method for non-invasively assessing the electrical activity of the heart. Although data from the 12-lead ECG can be stored and shared using open formats such as SCP-ECG, no open formats currently exist for storing and sharing the BSPM. As a result, an innovative format for storing BSPM datasets has been developed within this study.
Methods
The XML vocabulary was chosen for implementation, as opposed to binary for the purpose of human readability. There are currently no standards to dictate the number of electrodes and electrode positions for recording a BSPM. In fact, there are at least 11 different BSPM electrode configurations in use today. Therefore, in order to support these BSPM variants, the XML-BSPM format was made versatile. Hence, the format supports the storage of custom torso diagrams using SVG graphics. This diagram can then be used in a 2D coordinate system for retaining electrode positions.
Results
This XML-BSPM format has been successfully used to store the Kornreich-117 BSPM dataset and the Lux-192 BSPM dataset. The resulting file sizes were in the region of 277 kilobytes for each BSPM recording and can be deemed suitable for example, for use with any telemonitoring application. Moreover, there is potential for file sizes to be further reduced using basic compression algorithms, i.e. the deflate algorithm. Finally, these BSPM files have been parsed and visualised within a convenient time period using a web based BSPM viewer.
Conclusions
This format, if widely adopted could promote BSPM interoperability, knowledge sharing and data mining. This work could also be used to provide conceptual solutions and inspire existing formats such as DICOM, SCP-ECG and aECG to support the storage of BSPMs. In summary, this research provides initial ground work for creating a complete BSPM management system.
Keywords
- File Size
- Electrode Position
- Scalable Vector Graphic
- Diagram Element
- Limb Lead
Background
The Body Surface Potential Map
The Body Surface Potential Map (BSPM) is a specialised electrocardiographic method, for recording and displaying the electrical activity of the heart, from a spatial perspective. The BSPM has been deemed more accurate for diagnosing certain cardiac pathologies, when compared to the 12-lead electrocardiogram (ECG) [1, 2]. The major advantage of the BSPM is its ability to display electrical information in the spatial domain. This is achieved by placing a large number of electrodes (32-213) around the human torso, whereas the 12-lead ECG utilizes six thoracic electrodes which are subject to a limited anatomical area, namely the precordium [3].
Importance of interoperability
Interoperability is an important area of research, since it promotes the intercommunication of clinical documents between heterogeneous hospital information systems [4]. The predominant driver in promoting interoperability has been the development of open formats for storing clinical information [5]. These open formats can be easily integrated into the Electronic Patient Health Record (EPHR). Moreover, according to Fischer et al. [6], cardiological information is progressively being introduced into the EPHR. This is just one reason why a BSPM format should be created. Although the BSPM has been clinically proven to be more accurate for diagnosing cardiac patients, no work has been undertaken to improve the interoperability of BSPM data. Scientists currently store BSPM datasets in a number of custom formats which include propriety data files (e.g. MATLAB, Map3D) and format specific files (formatted Comma Separated Values).
ECG formats
A plethora of open formats have been created for storing and transmitting the ECG. These formats have been based around more familiar recording methods such as the 12-lead ECG. The three major industrial ECG formats exist; the Digital Imaging and Communication in Medicine ECG (DICOM-ECG) format; Health Level 7 Annotated ECG (HL7/aECG) and the Standardised Communication Protocol ECG (SCP-ECG) format. Other influential ECG formats include ecgML [7], XML-ECG [8], MFER [9], to name but a few. The following Sections provide a more detailed overview of each of the aforementioned three major formats.
DICOM-ECG
The DICOM standard, formally known as ACR-NEMA was created by the National Electrical Manufactures Association (NEMA) in 1985 [10, 11]. ACR-NEMA evolved as DICOM version 3 in 1993, and became a European standard in 1995. The DICOM format originally stored radiographic raster images, from diagnostic devices such as the X-RAY [12]. DICOM now endeavours to support all diagnostic modalities including the ECG. As a result, DICOM waveform supplement 30 was introduced in the year 2000. This extension enables the storage of raw waveform datasets i.e. blood pressure, audio and the ECG. Within the ECG community, DICOM supplement 30 is also called DICOM-ECG.
HL7
The Annotated ECG (aECG) format was created in partnership between the Health Level 7 and the US Food and Drug Administration (FDA) in 2001 [13]. It was then accepted as a standard by the American National Standards Institute (ANSI) in 2004. The FDA where collecting a large number of ECGs, submitted by pharmaceutical companies for clinical trials. These ECGs where submitted in various formats, some of which where hard copies that had to be scanned for electronic storage. The aECG format was therefore created to improve the administration tasks of managing such a complicated process. This was the first ECG format based on the eXtensible Markup Language (XML).
SCP-ECG
The SCP-ECG format is a compressed binary based format that takes advantage of Huffman encoding. In 2002, SCP-ECG became a promotion of the European funded OpenECG consortium [5]. The OpenECG network is a body of people dedicated to the interoperability in digital electrocardiography. According to Chronaki et al., they have at least 464 members [14]. In 2005, the SCP-ECG format became the official European standard for the storage and transmission of ECGs [5, 14].
All of the aforementioned ECG formats are non proprietary and are therefore capable of achieving interoperability, whereas many ECG Management Systems (EMS) integrate closed proprietary formats into the EPHR. These closed formats include Unipro, Sifor and MDW [15].
Storage requirements
12-lead ECG | BSPM | |
---|---|---|
Electrodes | 10 | 32-213 |
Bipolar leads | 3 | 0 |
Unipolar leads | 9 | 32-213 *All unipolar, each electrode has an associated unipolar lead. |
Electrode positions | Standardized. | Non-standardized *Range of different layouts. |
Calculated leads | Standard calculations for generating limb leads aVF, aVL, aVR and III. | Non standardized * Range of limited lead sets, for example the Lux-32 layout expands to Lux-192 using coefficients. |
Data | Usually a 10 second recording. | No set recording time. Some BSPMs store single beats. |
Formatting requirements | Requires a strict standard format since the 12-lead ECG is well standardized. | Requires a versatile format to support a range of electrode layouts. |
Display | 12 waveforms are usually rendered onto formatted graph paper, i.e. "3 × 4 + 1". | No standard representation exists. Can be displayed as a series of scalar traces or as a contour map. * Electrode positions must be known to generate a contour map. |
Diagnostic criteria | Diagnostic criteria have been well defined. | Very little diagnostic criteria exist. |
Accessibility and cost of equipment | Very accessible within the healthcare industry and relatively inexpensive. | Not all hospitals have a BSPM recording and visualisation system. Equipment can be expensive and hard to get. |
BSPM electrode configuration. This diagram illustrates the diversity in BSPM electrode configuration. a) This represents the anatomical locations of the 219 electrodes employed by the Parma lead set. b) This represents the anatomical locations of the 32 electrodes employed by the Lux Anterior lead set.
In contrast to the BSPM, the 12-lead ECG has been standardised since 1938 [17]. The 12-lead ECG utilizes 10 electrodes, which are positioned at well defined anatomical locations [18]. These include six chest electrodes which are placed at specific well defined landmarks on the precordium. It is these specifics that have made it easy to develop storage formats for the 12-lead ECG. Conversely, it is the lack of specifics, hence versatility in BSPM acquisition that leaves the community with the huge challenge of defining a format that supports all BSPM variations. Out of the existing formats, SCP-ECG supports up to 255 leads. These are, however, predefined leads, i.e. right sided chest leads [19]. The format is therefore not versatile enough to support BSPMs. Likewise, a simple change to the aECG specification would enable the storage of an arbitrary number of leads. Unfortunately, this would still leave the problem of storing the actual electrode positions. Given that the current ECG formats focus on storing 12-lead ECG data, such formats do not retain electrode positions because they are standardised and can be easily observed in clinical literature.
Example BSPM. An unrolled 2D torso diagram displaying 192 averaged beats.
- 1.
Supporting custom torso diagrams.
- 2.
Storing an arbitrary number of leads.
- 3.
Storing the associated electrode positions for each lead.
From these three challenges, storing electrode positions is the most challenging and arguably the most important aspect of a BSPM format. Electrode positions are required for clinical reference and for visualising the BSPM data, i.e. contour plotting.
Methods
There are a number of options when developing a solution to the BSPM storage problem. One option is to propose a BSPM extension to one of the current ECG formats such as SCP-ECG. Another option is to create a new BSPM format. The former option promotes the philosophy of supporting all ECG acquisition methods using a single format. This is similar to the DICOM philosophy, where the aim is to support all diagnostic modalities under one standard. The latter option involves the creation of a specialised format that will only store one ECG acquisition method, namely the BSPM.
Within our current work we have opted to adopt the strategy of creating a specialised format. This decision is partially attributed to the fact that there has been a development in growth in specialised ECG formats. These formats include ecgAware [20], which concentrates on storing ambulatory ECG data, and mECG [21] which concentrates on storing ECG data for mobile devices. Goncalves et al. created the ecgAware format because existing formats such as aECG and ecgML do not support ambulatory ECG monitoring, i.e. Holter monitoring. It is not obvious whether the advantages of general formats like DICOM outweigh the advantages of specific formats such as the ecgAware format. General formats are usually more complex, since they manage a large specification to support a range of modalities, whereas specific formats do not have this complication. Furthermore, since BSPMs are not as standardised as other ECG acquisition methods, a specialised BSPM format is more appropriate rather than integrating a complex BSPM extension into an existing format. If the proposed BSPM format is not industrialised, then this work, at least, provides the rationale for extending an existing format.
Implementation Method
XML technologies. This diagram depicts a plethora of XML related technologies that can be combined with XML-BSPM.
BSPM XML tree structure. Overview of the BSPM XML tree structure. The format is split into two main sections, the header, which retains the meta-data and the leads section, which stores the actual ECG values.
The root element
The root element bspm stores two required attributes called type and id. The attribute type defines what kind of BSPM data the file is storing. It therefore, indicates to a human observer or a computer program the type of data it is to expect. This is important as there are different methods for recording BSPM data. The type attribute can have one of four values (AVERAGED-BEATS-BSPM, AVERAGED-BEATS-BSPM-TRANSFORM, CONTINUOUS-BSPM or CONTINUOUS -BSPM-TRANSFORM). The value AVERAGED-BEATS-BSPM is used when each lead element within the format stores one single beat as raw number values, whereas the value AVERAGED-BEATS-BSPM-TRANSFORM indicates that some leads are derived, in that they contain equations as opposed to raw number values. Supporting derived leads is important because there has been substantial research carried out within the ECG community that involves limited lead sets and BSPM transformations [25]. The value CONTINUOUS-BEATS-BSPM, as the name suggests, is used when continuous data is stored for each lead. The value CONTINUOUS-BSPM-TRANSFORM is used to indicate the storage of multiple beats, some of which are stored in raw form and the derived leads are stored as mathematical equations. The attribute id is used to either uniquely identify a document or to associate the file with a database.
Description of the root element (bspm)
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
type | Required | AVERAGED-BEATS-BSPM/AVERAGED- BEATS -BSPM-TRANSFORM/CONTINUOUS-BSPM/CONTINUOUS - BSPM-TRANSFORM | This format can store four types of BSPMs. |
id | Required | String | For associating the file with a database. |
Elements | |||
Name | Required | Data type | Description |
header | Required | See header table. | This element separates the data from metadata, presenting the format in a coherent fashion. |
leads | Required | See leads table. | This element groups the entire lead data. It has been named leads as opposed to channels because all BSPM leads are unipolar. |
The header element
Description of the header element
Elements | |||
---|---|---|---|
Name | Required | Data type | Description |
patient | Required | See patient table. | Patient demographics and diagnosis. |
record | Required | See record table. | Information about the recording settings, i.e. device, time, and recording physician etc. |
annotations | Required | See annotations table. | This is a wrapper element for storing beat markers, i.e. p onset. |
comments | Optional | See comments table. | This can be used for collaboration and discussion amongst clinicians. |
limbLeads | Optional | See limbLeads table. | Some BSPM datasets retain the limb leads that were used to calculate the Wilson Central Terminal (WCT). These limb leads can be stored here and may prove useful in post processing. |
transformations | Optional | See transformations table. | This is where equations can be stored to transform the BSPM into the 12-lead ECG or the VCG. |
diagram | Required | CDATA, see diagram table for attributes. | This element stores an SVG diagram that represents an unrolled 2D torso. |
Description of the patient element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
id | Required | String | This is used to uniquely identify a patient, e.g. 0000001. |
Elements | |||
Name | Required | Data type | Description |
fullName | Optional | String | Name of the patient, e.g. John Smith. |
sex | Optional | male/female/unspecified/unknown | E.g. male. |
DOB | Optional | Date YYYY-MM-DD | E.g. 1984-06-24. |
address | Optional | String | E.g. 47 University street |
city | Optional | String | E.g. Belfast |
state | Optional | String | E.g. Antrim |
country | Optional | String | E.g. Northern Ireland |
postalCode(ZipCode) | Optional | String | This element can store either a postcode or a Zipcode, e.g. BT37 0QB. |
phone | Optional | String | The data type is string to support commas and hyphens, e.g. 08 700 400 700. |
fax | Optional | String | E.g. 08 700 400 700. |
Optional | String | E.g. johnsmith@myemailhost.com | |
diagnosis | Optional | String | This element is for storing the patient's diagnosis, as perceived by a clinician, e.g. Acute Myocardial Infarction. |
computerisedDiagnosis | Optional | String | This element is used to record the predicted diagnosis made by a computerised classification algorithm, e.g. Left Bundle Branch Block. |
Description of the record element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
recordingDevice | Optional | String | The name of the device used to record the BSPM, e.g. VCM-3000. |
recordingTime | Optional | Time:HH:MM:SS:SSS | The time of day the recording took place, e.g. 12:50:00:000. |
recordingDate | Optional | Date YYYY-MM-DD | The date the recording took place, e.g. 2009-08-28. |
investigator | Optional | String | The name of the recording clinician, e.g. Fred Kornreich. |
layoutName | Required | String | The name of BSPM configuration method, e.g. Lux-192. |
leads | Required | Integer | This records the number of leads that have been stored within the leads element, e.g. 192. |
samples | Required | Integer | This stores the number of sample values that have been stored for each lead, e.g.600. |
frequency | Required | String | Number of samples per second recorded in Hertz, e.g. "1000 Hz" can be interpreted as 1000 samples per second. |
sampleMultiplier | Optional | Float DEFAULT: 1 | This is the number each sample value must be multiplied by, in order to get the actual value. If this attribute does not exist, the value defaults to 1. |
Elements | |||
Name | Required | Data type | Description |
notes | Optional | String | This allows the investigator to include notes that best describe the recording procedure. |
record element. An XML excerpt of the record element, illustrating the readability of its attributes.
Description of the annotations element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
HR | Optional | Integer | The Heart Rate can be stored, because a patient's heart rate can not be calculated from a single beat, e.g. 70 bpm. |
pAxis | Optional | Integer | In degrees, e.g. 40°. |
qrsAxis | Optional | Integer | In degrees, e.g. 70°. |
tAxis | Optional | Integer | In degrees, e.g. 50°. |
Elements | |||
Name | Required | Data type | Description |
leadAnn | Required | See leadAnn table. | leadAnn stands for lead annotation. |
Description of the leadAnn element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
leadID | Required | String | This value corresponds to the id attribute stored within each lead element. This attribute is used to identify which lead the beat markers are referring to. The value * means that the beat markers refer to all the leads. |
Elements | |||
Name | Required | Data type | Description |
pOnset | Optional | String | Stores the onset of the P deflection. Multiple values are stored as CSV. |
pOffset | Optional | String | Stores the offset of the P deflection. Multiple values are stored as CSV. |
qrsOnset | Optional | String | Stores the onset of the QRS deflection. Multiple values are stored as CSV. |
qrsOffset | Optional | String | Stores the offset of the QRS deflection. Multiple values are stored as CSV. |
tOnset | Optional | String | Stores the onset of the T deflection. Multiple values are stored as CSV. |
tOffset | Optional | String | Stores the offset of the T deflection. Multiple values are stored as CSV. |
uOnset | Optional | String | Stores the onset of theU deflection. Multiple values are stored as CSV. |
uOffset | Optional | String | Stores the offset of the U deflection. Multiple values are stored as CSV. |
Description of the section element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
leadID | Optional | String | This attribute is used to specify which lead the sub comments refer to. If a comment refers to all leads, the value "*" can be used. |
ms | Optional | Float | This ms (milliseconds) attribute specifies which part of the waveform the sub comments are referring to. |
mV | Optional | Float | The voltage level at which the sub comments are referring to. |
Elements | |||
Name | Required | Data type | Description |
Comment | optional | String, see comment table for attributes | Comments can be used for collaboration and knowledge sharing amongst researchers and/or clinicians. |
Description of the comment element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
fullName | Required | Float | Storing the full name is useful for tracking discussions, e.g. Dr. John Smith. |
Optional | Float | Email can be used for both identification and correspondence. | |
date | Required | Date YYYY-MM-DD | E.g. 12:50:00:000. |
time | Required | Time:HH:MM:SS:SSS | E.g. 2009-08-28. |
Representing comments. A mock-up of how the comments feature could be presented in a BSPM viewing system.
Description of the limbLeads element
Elements | |||
---|---|---|---|
Name | Required | Data type | Description |
limbLead | Required | String | Stores limb lead data. Multiple values are stored as CSV. |
Attributes(for limblead element) | |||
Name | Required | Data type | Description |
name | Required | aVF/aVR/aVL/I/II/II/VF/VR/VL | Stores the name of the limb lead. |
Description of the transformations element
Elements | |||
---|---|---|---|
Name | Required | Data type | Description |
transformation | Required | See transformation table. | This element, for example can store equations for extracting the 12-lead ECG from the BSPM. It can also be used to transform one BSPM dataset into another. |
Description of the transformation element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
name | Required | String | This attribute stores the name of the transformation dataset, i.e. 12-lead ECG, VCG or BSPM. |
url | Optional | String | This attribute retains a link to an XML file containing the calculations. |
Elements | |||
Name | Required | Data type | Description |
transformLead | Required | See transformLead table. | This stores an equation which when executed calculates a new lead. e.g. ([Lead52] + [Lead53])/2 |
Description of the transformLead element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
name | Required | String | This attribute stores the name of the lead, e.g. aVF. |
x | Optional | Float | Stores the × axis for deriving the electrode position in relation to the thoracic diagram. |
y | Optional | Float | Stores the y axis for deriving the electrode position in relation to the thoracic diagram. |
location | Optional | A/P/LL/RL | Stores the general thoracic area of where the electrode was attached. |
myocardialRegion | Optional | An/HP/TP/IP/I/L/Ap/RV/S | Refers to the corresponding myocardial region. |
The rationale for storing equations in a BSPM format is that there are many custom electrode layouts. Therefore, each layout warrants its own unique set of equations for deriving, for example, the 12-lead ECG. Such calculations are also required as BSPM configurations do not usually contain the 12-lead ECG precordial electrode positions as a subset. Nevertheless, there is at least one BSPM lead configuration which has the six precordial leads as a subset of the BSPM leads [28], but most BSPM systems do not include all six precordial leads.
transformLead element. This diagram depicts how the transformLead element might be used to store a mean equation for calculating lead V1.
The diagram element is a required sub element of the header tag. It is required as it stores an unrolled torso schematic that is used as a reference diagram in a 2D coordinate system. This 2D coordinate system is used for storing electrode positions relative to the torso. This format must store electrode positions, in order to support different BSPM electrode layouts. Knowledge of electrode positions is also useful for clinical reference and visualizing the BSPM, i.e. contour plotting. Interestingly, like the BSPM, the number of electrodes used in certain instances to record an electroencephalogram (EEG) is not as standardised. These electrodes can also be positioned at custom cranial landmarks. Therefore, since the EEG and the BSPM are not as standardised as the 12-lead ECG, some EEG formats such as the Extensible Biosignal Format (EBS) store the actual electrode positions. The EBS format was created in 1993 by Marcus Kuhn and the specification is freely available online [29]. The EBS format stores the electrode positions within the header of the file using a Computer Graphics Metafile (CGM). These EEG formatting concepts provided inspiration in the development of the proposed BSPM format.
The diagram element has two optional attributes called url and waveScale. The url attribute is an abbreviation for Uniform Resource Locator (URL). This attribute stores a path or a web address to a torso diagram, which can reside either on the internet or on a local network. The waveScale attribute stores a float value between zero and one. This value is used to proportionally scale BSPM leads (scalar traces) to fit comfortably in their associated electrode positions, in relation to the size of the torso diagram. For example, the value 0.1 would scale the waveforms to 10 percent of their actual size. Although this attribute is optional, if it does not exist then the value defaults to 0.04, which scales all waveforms to 4% of their actual size. This default value has been chosen, as it proportionally scales waveforms in relation to torso diagrams that are approximately the size of an A4 piece of paper. This is a standard paper size within the UK.
The advantage of implementing a format in XML as opposed to binary is its accessibility to a suite of related XML technologies, i.e. Scalable Vector Graphics (SVG). SVG is a W3C recommendation and an XML language for describing images [30]. The diagram element stores an unrolled 2D torso schematic using SVG. This element is similar to the idea suggested in another study [31], which is to integrate a photograph of the subject into the format, in order to retain electrode locations.
SVG torso diagrams. a) A simple one kilobyte SVG torso diagram. b) A more complex nine kilobyte torso diagram, which includes drawings of the intercostal spaces.
Description of the diagram element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
url | Optional | String | This attribute can store an external link to an SVG diagram, e.g.: http://www.raymondbond.com/bspmDiagram.svg |
waveScale | Optional | Float, DEFAULT: 0.04 | This value is used to proportionally scale the waveforms in relation to the size of the torso diagram, e.g.: "0.04" scales the leads to 4% of their actual size. |
Embedded SVG diagram. This is an excerpt of the XML-BSPM format depicting the storage of the SVG diagram.
The leads element is a sub element of the root element, bspm. This element acts as a wrapper tag that accumulates all the subordinate BSPM leads. Hence, the leads element has one sub element called lead, which can appear multiple times. As its name suggests, each lead element stores a unipolar ECG lead. Other ECG formats store lead data using a different name, i.e. aECG [13] uses the name 'digits' and the ecgML [7] format uses the name 'channel'.
Description of the lead element
Attributes | |||
---|---|---|---|
Name | Required | Data type | Description |
Id | Required | Integer | This integer is used to uniquely identify and number each lead. |
X | Required | Float | Stores the × axis for deriving the electrode position in relation to the thoracic diagram. |
Y | Required | Float | Stores the y axis for deriving the electrode position in relation to the thoracic diagram. |
Location | Optional | A/P/LL/RL | Stores the general thoracic area of where the electrode was attached. |
myocardialRegion | Optional | An/HP/TP/IP/I/L/Ap/RV/S | Refers to the corresponding myocardial region. |
Data | Optional | raw/calc DEFAULT: 'raw' | Defines whether the lead stores raw data or a calculation. |
Storing electrode positions. This diagram illustrates a 2D coordinate system of how the attributes x and y are used to derive an electrode position.
Calculated leads. This is an excerpt of the leads element where the type attribute has been used to distinguish between calculated leads and raw leads.
Results
Evaluation of the format
Lux-192 BSPM. Lux-192 electrode layout consisting of 192 electrodes equally spaced throughout a custom torso diagram.
A comparison of BSPM file sizes when the file is stored as XML or compressed using either the ZIP or GZIP compression algorithms
BSPM dataset | Raw XML | ZIP compression | GZIP compression |
---|---|---|---|
Lux-192 BSPM | 293 kilobytes | 76 kilobytes | 68 kilobytes |
Kornreich-117 BSPM | 257 kilobytes | 110 kilobytes | 111 kilobytes |
Kornreich-117 BSPM. Kornreich-117 electrode layout consisting of 117 electrodes placed throughout a custom torso diagram.
To truly evaluate this format and in particular, its file size, it would seem appropriate to compare these files with other BSPM files that have been formatted by a different standard. This is complicated by the fact that no other BSPM format exists. It would also be difficult to compare BSPM files with 12-lead ECG files that have been formatted with, for example SCP-ECG, since the storage of 8 leads and 200 leads are not comparable. Some 12-lead ECG files formatted using the aECG format can be as large as 500 kilobytes, which is a lot larger than the BSPM files that have just been evaluated within this study.
Evaluation of the transformation feature
Extracting the 12-lead. The 12-lead ECG in relation to the Lux-192 BSPM and the basic equations used for extracting the 12-lead ECG from the BSPM.
Extracting the VCG. This diagram highlights the leads from the Lux-192 BSPM and the equations used to calculate the VCG.
12-lead ECG and VCG equations. This diagram contains the 12-lead ECG and the VCG equations as defined within the XML-BSPM format.
Discussion
Accompanying tools
BSPM viewer. A web based BSPM viewer for parsing, processing and visualising XML-BSPM files.
Future work
The format proposed in this paper has been developed to the level where it is useable. However, a number of additional tests are foreseen to prove the full utility of the format. These tests include the ability to securely store long term/continuous data as opposed to averaged beats and the ability to support data recorded from limited lead sets. Further work will also include the completion of the web based BSPM viewer, a format validation service, a BSPM to SVG converter and possibly an online warehouse, where users can share and download BSPMs. In summary, this research provides initial ground work for creating a complete BSPM management system.
Conclusions
The work presented in this paper documents one of the first attempts to establish a storage format that supports data recorded from any BSPM recording configuration. The primary goal has been to promote the storage and sharing of data that traditionally has not been widely accessible. Although the format has been conceived, bearing in mind the requirements of storing data recorded from a large number of leads, it can in fact be used to support data from any ECG recording. That said, this proposed format should not be seen as a competitor to well established formats such as SCP-ECG, DICOM and aECG. The lessons learned in this work and reported in this paper can be used for the further development of existing ECG formats and standards; which in the future may be enhanced to support BSPM leads.
Notes
Declarations
Acknowledgements
The authors would like to acknowledge Professor Robert Lux and Professor Fred Kornreich for provision of BSPM data.
Authors’ Affiliations
References
- Carley SD, Jenkins M, Jones KM: Body surface mapping versus the standard 12 lead ECG in the detection of myocardial infarction amongst emergency department patients: a Bayesian approach. Resuscitation. 2005, 64 (3): 309-314. 10.1016/j.resuscitation.2004.10.002.View ArticlePubMedGoogle Scholar
- McClelland AJJ, Owens CG, Menown IBA, Lown M, Adgey AAJ: Comparison of the 80-lead body surface map to physician and to 12-lead electrocardiogram in detection of acute myocardial infarction. Am J Cardiol. 2003, 92 (3): 252-257. 10.1016/S0002-9149(03)00619-2.View ArticlePubMedGoogle Scholar
- Lux RL: Uncertainty of the electrocardiogram: old and new ideas for assessment and interpretation. J Electrocardiol. 2000, 33 (Suppl): 203-208. 10.1054/jelc.2000.20347.View ArticlePubMedGoogle Scholar
- Sfakianakis S, Chronaki CE, Chiarugi F, Conforti F, Katehakis DG: Reflections on the role of open source in health information system interoperability. Yearb Med Inform. 2007, 50-60.Google Scholar
- Chronaki CE, Chiarugi F, Macerata A, Conforti F, Voss H, Johansen I, Ruiz-Fernandez R, Zywietz C: Interoperability in digital electrocardiography after the openECG project. Proceedings of IEEE Computers in Cardiology. 2004, 49-52.Google Scholar
- Fischer R, Chiarugi F, Zywietz TK: Enhanced integrated format and content checking for processing of SCP ECG records. In Proceedings of IEEE Computers in Cardiology. 2006, 413-416.Google Scholar
- Wang H, Azuaje F, Jung B, Black N: A markup language for electrocardiogram data acquisition and analysis (ecgML). BMC Medical Informatics and Decision Making. 2003, 3 (1): 4-10.1186/1472-6947-3-4.View ArticlePubMedPubMed CentralGoogle Scholar
- Lu X, Duan H, Zheng H: XML-ECG: An XML-based ECG presentation for data exchanging. In Proceedings of Bioinformatics and Biomedical Engineering ICBBE. 2007, 1141-1144. full_text.Google Scholar
- ECG description in MFER and HL7 version 3. [http://kosmi.snubi.org/2003_fall/APAMI_CJKMI/O8-4-023-Hirai-0829.pdf]
- Mildenberger P, Eichelberg M, Martin E: Introduction to DICOM. European radiology. 2002, 12 (4): 920-927. 10.1007/s003300101100.View ArticlePubMedGoogle Scholar
- Dicom.offis.de - general information - introduction to the DICOM standard. [http://dicom.offis.de/dcmintro.php.en]
- Hilbel T, Brown BD, de Bie J, Lux RL, Katus HA: Innovation and advantage of the DICOM ECG standard for viewing, interchange and permanent archiving of the diagnostic electrocardiogram. In Proceedings of IEEE Computers in Cardiology Conference. 2007, Durham, 633-636.Google Scholar
- HL7 aECG implementation guide. [http://www.amps-llc.com/UsefulDocs/aECG_Implementation_Guide.pdf]
- Chronaki CE, Chiarugi F, Sfakianakis S, Zywietz C: A web service for conformance testing of ECG records to the SPC-ECG standard. In Proceedings of IEEE Computers in Cardiology Conference. 2005, Lyon, 961-964.Google Scholar
- de Wijs MCJ, van Ettinger M, Meij SH, Nelwan SP: Integration of multiple ECG databases into a unified framework. In Proceedings of IEEE Computers in Cardiology Conference. 2005, Lyon, 447-450.Google Scholar
- Hoekema R, Uijen GJH, van Oosterom A: On selecting a body surface mapping procedure. Journal of Electrocardiology. 1999, 32 (2): 93-101. 10.1016/S0022-0736(99)90088-2.View ArticlePubMedGoogle Scholar
- Joint recommendations of the American Heart Association and the Cardiac Society of Great Britain and Ireland: Standardization of precordial leads. Am Heart J. 1938, 15: 107-108. 10.1016/S0002-8703(38)90039-0.View ArticleGoogle Scholar
- Hampton JR: The ECG made easy. 2003, Edinburgh; New York: Churchill Livingstone, 6Google Scholar
- How to implement SCP - part I. [http://www.openecg.net/tutorial1/index.html]
- ECGAWARE An ECG markup language for ambulatory telemonitoring and decision making support. [http://www.inf.ufes.br/~bgoncalves/contents/healthinf08.pdf]
- Fang Q, Sufi F, Cosic I: A Mobile Device Based ECG Analysis System. In Data Mining in Medical and Biological Research. Edited by: Giannopoulou GE. 2008, 209-225. IN-TECHGoogle Scholar
- Ng W, Lam W, Cheng J: Comparative Analysis of XML Compression Technologies. World Wide Web. 2006, 9 (1): 5-33. 10.1007/s11280-005-1435-2.View ArticleGoogle Scholar
- How XML is improving data exchange in healthcare. [http://www.softwareag.com/xml/library/schroeter_healthcare.htm]
- FDA XML Data Format Design Specification. [http://xml.coverpages.org/FDA-EGC-XMLDataFormat-C.pdf]
- Donnelly MP, Nugent CD, Finlay DD, Black ND: Diagnostic assessment of transformation of body surface potential mapping lead systems. J Electrocardiol. 2006, 39 (4, Supplement 1): S31-S32. 10.1016/j.jelectrocard.2006.08.042.View ArticleGoogle Scholar
- Montague TJ, Smith ER, Cameron DA, Rautaharju PM, Klassen GA, Felmington CS, Horacek BM: Isointegral analysis of body surface maps: surface distribution and temporal variability in normal subjects. Circulation. 1981, 63 (5): 1166-1172.View ArticlePubMedGoogle Scholar
- Horácek BM, Warren JW, Feild DQ, Feldman CL: Statistical and deterministic approaches to designing transformations of electrocardiographic leads. J Electrocardiol. 2002, 35 (4, Part 2): 41-52. 10.1054/jelc.2002.37154.View ArticlePubMedGoogle Scholar
- Robinson MR, Curzen N: Electrocardiographic Body Surface Mapping: Potential Tool for the Detection of Transient Myocardial Ischemia in the 21st Century?. Annals of Noninvasive Electrocardiology. 2009, 14 (2): 201-210. 10.1111/j.1542-474X.2009.00284.x.View ArticlePubMedGoogle Scholar
- Specification of the EBS file format for bio-signals. [http://www.cl.cam.ac.uk/~mgk25/ebs/]
- Scalable vector graphics. [http://www.w3.org/Graphics/SVG/]
- Varni A, Kemp B, Penzel T, Schlogl A: Standards for biomedical signal databases. IEEE Eng Med Biol. 2001, 20 (3): 33-37. 10.1109/51.932722.View ArticleGoogle Scholar
- Lux RL, Smith CR, Wyatt RF, Abildskov JA: Limited Lead Selection for Estimation of Body Surface Potential Maps in Electrocardiography. IEEE Transactions on Biomedical Engineering. 1978, 25 (3): 270-276. 10.1109/TBME.1978.326332.View ArticlePubMedGoogle Scholar
- Drew BJ, Schindler DM, Zegre JK, Fleischmann KE, Lux RL: Estimated body surface potential maps in emergency department patients with unrecognized transient myocardial ischemia. J Electrocardiol. 2007, 40 (6S1): 15-20. 10.1016/j.jelectrocard.2007.05.032.View ArticleGoogle Scholar
- Frank E: An accurate, clinically practical system for spatial vectorcardiography. Circulation. 1956, 13 (5): 737-749.View ArticlePubMedGoogle Scholar
- ECG measurement and analysis. [http://www.cvrti.utah.edu/~macleod/bioen/be6000/labnotes/ecg/descrip.html]
- Body surface potential map viewer. [http://bspm.raymondbond.com/]
- Adobe flash player. [http://www.adobe.com/products/flashplayer/]
- MacLeod RS, Johnson CR: Map3d: Interactive scientific visualization for bioengineering data. In Proceedings of the 15th International Conference on Engineering in Medicine and Biology Society. 1993, 30-31. full_text.Google Scholar
- The pre-publication history for this paper can be accessed here:http://www.biomedcentral.com/1472-6947/10/28/prepub
Pre-publication history
Copyright
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.