Rochester Institute of Technology
Critical Design Report for the
Universal Internet Interface
By
Eric Pettersen
Etana Elegbe
Jared Gillis
Shamit Patel
Shari McNamara
February 16 2005
Version 1
TABLE OF CONTENTS
1 Introduction
2 Recognition and Evaluation of Need
2.1 Comparison with Previous Work
2.2 Contrast with Previous Work
2.3 Split Team Design
3 Concept Development
3.1 UII Communications Protocol
3.2 Zigbee for all Wireless Communication
3.3 ECG/EMG Peripheral
3.4 PDA User Interface
3.5 USB for AHMD
3.6 Internet Connectivity
3.6.1 Ethernet Connection to Internet
4 Feasibility Assessment
4.1 PDA Electrical Interface
4.2 Translator
4.3 Zigbee
1. Bluetooth vs. Zigbee
4.4 ECG/EMG Front-end
5 Functional Specifications
5.1 Wireless Communication Link
5.1.1 Zigbee Board User Interface
5.1.2 Verification of Transmission
5.2 Fifth Element
5.3 Overall Functionality
5.3.1 Physician’s Perspective
5.4 AHMD Interface
5.5 Failure Conditions and Modes
5.5.1 Scenarios of User Mistakes
5.5.2 Ways Zigbee can Fail
5.5.3 Ways Translators can Fail
5.5.4 Ways UII can Fail
5.5.5 Ways ECG can Fail
6 Regulatory Requirments
6.1 Food and Drug Administration
6.1.1 Determining if the Device Meets the Definition of a Medical Device
6.1.2 Pre-market Review of Telemedicine Devices
6.1.2.1 Device Determination
6.1.2.2 Software Policy Development
6.1.2.3 The Pre-market Notification [510(k)]
6.1.2.4 Selecting the Appropriate Marketing Application
6.1.3 Other Requirements
6.1.3.1 Pre-market Requirements: Labeling, Registration, Listing
6.1.3.2 Post-market Requirements: Quality System, Medical Device Reporting
6.2 Federal Communications Commission
6.2.1 Zigbee
6.2.2 Modems
6.2.3 Ethernet
6.3 IEEE
6.3.1 Medical Device Communications Standard
6.3.2 Zigbee
6.4 Patents
6.4.1 Integrated Medical Information Management and Medical Device Control System and Method (US Patent Application #20040215490)
6.4.2 Physician information System and Software with Automated Data Capture Feature (US Patent Application #20040220830)
6.4.3 Pharmaceutical Patient Information System (US Patent Application #20040215489)
6.4.4 Distributed System and Method for Managing Communication Among Healthcare Provider, Patients and Third Party (US Patent Application #20040220829)
7 Synthesis of Design
7.1 Hardware
7.1.1 UII
7.1.1.1 CerfCube
7.1.2 Translator
7.1.2.1 Freescale Development Board as Translator
7.1.2.2 Freescale Development Board
3. 5th Element
1. The ECG-EMG signal properties
2. The ECG-EMG design
1. Basic components of a typical ECG and EMG
7.1.3.2.2 The Power Supply and Isolation Circuit
7.2 Software
7.2.1 UII Communications Protocol
7.2.2 UII Architecture
7.2.2.2 User Interface Architecture
7.2.2.3 Medical Database Architecture
7.2.2.4 AHMD Implementation
7.2.2.5 Web Server Implementation
7.2.3 Translator Architecture
8 Software Architecture
8.1 Programming the HC(S)08
8.2 The Medical Instrument Data Output
8.3 Software Organization
9 Bill of Materials
10 Citations
1 INTRODUCTION
The Universal Internet Interface (UII) is a smart communications hub that serves as a medium for bi-directional data flow between various physical health monitoring devices at a patient’s home and a physician at a remote location over the Internet. The advent of home medical monitoring devices has given the patient the freedom to stay at home and perform a number of medical tests; however, the utility of these home medical devices has been curtained by the lack of simultaneous professional analysis of the gathered data. While improving technology has provided fascinating facilities to the patient at home and to the physician at the hospital, there exists no link connecting the patient and the physician. The UII is being developed to form the physical connection between the physician and the patient and their medical technologies. The UII and its included software shall have the ability to communicate with various commercially available medical devices through a wireless connection, store retrieved data in a structured database, and act as a communications interface between the physician and the user. [1]
2 RECOGNITION AND EVALUATION OF NEED
The goals of the UII are to improve the following situations.
1. While the patient may be able to identify extreme deviations of medical results from normal readings, they still have to physically convey these readings to a physician for medical analysis. Furthermore subtle changes in readings, which might be critical to the patient’s health, may be overlooked if the patient is the only person interpreting the data.
2. The readings from a monitoring device could be critical in an early diagnosis; however, the uncertainty in how well and when these results reach the physician diminishes the usefulness of many home medical devices.
3. The burden of maintaining and storing an accurate database of the medical device readings to physically convey to the physician at a later stage is neither easy nor always practical. This results in a loss of critical data that, in a medical case, could be crucial to the patient’s health.
4. Until now, the physician has had no direct benefit in the existence of home medical monitoring devices. With access to a home database, the physician can make faster and more informed medical analyses and decisions.
The UII will magnify the utility of the home medical monitoring devices by providing the physician with the access to a medical database of the user, as well as add a feedback path for the user to get an input from the doctor based on his health monitoring device database. The end result shall be to provide the physician with the comfort in the knowledge of his patient’s current health, and provide the user the satisfaction that his physician has a constant update on his health status. [1]
2 Comparison with Previous Work
The UII has been in development for the past two years as a part of two RIT Electrical Engineering Senior Design projects. When the project was continued this year the UII had the functionality to:
1. Maintain and update a web server to store patent data and interface with the physician.
2. Interact with the user through a PDA via IrDA.
3. Talk to a medical device translator via Bluetooth. The translator will interpret data from various medical devices and send it to the UII in a form it can understand.
With this functionality the UII in this form not only shows the feasibility of the concept but also shows that it is practical to achieve this concept. However the goal of the Senior Design Project this year has changed. The goals for this year’s project are to improve upon this design to make a marketable affordable product. Another goal is to show that the medical devices in the future will not need any external hardware to be UII compliant but can follow our reference design to create a UII complainant device.
2.2 Contrast with Previous Work
This year, the initial concept has been enhanced. Using cutting edge technology the UII will become more robust, consistent and user friendly. The goal is to improve its practical performance and usability.
The only way for the user to interact with the UII is through a PDA. The PDA is touch screen and very user friendly; the architecture for this interface will cross over into the UII’s final design. However, the interface between the UII and the PDA is via IrDA. This will require the user to be pointing the PDA at the UII’s IrDA receiver. This reduces the user-friendly aspect of the UII. Using a new wireless technology Zigbee the user can interact with UII from any room in the house. This technology will also replace Bluetooth as the means of transmitting medical information from the medical devices to the UII.
An Electrocardiograph/Electro-myograph front-end with an RS-232 output will be built in addition to the current medical design. The ECG/EMG will be connected to a free-scale board, which will communicate with the UII via ZIGBEE. The ECG/EMG-ZIGBEE configuration will be called the Fifth Element.
2.3 Split Team Design
In order to meet the specifying needs of this project three groups will be used. The three parts to the project are: web server and interface, wireless communications network, and a bio-potential amplifier design. These needs will be completed over a period of three quarters. The first quarter was the over all design and planning stage. Second quarter was the implementation of a wireless communications link and the fabrication of the bio-potential amplifier. The final quarter will consists of the complete medical monitoring device implementation with the UII and a web server design.
3 CONCEPT DEVELOPMENT
3.1 UII Communications Protocol
To make the UII a feasible device, it has to be able to connect to as many medical devices as possible. As an initial concept implementation, the UII will be shown to interact with four basic medical devices. However an important part of the project will be to create and define a communications protocol, which will enable manufacturers to create their medical devices with an extension, which will support this protocol implementation. This protocol should be robust enough to handle the various possible data transfers yet at the same time well defined enough so that it can be practically used by the original medical manufactures or third party integration module developers. The UII communications protocol will try to bring a cost effective, easily implement-able standard into the medical device industry for talking to the UII. [1]
3.2 Zigbee for all Wireless Communication
The main role of the UII is to form a reliable yet convenient mode of data transfer. The most standard way of connecting two devices is through a cable connection. However in a home environment, having cable connections running between medical devices restricts mobility and makes having the UII a liability. For this reason it was decided to use a wireless communication method to talk between the medical devices and the UII. [1] The latest and greatest standard for short to medium wireless communication is Zigbee.
3.3 The ECG/EMG Peripheral
The ECG is a bio-potential differential device that will be used in monitoring the electrical activity of the patient’s heart as well as collecting related data that can be analyzed by a physician. Signal collection is done through the use of surface (non-invasive) electrodes that are placed at strategic points on the user’s body in order to adequately capture the heart’s sequence of activities during ventricular activation. In addition, the design is such that the user can also collect electro-myograms (recordings of other muscle activity) through a switch in the circuit.
3.4 PDA User Interface
The UII in its current form will have no externally configurable options. The only way for the user to communicate with the UII will be through a PDA, which will use Zigbee to communicate. Since there are no PDA’s that are Zigbee compatible a Zigbee transceiver will have to be attached to the PDA through the USB port on the PDA. The UII will support multiple users however, there will only be one user allowed on a PDA. For households with more than one user they can simply purchase another PDA.
3.5 USB for AHMD
The original concept for the UII rose from the need to have a device capable of connecting the AHMD (Automated Home Medication Dispenser) to the Internet. The AHMD will be connected to the UII through a USB connection. For its functionality all the AHMD needs is a file from the physician’s computer, this could have been implemented with Zigbee, but it was decided to have the AHMD connect to the UII through the UII. This would allow the UII to show its compatibility with a USB enabled device. The USB port on the UII’s motherboard (the CerfCube) will be used for this purpose. This implementation will require no further hardware addition. 1
3.6 Internet Connectivity
3.6.1 Ethernet Connection to Internet
The Internet is the backbone of the link the UII creates between the user and the physician. To implement Internet connectivity of the UII, the UII will support Ethernet connections to LANs and other network topologies. The Ethernet port on the CerfCube will be used to support this feature, and no further hardware additions are required. The Ethernet connectivity will allow home users to use their cable and DSL connections to the Internet enable the UII. 1
4 FEASABILITY ASSESSMENT
4.1 PDA Electrical Interface
The way in which users will communicate with the UII is by using a PDA. The UII team thought about several different issues that would make the UII user-friendly as well as reliable. Further, two main communication protocols were discussed; whether the PDA should communicate with the UII over Zigbee (sharing a communication channel with the medical devices), or IrDA. Both communication protocols are secure and have low power consumption. Zigbee was chosen as the best way to communicate with the UII. Most importantly with IrDA you have to be pointing the PDA at the IrDA receiver on the UII in order to establish a link. Zigbee only has to be in range of the UII (which is 100meters) in order to establish a link. Even though there are no Zigbee enabled PDAs currently in the short future there will be. A link through the USB port on a PDA will work as a reference design to show that a Zigbee-enabled PDA will work with the UII.
4.2 Translator
The goal of the translator is to have a programmable microprocessor capable of transmitting Zigbee data and communicating with the UII. To meet these goals, the design of a translator had to have a microprocessor to interface between a medical device, via RS-232, and the UII via Zigbee. At todays present time the only Zigbee devices that exist are development boards. These development boards have a Zigbee transceiver, a microprocessor, memory, an RS-232 port, and some LEDs. There were few companies that were selling each of these development boards, Crossbow, Chipcon, and Freescale. Each different company makes a different version of the Zigbee transceiver and has slightly different options.
Table 1: Decision Grid for Zigbee Development Board
| |Weight |Freescale |Chipcon |X-Bow |
|RS-232 port |4 |10 |10 |10 |
|Microprocessor |5 |9 |8 |8 |
|Low power |4 |8 |8 |8 |
|Memory |3 |6 |8 |9 |
|Ease of programming |4 |9 |8 |7 |
|Cost |5 |9 |6 |2 |
|Total | |216 |198 |177 |
Based on the results of the decision grid above, the team decided to go with the Freescale Development board. The Freescale board was significantly cheaper then the other development boards and comes with all the programming and debugging software necessary. Freescale has also been very helpful in any questions that the team needed answered. The only drawback is the lack of available memory on the Freescale board, compared to the other two development boards. However, this is not an issue since the Freescale board has sufficient memory for the teams needs.
4.3 Zigbee
Zigbee is a reliable, cost-effective, low power wireless communication device based off of the IEEE 802.15.4 standard. Zigbee operates in the worldwide 2.4 GHz band. Zigbee’s low power consumption comes from its ability to be in a deep-sleep mode when it is not actively being used and will only wake up for a fraction of a second to confirm its presence in the network. Zigbee can be set up into a beacon mode and a non-beacon mode. The beacon mode of Zigbee is used to synchronize the network. Intervals can be set anywhere from 15ms to 4 minutes. Non-beacon mode in which each device is autonomous and can initiate a conversation at will. However when a device initiates a conversation it cannot interfere with other devices. Zigbee security comes from the IEEE 802.15.4 standard, which has 4 security services. Each device will maintain a list of trusted devices within the network. Zigbee has a 128-bit advanced data encryption standard. The last standard will reject data frames that have been replayed. The Zigbee stack only requires 4Kb of memory for minimum capabilities and for full function only 32 KB of memory.[1]
4.3.1 Bluetooth vs. Zigbee
Bluetooth is a wireless standard that has been around for many years, so why replace this standard?
Table 2: Standard Wireless Comparison Chart[2]
[pic]
A quick comparison between Zigbee and Bluetooth can be seen in Table 1. In terms of system resources, battery life, network size, bandwidth and transmission range Zigbee is better than Bluetooth in every category except for bandwidth. The UII will be installed in the home and user should not be restricted as to where the UII can be installed. The cheapest, most popular, and readily available form of Bluetooth has a range of 10 meters. This limited range will restrict the user; it will require them to install the UII as close as possible to all the medical devices they wish to use. Zigbee will eliminate this restriction to the user because it has a range of 100m. In today’s modern technological world there are many home medical devices available. Bluetooth would limit the number of medical devices to be used with the UII. The one category in which Bluetooth is better than Zigbee is in bandwidth. Since only small amounts of data are being transferred a large bandwidth is not necessary. A smaller system resource requirement and a longer battery life will be a significant improvement over Bluetooth. Therefore Zigbee is the logical choice as a form of wireless communication standard for better performance and enhanced user features.
4.4 ECG/EMG Front-end
ECG/EMG devices cost anywhere from a couple of hundred dollars to thousands of dollars depending on the functional capabilities of the device. The fifth element (ECG-EMG front-end) is an efficient device that incorporates both an ECG and EMG at a relatively low cost. The fifth element will be used in collecting important data such as the electrical activity of the heart and other muscles in the body, thereby providing the physician with a greater range of information for the analysis of the patient’s condition.
5 FUNCTIONAL SPECIFICATIONS
The mission of the Universal Internet Interface (UII) is to provide physicians access to users’ recent medical information without the need for regular in-office checkups. Given the advent of home medical monitoring devices, patients now have the freedom to stay at home and still provide doctors with recent medical information. The UII provides the patient with one extra freedom: the elimination of the need to note the medical information themselves. The UII automatically maintains a medical record for the patient and provides access for the doctor to this record.
The UII is a medical data transfer device with temporary storage capabilities for that data. The UII is a central hub for the identification and interfacing of medical monitoring devices and an Internet communications point through which authorized users may access the data. The UII is able to communicate with all devices that communicate using the “UII Communications Protocol” (a wireless data transfer protocol). For devices that do not support this protocol, the UII provides “translators” for specific medical instruments. [1]
5.1 Wireless Communications Link
The wireless communications link will be the backbone of the UII. This will be how medical information is transferred from a medical device to the UII. This concept will be realized by connecting a medical device, a digital scale, to the Zigbee wireless development board. The Zigbee board connected to the scale will send the scale’s medical information to another host Zigbee board connected to a PC. The user interface for this design will be through direct interaction with the Zigbee board.
5.1.1 Zigbee Board User Interface
The user will be limited in how they can interface with the Zigbee board. Restricted user intercalation will keep the user from accidentally creating a malfunction with the hardware. A limited interface is also a benefit so the user will not be confused by too many options.
As long as the Zigbee wireless board is on and functioning, LED 4 will be light. The user will have to use the scale by turning it on with a button. The user must then wait until the scale has zeroed out and then step on the scale and stand still until the weight measurement stabilizes. This will cause LED 1 on the wireless board to light up.
LED 1 will signify to the user that a valid data measurement has been taken. If the user is satisfied with the measurement taken they will press button 1 on the Zigbee development board. This step is added for a future design addition of an LCD on the Zigbee board which will display the weight measurement that has been taken. The data will then be stored in memory upon the user pressing button 1.
In order to send the data the user will then press button 2 on the Zigbee development board. The data will be sent out to the host Zigbee board, connected to the PC. Once the host has received all the data it will send back an acknowledgement. Upon receiving this acknowledgement LED 2 will then light up.
5.1.2 Verification of Transmission
The Freescale Zigbee Development board will be connected to a PC and act as the host receiver. This board will always be on and waiting for a Zigbee wireless transmission. Once a transmission has been received the board will then output the data via its RS-232 port in a standard ASCII format. This data can be displayed in a standard serial interface program such as Hyper Terminal or ZOC term.
5.2 Fifth Element
The Fifth Element is a bio-potential differential device that will be used in monitoring the electrical activity of the user’s heart and collecting related data that can be analyzed by a physician. Data collection is done through the use of non-invasive (surface) electrodes that are placed at strategic points on the user’s body in order to capture the heart’s sequence of activities during atrial and ventricular activation. In addition, the design is such that the user can also collect electro-myograms (recordings of other muscle activity) by flipping a switch in the circuit.
The Bio-amplifier consists of a two channel front-end device operating in a frequency range from 0.1-100Hz (ECG) and 20-200Hz (EMG). Unlike the other medical devices, the output is an analog signal and it needs to be sampled by the A/D converter on the Freescale Zigbee board before the data is formatted and sent wirelessly to the Freescale board connected to the PC.
[pic]
Fig. 1: General Block diagram of Bio-potential Amplifier.
5.3 Overall Functionality
For any medical device that will communicate with the UII a custom designed software program for the Zigbee board will be created. Therefore the software used to establish the link needs to be designed in a fashion that will allow for simple portability to different devices. There will be no change in the user interface between different medical devices.
The UII will be the hub of the system. The Zigbee board connected to the UII must be able to differentiate between multiple medical device transmissions. Medical transmissions will be stored on the UII in a specified format. The format in which the information will be stored will be stored as shown in Figure 2.
|Device |Date |Time |Data |
Figure 2: UII Data Storage Format
5.3.1 Physician’s Perspective
The UII exists on the Internet as a unique IP. The doctor can connect to the UII directly through that IP to be served with the medical databases stored on the UII.
The first level of this interaction is the doctor authorization screen. Since the UII is available to anyone who knows its IP (which is, in fact, difficult to determine without aid), the UII must insure that it does not provide discreet medical information to anyone who is not authorized. The authorization shall ask for a predetermined user name and password.
When the doctor has successfully been authorized, the patient (user) profile selection screen is presented. Each available user is indicated as a link with their name as the link. Each link directs the doctor to the user’s home page.
Each homepage contains the users name and some statistics on their activity. Such statistics could include the date and time of the first and last measurements that the UII has stored. The homepage contains a link to an Extensible Markup Language (XML) document that contains all the acquired data for that user.
The XML is a structured representation of the database. It contains a link to a style sheet that is not hosted by the UII that will format this XML data into an easily comprehensible table. If the doctor downloads the XML file, then its data can be integrated with previous records.
If the doctor is satisfied with the data and sees that the UII cannot store much more, then they have the option to delete a portion of or all of the database information. [1]
5.4 AHMD Interface
The UII, in addition to all its other responsibilities, provides the connection between the Automated Home Medication Dispenser (AHMD) and the physician. [1]
5.5 Failure Conditions and Modes
To make the UII reliable and user-friendly, the team discussed several issues that could prevent the UII from operating properly. A summary of the discussion is listed below. [1]
5.5.1 Scenarios of User Mistakes
A complete picture of the causes of failure of the UII begins with the user. A design goal of the UII was to make it user-friendly and consistent; if the user makes a mistake is therefore a failure of the design. To help prevent such circumstances, the following list of possible situations was developed:
1. Turn off UII during measurement: While taking a measurement, the UII is turned off. The UII will have to be programmed in such a way, as its state is stored in non-volatile memory whenever it is hanged. This will insure that when it is re-activated, it will be able to recover and operate as if nothing extraneous occurred.
2. Turn off the Zigbee Board during measurement: If the Zigbee board is turned off any data stored will be lost. No wireless transmission can occur with the Zigbee board off. The only way to restore a connection and transmit data would be to turn on the board and retake the measurement.
3. Press the reset button during measurement: The zigbee board has a reset button if pressed all data stored on the Zigbee board will be lost. To restore data the user will have to retake the measurement.
4. Physician purges UII and looses data: The doctor fails to record the reading from the UII before purging them. Protection from this could take the form of a “Recycle Bin” or “Trash” container into which a database is placed when deleted. The metaphor already exists for most computer users and will therefore be readily apprehended. [1]
5.5.2 Ways Zigbee can Fail
Below are anticipated scenarios in which Zigbee communication fails.
1. Strong Interference other than Zigbee. The radio signals do not communicate as required.
2. Out of range: The device is too far for the Zigbee range of the UII.
3. Jammed signal: The Signal gets jammed with data.
4. Encryption key mix-up: The security key of the devices is interchanged.
5. Broken antenna: Hardware failure.
6. Lack of regulated power: The transmitter does not get enough power to function.
7. De-synchronization due to poor protocol implementation: Bad software. [1]
5.5.3 Ways Zigbee board can Fail
Below are anticipated scenarios in which the translators can fail.
1. Power shortage
2. Power surge
3. Breakdown in pin connection
4. Doesn’t show LED signals
5. Doesn’t initialize correctly
6. Cannot handle two UIIs
7. Power loss in middle of transmission[1]
5.5.4 Ways UII can Fail
Below are anticipated scenarios in which the UII itself can fail.
1. Out of RAM: The software requirements of the RAM are too much, bugs.
2. Out of flash memory: too much user data being stored.
3. Zigbee card not recognized: Incapability with Zigbee board.
4. Serial port not recognized
5. Battery failure: UII’s internal battery fails.
6. DOS attack on web server
7. Cannot find doctor sever: Can’t connect to server.
8. Cannot get through router address translation
9. Multiple transmissions (handling/storage)
10. Web server blocks transmission from doctor[1]
5.5.5 Ways the ECG/EMG front-end can fail
Listed below are ways that the ECG front-end can possibly fail to function as.
1. Battery Failure: 9V batteries provide the power supply of the ECG front-end
2. Saturation or Distortion of Signal data due to high offset voltages at the electrodes.
3. Interference due to ground loops (if patient is attached to more than one electrical device)
4. Broken electrode wires which results in inaccurate recordings
6 REGULATORY REQUIREMENTS
6.1 Food and Drug Administration
“FDA’s Center for Devices and Radiological Health (CDRH) is responsible for regulating firms who manufacture, repackage, re-label, and/or import medical devices sold in the United States”[3]. For the UII to be a commercially viable it has to meet the regulatory specifications of the CDRH. The basic regulatory requirements that manufacturers of medical devices distributed in the U.S. must comply with are:
1. Pre-market Notification 510(k), unless exempt, or Pre-market Approval (PMA),
2. Establishment registration on form FDA-2891,
3. Medical Device listing on form FDA-2892,
4. Quality System (QS) regulation,
5. Labeling requirements, and
6. Medical Device Reporting (MDR)
Going into the details of the regulatory requirements needed a basic understanding of the FDA’s role in the UII development. This was done based on the guidelines in “Getting to Market with a Medical Device”[4] and “Telemedicine Related Activities”[5] [1]
6.1.1 Determining if the Device Meets the Definition of a Medical Device
A medical device is defined as: "an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:
• Recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,
• Intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
• Intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it's primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes."[6]
Since the UII is intended to be marketed as a Home Medical Device with the goal to supplement diagnosis and treatment but at the same time not directly perform these activities there seemed to be some ambiguity if it would fall into the category of a medical device. This was however clarified by the following argument “It should also be noted that the classifications are not considered to apply to general purpose products, such as general purpose software, digital communications devices, and storage devices that are not intended for medical use. The Center recognizes that such products may be used in a medical setting, and ordinarily they are not considered to be medical devices. However, when such general purpose products are labeled for medical use, or included as components of systems labeled for medical use, they are considered to be within the scope of the proposed classifications”[7] This meant that “IF” the UII was marketed solely as a Universal Internet Interface, and not labeled as a medical device or included as component of a medical device, then it would be exempt from FDA regulations. Since the goal of the UII is to define and propose the incorporation of translators and a communication standard in home medical device monitoring devices our current definition of the UII would definitely come under the classification of a medical device.
The definition for “Telemedicine” under CDRH is “The delivery and provision of health care and consultative services to individual patients and the transmission of information related to care, over distance, using telecommunications technologies, and, incorporating the following activities.
1. Direct clinical, preventive, diagnostic, and therapeutic services and treatment, including procedures where a provider may be present with the patient, and clinical training and consultative clinical Grand Rounds, if used for decision-making regarding the clinical care of a specific patient.
2. Consultative and follow-up services.
3. Remote monitoring, including the remote reading and interpretation of results of patient's procedures.
4. Rehabilitative services.
5. Patient education provided in context of delivering health care to individuals.”[8]
The UII fits all five points with a conformity that makes it seem like the UII was designed to handle “telemedicine” in its entirety. [1]
6.1.2 Pre-market Review of Telemedicine Devices.
The FDA broadly classifies all devices into three classes, which are class I (general controls), class II (special controls) and class III (pre-market approval (PMA)). If a device is not in commercial distribution prior to May 28th 1976, and not found by the FDA to be substantially equivalent to a legally marketed device, then it requires a submission of a PMA. However it was noted that certain class 1 devices are exempt from various degrees of e.g. exemption from GMP (Good Manufacturing Practice) review and /or 510(k) submission. For Class III devices and non-exempt Class I and Class II devices a 510(k) will be required for marketing.
Another point noted was that when a parent device wants to use the UII or incorporate the UII’s translator it will have to get an approval from the Office of Device Evaluation (ODE) division with which the parent device is classified under. Which, means if a medical device measuring physiological parameters as body temperature decides to use the UII’s translator it would have to be reviewed in the Division of Dental, Infection Control and General Hospital Devices (DDIGD) once again because now it would further classify as a telemedicine device. [1]
6.1.2.1 Device Determination
Products which are components of or accessories to a medical device are typically regulated in the same way as the "parent" device, e.g. if the parent device is subject to GMPs and pre-market notification, the normal presumption is for an accessory to be subject to the same requirements, even if marketed separately. Furthermore, the manufacturer of a device is responsible for assuring that the full device, including all components, complies with the regulations. The medical device manufacturer is responsible for the safety and effectiveness of all components, including any general-purpose articles incorporated within the device. This again proves that having the UII certified, as a FDA approved medical device would credibly ease the process of allowing medical monitoring device manufactures to incorporate the UII. Other points of note under Device determination are:
1. An individual physician ("licensed practitioner") who develops a medical device genuinely for use in his own personal practice is exempt from the registration and listing and 510(k) provisions of the Act.
2. Multiple site use of a device (even within a single company) constitutes commercial distribution.
3. Finished product and products under development have different regulatory rules.
4. Source code is not considered regulated, where as commercially distributed or executable code related with medical devices is considered regulated. [1]
6.1.2.2 Software Policy Development
Because software is integral to the operation of the UII, it was looked into. At the present time the FDA website only lists its attempts to form a clear regulatory standard for software. Since the UII has a great dependency on software this will have to be looked into detail at a later stage. Considering all the functions of the UII and an exhaustive period of research looking into similar products (using keywords home, modem, phone, database, wireless etc) and remembering that the UII would also be classified under the same class as the devices it attaches to the UII will definitely be a class II device which will require both GMP as well as 510(k) (or PMA) submission. [1]
6.1.2.3 The Pre-market Notification [510(k)]
The FDA has the following definition for the 510(k):
“Each person who wants to market Class I, II and some III devices intended for human use in the U.S. must submit a 510(k) to FDA at least 90 days before marketing unless the device is exempt from 510(k) requirements. There is no 510(k) form but instead a format for the submission described in 21 CFR 807 and in the pages that follow.”
A 510(k) is a pre-marketing submission made to the FDA to demonstrate that the device to be marketed is as safe and effective, that is, substantially equivalent (SE), to a legally marketed device that is not subject to pre-market approval (PMA). Applicants must compare their 510(k) device to one or more similar devices currently on the U.S. market and make and support their substantial equivalency claims. A legally marketed device is a device that was legally marketed prior to May 28, 1976 (pre-amendments device), or a device which has been reclassified from Class III to Class II or I, a device which has been found to be substantially equivalent to such a device through the 510(k) process, or one established through Evaluation of Automatic Class III Definition”[9]. Unlike PMA, which requires demonstration of reasonable safety and effectiveness, 510(k) requires demonstration of substantial equivalence. SE means that the new device is as safe and effective as the predicate device(s). A device is SE if, in comparison to a predicate device if it:
• has the same intended use as the predicate device; and
• has the same technological characteristics as the predicate device; or
• has different technological characteristics, that do not raise new questions of safety and effectiveness, and the sponsor demonstrates that the device is as safe and effective as the legally marketed device.
A claim of substantial equivalence does not mean the new and predicate devices must be identical. Substantial equivalence is established with respect to intended use, design, energy used or delivered, materials, performance, safety, effectiveness, labeling, biocompatibility, standards, and other applicable characteristics. Detailed information on how the FDA determines substantial equivalence can be found in the Pre-market Notification Review Program 6/30/86 (K86-3) blue book memorandum”[10].
The UII will in our estimate qualify for a 510(k) and can avoid a PMA because a similar product is available on the US market and claims to have all required FDA approvals. This device is the “PSTN Telehealth Gateway”[11]. However this device was not found on the FDA website. Communication is on with the manufacturing company about their claims of regulatory adherence. “Until the applicant receives an order declaring a device SE, they may not proceed to market the device. Once the device is determined to be SE, it can then be marketed in the U.S. If FDA determines that a device is not SE, the applicant may resubmit another 510(k) with new data, file a reclassification petition, or submit a pre-market approval application (PMA).”[12] The SE determination is usually made within 90 days and is made based on the information, which will have to be submitted by us. The FDA has guidelines on preparing a 510(k), which have been identified and noted.[13] [1]
6.1.2.4 Selecting the Appropriate Marketing Application[14]
The development of data and/or information is necessary to submit a marketing application, and to obtain FDA clearance to market. For some 510(k) submissions and most PMA applications, clinical performance data is required to obtain clearance to market. In these cases, conduct of the trial must be done in accord with FDA's Investigational Device Exemption (IDE) regulation, in addition to marketing clearance. An IDE allows the investigational device to be used in a clinical study in order to collect safety and effectiveness data required to support a Pre-market Approval (PMA) application or a Pre-market Notification [510(k)] submission to FDA. Clinical studies are most often conducted to support a PMA. Only a small percentage of 510(k)’s require clinical data to support the application. Investigational use also includes clinical evaluation of certain modifications or new intended uses of legally marketed devices. All clinical evaluations of investigational devices, unless exempt, must have an approved IDE before the study is initiated. The FDA further lists these two requirements that the UII have to meet before it reaches the market and after it is a marketed product. [1]
[pic]
Figure 3: Flow chart of 510(k) process[15]
6.1.3 Other Requirements[16]
The FDA further lists these two requirements that the UII have to meet before it reaches the market and after it is a marketed product. [1]
6.1.3.1 Pre-market Requirements: Labeling, Registration, Listing
Before marketing clearance is obtained the manufacturer must assure that the device is properly labeled in accordance with FDA's labeling regulations. Once clearance for marketing is obtained, the manufacturer must register their establishment and list the type of device they plan to market with the FDA. This registration and listing process is accomplished by the submission of FDA Form 2891 and 2892. [1]
6.1.3.2 Post-market Requirements: Quality System, Medical Device Reporting
Once on the market, there are post-market surveillance controls with which a manufacturer must comply. These requirements include the Quality Systems (QS) (also known as Good Manufacturing Practices, GMPs) and Medical Device Reporting (MDR) regulations. The QS regulation is a quality assurance requirement that covers the design, packaging, labeling and manufacturing of a medical device. The MDR regulation is an adverse event-reporting program. [1]
6.2 Federal Communications Commission
The UII posses two ways to communicate with the outside world: via the Zigbee development board transceiver (this applies to the translators also) and through the Ethernet connection. The FCC regulates each one of these means in some way.
6.2.1 Zigbee
The FCC has this official stance on unlicensed spread-spectrum devices [2]:
▪ Create a minimal amount of rules to control (or prevent) interference.
▪ “Encourage Innovation through flexibility”
▪ Continuously update the rules in response to technological advancements, developments, or trends.
▪ Create the set of broad rules as a framework within which the private sector can develop standards.
The project utilizes a Zigbee IEEE 802.15.4 radio that has been certified to meet all regulations of the FCC. Specifically, it has been approved to operate at up to range of approximately 100 m. [1]
6.2.2 Modems
Regarding modems, there are two important regulations: FCC-15 and FCC-68.
FCC Regulation Part 15 describes the limitations on the amount of electromagnetic interference (EMI) allowed from electronic devices. It was originally developed to limit possible interference with broadcast communications and is still with us today. Nearly all devices have to pass this regulation and the modem is no exception.
FCC Regulation Part 68 describes the requirements for connecting to the U.S. telephone network. The report defines a variety of terms and goes into detail on how to test a device that will eventually be connected to the network. Such tests include: the reaction of the device to unforeseen external influences (high voltage down the transmission line), the possible ways the device can damage the network when it fails, insurance that the output power levels of the device will not cause problems on the network (crosstalk, etc.), billing protection (such that it is assured that telephone companies will be able to bill for the line usage, and other limitations (such as maximum number of redial attempts). [1]
In all, it is assured that the UII meets these two regulations because the integrated modem on the UII is itself certified to do so. [1]
6.2.3 Ethernet
With regards to the Internet, the FCC practices “regulatory openness” – that is, it does not regulate it beyond the mandates of Part 15 (which is discussed in the previous section). [1]
6.3 IEEE
In order for the UII to become a commercial product, it should also meet the IEEE standards requirements for wireless home medical devices. [1]
6.3.1 Medical Device Communications Standard
This standard is intended to enable medical devices to interconnect and interoperate with computerized healthcare information systems in a manner suitable for the clinical environment. The key requirements are that this standard shall
1. Meet applicable requirements for patient and user safety of medical devices.
2. Accommodate frequent network reconfiguration.
3. Provide an extremely simple user interface, the only required user action being to connect the medical device to the network.
4. Unambiguously associate a medical device with a specific patient.
5. Support a wide range of host computer topologies, allowing implementations ranging from those limited to a single bedside to those that span multiple beds and care units, with various gradations between these extremes.
6. Minimize implementation complexity for high-volume medical devices.
Communications are modeled as a collection of systems exchanging messages (see figure 4). More specifically, communications between medical devices associated with a specific patient environment and a patient care information system responsible for the data of that patient.
[pic]
Figure 4: Medical device communications model
Medical Device System (MDS) is a medical device that is actively connected to a type of communications link. Patient Care System (PCS) is a patient care information system that is actively connected to a type of communications link. Medical Device Data Language (MDDL) is the protocol used to transfer data. [1]
6.3.2 Zigbee
Zigbee technology falls under the IEEE 802.15.4 standard. Its key features are robustness, low complexity, low power and low cost. Zigbee is a direct-sequence spread spectrum (DSSS) device. A DSSS device combines a high data rate bit sequence, referred to as the chipping code, with the data signal that divides the user data according to a spreading ratio. The chipping code is a redundant bit pattern for each bit that is transmitted, which increases the signal’s resistance to interference.
[pic]Figure 5: Zigbee stack architecture[17]
Frequency Bands and Channel Arrangement[18]
• Frequency Band 2.4 – 2.4835 GHz
• It supports 16 Channels (11-26)
Spreading Parameters
• Chip rate 2.0Mchips/s
• Modulation O-QPSK
6.4 Patents
During patent search, there were few patents that were close to our project. Detailed information on the patents are given below:
1. Integrated medical information management and medical device control system and method
2. Physician information system and software with automated data capture feature.
3. Pharmaceutical patient information system.
4. Distributed system and method for managing communication among healthcare provider, patients and third party.
6.4.1 Integrated Medical Information Management and Medical Device Control System and Method: (United States Patent Application #20040215490)
Abstract
An integrated medical information management and medical device control system and method are described that links multiple users and multiple medical devices together in a coordinated fashion. The linkage of users and medical devices is accomplished using a bi-directional network and a centralized host system. Users of the system are able to communicate with each other, operate medical devices from remote locations, access information from diverse sources automatically monitor a patent's status.
Inventors: Duchon, Douglas J.; (Chanhassen, MN); Wilson, Robert F.; (Roseville, MN)
Filed: May 18, 2004
6.4.2 Physician Information System and Software with Automated Data Capture Feature: (United States Patent Application #20040220830)
Abstract
A system and method for collecting, storing, processing, and referencing information in a personal digital assistant system configured as an electronic physician assistant is provided. The system comprises a personal digital assistant having an electronic physician data module therein, a scanning device coupled to the electronic physician assistant, and an automated data collection module for electronically storing scanned data, the automated data collection module being associated with the electronic physician data module. The method scans a patient identification and associates the identified patient with a patient record. Furthermore, the method records medical data as an electronic file of information and assigns a readable code to the information. Then, when the code is accessed, the method associates the information with a patient record.
Inventors: Moreton, Paul Y.; (Plano, TX); Moreton, David W.; (Columbia, MO); Breda, David C.; (Plano, TX)
Filed: December 1, 2003
6.4.3 Pharmaceutical Patient Information System:
(United States Patent Application #20040215489)
Abstract
A patient information system for the provision of individual-specific information on the effects and risks of a medicament includes an expert system, in which relevant data on the medicament, for example, compositions, application area, contra-indications, mode of action, risks and side-effects are stored. The expert system is embodied such that, on a user inquiry about a particular medicament by inputting particular personal status data about the user, an individual user information reply, which matches the personal status data including the education and the knowledge state of the user-- (a personalized enclosure) is generated including all relevant data, and excluding data on the medicament which need not be introduced according to the special requirements of the user.
Inventors: Abraham-Fuchs, Klaus; (Erlangen, DE); Bieger, Johannes; (Munchen, DE); Eisermann, Uwe; (Erlangen, DE); Hengerer, Arne; (Erlangen, DE); Rumpel, Eva; (Erlangen, DE); Schmidt, Kai-Uwe; (Erlangen, DE); Tietze, Daniel; (Spardorf, DE)
Filed: January 16, 2004
6.4.4 Distributed System and Method for Managing Communication among Healthcare Provider, Patients and Third Party:
(United States Patent Application #20040220829)
Abstract
In a distributed system for managing communication among healthcare providers, patients and third parties, users interact via clients connected to a server. Modules resident on the server provide functions that facilitate efficient communication among all the parties. System functions include: an online consultation platform that provides an interactive patient interview, produces a succinct message to the provider, and a prompt response to the patient's query; online prescribing and refills and transmission of the prescription; streamlined messaging between patient and provider employs via specialized message types; practice and workflow management for the provider that includes specialized message types, customizable routing, and role-based permissions; customizable practice web sites for registered providers, wherein patients can visit to access online services; broadcast of patient education materials customized and automatically distributed to targeted patient groups; and integrated charging and collections, determination of eligibility for coverage, and reimbursement.
Inventors: Baharav, Ofir; (Palo Alto, CA); Weinstein, David R.; (Danville, CA); Morag, Assaf; (Palo Alto, CA); Gannot, Gary; (Kensington, CA)
Filed: February 5, 2003
All the patents mentioned above are directly or indirectly related and very close to what we are trying to achieve. Hence, if commercialization was an option, then all the patents mentioned above should be considered and necessary steps should be taken before launching the product.
7 SYNTHESIS OF DESIGN
7.1 Hardware
7.1.1 UII
The hardware requirements of the UII are
• Zigbee
• Connectivity to AHMD
• Broadband Internet
7.1.1.1 CerfCube
The core of the UII is the CerfCube 250 developed by Intrinsyc. The CerfCube was developed as a starting point for low power Internet devices and fitted in well with out requirements. [1]
The CerfCube 250with a central Intel variety arm-complying microprocessor called the PXA250. The included peripheral supports are Ethernet, a CompactFlash connector, 3 serial ports, and a USB port. Kernel and file-system images can be downloaded through Ethernet and written into Flash by the boot loader. The CerfCube is loaded with an I-Linux kernel specially built for the CerfCube 250. Device drivers are provided for all on-board peripherals. Through the Intrinsyc website it is possible to find a cross compilation tool chain to enable kernel and application development.
Table 3: CerfCube Features
|ITEM |DESCRIPTION |
|CPU |INTEL PXA 250 |
|Memory |16 MB Flash |
|SDRAM |32 MB, 32 bit Data Bus |
|Serial and I/O |3 RS-232, 16 Digital I/O lines |
|Displays |4 LEDs |
|Power |5.0 V DC 1 Amp Peak Power |
|Dimensions |69mm by 57mm |
|Ethernet |10 base-T |
|CompactFlash |Type I/II CF/CF+ |
|USB |Type B receptacle |
[pic]
Figure 6: Available ports on the CerfCube
The following gives a brief description of the pertinent ports to the UII:
Compact Flash Connector
The Type II CompactFlash Connector comes with the following features:
• Compact Flash (CF) cards are hot-swappable
• Only 3.3V CF cards are supported
• Type II header allows Type I or II CF (or CF+) cards to be used
USB Interface
The USB interface is a standard Type B interface.
Serial Ports
The serial ports allow three RS-232 connections to be made to the UII.
Ethernet
The Ethernet port has a standard RJ45 connector to connect to Cable/DSL modems.
Based on the available ports and the hardware requirements of the UII the CerfCube could be configured with two options. The options are covered in the below table.
Table 4: CerfCube Configurations
| |Configuration 1 |Configuration 2 |
|Ethernet |Internet |Internet |
|USB |AHMD |AHMD |
|CompactFlash |Modem |Additional Memory |
|RS-232 |Zigbee |Zigbee |
The CompactFlash Socket on the CerfCube can be configured based on a customers needs. If the customer does not have a Cable or DSL Internet connection they can still connect the UII to the Internet with a dial up connection. This can be done through a CompactFlash 56K modem card. However if a customer has multiple users, then extra memory storage might be necessary. 128MB compact Flash Memory Card should solve this problem for the customer. [1]
7.1.2 Translator
The hardware requirements of the Translator board are
• ZIGBEE 802.15.4 standard
• RS-232 input and RF output
• Programmable processor with enough storage for embedded program and data to be transmitted
• Battery operated and low power consumption
7.1.2.1 Freescale Development Board as Translator
The translator functions are going to be implemented using the Freescale development board. Freescale developed the MC13191/92 developer’s kit as a tool to implement wireless network designs compatible with the IEEE 802.15.4 standard. The developer’s kit also fit the team’s hardware and software needs. [19]
7.1.2.2 Freescale Development Board[20]
The Freescale development board is equipped with a programmable 40-MHz HCS08 (8 bit) micro controller unit (MCU). The HCS08 micro controller comes with 60 Kbytes in-application re-programmable FLASH memory and 4 Kbytes of RAM. Freescale provides Code Warrior development studio software from programming the HCSO8 MCU. The development board also is equipped with LED’s to help with debugging and status of data transfer. A further understanding of the development board can be seen by dividing it functionally into a front end and a back end.
The front end of the Freescale development board processes data and communicates with the UII. Data processing is done with the HCS08 CPU and transmitted to the UII via Zigbee radio. The HCS08 processor formats data from the back end in a usable form the UII will understand.
The back end of the Freescale development board consists of a RS-232 communication port. This port allows for peripheral devices to be connected to the development board. Unfortunately the hardware configuration cannot be changed to accept external inputs other than RS-232. For now if a peripheral does not come with an RS-232 communication port then a converter will have to be bought or made to connect the peripheral to the Freescale development board.
Table 5: Freescale Features
|ITEM |Description |
|MCU |40-MHz HCS08 (8 bit) |
|Memory |60 Kbytes in-application re-programmable FLASH |
|RAM |4 Kbytes |
|Serial |1 RS-232 port |
|Wireless |Zigbee IEEE 802.15.4 Standard |
|Power |9 volt battery or external power supply |
|Monitoring |LED’s |
[pic]
Figure 7: Freescale Development Board
[pic]
Figure 8: Example Block Diagram for Sensor Application
7.1.3 5th Element
The Fifth Element is a bio-potential differential device that will be used in monitoring the electrical activity of the user’s heart and collecting related data that can be analyzed by a physician. Data collection is done through the use of non-invasive (surface) electrodes that are placed at strategic points on the user’s body in order to capture the heart’s sequence of activities during atrial and ventricular activation. In addition, the design is such that the user can also collect electro-myograms (recordings of other muscle activity) by flipping a switch in the circuit.
The Bio-amplifier consists of a two channel front-end device and unlike the other medical devices, the output is an analog signal and it needs to be sampled by the A/D converter on the Freescale Zigbee board before the data is formatted and sent wirelessly to the Freescale board connected to the PC.
7.1.3.1 The ECG-EMG signal properties
To collect electrocardiogram or electro-myogram readings, electrodes will be attached to the patient on the left and right arm, and also on the right leg (which acts as a reference point). Bioelectric signals are generally small signals. The various types of recordings are usually differentiated based on the frequency response of the signal.
For both the EMG and the ECG, there are many unwanted components and interferences that are collected with the signal and need to be filtered effectively in order for the correct recording to be derived. Examples of these interferences include electric/electromagnetic interference- like the noise from the power mains (that is 60Hz noise) or radar devices (televisions etc.); noise due to electrode-skin contact and changes in impedance due movements between the electrode and the skin.
These noise issues are addressed simply by using a high pass filter, low pass filter and a 60Hz notch filter.
The high pass and low pass filters form a band-pass region that varies depending on the type of signal being recorded. A decent frequency range for ECG signals is from 1Hz to 100Hz. These values are used as the cut-off values for the low-pass and high-pass filters in the ECG design. The ECG signal amplitude is usually on the order of about 0.5-5mV. EMG signals really have a frequency range from about 25Hz to around 3kHz1. However, the significant EMG signal collection frequency range is usually from 2 to 500Hz2. This design uses a pass band of 20-200Hz which is also sufficient. The EMG signal amplitude for surface electrodes is usually on the order of about 0.1-2mV.
7.1.3.2 The ECG-EMG design
A simplified block diagram of the ‘fifth element’ can be seen in Figure 9:
[pic]
Figure 9: General Block diagram of Bio-potential Amplifier.
7.1.3.2.1 Basic components of ECG/EMG Bio-potential amplifier
1. Right leg drive
2. Electrostatic discharge (ESD) protection
3. Pre-amplifier -> Initial amplification prior to filtering
4. Amplifier block
5. Power supply
Right leg drive
The right leg drive is a portion of the circuit that ensures that the user is protected from leakage currents by acting as a reference or ground point. It is connected to the right leg of the user (which is implanted on the ground). Its feedback loop minimizes the effect of common-mode voltages.
Electrostatic discharge (ESD) protection
The initial portion (i.e. at the channel inputs) of the circuit is configured to protect the circuit from electrostatic discharges. It acts as a current limiter that prevents destructive voltages from passing through to the rest of the device. In addition to this, an isolation amplifier IC is placed with the power supply.
[pic]
Figure 10: The Schematic showing the ESD protection circuit
Figure 11 is a plot of the input voltage with a DC sweep of the voltage across the electrodes. The plot indicates that the input to the ECG circuit eventually saturates with increasing voltage across the electrodes.
[pic]
Figure 11: Voltage output of the ESD Protection circuit with increasing input voltage
Figure 12 is a plot of the output voltage (ADIN1) with a DC sweep of the voltage across the electrodes. The plot shows that the ECG output voltage eventually becomes saturated (indicated by the leveling off) with increasing voltage across the electrodes.
[pic]
Figure 12: A DC Sweep analysis of the output of the ‘fifth element’
Pre-amplifier
The incoming signals from the ESD protection circuitry passes through the pre-amplifier, which is characterized by high input impedance and a low common-mode gain, before entering the amplifier block. Just as important is that it serves to provide initial amplification prior to filtering.
Amplifier block
This section of the design is responsible for signal filtration and most of the amplification. The amplifiers in this stage also provide significant amplifications of the incoming signals. The gain in this region is about 1000. This is necessary because ECG and EMG signals are very small and are usually on the order of a few milli-volts.
The amplifier block consists of two identical high pass filters and a Sallen-Key low pass filter. It is also for the above that reason that is it essential that the incoming signals be filtered efficiently. The ECG signal filters create a band-pass from 0.1Hz to about 100Hz, while the EMG signal filters create a band-pass from 20Hz to 200Hz. Many other signals easily get mixed up with the desired signal and pose a problem when recording the ECG/EMG.
After the signal leaves the protection circuitry, it passes through two major amplifiers. The amplification is split into two steps and in between them is a high-pass filter which serves to remove DC-voltage offsets. This aspect of the design is important since electric charge can easily accumulate on the surface of the electrodes used for data acquisition and end up building a significant DC voltage. Theoretical amplification would imply that such a small voltage on the order of a couple of 100mV can be amplified to give a voltage on the order of tens of volts. Without this high pass filter, it will be possible to collect data without the desired signal content.]
[pic]
Figure 13: Showing the configuration for the filters of a single channel
The high pass filters were of the first order and the desired cut-off values and chosen capacitor values were used in determining the values of the resistors needed.
[pic] (Equation 1)
The Sallen-Key low pass filter was created using the standard formulas. Various values of capacitors where chosen and used to create different configurations which were then simulated in software.
[pic]
Figure 14: Typical Sallen-Key Low pass filter*
The cutoff frequency of 100Hz (ECG) or 200Hz (EMG) was first chosen. Then a capacitor value between 100pF and 0.1 uF is chosen for C2.
C1 = 2 x C2
R1 and R2 are of equal value. R2 is calculated as follows:
R2 = 0.707 / (2 · π · fo · C2)
RA and RB are set to create the necessary gain. ( In this design, RA and RB are set to 8.2K and 100K respectively)
The configuration that resulted in the best simulation results, in terms of frequency analysis, was used for the final design.
[pic]
Figure 15: Frequency analysis of the ECG filters
[pic]
Figure 16: Frequency analysis of the EMG filters
[pic]
Figure 17: Frequency analysis for a single ECG Channel
[pic]
Figure 18: Frequency analysis for a single EMG Channel
Specifically, the resulting frequency analysis for the ECG signal shows that the roll-off is about 48dB per decade, while that of the EMG signal is approximately 40dB per decade.
[pic]
Figure 19: Portion of Signal Amplification
Some major sources of noise include 60Hz noise from the power mains, surface, noise due to electrode-skin contact and noise due to radar devices. The 60Hz noise is taken care of by the 60Hz notch filter. This filter is created by using a UAF42 chip which is an active second order filter that efficiently gets rid of unwanted noise at 60Hz frequency when configured appropriately.
[pic]
Figure 20: Schematic showing the UAF42 60Hz notch filter configuration
[pic]
Figure 21: The notch filter frequency analysis
7.1.3.2.2 The Power Supply and Isolation Circuit
[pic]
Figure 22: Schematic of the Power Supply and Isolation Circuitry
The power supply to the circuit comes from any 12V source. The 12V directly powers the UAF42 chips which require this as a minimum voltage supply value. The rest of the circuitry (other chips and amplifiers) only need 5V to operate. The 12V is voltage regulated and sent through a DC-DC converter which provides an output of 5V. The 5V is then isolated and filtered before being used to power up the rest of the circuitry. Diode D4 allows reverse polarity. The DC/DC converter powers the rest of the device and also serves to protect the user from large voltages. The inductor/capacitor networks placed before the DC/DC are filters that serve to reduce the switching noise from the converter. In addition, the 5V is used to derive a buffered 2V bias (this is achieved through a simple voltage divider) which is used to create a reference point for many of the circuit components- thus preventing the desired output voltage from swinging negative. In other words, the output signals will swing around 2V as opposed to 0V.
[pic]
The DIP SPST Switches
Since the device is intended to also function as an electromyograph, certain components were included in order to minimize the number of circuit components. For example, the use of 4 position DIP SPST switches (2 position DIP SPST switches would have been sufficient for a single channel, but there are two channels). The signal through a single channel is the same for both an EMG and ECG up until the amplifier block where the signal filtration and amplification takes place. Consequently, a DIP SPST switch is placed at the output of the pre-amplifier. The output of the pre-amplifier is connected to two of the DIP inputs (four position switches implies two DIP inputs per pre-amplifier channel). Depending on which switch is toggled on, the signal from the pre-amplifier will either be filtered like an EMG or ECG signal. However, only one switch can be toggled on at a time. Also, there is one UAF42 notch filter per channel and another DIP SPST switch is placed at the input of the UAF42 notch filters. Although there is only one signal (ECG or EMG) that is allowed through to the channel’s notch filter, the presence of so many components might pose a problem in terms of leakage currents in different parts of the circuit. To avoid the effects of leakage currents and undesired impedances, the additional DIP SPST serves to limit or localize the area of the circuit through which current flows during a particular recording.
The final output is an analog signal which is sampled by the AD converter on the Freescale board, formatted as necessary and then sent wirelessly to the Freescale board attached to the PC.
7.2 Software
Large part of the project is based on software architecture. Basically most of the data will be processed in the UII. Hence, programming the UII will be most important task.
7.2.1 UII Communications Protocol
UII’s Communication protocol will work as a push method. A user would use a medical device which would then be pushed into the UII. This will simplify the user interface on a palm pilot. The user would use they’re own medical device as they normal would then press the send data button on the palm pilot to send the data. By using the medical device will cause the Zigbee board to wake up and establish a connection with the UII and palm pilot. Once this has been established the UII will then wait for the palm pilot to signify to take data from the currently active medical device.
Each manufactured device has a unique identifier. In addition to this identification, each device is capable of reporting its data to a specified datatype and in a specific dataunit. Together called dataform. The datatype specifies the format of the binary data stream that will eventually be retrieved by the UII. For multiple-byte datatypes, the most significant bytes are transmitted before the least significant bytes. The protocol allots for 256 distinct datatypes. Current datatype includes:
1. 8-bit integer
2. 2’s complement 8-bit integer
3. 16 bit integer
4. 2’s complement 16-bit integer
5. 32 bit integer
6. 2’s complement 32-bit integer
7. 64 bit integer
8. 2’s complement 64-bit integer
9. 32 bit IEEE floating point
10. 64 bit IEEE floating point
The dataunits parameter specified the scientific units of the data. The protocol allots 256 distinct dataunits. Some of these units are:
1. Pounds (lbs)
2. Kilograms (Kg)
3. Hz (1/s)
7.2.2 UII Architecture
The UII runs a modified version of the Linux 2.4 kernel. That kernel provides for process management, memory management, device management, inter-process communication, a file system, and networking system. The UII code shall run as separate processes that shall act like Unix daemons (background processes).
The UII code is responsible for a multitude of tasks. These include:
• Establishing a connection to the Internet through either Ethernet or PPP through the modem.
• Updating the central server with the current Internet address of the UII.
• Communicating with the user interface device (PDA).
• Managing the user identities and databases.
• Implementing the UCP to communicate with the medical devices.
• Communicating with the AHMD to provide it with the information that it requires.
• Providing a web server and set of web pages and scripts to provide the physician with a user interface.
7.2.2.1 User Interface Architecture
The user interface software is responsible for communicating with the external user interface device using Zigbee development board on the UII connected through one of the RS-232 port. IT shall run as a separate process that is tightly coupled to the software that implements the UCP since the User Interface essentially drives it. Further, the user interface software must be able to access the medical database and the configuration information. Essentially, the user interface software is the backbone of the UII’s operations with respect to the user.
The software shall be constructed on the principle of a finite state machine where the particular state is driven by the functionality of the user interface as described in the functional specifications.
7.2.2.2 Medical Database Architecture
All the information of a user is stored on a mySQL database on the UII. This database will be accessed by a boa page with displays all the information on a page over the net. Access to the user database will be given exclusively to one process at a time. If the database is already held by another process, then the requesting process must wait until the other process is finished. Final database will look like table shown below:
Table 6: Sample UII Data Base
[pic]
7.2.2.4 AHMD Implementation[1]
The AHMD requires certain files to be placed in its memory in order to function as required. It is up to the UII to provide the AHMD with those files. The true source of the files is the physician who is able to provide them to the UII via the user’s homepage. Once the UII has received those files from the physician, it shall make use of its USB connection to the AHMD to transmit those files to it. The precise messaging protocol is not specified here, but the following function shall be used when attempting to transfer data from the UII to the AHMD.
First, the UII will attempt to establish communication with the AHMD. This is necessary because the two devices do not stay in regular contact. Essentially, a short ping message is sent and the AHMD software waits a certain amount of time to receive an acknowledgement. If it does not receive one within an appropriate amount of time (approximately 1 second), then it will return an error code to the process that originally requested the action. (For information on the RPC mechanism, see the UII Software Architecture section.)
Once communication has been established, the UII shall transmit the filename, the user identity, and the file length of the file that is to be transferred to the AHMD. Again, the UII shall wait for either an acknowledgement or a non-acknowledgement (in which case the file access was denied). If the file access was denied, then the AHMD software shall return an error code specifying so.
Upon acknowledgement, the UII shall transfer the data in a byte-sequential form. At the end of the transfer, it will also transmit a two-byte check sum on the file. Again, it will wait for an acknowledgement from the AHMD. If it receives one, then it will return a success code. Otherwise, it will return another error code.
7.2.2.5 Web Server Implementation[1]
The UII shall provide a web server to provide the physician with a user interface (as described in the Functionality section). The web server will not be designed as a part of this project; instead a pre-designed server shall be chosen. The pre-designed server chosen was boa.
It is required that the web server be able to run server-side scripts in response to actions taken by users of the web pages. These scripts shall facilitate retrieving external files and communicating with the appropriate UII processes to dispatch information data back to the physician. The scripts themselves shall contain no logic specific to the operation of the UII (such as the UCP protocol) but will instead rely on the individual parts of software detailed above to do those types of operations.
7.2.3 Translator Architecture [1]
The translator’s software is designed such that the programmer – whose real task is to interface with the specific medical instrument – will not be burdened with learning or debugging the UII Communications Protocol. Instead, the programmer need only learn a basic API that will be provided to them along with the translator hardware.
Installation of the API requires the programmer to invoke one initialization function, provide the required interrupt handlers, and to respond to the API’s needs through a set of callbacks. Aside from those requirements, the programmer is free to work on the interface to the specific medical instrument.
8 Software Architecture
8.1 Programming the HC(S)08
The HC(S)08 microcontroller can be accessed through 8 Analog pins, a JTAG connection and a RS-232 port. The HC(S)08 can be programmed through either the RS-232 port or the JTAG connection. To program the microcontroller through the serial port a special Test Tool application must be used. This program will load a .s19 executable file onto the board. However this program has many bugs and may cause errors during operation. The JTAG connection uses the Background Debug Module connected to the HC(S)08 and will load a .elf executable file. In order to download the executable file to the HC(S)08 a USB Multilink S08 cable must be used. This cable will interface directly with the CodeWarrior IDE to load the code onto the board. CodeWarrior IDE is the software Integrated development environment used to create, compile, and debug the code used for this project.
2. The Medical Instrument Data Output
For this project it was required to show the feasibility of home medical wireless transmission. The medical device used was a digital scale with an RS-232 output. The scale outputs data in a specific format with two header characters, 8 data characters, two unit characters, and 2 termination characters. The header characters will be ST for stable or US for unstable. The Data characters will be a ‘,’ followed by a ‘+’ or ‘-‘ for positive or negative weights, then the weight in this format “XXXX.X”. The units will be lb for pounds. The termination characters are a carriage return followed by a linefeed character. This format is shown in figure 24.
[pic]
Figure 24: Sample scale output format
The format of each transfer will have a start bit followed by 7 data bits, an even parity bit, and ending with a stop bit. Data will be sent out from the scale at a baud rate of 2400bps.
The scale and the Zigbee SARD board were both designed to be serial devices. A serial device would then be connected to a serial host, in most cases a PC. However, for this project the scale and SARD board were to be connected to each other. This posed a problem since the scale outputs data using the RD serial data line and the SARD board looks for incoming data on the TD serial data line. In order for the SARD board to recognize that there was incoming data a serial crossover cable had to be used. This cable would switch the RD and TD lines so that the scale would output its serial data on the TD serial data line, which would be noticed by the SARD board.
3. Software Organization
The software organization for this project consists of 3 projects. The 3 projects are: Select MCU Target, SMAC, and Wireless UART. The Select MCU Target is common code used to select between different Freescale Zigbee Development boards. Each one of these boards contain a different processor from the HC(S)08 family. For this project the MC9S08GT60 processor was used. The SMAC, simple media access control, project contains the common code used to access the MC13192 Zigbee transceiver. This is the code that will send out the wireless data. The Wireless UART project is the code for the main application. This code has two main files wireless UART and SCI.
The SCI (serial communication interface) files contain the code for the UART operation. There are two files, the header file (SCI.h), and the source file (SCI.c). The header file contains the all the registers for the UART. Included in this file is the baud rate definition. Since the scale uses a baud rate of 2400 the value that must be set to the SCIBDL register is D0(hex) which is calculated from equation (2).
[pic] (Equation 2)
The bus clock speed of the GT60 MCU used in equation (2) is 8MHz. This will result in a value of 208, which when converted to hex is D0.
The source file contains the functions which will send out serial data and take in serial data. The function that displays serial data is very basic and will check to make sure the UART buffer is full and if it is not it will load to the UART buffer to send out the data serially. The serial receive function is more complicated and tailored to meet the specifications of the scales output. The receive function is an interrupt handler which will occur whenever there is incoming serial data. Since the SARD board is connected to the scale via the RS-232 port all incoming serial data will come from the scale. The form in which data is sent out wirelessly does not have a parity bit therefore; the scale data must be converted into 8 bits with no parity. The only data to be saved are stable values. The header portion of the scale output will contain “ST” for stable and “US” for unstable. In both of these cases there is an ‘S’ character therefore in order to check for a stable value the code will look for the character ‘T’. If a ‘T’ is contained in the output string then the rest of the scales output will be stored on the MCU. Once all the data has been collected the code will check to see if the 4 data characters to the left of the decimal point are non ‘0’. Only the data characters to the left are checked because no person will weigh less than 1 pound and a weight less than 1 is defined to be an invalid measurement. An invalid measurement and will do nothing. If there is a valid measurement, the four data characters are non ‘0’, then a flag will be set to signify that valid data has been acquired. A visual interpretation of serial interface can be seen in figure 25.
[pic]
The wireless UART file was created in a state machine format. The states used were Receiver_Always_On, Waiting_for_ack, Transmit_data, Transmit ACK, and Timeout. On the transmitting side the states used are: receiver always on, waiting for ACK, and transmit data. The receiver side uses the receiver always on state and the transmit ACK state. The Timeout state is only used if a transmission fails and it will retry 4 times before failing.
The transmission side, the scale side, will be in the receiver always on state while there is no data to transmit. At the end of every state the code will check to see if a transmit flag has been set, indicating to switch to the transmit data state. If this flag has been set to indicate that valid data is ready to be sent then LED 1 will turn on and LED 2 will turn off (if it was on). The main system architecture of the main loop for the transmitting Zigbee board can be seen in Figure 26.
[pic]
While in the transmit data state, the receiving function is disabled to avoid conflicts on the same channel. Then the transmit data state it will check to see if button 2 has been pressed, by checking a flag. If button 2 has been pressed then the transmit buffer will be loaded with the first half of the data and a ‘\0’ character to represent the end of the transfer. Once the buffer is full it will call the SMAC project to send out the data. If the data has been sent out successfully it will then turn the receiver back on to wait for an acknowledgement. This state will then increment the index so the next time this function is called the second half of the data will be sent out. It will check to see if all the data has been sent and if it has then the buffer is filled with 0’s. This is done to prevent the user from sending multiple data transfers without taking another measurement. When the buffer is filled with all 0’s then nothing will be transmitted. In addition to clearing the buffer once all the data has been sent, the flags will be cleared and the index set back to zero. Also LED 1 will turn off because there is no data available to be sent out and LED 2 will turn on to signify that all the data has been sent out successfully. An illustration of the transmission data function architecture can be seen in figure 27.
[pic]
The waiting for ACK stage will simply wait for an acknowledgement. This is because a timeout of zero was set. Once an ACK has been received then the code will change back to the transmit data state to send out more data if necessary.
The receiver side will always be in the receiver always on state waiting for data. Once data has been received the SMAC project will call the function MPCS data indication, which will check to see what was received. If the incoming data was not ‘A’, ‘C’, ‘K’ an acknowledgement then the data received should be outputted through the serial port. This is done through the SCItransmitSTR function. This function will serially step through a string and output one character of the string through the RS-232 port. A flow chart describing the receiver code is shown in figure 28.
[pic]
Figure 28: Receiver Flow Chart
9 Bill of Materials
Table 7: The Fifth Element B.O.M
|RESISTORS: 1% metal film, 0.25W, 10mm Pitch | | | | | | |
|Amount |Value | |Components | |Manufacturing details | | |
| |2.2K | |R1-R8,R34-R41 | | | | |
| |10K | |R51,R71,R72,R18 | | | | |
| |120K | |R14,R15,R47,R48 | | | | |
|2 |10pF | |C1,C16 | | |100V, 5mm pitch, COG, Package C5 | |
|4 |100pF | |C2,C3,C17,C18 | |100V, 5mm pitch, COG, Package C5 | |
|2 |1uF tantalum |C59,C60 | | |EL25B, 35V, 2.5mm pitch | | |
|8 |1uF film | |C6,C8,C11,C13,C21,C23,C26,C28 |C-10,5% |tolerance, 10mm pitch | |
|17 |100nF | |C4,C5,C19,C20,C33-C38,C41,C42,C50, |X7R, C-5, 100V, 5mm pitch | |
| | | |C53,C55,C57,C58 | | | |
|1 |47uF tant. (1ohm) |C43 | | |ES-5, >6.3V, 5mm pitch, ESR=0.8-1.2ohm |
|4 |47uF tantalum |C46,C49,C52,C56 | |EL25B, >6.3V, 2.5mm pitch | |
|2 |0.047uF | |C15,C30 | | | | |
|6 |1nF | |C7,C31,C32,C12,C22,C27 | |X7R, C-5, 200V, 5mm pitch | |
|2 |0.1uF | |C14,C29 | | | | |
| |TLC277P | |U2,3,5-8A&B,U10,U| | | |
| | | |12 | | | |
| |TL431CLP | |U13 | | |Adjustable Volt. Reg., TO92-CL | |
| |22uH | |L1,L2,L3 | | |R-125,SRF>13MHz,Lmax>285mA, 12.5mm pitch |
| |BC547, T092 |Q1,Q2,Q5,Q6 | |NPN TRANSISTOR | | |
| |BC557, T092 |Q3,Q4,Q7,Q8 | |PNP TRANSISTOR | | |
| | | | | | |4 POSITION, DIP SPST SWITCHES | |
| | |
|PCB Boards |$105 |
|Capacitors |$40 |
|Resistors |$10 |
|Discrete Semiconductors (Diodes, BJTs...) |$4 |
|ICs |$140 |
|Sockets |$1 |
|Misc. Parts (cable connectors, electrodes, crystals…) |$60 |
|Freescale Development Board |4 x $199.10 |
|Code Warrior for HC(S)08 Microcontrollers |$150 |
|USB Multilink BDM Cable |No cost |
|TOTAL |$ 1,306.4 |
10 Citations
[1] Critical Design Report for the Universal Internet Interface; Mohammed Benmansour, Frank A. Krudger, Reuben Mathew
[2] Trends in Unlicensed Spread Spectrum Devices. FCC Commission Meeting. May10, 2001.
-----------------------
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18] Zigbee: “Wireless Control That Simply Works”, William C. Craig,
[19]
[20]
-----------------------
Figure 23: ECG/EMG Schematic
F
T
F
F
F
T
T
T
T
Data ready for transmission flag set
Check to see if SCIsave[4,5,6,7,] equals zero.
If (i) counter < 13
Put SCID into SICsave vector. Increment (i) counter.
Is the incoming data an ASCII ‘T’
Is there incoming data from serial port.
Initialize counter (i) to put data in SCIsave vector
Figure 25: Serial Input Flow Chart
Disable the receive function
If transmit flag is set
Is (j) counter between 0 and 8
Reset transmit flag
Transmit 7 data characters followed by null character in transmit buffer
Increase (j) counter by 7 for next transition
Reactivate receive function
Go to main loop
If (j) counter is 14
Clear transmit buffer and set (j) counter to 0.
Turn Off LED 1
Turn On LED 2
If ACK is received
T
F
T
F
T
F
T
F
Figure 27: Transmit Data Loop
Waiting for receive
Turn receiver on
Has data been received
Is the Data received ASCII “ACK”
Output data received to serial port
T
T
F
F
F
F
T
T
T
F
F
T
F
T
Go to transmit data function
Set transmit flag
Is push button 2 still pressed
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- reading questions
- rochester institute of technology
- google translation of tyrel de poix
- thesis proposal for master of software engineering
- advanced metering infrastructure attack methodology
- manual for the nc bqa trainer gpvec
- the in famous beginners guide to daggerfall
- smartcars and smartroads
- dc phb section 6
Related searches
- seton institute of reconstructive surgery
- michigan institute of real estate classes
- sports institute of tucson
- institute of physics iop
- institute of physics uk
- american institute of physics
- american institute of physics citation
- american institute of physics inc
- chicago institute of plastic surgery
- indian institute of public health
- nigerian institute of international affairs
- eric institute of education science