thesis

Embedded Internet for Pulse Oximeters I

Embedded Internet for

Pulse Oximeters I

by

Matthew Roy Burey

School of Information Technology and Electrical Engineering

University of Queensland

Submitted for the degree of

Bachelor of Engineering

in the division of Computer Systems

October 2001


King’s College

Upland Rd

St Lucia Qld 4067

19 October 2001

Head of School

School of ITEE

The University of Queensland

St Lucia QLD 4067

Dear Professor Kaplan,

In accordance with the requirements of the degree of Bachelor of Engineering in the

division of Computer Systems Engineering, I present this thesis titled “Embedded

Internet for Pulse Oximeters I”. This work was performed under the supervision of

Dr Stephen Wilson.

I declare that the work submitted in this thesis is my own, except as acknowledged in

the text and footnotes, and that it has not previously been submitted for a degree at the

University of Queensland or any other institution.

Yours Sincerely

Matthew Burey


i

Acknowledgements I would like to thank Steve Wilson for his guidance and supervision during this year.

Special mention goes to the hard working people at the Mater Children’s Hospital

especially Gordon Williams who helped with this project. Last but not least I would

like to thank Ben Lever, my thesis partner, for his hard work and co-operation whilst

implementing the client side.

Thank you.


ii

Abstract

In recent years there has been many investigations into sleeping disorders. Many of

these studies are carried out in specially equipped units in which a patient is

monitored whilst sleeping. Measurements that are taken are in the form of

electrocardiograph (ECG), electromyograph (EMG), electroencephalograph (EEG),

nasal airflow, and abdominal movement. Pulse oximetry data is also recorded during

the night. Pulse oximetry is the measurement of pulse rate and oxygen saturation of

blood. Along with other measurements pulse oximetry data is used in the diagnosis of

sleeping disorders. Recent studies have shown that diagnosis of sleeping disorders is

better suited to a location of familiarity rather than a hospital situation. Amongst

others, this is one of the many reasons that remote monitoring of medical equipment,

such as the pulse oximeter, is a forward step in sleep medicine.

In building an “embedded internet for pulse oximeters” a door is opened on the

possibility of remote monitoring via the Internet. This solution would need to be

inexpensive relative to the cost of a pulse oximeter and the system needs to be robust

as it will be portable. Ease of use is another major factor when designing such a

system. Simplifying the operation of the device allows for non-technical operators to

adequately use the equipment to full potential. The proposed system, named Oximeter

Internet Interface or oi2, is a web server connected via RS-232 serial interface to a

pulse oximeter. The oi2 system is able to serve pulse and SpO2 data as well as trend

information to the Internet. The medical staff can download trend data and view real

time streaming data from any web browser. The design of an Internet based solution

can be broken down into two major components, these being the server side and the

client side. The server side includes the control and data acquisition from the pulse

oximeter and serving this information up to the Internet. The client side includes the

retrieval of information from the Internet and displaying that information in a human

readable form.

iii

An Internet solution such as this is not a comprehensive finished product but more a

stepping-stone to a fully functional system. The oi2 system has been demonstrated at

the Mater Children’s Hospital as a proof of concept. The idea was widely supported

by staff and this led to more in depth analysis of the feasibility of such a device. It can

be concluded that this proof of concept can be extended to a commercially viable

product.


iv

TABLE OF CONTENTS ACKNOWLEDGEMENTS......................................................................................... I

ABSTRACT................................................................................................................ II

1.0 INTRODUCTION............................................................................................1

2.0 LITERATURE REVIEW................................................................................6 2.1 TELEMEDICINE - REMOTE MEDICINE ................................................................... 6

2.1.2 Hospital Without Walls ................................................................................ 6 2.1.3 CARE System................................................................................................ 7

2.2 EMBEDDED INTERNET TECHNOLOGY ................................................................... 7 2.2.1 Embedded Internet Possibilities................................................................... 8 2.2.2 Embedded Internet In Practice .................................................................... 9 2.2.3 Available Embedded Web Servers.............................................................. 10

2.2.3.1 Netburner............................................................................................. 10 2.2.3.2 Picoweb ............................................................................................... 11 2.2.3.3 Connect One iChip .............................................................................. 12 2.2.3.4 Seiko S7600A...................................................................................... 12 2.2.3.5 Rabbit 2000 TCP/IP Development Kit................................................ 13 2.2.3.6 Review of Available Web Servers ...................................................... 14

2.3 PULSE OXIMETER TECHNOLOGY ........................................................................ 15 2.3.1 Oxinet II Central Station Network ............................................................. 15 2.3.2 TeleOximetry – 3900/3900P Pulse Oximeter............................................. 16 2.3.3 CSI-TC Wireless Monitoring Station ......................................................... 16 2.3.4 Internet Polysomnography ......................................................................... 17

3.0 RESULTS........................................................................................................19 3.1 DESIGN AND IMPLEMENTATION.......................................................................... 20 3.2 NOVACOM1 INTERFACE MODES..................................................................... 21

3.2.1 Real time Data Acquisition ........................................................................ 21 3.2.2 Trend Data ................................................................................................. 24 3.2.3 General Status Information........................................................................ 26

3.3 FINAL PRODUCT ................................................................................................. 28 3.3.1 Displays...................................................................................................... 29 3.3.2 In Practice .................................................................................................. 31

4.0 DISCUSSION .................................................................................................32 4.1 IMPLEMENTATION ISSUES................................................................................... 33

4.1.1 Real time Data Acquisition ........................................................................ 33 4.1.2 Trend Data ................................................................................................. 34 4.1.3 General Status Information........................................................................ 34

4.2 REVIEW OF AVAILABLE SYSTEMS ...................................................................... 35 4.3 EFFECTIVENESS OF DESIGN ................................................................................ 36 4.4 COMMERCIAL VIABILITY ................................................................................... 37

5.0 FUTURE WORK ...........................................................................................38 5.1 SUPPORT FOR OTHER DEVICES ............................................................................ 38 5.2 DIFFERENT INTERNET CONNECTIONS ................................................................. 39 5.3 SECURITY........................................................................................................... 40

v

5.4 REMOTE FIRMWARE UPDATES ........................................................................... 41 5.5 MULTI-USER MULTI CHANNEL SYSTEM ............................................................. 41

6.0 CONCLUSION...............................................................................................43

7.0 REFERENCES...............................................................................................44

8.0 APPENDIX A .................................................................................................46

9.0 APPENDIX B .................................................................................................55


vi

LIST OF FIGURES Figure 1-1: Pulse Oximetry Diagram............................................................................ 2 Figure 1-2: Oxipleth Pulse Oximeter from Novametrix. Photo courtesy of

Novametrix............................................................................................................ 2 Figure 1-3: Mater Children’s Sleep Unit ...................................................................... 3 Figure 1-4: System overview. Diagram courtesy of Ben Lever................................... 4 Figure 1-5: Implementation breakdown........................................................................ 5 Figure 2-1: Simplified block diagram of "Hospital without walls" implementation in

a single home. Diagram courtesy of The Center for Online Health..................... 7 Figure 2-2: Internet Fridge. Picture courtesy of LG..................................................... 9 Figure 2-3: Netburner CFV2-40 - Courtesy of Netburner. ......................................... 10 Figure 2-4: Picoweb server courtesy of Lightner Engineering ................................... 11 Figure 2-5: iChip block diagram. Picture is courtesy of Connect One. .................... 12 Figure 2-6: Seiko S7600A Block Diagram. Picture courtesy of Seiko Instruments. . 13 Figure 2-7: Rabbit 2000 TCP/IP Development Kit. Picture courtesy of Rabbit

Semiconductor..................................................................................................... 14 Figure 2-8: Oxinet II Central Station Network. Picture courtesy of Nellcor. ............ 15 Figure 2-9: 3900/3900P Pulse Oximeter. Picture courtesy of Datex-Ohmeda. ......... 16 Figure 2-10: Wireless Monitoring Station. Photo is courtesy of Criticare................. 17 Figure 2-11: Internet Polysomnography device. Courtesy of Advanced Medical

Electronics (AME). ............................................................................................. 18 Figure 2-12: Positioned on patient. Courtesy of AME. ............................................. 18 Figure 3-1: System overview ...................................................................................... 19 Figure 3-2: File interaction diagram............................................................................ 21 Figure 3-3: Real time mode functional overview........................................................ 22 Figure 3-4: Trend mode functional overview ............................................................. 25 Figure 3-5: Patient details functional overview .......................................................... 27 Figure 3-6: Final product (front view) ........................................................................ 28 Figure 3-7: Final product (back panel)........................................................................ 28 Figure 3-8: oi2 system operating in the sleep unit ....................................................... 31 Figure 3-9: Staff can easily set up the oi2 system ....................................................... 31 Figure 5-1: Satellite Implementation. Diagram courtesy of Ben Lever. .................... 40 Figure 5-2: Multiple Patient Scenario. Diagram courtesy of Ben Lever. .................. 42 Figure 9-1: Screen shot of main menu page................................................................ 55 Figure 9-2: Screen shot of patient details page ........................................................... 56 Figure 9-3: Screen shot of clear trend page................................................................. 56 Figure 9-4: Screen shot of date and time page ............................................................ 56 Figure 9-5: Screen shot of real time page ................................................................... 57 Figure 9-6: Screen shot of time out page .................................................................... 57 Figure 9-7: Screen shot of trend dump page ............................................................... 58 Figure 9-8: Screen shot of the online help page.......................................................... 58


vii

LIST OF TABLES

Table 3-1: Real time data format................................................................................. 21 Table 3-2: NOVACOM1 mode 1 data ........................................................................ 22 Table 3-3: Real time mode test data............................................................................ 23 Table 3-4: Trend data format ...................................................................................... 24 Table 3-5: Test trend dump data ................................................................................. 26


1

1.0 Introduction

Sleeping disorders are a common ailment for young children. As many as 30% [1] of

all children at some stage suffer from some form of sleeping disorder, many of which

will never receive the proper diagnosis or treatment. Ineffective sleep has a great

