How To Write A Health Record Protocol Data Format For A Medical Record On A Microsoft Ipa Device

Transcription

1 Design of a Vital Sign Protocol Format Using XML and ASN.1 Bayu Erfianto Graduation Committee prof. dr. ir. D. Konstantas dr. ir. I. Widya dr. ir. A. van Halteren A thesis submitted to the department of Computer Science of the University of Twente for the partial fulfillment of the requirements of the degree of Master of Science in Telematics Enschede, The Netherlands 2004

2 II Abstract Tele-monitoring of the condition of patients is an essential component of an electronichealthcare (e-health) system. In an electronic health record system, vital signs which reflect the condition of the patient have to be transferred over the heterogeneous communication network. One of the fundamental problems in dealing with communication in heterogeneous systems is to exchange data in such a way that the data received can be interpreted the same ways as the data before transmission. In the OSI model, the representation of data (including data structures and data types) to be exchanged is a function of the application layer [24]. Meanwhile, the encoding of the data format into a specific bytes stream for transfer is addressed by the presentation layer. This separation of functions allows the application layer deal only with the data format, independent of the encoding type applied in Presentation Layer. The aim of this thesis is to investigate the tool-based design methods to construct a protocol data format for distributed applications that apply separation of data format specification at several abstraction levels, distinguishing between abstract syntax formats and distinguishing transfer syntax format which are meaningful for the applications and the underlying transport systems, respectively. The design methods address some features presented by XML-based data format, while to get more compact transfer syntax, the design methods makes use of ASN.1 encoding rules to produce binary-encoded data format. Many electronic health record systems use XML technology as data format in the application layer. One of the benefits of using an XML-based data format is independency from encoding issue applied in its underlying layer. However, considering to the transfer syntax, an XML-based data format consumes more data length. It is because of the encoding technique used by XML-based data format is based-on textual encoding. By applying encoding rules like in ASN.1 in the presentation layer, the electronic health record system may produce a more compact transfer syntax, due to the feature of ASN.1 encoding rules that can generate binaryencoded data format, which is more compact than textual encoding like used by XML. The design methods are then applied to construct a protocol data format specific for electronic health records, including vital signs data of both continuous-time and non continuous-time type.

3 Table of contents Table of contents III Abstract...II Table of contents... III List of Figures... V List of Tables...VII Chapter 1 Introduction Aim of the thesis Problem studied in this thesis Solution Approach Structure of the Thesis Chapter 2 Physiology of Vital Signs Electrocardiography Electromyography Respiratory Blood Pressure Oxygen Saturation Chapter 3 Vital Sign Format Standards Introduction CEN/TC-251 Standard Communication Protocol FDA DICOM DICOM Message Structure and Encoding DICOM Upper Layer PDU Structure...26 Chapter 4 Design Methods Design Principles Design Methods Message Framework Definition Abstract Syntax Format ASN XML XML Schema and ASN.1 Cooperation Mapping XML Schema to ASN Mapping ASN.1 to XML Schema...52 Chapter 5 Patient Medical Record Specification Design Requirements Patient Demographic Record Specification XML-based Patient Demographic Record ASN.1-based Patient Demographic Record ECG Record Specification Lead Record Specification XML and ASN.1-based ECG Record Specification Blood Pressure Record XML-based Blood Pressure Record Specification ASN.1-based Blood Pressure Record Specification...74 Chapter 6 Demonstrator Implementation Architecture of Demonstrator Interface Implementation Result and Analysis Analysis of Patient Demographic Record Analysis of Lead Record and ECG REcord...83

4 Table of contents IV Analysis of Blood Pressure Record Conclusion General Conclusion Future Work Appendix A: Generating ECG Data Appendix B: Trial Case Scenario Appendix C: Specification of Application Protocol Bibliography Index

5 V List of Figures Figure 1 The heart contraction of heart muscles...12 Figure 2 The Normal 12 Lead ECG Waveform [6]...13 Figure 3 ECG Lead Positions in the body...15 Figure 4 Normal Rhythm and Sinus Bradycardia [7]...15 Figure 5 S-EMG Electrode [9]...16 Figure 6 (a) EMG Signal detected by DE-21 electrode. (b) EMG signal digitized by sampling rate at 2 KHz or every 0.5 ms, taken from [9]...16 Figure 7 Human Respiratory System...17 Figure 8 Pressure Based (left) and Volume Based (right) Respiratory Waveform...18 Figure 9 Oxygen Saturation Measurement...19 Figure 10 SCP Message Layout...22 Figure 11 FDA Application GUI...24 Figure 12 DICOM Message Exchange...25 Figure 13 DICOM Message...25 Figure 14 DICOM Data Set...26 Figure 15 P-DATA-TF PDU...27 Figure 16 P-DATA Service...27 Figure 17 Hierarchical Tree of ECG Record [3]...28 Figure 18 XML Schema Diagram of ecgml Record...28 Figure 19 XML Schema Diagram of Record Type and Waveform Type...29 Figure 20 Abstract Syntax, Local Syntax, and Transfer Syntax...32 Figure 21 Design methods to constitute protocol data format by separating user point of view and transfer point of view at abstract syntax specification...35 Figure 22 Intuitive interpretation of Message Framework consisting Customer Information...36 Figure 23 Iconography of Message Object...37 Figure 24 Message Object Diagram of Customer Information...38 Figure 25 Abstract Syntax and Transfer Syntax Definition...39 Figure 26 Tag, Length, Value in used in ASN.1 Encoding Rule...40 Figure 27 Tag Encoding...41 Figure 28 Example of ASN.1 Tag Encoding...41 Figure 29 Example of in ASN.1Length Encoding...41 Figure 30 Two Examples of Contents Encoding...41 Figure 31 XML Schema Diagram of Customer...46 Figure 32 ASN.1 Compilation process using ASN1C...47 Figure 33 Generating the ASN.1 binary-encoded (BER) data format using ASN1C Java Version...48 Figure 34 Content of Customer.bert viewed by Objective System ASN.1 Viewer...48 Figure 35 XML Schema to ASN.1 Translator from French Telecom...51 Figure 36 asn2xsd command Tool...53 Figure 37 Message Object Diagram of Patient Demographic Record...57 Figure 38 XML Schema Diagram of Patient Demographic Record in...58 Figure 39 Message Object Diagram of ECG Record...63 Figure 40 Message Object Diagram of Lead Record...65 Figure 41 XML Schema Diagram of Lead Record...66 Figure 42 Multiplexing Lead data...69

6 List of Figures VI Figure 43 XML Schema Diagram of ECG Record...70 Figure 44 Message Object Diagram of Blood Pressure Record...72 Figure 45 Specification of Blood Pressure Record in XML Schema Diagram...73 Figure 46 Encoder and Decoder Architecture...78 Figure 47 Refined ASN.1 Encoder and Decoder Module...79 Figure 48 Encoder Architecture in UML package diagram...80 Figure 49 Encoder Architecture in UML package diagram...81 Figure 50 Encoder Interface...82 Figure 51 ECG Generator Interface...82 Figure 52 Decoder Interface...82 Figure 53 Binary encoded of Patient Demographic Record value (using BER). The size of this binary-encoded BER file is 206 Bytes. This binary-encoded file is viewed by ASN.1 Viewer from Objective System...83 Figure 54 Piece of binary-encoded BER file of Lead Record...85 Figure 55 Piece of binary-encoded BER file of ECG Record...86 Figure 56 Binary encoded of Patient Demographic Record value (using BER). The size of this binary-encoded BER file is 206 Bytes. This binary-encoded file is viewed by ASN.1 Viewer from Objective System...86 Figure 57 Plot of Synthetic ECG data generated from ECGSyn...92 Figure 58 Connection Establishment Phase...95 Figure 59 Send Data Phase...96 Figure 60 Disconnection Phase...96 Figure 61 The Location of Service Primitives in SAP...96 Figure 62 PDU Layout...98 Figure 63 PMR PDU Format...99

7 VII List of Tables Table 1 ECG Rhythm...15 Table 2 Categories for Blood Pressure Levels (in mmhg)...19 Table 3 P-DATA Field Description...27 Table 4 Description of ECGRecord...28 Table 5 Description of Waveform Record [3]...29 Table 6 Customer Record Description...38 Table 7 Patient Demographic Record Definition...57 Table 8 ECG Record Definition...63 Table 9 List of standardized ECG lead number descriptors based on CENT/TC Table 10 LeadData Record Definition...65 Table 12 Blood Pressure Record Definition...73 Table 11 Encoding Integer value using BER...84 Table 22 Lead Data...91 Table 13 Tele Trauma Definition...93 Table 14 Coronary Heart Disease Definition...93 Table 15 Respiratory Problem Case Definition...93 Table 16 Home Care and Remote Monitoring Case Definition...94 Table 17 High Risk Pregnancy Definition...94 Table 21 Service Description...97 Table 18 PDU ID...98 Table 20 Relationship among Trial Case and Vital Sign Priority...99

8 Chapter 1 Introduction 8 Chapter 1 Chapter 1 Introduction This thesis is about the design of a data format for an electronic health care (e-health) record. The additional task is to develop a demo to validate the data format. In this introductory chapter, aim of the thesis, problem studied in this thesis, solution approach, and the structure of the thesis will be presented. 1.1 Aim of the thesis The aim of this thesis is to investigate design methods to construct a protocol data format suitable for different composition of data for different health care specialties. The additional aim is to present demonstrator implementation to validate the data formats derived using the design methods. 1.2 Problem studied in this thesis Two main problems are studied in this thesis, though some other related problems also addressed. The first problem deals with the representation of physiological information for electronic health record purpose. The second problem deals with developing toolbased design methods to construct data format. The research questions presented in the following lines drive us to the problem studied in the thesis, as follows: How to present the physiological information of vital signs in an electronic health record? This question leads us to know what kind of parameters, components or elements required to construct an electronic health record. First of all we study the physiological information of a vital sign and come to investigate the available standards that are used for presenting the information of a vital sign. In an electronic health record system, the vital signs data that acquired from sensors are required to be presented in a data format before they are exchanged over a communication network. This data format makes the application program get an abstract understanding of vital signs data to be exchanged over a communication network. Hence, the receiver can do interpret as the same as the sender. The abstract understanding also separates between syntax used by data format in application level and the syntax for transmission.

9 Chapter 1 Introduction 9 There have been many efforts initiated by many academic institutions, governments, and manufacturers of medical instrument to propose the standard of data format for representation of vital signs or biomedical information, including biological signal, images or text. CEN/TC-251 (Comité Européen de Normalisation European, Committee for Standardization, Technical Committee 251) has proposed data format for electronic healthcare application [2, 8]. DICOM (Digital Imaging and Communication in Medicine) [29, 30, 31, and 32] has also defined its own standard which supports exchange between medical imaging system and health care information system. ecgml has also proposed data format for ECG Record application exchange by making use of XML technology as its data format [3]. These efforts aimed at defining data format to carry the medical information over the heterogeneous communication network. By investigating the available vital sign format standards, this inspires us to construct the vital sign data format for our purpose. This will also allow us to study the advantages and disadvantages of those vital sign data format standards. The knowledge will be useful later if we want to build our own vital sign data format, which combines all the positive aspects of the investigated standards. What criteria are needed to develop the design methods to construct data format, and how to apply the developed design methods to construct electronic health record that meet our purpose? In the OSI model, the representation of data (including data structures and data types) to be exchanged is a function of the Application Layer [24]. Meanwhile the encoding of the data format into a specific bytes stream for transfer is addressed by the Presentation Layer. This separation of function allows the Application Layer to deal only with the data format, independent of the encoding type applied in Presentation Layer. By considering the separation of functions among abstraction levels, and transfer syntax format, this thesis comes up the design methods to construct a common protocol data format. Furthermore, we will apply the design methods to construct protocol data format which meets our requirements. 1.3 Solution Approach To address the problems studied in this thesis and to achieve the objectives of this thesis, the activities to approach the solution have been taken as follows: Background study of physiology of vital sign The first task is to collect as many as information about the physiological of vital signs and investigate the required components to build vital sign format standard. However, there are only 5 vital signs that have been taken into account in this thesis i.e. ECG, EMG, Respiratory, Oxygen Saturation, and Blood Pressure. The description of this task is presented in Chapter 2. Investigate the available electronic health record and vital sign format standards The second task is then to investigate the available electronic health record and vital sign format standards. This investigation inspires us to adopt the format standards defined in CEN/TC 251, DICOM, and FDA. There is also ecgml,

10 Chapter 1 Introduction 10 which uses XML technology on top of application layer data format. The protocol data format used in ecgml complies with FDA standard. The description of this task is presented in Chapter 3 Investigate the requirements to develop design methods that is used to construct a data format This task will include design principles i.e. separating the data format specification, distinguishing abstract syntax format, and distinguishing transfer syntax. The design criteria and design choice has also been taken into account to construct of such data format. The description of this task is presented in Chapter 4 Applying the design methods to construct electronic health record data format This task reuses the developed design methods and integrates with the concept, nomenclature and other parameters where applicable from the available electronic health record and vital sign format standards to construct the protocol data format for electronic health records for our purpose. The description of this task is presented in Chapter 5 Develop a demonstrator to validate the design methods and developed data format The developed demonstrator is based-on graphical interface. The demonstrator consists of two parts: Encoder Application and Decoder Application. The architecture of demonstrator application is discussed in Chapter Structure of the Thesis This thesis is organized as follows: Chapter 1: Introduction Chapter 2: Physiology of Vital Sign describes the physiology of vital signs. It presents a brief overview of vital signs from the physiological point of view. Chapter 3: Vital Sign Format Standard discusses some standard used to construct vital signs data format. The presented standards are taken from DICOM, FDA, and CEN/TC It presents the ecgml as well, that is an application of encoding ECG data using XML. Chapter 4: Design Methods presents the design principles and design methods to develop a protocol data format Chapter 5: Patient Medical Record Specification presents the design methods applied to construct a protocol data format for patient medical record purpose. Chapter 6: Demonstrator Implementation presents a demonstrator application to validate the Patient Medical Record data format derived from the design methods. Chapter 7: Conclusion

11 Chapter 2 Physiology of Vital Signs 11 Chapter 2 Chapter 2 Physiology of Vital Signs Aim of this chapter is to present a brief overview of physiology of vital signs. However, this chapter will not discuss all type of vital signs. A brief introduction to electrocardiography is presented in Section 2.1. Section 2.2 gives a brief overview of electromyography. Section 2.3 will give brief overview of human respiratory system. Section 2.4 presents the blood pressure. This chapter will end up with Section 2.5, which gives a brief overview of Oxygen Saturation. 2.1 Electrocardiography Vital signs such as heartbeat, breathing rate, temperature, and blood pressure indicate human's general physical condition 1. The physician can observe, measure, and monitor these vital signs to assess human s health condition. One or more sensors can capture the physical information of a vital sign. Upon capturing the vital signs, the values can also be recorded into analog or digital medium. The electrocardiography is a technique of recording the bioelectrical signal generated by the heart activity. The activity of heart can be measured by placing a sensor on the body of a patient, recorded on a graphical paper and displayed as a graphical representation on a monitor. This graphical representation is called electrocardiogram. Thus, the acronym of ECG may stand for both electrocardiogram and electrocardiography. The following subsection will describe the basic physiology of human heart and its activity, summarized from [6, 7]. Basic Physiology of ECG The muscle of heart always makes contraction in a certain period to pump the blood to all part of human body. This contraction of heart is regulated in a center located in the right atrium 2 known as the sinus node 3 [see Figure 1]. Cells compose heart muscle. These cells have a special property: they spontaneously depolarize with various rates. 1 Definition of vital sign is taken from The Free Dictionary, available at 2 Chamber of the heart 3 An area of special heart tissue that generates the cardiac electric pulse controlled by autonomic nervous system (Mosby Medical Dictionary)

12 Chapter 2 Physiology of Vital Signs 12 The cells of the sinus node depolarize faster than the other heart cells, hence the heart rate is determined here. The electrical impulse generated in the sinus node spreads throughout the right atrium, causing them to contract. P wave represents the impulse from the sinus node to the AV node. When the impulse travels along the structure and reaches "bundle of His", this leads to the generation of the "PR Interval". When the impulse travels across the ventricle (from left to right atrium via left and right bundle branches), this will cause the ventricle to depolarize, it leads to the generation of QRS wave. The impulse resulted from ventricle contraction then propagates to the ventricular myocardium 4 via the "purkinje fibres". This will cause the ventricle to re-polarize. It leads to the generation of T wave. Right Atrium Left Atrium Right Ventricle Left Ventricle Figure 1 The heart contraction of heart muscles The ECG Wave Einthoven, the inventor of first ECG recording device, named the waves he observed on the ECG using five capital letters from the alphabet i.e. P, Q, R, S, and T [7]. The wave on the horizontal axis represents a time domain and the Voltage in the vertical axis [see Figure 2]. On the electrocardiogram, the height and depth of a wave represent a measured voltage. An upward deflection of a wave is called positive deflection and a downward deflection is called negative deflection [6, 7]. The right side of picture on Figure 1 shows the correlation between heart contraction and the basic ECG waveform generated by ECG device [7]. That waveform represents the intervals as well as standard in time (ms) and in voltage (mv). According to Figure 2, it can be summarized that the PQRST waves discuss earlier exist during one heartbeat period [6]. The atrial depolarization wave, (P wave), is a small upward wave. The QRS Complex which represents ventricular depolarization [6], begins as a downward deflection, continues as a large, upright, triangular wave, and ends as a 4 The middle muscular layer of the heart wall (Webster Online Dictionary)

13 Chapter 2 Physiology of Vital Signs 13 downward wave to its base. The dome-shaped T wave indicates ventricular repolarization. Figure 2 The Normal 12 Lead ECG Waveform [6] The ECG waveform can also be annotated to give a remark in each PQRST wave. The averages values of ECG annotation point (from a normal ECG waveform) can be obtained as follows [6]: Peak value of P wave 0.15 mv Peak value of Q wave -0.1 mv Peak value of S wave segment -0.3 mv Peak value of R 1.1 mv Peak value of T wave 0.2 mv Peak value of U wave 0.05 mv P to P Duration 800 ms P-wave duration 100 ms P to R duration 160 ms QRS Complex duration 70 ms Q to T duration 240 ms T wave duration 175 ms S-T Segment 140 ms The ECG data is represented in 2 dimensions of numerical data: time and voltage dimension. In this approach the sampling rate of ECG waveform is required. The following lines are the example of properties of an ECG waveform taken from [6]: Digitization Sampling Rate = 100 samples/s; LSB = 5µV Sampling Interval = 8ms Absolute Error1 = 100µV in a single sample (outside P-QRS-T) Absolute Error2 = ±15µV in a single sample (within QRS) ECG Length = 10 seconds The ECG Leads The ECG signals can be measured by placing pairs of electrodes on the human body. However, the ECG waves from these signals have different shapes, depending on the

