Thesis

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
Kings 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
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 Childrens 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.
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.
ii
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 Childrens 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.
iii
TABLE OF CONTENTS ACKNOWLEDGEMENTS......................................................................................... I ABSTRACT ................................................................................................................ II 1.0 2.0 INTRODUCTION............................................................................................1 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
iv
5.4 REMOTE FIRMWARE UPDATES ........................................................................... 41 5.5 MULTI-USER MULTI CHANNEL SYSTEM ............................................................. 41 6.0 7.0 8.0 9.0 CONCLUSION...............................................................................................43 REFERENCES...............................................................................................44 APPENDIX A .................................................................................................46 APPENDIX B .................................................................................................55
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 Childrens 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
vi
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
vii
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 laymans 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 physiological variables that are recorded are: !"Electroencephalography (EEG) !"Electro-oculography (EOG) !"Electrocardiography (ECG)
[3]
The
Embedded Internet for Pulse Oximeters I !"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 photosensor 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 Childrens 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 2
Embedded Internet for Pulse Oximeters I 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 Childrens Sleep Unit
Since the Mater Childrens 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 patients 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.
Embedded Internet for Pulse Oximeters I 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. 4
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 its 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.
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 todays 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.
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
emWares 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 7
Embedded Internet for Pulse Oximeters I 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 MP3s, 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 PDAs. 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.
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 9
Embedded Internet for Pulse Oximeters I 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.
10
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. Engineering now sell the full development kits for $149[11]. Lightner
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.
11
2.2.3.3 Connect One iChip

The iChip
[12]
is a co-processor that communicates with the existing processor to Being an application-specific Internet
facilitate a connection to the Internet.
controller the iChip can be connected easily to an existing design. The iChip is compatible with Connect Ones 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 For network Low power
incorporates a 68/80 MOTO/Intel microprocessor bus interface. interaction the TCP/IP stack utilizes a 10Kbytes block of SRAM.
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.
12
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.
13
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.
14
Embedded Internet for Pulse Oximeters I 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 network for remote monitoring.
[14]
is a proprietary based pulse oximeter
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.
15
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.
16
Figure 2-10: Wireless Monitoring Station. Photo is courtesy of Criticare.
2.3.4 Internet Polysomnography