impact on growth and development and also contributes to poor academic results.

The immune system and general health, both mental and physical, are also affected.

Given that such a large number of children suffer from poor sleep it is not surprising

that research has been undertaken in this field. A large number of disorders have been

defined and categorized into three main categories. These are insomnia, sleep apnea

and narcolepsy, which in layman’s terms are not enough sleep, disturbed sleep and

too much sleep respectively.

Sleep apnea affects the breathing patterns of a sleeping person. A person who suffers

from this does not breath properly throughout the night and they may go through brief

periods when breathing stops all together. There are two main types of sleep apnea,

these are, obstructive sleep apnea and central sleep apnea. Obstructive sleep apnea is

the hindrance of the airway from a partial or total blocking of the throat. In adults this

can be caused by inherent characteristics, excessive obesity, and alcohol consumption

prior to sleeping. In children large tonsils and cranio facial deformities often cause

this. Central sleep apnea is caused by a delayed breathing signal from the brain. In

both cases sleep is broken so that breathing can continue. This may occur hundreds of

times during the night and the patient may not have any recollection of the waking

periods.

Polysomnography (PSG) is the recording of physiological variables that are related to

the stages of sleep in an effort to diagnose causes of sleep disorders [3]. The

physiological variables that are recorded are:

!"Electroencephalography (EEG)

!"Electro-oculography (EOG)

!"Electrocardiography (ECG)


2

!"Electromyography (EMG)

!"Airflow

!"Respiratory effort

!"Sound recordings to measure snoring

!"Video monitoring of body positions

!"Core body temperature

!"Pulse Oximetry

Pulse oximetry is the measurement of pulse rate and oxygen saturation of the arterial

blood. In essence it works by passing two different wavelengths of light through a

peripheral part of the body such as a finger. This light is absorbed depending on the

oxygen saturation of hemoglobin in the blood cells. As shown in Figure 1-1 a photo-

sensor detects the light on the other side of the peripheral and the resultant oxygen

saturation is calculated. The light absorbed also consists of a component that

corresponds to the pulse rate. This is a result of the increase in arterial blood volume

with each heartbeat. Pulse oximetry is one of the physiological variables that are

measured during the diagnosis of sleeping disorders. It is a useful variable to monitor

in cases such as sleep apnea as the oxygen saturation of the blood directly corresponds

to the volume of intake air.

Figure 1-1: Pulse Oximetry Diagram

Figure 1-2: Oxipleth Pulse Oximeter from Novametrix. Photo courtesy of Novametrix.

Diagnosis of sleeping disorders is undertaken in a controlled and monitored

environment. Hospitals such as the Mater Children’s in Brisbane have constructed a

specially designed unit consisting of four sleep rooms. These rooms are equipped

with probes to monitor vital signs during the different stages of sleep. Monitoring

equipment is located outside the room so they are accessible whilst the child is


3

sleeping. A data logging system is in place, which is a server running the Uniquant

Sleep Acquisition System. The data is logged throughout the night and two medical

staff also monitors the patient. From the ascertained data an assessment of the

patients stages of sleep can be made, which leads to the diagnosis of disorders.

Figure 1-3: Mater Children’s Sleep Unit

Since the Mater Children’s Hospital Sleep Unit is the only such unit in Queensland

and upper New South Wales the limited number of rooms poses quite a problem.

Given that 3%[1] of children suffer from obstructive sleep apnea at some stage it can

be seen that the resources to cope with such a high demand of cases does not currently

exist. Further more, the associated cost of keeping a child overnight is relatively high.

In a rural situation, a family would have to travel into Brisbane, stay overnight and

return the next day. If the study was carried out over multiple nights then the cost for

the family and hospital rapidly increases. Not only cost but also the family is

inconvenienced as mother and/or father would miss work and possibly a baby-sitter

would need to be arranged for the other children. As a result it is obvious that a better

solution needs to be incorporated.

Remote monitoring of such equipment allows for a more flexible situation. The

expense of sending a small box via a courier to a local hospital or to the patient’s

home is insignificant in comparison to the previous case. The inconvenience is also

reduced tenfold. Remote monitoring also brings with it the possibility of specialist

doctors being able to monitor their patients from a distance.


4

In building an “embedded internet for pulse oximeter” a door is opened on the

possibility of remote monitoring via the Internet. The proposal is put forward that an

embedded Internet web server device be designed so that remote monitoring can be

enabled on a pulse oximeter. The for-mentioned device, named Oximeter Internet

Interface or oi2, is a web server connected via RS-232 serial interface to a pulse

oximeter. A system overview is shown in Figure 1-4. The oi2 system is able to serve

pulse, SpO2 data and also trend information to the Internet. Medical staff can then

download the trend data or view real time streaming data from any web browser on an

Internet capable device. Patient details can be stored locally on the oi2 system so that

identification is possible. The oi2 system will have enough control so that it can clear

the trend memory located on the pulse oximeter.

Figure 1-4: System overview. Diagram courtesy of Ben Lever.

The design of an Internet based solution can be broken down into two major

components, these being the server side and the client side. This is shown in Figure

1-5. The server side includes the communication with the pulse oximeter and serving

the information to the Internet. The client side includes the retrieval of the information

from the Internet and displaying that information in a human readable form. Basically

the server side implementation executes on the server where the client side is

transferred to the client and executes there. This thesis is mainly concerned with the

server side implementation of the system.


5

Figure 1-5: Implementation breakdown

This solution needs to be inexpensive relative to the cost of a pulse oximeter and also

robust as it will be portable. Ease of use is another major factor when designing such

a system. Simplifying the operation of the device allows for less technical operators

to adequately use the equipment to it’s full potential.

The Internet serves as a global network for remote monitoring of devices. Since the

Internet infrastructure is already extensively in place the cost of setting up a remote

monitoring facility is greatly reduced. A wealth of resources is available for the

Internet particularly in relation development and standard protocols used. This

reduces cost and time in development of such a system. The Internet is also a

somewhat familiar medium, as it is becoming a part of everyday life for most people.


6

2.0 Literature Review This section provides an overview of the current technology available and its

relevance to this thesis. This technology relates to the current advances in embedded

Internet, pulse oximeters, and remote sleep medicine.

2.1 Telemedicine - Remote Medicine

Telemedicine utilizes current telecommunications technology such as

videoconferencing to help support those requiring health care. This is common in

situations where people are unable to access conventional health care. These include

but are not limited to the elderly and rural patients. Specialist care to rural areas is

also possible through the means of telemedicine. In the past, telemedicine has been

limited in transmission medium but currently advances are being made to incorporate

today’s technology.

2.1.2 Hospital Without Walls

“Hospital without walls”[13] is a documented project that encompasses the needs of

elderly patients living at home. By using current telecommunications and information

technology practices patients can be moved from hospitals/nursing homes back to

their own home. Patients are monitored with various probes and information is

transmitted back to a base station through a wireless local area network link. At the

base station the information is collated and sent through to an assessment center for

analysis. The base station consists of a PC in which data can also be entered

manually by visiting nurses. As a first implementation the sensing technology used

was to measure heart rate and blood pressure as well as attitude, gait and fall status.

Accelerometers are used to sense a patient falling and generate the appropriate alarm

at the assessment center. This system provides a better quality of life, as there are

definite benefits to living in familiar surroundings. Not only this but the cost savings

for home telemedicine are quite substantial.


7

Figure 2-1: Simplified block diagram of "Hospital without walls" implementation in a single

home. Diagram courtesy of The Center for Online Health.

2.1.3 CARE System Mastushita Electrics Works (MEW) has developed the CARE system [6] using

emWare’s device internetworking technology. The CARE system is targeted for the

elderly in nursing homes. Conventional methods used a mere camera that was viewed

by an attendant. This could be set up with multiple screens or with one screen

changing between cameras. Both these scenarios have problems as events such as a

patient falling down could be missed. The system comprises a camera and sensors

placed in a room within the nursing home. The sensors can detect locality and

whether the patient is lying down or standing up. Within the CARE monitor the

inputs are polled and events and alarms such as “laid down on bed” and “agitated

sleep” are generated. The events and alarms are transmitted back to central control

station. These are displayed in a web browser style interface and alert the attendant to

any problems. The system is set up over Ethernet but runs a proprietary open network

protocol called emNet. This system is in use in nursing homes in Japan.

2.2 Embedded Internet Technology

Embedded Internet technology is the current trend to manufacture small web servers

and place them in devices to allow control and monitoring via the Internet. Devices

such as printers, routers, cameras, and set-top boxes have embedded Internet devices


8

built into them so as to allow easy configuration and status information. The Internet

gives a standardized and familiar approach, which is relatively low cost. More

mainstream user interfaces include extra hardware such as keypads and screens,

which are suddenly not needed when implementing embedded Internet interface.

Embedded Internet technology has many other advantages, which allow devices to be

controlled remotely. Hard to reach equipment can now be monitored, maintained and

controlled from a distance and user manuals can be stored on-line for easy access.

2.2.1 Embedded Internet Possibilities

There are many uses of embedded Internet, some of which already exist in

commercially available products. Not only does embedded Internet simplify control,

diagnostics, maintenance and monitoring but also cuts the cost. This cost cutting is

shown in development and in practice as well. Just about anything can benefit from

this added feature, which has been demonstrated by such devices as the Internet

Fridge. From the fridge the user can surf the web, retrieve email, watch TV, play

MP3’s, download recipes and a hosts of others. This is all accomplished by a 15”

LCD touch screen with a virtual keyboard much the same as some PDA’s. This is an

example of what some people would call a novelty more than practical application but

clearly demonstrates that a seemingly unobvious device can benefit from embedded

Internet technology. All this shows that there are many uses to embedded Internet

technology some serious and some not so serious.


9

Figure 2-2: Internet Fridge. Picture courtesy of LG.

2.2.2 Embedded Internet In Practice

Many commercially available products are having the added feature of embedded

Internet built into them. In some cases the extra expense is warranted, in others

though it is more a novelty than anything else.

