中 華 大 學 碩 士 論 文
題目: 網頁心電圖資料庫處理系統的設計及其在臨床環境的 運用
The Design of a Web-Based Electrocardiogram Database Management System and Its Application in Clinical
Environment
系 所 別：資訊工程學系碩士班 學號姓名： M09102045 蔣家正 指導教授：曾文慶 博士
中華民國 九十四 年 六 月
June 2005
ABSTRACT
12-lead Electrocardiogram (ECG) is one of the most important non-invasive and low-cost diagnostic examinations in clinical practice. In modern hospital, it’s very important to digitalize medical data for efficient management of hospital information. Although a lot of medical instruments provide digital data, not all of them are stored in digital formats, e.g. ECG data. Most hospitals still use plain paper for ECG recording and storage. Many commercial ECG machines produce digital data. However, most of them use proprietary formats. These different manufacturer proprietary forms obstacle ECG data exchange. The primary objective of this study was to develop an inter-hospital web-based 12-lead ECG database management system for ECG record exchange and analysis in the local area of Miao-Li County in Taiwan. The database system was developed using PHP, MySQL, and Matlab for file transmission, format conversion, record storage, and signal analysis of SCP compatible format ECG records.
In the past two years, our efforts have resulted in the collection of more than ten thousands complete 12-lead SCP-ECG files. The results indicate that (1) SCP compatible ECG files can be exchanged in ASCII, XML, SVG, PNG and DICOM formats through the established server; (2) disease-specific database can be established from our ECG database for further medical research work; (3) clinical physicians can review ECG and write report via this database system; (4) authorized end users can browse the database and analyze ECG signals using provided signal processing tools. In conclusion, the established ECG database server can provide effective ECG informatics services such as online ECG pattern recognition to aid diagnosis for clinical physicians and ECG signal processing for researchers. In the future, our work may include other medical signals such as holter ECG, exercise ECG, patient monitor, and phenocardiogram. More efforts will also be extended to establish a country-wide inter-hospital medical signal database.
中文摘要
12 導程心電圖是臨床診療過程中最為重要的低成本及非侵入性檢查之一，
在現代化的醫療體系，醫療數據的數位化對於醫院資訊的有效率管理非常重要。
雖然許多醫療儀器提供數位化資料，但並不是所有的資料都能以數位化的格式來 儲存，例如心電圖資料。大多數醫院仍然使用原始的紙本做為心電圖記錄和貯存 的格式。許多商用的心電圖機器能產生數位化數據，然而，其中大多數使用專屬 的格式。這些不同製造廠商的專屬格式阻礙了心電圖的資料交換與分析。這項研 究的主要目標即是在台灣的苗栗地區，發展一個以網頁為基礎的跨院際心電圖資 料庫管理系統，來提供心電圖資料交換與分析的平台。本資料庫系統建構採用 PHP、MySQL 和 Matlab 來發展 SCP 相容格式心電圖記錄的檔案傳輸、格式轉換、
資料貯存以及信號分析之用途。
在過去的二年間，我們的努力已經產生超過一萬筆以上完整 12 導程 SCP-ECG 記錄的蒐集。結果表示：(1)SCP 格式相容的心電圖資料可以透過所建 立的伺服器轉換成 ASCII、XML、SVG、PNG 和 DICOM 等格式；(2)特殊疾病 的資料庫可以從此心電圖資料庫來建立，提供進一步的醫學與研究工作的題材；
(3)臨床醫生能檢閱心電圖並且透過這個資料庫系統進行報告書寫；(4)經授權的 終端用戶能瀏覽資料庫並且使用所提供的訊號處理工具分析心電圖訊號。總而言 之，所建立的心電圖資料庫伺服器能提供有效的心電圖訊息服務，比如線上的心 電圖圖樣識別，來幫助臨床醫生的診斷以及協助研究人員的心電圖訊號處理。將 來，我們的工作可以包括其他醫學訊號，比如 24 小時心電圖(holter ECG)、運動 心電圖，病患監視器和心音圖等。更多的努力也將進一步延伸到建立整個國家範 疇的跨院際醫學訊號資料庫。
ACKNOWLEDGEMENTS
First and foremost, I would like to take this opportunity to say thanks to my advisor, Professor Wen-Ching Tzeng. His constructive comments and criticisms have always inspired me to think more carefully and write more appropriately. He also opened the door of Bio-Informatics to me, which has always been my dreamland. He has not only encouraged me through the research, but also shown his generosity, integrity, kindness, and scientific research approach to me. Without all his help, I could not have accomplished what I have now.
I would like to thank my co-advisor, Professor Jui-Chien Hsieh, for providing helpful ideas and suggestions in shaping my thesis. He also introduced me to the wonders of biomedical engineering during the past two years. Without his help, I could not finish my thesis.
I would like to show my appreciation to Dr. Shih-Ming Shieh, the director of Wei-Gong Memorial Hospital and Dr. Shun-Mu Lin, the chief of the emergency department, who have given me encouragement and full support. Without their help, I could not have gone through the project within the expected time.
I would like to thank all colleagues and staff in the emergency department. They create such a wonderful atmosphere that I enjoy every day of studying and working in the hospital.
I would like to thank my lab colleagues Ming-Fang Wu, Ya-Chu Yang, Chao-Cing Chen, Yu-Jen Chan, Shun-Kuo Lin and I-Hsuan Chao for their help and cooperation in this project.
Last but not least, I would like to thank my family, my mother and my wife, for their encouragement, sacrifice, and support during my work on this thesis and my graduate education in general.
TABLE OF CONTENTS
Page
ABSTRACT... ii
中文摘要... iii
ACKNOWLEDGEMENTS... iv
TABLE OF CONTENTS ...v
ABBREVIATIONS ... viii
LIST OF TABLES...x
LIST OF FIGURES ... xi
1 INTRODUCTION ...1
1.1 Background ...1
1.2 Project Description...2
2 REVIEW ...5
2.1 12-lead ECG and Application of ECG in Hospital ...5
2.1.1 Biomedical Signal...5
2.1.2 A Brief History of ECG ...6
2.1.3 Anatomy and Electrophysiology of the Human Heart...8
2.1.4 Applications of ECG...9
2.2 ECG Management System (EMS) ...11
2.2.1 Computerized ECG...11
2.2.2 System Architecture ...12
2.2.3 ECG Management System (EMS) ...14
2.3 Useful Resources on Internet ...16
2.3.1 Open ECG Project...16
2.3.2 The BIOSIG Project...16
2.3.3 HL7 - Health Level Seven ...16
2.3.4 Medical Connections ...18
2.3.5 The Concept of UID...18
2.4 ECG Format ...20
2.4.1 SCP ECG...20
2.4.2 XML...36
2.4.3 FDA_XML...36
2.4.4 ecgML ...40
2.4.5 DICOM ...42
2.5 Graphics on the Web ...44
2.5.1 SVG...45
2.5.2 PNG...46
3 MATERIALS AND METHODS ...47
3.1 SCP Format Analysis ...47
3.1.1 Header Information...48
3.1.2 ECG Waveform...52
3.2 ECG Management System (EMS) Implementation...55
3.2.1 Three-Tier Architecture...55
3.2.2 Database Schema Design...56
3.2.3 UID Design ...57
3.2.4 ECG Uploading and Archiving...57
3.2.5 File-Directory System Design...58
3.2.6 Web Server Implementation...59
3.3 Data Format Exchange...60
3.3.1 ASCII ...60
3.3.2 XML...60
3.3.3 SVG...61
3.3.4 Clinical-like Graphic Representation of ECG (PNG)...63
3.3.5 DICOM ...65
3.4 Clinical Application ...66
3.4.1 Specific Disease Database ...66
3.4.2 ECG Signals Analysis ...67
4 RESULTS...69
4.1 SCP Format Analysis ...69
4.1.1 Decoding Program for SCP-compatible File ...69
4.1.2 Header Information...69
4.1.3 Decoding SCP to the Database and the ASCII Files...71
4.2 ECG Management System (EMS) ...74
4.2.1 Three-Tier Architecture Implementation ...74
4.2.2 Database Schema ...75
4.2.3 UID Generation...75
4.2.4 ECG Uploading and Archiving...77
4.2.5 File-Directory System...78
4.2.6 Web Server Interface...78
4.3 Data Format Exchange...81
4.3.1 Rendering ECG with FDA_XML...81
4.3.2 Rendering ECG with ecgML ...82
4.3.3 Rendering ECG with SVG...84
4.3.4 Rendering ECG with PNG...84
4.3.5 Rendering ECG with DICOM ...85
4.4 Clinical Application ...87
4.4.1 ECG Signals Analysis ...87
4.4.2 Specific Disease Database ...88
5 DISCUSSION ...89
5.1 SCP Format Analysis ...90
5.2 ECG Management System (EMS) ...91
5.3 Data Format Exchange...92
5.4 Clinical Application ...96
6 CONCLUSION AND FUTURE WORK...97
7 REFERENCES ...98
ABBREVIATIONS
ANSI: American National Standards Institute API: Application Programming Interface
ASCII: American Standard Code for Information Interchange
CCITT: Comite' Consultatif International Telegraphique et Telephonique CEN/TC251: Comité Européen de Normalisation Technical Committee 251 CPU: Central Processing Unit
CRC: Cyclic Redundancy Check CSV: Comma Separated Values CV: Cardiovascular
DBMS: Database Management System DCE: Distributed Computing Environment
DICOM: Digital Imaging and Communications in Medicine D-MIM: Domain Message Information Model
DOM: Document Object Model DTD: Document Type Definition ECG: Electrocardiogram
EMS: ECG Management System ER: Emergency Department
FDA: Food and Drug Administration EPR: Electronic Patient Record HIS: Hospital Information System HL7: Health Level Seven
HMD: Hierarchical Message Descriptions HTTP: Hypertext Transfer Protocol
ICD-9: International Classification of Diseases, Ninth Revision ICU: Intensive Care Unit
IE6.0: Internet Explore 6.0
IEEE: Institute of Electrical and Electronics Engineers II: Instance Identifier
ISO: International Standards Organization ITU: International Telecommunication Union
ITU-T: ITU Telecommunication Standardization Sector LSB: Least Significant Bit
MSB: Most Significant Bit NDA: New Drug Application
ODBC: Open Database Connectivity OID: Object Identifier
OSI: Open Systems Interconnection PHP: PHP: Hypertext Preprocessor PNG: Portable Network Graphics RIM: Reference Information Model
R-MIM: Refined Message Information Model SCP: Standard Communications Protocol
SCP-ECG: Standard Communication Protocol for Computerized Electrocardiography SDO: Standard Development Organization
SGML: Standard Generalized Markup Language SQL: Structured Query Language
SVG: Scalable Vector Graphics UID: Unique Identifier
UUID: Universally Unique Identifiers VIN: Vehicle Identification Number W3C: World Wide Web Consortium XLink: XML Linking Language XML: eXtensible Markup Language XPath: XML Path Language
XSL: Extensible Stylesheet Language
XSLT: Extensible Stylesheet Language Transformations
LIST OF TABLES
Page
Table 2.1: Global overview of the SCP-ECG data structure ...24
Table 2.2: Bytes definition of Section ID Header...25
Table 2.3: Maximum and reasonable length of free text fields...28
Table 2.4: Default Huffman table ...31
Table 2.5: Contents of data header...32
Table 2.6: Contents of statement data ...32
Table 2.7: ASCII table...34
Table 2.8: Formatting effectors ...34
Table 2.9: Summary of major differences between FDA_XML and ecgML...40
Table 3.1: The bit length of binary numbers and the corresponding values of ECG amplitude are represented in the modified Huffman Encoding ...54
Table 3.2: A subset of SVG elements is used for SVG generation. ...63
LIST OF FIGURES
Page
Figure 2.1: Types of medical data...5
Figure 2.2: The capillary electrometer developed by Waller ...6
Figure 2.3: Electrocardiographic notation suggested by Einthoven ...7
Figure 2.4: ECG waveform and nomenclatures...7
Figure 2.5: The relationship of ECG and heart anatomy ...9
Figure 2.6: Computerized electrocardiograph with PC ...11
Figure 2.7: Schematic presentation of two-tier and three-tier architecture ...12
Figure 2.8: Interactions between components of a three-tier architecture...13
Figure 2.9: N-tier architecture...13
Figure 2.10: The configuration of a five-module design of an EMS system...14
Figure 2.11: Methods of UIDs extended from OID or UUID ...19
Figure 2.12: Example for the tree structure of ISO OIDs...19
Figure 2.13: Overview of the SCP-ECG Record ...24
Figure 2.14: Section lay-out overview...25
Figure 2.15: Pointer section data part overview ...27
Figure 2.16: Overview of the Header section data part ...27
Figure 2.17: Ranges of the byte encoding space...33
Figure 2.18: The default character set for SCP-ECG ...35
Figure 2.19: Overview of the data part of the section 8...35
Figure 2.20: A graphic representation of an R-MIM model. ...37
Figure 2.21: HMD structure...38
Figure 2.22: Related real-time, recording section and dataset in a common x-axis (time-axis) domain ...39
Figure 2.23: PlotGroup Example of ECG Rhythm Data ...39
Figure 2.24: The hierarchical structure of ecgML model ...41
Figure 3.1: Flowchart of the universal SCP converter...48
Figure 3.2: Flowchart of the manufacture-specific SCP decoding algorithm...49
Figure 3.3: The eight blocks of data in a paper ECG...50
Figure 3.4: Free-text information in the section 8 of the SCP file...52
Figure 3.5: Extracted 37 sections from the waveform data ...53
Figure 3.6: The three-tier architecture model of the web-based ECG database. ...56
Figure 3.7: Method of UID generation. ...57
Figure 3.8: Flowchart of ECG uploading and archiving...58
Figure 3.9: Flowchart of generating XML (FDA_XML or ecgML) document by transforming engine ...61 Figure 3.10: The source codes of an example SVG demo file and its corresponding
graphic...62
Figure 3.11: Flowchart of generating PNG file from SVG document by PHP engine and svgtoolkits under the JAVA SDK ...64
Figure 3.12: Flowchart of generating DICOM file from PNG using Matlab DICOM-PNG generator...65
Figure 3.13 Flowchart of collecting specific disease database ...67
Figure 4.1: Header information decoded from section 0 and section 1 of an SCP file70 Figure 4.2: Header information and pointer information display on the web ...70
Figure 4.3: The free-text data stored in filename.tx0...72
Figure 4.4: The first 33 lines of values of the 2.544 sec 12-lead waveform (left) and 10 sec 3-lead rhythm data (right) from filename.tx1 and filename.tx2, respectively ...73
Figure 4.5: The web-based three-tier EMS system...74
Figure 4.6: The Schema of the ECG database system ...75
Figure 4.7: The ‘uid_lookup’ table. At the present, only uid_suffix of FDA_XML and ecgML is generated by the system ...76
Figure 4.8: The UID generated from the prefix and suffix. ...76
Figure 4.9: UID used as ‘id root’ in the FDA_XML document...77
Figure 4.10: UID used as ‘StudyId’ in the ecgML document ...77
Figure 4.11: Information decoded form SCP file display on the phpMyadmin...77
Figure 4.12: The tree structure of the file-directory system of the EMS. ...78
Figure 4.13: Login function of the EMS system ...79
Figure 4.14: Upload function of the EMS system ...79
Figure 4.15: Query function of the EMS system ...79
Figure 4.16: Results of query by patient id (pid) ...80
Figure 4.17: Results of query by date ...80
Figure 4.18: An FDA_XML document of ECG generated by the EMS system...81
Figure 4.19: FDA_XML document of ECG represented by the FDA_XML viewer. .82 Figure 4.20: Source codes of ecgML document generated by the EMS system ...83
Figure 4.21: ecgML document represented by the ecgML browser ...83
Figure 4.22: SVG document of ECG represented by the Adobe SVG viewer using IE6.0 with Adobe SVG viewer 3.0 plug-in...84
Figure 4.23: PNG file representation of ECG using IE6.0 ...85
Figure 4.24: DICOM representation of ECG from PNG file...86
Figure 4.25: Using wavelet transforms to identify the characteristic points of ECG. .87 Figure 4.26: The ECGDAS Home Page. ...88
Figure 5.1: Implementation of the Web-based EMS System...89
Figure 5.2: Differences between SVG and PNG during scaling ...94
1 INTRODUCTION
1.1 Background
ECG is one of the most important non-invasive diagnostic examinations, which can be performed at low cost and allows the early recognition of heart-related diseases. It’s the most common cardiology and emergency examination used in healthcare system. In 1993, it was estimated that more than 100 million standard ECGs were recorded yearly in the European Community [1], or 0.3 ECG/capita/year in Europe alone [2]. ECG devices are routinely used in many settings, including emergency rooms, ambulance, cardiovascular department, intensive care units, and general practice offices. Some ECG manufactures provide Application Programming Interface (API) for communication between ECG cart and host computer for data transfer and data storage. However, most commercial electrocardiographs use proprietary protocols and file formats that hinder interoperability of ECGs. These collected data are useful for both clinical physicians and medical researchers if we can decode these proprietary formats and transform them into readable formats.
These proprietary protocols not only make the exchange of patient’s ECG records difficult and inefficient, but obstruct the research work in the analysis of ECG data and related heart diseases. To facilitate the compatibility of ECG data among electrocardiographs from different manufactures, OpenECG project has been promoting SCP-ECG (Standard Communications Protocol for Computer-Assisted Electrocardiography) standard format for over decades [3].
Currently, although most of electrocardiograph manufactures claim that they have been supporting SCP-ECG format, the ECG files obtained from commercial electrocardiographs still can only be interpreted by their proprietary viewers.
as patient’s records, but also as raw data for researchers. Hence, in this study, we try to develop a program to decode the SCP-ECG files generated by the commercial electrocardiographs, and store the results in the database.
Different governmental, academic and private organizations have developed some standards for ECG format, and each format has its advantages. In order to facilitate the interoperability among these different standards, applications for format exchange should be developed. In addition, digital ECG is composed of binary or text data, which is not good for human viewing and interpretation.
Representation of ECG by graphic format is critical for practical applications.
This study develops utilities to transform the ECG data into standard formats such as XML, ecgML, DICOM, SVG, and PNG, which can facilitate the exchange and interoperability of ECG data.
1.2 Project Description
This study mainly consists of four parts: In the first part, the European Standards Committee SCP-ECG protocol (CEN/TC 251, prEN 1064) [1] was reviewed and applied to retrieve the SCP-compatible ECG format files (proprietary format) from a specific manufacturer's electrocardiograph in clinic environment. A binary editor was developed for this purpose. Specifications about standard SCP format and specific SCP-compatible format were studied and the results indicated that there were differences between (1) waveform data coding methods and (2) data compression methods. Header information and waveform data can be generated from the SCP-compatible file by the decoding algorithm. A standalone decoding program compiled by C++ language was used for this purpose.
The second part focused on the implementation of ECG management
system (EMS). To facilitate efficient and convenient utilization of ECG data, a relational database system was developed in this study. During the past two years, our efforts have resulted in the establishment of a web-based three-tier EMS system. The three-tier architecture has been widely used by academic institute and industrial field, which includes (1) a relational database as the base, (2) a web-based interface for system administration, ECG data management, and ECG data exchange and analysis, and (3) a web browser for clients. Open source freewares such as Apache, PHP, MySQL were used to establish the EMS system.
Decoding algorithm developed in the first part was embedded in PHP scripts, and then the decoded SCP files can be uploaded and passed to EMS via the internet.
The third part focused on representation of ECG data, conversion of various ECG formats, and application of the developed system on the clinic environment. At present, there is no unified ECG format available. This project studied and analyzed several popular formats related to ECG, including SCP, XML, SVG, PNG, DICOM, etc. The information stored in an ECG file is mainly the waveform data. Considering portability of ECG records, XML was chosen as the output format, due to its text-based yet well-formed structure. DICOM has been industry standard for many years (mainly used in radiological storage and transmission of image, but there has been no clear definition about waveform data until 2000). In addition, since general DICOM viewers do not support the interpretation of waveform data, DICOM isn’t an appropriate format for ECG waveform representation at present. SVG format can represent the waveform data graphically, which then can be conveniently investigated by the end users. An alternative way to represent ECG data on the web is using PNG format. SVG format was converted into PNG graphic on server side and then transmitted to the
disadvantage of PNG is that it is a raster image, and all information in the original ECG data are lost after the transformation.
The fourth part was application of the developed system in clinic environment and developed utilities for ECG signal analysis. Clinical ECG records were transmitted to web server via the internet. These ECG records then were decoded (the first part) and are passed to the database (the second part).
These decoded data can be converted to different formats (SCP Å Æ ASCII, XML, SVG, PNG, DICOM, the third part). Authorized clinicians and researchers can log into the EMS and perform query, downloading, analysis and other applications via the internet. Some ECG analyzing applications have been developed for research purpose. Until now, the database established by this study has already contained more than 10,000 electrocardiograms. ECG records for specific heart diseases have been collected using the system. There are four specific disease databases established during the past two years, including hyperkalemia, hypokalemia, acute myocardial infarction, and normal subjects.
Nowadays, this study is keeping on collecting specific ECG data from the clinical environment.
2 REVIEW
2.1 12-lead ECG and Application of ECG in Hospital 2.1.1 Biomedical Signal
There are three types of medical data: alphanumeric (e.g. text or lab data), 2-D or 3-D biomedical signals (e.g. images) and 1-D biomedical signals (e.g. ECG) [4], which are shown in Figure 2.1. This study focuses on the third type of data: 1-D biomedical signals, especially the electrocardiogram (ECG), which is one of the important and most monitored signals. Biomedical signal databases are important in research, engineering and new drug development.
Clinical diagnosis and academic researches are critically dependent on the biomedical signal recording and analyzing. Clinicians and researchers need high-quality, well-validated and standardized databases of biomedical signals.
However, this requirement can not be easily achieved in reality [5].
Figure 2.1: Types of medical data (modified from [4])
Presently, due to the digitization of hospital information, biomedical
facilitate the data transmission and exchange. Some standard formats for medical data have been developed, such as DICOM and HL7. DICOM has been widely used in medical images, particularly in radiology. Nevertheless, there still lake a unified standard format for some biomedical signals such as ECG.
2.1.2 A Brief History of ECG [6, 7]
Animal electricity was first introduced by Galvani in 1787 when he observed contraction of frog muscle exposed to an electrical process. In 1842, Matteucci demonstrated that electrical current of the resting heart muscle could be measured [6]. More and more studies about bioelectricity have been conducted since then. Electric potentials from a beating heart were first recorded from body surface in 1887 by Waller. Figure 2.2 shows the capillary electrometer developed by Waller for recording electricity of the human heart.
The method of calibrating and correcting electrocardiogram was modified by Einthoven between 1893 and 1895 [7].
Figure 2.2: The capillary electrometer developed by Waller (figure from [6])
Figure 2.3 shows the electrocardiographic notation suggested by Einthoven. Signal contour predicted by Einthoven from his experimental recording was very close to the ‘true’ ECG obtained by modern electrocardiographs. The nomenclatures of electrocardiogram defined by Einthoven have been followed by researchers and clinicians since then. Figure 2.4 shows the ECG waveform and nomenclatures.
Figure 2.3: Electrocardiographic notation suggested by Einthoven (figure from [6])
Figure 2.4: ECG waveform and nomenclatures
2.1.3 Anatomy and Electrophysiology of the Human Heart [8, 9]
The heart has four chambers: right atrium, left atrium, right ventricle and left ventricle. The atria consist of low-pressured thin-walled structure that receives blood from the venous system. The sinoatrial (SA) node is a group of cells in the right atrium that act as the pacemaker of the heart. An action potential can be generated from a complex change of sodium-potassium ionic pump from the SA node. The action potential then excites the neighboring cells and propagates to the atria and ventricles. This electrical current can be detected on the body surface. The characteristics of the electricity detected on the body surface depend on the amount of heart cells activated at one time and the relative speed and direction of the electric current. The action potentials generated from SA node are too small to be detected. As the activation potentials flow through the mass of atrial muscles, the electrical activity can be observed on the body surface, and forms the first ECG wave. This is the P wave, and it represents activation of the atria. Following the P wave, a short isoelectric segment PR interval can be observed, which represents the action potentials proceeds from the atria to the atrioventricular (AV) node, where the conduction delay occurs. Then the action potentials propagate to the ventricles.
Once the large mass of the ventricular muscle is excited, a rapid and large deflected wave can be observed on the body surface. It’s the QRS complex.
Following the QRS complex is another relatively short isoelectric segment.
After this short segment, the ventricles return to their electrical resting state, and a wave of repolarization is seen as a low-frequency signal known as the T wave. In some cases, a small peak U wave may occur at the end or after the T wave. Its origin has not been well known, probably related to repolarization process. The relationship of ECG waves to the heart anatomy is represented in
Figure 2.5.
Figure 2.5: The relationship of ECG and heart anatomy (modified from [9])
2.1.4 Applications of ECG
The applications of the ECG are mainly on the cardiology [10], including the followings:
9 The electric axis of the heart 9 Heart rate evaluation
9 Arrhythmias
Supraventricular arrhythmias
Ventricular arrhythmias
Other tachycardia
Bradycardia 9 Pacemaker defect
9 Conduction disturbance
Bundle-branch block
AV conduction defects
WPW syndrome
9 Hypertrophy of the heart
Atrial hypertrophy
Ventricular hypertrophy 9 QTc prolong
9 Ischemia heart disease
Ischemia
Injury
Infarction 9 Drug effect
Digitalis
Quinidine
Anti-arrhythmic agents
9 Electrolyte imbalance
Potassium
Calcium
Magnesium
9 Carditis
Pericarditis
Myocarditis
Endocarditis
Current application of ECG in hospital is mainly based on paper ECG. It means that the ECG generated from the cardiograph is recorded and stored on the plain paper. The paper ECG may travel to many departments:
including laboratory, examination room, emergency room, ward, and cardiovascular department, etc. Then the paper ECG is sent to the cardiologist for reporting or consultation. Finally the paper ECG is bound with the medical chart and filed to medical record department. Anyone wants to review the ECG must refer to the medical chart. The paper ECG has many disadvantages:
z High cost
z Poor maintenance: labor intensive
z Low availability: bound with medical chart, time consuming z Easily contaminated and destroyed: the paper is heat-sensitive z Poor resolution
z Poor quality: information may disappear after a long time z Easy to get lost: just one or two copies
z Difficult to reproduce
z Difficult to perform remote consultation
To overcome the drawbacks of the paper ECG and enhance efficiency, availability and interoperability, digitization of ECG is necessary for modern hospitals and healthcare systems.
2.2 ECG Management System (EMS) 2.2.1 Computerized ECG
Computerized ECG has been developed for decades. However, efforts on ECG devices have been focused on improving their functionality [11].
Most ECG devices manufactures utilize proprietary protocols for communication between cardiograph and host computer. Interoperability rarely has been the major concern when designing an ECG machine. The computerized electrocardiograph with PC is shown in Figure 2.6. The simplest computerized ECG management system (EMS) is an ECG equipment plus a personal computer with or without a database, which can only provide file storage and ECG reprint for machines of the same type. The system can be seen as a simple two-tier architecture (client/server system). Communication and integration among different protocols are difficult to achieve by such implementation. Multi-user access is impossible via such ECG management system. Nowadays ECG data reutilization and interoperability is more important. For efficient utilization of ECG for both clinical physicians and biomedical researchers, it’s urgent to develop a cross-platform, open source standard for ECG management system.
Figure 2.6: Computerized electrocardiograph with PC
2.2.2 System Architecture
A two-tier architecture is simply a client-server architecture, which includes two components: A user component and a server component. Most of the application runs on a single machine. The major functions of the server are to manage the database and respond to the client’s queries. Two-tier systems usually have limited scalability - few applications can support more than 100 users simultaneously [12]. Figure 2.7 shows the two-tier and three-tier architecture.
Figure 2.7: Schematic presentation of two-tier and three-tier architecture
A three-tier architecture is partitioned into three different processes:
the user interface, application processing and database management. The major difference between a two-tier and a three-tier system is that the application processing is independent of the client side and is placed in a separate application server. Each tier may have its own architecture. Figure 2.8 shows the interactions between components of a three-tier architecture [13].
Figure 2.8: Interactions between components of a three-tier architecture (figure from [13])
A N-tier (or multi-tier) system is basically a three-tier model with additional modules, such as a firewall, routers or file servers, which provide better safety, security, flexibility and stability of the system. N-tier databases are most commonly implemented as a three-tier model. For better safety and security consideration, N-tier architecture was proposed [14, 15]. Its design is more complex and takes more cost when being implemented. N-tier architecture is shown in Figure 2.9.
Figure 2.9: N-tier architecture (modified from [12])
2.2.3 ECG Management System (EMS)
Many ECG management systems have been developed for ECG communication and interoperability purpose. An EMS developed by Cho et al.
was an integrated system composed of five distinct modules: ECG equipment, acquisition server, archiving server, EMS database and EMS viewer [15]
(Figure 2.10). In practice, these modules can be organized as a two-tier, three-tier or N-tier architecture during the system implementation.
Figure 2.10: The configuration of a five-module design of an EMS system (modified from [15])
The two-tier architecture is the simplest and primitive design of an ECG management system. However, there are many disadvantages for a two-tier system. In the two-tier architecture, a fat client rather than a thin client is implemented, i.e., most of tasks are processed on the client side [14].
The only thing the server does is managing the client’s queries. When the heavy processing work can be moved to a powerful machine, like a server, the system can perform more efficiently and powerfully; and this can’t be achieved by a two-tier architecture design. Security is another important issue.
It puts the database at great risks if every client can access the database directly. It’s dangerous for database management. From the maintenance point
of view, in a two-tier system, all clients need to be updated if any change has been made for the system. Other considerations such as connection capacity, flexibility, and accessibility are all limited for the two-tier implementation.
To overcome the drawbacks of a two-tier system, three-tier architecture models have been widely adopted in many studies for web database implementation [13-18]. In 2003, Paracha developed a web database to facilitate the collection of valuable, decade-long data, which was built around a three-tier architecture model using open source softwares. Apache, PHP, and MySQL were used for this purpose [16]. In 2003, a three-tier EMS based on a relational database was proposed by Zhou et al [17]. The goals of the proposed EMS were to store and manage ECG data, to communicate with HIS, to automate the workflow of ECG, to facilitate ECG reporting and conformation, and to compare serial ECG [18]. In 2004, Hedberg developed a three-tier distributed system for biomedical signal data storage [14]. He successfully converted a two-tier client-database system to a three-tier client-server-database system, which could satisfy the requirements of security, flexibility and performance.
2.3 Useful Resources on Internet 2.3.1 Open ECG Project
OpenECG was a European project developed for integration and interchange of electrocardiography [3]. The goals of the OpenECG are to foster the consistency and interoperability of standards in implementation of computerized electrocardiography and to develop conformable standards for ECG-related biomedical signals, such as complete ECG, stress ECG, Holter ECG, and real-time ECG monitoring. The OpenECG is coordinated by a multidisciplinary, highly motivated consortium, which accepts membership from many fields, including healthcare providers, cardiologists, bioinformatics researchers, integrators, bio-medical engineers, standardization organization, manufacturers, academic institutes and the public.
2.3.2 The BIOSIG Project
The goal of the BIOSIG Project is to foster the researches in biomedical signals. Many different topics were mentioned, such as data acquisition, signal processing, quality control, feature extraction, classification, modelling, and signal representation. There are many useful sharewares and utilities available on the BIOSIG website. These open source softwares can be utilized to improve the performance and efficiency and reduce the developing time and cost in the field of biomedical signal processing [19].
2.3.3 HL7 - Health Level Seven
HL7 is a Standards Developing Organization (SDO) approved by American National Standards Institute (ANSI). HL7 refers to the highest level of Open Systems Interconnection (OSI), which is level seven, the application
level. OSI is the communication model defined by International Standards Organization (ISO). HL7’s domain is focused on clinical and administrative data. The aims of HL7 are: (1) to provide standards for data exchange, management and integration, (2) to support patient care, data delivery and evaluation of healthcare services, (3) to create flexible, cost effective approaches of standards, (4) to provide principles, guidelines, methodologies, and related informatics services for interoperability between healthcare information systems [20]. The newest version of HL7 is version 3, whose goals are to offer a definite and testable standard for healthcare system, and provide the methods to certify vendors' conformance. Version 3 adopts an object-oriented methodology and uses a Reference Information Model (RIM) to create messages. The RIM is the cornerstone of the HL7 Version 3 standard.
The RIM is a shared model between all the domains and all domains create their messages from the RIM. The RIM uses an abstract model, which is composed of six “back-bone” classes [20]:
• Act: represents the actions
• Participation: expresses the context for an act(who, for whom, where, etc)
• Entity: represents the physical things and beings that are of interest
• Role: establishes the roles that entities play
• ActRelationship: represents the binding of one act to another
• RoleLink: represents relationships between individual roles
2.3.4 Medical Connections
Medical Connections is an advanced software website. The aim of Medical Connections is to give a simple and effective way to develop medical related software. Medical Connections is owned and maintained by a radiologist, Dr David Harvey [21]. Harvey is kind to offer a fully valid and official UID prefix to public researchers who need a UID for constructing databases related to biomedical signals. The prefix will be within the Medical Connections’ numbering space. Applicants are granted full permission to use this UID prefix as their own subject without any restriction. The UID prefix 1.2.826.0.1.3680043.2.1071 used in this study (‘uid’ in DICOM or ‘id root’ in XML) was obtained from the Medical Connections.
2.3.5 The Concept of UID
Instance identifier (II) is an identifier that uniquely identifies a thing or an object. Examples of II are object identifiers for HL7 RIM objects, medical record numbers, order sequence numbers, Vehicle Identification Numbers (VINs), etc. Instance identifiers are defined based on ISO object identifiers (OIDs) [22].
An ISO Object Identifier (OID) is a globally unique string representing an ISO Object Identifier in a form consisting of sequential numbers separated by dots. According to ISO standard, OIDs are paths of a tree structure, with the left-side number representing a root and the right-side number representing a leaf. Each vertex corresponds to an assigning authority.
Unique Identifier (UID) is a character string which identifies an object in a globally unique and timeless identifier. At present, UIDs could only be extended from ISO Object Identifiers (OIDs) and DCE Universally Unique
Identifiers (UUIDs). Figure 2.11 shows the methods of UIDs extend from OID or UUID. The UIDs are also a tree structure. A UID contains two parts: a UID prefix and a UID suffix. The left-side numbers represent the prefix and the right-side numbers represent the suffix. The prefix (or root) should be certified by international organization (such as ISO or HL7) to assure the uniqueness.
An example for the tree structure of ISO OIDs is shown in Figure 2.12.
Figure 2.11: Methods of UIDs extended from OID or UUID (figure from [22])
2.4 ECG Format
Nowadays, an all-purpose, efficient, user-friendly, and unified format for ECG data is not available. The choice of a format depends on the domain of researchers’ application [23]. No any standard has all advantages over the others.
Interoperability of ECG information among different application categories is not possible with just one standard [16]. Therefore, there are many ECG-related formats developed by different organizations and institutes. Some standards are more popular and are more widely accepted by specific communities, such as SCP, FDA_XML, ecgML, and DICOM. In addition, SVG and PNG are recommended by W3C for visual representation on the web. In this section we will review these standards.
2.4.1 SCP ECG
Almost all ECG manufacturers can provide digital recording, storage and communication. However, different manufacturers use different proprietary formats. To facilitate the exchange of information between various systems, one standard has been established as CEN/TC 251, prEN 1064 (European prestandard CEN ENV 1064), and it is widely used for ECG recording. This standard is also known as the SCP-ECG (Standard Communications Protocol for Computer-Assisted Electrocardiography). The primary aim of this standard is to specify a data format to ensure compatibility of ECG reports and data between two ECG systems from different venders.
The same standard should also allow standardized transmission of digitized ECG data and results between various computer systems [2]. To facilitate the compatibility of ECG data among electrocardiographs from different manufactures, OpenECG project has been promoting SCP-ECG standard
format for over a decade [3]. Currently, although most of electrocardiograph manufactures claim that they have been supporting SCP-ECG format, the files output from commercial electrocardiographs still can only be interpreted by their proprietary viewers. Since there is a vast amount of these so called SCP-ECG data, they are valuable not only as patient’s records, but also as raw data for researchers. Hence, in this study, we try to develop programs to decode the SCP-ECG files generated by the commercial electrocardiographs, transform them into standard formats and store the results in the designed database.
SCP-ECG can manage textual annotations and binary signals in several defined sections obtained from short-term ECG recordings. In addition, it also uses some compressing algorithm to reduce the size of stored raw data. Some signal characteristics specified in the SCP-ECG format such as filter specifications, sampling rates, and annotation are limited to 12-lead ECG recording and the format cannot be used for other types of electrocardiac recording, such as Holter ECG. However, SCP-ECG is supported by most major manufacturers of ECG equipments. Therefore, it is one of the recommended file formats for ECG databases [4]. An SCP-ECG (CEN/TC251/N02-015, prEN 1064:2002) document can be divided into eight chapters:
z Chapter 1: Scope: The category of this protocol.
z Chapter 2: Normative References: This protocol incorporates many references, which were listed in this chapter.
z Chapter 3: Terms and Definitions.
z Chapter 4: Abbreviations.
z Chapter 5: Definition of the data contents and format. It’s the core
component of this protocol, which can be divided into different sections. Sections related to this study will be described in the following paragraphs in detail.
z Chapter 6: Minimum requirements for encoding and compression of the ECG signal data.
z Chapter 7: Definition of a minimum set of control and query messages for the interchange of ECG data.
z Chapter 8: Standard low-level ECG-Cart to host protocol.
2.4.1.1 SCP Chapter 1: Scope
This standard contains the two-way remote transmission protocol between digital electrocardiographs (ECG carts) and various kinds of computer hosts. Common conventions for ECG information interchange of cart-to-cart or cart-to-host are described in here. All ECG data to be transmitted, such as ECG signal data, specific patient data (administrative, demographic, recording etc.), measurement, annotation and interpretation results are defined in this protocol. This standard specified the content and structure of the ECG information to be interchanged. A logical link for ECG communication between two systems can be established under this protocol.
2.4.1.2 SCP Chapter 5: Definition of the data contents and formats
¾ 5.1 General considerations
The data record is divided into different sections. The contents and formats of these sections are defined in the protocol (standard communication protocol, SCP). Sections are numbered from 0 (the Pointer Section) to 32767.
All indexes or pointers (except section 0, Pointer Section) to a field are
defined in bytes and are ones-based (start at 1). Consecutive bytes are numbered from left to right (starting with 1). Bits of a byte are read from right to left (0 = LSB, 7 = MSB).
¾ 5.2 Specifications for the data structure
All sections should start on an odd index (even offset) boundary. It means that all sections should have an even number of bytes. Any section with an odd number of bytes must add one padding byte at the end with zero value (NULL). There can be odd numbers or even numbers of bytes in the data blocks of a section. Padding occurs only at the end of a section if needed. All sections are given section identification (ID) numbers. Section ID numbers 0-11 are defined in SCP-ECG protocol currently. ID numbers from 12 to 127 and above 1024 are reserved for future use. Numbers 128-1023 are provided as manufacturer specific sections. No specific rules are defined for these sections. Only the section ID header structure is required to follow the specification. There are no rules specified for the section data part. That is the major reason why a manufacturer’s SCP format is not compatible to the other’s SCP format.
All SCP-ECG files must contain section 0 and section 1, which are mandatory. Section 0 is the pointer section and pointers to the start of each following sections are recorded in this section. Section 1 contains header information, which includes data related to the patient (e.g. patient ID, name, sex, age, etc.). Sections 2-11 are optional.
A global overview of the SCP-ECG record structure is shown in Table 2.1. An ECG record starts with a 6-byte recode header, which contains a
there are section 0, section X and then final section. Overview of the SCP-ECG record is shown in Figure 2.13.
Table 2.1: Global overview of the SCP-ECG data structure IDs Status
Section
Content
- Mandatory 2 Bytes Checksum: CRC-CCITT - Mandatory 4 Bytes Size of The Entire Record 0 Mandatory Pointer to Data Areas In The Record 1 Mandatory Header Information-Patient Data /
ECG Acquisition Data
2 Optional Huffman Tables
3 Optional ECG Lead Definitions
4 Optional QRS Locations
5 Optional Encoded Reference Beat
6 Optional “Residual Signal” After Reference Beat Subtraction Or Encoded Rhythm Data
7 Optional Global Measurements
8 Optional Textual Diagnosis From The “Interpretive” Device 9 Optional Manufacturer Specific Diagnostic And Overreading
Data From The “Interpretive” Device 10 Optional Lead Measurements Results
11 Optional Universal Statement Codes Resulting From The Interpretation
12-127 Reserved Reserved for Future Use
128-1023 Optional Manufacturer Specific Sections 1024-65535 Reserved Reserved For Future Use
CRC Section 0
2 120 + var
Record Length
4
Final Section
var
... ...
Section X
var
CRC Domain
Record Length Domain
Figure 2.13: Overview of the SCP-ECG Record
The SCP files obtained from the local hospital in this study contain five sections: section 0, section 1, section 7, section 8, and manufacturer specific section 128. This study will focus mainly on these sections. The sequential order of the sections of a record is free, except section 0 which follows the record header (CRC and record length) immediately. Each section contains 2 parts:
1). A Section ID Header 2). A Section Data Part
Section ID Header is made up of 16 bytes. Bytes definition of Section ID Header is shown in the Table 2.2. The overview of the section lay-out is shown in Figure 2.14.
Table 2.2: Bytes definition of Section ID Header Bytes Contents
1-2 16 bit CRC-CCITT
3-4 Section ID number
5-8 Section length(in bytes)
9 Version Number of the Section 10 Version Number of the Protocol 11-16 Reserved(except section 0 *)
* Bytes 11-16 of the section 0 ID header shall contain "SCPECG"
Section ID Header Section Data Part
CRC Section ID
No. Length Section Ver. No.
Protocol Ver. No.
16 var = (section length) - 16
2 2 4 1 1
Reserved
6
Figure 2.14: Section lay-out overview
¾ 5.3 Pointer section - Section 0
The purpose of section 0 is to store the index and length of all sections.
This section starts with a “Section ID Header” consisting of 16 bytes, as defined above. Bytes 11-16 should contain the string: "SCPECG" (SCP file obtained in this research does not have this string).
Data part of Pointer section consists of several pointer fields for which several rules must be followed:
1). No matter whether a section is used, the pointer fields of section 0-11 must be defined.
2). Manufacturer specific section must have its corresponding pointer field in section 0.
3). The first pointer field is section 0.
Each pointer field is made up of 10 bytes, containing three parts:
Section ID, Section Length, and Section Index:
1). Section ID: 2 bytes, value: 0-32767.
2). Section Length: 4 bytes, value: unsigned 4 byte integer.
3). Section Index: 4 bytes, value: unsigned 4 byte integer, which is calculated relative to the start of the record.
Since sections 2-11 of the record are optional, if not exist, the length is set as 0 and the index is set as NULL (0). The index of section 0 is always set to 7 (following CRC: 2 bytes and Record Length: 4 bytes). The pointer fields in section 0 shall be arranged in sequential order, but the real block of each section may not need to follow this order. The overview of the pointer section data part is shown in Figure 2.15.
....
Pointer field Section 0 Mandatory
Section ID Nr.
Section Length
Index to Section 16
2 4 4
Pointer field Section 1 Mandatory
... ...
Pointer field Section 11 Mandatory
Pointer field Section 128
Optional
Figure 2.15: Pointer section data part overview
¾ 5.4 Header information - Patient data / ECG acquisition data - Section 1 Section 1 contains detailed information related to patient demographic and ECG administrative data. It also starts from a Section ID Header of 16 bytes. Following the header, there is the Section Data Part (see Figure 2.14), which contains many header fields arranged one by one, until the header terminator and padding byte (if needed). Figure 2.16 shows the overview of Header section data part.
Header Field
Field Tag
Field Length
Field Value
1 2 var
... ...
Header Field
Header Terminator
Padding byte (if needed)1
Tag 255
1
Length 0
2
Figure 2.16: Overview of the Header section data part
Header Field is made up of three parts:
1). Field Tag: 1 binary byte 2). Field Length: 2 binary bytes 3). Field Value: variable bytes
There are 255 field types can be defined in Field Tag (0-254). Tag 255 (FF in Hex) is used as terminator. Tags 200-254 are reserved for individual
Length defines the actual length of the Field Value. The tag and length bytes (first 3 bytes of field) are not included in the Field Length. Maximum length of the field is 65535 bytes (real length is indicated by a 2-byte unsigned integer). However, except for free text items, the maximum length should not exceed 64 bytes. Table 2.3 shows the maximum and reasonable length of free text fields.
Table 2.3: Maximum and reasonable length of free text fields
Section TAG CONTENTS Instanc
e > once
Reasonable Length
1 0 Last Name - 40
1 1 First Name - 40
1 2 Patient Identification Number - 40
1 3 Second Last Name - 40
1 10 Drugs yes 40 *
1 13 Diagnosis or Referral Indication yes 80 * 1 14 Acquiring Device Identification Number - 40
1 15 Analyzing Device ID Number - 40
1 16 Acquiring Institution Description - 40 1 17 Analyzing Institution Description - 40
1 18 Acquiring Department Description - 40
1 19 Analyzing Department Description - 40
1 20 Referring Physician - 60
1 21 Latest Confirming Physician - 60
1 22 Technician Description - 40
1 23 Room Description - 40
1 30 Free Text Field yes 80 *
1 31 ECG Sequence Number - 12
1 35 Free-text Medical History yes 80
* Multiple instances are allowed for these fields, each with 40 or 80 characters.
Most tags can only appear once except for the following five kinds of tags:
1). Tag 10: Drugs
2). Tag 13: Diagnosis or referral indication 3). Tag 30: Free text
4). Tag 32: History diagnostic codes 5). Tag 35: Free-text Medical History
When transmitting ECG data between ECG management systems, the uniqueness of patient and record is an important issue. In SCP protocol, some data are transmitted through section 1 of the SCP record for this purpose.
There are 35 tags defined in section 1 for patient demographic data (such as medical history, drug history and clinical data etc.) and ECG administrative data (such as ECG acquiring device, settings, recording location, and time stamping etc.). Although a lot of parameters (tags) are defined in section 1, most ECG equipments only send a subset of parameters. There is some flexibility reserved for ECG interoperability. Four parameters are mandatory in an SCP record:
1). Tag 2: Patient ID (primary key in this study) 2). Tag 14: ID of the Acquiring Device
3). Tag 25: Date of Acquisition 4). Tag 26: Time of Acquisition
Additional 6 parameters are highly recommended by SCP-ECG Working Group for strengthen the identifying uniqueness of the patient and acquiring time:
5). Tag 0: Patient Last Name
7). Tag 5: Patient Date of Birth 8). Tag 8: Patient Sex
9). Tag 15: ID of the Analyzing Device 10). Tag 34: Date Time Zone
There are 256 Tags can be used in header section data part (0-254 is general field tag, Tag255 is Terminator). Detailed rules and explanations for Tag0-35 and Tag255 are defined in SCP Protocol.
¾ 5.5 Huffman tables - Section 2
SCP protocol recommends Huffman method to encode and compress data. The coding rules and Huffman code tables are defined in section 2. The default Huffman table is shown in Table 2.4. The data part of SCP section 2 should have the content like the following [24]:
byte(s) Content Entry Comment
1-2 Number of Huffman tables 19999 Default Huffman table is used
Table 2.4: Default Huffman table number of bits
No.
entire code prefix
table mode
base value prefix code (in bits)
store binary as
1 1 1 1 0 0 0d
2 3 3 1 1 100 1d
3 3 3 1 -1 101 5d
4 4 4 1 2 1100 3d
5 4 4 1 -2 1101 11d
6 5 5 1 3 11100 7d
7 5 5 1 -3 11101 23d
8 6 6 1 4 111100 15d
9 6 6 1 -4 111101 47d
10 7 7 1 5 1111100 31d
11 7 7 1 -5 1111101 95d
12 8 8 1 6 11111100 63d
13 8 8 1 -6 11111101 191d
14 9 9 1 7 111111100 127d
15 9 9 1 -7 111111101 383d
16 10 10 1 8 1111111100 255d
17 10 10 1 -8 1111111101 767d
18 18 10 1 8 bit orig. 1111111110 511d
19 26 10 1 16 bit orig. 1111111111 1023d
¾ 5.6 ECG lead definition - Section 3
¾ 5.7 QRS locations, reference beat subtraction zones and protected areas - Section 4
¾ 5.8 Encoded type 0 reference beat data - Section 5
¾ 5.9 Rhythm data - Section 6
¾ 5.10 Global measurements - Section 7
¾ 5.11 Storage of full text interpretive statements - Section 8
This section contains free text of the diagnostic interpretation of the ECG. The section is made up of a Section ID Header and a Section Data Part.
The data portion of this section includes a data header followed by multiple statements. Table 2.5 and Table 2.6 show the contents and formats of the data header and the statement data respectively.
Table 2.5: Contents of data header Byte Contents
Binary: Confirmed/Non-confirmed report:
Value Type
0 Original report (not overread)
1 Confirmed report
1
2 Overread report, but not confirmed 2-3 Binary: Year (Full integer notation, as in 1990).
4 Binary: Month (range 01 to 12; 01 = January).
5 Binary: Day (range 01 to 31).
6 Binary: Hours (range 00 to 23).
7 Binary: Minutes (range 00 to 59).
8 Binary: Seconds (range 00 to 59).
9 Binary: Number of statements in this section.
Table 2.6: Contents of statement data Byte Contents
1 Binary: Statement sequence number, starting with 1.
2-3 Binary: Statement field length (number of bytes in the statement, starting with the first byte following, and including the NULL terminator).
4-*** Statement body: text terminated by NULL.
A character set should be defined for transmitting data between equipments and interpreted correctly by a receiver. The encoding rules of the alphanumeric ECG data are defined in SCP standard ANNEX A. The byte values are represented as two decimal numbers in the form of column/row as defined in the ISO Standards. The value can be calculated as (column*16) + row, e.g. 01/12 corresponds to the value 28 (1C hex). Figure 2.17 represents the byte encoding space.
0
column
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
r o w
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
C0 GL C1 GR
SPACE
DELETE
These two values are never used in 94 character set.
Figure 2.17: Ranges of the byte encoding space
C0 and C1 are "control character" sets, while GL and GR are "graphic character" sets. For GL, byte 02/00 is always defined as SPACE, and byte 07/15 (normally DELETE) is never used. The 16-by-16 array of columns and rows are numbered from 00 to 15, which contain 256 code positions. Columns 00 to 07 contain 128 character positions which are in one-to-one relation, corresponding to the characters of the 7-bit set of the ASCII table [25], which
Table 2.7: ASCII table
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI
1 DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
2 Space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | } ~ DEL
The interchange of text data (such as Section 8) may require some formatting information. Format effectors were defined in the C0 control set for this purpose, which are shown in Table 2.8.
Table 2.8: Formatting effectors
Category Abbreviatio Name Codes
Format effector BS BACKSPACE 00/08
Format effector HT HORIZONTAL TAB 00/09
Format effector LF LINE FEED 00/10
Format effector VT VERTICAL TAB 00/11
Format effector FF FORM FEED 00/12
Format effector CR CARRIAGE RETURN 00/13
Code extension ESC ESCAPE 01/11
The default character set for SCP-ECG is shown in Figure 2.18.
ISO 646 No designation in C1
The left-handed part of ISO 8859-1 (ASCII)
C0 C1 GR
G1 GL
G0
The right-handed part of ISO 8859-1 (Latin 1)
Use 8-bit environment
Designation also invokes.
Figure 2.18: The default character set for SCP-ECG
The overview of the data part of section 8 is shown in Figure 2.19.
Header 9
Statement 1 var
Statement 2 var
....
Hour Min. Sec.
1 1
1 Year
2
Month Day
1 1
Sequence
number Length Statement field
var 2
1 1
Confirmed Date Time Number of statements
4 3 1
Text NULL 1 var
Figure 2.19: Overview of the data part of the section 8
¾ 5.12 Storing manufacturer specific interpretive statements and data related to the overreading trail - Section 9
¾ 5.13 Lead measurement block - Section 10
¾ 5.14 Storage of the universal ECG interpretive statement codes - Section 11
2.4.2 XML
Extensible Markup Language (XML) is a simple, very flexible text format derived from Standard Generalized Markup Language (SGML). It was developed as a subset of SGML in 1996, and became a W3C recommendation in February 1998. Since November 2001, FDA has been interested in collecting information regarding the content and format of annotated ECG waveform data [26]. An electronic format for the submission of digital ECG waveform data with accompanying annotations was recently reviewed by HL7, which was developed by the Regulated Clinical Research Information Management Technical Committee (RCRIM) for the transportation of digital ECG data. The specifications for the annotated ECG waveform data message are explained in an HL7 informative document [27].
2.4.3 FDA_XML
FDA_XML format was originated from FDA’s New Drug Application (NDA) for biological data submission, often as waveform data. FDA recommended the XML as the standard format for annotated ECG waveform data [26]. FDA proposed specifications are based on the HL7 informative document (HL7 version 3 messaging standard [28]) for annotated ECG waveform data in electronic format. All FDA_XML elements (tags) are derived from the HL7 Refined Message Information Model (R-MIM), which defines all the components that make a specific HL7 informative message [29].
Under the protocol, all time-series biological data could be collected using this model. The R-MIM recreates the HL7's business model from Reference Information Model (RIM) of HL7. All classes in the R-MIM are derived from the six “back-bone” classes in the RIM model. These classes are called
"clones", because they are recreated by copying or "cloning" from the RIM.
No class can be added to the R-MIM in any other way [28]. The graphic of the R-MIM model is shown in Figure 2.20.
Figure 2.20: A graphic representation of an R-MIM model.
FDA_XML elements and attributes are derived from the Hierarchical Message Descriptions (HMD). An HMD is a hierarchical representation of the sequence of elements (i.e., classes, attributes and associations) defined in an R-MIM. Structural attributes like classCode, moodCode etc., are represented as XML attributes in an HMD instance. The HMD structure is shown in Figure 2.21.
Figure 2.21: HMD structure.
The ECG waveform data is assumed to be 2-D in nature. Synchronized ECG datasets can be grouped together based on their common x-axis (sample-time axis). The time stamp can be real time or relating time point.
Figure 2.22 shows the related real-time, recording section and dataset in a common x-axis (time-axis) domain. The relationships among real-time, the recording section, dataset groups and dataset can be thought as a set of related coordinated systems [30]. A FDA-recommended PlotGroup format was proposed by this specification. Figure 2.23 shows the PlotGroup Example of ECG Rhythm Data.
Figure 2.22: Related real-time, recording section and dataset in a common x-axis (time-axis) domain
Figure 2.23: PlotGroup Example of ECG Rhythm Data