14 Chapter 2 Physiology of Vital Signs 14 position on where they are placed. In electrocardiography, those pairs of electrodes are called ECG lead. A standard has been established in electrocardiography that specifies 12 leads and the corresponding positions of the electrodes on the human body [7]. The standard also provides way of obtaining the 12 standard ECG leads by combining the signals from different electrodes. The reason for recording and analyzing more than one single ECG lead is that different parts of the heart can be seen well from different positions by different leads. Hence, each ECG lead provides a different shape of the same heart activity. The 12 standard ECG leads are classified in limb leads, called I, II, III, AVR, AVL and AVF and chest leads called V1, V2, V3, V4, V5, V6 [6,7]. The limb leads provide views of the heart activity in the frontal plane and the chest leads provide views in the horizontal plane of the heart [7]. Figure 3 depicts the position of ECG leads either limbs lead and chest lead in the body with corresponding electrode positions. The meaning of each lead in ECG 12 leads and the way of obtaining them are described in the following lines [7]: I: is a lead obtained between a negative electrode placed on the right arm and a positive electrode placed on the left arm II: is a lead obtained between a negative electrode placed on the right arm and a positive electrode placed on the left foot III: is a lead obtained between a negative electrode placed on the left arm and a positive electrode placed on the left foot AVR: is a lead obtained between the average signal obtained from three negative electrodes (left arm, left leg and right foot) and the signal obtained from a positive electrode placed on the right arm AVL: is a lead obtained between the average signal obtained from three negative electrodes (right arm, left foot and right foot) and the signal obtained from a positive electrode placed on the left arm AVF: is a lead obtained between the average signal obtained from three negative electrodes (left arm, right arm and right foot) and the signal obtained from a positive electrode placed on the left foot V1: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V1 position V2: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V2 position V3: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V3 position V4: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V4 position V5: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V5 position V6: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V6 position V5: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V5 position V6: is a lead obtained between the reference negative electrode and a positive electrode placed on the chest in the V6 position

15 Chapter 2 Physiology of Vital Signs 15 Purposes of ECG Figure 3 ECG Lead Positions in the body Electrocardiography examination is used for detecting many heart problems. It may be used routinely for monitoring the patient's condition during and after surgery, as well as routine health care check. The physician can know the abnormality of heart function by evaluating and analyzing the heart rhythm depicted by electrocardiogram. By investigating the duration of various events within the ECG PQRS cycle, the physician can find out whether these ranges may be considered either as abnormal or not [7]. ECG Wave Table 1 ECG Rhythm Normal range P wave less than 0.12s PR s QRS less than 0.10s The following lines give the example of abnormal rhythm of heart activity taken from [7]. The general terms of abnormal ECG rhythm can be identified as follows: Bradycardia means that a heart rate is lower than normal. Tachycardia means that a heart rate that is higher than normal. Paroxysmal an arrhythmia (irregular heartbeat) that suddenly begins and ends. Sinus bradycardia occurs when the hearts rate is slower than 60 beats per minute. The sinus bradycardia rhythm is similar to normal sinus rhythm, except that the R-R interval is longer than normal. Each of P wave is followed by a QRS Complex. The PR interval is often slightly prolonged and occasionally, the P-waves might be abnormally wide. Figure 4 shows the normal cardiac and the cardiac, which gets sinus bradycardia. The ECG at the top shows normal sinus rhythm. The ECG at the bottom shows sinus bradycardia. R-R Figure 4 Normal Rhythm and Sinus Bradycardia [7]

16 Chapter 2 Physiology of Vital Signs Electromyography Electromyography (abbreviated as EMG) is a technique of recording the bio-electrical signal generated by the electrical activity of a muscle which involves the action of muscles and nerves and generates an electrical impulse known as EMG signal. In some medical conditions the electrical activity of the muscles or nerves behaves abnormally. Investigating and observing these electrical properties of the muscle or nerve can quickly help the physician to diagnose the muscle activities whether behaves normally or not. EMG is obtained by measuring the electrical impulse of a muscle. The measurement of EMG signal can be performed in two ways. The first way is intramuscular technique in which apply thin sensor inside the muscle. The second way is using the electrode attached on the body surface. The famous way is using the second one and result of this measurement well known as Surface EMG (S-EMG) [9]. Figure 5 illustrates an S-EMG electrode placed on the muscle, taken from [10]. Figure 5 S-EMG Electrode [9] The EMG measurement technique initially results the analog data. Thus, this S-EMG Device must digitize the analog S-EMG signal into digital (numerical) representation by implementing sampling technique. The sampling process depicted in Figure 6, generated by a sample Motor Unit Action Potential (MUAP) obtained with a DE-2.1 electrode [9]. Figure 6 (a) EMG Signal detected by DE-21 electrode. (b) EMG signal digitized by sampling rate at 2 KHz or every 0.5 ms, taken from [9]

17 Chapter 2 Physiology of Vital Signs 17 The amplitude of the signal can vary from 0 to 10 mv (peak-to-peak) or 0 to 1.5 mv (rms). The usable energy of the signal is limited to the 0 to 500 Hz frequency range, with the dominant energy being in the Hz range [10]. 2.3 Respiratory Respiration represents the rate of breathing in which a person inhales and exhales. Every 3 to 5 seconds, nerve impulses stimulate the breathing process, or ventilation, which moves oxygen into and out of the lungs. Hence, the respiration rate can be measured in terms of volume of oxygen per breathing period or in pressure in breathing period. Therefore, by observing this rate of breathing we can obtain a quick assessment of a person's health. Figure 7 Human Respiratory System The human respiratory system, as illustrated in Figure 11, consists of organs that supply oxygen to all part of the body [27]. In addition to supplying the oxygen, the human respiratory system also plays a role in taking out the carbon dioxide from the human body. Respiration involves at least three distinguished events [27]: Pulmonary ventilation; known as breathing process. The gas moves into and out of the lungs so that the alveoli of the lungs continuously get fresh oxygen. This relates to the two phases of breathing i.e. inspiration, when gas is flowing into the lungs, and expiration, when gas is leaving the lungs. External respiration; is the exchange oxygen and carbon dioxide in the eternal environment Internal respiration; exchanges O 2 and CO 2 between blood in the capillary vein and body cells. During the respiratory measurement, the measured volume of gas can be distinguished as follows [27]: Tidal volume; the amount of gas moved during normal breathing. The amount of measurement is approximately 500cm 3. Inspiratory reserve volume; the amount of gas that can be taken vigorously over the tidal volume. The amount of measurement is approximately 3100cm 3. Expiratory reserve volume; the amount of gas that can be vigorously exhaled after a tidal expiration. The amount of measurement is approximately 1200cm3.

18 Chapter 2 Physiology of Vital Signs 18 Residual volume; RV is the amount of gas that remains in the lungs even after the most vigorous expiration. The amount of measurement is approximately 1200cm 3. The respiratory measurement can be represented in continues (time series) data as shown in Figure 8 or in non-time series data. If we use time-series data, there are two types of respiratory graphic format i.e. Pressure Mode ventilation 5 and Volume Mode ventilation. Volume Control and Pressure Control mode refer to the parameter that is set or being controlled by the ventilator [17]. Inspiratory time is the parameter that controls cycling of the ventilator. The set volume or set pressure will be delivered within the set inspiratory time. Figure 8 Pressure Based (left) and Volume Based (right) Respiratory Waveform In Volume Control mode, the volume is constant and pressure will vary. On the contrary, in Pressure Control mode pressure is constant and volume will vary [17]. The volume control mode and pressure control mode waveform are illustrated in the Figure Blood Pressure Blood is carried from the heart to all parts of body in vessels called arteries. Based on the definition taken from [16], blood pressure is the force of the blood pushing the walls of the arteries. Each time the heart beats, normally times a minute, it pumps out blood into the arteries. The blood pressure is at its highest beat when the heart pumping the blood into the body part. This is called systolic pressure. When the heart is at rest, between beats, the blood pressure falls down. This is known as diastolic pressure. Blood pressure is always given as these two numbers, the systolic and diastolic pressures such as 120/80 mmhg. The top number is the systolic and the bottom the diastolic. Table 2 gives the examples of classification of blood pressure level taken from [16]. By means of that table the physician can see three cases of blood pressure level i.e. Normal condition, pre-hypertension and hypertension based on the value belongs to systolic 5 The process by which gases are moved in to and out of the lungs (Mosby Medical Dictionary)

19 Chapter 2 Physiology of Vital Signs 19 pressure and diastolic as well. Table 2 Categories for Blood Pressure Levels (in mmhg) Category Systolic (Top number) Diastolic (Bottom number) Normal Less than 120 Less than 80 Normal Less than 120 Less than 80 Pre-hypertension High Blood Pressure Stage Stage or higher 100 or higher 2.5 Oxygen Saturation Oxygen saturation is an indicator of percentage of hemoglobin saturated with the oxygen at the time of measurement. The instrument, well known as pulse oximetry, uses two sources of infra red light that are absorbed by hemoglobin and transmitted to a tissue to a photo detector [18]. Figure 9 Oxygen Saturation Measurement The oxygen saturation values (SaO2) are obtained from the pulse oximetry. Normal oxygen saturation values are 97% to 99% in the healthy individual. An oxygen saturation value of 95% is clinically accepted in a patient with a normal hemoglobin level [18].

20 Chapter 2 Physiology of Vital Signs 20

21 Chapter 3 Vital Sign Format Standards 21 Chapter 3 Chapter 3 Vital Sign Format Standards This chapter discusses some known standard for electronic health data formats used as background materials to develop vital signs data format for our purpose. Section 3.1 presents the introduction of the available vital sign description format standards. The remaining sections will generally describe the common standard encoding, such as DICOM, FDA, and CEN/TC-251. Section 3.5 will end the discussion in this chapter with an example of application that uses XML application for such encoding of a vital sign data, known as ecgml application. 3.1 Introduction Why do we need standard? Medical data, including patient demographic data, needs to be exchanged between medical system and hospital or physician information system. To do so, the medical device, medical archiving system, medical exchange system and medical displaying system must talk with the same language by using the format standard, as well. The format standard is then required to construct the data format that will address physiological information including continuous-time and non continuous-time vital sign data. Thus, by having the format standard, we can design the medical device, medical archiving system, medical exchange system and medical displaying system talk together 3.2 CEN/TC-251 Standard Communication Protocol This section gives a brief overview of the Standard Communication Protocol (SCP) for Computer-assisted Electrocardiography based on the current version pren 1064:2002 prepared by CEN/TC-251 [8]. CEN/TC-251 SCP is a standard that specifies the interchange format and a messaging procedure especially for ECG device-to-host communication and for retrieval of SCP- ECG records from the host to the ECG device. The CEN/TC-251 SCP communicating systems defined and used in this standard works on top of OSI protocol stacks. CEN/TC-251 SCP also defines the information object to model the real world, and objects defined in the information model are considered as

22 Chapter 3 Vital Sign Format Standards 22 managed medical objects. For the most part they are directly available to management services provided by the Common Medical Device Information Service Element (CMDISE) as defined in this standard. SCP ECG Message Structure CEN/TC251 SCP specifies the data record, which is to be interchanged, in several fields. The first field is defined for SCP ECG Record Header, and the remaining records are defined for Sections. The contents of Record Header and Sections are defined in the SCP document [8]. The layout view of SCP-ECG message structure is depicted in Figure 10. Figure 10 SCP Message Layout The SCP-ECG record starts with the Record Header that consists of 2 bytes CRC- CCITT and 4 bytes Record Length. The Record Length header determines the byte length in the Record Length Domain, including 6 bytes of Record Length in the Record Header. The Record Header is followed by some Section fields. Each section field consists of 16 bytes Section Identification Header and the remaining bytes of Section Data Part. CEN/TC251 SCP also specifies two CRC CCITT in every Section ID Header. The difference between CRC in Record Header and Section ID Header is as follow: The CRC algorithm in Record Header calculates the entire range starting from the first byte of Record Length and ending with the last byte in Section Part The CRC in Section ID Header only calculates over the entire Section part except this 2 bytes All section must have identification number. The currently used section is Section 0 to Section 11, and the remaining number is reserved for the future SCP protocol. The following lines describe the Section definition taken from SCP Document [8]. Section Contents (0) This section contains pointers to the start of each of the following sections. This section is mandatory. (1) This section contains general information concerning to the patient (e.g. patient name, patient ID, age, etc.) and the ECG (acquisition date, time, etc.). This section is mandatory. (2) This section contains all of the Huffman tables used in the encoding of rhythm (or "residual signal") and reference beat data. This section is optional.

23 Chapter 3 Vital Sign Format Standards 23 (3) This section specifies which ECG leads are contained within the record. This section is optional. (4) If reference beats are encoded, then this section shall identify the position of these reference beats relative to the "residual" signal contained in Section (6) below. This section is optional. (5) Reference beats for each lead are encoded if the originating device has identified those complexes. This section is optional. (6) This section contains the "residual" signal that remains for each lead after the reference beats have been subtracted, or if no reference beats have been subtracted, the entire rhythm signal. This section is optional. (7) This section contains global measurements for each reference beat type or for each QRS contained in the record and a list of possible pacemaker spikes in the record. This section is optional. (8) This section contains the latest actual text of the diagnostic interpretation of the recorded ECG data, including all over readings if performed. Only the text of the most recent interpretation and over reading shall be included in this section. No manufacturer specific codes should be used in the text. Mnemonic codes as listed in the Universal statement codes may be used if necessary. The data contained in this section shall be consistent with the data in Section 9 and Section 11. This section is optional. (9) This section contains the manufacturer specific diagnostic statements of the analyzing device and overriding trails of the interpretations. The source of the analyzing device and the name of the latest confirming physician (or device) are defined in the "Header section" (Section 1). This section is optional. (10) A set of basic measurements and manufacturer specific measurements (if any) for each recorded lead are presented in this section. This section is optional. (11) This section contains the most recent interpretation and overreading data, coded according to the Universal Statement Codes and Coding. The data contained in this section shall be consistent with the data in Sections 8 and 9. This section is optional. 3.3 FDA One of the activities of FDA (US Food and Drug Administration) is collecting biological data, often as waveforms from subjects being measured. Those measurements are compiled into FDA datasets. The biological data could also be annotated with points and intervals. The annotation on a waveform is performed by giving remark on the dataset. The annotations are intended to give a precise indication of where the measurements points, e.g. P-wave, QRS Complex, and T-wave in electrocardiogram. FDA specifies the data to be exchanged in XML documents. The specifications of FDA XML are as follows [13]: The specification should support submission of continuous-time and multichannel data. Specification for a standard n-lead ECG, e.g. common channel names, annotation types, units, exist at a higher level of abstraction. This higher level might be specified in external documentation. If data compression is desirable, there should be one data compression algorithm. That algorithm must be in the public domain and it must produce loss-less compression. Data compression should be at the file level, i.e. not integral to a particular XML data element or be performed across multiple files. A single encoding mechanism should be defined for representation of the sample data. The data sets should not contain interleaved channels on a sample-by-sample basis.

24 Chapter 3 Vital Sign Format Standards 24 The FDA makes use of XML as its data set specification. The FDA dataset is presented in two-dimensional (2-D) format. Therefore, the datasets can be considered as a part of a real time system. Thus, the 2-D FDA datasets can also be placed in a group when they are related by synchronizing them in a common x axis. For instance, the ECG leads can be grouped and synchronized together because they share a common x-axis sample time dimension. Figure 11 depicts the FDA application interface that is displaying the synchronized leads. 3.4 DICOM Figure 11 FDA Application GUI This section only describes the DICOM description standard that relates to representation of vital signs data format. DICOM stands from Digital Imaging and Communications in Medicine. This standard was defined by the National Electrical Manufacturers Association (NEMA) to give the solution on distribution and viewing of medical images, such as CT 6 scans, MRI 7, and ultrasound. Currently, DICOM is the most common used standard for sending and receiving medical images from a hospital. Generally, DICOM Standard defines: DICOM Application Protocol, including Protocol Data Unit Format Image Format File Structure Format 6 Computerized Tomography, a technique for examining the internal structure of the body (Mosby Medical Dictionary) 7 Magnetic Resonance Imager, a diagnostic technique which uses magnetic field or radio wave to obtain computerized image (Mosby Medical Dictionary)

25 Chapter 3 Vital Sign Format Standards DICOM Message Structure and Encoding The DICOM protocol data format, known as DICOM Message, and encoding is defined in Part 5 [31] of DICOM document. In this document the protocol data format and encoding of data set is explained. Data Set is a part of DICOM Message that conveys the object of medical image. DICOM service user sends the DICOM Message that contains commands and associated data set, to the receiver by means of DICOM Service Provider. Figure 12 shows the sequence diagram of DICOM Message exchange. Figure 12 DICOM Message Exchange DICOM Message Structure and Command Set DICOM Message is composed of a Command Set field followed by Data Set fields. The Command Set is used to indicate the operations/notifications to be performed on or with the Data Set. A Command Set is constructed of Command Elements. Command Elements contain the encoded values for each individual field of the Command Set per the semantics specified in the DIMSE (DICOM Message Service Element) protocol. The complete specification of Command Set can be seen in DICOM Document Part 5 [31]. DICOM Message Command Set Data Set Tag Length Value Data Element... Data Element Tag VR Value Length Value Field Figure 13 DICOM Message Data Set Data Set fields represent specific real world information object. A Data Set is constructed of Data Elements. Data Elements contain the encoded Values of Attributes of that object. The specific content and semantics of these Attributes are also specified in Information Object Definitions document [31]. For instance, the scanned image has Pixel Data, Overlays, and Curves are Data Elements whose interpretation depends on

26 Chapter 3 Vital Sign Format Standards 26 other related elements. Figure 14 shows the lay out of DICOM Data Set. Data Set may consist of sequence of Data Element. Data Elements Figure 14 DICOM Data Set Tag followed by Value Representation (VR), Value Length, and Value Field, respectively, uniquely identifies a Data Element. The Data Elements in a Data Set shall be ordered by increasing Data Element Tag Number and shall occur at least once in a Data Set. Data Element Tag consists of ordered pair of 16-bit unsigned integers representing the Group Number followed by Element Number [30]. Value Representation (VR) field is an optional. The value of VR for a given Data Element Tag is defined in Data Dictionary in DICOM Standard Part 3 [30]. Value Length consists of a 16 or 32-bit (dependent on VR and whether VR is explicit or implicit) unsigned integer containing the Explicit Length of the Value Field as the number of bytes (even) that make up the Value. It does not include the length of the Data Element Tag, Value Representation, and Value Length Fields DICOM Upper Layer PDU Structure PDU, stands for Protocol Data Unit, is the unit of message exchanged between peer entities within the OSI or TCP/IP Layers. There are two type of information included in PDU i.e. Protocol Control Information (PCI) and User Data [22]. Applying to DICOM application, the DICOM Upper Layer protocol that carries the DICOM message has been defined [33]. This upper layer PDU is known as P-DATA-TF PDU. A P-DATA-TF PDU is composed of a sequence of mandatory fields followed by a variable length field. Figure 15 shows the P- DATA-TF PDU layout and the description of each field in P-DATA-TF can be seen in Table 3.

27 Chapter 3 Vital Sign Format Standards 27 Figure 15 P-DATA-TF PDU Table 3 P-DATA Field Description Bytes Field Name Description 1 PDU-type 04 H 2 Reserved This reserved field shall be sent with a value 00H but not tested to this value when received. 3 to 6 PDU-length This PDU-length shall be the number of bytes from the first byte of the following field to the last byte of the variable field. It shall be encoded as an unsigned binary number. 7 to xxx Presentation data- value Item(s) This variable data field shall contain one or more Presentation-data-value Items(s). This P-DATA Service will be initiated by Application Entity to cause the exchange of DICOM Messages. Following Figure 16 illustrates the transfer of DICOM Message, by means of DICOM Upper Layer (UL) Service Provider, on an established association between two-peer applications. 3.5 ecgml Figure 16 P-DATA Service The ecgml [3] is an application that defines how to construct the ECG information using XML-based data format. After having the set of discrete ECG data, ecgml application does not directly go to specify this data into XML format. The ecgml application first represents all related information of ECG data in the hierarchical structure as depicted in Figure 17.