A good example of embedded Internet is the HP LaserJet series of printers. This

series has had web servers embedded into them to allow remote printing, monitoring

and a host of other useful features. The embedded Internet changes the way users

access, manage and print information. As a forecast from a market analyst group,

35% [17] of devices attached to the Internet by 2006 will be non-PC based. The

printers in this series come with the added features of HP smart chip. This enables the

network administrator to receive notification by email, mobile phone or computer

about supply of toner or paper. The HP LaserJet 4100 costs about $US1099 [17] and is

the top of the range printer. The HP LaserJet 1200 still has embedded Internet

technology but comes in at a price of $US399.

Another practical application of embedded Internet is the myriad of camera set up on

beaches around the world that have a direct link to a web site. In this way, surfers can

go on the web to view the beach conditions and decide whether it is worthwhile going


10

surfing. There are quite a few beaches with the installed even here in Australia. A

good example is Noosa in Queensland.

2.2.3 Available Embedded Web Servers

There are quite a few embedded web servers on the market today. These vary greatly

in specifications and price. This section covers some of the embedded web server

technology that was considered when originally researching the topic.

2.2.3.1 Netburner

The Netburner [9] package is Motorola Coldfire processor running the real time

operating system uC/OS. The netburner has a fully implemented TCP/IP stack with

UDP and supports HTTP, PPP, FTP, and TELNET. The NetBurner CFV2-40 starts at

around US $499 [10]. This includes the Motorola Coldfire 5206e, which is a 40 MIPS

processor, which has 512 kBytes of FLASH compressible up to 1 Mbytes. Available

to the processor is 4 Mbytes of DRAM and an 8Kbyte allocation of non-volatile

parameter storage. The CFV2-40 includes 2 DMA channels and dual UARTs. Also

included in the design is a 60-pin interface to attach custom hardware. These kits are

designed to get projects running quickly and easily.

Figure 2-3: Netburner CFV2-40 - Courtesy of Netburner.


11

2.2.3.2 Picoweb

The Picoweb is a miniature web server from Lightner Engineering. The design of the

Picoweb is based around the ATMEL 8515 micro-controller and also includes 8k

FLASH, 512 bytes of EEPROM, 512 bytes of RAM and 32k serial EEPROM. The

8515 is an 8 MIPS processor. The Realtek 8039 handles the network interface. This

is an NE2000 compatible controller.

Previously the Picoweb was published in some technical magazines as the worlds

smallest web server. The, first prototype, was claimed to be priced at a modest $25

for a breadboard design. Later versions included more serial EEPROM for web site

storage and were packaged as a commercially available product. Lightner

Engineering now sell the full development kits for $149[11].

Figure 2-4: Picoweb server courtesy of Lightner Engineering

The Picoweb includes a real time network kernel, TCP/IP stack and HTTP web

server. Network connectivity is established with an RJ-45 type connection.

Programming is accomplished through the parallel port of a PC and the Picoweb can

interface to other devices through the serial interface or the extra port on the 8515

micro-controller. All these pins have been grouped together on one 25 pin D-shell

connection.


12

2.2.3.3 Connect One iChip

The iChip [12] is a co-processor that communicates with the existing processor to

facilitate a connection to the Internet. Being an application-specific Internet

controller the iChip can be connected easily to an existing design. The iChip is

compatible with Connect One’s proprietary API, simplifying communication between

the host processor and the iChip. With a fully implemented TCP/IP stack the iChip

can easily be connected to the Internet via several mediums. With the iChip changing

the design between modem and LAN connections becomes an insignificant step.

Figure 2-5: iChip block diagram. Picture is courtesy of Connect One.

2.2.3.4 Seiko S7600A

Seiko have produced a fully self-contained TCP/IP stack in a chip called the S7600A [18]. This LSI device features TCP/IP version 4, UDP and PPP protocols and

incorporates a 68/80 MOTO/Intel microprocessor bus interface. For network

interaction the TCP/IP stack utilizes a 10Kbytes block of SRAM. Low power

consumption and a wide operating voltage help make this an easy to integrate

solution. To help push this product Seiko have a comprehensive listing of the full

technical specifications online that includes development APIs, source code and

utilities. Figure 2-6 shows the block diagram of the device showing the

microprocessor and physical layer interface.


13

Figure 2-6: Seiko S7600A Block Diagram. Picture courtesy of Seiko Instruments.

2.2.3.5 Rabbit 2000 TCP/IP Development Kit

The Rabbit 2000 TCP/IP Development Kit [19] incorporates an 18 MHz Rabbit 2000

Processor with Ethernet hardware and SRAM. The board includes both an RS-232,

RS-485 port and 10baseT connection. This development kit includes full TCP/IP

source code with capabilities provided for ICMP, SMTP, FTP and TFTP. HTTP

protocol is also implemented with functionally including CGI routines, server side

includes (SSI), cookies, and basic authentication. 512Kbytes of flash is available for

program and web page storage. The entire development kit sells for US $199.


14

Figure 2-7: Rabbit 2000 TCP/IP Development Kit. Picture courtesy of Rabbit Semiconductor.

2.2.3.6 Review of Available Web Servers

The Netburner whilst a very good choice as functionality goes is too powerful for the

application at hand. Also the price is quite high relative to the Picoweb. The

Netburner would be a better choice for further work to this thesis as more

functionality will be required, with the possibility to implement PPP across a modem

link.

Seiko S7600A is also a quality option. This chip would be more involved as

hardware would need to be built which would slow down development time. The

Connect One iChip will also require extra hardware. What is needed for this thesis is

an existing embedded web server not just a TCP/IP stack-in-a-chip. Both the Seiko

S7600A and the Connect One iChip would also be a possibility for further

implementations of the oi2 system as connectivity to a modem would be possible.

Specific hardware could then be designed to utilize the iChip.

The TCP/IP development kit from Rabbit is a good option. It has the required RS-232

and Ethernet interfaces. It also has relatively fast processor, good storage space and

the price is reasonable for the product. This web server is a definite possibility.


15

The web server that stands out is the Picoweb since it is extremely low cost with serial

and network connectivity. The specifications are at a minimum but will be adequate

for the project. This web server will suit the initial proof of concept needed in this

thesis. The storage space on the Picoweb is relatively small so code and web pages

would need to be minimized.

2.3 Pulse Oximeter Technology

In recent years the pulse oximeter has changed shape from a small standalone unit to a

network-able device. With the added functionality comes cost and these systems

quite often use proprietary hardware and software. These are some of the products

that are on the market for remote monitoring of pulse oximeters.

2.3.1 Oxinet II Central Station Network The Oxinet II Central Station Network [14] is a proprietary based pulse oximeter

network for remote monitoring. The Oxinet II has the capacity for 30 patients

connected via a wireless spread spectrum radio link or 16 patients hard wired to the

system. Hardwire connection is achieved by RS-232 or RS-422 links. Only Nellcor

brand pulse oximeters can interface to this system. These record data for ECG, SpO2,

and respiratory rate. This system is available in USA and Europe only. A PC with a

connected UPS logs the data analysis. This system also has an optional printer for

trend and waveform output.

Figure 2-8: Oxinet II Central Station Network. Picture courtesy of Nellcor.


16

2.3.2 TeleOximetry – 3900/3900P Pulse Oximeter

The 3900/3900P Pulse Oximeter from Datex-Ohmeda [16] has remote access

capabilities. A modem attached to the oximeter can dial up and fax data back to the

sleep lab or the oximeter can be accessed from the labs and the stored data can be

downloaded. In addition the 3900/3900P also has RS-232 capabilities to directly

download stored data. Faxed data is presented in an instant report style for easy

diagnosis.

Figure 2-9: 3900/3900P Pulse Oximeter. Picture courtesy of Datex-Ohmeda.

This pulse oximeter also has the added features of an internal printer for fast printing,

24-hour trend memory, analog output, customized patient labels and user savable

defaults. This device can also lock function keys to stop tampering when placed in a

home. The 3900 oximeter is designed for home care and sleep labs performing

overnight oximetry studies.

2.3.3 CSI-TC Wireless Monitoring Station

The Wireless Monitoring Station from Criticare [20] is a portable central station

designed for both inside and outside the hospital. This system is a proprietary based

system that can connect up to 8 multiple parameter portable monitors, printers and

even pagers. Telemetry of data is achieved by a 2.4GHz ISM band RF transceiver

and uses Frequency Hopping Spread Spectrum modulation. This gives a data

throughput of 1Mb/sec. This device is not strictly designed for remote sleep studies

but gives a good indication of the devices available for remote monitoring of medical

equipment. Alarms can be generated and the device will page doctors appropriately.


17

Figure 2-10: Wireless Monitoring Station. Photo is courtesy of Criticare.

2.3.4 Internet Polysomnography

Advanced Medical Electronics Corporation [15] has developed an Internet

Polysomnography device. This device monitors 16 channels including:

!"EEG

!"EOG

!"EMG

!"EKG

!"Pulse oximetry and heart rate

!"Chest effort

!"Airflow

!"Body position

!"Snore

Data is encrypted and transmitted in real time over an Internet connection. The

Internet Polysomnography device has the capability to be used intra-facility over an

Ethernet connection or remote monitoring over a 128kbit/s Internet connection.


18

Figure 2-11: Internet Polysomnography device. Courtesy of Advanced Medical Electronics (AME).

Figure 2-12: Positioned on patient. Courtesy of AME.

As can be seen from Figure 2-11 and Figure 2-12 the device is small and can be

strapped to the chest of a monitored patient.


19

3.0 Results

In the design of the oi2 system, the Picoweb server from Lightner Engineering was

incorporated as the central unit. The Picoweb can be attached to the pulse oximeter

through the serial interface common to both products. The pulse oximeter that is

being used is the Oxypleth Pulse Oximeter from Novametrix. The Picoweb also has

an Ethernet connection so this will be our means of connecting the server to the

Internet. This implementation requires the server to be located on a local area

network with a gateway to the Internet. The new system overview can be seen in

Figure 3-1.

