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

(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)

Abstract

Tele-monitoring of the condition of patients is an essential component of an electronic-healthcare (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 binary-encoded 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 III

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

(6)

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

(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-251 ...64

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

(8)

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 tool-based 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)

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 6.

1.5 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-251. 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

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 condition1. 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 atrium2 known as the sinus node3 [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} http://www.thefreedictionary.com/

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)

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 myocardium4 via the "purkinje fibres". This will cause the ventricle to re-polarize. It leads to the generation of T wave.

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)} Right Atrium

Left Atrium

Right Ventricle

(13)

Chapter 2 Physiology of Vital Signs 13 downward wave to its base. The dome-shaped T wave indicates ventricular

re-polarization.

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)

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

(15)

Chapter 2 Physiology of Vital Signs 15

Figure 3 ECG Lead Positions in the body

Purposes of ECG

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].

Table 1 ECG Rhythm ECG Wave Normal range P wave less than 0.12s

PR 0.12-0.22s 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

(16)

2.2 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 50-150 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]:

z 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.

z External respiration; is the exchange oxygen and carbon dioxide in the eternal environment

z Internal respiration; exchanges O₂ and CO₂ between blood in the capillary vein and body cells.

During the respiratory measurement, the measured volume of gas can be distinguished as follows [27]:

z Tidal volume; the amount of gas moved during normal breathing. The amount of

measurement is approximately 500cm3_.

z Inspiratory reserve volume; the amount of gas that can be taken vigorously over the tidal volume. The amount of measurement is approximately 3100cm3.

z Expiratory reserve volume; the amount of gas that can be vigorously exhaled

(18)

z 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 1200cm3.

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 ventilation5 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 8.

2.4 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 60-70 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 120-139 80-89

High Blood Pressure

Stage 1 140-159 90-99

Stage 2 160 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].

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)

(21)

Chapter 3 Vital Sign Format Standards 21

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 SCP-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)

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 multi-channel 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)

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.

Figure 11 FDA Application GUI

3.4 DICOM

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 CT6 scans, MRI7, 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)

3.4.1 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].

Command Set Data Set

Tag Length Value Data Element ... Data Element

Tag VR _LengthValue Value Field DICOM Message

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)

other related elements. Figure 14 shows the lay out of DICOM Data Set. Data Set may consist of sequence of Data Element.

Figure 14 DICOM Data Set

Data Elements

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.

3.4.2 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)

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

Figure 16 P-DATA Service

3.5 ecgML

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)

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 2002-10-22 StudyTime Study Time: HH-MM-SS-SS Optional Time 12.01.00

(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 appropriate

mV

FileLink Reference for external data Optional String RealValue Real value of ECG Data Required String

(30)

From Offset from the origin on the x

axis to the beginning of waveform Required Time or samples 20:10:00 To Offset from the origin on the a axis

to the ending of waveform Required Time or samples 21:00:00 Data The list of Y value Required A list for

float values string

1.25,1.20

Comment Comment on this format Optional String Binary Data Binary Representation of ECG

Data Required Hexadecimal Encoding Encoding Scheme for embedding

the binary data within XML document

Required Base64

From Offset from the origin of x axis to the beginning of waveform

Required Time or samples

00:00:02 To Offset from the origin of x axis to

the ending of waveform

Required Time or samples

00:20:00 Scale Scale factor to use to convert a

binary data into a real value

Required Float 1.0

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

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)

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 design-time 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)

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;

TheASN.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 binary-encoded (using BER or PER) protocol data format. This ASN.1 binary-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 Making Description Table Specification of Message in XML (XML Schema and XML Document)

XML Schema

Automatic Mapping from XML Schema to ASN.1 Specification performed by a tool Compiling ASN.1 Specification (BER,PER) Values to be exchanged ASN.1 (BER,PER) binary-encoded data format XML-based data format Message Framework Definition Abst ract Synt ax Specificat ion

User point of view

System point of view

Compile time Run-time ASN.1 Specifications Description Table Execution Compiling (using a language compiler)

Generated Encoding/ Decoding Method & Data

Structure ASN.1 Encoding Run-time Library (PER,BER) Application Behavior Run-time Encoding Run-time (BER,PER) Manual Mapping to generate ASN.1 Specification Option 1 Option 2 XML API XML Schema and XML Document Option 2a Option 2b Design-time Run-time Library Input/ Output Process XML-based Legend

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)

1. A message can be composed by objects or elements8 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 sub-section.

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}

(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 man