28 Chapter 3 Vital Sign Format Standards 28 Figure 17 Hierarchical Tree of ECG Record [3] The major goal of ecgml application is to provide a platform independent for ECG record exchange by using XML message. The XML message represent hierarchical ECG record in which ECG waveform itself can be described by basic feature such QRS duration with text based interpretation. ecgml will enable the seamless integration of ECG data into Electronic Patient Records and medical guidelines. This protocol can support data exchange between different ECG acquisition and visualization devices. The accompanying application comfortably supports medical tasks such as pattern recognition and identification of relevant wave markers. The advantages of separating content from presentation information have proven very successful, where ECG data stored in the ecgml can be delivered in customized output format to suit different devices and applications. Thus, ecgml is a useful tool to facilitate the representation, exchange and interpretation of ECG information. Figure 18 shows the record structure represented in XML Schema Diagram. The XML Schema Diagram represents the same ecgml Record Structured shown in Figure 18. Table 10 contains the description of each element used to construct ecgml Record. Figure 18 XML Schema Diagram of ecgml Record Table 4 Description of ECGRecord ECG Record The Root Element for XML- Based ECG Record Elements Description Required Data Type Example StudyID Unique ID for an ECG Record Required String ECG00001 StudyDate Study date: YYY-MM-DD Required Date StudyTime Study Time: HH-MM-SS-SS Optional Time

29 Chapter 3 Vital Sign Format Standards 29 Comment Comment on the ECG Record Required String PatientDemographic Describes Patient Demographic Required Table Record ECG Data Required Table MedicalHistory Describes patient clinical problem Optional String Bradicardia Diagnosis Diagnosis Interpretation Optional string Myocardial infraction The important element in ecgml is the Record element that represents the ECG waveform and its annotations. Multiple recorded ECG waveforms may exist in this Record element. Figure 19 shows how ecgml constructs the Record element that contains the ECG record data. Figure 19 XML Schema Diagram of Record Type and Waveform Type From Figure 19 we can see that ecgml application presents ECG data either in ECG waveform or annotation points. ecgml generates waveform based on FDA recommendation PlotGroup. This waveform is represented by series of value along the X and Y-axis that is a plot of Voltage (Y value) vs Time (X values). The description of ecgml waveform record can be seen in the following Table 11. Table 5 Description of Waveform Record [3] Waveform A 2D plot with X and Y axis is used to Display the ECG waveform Elements Description Required Data Type Example XValue Describes X axis Required Complex Type XOffset Offset from the start Required Time 00:23:10 Duration Duration of each record Optional Time 00:00:10 SampleRate Sample rate Hz for ECG Record Required UnsignedInt YValue Describes Y axis Required Complex Type Unit Name of based unit for X axis Required Use UCUM when mv appropriate FileLink Reference for external data Optional String RealValue Real value of ECG Data Required String

30 Chapter 3 Vital Sign Format Standards 30 From Offset from the origin on the x Required Time or 20:10:00 axis to the beginning of waveform samples To Offset from the origin on the a axis Required Time or 21:00:00 to the ending of waveform samples Data The list of Y value Required A list for 1.25,1.20 float values string Comment Comment on this format Optional String Binary Data Binary Representation of ECG Required Hexadecimal Data Encoding Encoding Scheme for embedding Required Base64 the binary data within XML document From Offset from the origin of x axis to Required Time or 00:00:02 the beginning of waveform samples To Offset from the origin of x axis to Required Time or 00:20:00 the ending of waveform samples Scale Scale factor to use to convert a Required Float 1.0 binary data into a real value Data Encoded binary data Required string AB454CA Annotation record is used to describe events specific to the corresponding ECG waveform channel. It includes PointNotation and WaveNotation. The important element within this annotation record is WaveNotation that includes descriptions of ECG waveform such P wave, QRS wave, and T wave.

31 Chapter 4 Design Methods 31 Chapter 4 Chapter 4 Design Methods This chapter presents the designs methods of constructing a data format. Section 4.1 discusses the general design principles dealing with separation of functions of data format specification. Section 4.2 discusses the design methods to build a data format. Section 4.3 discusses the message framework definition that is going to be used to build abstract syntax format. Section 4.4 discusses the distinguished abstract syntax format that is from user point of view and system point of view. Section 4.5 presents the example case of applying the design methods to build a protocol data format. Section 4.6 discusses the XML Schema and ASN.1 cooperation which is expressed in mapping from XML Schema to ASN.1 and vice versa. 4.1 Design Principles One of the fundamental problems dealing with communication in different systems is the exchange of data in such a way that the data received is the same with data transmitted. In the OSI model, the representation of data format (data structures and data types) to facilitate this exchange is a function of the Application Layer [24]. Meanwhile the encoding of the data into a specific bytes stream for transfer is addressed to the Presentation Layer. This separation of functions allows the Application Layer to deal only with the data format, independent of the encoding type applied in Presentation Layer. The data format is usually defined in abstract manner viewed from the perspective of application entity (user entity). In this abstraction, the data format is still human readable that makes it easier to integrate with another application and also easy to debug. As described in the previous paragraph, the application layer deals only with common representation of data format. The application layer presents this format in unit of transfer: Application Protocol Data Units (APDUs).

32 Chapter 4 Design Methods 32 Figure 20 Abstract Syntax, Local Syntax, and Transfer Syntax Protocol Data Unit is information that is delivered as a unit between peer entities of a network and that may contain control information and data. In layered protocol system, a PDU can be considered as a unit of data that is specified in a protocol at a given layer that consists of protocol-control information of the given layer and user data of that layer [24]. Meanwhile, Protocol Data Format describes message formats which can be syntax (ASN.1 syntax or XML Syntax). Application Layer defines protocol data format independent of its underlying protocol layer that is using an abstract syntax format [24]. The Presentation Layer is concerned with the representation of information in transit between two application entities. In the heterogeneous system, e.g. Open System A and B as shown in Figure 20, a system may use different format for the local representation of a message, known as local syntax. Hence, a common representation of a data format must be agreed if a message is exchanged between two systems, e.g. Open System A and B. The presentation layer then has to change the syntax that is used by application layer, with the syntax that is agreed by both open systems to exchange the message while in transit [24]. Thus, implementations of application entities will make use a local syntax to represent the APDUs, and the presentation layer constitutes a transfer syntax as a common representation of a data format. This thesis is emphasized to the design of protocol data format by considering three design principles as follows: Separating the data format specification This separation defines the format in the perspective of application entities (abstract syntax) and in the perspective of transport provider (transfer syntax). This separation of data format specification makes the abstract syntax independent of transfer syntax Distinguishing abstract syntax format The abstract syntax format is distinguished into two point of views i.e. user point of view and system point of view. From the user point of view, it focuses on how to keep abstract syntax format still human readable that makes it easier to debug and modify. From the system point of view, it focuses on abstract syntax format which can be encoded by rules to obtain efficient (in term of data length) transfer syntax. In this thesis, the relation between these two kinds of abstract syntaxes is also discussed. Distinguishing Transfer Syntax The selection of transfer syntax to be used is typically based on a criterion that is the transfer syntax must be efficient in term of message length and processing time. However, for simplicity user friendly transfer syntax (e.g. character-based encoding) is also used.

33 Chapter 4 Design Methods 33 To address such design principles, the design methods have been defined. The discussion of the design methods is going to be presented in the following section. 4.2 Design Methods This section discusses the design methods to constitute protocol data format by considering the design principles discussed in the previous section. The design methods are distinguished in design-time, compile-time, and run-time. The outcome of designtime is specification of protocol data format in abstract syntax format. The outcome of compile time is encoding run-time using BER or PER. The outcome of run-time is the BER/PER binary-encoded protocol data format. Design-time method Design time method distinguishes the preparation of making abstract syntax format and making of abstract syntax format itself. The following lines describe activities involved in design-time method. Message Framework Definition This thesis proposed a method to presenting the object of information to be exchanged in a message framework using hierarchical message structure. The use of hierarchical message structure in this thesis is inspired by Health Level 7 (HL7) Message Framework Definition [19]. We choose message object diagram as a tool to represent the hierarchical message structure. Through this hierarchical message structure, the application developer can see the relationships among the object of information. The notation used in this thesis for representing hierarchical message structure is adopted from Health Level 7 (HL7) Message Framework Definition. HL7 uses a notation to presenting message framework in hierarchical message structure i.e. message object diagram. While there is no special notation used by ecgml Application. The application developer may also choose UML for representing hierarchical message structure. However, the UML structure is more complicated than the message object diagram used by HL7 standard. The message object diagram notation only shows the relationship among object of information, however, it cannot present the attribute such as a data type of each element. To address this problem, it is desirable to make a table that complementary describes elements and attributes used in message object diagram. The elements and attributes defined in message object diagram and its description table is then used to build abstract syntax format. The further description of message framework definition will be given in Section 4.3 Abstract Syntax Format Specification The distinguished abstract syntax format has been identified in the design principles described in previous section. To address this distinguished abstract syntax format, XML (XML Schema including XML Document) has been chosen as data format used in the user point of view (see Figure 22). It is because of XML has syntax that can easy to integrate with the existing application. Nowadays, many applications use XML-based data format on top of application layer. On the other hand, XML also has more readable syntax. Then, the application designer can use the description table and message object diagram obtained from the previous method to construct XML Document and its XML Schema specification.

34 Chapter 4 Design Methods 34 If character-based encoding is preferred than binary-based encoding, the application designer can directly make use of XML (including XML Schema and XML Document, see option 1 in Figure 22) as data format to carry the information. The application developer then also needs the XML API (XML Application Programming Interface, such as DOM or SAX, see [33]) to process such XML Document. The discussion about XML (including XML Schema and XML Document) will be presented the Section 4.4. If the application developer prefers having more compact transfer syntax, the application developer may choose ASN.1 to address the system point of view (option no 2 in Figure 21). As we know, ASN.1 employs encoding rules (such as Basic Encoding Rule or BER, and Packed Encoding Rule, or PER) that can obtain more compact transfer syntax. This compact transfer syntax is in binary format. The further abstract syntax format specification, including ASN.1 and XML, will be presented in Section 4.4. In our design methods, there are two options to have the ASN.1 specification. The first option (option 2a in Figure 21) is having the ASN.1 specification by automatically translating from XML Schema specification. This automatic translation is performed by a tool which applies ITU X.694 standard, Mapping from XML Schema to ASN.1. The second option (option 2a) is manually defined ASN.1 specification. The process of mapping from XML Schema specification to ASN.1 specification (and vice versa) is described in Section 4.6. Compile-time; The ASN.1 specification(s) yielded from the previous method becomes an input for compile-time method. The compiler takes ASN.1 specification(s) as input, verifies it and then generates data structure and encoding/decoding functions. The encoding/decoding functions is then used later to perform encoding and decoding of ASN.1 values using ASN.1 encoding/decoding rules, PER or BER. The data structure and encoding/decoding functions must be compiled to produce a run-time application. To do so, the language compiler (typically C or Java) takes place encoding/decoding function and data structure as input of language compiler. The language compiler then generates encoding/decoding run-time (using BER or PER) application. During the execution, this encoding/decoding run-time is used together with ASN.1 run-time library (provided by ASN.1 compiler vendor) and application behavior run-time (made by application developer) Run- time; The run time method is intended to produce the ASN.1 binary-encoded (using BER or PER) data format (can be stored in a file). The execution process (see Figure 24) is performed here by involving application behavior run-time, encoding/decoding run-time, and ASN.1 encoding library. The execution process takes the values to be exchanged as input, and the outcome of the execution process is ASN.1 binaryencoded (using BER or PER) protocol data format. This ASN.1 binary-encoded protocol data format is ready to be exchanged. Following Figure 21 depicts the design methods used in this thesis to constitute a generic protocol data format. In Chapter 5, the design methods are used specifically to construct a data format for electronic health record.

35 Chapter 4 Design Methods 35 Definition of Message Object Diagram Option 1 XML Schema and XML Document Design-time Message Framework Definition Making Description Table Description Table User point of view Specification of Message in XML (XML Schema and XML Document) XML Schema Option 2a Automatic Mapping from XML Schema to ASN.1 Specification performed by a tool System point of view Option 2 ASN.1 Specifications Option 2b Manual Mapping to generate ASN.1 Specification Abstract Syntax Specification Compiling ASN.1 Specification (BER,PER) Generated Encoding/ Decoding Method & Data Structure Compile time Compiling (using a language compiler) Encoding Run-time (BER,PER) XML API Values to be exchanged Application Behavior Run-time ASN.1 Encoding Run-time Library (PER,BER) Legend Run-time Library Run-time Execution Input/ Output XML-based data format ASN.1 (BER,PER) binary-encoded data format Process XML-based Figure 21 Design methods to constitute protocol data format by separating user point of view and transfer point of view at abstract syntax specification 4.3 Message Framework Definition The definition of message framework can be started from abstraction degree e.g. expressed in concepts used by communication entities. A message framework can be composed by many elements. Elements are components in a message that are related to object which represents the real object in the perspective of the communication entities. The abstraction of a message can be identified as follows [19].

36 Chapter 4 Design Methods A message can be composed by objects or elements 8 2. Each element has a data type. 3. Each data type can be assigned as: data type associated with a simple attribute, or list of elements which are defined as the as a complex data type. For instance, a client application process wants to send the information about a new bank customer. First of all, the application designer can compose a message framework that will carry the customer information. This message framework gives an abstract understanding of customer information. Later on, the application protocol designer can directly use this message framework to construct abstract syntax format. The customer information may be composed by several objects or elements e.g. Name, Address, Account Number and any related elements. Each element may also have children; Name may have children FirstName, MidleName and LastName, respectively; Address may have children e.g. Street, Zip, and Phone, respectively. Concerning to abstraction of message, a specific data type can then be assigned to each element. The intuitive interpretation is used to show the relationship among message, elements and group of elements related to the customer information, as shown in the Figure 22. However, this intuitive interpretation is not going to be used in the specification later, because this is legally used by a standard. Instead of using this intuitive interpretation, this thesis will use the existing legal notation that will be described in the next subsection. From the Figure 22, Customer is the name of message framework. Element Name and Address is defined as complex data type which means that both elements data type refers to the group of other elements. The data type of simple type element within a complex type can also be defined. For instance, LastName is a simple type element, which is defined as complex type Name. The data type of LastName is defined as string. The enumerated data type is also introduced in Gender element. The enumerated is intended to express the itemized data e.g. {male, female}. Age element has bounded integer data type. The bounded data type can be used in case the range of value to be used in data is already known. Figure 22 Intuitive interpretation of Message Framework consisting Customer Information The above abstraction of message does not mean to be a complete message framework. An element in the Figure 22 can be optional or required. This optionality of an element is important later in specifying an abstract syntax format. To give more complete 8 This thesis will use element instead of object

37 Chapter 4 Design Methods 37 abstraction of a message framework, it is necessary to assign the optionality of an element. This will be described as follows. The element as an object view may have optionality [19]: Required. The object or element must appear in the message framework Optional. The object view may appear in the message when required. The cardinality of an element refers to how many times the value may appear in the element. It is specified as a pair of numbers specifying the lower bound and the upper bound, as in (1,m). The left number is the lower bound. It may be zero, one, or any other positive integer. When it is zero, the element may have no value to be contained in a message. The right number is the upper bound. It may be one, any other positive integer, or lower case "m." Message Object Diagram Message Object Diagram is notation used in HL7 Message Framework Definition [19]. The message object diagram is used to describe the relationship among elements. The elements in message are represented in hierarchical structure. The relationship of an element whether belongs to simple or complex type can also be defined here. The iconography used to draw a message object diagrams is shown in Figure 24 [19]. Figure 23 Iconography of Message Object Figure 24 shows the message framework of customer information presented in message object diagram. The root element of this message is Customer. This root element has some elements i.e. Name, Address, Sex, and Age. Name and Address are defined as complex type object because each of them has several child elements. The Gender and Age element does not contain child element. Hence, both are defined as simple type object.

38 Chapter 4 Design Methods 38 Figure 24 Message Object Diagram of Customer Information There are some limitations of having message object diagram notation: The attribute of element such as data type cannot be assigned in element the specific data type e.g. enumeration cannot be assigned in an element However, those limitations can be figured out by making the description table that complementary describes elements and attributes used in message object diagram. This table can bridge the gap of some drawbacks that cannot be defined in message object diagram notation. Table 6 Customer Record Description Element Description Required Data Type FirstName The First Name of Customer Required String LastName The Last Name of Customer Required String Street Describes customer s address Required String City Required String Zip Required String Phone Customer phone number Optional String AccountNumber Customer Account Number Required String Gender The gender of customer Optional Enumeration {Male(0), Female(1)} Age Date of birth Optional Integer(1..255) 4.4 Abstract Syntax Format According to OSI Reference Model (OSI RM), the data exchange mechanism in layer 1-5 is performed typically in bytes stream. However, the Layer 6 is rather different. This layer is concerned with transparent exchange of information between application services. There are two major source of difficulty in specifying a protocol data format in the OSI layer 6 and 7, i.e. the confusion that exists between the representation of information to be carried by the protocol, and the mechanism used to carry such information [24]. In OSI RM terminology, the information to be carried by a protocol is referred to as

39 Chapter 4 Design Methods 39 abstract syntax, and the protocol used to carry this information is well known as transfer syntax. Figure 25 shows two terminologies on Layer 6 and 7 of OSI RM. Abstract syntax further means that the structured data format is used to carry the information passed from application layer in one machine into another machine. Each machine may locally have different format to represent the content of information to be exchanged. The format is also known as local syntax. Figure 25 Abstract Syntax and Transfer Syntax Definition There are two major types of encoding mechanism i.e. character-based encoding and bit or binary-based encoding. In character-based encoding, all information is transformed to text format before transmission is performed. Example: A floating-point number might be transformed to the textual string of characters 4,678, and this string is then encoded using some character, for instance using US-ASCII character set, where each character is sent as one byte. Binary-based encoding is rather different. In binary encoding, all Information is transformed to a standardized binary format, not dependent on the architecture of a particular computer. For a floating-point number, the mantissa and exponent are sent as bit strings. The example of binary-based encoding is ASN.1 BER (Basic Encoding Rule) and for character-based encoding is XML. The next section of this paper will describe several encoding issues like comparison between ASN.1 and XML and the new notation for ASN.1 based-on XML schema ASN.1 ASN.1 is the international standard for representing data format (types and structures). CCITT published the first version of the ASN.1 standard X.409 in A newer version of ASN.1 is specified in X.208 (1988). One benefit of using ASN.1 is that ASN.1 uses encoding rules that will encode the ASN.1 structure and values to obtain more compact protocol data format in binaryencoded data, a binary encoding theoretically may save up to 80% or even more relative to corresponding character-based encoding [34]. The use of ASN.1 has been defined in many national and international standards, including X.500 standards, cellular telephony, security, videoconferencing, biometrics application, etc [15]. ASN.1 supports many types identifier as follows: Universal: generalized type like INTEGER and REAL, the Universal types are