Advanced Medical Electronics Corporation !"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.
[15]
has developed an Internet
Polysomnography device. This device monitors 16 channels including:
17
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.
18
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.
19
Embedded Internet for Pulse Oximeters I 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
20
Embedded Internet for Pulse Oximeters I 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
21
Embedded Internet for Pulse Oximeters I M S Event Marker 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 isnt 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 22
Embedded Internet for Pulse Oximeters I 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
23
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 Picowebs internal EEPROM so the data needs to be sent directly to the Internet.
24
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. 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. 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
25
Embedded Internet for Pulse Oximeters I 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 patients name, location, identification number, and a small comment about them. This data is saved onto the Picoweb by a web page 26
Embedded Internet for Pulse Oximeters I 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.
27
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)
28
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 29
Embedded Internet for Pulse Oximeters I 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.
30
3.3.2 In Practice
By setting up the system in the Mater Childrens 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
31
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.
32
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.
33
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.
34
Embedded Internet for Pulse Oximeters I 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 35
Embedded Internet for Pulse Oximeters I 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 Oximeters 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. 36
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 Childrens 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.
37
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 cameras that come packaged with some PCs. Also web servers have already been installed in devices such as these in coastal regions to view 38
Embedded Internet for Pulse Oximeters I 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 dont 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. 39
Figure 5-1: Satellite Implementation. Diagram courtesy of Ben Lever.
Extending this idea remote studies could be further enhanced by implementing a bidirectional 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 40
Embedded Internet for Pulse Oximeters I 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 41
Embedded Internet for Pulse Oximeters I 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.
42
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 oximeters 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 Childrens 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.
43
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. 161178, 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, Dorlands 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 Users Manual Rev.02, pp. 5558, 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
44
Embedded Internet for Pulse Oximeters I 16. Datex-Ohmeda, 3900/3900P Pulse Oximeter, http://www.datexohmeda.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.seikousa-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
45
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 #define ENABLE_WATCHDOG #undef DEBUGGER #define NO_ETHER_ADDR_ON_BOOT #define CLOCK 7372000 #define BAUD_RATE 9600 #define TIMEOUT_DELAY 1000 #define WEB_BLINK_LED /* #define START_EEPROM 32
/*use file "ip" for IP address*/ /* enable watchdog */ /* disable debugger */ /* no MAC displayed on reset */ /* processor clock rate (Hz) */ /* serial port baud rate */ /* delay used for timeout */ will blink PicoWeb LED */ /* 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. 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 // patientdetails.htm // checktime.htm // trenddump.htm timeout.htm // clear.htm // PulseOximeter.class // PicoDataIF.class // DataStripperRealTime.class TrendDump.class TrendData.class DataStripperDump.class // CGI routines erasepatientinfo.cgi data.cgi start_mode1.cgi stop_mode.cgi cleartrends.cgi datetime.cgi oximeter savepatientname.cgi savepatient__id.cgi Two seconds of
data retrieval Store Patient Details on Picoweb returns current time time out error screen clears internal trend memory Pulse Oximeter class Picoweb interface class // data stripping class
// returns data stored in eeprom // start the pulse oximeter // stop the pulse oximeter // clear trend memory of pulse oximeter // check current date and time stored on // store patient details on picoweb
46

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

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 LED_ON ret .global pledoff pledoff: pcode_routine 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
48

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:
49

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], '&'
50

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 ;------------------------------------
51

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
52

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
53

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
54
9.0 Appendix B
Figure 9-1: Screen shot of main menu page
55

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
56
Figure 9-5: Screen shot of real time page
Figure 9-6: Screen shot of time out page
57
Figure 9-7: Screen shot of trend dump page
Figure 9-8: Screen shot of the online help page
58

Thesis

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis

Uploaded by

Copyright:

Available Formats

Embedded Internet for Pulse Oximeters I

Embedded Internet for Pulse Oximeters I

Embedded Internet for Pulse Oximeters I

Kings College Upland Rd St Lucia Qld 4067 19 October 2001

Embedded Internet for Pulse Oximeters I

Embedded Internet for Pulse Oximeters I

Embedded Internet for Pulse Oximeters I

Embedded Internet for Pulse Oximeters I

Embedded Internet for Pulse Oximeters I

Embedded Internet for Pulse Oximeters I

Figure 1-1: Pulse Oximetry Diagram

Figure 1-3: Mater Childrens Sleep Unit

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

Embedded Internet for Pulse Oximeters I

Figure 1-5: Implementation breakdown

Embedded Internet for Pulse Oximeters I

2.0 Literature Review

2.1 Telemedicine - Remote Medicine

2.1.2 Hospital Without Walls

Embedded Internet for Pulse Oximeters I

2.1.3 CARE System

2.2 Embedded Internet Technology

2.2.1 Embedded Internet Possibilities

Embedded Internet for Pulse Oximeters I

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

2.2.2 Embedded Internet In Practice

of devices attached to the Internet by 2006 will be non-PC based. The

2.2.3 Available Embedded Web Servers

package is Motorola Coldfire processor running the real time

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

Embedded Internet for Pulse Oximeters I

Figure 2-4: Picoweb server courtesy of Lightner Engineering

Embedded Internet for Pulse Oximeters I

2.2.3.3 Connect One iChip

facilitate a connection to the Internet.

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

2.2.3.4 Seiko S7600A

Embedded Internet for Pulse Oximeters I

2.2.3.5 Rabbit 2000 TCP/IP Development Kit

incorporates an 18 MHz Rabbit 2000

Embedded Internet for Pulse Oximeters I

2.2.3.6 Review of Available Web Servers

2.3 Pulse Oximeter Technology

2.3.1 Oxinet II Central Station Network

is a proprietary based pulse oximeter

The Oxinet II has the capacity for 30 patients

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

Embedded Internet for Pulse Oximeters I

2.3.2 TeleOximetry 3900/3900P Pulse Oximeter

has remote access

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

2.3.3 CSI-TC Wireless Monitoring Station

is a portable central station

Embedded Internet for Pulse Oximeters I

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

2.3.4 Internet Polysomnography

has developed an Internet

Polysomnography device. This device monitors 16 channels including:

Embedded Internet for Pulse Oximeters I

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

Embedded Internet for Pulse Oximeters I

Figure 3-1: System overview

3.1 Design and Implementation

Info Records TFF|||||||||||||||**<cr><lf>