Technology

The patient box is a matchbox size electronics unit incorporating all the sensors except the SpO2 sensor, primary processing electronics, rechargeable Lithium battery and the Bluetooth radio.

The Ecg front end is an integrated Analog Front End (AFE) from Texas Instruments, that does all of the Ecg data acquisition. It also handles the respiratory impedance signal acquisition. The data is sent digitally to a Nordic Semiconductor System-On-Chip (SOC) microcomputer, that holds all memory and required I/O as well as data processing functions.

The electrode lead wires emerge from the box in the correct direction, minimizing misconnection and cable clutter. The lightweight box hangs on the Ecg electrodes (under a T-shirt or similar).

Signal processing, noise filtering and arrhythmia analysis are performed by the SOC. The Ecg functionality is tested against the relevant IEC standards for accuracy, frequency response, pacer detection and suppression, noise performance etc. The arrhythmia algorithms are separately tested against standard databases according to FDA and European requirements. Alarms include heart rate, ventricular contractions, atrial and ventricular fibrillation and ST-segment deviations (cardiac oxygenation sufficiency indicator), SpO2 level and Respiration Rate as well as minor alarms like Leads Off, Sensor Inop and Low Battery

Respiration detection is dual mode; the simpler is impedance respiration. This is done via high frequency (30-60kHz) current applied through Ecg electrodes. Lung volume changes modulate this signal, which is then analyzed for respiratory rate and sufficiency. As also the chest motions of other sources affect the signal, impedance respiration is generally considered error prone and artefact prone and not very reliable. It is convenient though, and thus widely used in hospitals.

The more reliable respiration assessment mode is nasal pressure, detected via a thin tube from nasal prongs or supplementary oxygen delivery system. This mode actually measures gas movement and is close in performance to the gold standard (capnometry or CO2 monitoring, usually not doable in a wearable format due to high current consumption and bulky form factor). The drawback of course is the tubing on the nose. However, with supplementary oxygen this is not an issue, and this is especially important as pulse oximetry is not a reliable hypoventilation detector in this case. Hypercapnia (high CO2) may harm the patient before oxygen saturation (SpO2) falls.

The pulse oximeter sensor is connected onto the top of the patient box, the sensor sleeve protecting against fluid ingress. We use ubiquitous, low cost “RCAL” (formerly “Nellcor”) sensors available widely in several disposable and durable configurations.

The oximeter signal is acquired and initially processed by another AFE from Texas Instruments. Again, it sends digitally the signal to the SOC for processing. The resultant data is the SpO2; the percentage of red blood cells that are oxygenated at the sensor site (finger or ear). Also, the plethysmographic waveform gives the pulse rate and the perfusion percentage, as well as the Pulse Wave Transit Time used to roughly estimate changes in blood pressure.

Other signals acquired are acceleration, which is used to detect patient posture, motion and motion artefacts. Also, the patient falling is likely to be detected by the accelerometer.

The SOC compares all these values to alarm limits and criteria set by the user (or the defaults). The alarms are prioritized by severity and time of limit violation, and can be adjusted and silenced by the user (operator, clinician). The essential value of having the calculation algorithms and the alarm processing on the patient box, stems from the fact that we want to use a low cost, low power commercial radio, with its limitations what comes to signal integrity and continuity. In this system, brownouts and transmission errors can be tolerated up to 20 seconds before indicating a transmission break alarm, without affecting the performance of the algorithms in noise removal or without affecting safety. Competitors here often use proprietary and/or higher power radios, leading to higher cost and shorter battery life.

The Bluetooth signal carrying all the waveforms, numbers, settings and alarms, is received preferentially by a cell phone (Android only at this time; however, the app is written in Google Flutter for multiplatform implementation) that displays a simplified user interface with Heartrate, ST-segment, SpO2 and Respiratory rate, as well as the alarms.

The cell phone needs to be within Bluetooth / Thread radio range (5-20meters), and can be carried by the patient if going e.g. to a remote cafeteria…

The cell phone relays the data onto a Wi-Fi network for transmission to a local intranet or using standard mobile data, depending on how it is configured, e.g. Internet/VPN for home monitoring.

Optionally, we have a Bluetooth or Thread (IEEE 8.2.15.4 standard mesh network) USB dongle for direct transmission to a PC.

The PC Central Station is the primary user interface for displaying the Patient Monitor UI. The UI is modelled according to existing commercial patient monitors with well-rehearsed usability. Up to 16 patients can be viewed, preferably on two high resolution screens.

The PC is also used to configure the system, setting bed numbers, patient ID’s, alarm limits etc. It also has an archiver that manages the data of the patients and allows for off line viewing and printing of discharged patients. Conversion of data to public formats for research is supported.

Disruptive technology: On the surface, the wearable monitor is just as a high-end monitor. The Important innovation is that in a general ward setting, a general high-end monitor in not good enough. Our wearable monitor runs equivalent performance of a high-end patient monitor, with the computing infrastructure of a PC (typically Linux) on a 4 USD single chip SOC. This means that the algorithms (e.g. Fourier transform spectrum analysis of the pulse oximeter signal) must be highly optimized to be able to run on a processor consuming less than 30 mW of power.

Alarm logic: A major cause of problems in a clinical setting is false alarms, and false alarms have been classified as one of the most distracting nuisances in hospitals for many years. In an operating room or intensive care, clinicians accept this (albeit grudgingly), as nurses are at the bedside all the time. For general wards, this has been one of the main reasons continuous ward monitoring has so far not been accepted by the nurses. Thus, to be a viable product in a ward, nuisance alarms must be kept low. First, of course, this means that the numbers (HR, SpO2...) have to be correct in spite of the patient moving, eating etc. Next, the alarm logic must be advanced; trending alarms must be treated differently from sudden crashes, and combinations of alarms (e.g. simultaneous low SpO2 and ST-segment deviation) must be boosted in priority. Bad signal quality and motion usually allows delaying the alarm or keeping the priority lower (according to IEC60601-1-8 standard alarms are typically classified with different priorities, i.e.-: Info-Low-Medium-High priority).

IP: The primary approach in IP management is to hide the design details by encrypting the algorithms of the patient box. We have reviewed the patient monitoring patent field in order to guarantee freedom to operate. All of the patents in use have been long timed out and are in general use in the patient monitoring business. Minor details will be considered for patenting, but we do not expect to rely on patents; the business is quite mature technically, and the best way to protect our algorithm is to hide their implementation. Some technical solutions in respiratory monitoring have been avoided due to patent issues, but without significant impact on the functionality and performance.

Summary: The technical advantage of the wearable monitor is not really in the general functionality. The device essentially duplicates the features of a mainstream high end patient monitor in a small low cost, easy to use, wearable format. The technology selections are all geared towards enabling the use of reliable, wearable, nurse friendly general ward monitoring. The reason why this has not been done previously, is that it is very difficult. All the algorithms are written in plain C language and tuned towards compactness, speed and low power usage. This code is proprietary and cannot be retrieved even in binary form from the SOC. The Central Station PC, on the other hand, is written in JavaScript for easy web integration, as power consumption or speed is not an issue. The short range radio transmission protocol was a major undertaking, to be able to transmit all the required data with minimal bandwidth utilization and power use.