40 Chapter 4 Design Methods 40 defined in X.208 Context-Specific; related to the specific context in which they are used Private; user defined Application; whose type is specific to an application ASN.1 Record Structure The common structure to construct a message in ASN.1 can be achieved by gathering values from several other types and forming a record structure from the combined types. This can be done in two ways i.e. ordered and unordered. The ordered collection of values type is named as SEQUENCE and the unordered known as SET. These collections may either be composed of finite of distinct type or infinite number of the same type. The following list is the summary of the difference of SEQUENCE and SET. SEQUENCE: specify an order list of all objects types SEQUENCE OF: specify an order list of objects of the same type SET: specify unordered list of all objects type SET OF: specify unordered of all objects of the same type The use of SEQUENCE and SET in ASN.1 specification can be clearly distinguished in the following example: Name :: = SEQUENCE { FirstName VisibleStringString, LastName VisibleString, } CustomerName ::= SEQUENCE OF Name Address::= SET { Street VisibleString, City VisibleString, Zip VisibleString, Phone VisibleString } CustomerAddress ::= SET OF Address ASN.1 Encoding Rule Having specified an abstract syntax format in ASN.1, the encoding rules can then be applied in the manner of how to encode the ASN.1 structure (including ASN.1 values) into binary data format. The concept of ASN.1 Basic Encoding Rule (BER) will be discussed in the following in this thesis. The encoding of a certain ASN.1 data type comprises three parts i.e. with Tag, Length, and Value, known as TLV. The Tag identifies the type; The Length identifies the length of encoded values, and the value identifies the encoded values in byte. Figure 26 shows the layout of encoding ASN.1 in Tag, Length, and Value. Tag Length Value Figure 26 Tag, Length, Value in used in ASN.1 Encoding Rule The first byte represents the tag identifier. This tag identifier is composed by Class identifier, P/C identifier (primitive/constructed encoding), and the number of the tag,

41 Chapter 4 Design Methods 41 respectively. Primitive encoding means that the value contains real encoding; while constructed encoding contains sequence of further encoding Class P/C Number Figure 27 Tag Encoding The first two bits encode the Class identifier as follows: Class Bit 8 Bit 7 Universal 0 0 Application 0 1 Context-specific 1 0 Private 1 1 ASN.1 data type such as INTEGER is indicated as primitive encoding number 02, where the SEQUENCE is constructed as encoding number 30. The example of Tag Encoding is simply shown in the Figure INTEGER (Universal 2-Primitive) SEQUENCE (Universal 16-Constructed) Figure 28 Example of ASN.1 Tag Encoding The next second byte in TLV represents the length of encoded value. The length of short encoded value can be allocated in one byte, whereas the longer one needs long bytes. The following Figure 29 shows the various Length bytes to represent the length of encoded value bytes length 3004 bytes length Figure 29 Example of in ASN.1Length Encoding The last byte in TLV represents the contents depends on the particular data type to be encoded. Figure 30 shows the two examples the encoding of INTEGER value and VisibleString value INTEGER 1560 Visible String Hello Figure 30 Two Examples of Contents Encoding From the previous example, hence the binary-encoded (BER format) of Integer 1560 is Binary Hex XML XML, Extensible Markup Language, is a W3C-supported standard for document markup. It defines a generic syntax used to mark up data with simple, human-readable tags. It provides a standard format for computer documents. XML is a markup language for text documents where the data is included in XML documents as strings of text. In XML the basic unit of data and markup is known as an element. The XML document

42 Chapter 4 Design Methods 42 defines the exact syntax hence this markup must follow: how elements are delimited by tags, what a tag looks like, what names are acceptable for elements, where attributes are placed, etc. The XML-based applications are easily for editing, thus the XML-based document is more human-readable. The advantages of XML application including: applicability of existing text tools, flexibility and readability, ease of debugging suitability as a basis for other text vocabularies The data is structured in elements and defined using tags XML Syntax This section will briefly describe the XML Syntax. There are many sources available that contain more details description about the XML syntax 9. Building an XML document begins with the definition and identification of the data that will be displayed to end user. First of all, the XML document should be well-formed which means that this XML document should conform to the syntactic rule. The data is structured in elements and defined using tags that indicate what a data element represents. Elements are the building block of an XML document. In XML document, element must have a start and end tag. The following example shows an XML document of Customer s name: <Customer> <Name> <FirstName type="string">bayu</firstname> <LastName type="string">erfianto</lastname> <Name> </Customer> There is also an attribute which is as additional information for elements. In the above example, type is an attribute with value string. DTD and XML Schemas The original XML recommendation only defines a way to describe the elements, attributes, and data types allowed in an XML document: the XML Document Type Definition (DTD). However, more flexible and powerful way to describe the XML Document model was then required, and work began on the XML Schema, which became available as a final recommendation in May of 2001 [33]. An XML Document is said to be valid if it conforms to the content model described in its associated DTD or XML Schema [33]. Although the metadata required by an XML parser to validate an XML document can be conveyed by a DTD or XML Schema, however, an XML Schema definition is more specific than a DTD. XML Schema provides much better control over the content of XML Document than a 9

