GB2598568A

GB2598568A - Patient monitoring device

Info

Publication number: GB2598568A
Application number: GB2013692.5A
Authority: GB
Inventors: Allingham Passmore Hugh; Chef Samuel
Original assignee: Clini Hub Ltd
Current assignee: Clini Hub Ltd
Priority date: 2020-09-01
Filing date: 2020-09-01
Publication date: 2022-03-09
Also published as: GB202013692D0; WO2022050899A1

Abstract

A patient monitoring device 230 includes first and second sensors for measuring a physical parameter of the patient 220 at two separate locations. The outputs of the sensors are used to determine the physical parameter and calculate a priority score which is displayed on a display 234. The device 230 may be worn on a patient’s forehead 221, and may be used for casualty triage. The sensors may be pulse oximetry sensors in compartments (1213, fig 12a) on opposite sides of the subject’s forehead or fingertip PPG sensors (1530, 1532, fig 15b). There may be a control panel 231 to allow a clinician to input observations. The patient priority score may be displayed as a red, yellow or green LED 233 on the device. The priority score may be continuously updated based on the measured data. The sensor outputs may be communicated to a server and displayed on a Clinician Control Dashboard (fig 8a) to rank patients in a patient priority table.

Description

PATIENT MONITORING DEVICE

TECHNICAL FIELD

The present disclosure relates to wearable patient monitoring devices and in particular for devices for use in a triage system.

BACKGROUND

The main factors driving change in patient monitorino are focused around reducing healthcare service costs where possible while at the same time improving the standard of care provided to patients. The rise of mass patient data capture for the purpose of managing patient conditions and well-being has been accelerated by the Covid-19 pandemic and a need for re,lated medical response infrastructure. Ubiquitous monitoring, predictive analytics, machine learning and artificial intelligence have all taken off in recent years. The focus on managing large cohorts of patients and scaling up of data/telemetry capture is set to grow considerably. The move from periodic monitoring to continuous (remote) monitoring allows for clinicians to free up their time to focus on more time critical interventions while reducing the burden on an already over-stretched system. The ability of clinicians to intervene earlier in the detection of acute and chronic serious illnesses whether pre-hospitai or in-hospital will reduce number of presentations/admissions and length of hospital stay, pivoting the focus on cheaper outpatient and community care infrastructure.

SUMMARY

According to an aspect of the present disclosure a patient monitoring device is provided. The patient monitoring device is configured to be worn by a patient. The patient monitoring device comprises: a first sensor arranged to measure a first physical parameter at a first location on the patient; a second sensor arranged to measure the first physical parameter at a second location on the patient; a processor configured to process signals indicative of the output of the first sensor and the output of the second sensor, determine an estimated value for the first physical parameter using the signals indicative of the output of the first sensor and the second sensor and calculate a patient priority score for the patient using the estimated value for the first physical parameter of the patient; and a display configured to display an indication of the patient priority score for the patient.

The patient monitoring device forms part of a mass patient monitoring system for both ambulatory and non-ambulatory patients alike within the pre-hospital and in-hospital care contexts. The ability to effectively continuously capture and compile large amounts of patient physiological data for assessment and intervention can greatly improve clinical outcomes, while reducing clinician overburdening. Using appropriate wearable patient monitoring devices and related software can help manage a patient's condition in the absence of a clinician. Such monitoring devices can improve the management of patient conditions through intelligent data compilation and risk assessment. The system management only requests or flags clinician interventions as and when required. Location tracking on the wearable patient monitoring devices allows for reduced time to intervention as the clinician can track the patient's location and distance to a designated point of care gee-fence. The proximity of the wearable patient monitoring device to the designated point of care gee-fence (treatment location) will indicate a time risk to clinician intervention.