Figure 3-1: System overview

The Picoweb comes with development environment, including utilities to build and

upload CGI scripts, HTML documents, and idle server code. The project is contained

within a project file that includes code and other definitions. The Picoweb server has

no ability for dynamic languages like PHP or ASP so all dynamic content of web

pages needs to be done through CGI, Java applets and possibly Java script. CGI

routines can be written in native AVR assembly or in using the PCODE language.


20

PCODE is a language devised by Lightner Engineering to simply the code on the

Picoweb.

To aid in the implementation of the oi2 system a simulator was written in Visual

Basic. This simulator mimicked the NOVACOM1 Interface on the Oxypleth through

the serial port of a PC.

3.1 Design and Implementation The user interface was implemented as a one level menu. This system is the easiest to

follow and document. The system has the following options:

!"View real time data

!"Retrieve trend data

!"Clear trends

!"Change patient details

!"Check date and time

View Real Time Data brings up a page that looks similar to the front of the pulse

oximeter. Displayed there is the pulse rate, SpO2 and status values which are fed in

real time to the client. This is to enable quick monitoring by medical staff at the

current conditions of the patient. Retrieve Trend Data brings up a graph of the trend

stored in the internal memory of the pulse oximeter. This graph can be used in

conjunction with other PSG information to identify sleep disorders. Clear Trends

option allows the user to clear the internal memory prior to a sleep study. Change

patient details option brings up a form-based web page that allows the user to check

and modify details of the patient. This is to allow the data to be referenced correctly

to the patient. Check Date and Time option allows the user to check that the time is

set correctly on the pulse oximeter.

Figure 3-2 gives an overview of the relationship between html documents, java

applets and CGI scripts. While the implementation of the Java classes are not the

focus of this thesis they are still an important part of the user interface. These applets

are client side software that communicates with the server side CGI routines. They


21

also handle much of the string manipulation that cannot be accomplished easily on the

server.

Figure 3-2: File interaction diagram

3.2 NOVACOM1 Interface Modes

The NOVACOM1 Interface gives access to data from the pulse oximeter and limited

control aspects. The modes of operation that are outlined in the NOVACOM1

specifications are also outlined here with their implementation in this system.

3.2.1 Real time Data Acquisition

The real time mode is defined in the Oxypleth User Manual as “NOVACOM1

Interface Mode 1 – Real Time”. In this mode the saturation values and pulse rate are

continually transmitted at one-second intervals. To initiate the transfer an ASCII ‘1’

is sent to the interface. The Oxypleth responds with an ASCII ‘1’ and immediately

starts transmitting the data. Each data string is in the form of:

MS***P***Z**<cr><lf>

Table 3-1: Real time data format


22

M Event Marker

S Identifier for 3 digit ASCII

SpO2 value

P Identifier for 3 digit ASCII

pulse value

Z Identifier for 2 digit ASCII

status value

Table 3-2: NOVACOM1 mode 1 data

The NOVACOM1 Interface is configured for 9600 baud, 8 data bits, no parity and 1

stop bit. The Picoweb can be configured to suit by setting the baud rate in the project

file definitions. The data bits, parity and stop bits are assumed.

Figure 3-3: Real time mode functional overview

In essence, the real time mode functions with the use of CGI scripts. The interation

can be seen in Figure 3-3. From the main menu page a hyperlink directs the browser

into the real time mode data page. This link isn’t a normal hyperlink to another page

but a link to the CGI script. On execution of the CGI an ASCII ‘1’ is sent to the pulse

oximeter. When the Oxypleth returns with an ASCII ‘1’, the CGI script then redirects

the browser by the use of HTML headers. On the occurrence that the pulse oximeter

does not respond for whatever reason the CGI script will time out and redirect the


23

browser to a time out page. Detailed in this page are some reasons why the time out

occurred so that the user can remedy the problem. It is also possible for the incorrect

response to be echoed back so on this occurrence an error message is produced.

When the CGI receives a response it also sets a flag so that the idle code can start

running. The idle code runs whenever the Picoweb is not processing requests. This

code checks for incoming characters from the pulse oximeter. When the idle code

receives a data string it saves the string into EEPROM. When the client requests the

data string it calls another CGI script. This script retrieves the data string from

EEPROM and returns it to the browser.

The real time mode was tested with the simulator and data that was recorded from a

pulse oximeter during a visit at the hospital. Attaching the pulse oximeter to a PC and

using hyper terminal software the data could be retrieved. The is given below:

-S098P064Z00 -S098P064Z00 -S098P065Z00 -S098P066Z00 -S098P066Z00 -S098P067Z00 -S098P068Z00 -S098P068Z00 -S098P068Z00 -S098P068Z00 -S098P069Z00 -S098P068Z00 -S098P067Z00 -S098P066Z00 -S098P064Z00 -S098P063Z00 -S098P062Z00 -S098P061Z00 -S098P060Z00 -S098P060Z00 -S098P061Z00 -S098P062Z00 -S098P063Z00 -S098P066Z00 -S098P066Z00 -S098P065Z00 -S098P065Z00 -S098P065Z00

Table 3-3: Real time mode test data


24

3.2.2 Trend Data

The trend dump mode of the NOVACOM1 interface is mode 6. In this mode the data

stored in the internal trend memory of the Oxypleth is literally dumped to the serial

interface. To initiate this mode an ASCII character ‘6’ is sent to the Oxypleth. The

Oxypleth responds with an ASCII ‘6’ and immediately starts the dump. This dump

consists of:

Data Records

T**|**|**|**|**|**|**|**|**|**|**|**|**|**|**|**<cr><lf>

Info Records

TFF|**|**|**|**|**|**|**|**|**|**|**|**|**|**|**<cr><lf>

NOTE: The | character is not part of the record. It is merely there

to show the separation between data.

Table 3-4: Trend data format

The info record contains information such as the model code, compression ratio, date

and time, and the upper and lower limits of SpO2 and pulse data. The data record

consists of 8 bytes of SpO2 data and 8 bytes of pulse data. In normal use the trend

dump would consist of an info record followed by 15 data records, repeated until all

the data has been dumped. The data record uses 8 data points per parameter with an 8

second resolution. This gives 64 seconds of data for each data record. Calculating

this for approximately 8 – 10 hours of sleep we have about 12 kilobytes of trend

information. This is too much data to store on the Picoweb’s internal EEPROM so

the data needs to be sent directly to the Internet.


25

Figure 3-4: Trend mode functional overview

Unlike the real time mode the hyperlink on the main menu page is a normal hyperlink.

The functional interaction can be seen in Figure 3-4. From the trend dump page,

which contains a Java Applet, another CGI script is called that retrieves the data from

serial interface and sends it directly to the browser. This process is required to be a

lot quicker than the other CGI scripts so this code was moved out of the serial

EEPROM and into the internal EEPROM of the ATMEL chip. An ASCII ‘6’ is sent

to the pulse oximeter and it then waits for a response. On response of an ASCII

character ‘6’ the CGI routine immediately starts retrieving data and dumping it to the

browser. The transaction can time out just the same as mode 1 to reveal a

troubleshooting page. Also an error message is also produced on unexpected

responses.

Data was recorded at the hospital overnight and the trend was downloaded through

hyper terminal. Table 3-5 is a truncated version of the data. The real data extends for

about 8 hours.


26

TFFFE0208270B150B0A01645AC8300000 T4068282727282726004E4C4D5655524F T26272728282828284F4D4B4D4D4D4D4D T28262525252525264D4F4F4F4F4F4F50 T2829262928282728545355564E50514F T29292828292829294D4F5057564F5150 T29282829282929285154625C56524E4F T29292929292929295759544D4B4D4848 T29292928282828284B4A4B4C4B4D4D4C T282727282828272749474C4A524C4C4F ……………………………………………. T27272727282827274D4E4D4A4A53544A T27272727262727274A4E54494B4E4E4A T27272827272627274B4D4F4B4C4E4E4A T27272727272727274B4B4B4D484C4E4F T2727272727272727564D4B4E4E4F4C52 T2726272727272727514A544B4749494C TFFFC0208271B150B0A01645AC8300000 T27272727272727274F48504B4A49494A T27262727272626274A4B4A4C4A4B4B51 T2727272727272727504E4D4F514D4B4C T272727272727272749494A49494C4B4B T27272727272726264E4D4D4E4F524F4F T2726262626262627564D56534E4D515A T262626262626262652504C4E504E4D4E T26262726262626264F50535A554C4F52 T2626262626262626555655544F4D4C4A T27262626262626264E484A50514F5649 T2626262626262626484C4D574A514347 T26262626272626264A4B4B4E4E46474B T26262626272626264C524C4C55444548 T27272626262627264545494A4C514C42 TFFFC0208272B150B0A01645AC8300000 T262626262626262646494C5144444345 T262626262626262643454A49484A4948 T2626262726262626494B4A474C4B4144 T2626262626262726484A49474C464448 T2626262626262625494A5358494D4755 T2626262626262626474A4644484B4C4B T2626262626262626524747484348494A

Table 3-5: Test trend dump data

3.2.3 General Status Information

Status information is stored in the internal EEPROM of the Picoweb server. This

status information includes the patient’s name, location, identification number, and a

small comment about them. This data is saved onto the Picoweb by a web page


27

designed with text box data entry. The interaction can be seen diagrammatically in

Figure 3-5. The data entry is saved via CGI scripts. These scripts strip the valid

information from the HTML form get request and save it to a location in the

EEPROM. Retrieval of this information is by another CGI that takes the data from

EEPROM and sends it to the browser.

Figure 3-5: Patient details functional overview

The Oxypleth has limited control functions. The only such control accessible through

the NOVACOM1 Interface is a clear trend function. Basically by sending the ASCII

character ‘c’ to the interface the Oxypleth echoes back the character ‘c’ and then

clears the trend memory. The web site has been implemented to prompt for a “Do

you really want to clear trend memory?” warning before the CGI script runs and

clears the trend.

The date and time is stored on the Oxypleth for data records. It can be checked, by