43 Chapter 4 Design Methods 43 DTD. The following lines will give the brief overview of XML Document type Definition (DTD) and XML Schema. XML Data Type Definition (DTD) The purpose of DTD is to define a legal building block of an XML document. DTD defines the document structure by showing a list of legal elements. A DTD can be declared inside the XML Document or as external reference. The question can then be come up: why an XML Documents need DTD. By using a DTD, the end users can agree to use a standard common data type definition. Our application can also use a DTD to verify that the data format sent by the other user is valid. The following lines show the syntax of DTD declared inside the XML Document Specification 1 Customer.xml with internal DTD <?xml version="1.0"?> <!DOCTYPE Customer [ <!ELEMENT Customer(Name, Address,AccountNo,Gender,Age)> <!ELEMENT Name (FirstName, LastName)> <!ELEMENT FirstName (#PCDATA)> <!ELEMENT LastName (#PCDATA)> <!ELEMENT Address (Street, City, Zip, Phone)> <!ELEMENT Street (#PCDATA)> <!ELEMENT City (#PCDATA)> <!ELEMENT Zip (#PCDATA)> <!ELEMENT Phone (#PCDATA)> <!ELEMENT AccountNo (#PCDATA)> <!ELEMENT Gender(#PCDATA)> <!ELEMENT Age(#PCDATA)> ]> <Customer> <Name> <FirstName type="string">bayu</firstname> <LastName type="string">erfianto</lastname> </Name> <Address> <Street>Hengelose Straat </Street> <City>Enschede</City> <Zip>7514AK</Zip> <Phone> </Phone> </Address> <AccountNo>ABN </AccountNo> <Gender>Male</Gender> <Age>33</Age> </Customer> Line 2 to 15 is the declaration of internal DTD to be used by such XML document. The content of XML document itself is starting from line17 to line 31. If DTD is desirable to be used as external reference, the DTD external file link should be declared as follow: <!DOCTYPE Patient SYSTEM "customer.dtd"> where the content of customer.dtd can simply be copied starting from line 2 to line 15 from the customer.xml file. XML Schema XML Schema acts as a framework for defining the content, format and structure of an XML document. XML Schema is the new alternative to DTD. Just like a DTD, the purpose of a Schema is to validate and define the legal building block of an XML document.

44 Chapter 4 Design Methods 44 To build an XML Schema, we could simply follow the XML Document structure and define each element as we find in it. To start with, we have to type xs:schema element to open a Schema document and followed by the XML name space 10. This name space conforms to the W3C XML Schema definition language. To start the contents of XML Schema document, it starts from the elements definition <xs:schema> and ends up with the end of schema definition </xs:schema>. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" </xs:schema> Like ASN.1 notation, there is also sequence in XML notation. The sequence is a compositor that defines an ordered of sub-elements. We can also identify the two other compositors, choice and all in the following sections. Now we can define the first name and last name elements as simple types; they don't have attributes or non-text children. The type xs:string indicates a predefined XML Schema data type: <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> The complex data type can be specified by opening with <xs:complextype> closing with </xs:complextype>, as shown in 4 and 11 in Specification 2. The Specification 2 shows the XML Schema specification that is used to validate the content, format and structure of Customer.xml as described in Specification 1 (excluding internal DTD) Specification 2 Customer.xsd <?xml version="1.0" encoding="utf-8"?> <!--W3C Schema generated by XMLSPY v5 rel. 4 U ( <xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:complextype name="addresstype"> <xs:sequence> <xs:element name="street" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="zip" type="xs:string"/> <xs:element name="phone" type="xs:integer"/> </xs:sequence> </xs:complextype> <xs:element name="customer"> <xs:complextype> <xs:sequence> <xs:element name="name" type="nametype"/> <xs:element name="address" type="addresstype"/> <xs:element name="accountno" type="xs:string"/> <xs:element name="gender" type="xs:string"/> <xs:element name="age" type="xs:integer"/> </xs:sequence> </xs:complextype> </xs:element> <xs:complextype name="nametype"> 10 The XML Schema name space definition is clearly described at: 1/#composition

45 Chapter 4 Design Methods <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:schema> 4.5 Example Case This section will give the small example of applying the design methods to construct protocol data format. In this example, the protocol data format in XML-based and ASN.1 binary-based will be given. The case to be carried out in this example is still customer information. The first design methods explain how to build a message framework that describes the data format in hierarchical structure. This comes out with the message object diagram depicted in Figure 24 and description table in Table 6. The outcome of this method is then used to define abstract syntax format. Our design methods define two type of protocol data format in transit i.e. using XMLbased (character-based encoding) and ASN.1 binary-based encoding (BER, PER), mostly known as binary-based encoding. Hence, in the abstract syntax format, the specification of customer information will be given in XML and ASN.1 as well Customer Information: XML-based The message framework of customer information, that is needed to define the abstract syntax format, has been defined in Section 4.3 (see Figure 24 and Table 6). Thus, the task of application developer is then expressing such message framework in XML Schema and XML Document. There are many available tools that can be used to design an XML Document and XML Schema specification. One of the useful tools is XML Spy from Altova 11. This is very convenient tool and user friendly. This tool provides automatic generation of XML Schema specification from the XML Document, and vice versa. This tool also provides the capability to design the XML Schema by means of diagram notation: XML Schema Diagram. The XML Schema Diagram represents the hierarchical structure data format as well as message object diagram. Hence, the application designer can start translating message object diagram (with description table) into XML Schema Diagram. The benefit of defining XML Schema trough XML Schema Diagram is that XML Schema specification can conveniently be modified by means of graphical interface instead of text-based editor. Figure 31 depicts the XML Schema Diagram of Customer information. 11

46 Chapter 4 Design Methods 46 Legend Element Element Optional Element Element contains sequence of elements Sequence Choice Figure 31 XML Schema Diagram of Customer The tool provides direct translation to obtain the XML Schema specification from the XML Schema Diagram. The translated XML Schema specification is the same with the XML Schema specification depicted in Specification 2 (see previous section). XML Spy tool also facilitates to generate the XML Document from XML Schema specification. The Specification 3 shows the XML Document of customer information. The length of this XML Document is 579 bytes Specification 3 Customer.xml <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v5 rel. 4 U ( by Bayu <Customer xmlns:xsi=" xsi:nonamespaceschemalocation="..\xml\customer.xsd"> <Name> <FirstName>Bayu</FirstName> <LastName>Erfianto</LastName> </Name> <Address> <Street>Hengelose Straat </Street> <City>Enschede</City> <Zip>7514AK</Zip> <Phone> </Phone> </Address> <AccountNo>ABN </AccountNo> <Gender>Male</Gender> <Age>25</Age> </Customer> Customer Information: ASN.1 binary-encoded based Our design methods provide two options to obtain ASN.1 specification i.e. by means of automatic mapping and manual mapping from XML Schema specification. This subsection discusses the ASN.1 specification obtained from manual mapping. However, the scheme or rules of automatic mapping from XML Schema to ASN.1 specification will clearly be discussed later in the Section 4.6.

47 Chapter 4 Design Methods 47 The Specification 4 shows the customer information specified in ASN.1 format. Such ASN.1 specification is manually defined by conforming to the XML Schema in Specification 2. The way of such manual mapping also conforms to the standard [34]. The further description of mapping from XML Schema to ASN.1 definition can be seen in Section 4.5 By applying some X.694 rules [35], the corresponding ASN.1 specification of customer information can then be obtained, as shown in Specification 4 bellow Specification 4 Customer.asn Customer DEFINITIONS ::= BEGIN CustomerRecord ::= SEQUENCE { name Name, address Address, account Account, gender Gender, age Age} Name ::= SEQUENCE {firstname FirstName, lastname LastName} Address ::= SEQUENCE {street Street, city City, zip Zip, phone Phone} FirstName ::= VisibleString LastName ::= VisibleString Street ::= VisibleString City ::= VisibleString Phone ::= VisibleString Zip ::= VisibleString Gender ::= VisibleString Account ::= VisibleString Age ::= INTEGER(1..150) END The ASN.1 specification described in Specification 4 is the outcome of Abstract Syntax Specification design method. In the Compile-time design method, an ASN.1 compiler will take the ASN.1 Specification 4 as an input. In this thesis, the tool used to compile the ASN.1 specification is ASN1C which is provided by Objective System 12. This tool is used to generate data structure and encoding/decoding functions in Java (also available in C) with BER (PER is also available) as encoding rule. Figure 32 shows the process of compilation of ASN.1 source to generate data structure and encoding/decoding methods in Java. Figure 32 ASN.1 Compilation process using ASN1C 12

48 Chapter 4 Design Methods 48 To compile all such java files, it needs ASN.1 encoding/decoding a run-time library provided by ASN1C tool. Hence, the generated java class will contain the encoding/decoding methods and data types (see Figure 33). The ASN1C run-time library that defines ASN.1 encoding/decoding method (BER) is required during execution process. Application behavior run-time (in Java as well) class is also required to which the values that want to be encoded are input during the execution process (see Figure 33). Compilation-time Run-time Values to be encoded Application Behavior Run Time Generated Java Files Java Compiler Generated Java Class Execution ASN.1 binary-based encoded data format (BER) ASN1C run time library (BER) Figure 33 Generating the ASN.1 binary-encoded (BER) data format using ASN1C Java Version The execution process directly results ASN.1 BER binary-encoded data format. This data format is stored in a file customer.ber, the content of this file can be seen in Figure 34. The length of this ASN.1 BER binary-encoded data format is 106 bytes, more compact than the XML Document which is 579 bytes. Figure 34 Content of Customer.bert viewed by Objective System ASN.1 Viewer 4.6 XML Schema and ASN.1 Cooperation The joint committee of the ISO/IEC and ITU-T has produced a draft standard that specifies ITU-T Rec. X.693 ISO/IEC Mapping ASN.1 into W3C XML Schema Definitions. The join committee also produces a new recommendation ITU-T Rec. X.694 ISO/IEC Mapping W3C XML Schema Definitions into ASN.1 (still in progress).

49 Chapter 4 Design Methods Mapping XML Schema to ASN.1 A new standard ITU-T Rec. X.694 provides a mapping from XML Schema to ASN.1. This mapping process takes an XML Schema specification as an input and produces an ASN.1 specification. The mapped ASN.1 specification will contains a set of type definitions (and, optionally, an XER encoding instruction section), in such a way that there is a one-to-one correspondence between ASN.1 abstract values and valid XML instances. As a result of this mapping, the ASN.1 binary encoding rules (BER or PER) can be implemented. BER, provides a compact binary format, while PER provides more compact binary format with fine compression rates. Decoding a binary format like BER or PER is more efficient than processing (parsing) XML (Schema and Document) and this can increase the performance of a system. Another benefit is data length: It is stated in [34] that a binary encoding may save up to 80% or even more relative to corresponding XML text. Those two benefits enable the XML to be used by a device which works with low bandwidth (or even with fluctuated bandwidth). Moreover, the details description of ITU-T Rec. X.694 or mapping from XML Schema to ASN.1 has been published to public but still in force 13. However, French Telecom 14 implements X.694 standard in a tool (prototype): XML Schema to ASN.1 Translator. Some example of mapping from XML Schema to ASN.1 using X.694 rules will be presented here. However, more complete mapping rules can be seen in [35]. Mapping Simple Type Integer: XML Schema: corresponding ASN.1: <xsd:simpletype name="typename"> <xsd:restriction base="xsd:integer"/> </xsd:simpletype TypeName ::= INTEGER Mapping Simple Type Float : XML Schema: <xsd:simpletype name="typename"> <xsd:restriction base="xsd:float"/> </xsd:simpletype> corresponding ASN.1: TypeName ::= INTEGER Mapping Simple Type String: XML Schema: corresponding ASN.1 <xsd:simpletype name="typename"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> TypeName ::= VisibleString There are several ASN.1 String data type that can be used, see [36]

50 Chapter 4 Design Methods 50 Mapping Enumeration data type: XML Schema: corresponding ASN.1 <xsd:simpletype name="state"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="off"/> <xsd:enumeration value="on"/> </xsd:restriction> </xsd:simpletype> State ::= ENUMERATED {off, on} Meanwhile, the Complex Type in XML Schema definition is converted into SEQUENCE in ASN.1 as follow: Mapping complex Type : XML Schema: corresponding ASN.1 <xsd:complextype name="typename"> <xsd:sequence> <xsd:element name="element1- name" type="element1-type"/> <xsd:element name="element2- name" type="element2-name"/> </xsd:sequence> </xsd:complextype> TypeName ::= SEQUENCE { element1-name element1-type, element2-name element2-type } X.694 standard also defines XSD (XML Schema Definition) built-in data type. However, this XSD built-in data type is optional to be used in an ASN.1 specification (XSD builtin data type can be defined inside the ASN.1 module or externally). A use of an XSD built-in data type should be mapped to an ASN.1 type definition in accordance with the following lines (the complete XSD built-in data type can be seen in [35]). XSD built-in data type ASN.1 data type definition base64binary OCTET STRING Boolean BOOLEAN Byte INTEGER ( ) Date XSD.date Decimal XSD.Decimal Duration XSD.Duration Float XSD.Float For example, the XSD.Float in ASN.1 data type definition has corresponding XSD built-in data type as follows: XSD DEFINITIONS::= BEGIN Float ::= REAL (WITH COMPONENTS { mantissa( ), base(2), exponent( )}) END

51 Chapter 4 Design Methods 51 This thesis will employ XML Schema to ASN.1 Translator tool to translate XML Schema specification into ASN.1 specification. This tool generates separately XSD built-in data type from the ASN.1 specification. Figure 35 XML Schema to ASN.1 Translator from French Telecom The following lines show the example of result using automatic mapping from XML Schema specification into ASN.1. The XML Schema specification to be mapped is taken from the Specification 2 (Customer.xsd). The translated ASN.1 module is Customer.asn which contains specification of customer identification, and the XSD built-in data type module is XSD.asn Specification 5 Customer.asn Customer DEFINITIONS ::= BEGIN IMPORTS String FROM XSD; Customer ::= SEQUENCE { name Name, address Address, accountno XSD.String, gender XSD.String, age INTEGER} Address ::= SEQUENCE { street XSD.String, city XSD.String, zip XSD.String, phone XSD.String} Name ::= SEQUENCE {firstname XSD.String, lastname XSD.String} END XSD DEFINITIONS ::= BEGIN Specification 6 XSD.asn

52 Chapter 4 Design Methods XMLCompatibleString ::= UTF8String (FROM ({0, 0, 0, 9} {0, 0, 0, 10} {0, 0, 0, 13} {0, 0, 0, 32}..{0, 0, 215, 255} {0, 0, 224, 0}..{0, 0, 255, 253} {0, 1, 0, 0}..{0, 16, 255, 253})) String ::= XMLCompatibleString END Comparing to the manually-defined ASN.1 specification, the generated modules (ASN.1 specification and XSD built-in data type) have much more complicated structure. The more complicated ASN.1 structure is the more difficult to implement the application run-time as well. Another issue also appears: the ability of the ASN.1 compiler to support the XSD built-in data type (the ASN.1 compiler needs XER parser to process XSD built-in data type). Hence, the application developer must also check this issue. However, the automatic mapping will help the application designer to work faster on the design of ASN.1 specification, especially if the XML Schema that is going to be mapped has more complicated structure as well. To avoid the complexity in the designing the application behavior run-time and to avoid the unsupported of XSD builtin data type, the application designer can remove the XSD built-in data type definition in ASN.1 module and change with the own ASN.1 data type definition Mapping ASN.1 to XML Schema This subsection presents such a mapping from ASN.1 specification to XML Schema. It uses as standard ITU-T Recommendation X.693 XML Encoding Rule (XER). There is more than one set of encoding rules that can be applied to values of ASN.1 types [37]. X.694 standard defines two encoding rules, and both produce an XML document conforms to W3C XML. The first encoding rule is called the Basic XML Encoding Rules. The second is called the Canonical XML Encoding Rules [used for secured message, see [37]]. This thesis will use Basic XER. Some example of mapping from ASN.1 to XML Schema using X.693 rules will be presented here. However, more complete mapping rules are defined in [37]. Each ASN.1 data type is mapped to a corresponding XML Schema data type. Mapping INTEGER : ASN.1 syntax corresponding XML Schema syntax TypeName ::= INTEGER <xsd:simpletype name="typename"> <xsd:restriction base="xsd:integer"/> </xsd:simpletype> Mapping OCTET STRING : ASN.1 syntax corresponding XML Schema syntax TypeName ::= OCTET STRING <xsd:simpletype name="typename"> <xsd:restriction base="xsd:hexbinary"/>

53 Chapter 4 Design Methods 53 </xsd:simpletype > Mapping REAL : ASN.1 syntax corresponding XML Schema syntax TypeName ::= REAL <xsd:simpletype name="typename"> <xsd:restriction base="xsd:double"/> </xsd:simpletype> Mapping REAL : ASN.1 syntax TypeName ::= SEQUENCE { element1-name element1-type, element2-name element2-type, } corresponding XML Schema syntax <xsd:complextype name="typename"> <xsd:sequence> <xsd:element name="element1-name" type="element1-type"/> <xsd:element name="element2-name" type="element2-name"/> </xsd:sequence> </xsd:complextype> In this thesis, the tool that is used to map from ASN.1 to XML Schema is asn2xsd version 0.3 B. This tool is provided freely by Objective Systems 16 and can be downloaded at that web site. For instance, the Customer.asn (including the XSD.asn) module in the Specification 5 and 6 is going to be converted back to XML Schema. The process of mapping from ASN.1 specification to XML Schema by using asn2xsd tool is shown in Figure 37. Figure 36 asn2xsd command Tool As the result, the following lines show the generated XML Schema specification Specification 7 Converted Customer.XSD from ASN.1 to XML Schema <?xml version="1.0"?> <!-- This file was generated by the Objective Systems ASN2XSD (Version: 0.3B, Date: 01-Jul > <xsd:schema xmlns:xsd=" elementformdefault="qualified"> <xsd:element name="customer" type="customer"/> <xsd:complextype name="customer"> <xsd:sequence> <xsd:element name="name" type="name"/> <xsd:element name="address" type="address"/> <xsd:element name="accountno" type="xsd:string"/> 16

54 Chapter 4 Design Methods <xsd:element name="gender" type="xsd:string"/> <xsd:element name="age" type="xsd:integer"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="name"> <xsd:sequence> <xsd:element name="firstname" type="xsd:string"/> <xsd:element name="lastname" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="address"> <xsd:sequence> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="zip" type="xsd:string"/> <xsd:element name="phone" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:schema> The Specification 7 defines customer as a root of XML Schema with the data type as complex type element (type="customer", line 6, Specification 7), while in Specification 2 the root customer is defined as element (xs:element name="customer"). However, this difference does not affect to the structure of XML Schema specification and this Specification 7 still can be used to validate the XML Document in Specification 3.

55 Chapter 5 Patient Medical Record Specification 55 Chapter 5 Chapter 5 Patient Medical Record Specification This chapter applies the design methods described in the previous chapter to construct a specific protocol data format i.e. for electronic health record. Section 5.1 discusses the requirements that are needed to construct electronic health record for our purpose. Section 5.2 discusses the specification of Patient Demographic Record. Section 5.3 discusses the specification of ECG Record, including ECG Lead. Section 5.4 discusses Blood Pressure specification. 5.1 Design Requirements The common term of electronic health record is placed by Patient Medical Record (PMR) term in this thesis. For our purpose, the PMR is decomposed into two parts i.e. the patient demographics record part, which contains the general patient identification data, and the vital signs record part. The structure of the record part are adopted from the available standards and application e.g. ecgml Application and CEN/TC 251-SCP, combined and tuned to meet our purpose. This section discusses the application of design methods described in Chapter 4 to construct specific protocol data format i.e. for Patient Medical Record purpose. The applied design methods are as follows: Design-time method; the outcome of design-time methods is abstract syntax specification of Patient Medical Record. During the design-time, the design criteria of constructing Patient Medical Record have been taken into account as follows: Reuse the applicable concept, nomenclature and other parameters that have been investigated from the available standard e.g. CEN/TC251 or ecgml application Patient Demographic Record; gives particular information about demographic identity of a patient and also the brief information about medical history (medical assessment) of a patient such as current diagnosis and needed treatment Vital Signs Record may address non continuous time data and continuous-time data obtained from several sensors Vital Signs Record must support several leads of measurement e.g. lead in ECG or EMG Must be open to include externally defined format of a vital sign record If the application developer prefers having more compact transfer syntax, the application developer may choose ASN.1 to address the system point of view (option no 2 in Figure 21). However, the application developer may also use the XML-based protocol data format to exchange Patient Medical Record between

56 Chapter 5 Patient Medical Record Specification 56 application entities. Compilation-time; if the ASN.1 is chosen to exchange Patient Medical Record between application entities, the ASN.1 encoding rule has to be defined during this compile-time method. This thesis employs ASN.1 BER as encoding rule. The outcome of compilation-time method is encoding/decoding run-time. Run-time; the run time method is intended to produce the ASN.1 binary-encoded data format. The application developer must also make application behavior runtime that is used to input the Patient Medical Record values. The execution process (see Figure 21) is then performed here by involving application behavior run-time, encoding/decoding run-time, and ASN.1 encoding library. The execution process takes the values to be exchanged as input, and the outcome of the execution process is ASN.1 binary-encoded protocol data format. This ASN.1 binary-encoded protocol data format is ready to be used by transfer syntax. 5.2 Patient Demographic Record Specification Patient Demographic Record will carry patient identity and its demographic data. This information usually remains constant during the measurement or monitoring activity. The information is in text and viewed by humans rather than processed by computer. Generally, the demographic data may consists of [3]: Patient Identification Data; gives particular information about the patient such as Name, Address and other information which describe the demographical identity of a patient [13]. Clinical Protocol/Assessment Data ; gives the brief information about medical history of a patient such as current diagnosis and needed treatment This thesis addresses a patient demographic record which includes both patient identification data and clinical assessment data. The information contained in patient demographic record is classified in several elements. The Name element contains information about general patient identity. Address element contains information about patients address. Sex and DoB element is used to identify the gender and date of birth of a patient. Our solution also includes Insurance element which describes the patient insurance identification. The last element is Clinical Protocol which describes the patient medical or clinical history [3]. Because Name, Address and Clinical Protocol element has its sub elements, therefore the data type for those elements are defined as complex type record. Our solution of message object diagram of Patient Demographic Record can be seen in the Figure 37.

57 Chapter 5 Patient Medical Record Specification 57 Figure 37 Message Object Diagram of Patient Demographic Record The description, optionality, and data type of each element in message object diagram are clearly described in Table 8. Table 7 Patient Demographic Record Definition Element Description Required Data Type FirstName Patient s First Name Required String LastName Patient s Last Name Required String Street City Postcode Country Describes complete patient s address Required Required Required Required String String String 17 String Patient s address Optional String Phone Patient phone number Optional String Sex Male or Female Optional String 18 DoB Date of birth Optional String 19 Insurance Type of Insurance Required String Weight Weight of patient Optional Integer Height Weight of patient Optional Float 17 String data type is used for simplicity 18 idem 19 idem

58 Chapter 5 Patient Medical Record Specification 58 Diabetes Status of Patient either has Diabetes or Optional String not Hypertension Status of Patient either has Optional String Hypertension or not Medication Describes whether the patient has Optional String special treatment/medication Other Describes other clinical protocol Optional String XML-based Patient Demographic Record The message object diagram in Figure 43 is similar to XML Schema Diagram which also represents a hierarchical message structure. The application developer can start translating the message object diagram into XML Schema Diagram. The XML Schema Diagram of our Patient Demographic Record is depicted in Figure 39. Afterwards, by using XMLSpy, such XML Schema Diagram can be directly converted into XML Schema specification. Figure 38 XML Schema Diagram of Patient Demographic Record in The XML Schema specification starts with PatientDemographicRecord as root element. Element Name in line 9 of Specification 8 is defined as a complex type Name. The contents of complex type Name is defined in line The following lines are the solution of abstract syntax of Patient Demographic Record in XML Schema.

59 Chapter 5 Patient Medical Record Specification Specification 8 PatientDemographic.XSD <!-- edited with XMLSPY v5 rel. 4 U ( by Bayu Erfianto (STTT) --> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="patientdemographicrecord"> <xs:complextype> <xs:sequence> <xs:element name="patientid" type="xs:string"/> <xs:element name="name" type="name"/> <xs:element name="address" type="address"/> <xs:element name="gender" type="xs:string"/> <xs:element name="dob" type="xs:string"/> <xs:element name="insurance" type="xs:string"/> <xs:element name="clinicalprotocol" type="clinicalprotocol"/> </xs:sequence> </xs:complextype> </xs:element> <xs:complextype name="name"> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> </xs:complextype> <xs:complextype name="address"> <xs:sequence> <xs:element name="street" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="postcode" type="xs:string"/> <xs:element name="country" type="xs:string"/> <xs:element name="phone" type="xs:string"/> <xs:element name=" " type="xs:string"/> </xs:sequence> </xs:complextype> <xs:complextype name="clinicalprotocol"> <xs:sequence> <xs:element name="weight" type="xs:float"> <xs:annotation> <xs:documentation>unit in Kg</xs:documentation> </xs:annotation> </xs:element> <xs:element name="height" type="xs:float"> <xs:annotation> <xs:documentation>unit in cm</xs:documentation> </xs:annotation> </xs:element> <xs:element name="diabetes" type="xs:string"/> <xs:element name="hypertention" type="xs:string"/> <xs:element name="medication" type="xs:string"/> <xs:element name="otherclinicalprotocol" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:schema> XML Spy tool also facilitates to generate the XML Document from XML Schema specification. The Specification 9 shows the XML Document of Patient Demographic Data. The patient demographic values can then be filled in into this XML Document. Hence, this XML Document is ready to be exchanged by application entities Specification 9 PatientDemographic.XML <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v5 rel. 4 U ( by Bayu Erfianto (STTT) --> <!--Sample XML file generated by XMLSPY v5 rel. 4 U (

60 Chapter 5 Patient Medical Record Specification <PatientDemographicRecord xmlns:xsi=" xsi:nonamespaceschemalocation="..\xmlschema\patientdemographicrecord.xsd"> <PatientID>MHealth007</PatientID> <Name> <FirstName>Bayu</FirstName> <LastName>Erfianto</LastName> </Name> <Address> <Street>Hengelose Straat </Street> <City>Enschede</City> <PostCode>7514 AK</PostCode> <Country>The Netherlands</Country> <Phone> </Phone> < >[email protected]</ > </Address> <Sex>Male</Sex> <DoB>17 November 1980</DoB> <Insurance>IPS </Insurance> <ClinicalProtocol> <weight>60.5</weight> <height>160.5</height> <diabetes>no Data</diabetes> <hypertention>no Data</hypertention> <medication>vitamine A,B,C,D,E</medication> <otherclinicalprotocol>no Data</otherClinicalProtocol> </ClinicalProtocol> </PatientDemographicRecord> ASN.1-based Patient Demographic Record In case the application developer prefers using ASN.1-based to exchange the Patient Demographic data between application entities, the application developer can choose the second option, depicted in Figure 21. Our design methods define how to obtain the ASN.1 specification. This can be done manually or automatically converted from XML Schema using a tool. The easiest way is converting from XML Schema document automatically to ASN.1 using a tool. This has been described in the previous chapter. The ASN.1 specification of Patient Medical Record has been obtained by means of automatic mapping from XML Schema. However, to avoid the more difficult to implement application run-time, the ASN.1 XSD built-in data type has been removed from the ASN.1 specification. Specification 10 shows the ASN.1 specification of Patient Demographic Record Specification 10 PatientDemographic.asn PDD DEFINITIONS ::= BEGIN PatientDemographic ::= SEQUENCE { patientid name PatientID, Name, address Address, gender age Gender, Age, insurance Insurance, clinicalprotocol ClinicalProtocol} Name ::= SEQUENCE {firstname FirstName, lastname LastName} Address ::= SEQUENCE { street Street,

61 Chapter 5 Patient Medical Record Specification city City, zip Zip, country Country, phone Phone, } ClinicalProtocol ::= SEQUENCE { weight Weight, height Height, hypertention Hypertention, diabete Diabete, medication Medication, other Other} PatientID ::= VisibleString FirstName ::= VisibleString LastName ::= VisibleString Street ::= VisibleString City ::= VisibleString Phone ::= VisibleString Zip ::= VisibleString Country ::= VisibleString Phone ::= VisibleString := VisibleString Gender ::= VisibleString Insurance ::= VisibleString Age ::= INTEGER(1..150) Weight ::= REAL(1..300) Height ::= REAL(1..300) Hypertention ::= VisibleString Diabete ::= VisibleString Medication ::= VisibleString Other ::= VisibleString END Furthermore, by referring to the design methods, the compilation of ASN.1 file must be performed in the compilation-time method. The tool used to compile the ASN.1 specification is the same with the tool used in the example in Chapter 4. For simplicity, Basic Encoding Rules has been chosen with Java as the target language. The ASN.1 compilation process results encoding/decoding and data type methods. These methods are then compiled Java compiler (Java SDK 1.4) to obtain the encoding/decoding runtime. Thus, to generate the binary-encoded BER data format, this is performed in run-time method. In this method, there are some activities that have to be done before as follows: Application developer has to build an application behavior that is used to input the patient demographic values, and compiles this application behavior (using Java compiler) to obtain the application behavior run-time. There is also an alternative way, the application developer makes use of the application behavior that can read the XML Document and extracts the patient demographic values from such XML Document. These values are then to be an input for execution process. In the run-time method, all run-time (encoding/decoding run-time, application behavior run-time, and encoding/decoding library) have to be executed together. The execution process will generate the ASN.1 binary-encoded protocol data format of Patient Demographic Record using BER. The result of the execution is presented in Section 6.3.1

62 Chapter 5 Patient Medical Record Specification ECG Record Specification To compose vital signs record protocol data format, the design criteria have been taken into account as follows: Reuse the applicable concept, nomenclature and other parameters that have been investigated from the available standard e.g. CEN/TC251 or ecgml application Vital Signs Record may address non continuous time data and continuous-time data obtained from several channels Vital Signs Record must support several leads of measurement e.g. lead in ECG or EMG Must be open to include externally defined format of vital sign record Generally, there are two approaches of representing ECG data. First approach, known as annotation, is based on the physiological interval of wave division, and the second approach is by using the sampled data. The definition of each element in this ECG Record is inspired by the standard description format CENT/TC-251 SCP and ecgml application. To compose ECG Record for our purpose, the design criteria have been taken into account as follows. The Vital Sign identified is used to distinguish ECG Record among others An element is provided to addresses the multiple lead data in case there are many leads used during the measurement. However, the leads data are already multiplexed before they are filled in into the lead data element. The further explanation of lead data element will be given in the next sub section In case the user wants to exchange only Computed ECG data, there should be an element in ECG Record that is provided to address this purpose. An element is provided to address the physiological interval of wave division, or known as ECG annotation. Must be open to include externally defined format of ECG data format. By applying our design methods, the specification of ECG Record can be started from the definition of message object diagram. The solution of message object diagram of ECG Record can be seen in the Figure 39.

63 Chapter 5 Patient Medical Record Specification 63 Figure 39 Message Object Diagram of ECG Record The description, optionality, and data type of each element in message object diagram are clearly described in Table 8. Table 8 ECG Record Definition Element / Attribute Description Required Data Type VitalSignID Describes the ECG Device ID Required String RecordingDate Describes the recording date of Required Date ECG Record RecordingTime Describes the recording time of Required Time ECG Record MultilexedLeadData Contains data from the Required Complex multiplexed leads ComputedECGData Contains data from the computed ECG Optional Type Complex Type

64 Chapter 5 Patient Medical Record Specification 64 External Format Contains the attachment of external format of ECG Record (in case needed) LeadSamplingRate Describes the sampling rate used in each lead CompSamplingRate Describes the sampling rate used in Computed ECG data LeadData Contains the sequence of lead data Annotation Contains annotation points of an ECG waveform Optional Required Optional Required Required Octet String Integer Integer Octet String Complex type LeadData element in MultiplexedLead complex type consists of the sequence of multiplexed lead data. The multiplexing is necessary to be performed to avoid of having one long lead data to be filled into LeadData element. One of the benefits of having multiplexed lead is when the network has high loss rate; the application process at the receiving site will only lose some small parts of ECG / lead data. Because the LeadData element contains sequence of multiplexed of lead data, it is necessary to refine this LeadData into a record. Having a refined LeadData will ease the application process to de-multiplex the lead data later. The complete ECGRecord specification will be given in Section Meanwhile, the following lines will discuss the refinement of LeadData element Lead Record Specification This LeadData element is refined into a record refer to the previous discussion. By reusing the same design methods, the definition of LeadData record can be started from the definition of message object diagram. The solution of message object diagram of Lead Record can be seen in the Figure 40. To compose Lead Data Record for our purpose, the design criteria have been taken into account as follows. The Vital Sign identified is used to distinguish ECG Record among others There should be an element which describes when the ECG data has been recorded Device identification is required. This will address the use of attributes such as Device Name and Channel. It may also contain manufacturer specific information. There should be a mechanism to synchronize one vital sign waveform with another wave. To do so, the Sync Point element has been introduced in the waveform definition. The ECG lead number is defined based on CENT/TC-251 SCP document [8]. CENT/TC-251 describes ECG leads by numbering the index starting from 0 to 255. Table 9 describes the ECG lead number based on SCP code. Table 9 List of standardized ECG lead number descriptors based on CENT/TC-251 Lead Lead Number Unspecified lead 0 I 1 II 2 V1 3 V2 4 V3 5 V4 6 V5 7 V6 8

65 Chapter 5 Patient Medical Record Specification 65 Lead Lead Number V7 9 V2R 10 V3R 11 V4R 12 V5R 13 V6R 14 V7R 15 X 16 Y 17 Z 18 CC5 19 CM5 20 Left Arm 21 Right Arm 22 Left Leg 23 I 24 E 25 C 26 A 27 M 28 F 29 H 30 III 61 avr 62 avl 63 avf 64 -avr 65 Reserved for future expansion Application specific The root of message object diagram is named as Lead. The first element is reserved for LeadID which is used to identify the waveform data belongs to which lead. DeviceID element is defined as complex type. This element is used to identify the device used to capture the lead data. Waveform element is also defined as complex type. This complex type element will contains several simple type elements which are used to specify the ECG lead data i.e. x values, y values and annotation point values. Figure 40 Message Object Diagram of Lead Record The description, optionality, and data type of each element in message object diagram are clearly described in Table 10. Table 10 LeadData Record Definition Element / Attribute Description Required Data Type LeadID Describe ECG Lead Definition Required Integer Channel Describes the channel used by ECG Required String Device SensorID Describes the ECG Device ID Required String DeviceName Describes the ECG Device Name Required String

66 Chapter 5 Patient Medical Record Specification 66 SyncPoint XValue YValue AnnotationPoint Describes the time unit needed to synchronize the ECG wave with another waves Contains sequence of x axis (time domain) values sampled data Contains sequence of y values (voltage domain) sampled data Contains sequence of annotation point Required Required Required Required Integer Sequence of Real Sequence of Real Sequence of Integer XML-Based Lead Record Specification The message object diagram in Figure 40 is closer to XML Schema Diagram that also represents a message in hierarchical structure. The designer can start translating the message object diagram into XML Schema diagram. Afterwards, by using XMLSpy, the XML Schema specification of Lead Data Record can be automatically generated from the XML Schema diagram. Figure 41 shows XML Schema Diagram of Lead Data Record. Figure 41 XML Schema Diagram of Lead Record The XML Schema specification starts with Lead as root element. This root element contains a complex type element where the ECG lead data is defined. The contents of complex type Waveform is defined is defined in line Element XValue, YValue, and Annotation Point are composed of sequence of x values, y values, and annotation point values, respectively Specification 10 LeadData.XSD <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v5 rel. 4 U ( by Bayu Erfianto (STTT) --> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="lead"> <xs:complextype> <xs:sequence> <xs:element name="leadid" type="xs:integer"/> <xs:element name="deviceid" type="device"/> <xs:element name="waveform" type="waveform"/> </xs:sequence>

67 Chapter 5 Patient Medical Record Specification </xs:complextype> </xs:element> <xs:complextype name="device"> <xs:sequence> <xs:element name="channel" type="xs:string"/> <xs:element name="sensorid"/> <xs:element name="devicename" type="xs:string"/> </xs:sequence> </xs:complextype> <xs:complextype name="waveform"> <xs:sequence> <xs:element name="syncpoint" type="xs:string"/> <xs:element name="data"> <xs:complextype> <xs:sequence> <xs:element name="xvalues"> <xs:annotation> <xs:documentation>unit in Time(ms)</xs:documentation> </xs:annotation> </xs:element> <xs:element name="yvalues"> <xs:annotation> <xs:documentation>unit in Volt (mv)</xs:documentation> </xs:annotation> </xs:element> <xs:element name="annotationpoints"> <xs:annotation> <xs:documentation>reference Point for PQRST wave annotation</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:schema> The values of Lead Record to be exchanged are defined in XML Document depicted in Specification 11. This XML document has been validated using XML Schema in Specification 10. The size of this XML Document file is bytes Specification 11 Lead.xml <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v5 rel. 4 U ( by Bayu Erfianto (STTT) --> <!--Sample XML file generated by XMLSPY v5 rel. 4 U ( <LeadData xmlns:xsi=" xsi:nonamespaceschemalocation="..\xmlschema\leaddata.xsd"> <LeadID>1</LeadID> <DeviceID> <Channel>CH01</Channel> <SensorID>S01</SensorID> <DeviceName>TMSI Sensor Device</DeviceName> </DeviceID> <WaveForm> <SyncPoint>100</SyncPoint> <SampledData> <XValues>xvalue.dat</XValues>

68 Chapter 5 Patient Medical Record Specification <YValues>yvalue.dat</YValues> <AnnotationPoints>annotation.dat</AnnotationPoints> </SampledData> </WaveForm> </LeadData> ASN.1-based Lead Record Specification The same design methods are used to define the specification of Lead Data Record in ASN.1. The following lines show the Lead Record specification in ASN Lead DEFINITIONS ::= BEGIN LeadRecord ::= SEQUENCE { leadid LeadID, deviceid DeviceID, waveform WaveForm} DeviceID ::= SEQUENCE { channel Channel, sensorid SensorID, devicename DeviceName} Specification 12 Lead.asn WaveForm ::= SEQUENCE {syncpoint SyncPoint, sampleddata SampledData} SampledData ::= SEQUENCE { xvalues XValues, yvalues YValues, annotationpoints AnnotationPoints} LeadID ::= INTEGER Channel ::= VisibleString SensorID ::= VisibleString DeviceName ::= VisibleString SyncPoint ::= INTEGER XValues ::= SEQUENCE OF INTEGER YValues ::= SEQUENCE OF INTEGER AnnotationPoints ::= SEQUENCE OF INTEGER END The compilation of ASN.1 file has been performed and results some java files as the outcome. The application run time, to input the lead data and to encode using BER, has also been made in Java. Thus, to generate the binary-encoded BER file of lead record value, the run time application needs to be executed. The result of execution can be seen in Section Multiplexing Lead Data Having defined per lead specification, we come up an alternative idea to multiplex the entire existing leads in case there are more than one leads to be encoded. The motivation of multiplexing leads data is to avoid the channel occupation by a long stream of lead data; hence the other streams have to wait until the first one is completely transmitted. In case the multiplexing is required, first of all, each of lead data must be chunk into small elementary packet. The output of multiplexer is the long single stream which

69 Chapter 5 Patient Medical Record Specification 69 contains the multiplexed leads data. The Header field is defined to distinguish each elementary packet among others. This Header field is required when the application run-time needs to de-multiplex. Each of Header field contains: Stream ID; to distinguish between one elementary stream belongs to the same lead data, with the other Sequence; to inform the length of the each elementary packet. Figure 42 Multiplexing Lead data Furthermore, the long stream of multiplexed Lead data becomes an input of MultiplexedLeadData element in ECG Record (see Figure 41) XML and ASN.1-based ECG Record Specification The specification for ECG Record has been defined. This specification addresses ECG Record header, multiple ECG lead requirement, ECG annotation point, Computed ECG data, and External ECG format. The ECG Record header is used to identify record, recording time and recording date. The Computed ECG data is optional; it is reserved in case the physician needs to include the computed ECG data for comparison (or even for calibration) against the ECG lead data obtained from sensors. The annotation points describe the annotated ECG waveform. As we described in Chapter 2, the annotation point refers to the annotation invented by Einthoven, PQRST. The external format is reserved as optional, which is used to address the ECG external data format, in case required for assessment.

70 Chapter 5 Patient Medical Record Specification 70 The XML specification of ECG Record is depicted by the following XML Schema Diagram. Figure 43 XML Schema Diagram of ECG Record The binary-encoded file of ECG lead data has been defined in the previous section. Because this thesis will be making use the benefits of binary encoding to carry the lead data, hence the complete ECG Record is only specified in ASN.1. However, if the designer prefers using XML, the XML Schema and Document is still needed to be defined. The following lines show the specification of ECG Record in ASN.1. This syntax of ASN.1 notation is also defined manually and checked by parsing it into Asnp Specification 13 ECGRecord.asn ECG DEFINITIONS ::= BEGIN ECGRecord ::= SEQUENCE { vitalsignid VitalSignID, recorddate RecordDate, recordtime RecordTime, multiplexedlead MultiplexedLead, annotation Annotation, computedecg ComputedECG, externalformat ExternalFormat} ComputedECG ::= SEQUENCE { compsamplingrate CompSamplingRate, multiplexedcompecgdata MultiplexedCompECGData } DeviceID ::= SEQUENCE {channel Channel,

71 Chapter 5 Patient Medical Record Specification devicename DeviceName} MultiplexedLead ::= SEQUENCE { leadsampling LeadSampling, multiplexedleaddata MultiplexedLeadData} Annotation ::= SEQUENCE { p-wave P-Wave, p-r-interval PR-Interval, p-p-interval PP-Interval, q-peak Q-Peak, qrs QRS-Complex, q-t-interval QT-Interval, s-peak S-Peak, s-t-segment ST-Segment, t-wave T-Wave, u-wave U-Wave} P-Wave ::= SEQUENCE { p-onset P-Onset, p-peakvalue P-PeakValue, p-offset P-OffSet, p-comments P-Comments} QRS-Complex ::= SEQUENCE { qrs-onset QRS-Onset, qrs-peakvalue QRS-PeakValue, qrs-offset QRS-OffSet, qrs-comments QRS-Comments} T-Wave ::= SEQUENCE { t-onset T-Onset, t-peakvalue T-PeakValue, t-offset T-OffSet, t-comments T-Comments} U-Wave ::= SEQUENCE { u-onset U-Onset, u-peakvalue U-PeakValue, u-offset U-OffSet, u-comments U-Comments} ExternalFormat ::= SEQUENCE {type Type, contents Contents} VitalSignID ::= VisibleString RecordDate ::= VisibleString RecordTime ::= VisibleString LeadSampling ::= INTEGER NuliplexedLeadData ::= OCTET STRING SyncPoint ::= REAL Channel ::= VisibleString DeviceName ::= VisibleString CompSamplingRate ::= INTEGER MultiplexedCompECGData ::= OCTET STRING P-Onset ::= REAL P-PeakValue ::= REAL P-OffSet ::= REAL P-Comments ::= VisibleString QRS-Onset ::= REAL QRS-PeakValue ::= REAL QRS-OffSet ::= REAL QRS-Comments ::= VisibleString T-Onset ::= REAL T-PeakValue ::= REAL T-OffSet ::= REAL T-Comments ::= VisibleString U-Onset ::= REAL U-PeakValue ::= REAL U-OffSet ::= REAL

72 Chapter 5 Patient Medical Record Specification U-Comments ::= VisibleString PR-Interval ::= REAL PP-Interval ::= REAL Q-Peak ::= REAL S-Peak ::= REAL QT-Interval ::= REAL ST-Segment ::= REAL Type ::= VisibleString Contents ::= OCTET STRING END The data type of LeadData element in line 67 is defined as Octet String. This is because the lead data obtained in the previous section is already in binary-encoded BER. Hence, the data type of LeadData element in ECGRecord.asn is defined as Octet String. This lead data element may also contain sequence of binary-encoded data obtained from one lead or sequence of multiplexed binary-encoded data obtained from several leads. In case the binary-encoded data is obtained from several leads, then multiplexing of those binary-encoded is a must. This is done by the application run time and separately defined from the specification of ECGRecord.asn. 5.4 Blood Pressure Record Blood Pressure Record contains no time series data. Hence, in the Blood Pressure Record specification there is no element or leaf that specifies waveform data. The definition of each element in Blood Pressure Record is also inspired by ecgml application. However, in ecgml application this blood pressure is defined as a part of clinical protocol. To compose Blood Pressure Record for our purpose, the design criteria have been taken into account as follows. The Vital Sign identified is used to distinguish Blood Pressure Record among others There should be an element which describes when the Blood Pressure data has been recorded Device identification is required. This will address the use of attributes such as Device Name and Channel. It may also contain manufacturer specific information. The Blood Pressure values i.e. systole and diastole are defined in separate element. By reusing the same design methods, the specification of Blood Pressure Record can be started from the definition message object diagram. The solution of message object diagram of Blood Pressure Record can be seen in the Figure 44. Figure 44 Message Object Diagram of Blood Pressure Record

73 Chapter 5 Patient Medical Record Specification 73 The description, optionality, and data type of each element in Blood Pressure Record message object diagram are clearly described in Table 11. Table 11 Blood Pressure Record Definition Element / Attribute Description Required Data Type VitalSignID Contains the Vital Sign ID to Required String distinguish this Blood Pressure Record among others SensorID Describes BP Sensor ID Required String Channel Describes the channel used to captured Required the BP values (systole and diastole) DeviceName Describes the device name used to Required String captured the BP values RecordDate Describes BP recording date Required String RecordTime Describes BP recording time Required String Systole Systole value Required Integer Diastole Diastole value Required Integer XML-based Blood Pressure Record Specification The message object diagram in Figure 44 is similar to XML Schema Diagram that also represents a hierarchical structure of a message. The application developer can start translating the message object diagram into XML Schema diagram. Afterwards, by using XMLSpy, the XML Schema specification of Blood Pressure Record can be automatically generated from the XML Schema diagram. Figure 45 shows XML Schema Diagram of Blood Pressure Record. Figure 45 Specification of Blood Pressure Record in XML Schema Diagram The XML Schema specification starts with BPRecord as root element. This root element contains some simple type element and one complex type i.e. DeviceID. Definition of this complex type element is in line 11. The contents of complex type DeviceID are defined in line The following lines are the solution of abstract syntax of Blood Pressure Record specified in XML Schema Specification 14 BPRecord.XSD <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v5 rel. 4 U ( by Bayu Erfianto (STTT) --> <xs:schema xmlns:xs="

74 Chapter 5 Patient Medical Record Specification elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="bprecord"> <xs:complextype> <xs:sequence> <xs:element name="vitalsignid" type="xs:string"/> <xs:element name="deviceid" type="device"/> <xs:element name="recordingdate" type="xs:date"/> <xs:element name="recordingtime" type="xs:time"/> <xs:element name="systole" type="xs:integer"/> <xs:element name="diastole" type="xs:integer"/> </xs:sequence> </xs:complextype> </xs:element> <xs:complextype name="device"> <xs:sequence> <xs:element name="channel" type="xs:string"/> <xs:element name="sensorid" type="xs:string"/> <xs:element name="devicename" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:schema> The values to be exchanged over the network are defined in XML Document as depicted in Specification 15. This XML document has been validated using XML Schema in Specification 14. Hence, this XML Document is ready to be transferred via a communication network to carry the blood pressure data. The size of this XML Document file is 691 bytes Specification 15 BPRecord.XML <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v5 rel. 4 U ( by Bayu Erfianto (STTT) --> <!--Sample XML file generated by XMLSPY v5 rel. 4 U ( <BPRecord xmlns:xsi=" xsi:nonamespaceschemalocation="..\xmlschema\bprecord.xsd"> <VitalSignID>BPRecord</VitalSignID> <DeviceID> <Channel>CH03</Channel> <SensorID>SID04</SensorID> <DeviceName>TMSI-Blood Pressure Device</DeviceName> </DeviceID> <RecordingDate> </RecordingDate> <RecordingTime>14:20:00-05:00</RecordingTime> <Systole>120</Systole> <Diastole>70</Diastole> </BPRecord> ASN.1-based Blood Pressure Record Specification The same design methods are used to define the specification of ASN.1 as described in the previous section. The following specification shows the Blood Pressure Record specified in ASN Specification 16 BPRecord.asn BP DEFINITIONS AUTOMATIC TAGS ::= BEGIN

75 Chapter 5 Patient Medical Record Specification Root of BP Record BPRecord ::= SEQUENCE { vitalsignid VitalSignID, deviceid DeviceID, recorddate RecordDate, recordtime RecordTime, systole Systole, diastole Diastole} DeviceID ::= SEQUENCE { channel Channel, sensorid SensorID, devicename DeviceName} Channel ::= VisibleString SensorID ::= VisibleString DeviceName ::= VisibleString Priority ::= INTEGER(0..10) VitalSignID ::= VisibleString RecordDate ::= VisibleString RecordTime ::= VisibleString Systole ::= INTEGER(1..200) Diastole ::= INTEGER(1..200) END Furthermore, by referring to the design methods, the compilation of ASN.1 file must be performed. This compilation step will result some java files. The application run time, to input the blood pressure record data and to encode using BER, has also been made in Java. Then, to generate the binary-encoded (BER) protocol data format of Blood Pressure Record value, the run-time applications need to be executed. The analysis of this result will be given in Section 6.3.3

76 Chapter 5 Patient Medical Record Specification 76

77 Chapter 6 Demonstrator Implementation 77 Chapter 6 Chapter 6 Demonstrator Implementation This chapter discusses the demonstrator to validate the developed data format derived from the design methods. Section 6.1 discusses the architecture of demonstrator including encoder and decoder. Section 6.2 discuss presents the interface of demonstrator. Section 6.3 presents the analysis of data format resulted during the demonstration. 6.1 Architecture of Demonstrator Before going to discuss the architecture of demonstrator, the following lines describe the functionalities that can be expected from the demonstrator: The demonstrator will be a graphical interface which consists of two main applications i.e. Encoder and Decoder. In this demonstrator the records to be involved are Patient Demographic record, Blood Pressure record and ECG record. Patient Demographic data and Blood Pressure data represent the non continuous-time data, while the ECG record (including Lead record) represents the continuous-time data. For further application, the other vital sign records can be involved to contruct more complete electronic health record. During the demonstration, the following can be inspected: o The time needed to encode the vital sign and patient demographic data into ASN.1 BER binary-encoded data format is observed and displayed in the status message in the user interface. o The user interface also displays the size of BER data format. Therefore, the user can compare the BER binary-encoded data format to its XML document. o Each of BER data format is then stored in a file. The decoder application directly reads the BER data format files and decode them back to get the values of patient demographic and vital signs data. Figure 46 shows the demonstrator architecture of Encoder and Decoder. As depicted in that figure, the demonstrator consists of two parts i.e. Encoder Application and Decoder Application. The demonstrator is developed under Java, using Eclipse 3.0 environment with Jiglo 2.6 as GUI plug-in.

78 Chapter 6 Demonstrator Implementation 78 Figure 46 Encoder and Decoder Architecture The encoder architecture has three main functionalities, as follows: To generate the ECG waveform data. The specification of this synthetic ECG waveform generator is discussed in Appendix A. The generator will generate three files which represents x values, y values, and annotation points. Those files are then referred as file link in Xvalues, Yvalues, and AnnotationPoints element in lead.xml (see Specification 11 in Chapter 5) To extract the values of vital signs data from the XML documents and to encode them into ASN.1 BER binary-encoded data format. Since this thesis does not discuss the data acquisition, we assume that the blood pressure data is already acquired from the sensor, and stored in an XML document that contains the Blood Pressure record specification. For practical implementation, the application developer might design an application that can directly read the vital signs data from data acquisition system. To encode the vital signs and patient demographic values extracted from the XML document. This demonstrator employs ASN BER, hence the encoding process produces BER binary-encoded data format. The decoder architecture has two the functionalities: To decode ASN BER binary-encoded data format. The decoded values are then fed into XML API (XML Application Programming Interface) to be process later. The XML API will process the decoded values of patient demographic record and vital signs record, and write the values in XML document. Especially for lead data, the XML API will directly write the values of lead data in xvalues.dat, yvalues.dat, and annotation.dat files. Hence, XValues, YValues, and AnnotationPoints elements in Lead.xml document refer to those files [see line in Specification 11].

79 Chapter 6 Demonstrator Implementation 79 The refined architecture of ASN.1 Encoder and ASN.1 Decoder module are as follows: Figure 47 Refined ASN.1 Encoder and Decoder Module At encoder side, the Encoder module are refined to three packages, each of them functions to encode the ECG waveform data, blood pressure data, and patient demographic data, respectively. The Lead record encoder is defined as sub package of ECG record. This Lead record functions to provide the BER binary-encoded lead record data format that takes as input for ECG Record. In this demonstrator, ECG Record takes an input from ECG record header, Lead record, and ECG external data format that is ecgml.xml format. Like the Encoder module, the Decoder module is also refined to three packages, each of them functions to decode ECG waveform data, blood pressure data, and patient demographic data, respectively. The Decoder module takes input from ECGRecord.ber, BPRecord.ber, and PDD.ber, respectively. The decoded values are then fed into XML API module. This XML API module will then extracts the values and stores them in XML documents. 6.1 Encoder Architecture The encoder demonstrator consists of the following application program: Synthetic ECG Waveform Generator We involve this application program is to generate the ECG waveform. The ECG waveform is fed as Lead data which is stored in files distinguished by x value, y value and annotation points. Our demonstrator only employs one lead; hence there is only one file of x values, y values, and annotation values to be fed into Lead record. The discussion of this synthetic ECG Waveform Generator is given in Appendix C. This Synthetic ECG Waveform Generator is not created from scratch, but from previous work by McSharry, P.E at all [38]. XML API package Our design method, discussed in Chapter 4 and Chapter 5, distinguishes the user point of view which employs XML as data format and system point of view which employs ASN.1 binary encoded data format. To apply the distinguished design methods in our demonstrator, the XML API is required. This XML API is used to extract the vital signs and patient demographic data from the XML document. The vital signs data and patient demographic data are then fed into ASN.1 Encoder Module. The generation of ASN.1 binary encoded data format (using BER) is further done in the ASN.1 Encoder Module.

80 Chapter 6 Demonstrator Implementation 80 ASN.1 Encoder Module The ASN.1 Encoder Module consists of three packages i.e. Patient Demographic package, Blood Pressure package, and ECG Record package. As discussed in previous sub section, each package has the functionality to encode the values (extracted from XML document) to ASN.1 binary encoded data format using BER. In this demonstrator, we only involve one Lead record and one external format (ecgml application) to be encoded by ECG Record encoder package. However, for further requirement we can add new encoder module within this ECG Record package. The UML package diagram of encoder architecture can be seen in the Figure 48. This UML package diagrams can be used as high-level design or architecture to describe our demonstrator implementation structure. Because we use Java for the demonstrator implementation, hence a package in Figure 48 can be considered to Java package and dependencies between packages can be mapped to Java import statements. Figure 48 Encoder Architecture in UML package diagram As discussed in Chapter 4, our thesis employs ASN1C as ASN.1 compiler, altogether as encoder. The target language used by this ASN1C is Java. Hence, in Figure 48 we can see that the Encoder package has dependencies to ASN1C packages, which is Java package for ASN.1 encoding provided by Objective-System. For this thesis purpose, we use the evaluation version of ASN1C. 6.2 Decoder Architecture The decoder demonstrator consists of the following application program: ASN.1 Decoder Module The ASN.1 decoder module consists of three packages i.e. Patient Demographic package, Blood Pressure package, and ECG Record package. Each package has the functionality to decode the values in ASN.1 binary encoded data format. XML API Module This XML API is used to process the extracted vital signs and patient demographic data decoded from ASN.1 Decoder module from the XML document. This XML API module will store the data in XML documents. We also distinguish the lead data in x values, y values, and annotation values. In this implementation, we store all such lead data in three files i.e. xvalues.dat, yvalues.dat, and annotation.dat. Hence, in the

81 Chapter 6 Demonstrator Implementation 81 XML document, we just refer to the link of files, and do not need to include the lead data within the XML document. The UML package diagram of decoder architecture can be seen in the Figure 49. Figure 49 Encoder Architecture in UML package diagram Like in Encoder architecture, at decoder side we also employ ASN1C package that functions as to encode the ASN.1 binary-decoded data format. The ECGRecord, BPRecord, LeadRecord, and DemoGraphic package, respectively, will read the contents of BER file and feed the values to Decoder package. The Decoder package will call ASN1C package to decode back the values. 6.2 Interface As described in the previous section, the demonstrator consists of two parts i.e. Encoder that encode the vital signs and patient demographic data into ASN.1 binary-encoded data format and Decoder that decodes the ASN.1 binary-encoded data format and store the values in XML document. Therefore, the interface that we design in demonstrator must accommodate of such encoder and decoder functions. Encoder Interface In the encoder application, user runs program by means of graphical interface. The menu provided by this encoder interface is as follows: user can also see the value of patient s name, patient ID, user can also observe the value of numeric observation of a vital sign such as systole and diastole. User can view and modify the patient demographic data by means of graphical interface. encoder interface provides the user to modify and generate the ECG waveform that will be encoded into ASN.1 binary-encoded data format. However, in the practical implementation we do not need this synthetic ECG generator since the data of ECG waveform are directly obtained from lead sensors. The provided interface at encoder and decoder application can be seen in Figure 50,51, and 52 respectively.

82 Chapter 6 Demonstrator Implementation 82 Figure 50 Encoder Interface Figure 51 ECG Generator Interface Decoder Interface In the decoder application, user also runs program by means of graphical interface. The menu provided by this encoder interface is as follows: user can see the patient demographic data user can also observe the value of numeric observation of a vital sign such as systole and diastole. The decoder interface does not provide the graphical interface to plot the ECG waveform data. This can be considered for further implementation. Figure 52 Decoder Interface 6.3 Implementation Result and Analysis This section presents the implementation result and analysis of encoding the vital signs data and patient medical record. During the execution of encoder application program,

83 Chapter 6 Demonstrator Implementation 83 the user can generate the ASN.1 BER binary-encoded data format. The ASN.1 BER binary-encoded data format of vital signs record and patient demographic record are stored in file. Therefore, to view the contents of such BER file we can use the ASN.1 viewer tool Analysis of Patient Demographic Record The XML Document size to carry the patient demographic values has been defined in the Section The size of this XML Document is 1756 bytes. By running the encoder application, the ASN.1 BER binary-encoded data format will be produced. The binary-encoded data format is stored in demographic.ber. The size of binary-encoded protocol data format of Patient Demographic Record is 202 bytes. The observed average encoding time has also been measured i.e. 321 ms (on P III with 128 MB of Memory with Java SDK 1.4). Figure 53 Binary encoded of Patient Demographic Record value (using BER). The size of this binary-encoded BER file is 206 Bytes. This binary-encoded file is viewed by ASN.1 Viewer from Objective System The size of this binary-encoded data format of is almost 8 times smaller, that is 202 bytes, comparing to the XML Document. Hence, it can be concluded that the BER binary-encoded data is very efficient (in term of file size) to carry the patient demographic data Analysis of Lead Record and ECG REcord Analysis of Lead Record The XML Document size to carry the Lead data has been generated in the Section The XML Document (including the reference files that contain ECG lead data) size to carry the one lead data is bytes. This is because XML defines all values as an ASCII string. In character encoding like XML, 1 digit takes 1 byte. This will consume more bytes where lots of digits (integer or real) represented in ASCII string want to be encoded using character encoding.

84 Chapter 6 Demonstrator Implementation 84 There is a problem arose especially in the encoding of XValues and YVlues of lead data. In Table 12 those values represent real number. Because they consume more bytes, hence the selection of data type will affect to the size of binary-encoded BER file. There are two options i.e. defining the data type whether as SEQUENCE of REAL or SEQUENCE of INTEGER. If in the ASN.1 Specification XValues and YValues are defined as SEQUENCE OF REAL, the size of binary-encoded BER file of lead data is 293,807 bytes. The encoding time of such binary-encoded BER file has also been identified i.e ms (on UTIP 493 machine, PIII 128 MB memory with Java SDK 1.4.1_02). This takes more times because: Java compiler must perform the conversion from string (first of all, Java run time application reads the content of Xvalue, Yvalue and Annotation Value as string) to real. However in practice, the measurement with sensors can direclty obtains the real value. Hence, this eliminates the cost of conversion time. Encoding real value needs more computation times because the compiler must calculate the mantissa, base, and exponent of a real number. The size of ASN.1 BER encoded file is almost 2 times smaller than XML Document. The binary-encoded size does not reach 80% smaller like in the previous results. It is because of encoding the REAL value needs more bytes according to the precision of decimal digit. Another option, if samples are x,xxxxx (fixed decimal) is multiply them with a large number e.g. 1.E10, and consider the result as integer. During decoding, this integer value divides back by the large number to obtain the real value. The maximum ASCII length of a 64 bit integer value (in Java and Cit is represented as double) is 19 bytes (signed) or 20 (unsigned). The maximum binary-encoded BER length for a 64 bit integer encoding is 8 bytes (signed) or 9 (unsigned), and of course plus 2 for tag and length. However, these tag and length aren't included in the numbers for an ASCII value. The value 0 is encoded as a single 00 octet. Some examples of binary-encoded BER encoding are given in following table. Table 12 Encoding Integer value using BER Integer Value Binary BER Encoding T L Value (Required bytes) F B D EB D9 18 CA CD F A4 40 In ASCII, to represent an integer value, 1 digit takes 1 byte. Hence, integer requires 10 * 8 = 80 bits (or 10 bytes). Meanwhile, the BER encoding results fewer bits. To represent the number of *1.E10 by using binary encoding, the number of bits reserved to express this number is 2^40 (because 2^32 equals to *1.E10, hence to represent * 1E10 requires more 8 bits) or equal to 5 bytes.

85 Chapter 6 Demonstrator Implementation 85 Another example, to represent the value of *1E16 in ASCII, it requires 16 bytes. Meanwhile, to represent such number in binary encoding, the number of bits reserved to express this number is 2^56 or equals to 7 bytes (by using 2^56 bits, it can allocate the integer value up to If it uses 2^48, the integer value that can be allocated by this number of bits is up to *1E15). Hence, the number of bits required to express an integer value using binary encoding reduces with factor of 2 (or up to 3 times smaller than the ASCII encoding). According to the calculation above, the range of the number of bytes reserved to encode the SEQUENCE OF INTEGER can be calculated. Based-on calculation, the range is obtained from bytes to bytes. By using the run time application of BER encoding, the size of binary-encoded BER file is bytes, or 53% of the size of ASCII file. Hence, the use of binary encoding (to represent the integer value) can reduce the size of ASCII file by factor of to 2. Hence, the binary-encoded data is still efficient (in term of file size) to carry the ECG lead record data Figure 53 shows the Lead.ber which contains the binary-encoded BER of lead record values. This binary-encoded file is viewed using ASN.1 Viewer from Objective System. Figure 54 Piece of binary-encoded BER file of Lead Record Analysis of ECG Record The ECG lead data has been obtained from previous sub section. Thus, to generate the binary-encoded BER protocol data format, all run-time need to be executed. Figure 54 shows the piece of ECGRecord.ber. In this example, the binary-encoded file contains only 1 lead record and external file which is ecgml.xml. The size of binary-encoded file is bytes. Hence, this binary file is still efficient (in term of file size) to carry the complete ECG Record value comparing to the same values carried in XML document.

86 Chapter 6 Demonstrator Implementation 86 Figure 55 Piece of binary-encoded BER file of ECG Record Analysis of Blood Pressure Record The XML Document size to carry the blood pressure data has been specified in Section The size of this XML document is 601 bytes. Meanwhile, the size of binaryencoded (BER) data format is 74 bytes. The execution process is run on machine UTIP 493 (P III with 128 MB memory) with Java SDK 1.4.1_02. The average encoding time of such binary-encoded BER protocol data format has also been identified i.e. 541 ms. Figure 56 Binary encoded of Patient Demographic Record value (using BER). The size of this binary-encoded BER file is 206 Bytes. This binary-encoded file is viewed by ASN.1 Viewer from Objective System The size of this binary-encoded BER protocol data format is almost 8 times smaller than XML Document. Hence, it can be concluded that the binary-encoded protocol data format is very efficient (in term of data length) to carry the blood pressure record data.

87 Conclusion 87 Chapter 7 Conclusion This chapter summarizes the conclusions reached throughout the thesis. This chapter also gives ideas for future work. The structure of this chapter is the following: Section 7.1 presents the general conclusions; section 7.2 presents some possible future works. 7.1 General Conclusion In this thesis, the concept of representing physiological information such as vital signs data into a data format has been discussed. The vital sign data format is needed to construct an electronic health record, which also caries the patient demographic data. Several vital sign format standards such as CEN/TC-231 SCP, DICOM, and ecgml have been taken into account to construct an electronic health record for our purpose. There are two points that distinguish the background study needed to construct electronic health record data format for our purpose, as follows: Standard for electronic health data format This standard describes the data format used to carry the medical information. The known standards such as CEN/TC-251 Standard Communication Protocol and FDA standard have been taken into account. ecgml which complies with FDA standard also inspires us to construct vital signs data format for our purpose. Standard for electronic health messaging procedure This standard describes more details about messaging procedure to exchange the data format from one host to another host. DICOM standard clearly defines the messaging procedure to exchange medical information over the network. Besides that, DICOM standard also defines the standard for electronic health data format, however, more specifically for scanned image data. Hence, to construct the electronic health record data format, we also take into account the DICOM data format standard. However, to exchange our developed data format, we can consider the DICOM electronic health messaging procedure. The following results have been summarized in composing the vital signs record data format: The composed electronic health record, which is named as Patient Medical Record incorporates the patient demographic record and vital signs record. The composed electronic record has also incorporated continuous-time vital sign data such as ECG data and non-continuous-time data such as blood pressure data. In this prototype, the Patient Medical Record is only composed by Patient Demographic, ECG Record and Blood Pressure Record. For further work, we can incorporate more vital signs data

88 Conclusion 88 The Patient Demographic Record is composed by patient identification, or demographic data and assessment data. However, in our solution we only involve hypertension, diabetes, and medical history to address the assessment data. For further work, we can add more assessment data to give more detailed information on Patient Demographic Record. The ECG Record is composed by header, lead, computed ECG, annotation, and external format record. The header record describes the record identification, recording date, and recording time. The lead data is defined to address the data belongs to some lead. In this prototype, we only address one lead. For further application, some lead records can be added into the ECG Record. Because each lead can have long ECG waveform data, we propose to chunk and multiplex them. This can avoid burst error that cause losing of some bytes in one lead data in case the network is in unreliable. The computed ECG record is used to address in case the computed ECG data is needed. Hence, this computed ECG record is optional. The annotation element is used to address the annotation points of ECG records. The ECG annotation point itself can be obtained by calculating the peak and interval of PQRST wave. The external format record is used to address in case the external format of ECG record such as ecgml format is required. The health care practitioner use this ECG external format as the comparison to the ECG waveform obtained from leads. This external format is optional; hence we can leave it blank. The Blood Pressure Record is composed of record header and blood pressure data itself. Record header describes the record identification, recoding date, and recording time. The systole and diastole are present as blood pressure data. In this thesis, the design methods to construct data format by taking into account user point of view and system point of view has also been discussed. From the user point of view, the design methods considers user friendliness and easy to modify/debug the data format by using the available (free) tools. The XML data format has been chosen to address this user point of view. Meanwhile, from the system point of view the design methods consider the compactness (in term of size) of the data format. The ASN1 binary-encoded data format has been chosen to address this system point of view. The design methods are used to develop electronic health record data format for our purpose that incorporates vital signs record and patient demographic record. The demonstrator has been developed to validate the design methods and developed data format. The following results have been summarized in developing the demonstrator: The demonstrator consists of encoder and decoder parts. The encoder has main module i.e. XML API and ASN.1 Encoder module. The XML API module will extract the values of vital signs and patient demographic record, and feeds the values to ASN.1 Encoder module. The process of generating ASN.1 binary encoded data format is done in ASN.1 Encoder module. Since this thesis does not dealing with the data acquisition system, the encoder part employs a synthetic ECG generator waveform to generate ECG lead data. The architecture of demonstrator has taken into account the user point of view and system point of view. Hence, it conforms to our design methods. At decoder side, the ASN.1 Decoder module and XML API module have been made. The decoder module has the functionality to decode the ASN.1 BER binary-encoded files and feed the values into XML API module. The values of vital signs and patient demographic record are then stored in XML document for further use.

89 89 Our design methods results two types of data format. The first one is XML-based Patient Medical Record data format and the second one is ASN.1 binary-encoded-based data format. Comparing to the XML-based data format, we analyze that the Patient Medical Record using ASN.1 binary-encoded data format is more compact and efficient in term of data length. Hence, this data format is suitable to be used to exchange the electronic medical record over the network with minimum bandwidth requirement. On the other hand, the XML-based data format is also preferred because XML may address the integration issue with the existing electronic health record application. This thesis addresses both type of data format used in different point of view. 7.2 Future Work Although we have attempted to cover the issues in the designing data format for patient electronic health record using XML and AS.1, this problem domain is still quite complex. Below we point out some issues that could be addressed in order to improve the results and implementation, of our work. Involve more vital signs such as EMG, Respiratory, etc. Hence, we can involve trial case scenario (see appendix) in our patient Medical Record implementation. Use multiple lead and apply multiplexing technique in the implementation. In this thesis, we only use one lead as the example. However, for further application we can add more leads. To address more than one leads, the multiplexing issues has been discussed. Use the real vital sign data obtained from the sensors. Instead of using the simulator, we can directly use the vital signs data acquired from the sensors. This vital signs data can be considered as binary, not as text string as in our implementation. Hence, the application developer can define the element which will accommodate the vital signs data as OCTET STRING, not as REAL. This will reduce the size of ASN.1 binary-encoded data format, because we do not need the mantissa, base and power anymore, which are needed to define the real number to represent the x and y values of an ECG waveform. Improve the demonstrator to provide the exchange of electronic health record. In this demonstrator, we only develop an application that is intended to validate the data format derived from our design methods. The application to exchange of data format over the network is not yet developed in this thesis. For further implementation, we can add this functionality.

90 90

91 Appendix A: Generating ECG Data 91 Appendix A: Generating ECG Data This thesis does not deal with data acquisition and digitizing of ECG waveform. To obtain the ECG waveform data (that will be fed as lead data including the waveform and its annotation values), the ECG waveform generator tool has been used. This tool, that is ECGSyn, is freely available at Physionet 20 web site. By using a dynamical model for generating synthetic (artificial) electrocardiogram signals [38], EGSyn produces many of the features of the human ECG such as beat-to-beat variation in morphology and timing, QT dependence on heart rate, and R-peak amplitude modulation. Hence, we decide to use this tool because of its feature. There are three available versions of ECGSyn generator i.e. Java, C, and MatLab version. This thesis employs Java version of ECGSyn generator. We do a nit modification hence the ECGSyn generates the synthetic electrocardiogram data in three separated values i.e. x values (time domain in ms), y values (voltage domain in mv) and annotation point values that is used to identify the peak of PQRST wave. The annotation point values are as follows: Annotation point: 0 = propagation 1 = P wave peak 2 = Q wave peak 3 = R wave peak 4 = S wave peak 5 = T wave peak Because an ECG record may be composed of waveform data from several leads, therefore, the ECG waveform data generated from the tool is also assumed generated from a lead. The lead data is stored into 3 separated files i.e. x, y, and annotation point. Table 11 shows the contents of a lead data. The size of each file is determined by the sampling rate. The length of synthetic ECG waveform generated from ECGSyn is 10 seconds. The 500 samples per second generates totally 1.7 MB of lead data size. For 100 samples per second, the size of each file is as follows: Xvalue YValue Annoation Total Lead size = bytes = bytes = bytes = bytes Table 13 Lead Data XValue (time in ms) YValue (Voltage in mv) Annotation Point

92 Appendix A: Generating ECG Data 92 After generating lead data, ECGSyn generator can directly plot such lead data in 2D graphic. However, there is another tool which can be used to plot the lead data. Figure 57 shows the synthetic ECG waveform plotted using plt program on Unix Machine. Figure 57 Plot of Synthetic ECG data generated from ECGSyn

93 Appendix B: Trial Case Scenario 93 Appendix B: Trial Case Scenario The collection of vital signs will be transmitted based on the case of the patient. The system may send all of the vital signs or only some of them. This thesis defines case by referring to the Detail Description of Trial Case Scenario [23]. For further implementation, we can add this trial case scenario in our Patient Medical Record solution. Those 5 scenarios, which are summarized from [23], are as follows: Tele-Trauma Team Coronary Heart Disease Patients with Respiratory Insufficiency Home Care and Remote Consultation High Risk Pregnancy Tele Trauma System In this Tele-Trauma System, the sensors will measure the necessary vital signals that will be delivered to the Tele Trauma Team. The vital signs required for this Tele Trauma System can be seen in the Table 14. Table 14 Tele Trauma Definition Vital Sign Quality Aspects Quality of Service ECG 10 s Duration 4800 bps 100 Hz Sampling Rate Lead III Blood Pressure Numerical; every 5, 10, 30 and 60 min May consume low bit rate temperature Numerical every 15 min May consume low bit rate SaO2 Numerical every 15 min May consume low bit rate respiratory 10 s Duration bps Coronary Heart Disease The required vital signs for this Coronary Heart Disease case can be seen in the following Table 15. Table 15 Coronary Heart Disease Definition Vital Sign Quality Aspects Quality of Service ECG 10 s Duration 100 Hz Sampling Rate 4800 bps Lead III Blood Pressure Numerical; every 5, 10, 30 and 60 min May consume low bit rate Patients with Respiratory Insufficiency The required vital signs for this Respiratory Insufficiency can be seen in the following Table 16. Table 16 Respiratory Problem Case Definition Vital Sign Quality Aspects Quality of Service SaO2 Numerical May consume low bit rate Respiratory 10 s Duration 600 bps Home Care and Remote Consultation The necessary vital signs that will be involved in this Home Care and Remote Monitoring can be seen in the following Table 17.

94 Appendix B: Trial Case Scenario 94 Table 17 Home Care and Remote Monitoring Case Definition Vital Sign Quality Aspects Quality of Service ECG 10 s Duration 4800 bps 100 Hz Sampling Rate Lead III Blood Pressure Numerical; every 5, 10, 30 and 60 min May consume low bit rate temperature Numerical every 15 min May consume low bit rate SaO2 Numerical every 15 min May consume low bit rate High Risk Pregnancy The required vital signs for this High Risk Pregnancy can be seen in the following Table 18. Table 18 High Risk Pregnancy Definition Vital Sign Quality Aspects Quality of Service ECG 10 s Duration 100 Hz Sampling Rate Lead III 4800 bps > EMG 10 s 1600 bps > Blood Pressure Numerical; every 5, 10, 30 and 60 min May consume low bit rate

95 Appendix C: Specification of Application Protocol 95 Appendix C: Specification of Application Protocol In Chapter 7, we discuss the future work to improve the application that can exchange our Patient Medical Record over the network. For that purpose, we propose the specification of application protocol that can address the exchange of our Patient Medical Record. Service Element Protocol elements are defined to support service elements. Each protocol element may support [22] one or more service elements of the required service, the cooperation between protocol entities, or a combination of them The E-health service at least has three concerns which are addressed by its Service Element. The first concern is connection establishment phase, in DICOM communication model it is called association establishment. Upon receiving SendPMR service primitive signal from its upper layer, the Mobile Based Unit, or MBU, Protocol Entity (MBU PE) will initiate ConnRequest to E-health LLS. The LLS will forward this message by initiating the ConnIndication to Back End PE. Upon receiving ConnIndication from LLS, Back End PE initiates ConnResponse which will be sent back to MBU PE. This indicates that Back End PE is ready to receive the PMR data sets from the MBU PE. Figure 58 Connection Establishment Phase The second concern is send data phase. This service element is intended to send the PMR Data sets over the established communication. Once the data set sent by MBU PE, the Back End PE will receive the indication. Having received complete PMR data sets, the Back End PE will immediately acknowledge by sending the DataResponse to LLS.

96 Appendix C: Specification of Application Protocol 96 Figure 59 Send Data Phase The third concern is disconnection phase. This service element ends the connection once all PMR data sets have been received by the Back End PE. Once the MBU PE received Data Conf, the MBU PE will immediately initiate DisRequest. If the patient wants to send the new PMR data, the step will be the same, starting from connection establishment first. However, the system may have different connection identification. Following Figure 60 shows the sequence diagram of disconnection phase. Figure 60 Disconnection Phase Figure 61 shows where the service primitives take place in Service Access Point (SAP). The lower level SAP (LSAP) and upper level SAP has been identified here. Lower Level Service make use of connection oriented protocol, hence the client, e.g. MBU, Protocol Entity (MBU PE) needs to initiate a connection request first before sending PMR. E-health Transport takes place as Lower Lever Service. This research work does not specify the LLS whether using wireless communication network or wired communication network to carry the set of Patient Medical Record. Hence, the protocol is flexible enough to be modified in different transport provider later on. Figure 61 The Location of Service Primitives in SAP

97 Appendix C: Specification of Application Protocol 97 The complete description of service primitives can be seen in the following service Table 19. Table 19 Service Description Service Element Service Primitive Parameters Descriptions Connection Establishment ConnRequest ConnectionID, Called Address, MBU initiates this signal to request a connection ConnIndication ConnResponse CallingAddress ConnectionID, CallingAddress, CalledAddress ConnectionID, CallingAddress, Called Address ConnConf ConnectionID, CallingAddress, CalledAddress Send Data SendPMR ConnectionID, CalledAddress, CallingAddress, VitalSignRecords DataIndication ConnectionID, VitalSignRecords SendData DataConf DatResponse ConnectionID, CalledAddress, CallingAddress, VitalSignRecords ConnectionID, CalledAddress ConnectionID, CalledAddress Disconnection DisRequest ConnectionID, Called Address, CallingAddress DisResponse ConnectionID, CalledAddress DisConf DisIndication ConnectionID, CalledAddress ConnectionID, CallingAddress, CalledAddress Back End has successfully receives a request from a MBU PE Back End is ready to receive PMR sets by sending a response back to MBU PE MBU PE receives connection confirmation Patient sends PMR sets by means to MBU PE Health care practitioner receives PMR sets from MBU PE MBU sends PMR stes to Provider PE MBU receive confirmation that indicates PMR has successfully been received by Provider PE Back End PE sends response signal back to MBU PE MBU initiates disconnection request Back End PE sends response signal back to MBU PE MBU receive disconnection confirmation from Provider PE Back End receives disconnection request

98 Appendix C: Specification of Application Protocol 98 PDU Format The PDU format used to carry the binary-encoded PMR data format will be discussed in this section. Figure 62 depicts the PDU layout for such purpose. Figure 62 PDU Layout The required fields in PDU have been identified as follows: PDU ID; this field is composed of PMR Format and Data Set Encoding. The PMR Format field is used to identify that the PDU format specifically carries our own PMR Data Set. The Data Set Encoding is used to determine whether the content of PMR Data Set itself is binary-encoded protocol data format or XML-based protocol data format. The Following table shows the PDU ID values used for our purpose. PDU ID ASN.1 Data Set XML Data Set Table 20 PDU ID Value 11 H 12 H PDU type; there are at least two PDU type has been identified as follows: SendPMR-PDU; informs the client protocol entity that a patient wants to send PMR. This PDU also contains he sets of PMR to be delivered to health care practitioner. DisplayPMR-PDU; display the sets of PMR value to the health care practitioner. Destination and Source Address; used to identify the address of the sender and receiver. Since the application protocol works on top of TCP/IP, the address field will identify the source and destination IP address Trial ID; this field is used to identify that the PMR data set belongs to a specific case based-on trial case scenario, defined in Section 6.1. The Trial ID field also determines the priority of each vital sign records which belong to a specific case. This priority types is for defined further work in case that the user wants to send the collection of vital signs related to a case; however, the bandwidth is fluctuated. Instead of dropping some vital sign records, the system can postpone the lower priority vital sign records and transmit the high priority vital sign records. This thesis defines the priority of vital signs inspired by CEN/TC-251 PT-40 document [2], the vital signs which have continues-time data is considered to have the high priority type. However, CEN/TC-251 PT-40 document only specifies the priority type to be stored in Medical Information Data Base only, not for the exchange. In our specification, the highest priority vital sign is given by the highest number, and the lower number for lower priority. The relationship among Trial Case and the priority of Vital Sign can be seen in Table 21.

99 Appendix C: Specification of Application Protocol 99 Table 21 Relationship among Trial Case and Vital Sign Priority Case Field Vital Sign Priority Value ECG EMG Resp SaO2 BP Temp Tele-Trauma System 01 H Coronary Heart Disease 02 H 3 1 High Risk Pregnancy 03 H Respiratory insufficiency 04 H 3 2 Home Care and Remote Consultation 05 H PMR PDU PMR Protocol Data Unit is a unit of information used to exchange PMR protocol data format between peer application entities. This PMR PDU consists of several multiplexed sampled frames. Applying the multiplexing to each sampled frame is to avoid the short frame has to wait till the long frame has been transmitted completely. Each of sampled frames will carry the protocol data format that has been defined in the previous section such as Patient Demographic, Blood Pressure, and ECG Record protocol data format. Following Figure 63 depicts the multiplexed PMR PDU format. Figure 63 PMR PDU Format Each of sampled frames is composed of a Header and Data Set. Header field consists of: FrameID ; to distinguish between one sampled frame with the others Sequence; the use of this field is inspired by the use of Sequence Number field used by TCP. This field will inform the receiver how many data has been sent by the sender. Data Set is composed of: Data Set ID; this Data Set ID field is defined in Data Set field. This Data Set ID is used to identify whether the content of Data Set field. The value of Data Set Id has been defined as follows:

100 100 Data Set ID Content of Data Set 01 H Patient Demographic Record 02 H ECG Record 03 H EMG Record 04 H Respiratory Record 05 H Oxygen Saturation Record 06 H Blood Pressure Record Data; this field contains the data which can be protocol data format from Vital Sign Records or Patient Demographic Record

101 Bibliography 101 Bibliography [1] Medical waveform description Format Encoding Rules, MFER Committee (IS&C, JAHIS), Version [2] A. Värri, T. Penzel, P. Jacobi, et all, First Working Document of the project team CEN/TC251/PT-40 - File Exchange Format for Vital Signs, Revision 1.2, 2001 [3] Haiying Wang, Francisco Azuaje, Benjamin Jung and Norman Black, A markup language for electrocardiogram data acquisition and analysis (ecgml), Journal of BMC - Medical Informatics and Decision Making [4] Igamberdiev Muzaffar and Kamilova Malohat, Designing PDU formats Used for Vital Signs Exchange In Telemedicine Aos.cpplications, Telematic Service Report, Universiteit Twente 2003 [5] Petrus Santoso, Inclusion of Medical Data in MPEG-2 for a Distributed Tele- Rehabilitation System, M.Sc. Thesis, M.Sc. Telematics Programme Univesity of Twente, 2002 [6] Frank G. Yanowitz, The Standard 12 Lead ECG, ECG Learning Center, University of Utah School of Medicine, available online: medstat.med.utah.edu/kw/ecg/ecg_outline/lesson1/index.html [7] Sorin Dusan, Introduction to Electrocardiography, Rutgers University Piscataway, New Jersey,U.S.A. [8] Health Informatics Standard Communication Protocol Computerassisted electrocardiography, Health Informatics CEN/TC 251/N02-15, available online: [9] Gianluca de Luca, Fundamental Concept in EMG Signal Acquisition, Delsys Inc, 2001 [10] Carlo de Luca, Surface Electromyography: Detection and Recording, Delsys Inc, 2001 [11] John Larmouth, The Emergence of ANS.1 as an XML Schema Notation, Larmouth T & PDS Ltd, UK. [12] Jacob Palme, Internet Application Protocol : Chapter 2 :Introduction to Coding System, available online: [13] Barry Brown, Mark Kohl and Norman Stockbridge, FDA XML Data Format Design Specification [14] E.F. Michels, M.J. van Sinderen and I.A. Widya. Dictaat Telematica Diensten, Universiteit Twente, [15] ASN.1 Site [16] Carl J. Brandt, Blood Pressure Measurement, available online: [17] Suzanne M. Burns, Working with Respiratory Waveform, AACN Clinical Issue, Vol. 14, No. 2, pp , [18] Sandra L. Schutz, Oxygen Saturation Monitoring by Pulse Oximetry, AACN Prosedure Manual for Critical Care, 4th edition, 2001 [19] HL7 Version 3.0 Standard Message Development Framework, available online: [20] R.Fischer, Chr. Zywiets, How to Implement SCP-ECG, Open ECG, Hannover, [21] Jaakko Malmivuo and Robert Plonsey, Principles and Applications of Bioelectric and Bio magnetic Fields, chapter 15: 12 Lead ECG System, OXFORD UNIVERSITY PRESS, [22] L. Ferreira Pires and D.A.C. Quartel, Dictaat Protocol Engineering,

102 Bibliography 102 Universiteit Twente, Copy right June 2003 [23] Detailed Description of Trial Scenario, Mobihealth IST , Gesucnd Heit Scout 24, Lulea Technical University, Medisch Spectrum Twente, Corporacio Sanitaria Clinic, 2003 [24] Colin l Anson and Adrian Pell, Understanding OSI Application, Prentice Hall, 1993 [25] Stephan Kay, The Domain Model of Electronic Health Care Record Communication, Medical Information Group, Dept. of Compuyer Scienece, University of Manchester, 1999 [26] 12 Leads ECG System. Available online at : [27] DR. D.R. Johnson, Introductory Anatomy: Respiratory System,Center for Human Biology, Leeds University, UK. [28] Steven C. Horiil, Fred W. Prior,et all. DICOM Protocol Analyzer, available online at: [29] Digital Imaging and Communication Medicine(DICOM) Standard, Part 1: Introduction and Overview, National Electrical Manufacturers Association, Virginia, USA, 2003 [30] Digital Imaging and Communication Medicine(DICOM) Standard, Part 3: Information Objects Definition, National Electrical Manufacturers Association, Virginia, USA, 2003 [31] Digital Imaging and Communication Medicine(DICOM) Standard, Part 5: Data Structures and Semantics, National Electrical Manufacturers Association, Virginia, USA, 2003 [32] Digital Imaging and Communication Medicine(DICOM) Standard, Part 7: Message Exchange, National Electrical Manufacturers Association, Virginia, USA, 2003 [33] Extensible Markup Language (XML), W3C Architecture Domain, available online at : [34] ASN.1 Information Site France Telecom, available online at [35] Information Technology ASN.1 Encoding rule mapping: W3C XML Schema definition into ASN.1 ITU-T Recommendation No. X.694, available online at [36] John Larmouth. ASN.1 Complete. Printed Edition by Morgan Kauffmann.2000 [37] Information Technology ASN.1 Encoding rule: XML Encoding Rule (XER) ITU-T Recommendation No. X.693, available online at [38] McSharry PE, Clifford GD, Tarassenko L, and Smith L. A dynamical model for generating synthetic electrocardiogram signals. IEEE Transactions on Biomedical Engineering 50 (3): ; March 2003

103 Index 103 Index A abstract syntax, II, 11, 31, 32, 33, 34, 35, 36, 39, 40, 45, 55, 58, 73 Abstract Syntax Format Specification, 33 abstraction of a message, 35, 37 annotation, 14, 23, 29, 30, 59, 62, 64, 65, 66, 69, 91 Application Layer, II, 10, 31, 32 Application Protocol Design, 77 arteries, 19 ASN.1 Encoding Rule, 40 ASN.1 Record Structure, 40 ASN.1 Translator, 49, 51 ASN1, 39 asn2xsd, 53 atrium, 12 B BER (Basic Encoding Rule), 39 binary encoding, 39 binary-based encoding, 34, 39, 45 Blood Pressure, 19, 20, 62, 71, 72, 73, 74, 75, 86, 93, 94, 99, 100, 101 Blood Pressure Record, 71, 72 C CEN/TC-251, 11, 21, 87, 98 CEN/TC251 SCP, 22 CEN/TC-251 SCP, 21 character based encoding, 39 character-based encoding, 32, 34, 39, 45 compile-time, 33, 34, 56 Compile-time, 34, 47 Complex Type, 29, 50, 63 D data format, 31 data structures, II, 10, 31 data types, II, 10, 31, 42, 48 Design Methods, 33 Design Principles, 31 design-time, 33, 55 DICOM, 11, 21, 24, 25, 26, 27, 95, 102 DICOM Message, 25, 27 DTD and XML Schemas, 42 E ECG 12 lead, 15 ecgml, 10, 11, 21, 27, 28, 29, 33, 55, 62, 71, 87, 101 electrocardiography, 12, 14, 101 Electrocardiography, 12, 16, 21, 101 F FDA, 10, 11, 21, 23, 24, 29, 101 Generating ECG Data, 91 HL7, 33, 37, 101 intuitive interpretation, 36 G H I Lead, 14, 16, 64, 65, 66, 67, 68, 83, 84, 85, 91, 93, 94, 101 L M Mapping XML Schema to ASN.1, 49 Message Framework Definition, 33, 35, 37 Message Object Diagram, 37, 38, 57, 63, 65, 72 Message Structure, 22 Multiplexing, 68, 97 O Objective System, 47, 48, 83, 84, 86 OSI Reference Model, 38 Oxygen Saturation, 12, 20, 62, 100, 101

104 Index 104 P Patient Demographic Record, 55, 56, 57, 58, 60, 61, 82, 83, 86, 100 Patient Medical Record, 11, 55, 56, 60, 96 P-DATA Service, 27 P-DATA-TF PDU, 26 PDU, 26, 27, 32, 97, 98, 99, 101 perspective of application entities, 32 perspective of transport provider, 32 Pressure Mode, 19 Protocol Data Format, 32 Protocol Data Unit, 24, 26, 32, 99 Protocol Entity, 78, 96, 97 purkinje fibres, 13 QRS Complex, 13 Q R Respiratory, 18, 19, 62, 93, 99, 100, 101, 102 respiratory measurement, 18, 19 Run- time, 34 run-time, 33, 34, 48, 52, 56, 60, 61, 75, 85 Committee S SCP ECG Message Structure, 22 SEQUENCE, 41 Service Element, 22, 25, 95, 96 Simple Type, 49, 50 systolic pressure, 19, 20 T T wave, 14 TLV, 40 transfer syntax, II, 10, 32, 34, 39, 55, 56 Trial Case Scenario, 93 Vital sign, 12 Volume Mode, 19 X.693, 49, 52, 102 V X X.694, 34, 47, 49, 50, 52, 102 XML Document, 33, 34, 42, 43, 44, 45, 46, 48, 54, 59, 61, 67, 73, 82, 83, 86 XML Schema Diagram, 28, 29, 45, 46, 58, 66, 72, 73