A triage system may comprise the wearable patient monitoring device and a computer implemented method for patient prioritisation, generating a risk assessment based on specified health parameters through one or more sensors on the device (e.g. heart rate risk due to low beat rate). Further definition may be added to the risk assessment via the inclusion of manual observation inputs via an input control panel on the device or a paired mobile user device application interface (e.g. Glasgow Coma Score assigning patient's alertness level). The health risk assessment system is derived from sensor data from the wearable patient monitoring device, manually inputted health parameters on the wearable patient monitoring device, manually inputted health parameters from a paired user mobile device; and/or manual inputted health parameters and information via a fixed user clinician dashboard on the system. As an aspect of this system the user devices have the functionality to initiate visual alerts when threshold rules are breached. Alert information is configured into notification messages which are transmitted to the display screen of the relevant paired mobile user device and fixed clinician dashboard device. Another aspect of the invention allows the user device to act on alert information by initiating a visual call/page message on the wearable patient monitoring device to proceed to point of treatment area In an embodiment, the patient monitoring device further comprises an input device configured to receive a user input indicative of at least one observed physical parameter of the patient and the processor is configured to calculate the patient priority score for the patient using the estimated value for the first physical parameter of the patient and the at least one observed physical parameter of the patient.

In an embodiment, the patient monitoring device further comprises a communication interface configured to receive a user indication indicative of at least one observed physic a-11 parameter of the patient from a user device, and wherein the processor is configured to calculate the patient priority score for the patient using the estimated value for the first physical parameter of the patient and the at least one observed physical parameter of the patient The first sensor and the second sensor may be pulse oximetry sensors.

The first location and the second location may be symmetrical positions on the patient.

For example, the first location and the second location may be on the forehead of the patient.

The patient monitoring device may comprise a third sensor and may comprise further additional sensors. The third sensor may be, for example, a temperature sensor or a galvanic sensor.

The patient monitoring device may be configured to be worn a primary position on the patient and on a secondary position on the patient The primary position may be the on the forehead of the patient. The secondary position may be on a hand of the patient.

A pocket or pouch may be provided on the patient device configured to receive a fingertip of the patient is provided in the vicinity of the first sensor.

The patient monitoring device may be provided with an adhesive portion to secure the patient monitoring device to the patient. The patient monitoring device may be provided with specialist skin-sensitive adhesive strips arid elasticated band supports to secure the main device embodiment around the forehead and temples. In such a configuration, the core processing unit together with an instructional LED screen sits at the centre of the forehead. Two operator buttons and a three-setting switch are attached to the left flank of the central unit. The sensor (trades, device memory and processing unit will be contained within the central unit. Adhesives and supporting elasticated bands will keep the device in place, securely fixing the device onto the patients forehead during supine or ambulatory comportment. It is important to note that the above description refers to the example of the apparatus being secured around the forehead and temples; however, the device can be alternatively used on different high blood flow nodes around the body.

The patient monitoring device may be provided with a counterfoil overlaying the adhesive portion, wherein the device is configured to activate on removal of the counterfoil.

The patient monitoring device may be provided with a strap configured to secure the patient monitoring device to the patient.

The patient monitoring device may further comprise a communication module configured to send the signals indicative of the output of the first sensor and the output of the second sensor to a server.

The patient monitoring device may further comprise a battery module configured to supply power to the patient monitoring device. The patient monitoring device may have a disposable portion comprising a cover and the battery module; and a reusable portion comprising the first sensor, the second sensor, the processor, and the display.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, embodiments of the present invention will be described as non-limiting examples with reference to the accompanying drawings in which: FIG.1 is a flowchart showing an exemplary method using a patient monitoring device according to an embodiment of the present invention FIG. 2(a) shows an example deployment of a patient monitoring device according to an embodiment of the invention; FIG. 2(b) shows a graphical rendering of a patient monitoring device according to an embodiment of the present invention; FIG. 3 is a block diagram showing functional steps in the processing of data from a patient monitoring device according to an embodiment of the present invention; FIG.4 is a block diagram showing the basic network architecture for the deployment of the patient monitoring device according to an embodiment of the present invention; FIG. 5 is a block diagram showing a schematic of the functional blocks of a patient monitoring device according to an embodiment of the present invention; FIG. 6 is a table illustrating a dynamic Cloud Database population snapshot of patient physiological Data, location data, related risk assessment calculations and device ID reference data from a group of patient monitoring devices according to embodiment of the present invention; FIG.7 is a table illustrating a dynamic Cloud Database population snapshot of Machine Parameter Data from a group of patient monitoring devices according to an embodiment of the present invention; FIG. 8(a) shows the Clinician Control Dashboard (CCD) Graphical User Interface used 30 with embodiments of the present invention; FIG. 8(b) shows a display of a patient monitoring device according to an embodiment of the present invention; FIG.9 shows exemplary Geo-Fenced Hospital Perimeter and Specialist Treatment Zones for a patient monitoring device; FIG.10 illustrates an exemplary Database populated with Reference Data for use in a system for a patient monitoring devices; FIG.11 is a block diagram showing the processing of data from patient monitoring devices; FIG. 12(a) shows the configuration of a disposable/reusable head wearable patient monitoring device according to an embodiment of the present invention; FIG. 12(b) shows the configuration of a disposable/reusable head wearable patient monitoring device according to an embodiment of the present invention; FIG. 12(c) shows the configuration of a reusable head wearable patient monitoring device according to an embodiment of the present invention; FIG. 12(d) shows the configuration of a reusable head wearable patient monitoring 20 device according to an embodiment of the present invention; FIG. 13 (a) to 13 (i) illustrate configurations of patient monitoring devices according to embodiments of the present invention; FIG.14 (a) to FIG.14 (d) show the ergonomic design of patient monitoring devices according to embodiments of the present invention; and FIG.15 (a) to 15(c) illustrate a patient monitoring device according to an embodiment of the present invention having an alternative application node.

DETAILED DESCRIPTION

The present disclosure relates to a wearable patient monitoring device. The patient monitoring device works with a database and software for triage assessment and enhanced mobile patient risk assessment monitoring. The patient monitoring device may be worn by ambulatory and non-ambulatory patients. In some embodiments, the patient monitoring device is GSM, Bluetooth and LoRa (Long Range)-enabled. The patient monitoring device comprises sensors for measuring directly measurable health parameters and indirectly monitored or derived health parameters. Parameters such as blood oxygen (SP02), Heart Rate (HR), Respiratory Rate (RR) and skin surface temperature (TEMP) are captured via continuous monitoring device sensor data. Glasgow Coma Score (GCS) and Systolic Blood Pressure reading (BP) may be manually inputted via a clinician control panel or mobile device API or computer desktop dashboard. The patient monitoring device is configured to generate data and communicate the data to a risk assessment prioritisation software system. The risk assessment prioritisation software system carries out its dynamic assessment by combining (i) continuous health parameter monitoring (using a range of sensors) with (ii) periodic manual clinician observations and (iii) patient location tracking data. The wearable patient monitoring device can be used in an individual patient monitoring and health risk assessment scenario or configured to a priority queuing system with respect to multiple patient monitoring: when presented with a cohort of patients wearing the patient monitoring devices. For each patient monitored and triaged in this way, they are assigned priority score and their risk assessment level is continuously refreshed through the database being dynamically populated with updated real-time health data. Included in the device software is a patient "Early Warning Score" (EWS) calculation. The efficacy of the priority score and EWS is dependent on the composition and number of health parameters available for measurement: the continuous monitoring sensors give a provisional priority score, whereas as the continuous monitoring sensors, together with the manually inputted parameters give a complete triage priority score. Non-health parameter sensors on the wearable patient monitoring device may provide location tracking and accelerometer data as well as device systems diagnostic data. The device provides risk assessment information relating to physiological telemetry, alert thresholds and health monitoring software to recognise pattern variance in physiological parameters. Alerts are fed from the wearable patient monitoring device through cloud infrastructure to a network enabled clinician control dashboard for subjective risk assessment and intervention assessment decisions. Where available the wearable patient monitoring device can be paired with the clinician control dashboard through a direct enabled Bluetooth (LE) connection or mesh-network enabled BLE relay system or LoRa communication or via a GSM enabled cloud infrastructure or VVi-Fi connectivity hub.

The presented wearable patient monitoring device technology proposition is designed around the National Ambulance Resilience Unit's Triage Sieve model and the Royal College of Physicians', National Early Warning Score paradigm. The innovation is led by principles and standards of triage, assessment and early warning systems as set out by the United Kingdom's National Health Service. The goal is to automate as much of the medical practitioner's 'non-subjective' workload as possible via a smart 'e-triage' system (Internet enabled) and wearable patient monitoring device. The second part to this approach is the logging of the e-triage information seamlessly to a clinician control dashboard interface (and where required integrating with hospital electronic patient records). The third aspect of our approach based on the data sets compiled; is to improve our e-triage system through using machine learning to refine and update the priority care risk assessment system.

Pre-Hospital Care major incident example: The initial frontline assessment is based on a triage sieve and allows clinicians/medics to assess and assign a provisional priority status based on initial observations. This is the point at which the wearable zo patient monitoring device is deployed, activated and locked onto the patient; it is the starting point for patient monitoring system data sets. Due to lack of historical data at this point; the clinicians initial subjective assessment is a significant factor. First responders can use the priority override button on the device, to assign an initial priority status, indicated on the wearable patient monitoring device manual input control panel.

This initial partial score from the treatment frontline allows the patients to be separated at the Casualty Collection point, and the highest severity patients will be given priority attention at Casualty Clearing Station, (usually between the inner and outer cordons of the incident site). At this point a second (fully comprehensive) assessment, treatment and stabilisation is carried out by either a paramedic; clinician or mobile medical teams on scene. While medical practitioners cannot be everywhere at once, e-triage protocols continue to monitor chances in patient physiological stress levels in the absence of medical personnel. The primary and ancillary algorithms developed are derived from the previously mentioned triage rules, the priodty score system allows for seamless priority queuing and automation.

Embodiments of the patent monitoring device may include the following features: 1. Visualisation of priority Score: From telemetry compiled by the wearable patient monitoring device, each patient is assigned a colour-coded provisional score/priority status based on the severity of the initial observations (Highest Priority=RED, Medium Priority=YELLOW and Lowest Priority=GREEN). The assigned priority colour is Lo visualised via LEDs on the device.

2. Unique duel sensor bi-symmetrical cradle format allows for data to be compiled in tandem (right & left), reducing data intermittency, improving data resolution and calibration quality.

3. The novel location of sensors at the temples and forehead, allowing sensor readings directly from the proximal blood flows to and from the brain. The brain is the most vital organ to protect in clinically critical situations.

4. Priority Score software and interface platform: information presentation and score-carding of telemetry for the e-triage sieve is conducted via our algorithm and two-way information flow.

5. Dataflow Methodology: Using unique continuous monitoring device to compile and sieve vital medical data into decision software creating a dynamically changing priority treatment table.

6. Resource Management: The data-informed triage sieve uses a uniquely tabulated interface to redirect medical practitioners and resources to patients most in need (highest up the priority table receives clinical invention the fastest).

7. Geo-fencing of patient locations, tracking medical personnel entry into the patient's treatment zone and notifying command module when subsequently exiting again.

8. Smart initialisation of device. Wearable patient monitoring devices initialise upon removal of outer packaging. The devices are aware of when they attached to a patient and when they are not, no "ON/OFF" button is necessary. Ease of use for medical respondent.

9. Specialist materials allowing the device to function in hostile environments.

10. Ergonomic design development for patient comfort and data-flow stability. 10 11. Format and System Design means minimal training is needed for medical practitioners to operate the wearable patient monitoring devices and interface.

12. Manual input and override toggle for subjective observations by medical practitioners -ensuring the primacy of human observation as a parameter.

13. Adaptability for required functionality and client specifications, select/de-select specific sensors and configurations. This incorporates modular build and selection of components and materials from a listed set of composite layups.

14. Disposable and non-disposable versions.

15. Protective replacement hygienic cloth outer glove for device reusability.

16. Node configuration and format -the wearable patient monitoring device is designed to minimise intermittency and signal disruption to sensors in monitoring ambulatory patients.

An operational example for a cohort of unknown patients presenting at an emergency department: As members of the public present at an Emergency Department, there are a number of queried conditions that will be assessed with varying degrees of severity and urgency. A critical risk factor is time in such scenarios. Patients can display a reduction of condition severity over time, or equally during the same period they can display symptoms that warrant more urgent clinician attention than indicated during the initial patient assessment. The (health parameter) wearable patient monitoring device and software being presented in this disclosure transmit to a cloud database and clinician control dashboard. The priority software can rank patient severity and present the information in the form of a priority queuing system accordingly. The devices also transmit the patient location for prompt intervention where required. The device continuously monitors key patient health parameters (both through sensor monitoring and manually inputted clinician observational scores). The health parameters being measured are not static and continuous change over time; therefore, neither do corresponding risk assessment rankings remain static. The device integrated assessment software moves patients dynamically up and down the priority queue with patients exhibiting the most immediate and severe health parameter risks been tended to as a matter of priority -optimising the use of available clinician resources.

FIG.1 is a flowchart showing an exemplary method using a patient monitoring device according to an embodiment of the present invention. The method starts 101 when a patient with a medical condition presents to frontline medical worker (first responder/triage nurse/paramedic/clinician) who is trained in the deployment of the patient monitoring device. At the initial point of assessment the frontline medical worker (in this case we assume is a clinician) checks if the patient is currently wearing a patient monitoring device or not 102. If the device is absent from the patient, the clinician proceeds to unpackage a new device 1021 in the process initialising and securely affixing the patient monitoring device to the centre of the patient's forehead 1022 or any suitable location if the patient' s conditions prevent it. At this point the clinician may decide to include manual observations (to enrich the triage assessment information) or chose to limit the data set to the automated computational health parameter assessment compiled by the wearable device sensors 103. As part of the clinician's manually input observations 104 to build a full patient priority assessment, he/she may include a systolic blood pressure reading and Glasgow Coma Score (Consciousness score) as well as further observable health parameters; inputted via device's manual input control panel. The manually inputted parameters 104 if included in the assessment are combined with the automated health parameter data from the wearable device sensors and included with location data from the device sensors. A risk assessment in the format of a full Patient Priority Score is calculated based on the combined manual and automated health parameter data observed or a partial Patient Priority Score calculated exclusively on the automated data sets 106. The health parameter data as well as device location data is transmitted to a main central system 107. From the main central system, the patient's information and priority ranking is updated in the context of other patient information, visualised in the care receiver priority list 108. The Priority Score is based on the severity scores of a range of health parameters captured by the patient monitoring device and is included in the context of the distance of the wearable monitoring device to the designated point for clinician intervention. After the required monitoring period has elapsed for the clinician to make an informed decision, the patient is either (i) been given the discharged order 109 and the wearable patient monitoring device collected and disposed of via a dedicated disposal system 110, (ii) the patient is admitted to a hospital ward for specialist treatment 1091 and the wearable patient monitoring device collected and disposed of via a dedicated disposal system 110 or (iii) the patient is not admitted to a hospital ward for treatment 1091 but instead reassessed by the clinician for continued monitoring and updates inputted for manual health parameter observations 103. Once the wearable patient monitoring device is collected 110 may automatically power down after a 10-minute time interval without valid health parameter sensor readings 111 or manually by the worker collecting the patient monitoring device.

FIG. 2(a) shows an example deployment of a patient monitoring device according to an embodiment of the invention. As shown in FIG.2(a), a subject 200 wears the patient monitoring device 210 on their forehead. The patient monitoring device 210 transmits data wirelessly 211 for further processing and analysis.

FIG. 2(b) shows a graphical rendering of a patient monitoring device according to an embodiment of the present invention. The patient monitoring device 230 has control panel 231 which includes an input device configured to receive user input from a clinician. The control panel 231 is provided as a moving flap. The clinician may input observations via the input device. The main body 232 of the patient monitoring device 230 is configured to adhere to the skin surface of a subject 220 via adhesive medical gel components. A visual indicator 233 is provided at the lower edge of the main body 232 of the patient monitoring device 232. A display 234 is superimposed over the main body 232 of the patient monitoring device 230. The display 234 is provided to interact and inform the clinicians or care givers based on inputs given through the control panel 23. As shown in FIG.2 (b), the primary point of application of the patient monitoring device 230 on the subject 200 is across the centre of the forehead 221 of the subject 200 FIG. 3 is a block diagram showing functional steps in the processing of data from a patient monitoring device according to an embodiment of the present invention. The method 300 comprises monitoring four or more health parameters 310. The parameters may include heart rate, respiratory rate, blood oxygen saturation, and temperature. These parameters are captured from the sensors on the patient monitoring device and are used to calculate a partial priority score 310 (availability of further health parameters including Glasgow Coma Score and systolic blood pressure are indicative of a full priority score). Location tracking of the wearable patient monitoring device is captured via sensors on the device and is observed in conjunction with pre-determined reference data for the geo-fenced network 320. From this information the patient distance to point of care risk assessment is calculated 330 and transmitted together with the health parameter data and partial priority score to the main central system. This information populates the main central system together with information from a cohort of further patient monitoring devices generating a priority table and queuing system which is viewable by clinicians via a graphical user interface-dashboard 340. The priority table is dynamically refreshed as updated data is fed into the main central system, timely alerts and appropriate intervention prompts are generated on the clinician interface-dashboard based on pre-defined system rules and thresholds 350.

FIG.4 is a block diagram showing the basic network architecture for the deployment of the patient monitoring device according to an embodiment of the present invention. In a local deployment scenario, the patient monitoring device 401 is deployed in an environment equipped with dedicated infrastructure (e.g. hospital department or service) to acquire, transmit, store, process and interact with the data captured by the patient monitoring device 401 through its own local network. A cohort of patient monitoring devices 401 may be connected to a local mesh node 402 that acts as a buffer to receive data captured by the patient monitoring devices 401. The local mesh node 402 may be either a dedicated device or may be a patient monitoring device not deployed onto any patient and which has the specific role to act as a local mesh node. A local hub 403 enables the interaction between a dashboard device 404 held by the care giver and the cohort of patient monitoring devices 401, even if there are out of wireless communication range of the dashboard device 404. If a patient monitoring device 401 is in range of the dashboard device 404, it can directly interact with it to display current information about the patient equipped by a patient monitoring device 401. Data transiting through the local hubs 403 are then collected by the central hub 405 which is the local network central point. The central hub 405 computes the update of patient priority score, generate update order to all patient monitoring devices 401 and transmit them to the patient monitoring devices 401 through the local hub 403 and the local mesh node402. Finally, collected data and patient history may be uploaded to a reference database 408 via a server 407 via the Internet. In a global deployment scenario 406, for instance an emergency field where an accident or disaster has just occurred, the patient monitoring device 401 will connect directly to a global mesh node 406 through either GSM or LoRa before transmitting collected data to the server 407 and the reference database 408.

FIG. 5 is a block diagram showing a schematic of the functional blocks of a patient monitoring device according to an embodiment of the present invention. As shown in FIGS, the patient monitoring device 500 comprises a manual input interface 501 that enables the care giver or clinician to enter observed patient health parameters. These parameters may include the respiratory rate, systolic blood pressure or Glasgow coma score. Inputs entered into the manual input interface 501 are monitored by a logic controller 502 which acts as a relay with a main processing unit 507 and a display controller circuit 504. Once entered, parameters are stored in the embedded device memory 508 and are further used by the main processing unit 507 to compute a severity score and a priority score or other score relevant to the triage of the patient. If requested on the manual user interface 501, the logic controller 502 may execute specific orders such as sending a display request to the display controller 504. A display system 503 shows the information requested or inputted through either the manual interface 500 or through a digital dashboard device 404. The digital dashboard device communicates with the patient monitoring device 500 by either a wired or wireless connection. The display system 503 may include a set of status LEDs 514 of different colours that displays the state and priority of the patient as computed by the device. The display controller 504 interacts with the main processing unit 507 to access data stored in memory 508 or send instructions through one of the communication channels, either wired communication 509 (e.g. USB) or wireless communication 510 (e.g. Bluetooth LE, LoRA). The manual input interface 501 also allows the care giver to directly input a priority score if patient state requires it (e.g. high severity injuries). The care giver must then manually enter in a time during which the patient monitoring device 500 cannot downgrade the patient priority score and status but only increase it (e.g. from medium emergency to high emergency state). A cohort of sensors 505 acquires various health parameters and signals. Typical examples of monitored signals include Sp02, body temperature, galvanic skin response or electro-cardiogram. The same parameters can be measured by several sensors simultaneously (referred hereafter as tandem signal/waveforms) to mitigate estimation errors provide a better monitoring. Discrepancies in phase and amplitude between tandem waveforms may also provide further insights on patient's conditions, which in turn will help in diagnosis. Electrical signals generated by the sensors 505 are pre-processed to the required conditions and format for the main core and processing unit 507 by a dedicated circuitry 506. The main processing unit 507 processes the signals acquired by the sensor 505 to compute and/or update the priority and severity scores. Typical processing includes but is not limited to the selection of the best signals for update of priority/severity score (e.g. the same parameter is measured by multiple sensors but some sensors exhibit poorer signal to noise ratio); averaging of signals provided by sensors measuring the same physical parameters; measure of delays between waveforms from sensors acquiring the same parameters; detection of respiratory and cardiac rate (i.e. computation of photoplethysmography derived heart rate and heartbeat waveform). The processing unit 507 may also execute implementations of signal processing and machine learning algorithms to extract signal features that have been previously identified in a database to be related with specific conditions. If the scores reach pre-defined threshold values, the LED display 514 is updated accordingly and an alarm notification is sent to the dashboard device. If overhead allows it, the digitized signals are sent to a main server through the wireless or wired communication circuits 510 and 509. Otherwise they are temporarily stored onto the on-board memory 508 before being transmitted to the server. Scores computed by 507 are also stored in the 508. The wired communication circuit is composed of a signal pre-processing circuit 511 that shapes the signals to required format for the frontend wired communication circuit 510. The wireless communication circuit is composed of a signal pre-processing circuit 513 that controls and shapes the signals to required format for the wireless communication frontend circuit 512. The front end circuit 512 emits to and receives signals from the main server.

A dedicated circuit 515 supplies power to all the other parts of the device.

FIG. 6 is a table illustrating a dynamic Cloud Database population snapshot of patient physiological Data, location data, related risk assessment calculations and device ID reference data from a group of patient monitoring devices according to embodiment of the present invention. The raw data for each specific health parameter sensor 621 is processed on the patient monitoring device, stored locally on the device memory and transmitted together in health sensor data packets to the cloud based central system 600. Similarly, raw location data is processed in conjunction with location reference data into patient tracking information 650 on the patient monitoring device, stored locally on the device memory and transmitted in output formats 651, 652, 653.

The periodic control panel inputted manual observations can be inputted at erratic time intervals and sometimes might not be inputted at all. However, when this data is inputted it is stored on the patient monitoring device, and the data is also stored locally on the device memory and transmitted together in manual observation data packets 630 to the cloud based central system 620. The Priority Risk software 640 uses health sensor data 620, clinician observation data 630, patient location data 650 and device activation time lapse data 654 to arrive at Priority Score 1 641 and Risk Assessment Score 2 642. All data transmitted to the cloud is tagged with a fixed label parameter 610 which links all the aforementioned cloud data and calculations to a specific wearable patient monitoring device ID exampled by four devices 612, 613, 614, 615.

Observation score 2 631, Calculation 2 643 and time lapse value 655 from the compiled cloud data are all linked to a specific device ID 615.

FIG.7 is a table illustrating a dynamic Cloud Database population snapshot of Machine Parameter Data from a group of patient monitoring devices according to an embodiment of the present invention. Similar to FIG. 6 described above, the machine data is transmitted to the central system cloud infrastructure in sub-packet categories of battery health indicator data 720, network health indicator data 730, BLE (Bluetooth) connection status indicator data 740. As the patient monitoring device both transmits and receives data packages via a network or cloud infrastructure to a clinician dashboard device, the machine data is displayed via the graphical user interface Machine Data Dashboard tab 801 of the Clinician Control Dashboard 800 which is described below with reference to FIG.8. Label reference data categories 710 and 750 are used to identify originating device and destination device for the transmitted data packets (e.g. from the wearable device 712 to the clinician dashboard 752 and vice versa). The Machine Data Dashboard tab 801 on the Clinician Control Dashboard 800 provides a visual representation of the wearable device, power consumption, connectivity status, data flow status as well as related alerts 724 for system errors and outages FIG. 8(a) shows the Clinician Control Dashboard (CCD) Graphical User Interface used with embodiments of the present invention. The Graphical User Interface 800 provides a remote user tool whereby a clinical user gains access to patient telemetry 816 via a specified graphical user interface (GUI) module 800. The module provides to up-to-date patient health parameter data 810, 811, 812, 813, 814 captured by a patient monitoring device which is presented in the context of a cohort of devices 838 in a patient priority table 803 format. Through this graphical user interface patient priority table 803, the clinician has access to an overview of a cohort of patients active on the system through the active device ID 839, and information appropriate for decision-making. The information included in the tab 803 specifies patient priority ranking 821, 823 patient telemetry 810, 816, priority scores 820, 822 patient location tracking 831, 837, patient paging interactive features 830, 836 and alert notifications 832, 833. The patient priority table 803 tab allows data to be sorted into presentable and actionable information for clinicians. The Machine Dashboard 801, Network Interface 802, and Patient System Geo-Telemetry 804 tabs provide presentable and usable information in the form of non-health parameter data from the patient monitoring device.

FIG. 8(b) shows a display of a patient monitoring device according to an embodiment of the present invention. The Device Manual Display Dashboard (MDD) Graphical User Interface 840 is a device-edge graphical user interface that displays selected manual observation inputs for patient health parameters: systolic blood pressure or Glasgow coma score 841, their related numerical value 843 and the confirmation of the selected value 845. FIG. 8(b) also shows the manual input/override 815 of the patient priority score displayed on the viewer 842. The confirmed manual inputs are then transmitted to the central system and Clinician Control Dashboard (CCD) 800 shown in FIG. 8(a) on its next data refresh. Health parameter alert information is displayed on the viewer 842 in the event of a breach in sensor reading thresholds 847, 848. Machine parameter alerts may also be triggered and displayed on the MDD viewer 840 for low battery, loss of network, location, or Bluetooth signal 849.

FIG.9 shows exemplary Geo-Fenced Hospital Perimeter and Specialist Treatment Zones for a patient monitoring device. Using reference data for geo-fence treatment zones allows for efficient tracking of ambulatory patients with patient monitoring devices. The use of GPS (for outdoor) or BLE or RFID to define a geographic location 918 for a patient monitoring device within a specific geo-fenced zone 912 at any particular moment in time, allows clinicians to evaluate distance and time to a designated treatment point 913, 916. For wearable patient monitoring device tracking a combination of methods can be deployed specific to Bluetooth technology: Proximity (range based location estimation), trilateration (distances from multiple known positions, received signal strength indicator), fingerprinting (measure signals across the building and store on reference database), and movement (estimated relative movement from device sensors). Should the proximity of a patient monitoring device's geo-location, for example 917 be within one meter of a designated treatment point 916 geo-location, it can be inferred that the patient is receiving clinician medical attention. For exemplary purposes: equally should a patient be outside a treatment zone 914 but still within the confines of hospital facilities 915 and the broader geo-fenced area 919, then in the situation where urgent intervention is required, or where the patient is needed back at a designated treatment point, minimal time is lost to the patient retrieval process. The geo-fenced hospital perimeter rules mean notifications and alerts will be sent to the client control dashboard should a patient's geo-location exceed the boundaries 910 of the hospital geo-fence area limits 919. The wearable patient monitoring device location tracking attributes improves patient monitoring management while allowing for more freedom of movement for patient cohorts.

FIG.10 illustrates an exemplary Database populated with Reference Data for use in a system for a patient monitoring devices. The selection of reference data is determined by the wearable patient monitoring device sensor data. The reference data is separated into directory categories which define the contextual information for patient care. The main reference categories are as follows: general care category 1010, wearable device type 1020, responsible clinician directory 1030, local treatment centre 1040, specialist treatment sub-centre 1050, point of care (geo-location pin for treatment) 1060. The wearable device category is derived directly from the wearable patient monitoring device ID linked to machine data transmission to the cloud database 700. General care category 1010, local treatment centre 1040, specialist treatment sub-centre 1050 and point of care pin 1060 are all defined via a pre-loaded reference data 408 from a geo-map. The correct reference data selection 1013, 1041, 1051, 1061 is determined by the wearable patient monitoring device rules relating to the device geo-position. The selection of a responsible clinician remains blank unless a specific clinician is selected from the reference data database and assigned through the graphical user interface: clinician control dashboard, patient system geo-telemetry tab.

FIG.11 is a block diagram showing the processing of data from patient monitoring devices. In the system 1100, sensor data 1110 is provided by a patient monitoring device to clinician or user dashboard devices running the base software module 1120, this may be done through direct connection (see FIG. 5 data flow 401 to 408) or via a local mesh node or local hub for a local deployment or via a global mesh node to the internet for global deployment then on to the local network central hub. Manual Data 1111 is also provided in a similar way to the sensor data 1110, however manual data may originate either from a patient monitoring device(s) or a clinician/user dashboard device(s). The Priority Software 1120 may run continuously (for patient monitoring device) or run at specified time intervals 1130 (for user dashboard devices pre-determined during system setup configuration). Should threshold rules for the priority software be breached during the software run cycle 1130 then a visual alert and/or notification or message is sent to both the wearable monitoring device via the patient monitoring device viewer, or the Priority LED Display and sent to the clinician user dashboard via the graphical user interface clinician dashboard. Warning messages may relate to breached rules specific to health parameters (e.g. low heart rate), geolocation rule triggers (e.g. exiting a geo-fenced zone) or machine data rule triggers (e.g. low battery). Messages can also be generated on the graphical user interface dashboard device 800 (e.g. 'page' message 830, 836). The local priority score database is updated 1150 with the extra information and fed back into the base software module 1120. It should be noted that above steps may take place in a different order and the ordering shown in FIG.11 is merely exemplary.

FIG. 12(a) shows the configuration of a disposable/reusable head wearable patient monitoring device according to an embodiment of the present invention. The disposable/reusable head wearable patient monitoring device 1200 has a coin battery power supply 1210 and device periphery adhesive cushion strips 1212 for binding with the patient's forehead. The device disposable/reusable head wearable patient lo monitoring device 1210 contains two free moving modular flaps, one containing the coin battery power supply 1210 the other containing a manual input control panel 1211. There are four sensor compartments 1213 two on the left and two on the right of the device 1200. A viewer 1214 is located at the centre of the device for displaying system alerts, messages, and notifications. Further visual alert indicators take the form of LEDs 1215 at the bottom front of the device.

FIG. 12(b) shows the configuration of a disposable/reusable head wearable patient monitoring device according to an embodiment of the present invention. The device shown in FIG. 12(b) has two wrap-around elasticated supports 1220. The elasticated wrap-around bands provide extra stability for highly ambulatory patients and are bridged at the back of the patient's head via a connecting rubber section 1210.

FIG. 12(c) shows the configuration of a reusable head wearable patient monitoring device according to an embodiment of the present invention. The reusable head wearable patient monitoring device is provided with a rechargeable battery power supply 1230, two wrap-around elasticated supports, and a free moving modular flap containing a manual input control panel. The rechargeable battery can be slotted into and removed from a reinforced battery compartment 1231. The battery can be recharged via a USB Type C 1232 access port or a standard Jack connector or any other connection providing power to the rechargeable battery.

FIG. 12(d) -shows the configuration of a reusable head wearable patient monitoring device according to an embodiment of the present invention. The device shown in FIG.12 (d) is provided with rechargeable battery power supply and two wrap-around elasticated supports. Clinician manual observation inputs are carried out by a wireless enabled (e.g. Bluetooth LE) mobile device application.

FIG. 13 (a) to 13 (i) illustrate configurations of patient monitoring devices according to embodiments of the present invention.

FIG. 13 (a) shows the manual input control module of a patient monitoring device. As shown in FIG. 13(a) the manual input control module 1310 is designed in a flap format to keep the buttons away from main device adhesive strip. This is to avoid pressing on the patient's forehead creating discomfort and disruption in blood perfusion through the application of pressure on the skin. The control flap design allows for ergonomic forefinger and thumb pitch operation. When manual inputs are being entered either through the four press-buttons 1311, 1312, 1313, 1314 or the three-setting slide switch 1315, there is minimal patient irritation or sensor disruption. The two manual observation buttons (OBS#1, OBS#2) 1311, 1312 are backlit 'red' when active (one press 1311 to activate the observation parameter, which then appears in numerical format on the device viewer display (HPOD). An observation score is set using the plus 1313 and minus 1314 buttons on the control panel 1310. Observation button 1311 is pressed a second time deactivating the red backlight saving latest inputted score.

Override slide switch 1315 position setting corresponds to the three colour-coded LED indicators situated below the device viewer display (HPOD). Depending on clinician selection these LED indicators represent one of possible three switch setting selected to determine the selected Priority level (1 =Red, 2=Amber, 3=Green).

FIG. 13(b) shows the power supply module of a patient monitoring device. AS shown in FIG. 13(b), similar to the control module, the power supply module 1320 is designed in flap format to keep the module away from main device adhesive strip. The control flap design allows the operator to avoid pressing on the patient's forehead when replacing the battery power supply 1321, avoiding having to remove the device from the patient's forehead (which would compromise the adhesive properties of the main device adhesive strip. The power supply module contains a two-battery cartridge 1321 which is easily removed and replaced. For exemplary illustration the power supply cartridge contains two 3V CR2032 Alkaline button batteries. The two-battery disposable cartridge can instead be swapped out and the device configured to the format illustrated in FIG. 12 (c) with a rechargeable lithium-ion battery.

FIG. 13 (c) shows flexible printed circuitry in a patient monitoring device. As shown in FIG. 13 (c), for comfortable ambulatory patient enabled application flexible printed circuit boards 1331 and electronics allow for lightweight and bendable components essential for an ergonomic wearable head device. The circuits, PCB and sensor components are fully insulated to Defibrillation Proof Type BF Applied Parts as well as adhering to water resistant IP32 standards and conformance to EC Directive No. 93/42/EEC. The components and circuitry can be configured for disposable or reusable device format.

FIG. 13 (d) shows the adhesive strip of a patient monitoring device. As shown in FIG. 13 (d), a device parameter adhesive sponge/gel strip is provided. A strong (non-latex, non-irritant) skin adhesive material 1340 secures the wearable health monitoring headset. The adhesive contains a gel/ sponge underlayer to cushion the patient from excessive irritation or friction. The adhesive cushion also acts as an insulator to cocoon the encapsulated sensors from external noise and vibration contamination. An adjustable (non-latex) duel elasticated band may also be provided which wraps around the back of the patient's head from the upper and lower device left-hand edges to the upper and lower right-hand edges (ambulatory enabled). Auto-on device activation: Once the device adhesive counterfoil is removed during patient application a light dependant resister (LDR) is exposed switching the device 'ON' permanently until battery depletion.

FIG. 13(e) shows the device identifier of a patient monitoring device. As shown in FIG. 13(e) the patient monitoring device has a device registration ID 1350. The device registration ID 1350 maintains the anonymity of the patient's data contained on the device, no identifiable patient information can be assigned to wearable head worn monitoring devices. The device registration ID 1350 can be used to search for geo-locations of active devices on the API map. The clinician control dashboard (CCD) 800 can match a physical device to the GUI and patient record. A device QR code can be used to pair the wearable patient monitoring device with an authorised mobile device API.

FIG. 13(f) shows the LED display of a patient monitoring device. As shown in FIG. 13 (f) the LED Priority Display 1360 exhibits four settings (LED = Green: low priority category, LED = Amber: medium priority category, LED = Red: high priority category, LED = Flashing Red: Alert threshold/Page triggered). Display position is maximised for eye contact monitoring, display visual indicators are close to eye level. The LED displays light up under three circumstances: (i) Alert is triggered, (ii) Clinician (CDD) GUI initiates a device 'page', (iii) Patient enters a geo-fenced assessment area (e.g. Triage bay/E.D. Observation area). Clinician 'override switch' 1315 is activated on the device control panel: LED stays lit for 20 seconds to setting selected (Pos.1 = LED Red, Priority 1; Pos.2 = LED Amber; Priority 2, Pos.3 = LED Green, Priority 3).

FIG. 13 (g) shows the upper sensor compartments of a patient monitoring device. As shown in FIG. 13(g) upper left and right sensor compartments are provided. The upper sensor compartment locations are optimised for medical grade reflectance photodiode 1370 configured for photoplethysmography (PPG) readings. The compartments are also purposely designed to be modular is design so sensors can be replaced/modified for different formats and configurations. The compartments contain insulation material to mitigate impairment of (PPG) sensor signal quality. The sensor cradle 1371 zo containing the sensor module is designed to ensure an optimal contact pressure close to the 80m mHg range for PPG readings (both for supine and ambulatory patients). It should be noted that the dimensions and design of the sensors in the accompanying wearable patient monitoring device drawings are purely intended for illustrative purposes and may vary depending on supplier & sensor type.

FIG. 13 (h) shows the lower sensor compartments of a patient monitoring device. As shown in FIG. 13(h) Lower left and right sensor compartments are provided. The lower sensor cradles 1381 locations are optimised for measuring patient temperatures accurately using medical grade thermistor thermometers 1380. Similar to the upper sensor compartments the lower sensor compartments are purposely designed to be modular is design so sensors can be replaced/modified for different formats and configurations. It should be noted that the dimensions and design of the sensors in the accompanying wearable monitoring device drawings are purely intended for illustrative purposes and may vary depending on supplier, or sensor type or patient onto which the device will be used.

FIG. 130) shows the Health Parameter Observation Display (HPOD) of a patient monitoring device. The Health Parameter observation display (HPOD) 1390 activates during the input process of manual observation scores. This process involves using the HPOD 1390 together with the device flip control panel 1310 (HPOD switches off 10 seconds after final OBS#1/OBS#2 score 1392 confirmation). HPOD 1390 activates with message: "PAGE -AJ412" (depending on device registration number) should a clinician initiate a patient device 'page via the (CCD) GUI interface 800. The HPOD page notification (and LED Priority Display) 1360 is deactivated by simultaneously pressing OBS#1 1311 and OBS#2 1312 buttons. HPOD is activated should both upper left and right dual sensors or both lower left and right dual sensors breach a telemetry alert threshold. HPOD displays the breached output health parameter on screen and HPOD remains active/continues to display the telemetry readings only activating should the parameter revert to within the parameter threshold rules for greater than 5 seconds. HPOD is activated and relays a specific error message should there appear to be a sensor reading error/issue with both the upper left and right or both the lower left and right duel sensors. HPOD is activated for other device alerts set out with specific threshold rules (i) low battery level; (ii) loss of network connection; (iii) loss of BLE/Wi-Fi device pairing; (iv) loss of geo-location. HPOD warning is activated when an ambulatory patient is nearing exit to a geo-fenced zone. HPOD notification appears when the wearable head device transitions from one geo-fenced zone to another and the notification remains on HPOD for 5 seconds before the display switches off.

FIG.14 (a) to FIG.14 (d) show the ergonomic design of patient monitoring devices according to embodiments of the present invention.

FIG. 14(a) shows a basic disposable variant of the patient monitoring device. The power supply (3v coin battery) has been incorporated into the main body of the wearable health monitoring device 1410. The device acts as one large entire adhesive strip which binds with the patient's forehead, the only areas not covered by adhesive on the main body are the sensor windows. The control panel module is contained within a lightweight free moving flap on the left-hand of the forehead 1310. The sensors are designed to be reusable or disposable depending on the specified end user requirements as are the internal PCB related components/circuits.

FIG. 14(b) shows a patient monitoring device based on the same disposable concept as the device variant demonstrated in FIG. 14 (a) the main difference is the device is reusable by a single patient, and the adhesive strip is replaced by a narrow medical gel band that follows the periphery of main device body 1340. A simple adjustable flexible cloth headband 1420 is included to support long duration wear-ability, the back of which houses a rechargeable battery and USB-C charging port. This variant of the wearable patient monitoring device is designed for highly ambulatory patients, primarily addressed to the in-hospital observation scenario or primary care patient observation. There is also the case for its use as a safety precaution for early hospital discharge home-care monitoring.

FIG. 14(c) shows a patient monitoring device based on the same disposable concept as the device variant demonstrated in FIG. 14 (a) the main difference lies in the addition of two regional oximetry sensors 1432, 1434 for a more detailed assessment of oxygen flows proximal to the brain. This would be appropriate for more heightened critical care monitoring scenarios where patients might exhibit breathing difficulties or have a low consciousness scoring. An increased power supply requirement is needed for longer monitoring periods, the additional two rS02 sensors as well as increased data transmission are addressed through the supplementary battery module located at the bridge point of the two overhead stabilising tie-downs 1435. The rS02 sensors are used in conjunction with SP02 sensors 1433, 1436 and the enhanced sensor position configuration illustrates optimal node monitoring 1431 FIG. 14(d) shows a patient monitoring device which is a hybrid combination of the use of the overhead tie down shown in FIG.14 (c) and the use of the headband strap FIG. 14 (b). The patient monitoring device sits discretely under head-worn clothing 1440.

The profile height of the main device housing positioned at the forehead has been reduced by 50% 1441, 1442, 1443. This has been achieved by removing the Health Parameter Observation Display (HPOD), the eye level LED Priority Display, and the device control panel flap module. The power supply module has been relocated to the back of the head 1446 at the point where the overhead tie downs meeting the headband strap. The left and right upper sensor cradles 1444 have been relocated in front of the two lower sensor cradles 1445, along the same plane (as illustrated in Fig.14 (d) above). The manual control panel flap is replaced with a remote mobile phone or tablet user API. This version of the device is designed for reusable personalised ambulatory comportment: sensors will need to be wiped cleaned 1447 before each use.

FIG.15(a) to 15(c) illustrate a patient monitoring device according to an embodiment of the present invention having an alternative application node. The device shown in FIG.15 may be applied in a Splint Format if primary node of application on the patient's forehead is impeded.

FIG.15 (a) shows the patient monitoring device applied to the hand of the patient. The two PPG sensors as well as one thermistor thermometer (located at the palm-thumb-junction) are fully operational. Dual PPG data is observed via the (optimal amplitude signal) primary site 1510 (fingertip node) and secondary site 1520 (palm of the hand). A single temperature reading is also observed by the thermometer (the second thermistor has no application point -> indicating a reading error). A pouch/pocket 1531 is provided to secure the fingertip and PPG sensor, device adhesive secures second PPG sensor and thermistor in place. The splint format is designed to be applied to either right or left hand of the patient, but the fingertip must be cleaned of contaminants/debris. The rational of the splint configuration is to offer application redundancy if for a specific reason (injury) the primary forehead site is unavailable.

FIG.15 (b) shows the patient monitoring device applied to the hand of the patient. The Device in Splint-Format is secured in place by two specific design features and mechanisms. The adhesive applicator gel present around the periphery of the device 1533 provides stability and prevents the entire unit from moving or slipping. The cloth pouch 1431 located to the inside of the PPG sensor 1530 allows the selected finger to be secured in a mini glove-like cloth structure.

FIG. 15(c) shows the locations of the control panel flap and power unit flap of a patient monitoring device applied to the hand of the patient. The two panel flaps on either side of the device remain accessible when deployed for Contingency Triage Splint application. The clinician control panel flap 1540 remains beyond the application area and is easily accessible for manual inputting of patient observations. The power unit flap 1441 also remains free from the application area and therefore can be accessed should a battery need to be replaced/adjusted. Both PGG sensors 1443, 1444 have the option of using an adjacent pocket./pouch 1442, 1443 for device splint format application on fingers on either the right or left hand.

Whilst the foregoing description has described exemplary embodiments, it will be 10 understood by those skilled in the art that many variations of the embodiments can be made within the scope and spirit of the present invention.

Claims

CLAIMS1. A patient monitoring device, configured to be worn by a patient, the patient monitoring device comprising: a first sensor arranged to measure a first physical parameter at a first location on the patient; a second sensor arranged to measure the first physical parameter at a second location on the patient; a processor configured to process signals indicative of the output of the first sensor and the output of the second sensor, determine an estimated value for the first physical parameter using the signals indicative of the output of the first sensor and the second sensor and calculate a patient priority score for the patient using the estimated value for the first physical parameter of the patient; and a display configured to display an indication of the patient priority score for the patient.
2. A patient monitoring device according to claim 1, further comprising an input device configured to receive a user input indicative of at least one observed physical parameter of the patient; wherein the processor is configured to calculate the patient priority score for the patient using the estimated value for the first physical parameter of the patient and the at least one observed physical parameter of the patient
3. A patient monitoring device according claim 1, further comprising a communication interface configured to receive a user indication indicative of at least one observed physical parameter of the patient from a user device, and wherein the processor is configured to calculate the patient priority score for the patient using the estimated value for the first physical parameter of the patient and the at least one observed physical parameter of the patient.
4. A patient monitoring device according to any one of claims 1 to 3, wherein the first sensor and the second sensor are pulse oximetry sensors.c.
A patient monitoring device according to any one of claims 1 to 4, wherein the first location and the second location are symmetrical positions on the patient.
6. A patient monitoring device according to any preceding clam, wherein the fin location and the second location are on the forehead of the patient.
7. A patient monitoring device according to any preceding claim, further comprising a third sensor.
8. A patient monitoring device according t - , wherein the third sensor is a temperature sensor.
9. A patient monitoring device according to any one of preceding claims wherein the third sensor is a galvanic sensor.
10. A patient monitoring device according to any preceding claim configured to be worn on a primary position on the patient and on a secondary position on the patient.
11. A patient monitoring device according to claim 10, wherein the primary position on the patient is on the forehead of the patient.
12. A patient monitoring device according to claim 10 or claim 11, wherein the secondary position is on a hand of the patient.
13. A patient monitoring device according to any preceding claim wherein a pocket or pouch configured to receive a fingertip of the patient is provided in the vicinity of the first sensor.
14 A patient monitoring device according to any preceding claim further comprising an adhesive portion to secure the patient monitoring device to the patient.
15. A patient monitoring device according to claim 14, comprising a counterfoil overlaying the adhesive portion, wherein the device is configured to activate on removal of the counterfoil.
16. A patient monitoring device according to any one of claims 1 to 13, further comprising a strap configured to secure the patient monitoring device to the patient.
17. A patient monitoring device according to any preceding claim, further comprising a communication module configured to send the signals indicative of the output of the first sensor and the output of the second sensor to a server.
18. A patient monitoring device according to any preceding claim further comprising a battery module configured to supply power to the patient monitoring device.
19. A patient monitoring device according to claim 18, having a disposable portion comprising a cover and the battery module. and a reusable portion comprising the first sensor, the second sensor, the processor, and the display.