sending the ASCII character ‘d’ to the interface. The date and time is sent back as

and ASCII string in the form of:

d MMM/DD/YY hh:mm:ss<cr><lf>

The leading ‘d’ is the echoed character sent back from the Oxypleth. A CGI script

strips the leading ‘d’ and sends the rest of the date string unaltered.


28

3.3 Final Product As can be seen in Figure 3-6 the final product was housed in a sleek box with costing

of about AU $30. In the bottom left corner of the front panel the power and receiving

light is visible. The green LED is the power and the yellow LED is for receiving.

Figure 3-6: Final product (front view)

The back panel contains the connections to RS-232, Ethernet and power as can be

seen in Figure 3-7. The RS-232 interface connects through a 25pin male D shell

connector. The Ethernet connects with a RJ45 female connector and a standard 6V

plug back supplies the power.

Figure 3-7: Final product (back panel)


29

3.3.1 Displays

When the oi2 system is first accessed the initial web page, shown in Appendix B

Figure 9-1, is displayed. From this page the user can access:

!"Real Time Data

!"Trend Data Graph

!"Date and Time

!"View and change patient details

!"Clear trend memory

!"Online help

At the top of this page the current patients name is displayed for easy identification.

Since the graphics do not affect the functionality of the page these are referenced from

another server. This is to save the already limited space left in the SEEPROM.

By clicking on the “Change Patient Details” hyperlink the page shown in Figure 9-2 is

brought up. At the top of this page the current details are displayed and can be

changed by entering into the text boxes. These text boxes each have a save button

and a reset button. When data is entered into a text box, the save button can then be

pressed to record the data into EEPROM. After the data is saved the page refreshes

so that the new changes are reflected at the top.

The “Check Date and Time” option brings up a simple page shown in Figure 9-4. On

this page the current date and time is represented in the format:

MMM/DD/YY HH:MM:SS

If for some reason communication between the pulse oximeter and the oi2 system

does not occur a timeout error is displayed instead of the date and time. This error is

a hyperlink option to browse the timeout page, shown in Figure 9-6. This timeout

page contains information about possible reasons for the communication breakdown.

When the “Clear Trend” option is selected the clear trend page is displayed. This

page, shown in Figure 9-3, is basically a last chance. Since erasing the trend memory


30

could effectively delete useful data, this last chance page is brought up just in case

selecting the first option was an accident.

If the user wants to view the real time data and select that option the real time page is

brought up. The page is shown in Figure 9-5. The real time data is displayed in a way

characteristic of the front panel of the Oxypleth pulse oximeter. This data is refreshed

once per second and contains information about pulse rate, oxygen saturation and the

status of the oximeter. It is important that the user selects the Stop Real Time Mode

option when exiting this page. This allows the oi2 system to stop the oximeter from

transmitting data. Also visible is the current patient information.

By selecting the “Retrieve Trend Data” option the page shown in Figure 9-7 is

launched. This page displays a graph of the trend data for both oxygen saturation and

pulse rate. Printing from the browser will produce a hard copy of the graph. The

margins should be changed in the print options to 0.2” for best results.

For ease of use an online help section has been included. This section is a page

containing comprehensive information about each option available and also

troubleshooting. This page is stored on another web server as the information stored

is far too large. When the help option is selected a new browser window is brought

up.


31

3.3.2 In Practice By setting up the system in the Mater Children’s sleep unit the data from the pulse

oximeter can be accessed across the local area network. As you can see from Figure

3-8 the system is small enough to be placed out of the way in the same room.

Figure 3-8: oi2 system operating in the sleep unit

Staff can easily set up the system by connecting the pulse oximeter to the oi2 system,

connecting the system to the network and turning the power on. Communication can

begin when the pulse oximeter is placed in the correct mode.

Figure 3-9: Staff can easily set up the oi2 system


32

4.0 Discussion Early in the design process it was decided that the oi2 system device needed to be

small, robust and inexpensive relative to the pulse oximeter. These design parameters

make sense because the oi2 system will be portable and possibly knocked around.

Pulse oximeters generally range in price from $1000 to $10,000 so the Picoweb server

was a good choice in relation to cost, being less than 10% of the lower end.

The Picoweb is an extremely small web server that makes all the better choice. As

can be seen from the picture of the oi2 system in Figure 3-6 the Picoweb was housed

in a small metal case. The serial and network interfaces along with power were

situated at the back of the device. It is intended that the oi2 system reside on top of

pulse oximeter with cables connected at the back.

To be totally robust the device needs to be simple to use and error free. In

implementing the user interface as many possible combinations of incidents were

introduced and these were included in the design. Some of these incidents include

disconnection of the any of the cables during transmission, incorrect setup and loss of

power. The user interface was also made to be simple with a one level menu system

and an online help. This online help system was implemented on an external web

server due to tight restrictions of storage space on the Picoweb server. It was decided

that to have a comprehensive online help was a valuable feature but it was not

possible to store that much information in the 32kbytes of serial EEPROM. This also

gives light to why the Internet is a good choice for transmission medium as the online

help can be easily stored on another server and a linked made to it.


33

4.1 Implementation Issues

This section outlines the problems faced when implementing the system and how they

were overcome.

4.1.1 Real time Data Acquisition

The real time data mode was implemented in such a way so as to allow easy

connectivity to a Java applet. The applet can call the CGI script to get the data.

Whenever the CGI script is called it will return a complete data string. The idle loop

code could have been implemented so that it receives one character at a time and

saves it to EEPROM. This would allow the server to process requests whilst

receiving the data string and had detrimental results. It would then be possible for the

data string to be only half completed when the CGI script was called returning a half

valid string and possibly extra corrupt data. As it is implemented control is not passed

back to the kernel until the end of line character is received and the data is saved.

This implementation also poses another problem. If the pulse oximeter for some

reason were disconnected from the oi2 system then the idle code would become fixed

in an infinite loop. The web server would effectively stop responding. To fix this

problem a time out feature was added to the loop code. In this way if the pulse

oximeter started to send data and then was disconnected before the end of line

characters was sent, then the oi2 system would time out and break from the loop.

Included in the NOVACOM1 Interface is a mode 4, which is a SpO2 waveform mode.

This mode outputs the same data as real time mode every second but also includes

SpO2 waveform data that is output 50 times per second. Originally it was intended to

implement this feature so that the output onscreen had the appearance of the front

panel but it was soon realized that there was a few problems. The Picoweb is not

powerful enough to retrieve that much data from the serial port and also process

requests. In testing the Picoweb would stop responding and need to be reset. It was

decided that this feature was not as important as some of the others as was not

implemented.


34

4.1.2 Trend Data

Whilst implementing the trend dump feature it was found that the Picoweb could not

keep up with retrieving the data from the serial port and sending it to the browser.

Certain characters were dropped and it generally behaved in an odd fashion. To fix

this problem the CGI script was brought out of serial EEPROM and placed into the

internal EEPROM of the Picoweb. Whilst in the serial EEPROM each instruction

was retrieved serially which proved to be a slow process. By placing the code into the

EEPROM the execution time was dramatically increased and the CGI was able to

cope with the amount of data.

The lack of processing power was the cause of another problem with the

implementation. It was found that the first couple of lines of data were being

corrupted during transmission. This was because the original implementation was

similar to the real time mode in the way the mode was started. One CGI started the

mode and redirected the browser and another CGI retrieved all the characters and sent

them to the browser. The extra processing in between starting the mode and

retrieving the data caused the corruption.

4.1.3 General Status Information

The status information that is saved to EEPROM utilizes four forms that call a CGI

script for each parameter. In a normal web server this could have been implemented

with four text fields in one form. On the Picoweb it was found that the length of the

parameters to the CGI script was a limited length. The length of the data was

shortened further, by a dodgy memory location. This was in the position where the

URL parameters were saved. Since the URL parameters include the name of the CGI

script, the name length was increased so that the data would never be placed on this

section. This is not something that would need to be taken care of if another Picoweb

server was used. This seems to be a one off imperfection. This final size of each of

the data fields is 20 characters long. It was decided that this was sufficient for this

implementation.


35

The limited control aspect to the NOVACOM1 Interface poses a limitation on the oi2

system. While the user can clear the trend remotely which would be done prior to a

sleep study, the date and time cannot be altered remotely. This limits the

effectiveness of the user being able to set the system up remotely for a night study. It

is all well and good having accurate data if the times do not match. This makes

comparison with other measurements difficult at best.

4.2 Review of Available Systems

As far as transmission mediums go the Internet is a relatively new concept. Even

though it is new there is already an extensive worldwide network installed. Along

with the fact that the Internet is an inexpensive medium makes it a more the

interesting prospect. Most medical instruments with remote access utilize proprietary

protocols over some type of medium. This means that the equipment at the other end

needs to also use the proprietary methods, which makes the system inflexible to the

needs of hospitals and sleep units. The Oxinet II uses a proprietary protocol over a

RF link. The remote pulse oximeters also require having the RF interface so in

purchasing the Oxinet II system, a hospital is locked into buying pulse oximeters from

the same company. The CSI-TC Remote Monitoring Station is in the same boat as it

also connects through a proprietary RF link.

It is very common for a pulse oximeter to have a RS-232 interface so that data can be

uploaded to a PC. Having a small device that can attach to this interface and connect

the pulse oximeter to the Internet overcomes this drawback. A device implemented

with sufficient support can be attached to just about any make and model of pulse

oximeter to interface it to the Internet. The Internet Polysomnography device utilizes

the Internet as well but it incorporates all the instruments into one. This is the same

drawback where there is no freedom to use an instrument of particular specifications.

Sleep studies performed on children require very sensitive equipment. A childs

oxygen saturation level can drop quite low and then back up quite quickly. A lot of

pulse oximeters do not record this because there trend data is sampled at too low a

rate with averages taken. The hospital needs to use the equipment that can cope with

the work so by implementing a system in which the pulse oximeter is completely


36

independent is obviously advantageous. This also takes the pressure of the hospital

when they are upgrading to newer or different models.

A common feature that is lacking in some of the available remote monitoring devices

is real time data access. Real time access allows an observer to watch the results as if

they were in the room with the patient. The 3900/3900P Pulse Oximeter’s dial up

interface and is a good example of a device without real time access. Not having this

makes it hard for the medical staff to check up on the results. They have to ring up

especially and download all the data.

Something else that is common to most remote monitoring devices is expense.

Companies charge quite high prices for their proprietary systems. By making them

proprietary they have guaranteed themselves more sales of other devices to work with

the system. While this is good for the company, it is not beneficial to the hospitals

that have to bear the extra expense. The oi2 system overcomes this problem as it uses

an interface that is common to many pulse oximeters available.

4.3 Effectiveness of Design

The oi2 system is whilst still being a functional remote monitoring device is actually

more of a proof of concept. All the basic features required for a successful remote

monitoring project have been implemented with some minor limitations. The

Picoweb was a good choice of web server in regards to cost, size and quick set up

time but lacked some of the features that other more expensive embedded web servers

have. The main lacking feature was processing power. Whilst most of the needs of

processing power were worked around there still are some issues with the design. As

a web enabled device it is possible that two or more browsers connect to the server at

once. The Picoweb is able to support multiple browsers but often falls over when

given a couple of requests. This is a limitation of the device as a remote monitoring

device as it hinders the ability of two colleagues to confer about results when they are

in different locations. This is one of the reasons for choosing the Internet as a

transmission medium. As an initial device the Picoweb was a good choice but it may

not cope with further work.


37

Apart from the minor limitations the device whose main connection is by Ethernet is

an effective remote monitoring tool for in hospital sleep studies. The oi2 system can

be accessed from any computer on the local hospital network to download data from

say another ward. As demonstrated at the Mater Children’s Department of

Respiratory Medicine, the oi2 system performed as expected.

The effectiveness of the oi2 system is limited in relation to the larger scheme of the

Internet. Other issues need to be addressed such as security and different Internet

connections to provide true remote access.

4.4 Commercial Viability

In the general population about 4% [2] of men and 2% [2] of women incur significant

obstructive sleep apnea. Given the population of Queenland it is not hard to calculate

the number of people is quite high. Sleep apnea is only one of the many sleep

disorders in which a person could have. From this we can conclude that there are a lot

of people in Australia that have sleeping disorders and are in need of an overnight

sleep study to diagnose their problem. At present there is about 100 sleep units

around Australia. This figure has grown rapidly in recent years. All these people

needing sleep studies has given rise to the supply and the cost. A remote access

system provides a means of expanding the sleep unit from 5 beds confined to the

hospital to a large number of beds in homes around Australia. This number is only

limited by the unit cost of such a device and the scope of area in which the device can

be transported to. This system is commercially viable because of this demand for the

service.

The total cost of parts for the oi2 system comes to approximately AU $180. Adding

on labour costs and including mark up the unit is still extremely cheap in comparison

to other systems on the market. Other proprietary systems are often priced at tens of

thousands of dollars. Given that there is a definite market for this product and the

system can be produced and sold for low price this product is commercially viable.


38

5.0 Future Work In developing the oi2 system project certain limitations were found in the current

implementation. Outlined here are these and some grander ideas for the future of

remote monitoring of medical equipment for sleep medicine.

5.1 Support for other devices As an added feature this system would benefit from having support for pulse

oximeters other than the Oxypleth from Novametrix. Due to the size restrictions in

place on the Picoweb this feature would need to be implemented as a firmware

update. Firmware is meant to include the CGI scripts placed on the Picoweb that

communicate with the pulse oximeter. In implementing this feature a broader range

of products can be used with this system. This helps many hospitals, as they will not

have to buy all new pulse oximeters when installing the remote monitoring system,

therefore reducing cost and hassle. Also when a hospital decided to upgrade its

current hardware to newer models the whole system does not need to be replaced. A

cost effective firmware update will be all that is needed.

As well as support for other pulse oximeters it would also be important to include

support for devices other than pulse oximeters. This includes any of the devices used

in a polysomnography study, which include but are not limited to:

!"Electroencephalography (EEG)

!"Electro-oculography (EOG)

!"Electrocardiography (ECG)

!"Electromyography (EMG)

!"Airflow

!"Respiratory effort

!"Sound recordings to measure snoring

!"Video monitoring of body positions

!"Core body temperature

Especially interesting devices to include are the sound and video monitoring

equipment. Support for devices such as these are already springing up with

equipment such as web camera’s that come packaged with some PCs. Also web

servers have already been installed in devices such as these in coastal regions to view


39

the surf conditions. As mentioned in the literature review these surf cameras are in

place all round the world so access to resources is by no means limited.

5.2 Different Internet Connections The current system utilizes an Ethernet connection to access the Internet. The oi2

system becomes part of the local area network and a gateway is required for Internet

access. This model suits the hospital location as a preexisting LAN is in place in

which all their PCs are attached. By attaching the oi2 system to this LAN it can be

accessed by any computer in the internal network. The data is made secure by the

gateway and firewall that protect the internal network from the Internet. The system

can also be access remotely from another hospital by connecting it to its LAN and

accessing it by the Internet. This has issues with security but is also another avenue

for further work.

As explained in the introduction there are benefits to sleep studies performed in the

home. Children sleep better in their own home mostly because they feel safe as well

as they are familiar with the colours, noise, and smells of their own bedroom. To

perform sleep studies in this sort of location requires a different approach. Most

households don’t have a local area network running through them with a gateway to

the Internet. Most Internet access in homes is via a MODEM and a telephone line.

An increasing amount of private homes have cable Internet access in which they have

a cable MODEM. To operate the oi2 system under such conditions access to these

types of connections need to be implemented.

The Picoweb provides no direct method of implementing other transmission mediums

so another embedded web servers would need to be looked at to implement this

feature. An example would be the Netburner that already has a second serial

interface. The Netburner also provides the PPP protocol that is needed for dial in

access to the Internet.

The extra feature provides the necessary connection to allow remote monitoring to

occur in a home situation. This also applies to a rural hospital situation where a local

area network does not exist or is not connected to the Internet. Dial up access would

allow for remote studies to occur.


40

Figure 5-1: Satellite Implementation. Diagram courtesy of Ben Lever.

Extending this idea remote studies could be further enhanced by implementing a bi-

directional satellite link. It is becoming common practice to receive downstream data

in the form of high-speed satellite connection through the means of a satellite dish.

Upstream data, in Australia anyway, has been limited to the slower modem

connection. In the USA it is becoming possible to receive and transmit data through a

bi-directional satellite dish. This sort of connection would enhance the sleep studies

as even more remote locations could be serviced. It would be possible to set up a

mobile station, which could travel between rural towns and perform sleep studies.

Data could then be uploaded to a central database at a base station and the mobile

station could move to a new area.

5.3 Security Medical records and medical data is a sensitive area for most people. As the system is

implemented now the oi2 system transmits data across an internal LAN. This LAN is

protected from prying eyes by a firewall, which disallows unauthorized incoming

connections. For this reason security was not a large issue when implementing the oi2

system. For this system to become a true remote monitoring device the need for

security arises as transmission across the Internet is open to hackers and the like.

While not really possible on the Picoweb server, security features such as

authorization and encryption would be essential in providing remote access. The

Internet provides such security through the implementation of Secure Sockets Layers


41

or SSL. An embedded web server would need to be chosen with such capabilities.

This would increase overhead and processing at the embedded web server so a more

powerful unit would be required.

Another consideration when introducing further work should be the problems incurred

by hackers such as a denial of service attacks. Response to and impact of viruses

similar to Code Red need to be considered. This problem is not really an issue with

embedded Internet at the moment as the main targets are more mainstream web

servers. By running well-known real time operating systems such as embedded linux

or μC/OS II the likelihood of an attack is increased. This problem is forever ongoing

with the development of new techniques and viruses so a method of updating the

security would need to be in place.

5.4 Remote Firmware Updates Related to the connectivity of the oi2 system to devices other than a pulse oximeter or

pulse oximeters of multiple brands is the need to update the firmware. Since the

firmware contributes the communications between the instrument and the web server

a different firmware would be available for each type of instrument and vendor.

Utilization of the Internet as a method for easily updating the firmware is possible and

also quite appropriate. This feature would simplify the transition between models of

pulse oximeters and could be performed by some one at the hospital rather than a

technician. This would also reduce cost and down time providing for a much simpler

system. The transition would also be transparent from user as they would merely

follow a link on a web page either located on the embedded web server or a central

web server that are both accessible via the Internet.

5.5 Multi-user Multi channel System In performing sleep studies more than one parameter is recorded over a night. Given

that the system has the capabilities to be extended to other devices, which was

discussed earlier, the system needs to be integrated so that all the devices are fed back

to the one place. This enables the medical staff to view all the data from a range of

instruments. This data should of course be time stamped to allow easy correlation

between say the audio of someone snoring and the oxygen saturation decaying. All

this data would need to be logged in a central database so that old records can be


42

viewed and comparisons drawn. This database would need to include patient

information and data from multiple nights for ongoing studies.

In any given night in a sleep unit there will be more than one person under

observation. It makes sense, therefore, to incorporate into the system a method of

retrieving data from multiple patients simultaneously. This would probably consist of

one remote unit for each patient transmitting data back to a central database for

storage.

An advantage to remote monitoring sleep studies is that medical personnel can confer

with colleagues and both be viewing the same set of data whilst in different locations

be it different cities or different countries. When the system has more control over the

instruments that it monitors a multi-user model would need to be used. In this model

access would be logged to monitor what has been done and also permission set

accordingly. It may be necessary to give access to view the data but not give access

to control the instrument. An example of this would be you only want one person to

be able to clear the trend to start the sleep study as they are looking after that sleep

study. Other people may want to view the results but should not be given the access

to clear the data. With the multi-user system comes security, which was discussed

earlier. Authorization would be necessary to ensure the correct user had control. It

may also be necessary to lock the control over an instrument. More than one person

may have permission to control the device but if one person is doing something with

it then the second person should not be able to access any control functions.

Figure 5-2: Multiple Patient Scenario. Diagram courtesy of Ben Lever.


43

6.0 Conclusion

The Oximeter Internet Interface system was developed and is able to stream real time

SpO2 and pulse rate data to an Internet browser. This data is displayed in a manner

that is characteristic of the front panel of the Novametrix Oxypleth pulse oximeter.

The system can also download the trend data from the pulse oximeter’s internal

memory and display this in a graph that can be printed and used in the diagnosis of

sleep disorders. Implemented with web pages the system follows an easy to use one

level menu and also includes an online help page.

This system was implemented so that it can operate intra-facility through the internal

local area network. For full remote access capabilities some of the ideas discussed in

future work need to be employed. Full remote access through the Internet will bring a

cost effective solution to the problems involved with the current practices of sleep

studies. This will effectively increase the number of beds available for overnight

observations and increase the throughput of patients further towards the demand.

Furthermore, from the positive response from the staff at the Mater Children’s

Department of Respiratory Medicine and the discussion into the feasibility of a

commercially available product it can be concluded that this project is viable and

worthy of further development.


44

7.0 References 1. J. Garcia, L. Wills, “Sleep disorders in children and teens: helping patients and

their families get some rest”, Postgraduate Medicine, Vol. 107, No. 3, pp. 161-

178, Mar. 2000.

2. M.W. Mahowald MD, “What is causing excessive daytime sleepiness?”,

Postgraduate Medicine, Vol. 107, No. 3, pp.108-123, Mar. 2000.

3. D.M. Anderson, Dorland’s Illustrated Medical Dictionary, 29 Ed., W.B. Saunders

Company, 2000.

4. E. Hill, M.D. Stoneham, “Practical Applications of Pulse Oximetry”, World

Federation of Societies of Anaesthesiologists, Issue 11, Article 4, 2000.

5. Novametrix Medical Systems Inc., “OXYPLETH User’s Manual Rev.02”, pp. 55-

58, 1995.

6. emWare, “Mastushita and emWare Deliver Remote Care Monitoring”,

http://www.emware.com/company/success%20stories/MEW%20Success%20Stor

y.asp, 2001.

7. “Obstructive Sleep Apnoea”, Newcastle Sleep Disorders Centre,

http://www.newcastle.edu.au/department/md/sleep/apnoea.htm, 2001.

8. P.J. Dunne, P. Minkley, “Pros and Cons of Home Sleep Studies”, RT Magazine,

Apr. 1, 2000.

9. NetBurner, “Netburner Standard Hardware Platforms”,

http://www.netburner.com/hardware_platforms.html, 2001

10. NetBurner, “Pricing Information”, http://www.netburner.com/pricing.html, 2001

11. Lightner Engineering, “PicoWeb”, PicoWeb Home Page,

http://www.picoweb.net/, 2001.

12. ConnectOne, “Connect One Home Page”, http://www.connectone.com/, 2001.

13. L.S. Wilson, I.F. Sharp, R.W. Gill, S.A. Heitmann, C.F. Chen, M.J. Dadd, A.

Kajan, M. Gunaratnam, E. Tam, “The Hospital Without Walls – Home Telecare

using Vital Signs Monitoring”

14. Nellcor, “Oxinet II Central Station Network”,

http://www.nellcor.com/products/index.asp, 2001.

15. Advanced Medical Electronics Corporation, “Internet Polysomnograph”,

http://www.ame-corp.com/Internet_Polysomnograph.htm, 2001


45

16. Datex-Ohmeda, “3900/3900P Pulse Oximeter”, http://www.datex-

ohmeda.com/products/monitoring_3900po.htm, 2001.

17. Hewlett Packard, “HP Brings the Power of the Internet to Printing”,

http://www.hp.com/hpinfo/newsroom/press/20mar01a.htm, Mar. 20, 2001

18. Seiko Instruments, “S-7600A Series iChip TCP/IP Protocol”, http://www.seiko-

usa-ecd.com/intcir/products/rtc_assp/s7600a.html, 2001

19. Rabbit Semiconductor, “Rabbit 2000 TCP/IP Development Kit”,

http://www.rabbitsemiconductor.com/products/rab20_tcpip/rab20_tcpip_devkit.ht

ml, 2001

20. Criticare System Inc., “Products”, http://www.csiusa.com/csitc.html, 2001


46

8.0 Appendix A

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71

//------------------------------------------------------------- // // PicoWeb Project File for PULSE OXIMETER WEB INTERFACE // //------------------------------------------------------------- // DEFINE CONSTANTS #define EEPROM_IP /*use file "ip" for IP address*/ #define ENABLE_WATCHDOG /* enable watchdog */ #undef DEBUGGER /* disable debugger */ #define NO_ETHER_ADDR_ON_BOOT /* no MAC displayed on reset */ #define CLOCK 7372000 /* processor clock rate (Hz) */ #define BAUD_RATE 9600 /* serial port baud rate */ #define TIMEOUT_DELAY 1000 /* delay used for timeout */ #define WEB_BLINK_LED /* will blink PicoWeb LED */ #define START_EEPROM 32 /* beginning of useable eeprom */ #define HTTP_REDIRECT "HTTP/1.1 302 Found\r\n" #define TIMEOUT_PAGE "Location: /timeout.htm\r\n\r\n\r\n" #define START_PAGE "Location: /oxinet.htm\r\n\r\n\r\n" #define PATIENT_PAGE "Location: /patientdetails.htm\r\n\r\n\r\n" #define GETDATA_PAGE "Location: /realtime.htm\r\n\r\n\r\n" #define REQ_TIMEOUT "<p align="center">Request has timed out<a href=\"/timeout.htm\"> Click Here</a> </p>" #define UNRECOG_RESP "<p>Error: Unrecognized Response<a href=\"/oxinet.htm\">Click Here</a> to return to main menu</p>\r\n" #define APPLET_TIMEOUT_TAG "E1" #define APPLET_UNRECOG_RESP_TAG "E2" // define data locations for mode 4 SpO2 waveform. Two seconds of data stored. #define RESET START_EEPROM + 96 #define PATIENT_NAME START_EEPROM + 100 #define PATIENT_ID START_EEPROM + 120 #define PATIENT_LOC START_EEPROM + 140 #define PATIENT_COM START_EEPROM + 160 // HTML code & JAVA classes oxinet.htm realtime.htm // data retrieval patientdetails.htm // Store Patient Details on Picoweb checktime.htm // returns current time trenddump.htm timeout.htm // time out error screen clear.htm // clears internal trend memory PulseOximeter.class // Pulse Oximeter class PicoDataIF.class // Picoweb interface class DataStripperRealTime.class // data stripping class TrendDump.class TrendData.class DataStripperDump.class // CGI routines erasepatientinfo.cgi data.cgi // returns data stored in eeprom start_mode1.cgi // start the pulse oximeter stop_mode.cgi // stop the pulse oximeter cleartrends.cgi // clear trend memory of pulse oximeter datetime.cgi // check current date and time stored on oximeter savepatientname.cgi // store patient details on picoweb savepatient__id.cgi


47

72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148

savepatient_loc.cgi savepatientcomm.cgi patientname.cgi // retrieve patient name patientid.cgi // retrieve patient id patientloc.cgi // retrieve patient location patientcom.cgi // retrieve comments about patient getserialdata.cgi #avr_reset .data hit_count:: .word 0 ; will reset with this value .text ser r16 ; pull-up on port B inputs out portb,r16 #ifdef WEB_BLINK_LED #define LED_ON cbi portd,LED_BIT /* turn LED on */ #define LED_OFF sbi portd,LED_BIT /* turn LED off */ #define PLED_ON pledon /* turn LED on with pcode */ #define PLED_OFF pledoff /* turn LED off with pcode */ .text sbi DDRD,LED_BIT ; make LED driver pin an output LED_OFF ; turn LED off #else /* !WEB_BLINK_LED */ #define LED_ON #define LED_OFF #define PLED_ON #define PLED_OFF #endif /* !WEB_BLINK_LED */ #avr_slow #avr_fast ;-------------------------------------------------------------------------- ; FAST LOOP CODE ;-------------------------------------------------------------------------- .cseg #define SCRAP buf #define PTR2 buf + 1 #define LEN2 buf + 3 #define STR2 buf + 4 pbegin pee2s SCRAP, START_EEPROM, 1 ; check mode so that idle loop code can execute pcmpbi SCRAP, '1' pjumpeq mode1 pjump theend ; otherwise skip code mode1: pmovwi PTR2, STR2 pmovbi LEN2, 0 pser_getc [PTR2] ; once first char recieved collect the rest of line pjumpeq theend pledon


48

149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 222 223 224 225 226

getcharloop: pincw LEN2 pincw PTR2 psgetcto [PTR2], PSGETCTO_MSECS(TIMEOUT_DELAY) pcmpbi [PTR2], 10 pjumpne getcharloop pledoff pmovbi [PTR2], 0 pincw LEN2 pincw LEN2 ps2ee START_EEPROM + 1, LEN2, [LEN2] ;store in eeprom theend: pend #avr_asm .cseg #ifdef WEB_BLINK_LED .global pledon pledon: pcode_routine 0 LED_ON ret .global pledoff pledoff: pcode_routine 0 LED_OFF ret ledon:: pledon pret ledoff:: pledoff pret #else /* !WEB_BLINK_LED */ ledon:: pret ledoff:: pret #endif /* !WEB_BLINK_LED */ .eseg ; --------------------------------------------------------------------; ; CGI routines -- control functions of the Pulse Oximeter. ; ; --------------------------------------------------------------------#define EEPROM_ADDR buf+16 #define RESET_ADDR buf+17 #define BEG_POINTER buf+18 #define POINTER buf+20 #define CH buf+22 ;--------------------------------------------------------------------- ; Start real time mode 1 by sending ascii character '1' to the


49

227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302

; oximeter. If no reponse then redirect to timeout page otherwise ; are response redirects to the realtime page. ;--------------------------------------------------------------------- start_mode1: ; send char '1' to pulse oximeter pser_putc '1' psgetcto CH, PSGETCTO_MSECS(TIMEOUT_DELAY) pjumpne check1 pprint HTTP_REDIRECT pprint TIMEOUT_PAGE pjump done1 check1: pcmpbi CH, '1' pjumpeq redirect1 pprint UNRECOG_RESP pjump done1 redirect1: pwreebi START_EEPROM, '1' pprint HTTP_REDIRECT pprint GETDATA_PAGE done1: pret ;---------------------------------------------------------------- ; Stop mode ;---------------------------------------------------------------- stop_mode: ; send char 'x' to pulse oximeter pser_putc 'X' psgetcto CH, PSGETCTO_MSECS(TIMEOUT_DELAY) pjumpne check2 pprint HTTP_REDIRECT pprint TIMEOUT_PAGE pjump done2 check2: pcmpbi CH, 'x' pjumpeq redirect2 pprint UNRECOG_RESP pjump done2 redirect2: pwreebi START_EEPROM, 'S' pprint HTTP_REDIRECT pprint START_PAGE done2: pret ;---------------------------------------------------------------------; Clear oximeters internal memory by sending a ascii character 'c'. ; If no reponse then redirects to timeout pages otherwise a response ; causes the web page to be redirected to the main page. ; Need to implement a "do you really want to do this? yes/no"! ;--------------------------------------------------------------------- cleartrends: ; send char 'c' to pulse oximeter pser_putc 'c' psgetcto CH, PSGETCTO_MSECS(TIMEOUT_DELAY) pjumpne check3 pprint HTTP_REDIRECT pprint TIMEOUT_PAGE pjump done3 check3: pcmpbi CH, 'c' pjumpeq redirect3 pprint UNRECOG_RESP pjump done3 redirect3: pprint HTTP_REDIRECT pprint START_PAGE done3:


50

303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379

pret ;---------------------------------------------- ; Retrieves the date and time stored on the ; oximeter by sending an ascii character 'd'. ; If no reponse then timeout option available ; otherwise displays the date and time. ;---------------------------------------------- datetime: ; send char 'd' to pulse oximeter pser_putc 'd' psgetcto CH, PSGETCTO_MSECS(TIMEOUT_DELAY) pjumpne check4 pprint REQ_TIMEOUT pjump done4 check4: pcmpbi CH, 'd' pjumpeq redirect4 pprint UNRECOG_RESP pjump done4 redirect4: psgetcto CH, PSGETCTO_MSECS(TIMEOUT_DELAY) pcmpbi CH, 13 pjumpeq done4 pputcb CH pjump redirect4 done4: psgetcto CH, PSGETCTO_MSECS(TIMEOUT_DELAY) pret ;--------------------------------------- ; Saves the patient name entered into ; a one-line text box. ;--------------------------------------- savepatientname: pmovwi POINTER, url_parms paddwi POINTER, 8 findname: pincw POINTER pcmpbi [POINTER], '=' pjumpne findname pincw POINTER pmovw BEG_POINTER, POINTER nextcharloop5: pincw POINTER pcmpbi [POINTER], '&' pjumpne nextcharloop5 pmovbi [POINTER], 0 ps2ee PATIENT_NAME, [BEG_POINTER] , 20 pmovbi CH, 0 ps2ee RESET, CH, 1 pprint HTTP_REDIRECT pprint PATIENT_PAGE pret ;-------------------------------------- ; Saves the patient id number entered ; into a one-line text box. ;-------------------------------------- savepatient__id: pmovwi POINTER, url_parms paddwi POINTER, 8 findid: pincw POINTER pcmpbi [POINTER], '=' pjumpne findid pincw POINTER pmovw BEG_POINTER, POINTER nextcharloop6: pincw POINTER pcmpbi [POINTER], '&'


51

380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456

pjumpne nextcharloop6 pmovbi [POINTER], 0 ps2ee PATIENT_ID, [BEG_POINTER] , 20 pmovbi CH, 0 ps2ee RESET+1, CH, 1 pprint HTTP_REDIRECT pprint PATIENT_PAGE pret ;--------------------------------------- ; Saves the patient location entered ; into a one-line text box. ;--------------------------------------- savepatient_loc: pmovwi POINTER, url_parms paddwi POINTER, 8 findloc: pincw POINTER pcmpbi [POINTER], '=' pjumpne findloc pincw POINTER pmovw BEG_POINTER, POINTER nextcharloop7: pincw POINTER pcmpbi [POINTER], '&' pjumpne nextcharloop7 pmovbi [POINTER], 0 ps2ee PATIENT_LOC, [BEG_POINTER] , 20 pmovbi CH, 0 ps2ee RESET+2, CH, 1 pprint HTTP_REDIRECT pprint PATIENT_PAGE pret ;---------------------------------------- ; Saves the comments about the patient ; entered into a one-line text. ;---------------------------------------- savepatientcomm: pmovwi POINTER, url_parms paddwi POINTER, 8 findcom: pincw POINTER pcmpbi [POINTER], '=' pjumpne findcom pincw POINTER pmovw BEG_POINTER, POINTER nextcharloop8: pincw POINTER pcmpbi [POINTER], '&' pjumpne nextcharloop8 pmovbi [POINTER], 0 ps2ee PATIENT_COM, [BEG_POINTER] , 20 pmovbi CH, 0 ps2ee RESET+3, CH, 1 pprint HTTP_REDIRECT pprint PATIENT_PAGE pret ;------------------------------------ ; Returns patients name ;------------------------------------


52

457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 522 523 524 525 526 527 528 529 530 531 532 533

patientname: pee2s CH, RESET, 1 pcmpbi CH, 255 pjumpne getname pprint "Not Set" pjump nameend getname: pee2s CH, PATIENT_NAME, 20 pmovwi POINTER, CH nextcharloop1: pcmpbi [POINTER], '+' pjumpne notspace1 pmovbi [POINTER], ' ' notspace1: pputcb [POINTER] pincw POINTER pcmpbi [POINTER], 0 pjumpne nextcharloop1 nameend: pret ;------------------------------------ ; Returns patients id number ;------------------------------------ patientid: pee2s CH, RESET + 1, 1 pcmpbi CH, 255 pjumpne getid pprint "Not Set" pjump idend getid: pee2s CH, PATIENT_ID, 20 pmovwi POINTER, CH nextcharloop2: pcmpbi [POINTER], '+' pjumpne notspace2 pmovbi [POINTER], ' ' notspace2: pputcb [POINTER] pincw POINTER pcmpbi [POINTER], 0 pjumpne nextcharloop2 idend: pret ;---------------------------------- ; Returns patients location ;---------------------------------- patientloc: pee2s CH, RESET + 2, 1 pcmpbi CH, 255 pjumpne getloc pprint "Not Set" pjump locend getloc: pee2s CH, PATIENT_LOC, 20 pmovwi POINTER, CH nextcharloop3: pcmpbi [POINTER], '+' pjumpne notspace3 pmovbi [POINTER], ' ' notspace3: pputcb [POINTER] pincw POINTER pcmpbi [POINTER], 0 pjumpne nextcharloop3


53

534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609

locend: pret ;----------------------------------------------- ; Returns comments about patient ;----------------------------------------------- patientcom: pee2s CH, RESET + 3, 1 pcmpbi CH, 255 pjumpne getcom pprint "Not Set" pjump comend getcom: pee2s CH, PATIENT_COM, 20 pmovwi POINTER, CH nextcharloop4: pcmpbi [POINTER], '+' pjumpne notspace4 pmovbi [POINTER], ' ' notspace4: pputcb [POINTER] pincw POINTER pcmpbi [POINTER], 0 pjumpne nextcharloop4 comend: pret ;----------------------------------------------- ; Erase all patient info ;----------------------------------------------- erasepatientinfo: pmovbi CH, 255 ps2ee RESET, CH, 1 ps2ee RESET+1, CH, 1 ps2ee RESET+2, CH, 1 ps2ee RESET+3, CH, 1 pprint HTTP_REDIRECT pprint PATIENT_PAGE pret ;--------------------------------------------------------- ; CGI routine - returns all data from the serial port. ; (used in mode 6 trend dump mode) ;-------------------------------------------------------- .cseg getserialdata: ; send char '6' to pulse oximeter pser_putc '6' psgetcto CH, PSGETCTO_MSECS(TIMEOUT_DELAY) pjumpne check5 pprint APPLET_TIMEOUT_TAG pjump done5 check5: pcmpbi CH, '6' pjumpeq redirect5 pprint APPLET_UNRECOG_RESP_TAG pjump done5 redirect5: pwreebi START_EEPROM, '6' pledon next5: psgetcto buf, PSGETCTO_MSECS(TIMEOUT_DELAY) pjumpne print5 pjump done5


54

610 611 612 613 614 615 616 617 618 619 620 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649

print5: pputcb buf pjump next5 done5: pledoff pret ;-------------------------------------------------------------- ; CGI routine - reads data from eeprom into sram then prints it ; out to browser (used in mode 1 real time mode) ;-------------------------------------------------------------- data: pcall print pret .cseg #define PTR buf #define LEN buf + 2 #define STR buf + 3 print: pmovwi PTR, STR pee2s LEN, START_EEPROM + 1, 1 pee2s STR, START_EEPROM + 2, [LEN] loop: pcmpbi [PTR], 0 pjumpeq out pputcb [PTR] pincw PTR pjump loop out: pret


55

9.0 Appendix B

Figure 9-1: Screen shot of main menu page


56

Figure 9-2: Screen shot of patient details page

Figure 9-3: Screen shot of clear trend page

Figure 9-4: Screen shot of date and time page


57

Figure 9-5: Screen shot of real time page

Figure 9-6: Screen shot of time out page


58

Figure 9-7: Screen shot of trend dump page

Figure 9-8: Screen shot of the online help page

thesis

Documents

mater childrens

advanced medical

core body

simplified

obstructive

urlparms paddwi

perform sleep

wireless monitoring