EP4616429A1 - Patient monitoring method and system - Google Patents

Patient monitoring method and system

Info

Publication number
EP4616429A1
EP4616429A1 EP23888221.1A EP23888221A EP4616429A1 EP 4616429 A1 EP4616429 A1 EP 4616429A1 EP 23888221 A EP23888221 A EP 23888221A EP 4616429 A1 EP4616429 A1 EP 4616429A1
Authority
EP
European Patent Office
Prior art keywords
patient
risk
component
risk score
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23888221.1A
Other languages
German (de)
French (fr)
Inventor
Christopher Harding CAMPBELL
Benjamin Wilson Casse
Brett John Huddart
Andrew Paul Maxwell Salmon
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fisher and Paykel Healthcare Ltd
Original Assignee
Fisher and Paykel Healthcare Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2022903368A external-priority patent/AU2022903368A0/en
Application filed by Fisher and Paykel Healthcare Ltd filed Critical Fisher and Paykel Healthcare Ltd
Publication of EP4616429A1 publication Critical patent/EP4616429A1/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/117—Identification of persons
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7271—Specific aspects of physiological measurement analysis
    • A61B5/7275—Determining trends in physiological measurement data; Predicting development of a medical condition based on physiological measurements, e.g. determining a risk factor
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/74—Details of notification to user or communication with user or patient; User input means
    • A61B5/742—Details of notification to user or communication with user or patient; User input means using visual displays
    • A61B5/7435—Displaying user selection data, e.g. icons in a graphical user interface
    • G—PHYSICS
    • G08—SIGNALLING
    • G08C—TRANSMISSION SYSTEMS FOR MEASURED VALUES, CONTROL OR SIMILAR SIGNALS
    • G08C17/00—Arrangements for transmitting signals characterised by the use of a wireless electrical link
    • G08C17/02—Arrangements for transmitting signals characterised by the use of a wireless electrical link using a radio link
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q9/00—Arrangements in telecontrol or telemetry systems for selectively calling a substation from a main station, in which substation desired apparatus is selected for applying a control signal thereto or for obtaining measured values therefrom
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B2562/00—Details of sensors; Constructional details of sensor housings or probes; Accessories for sensors
    • A61B2562/02—Details of sensors specially adapted for in-vivo measurements
    • A61B2562/0271—Thermal or temperature sensors
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0015—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system
    • A61B5/002—Monitoring the patient using a local or closed circuit, e.g. in a room or building
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/01—Measuring temperature of body parts ; Diagnostic temperature sensing, e.g. for malignant or inflamed tissue
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A61B5/0205—Simultaneously evaluating both cardiovascular conditions and different types of body conditions, e.g. heart and respiratory condition
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A61B5/024—Measuring pulse rate or heart rate
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/08—Measuring devices for evaluating the respiratory organs
    • A61B5/0816—Measuring devices for examining respiratory frequency
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/145—Measuring characteristics of blood in vivo, e.g. gas concentration or pH-value ; Measuring characteristics of body fluids or tissues, e.g. interstitial fluid or cerebral tissue
    • A61B5/14542—Measuring characteristics of blood in vivo, e.g. gas concentration or pH-value ; Measuring characteristics of body fluids or tissues, e.g. interstitial fluid or cerebral tissue for measuring blood gases
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/68—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient
    • A61B5/6887—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient mounted on external non-worn devices, e.g. non-medical devices
    • A61B5/6891—Furniture
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G16H10/65—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records stored on portable record carriers, e.g. on smartcards, RFID tags or CD
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring

Definitions

  • the present disclosure generally relates to the collection and remote processing of data from one or more wireless sensors. More particularly it relates to the real time collection, monitoring and display of patient data.
  • BACKGROUND [0002]
  • patients can be found in a variety of states of wellbeing, either from diseases they have, or from controlled surgical interventions. In many circumstances, patients are monitored to assess either their state of wellbeing or to identify early indications of health deterioration and identify the need for changes in treatment. Most patients in unstable states of wellbeing present with some form of respiratory failure or changes in respiratory function.
  • the present disclosure may broadly be said to consist in a method for generating a component risk score based on the measurement of one or more physiological parameters of a patient, the method comprising the steps of: receiving sensor data; determining a physiological parameter of the patient from the sensor data; determining a component risk score based on the physiological parameter; outputting the component risk score.
  • the sensor data is received over one or more advertising channels of a short-range wireless communication component.
  • determining the component risk score comprises associating at least one of the at least one physiological parameter with a risk band of a corresponding plurality of risk bands, each risk band in the plurality of risk bands having a respective first upper and first lower threshold, the associated at least one physiological parameter falling between the first upper and first lower thresholds of the corresponding risk band.
  • the component risk score corresponds to a clinical risk index.
  • the clinical risk index corresponds to an early warning score.
  • the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level.
  • the supplementary oxygen is determined by a sensor on a respiratory device and/or a sensor integrated into a respiratory device.
  • the risk bands correspond to predetermined Early Warning Score values.
  • the plurality of risk bands comprises a first risk band and second risk band.
  • the size of the first risk band is different to the size of the second risk band.
  • the size of a risk band is defined by the difference between its first upper and first lower threshold.
  • the physiological parameter is one of temperature, body temperature, blood pressure, respiratory rate, heart rate, carbon dioxide level, and SpO2 (blood oxygen saturation).
  • the physiological parameter and component risk score are stored as a time series.
  • the physiological parameter and component risk score are updated in real time.
  • the component risk score is recalculated at regular intervals of time.
  • the component risk score is recalculated only when new sensor data is received and an updated physiological parameter is determined.
  • the method further comprises the steps of: determining a second physiological parameter from the sensor data; determining a second component risk score based on the second physiological parameter; outputting the second component risk score; and determining a total component risk score based on the first and second component risk score.
  • determining the total component risk score comprises selecting the highest of the first and second component risk score as the total component risk score.
  • determining the total component risk score comprises averaging the first and second component risk score.
  • determining the total component risk score comprises calculating a weighted average of the first and second component risk score, wherein the weighting is based on a predetermined rule set.
  • determining the total component risk score comprises summing the first and second component risk score and comparing the summed value to a predetermined threshold.
  • the method further comprises the step of: displaying the component risk score in a first view of a display screen, wherein the component risk score is displayed along with a patient identifier, the patient identifier corresponding to a patient associated with the sensor data and the physiological parameter derived therefrom.
  • the patient identifier comprises any one or more of a patient name, a patient ID, a location identifier and a bed identifier.
  • the component risk score is displayed in the form of a gauge, wherein the gauge is sectioned according to the second upper and second lower thresholds of the plurality of risk bands.
  • the gauge displays a rolling average of the component risk score.
  • displaying the component risk score further comprises displaying a graphical time series showing current and historical values of the component risk score.
  • the method further comprises the step of: displaying the physiological parameter in the first view of a display screen.
  • displaying the physiological parameter further comprises displaying a graphical time series showing current and historical values of the physiological parameter.
  • the graphical time series are updated in real time as updated values are determined.
  • the method further comprises the steps of: displaying the second physiological parameter; displaying the second component risk score; and displaying the total component risk score.
  • the display of the first and second physiological parameter is arranged based on their associated first and second component risk score.
  • the display of the first and second physiological parameter is arranged according to the relative contribution of the first and second physiological parameter to the total component risk score.
  • the method further comprises the step of receiving parameters of a therapy being provided to the patient by a respiratory support device and/or usage data representing the patient’s use of the respiratory support device; and displaying said therapy parameters and/or usage data on the display screen.
  • the therapy parameters and/or usage data are displayed as a time series and updated in real time.
  • the method further comprises the step of: displaying, in a second view of a display screen, one or more patient identifiers, each associated with a patient and component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the relative value of their associated component risk score.
  • the one or more patient identifiers are grouped into regions of the display, each region associated with a risk band of the plurality of risk bands.
  • the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score.
  • the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated.
  • the one or more patient identifiers are in the form of a tile.
  • the one or more patient identifiers each comprise a risk indicator.
  • the risk indicator includes a numerical value indicative of the risk level of a patient based on their component risk score and the associated risk band.
  • the risk indicator is updated in real time, as updated values of the component risk score are determined.
  • the numerical value is a rolling average.
  • the risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same.
  • the risk trend indicator is colour coded.
  • the one or more patient identifiers further comprises a display of one or more physiological parameters associated with the patient, wherein the selection and arrangement of the one or more physiological parameters is based on their contribution to the component risk score.
  • the display of the one or more physiological parameters is updated in real time.
  • the display of the one or more physiological parameters comprises a rolling average of the one or more physiological parameters.
  • the one or more patient identifiers each comprise one or more of the following elements: a patient identification number, a patient room number, a patient bed number, a patient bed location, a patient name, and an indication of the time expired since a clinician last interacted with the patient.
  • the presence, size, and/or display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the component risk score.
  • the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score.
  • the second risk band is a higher risk band than the first risk band.
  • the estimated amount of time is provided by analyzing a trend in historical values of the component risk score.
  • the one or more patient identifiers are grouped into regions of the display, each region associated with a discharge risk determined, at least in part, on the component risk score.
  • the size and/or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score.
  • the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated.
  • the presence, size, and/or display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the discharge risk score and/or component risk score.
  • the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first discharge risk band, to another region of the display associated with a second discharge risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first discharge risk band, to another region of the display associated with a second discharge risk band as a result of a change in the respective component risk score.
  • the second risk band is a lower risk band than the first risk band.
  • the estimated amount of time is provided by analyzing a trend in historical values of the component risk score.
  • the discharge risk score depends on any one or more of patient characteristics, therapy characteristics and/or socio-economic factors.
  • the patient characteristics comprise any one of more of: age, weight, ethnicity, and sex.
  • the therapy characteristics comprise any one or more of: illness, diagnosis, therapy applied, therapeutic devices used, time under therapy.
  • the socio-economic factors comprise any one or more of: patient’s support network and the home environment.
  • the discharge risk is determined by any one or more of as a decision tree, rules engine, or flow chart.
  • the display is configurable to switch between showing discharge risk and component risk scores.
  • the method comprises sending an alert to the display.
  • the method comprises displaying summarized physiological parameters for a plurality of time periods.
  • the summarization comprises any one or more of a selected value, an average value, a maximum value, a minimum value, a mean value, upper quartile value, lower quartile value and a median value.
  • the plurality of time periods comprise an integer number of hours, days, weeks and/or months.
  • each of the physiological parameters is displayed on an independent axis.
  • the summarized physiological parameters are displayed in the form of a chart.
  • the chart comprises any one or more of a radar chart, an area chart, a lollipop chart, a radial column chart, a stellar chart.
  • the chart comprises at least two time periods.
  • the chart displays risk categories corresponding to the physiological parameters.
  • the chart displays interpolated data between adjacent time periods.
  • the chart summarizes data from the stored time series data.
  • the present disclosure may broadly be said to consist in a patient monitoring system configured to perform the methods set out above.
  • the patient monitoring system comprises: one or more sensors; and a processing server.
  • the component risk score is a normalized component risk score and/or comprises normalizing the component risk score.
  • determining the normalized component risk score comprises feature scaling or min-max normalization of the physiological parameter within the first thresholds of the risk band to give a measure of the position of the physiological parameter within the first thresholds of the risk band.
  • determining the normalized component risk score comprises standardizing the size of each risk band in the plurality of risk bands to a preferred size W, wherein each risk band has a second upper threshold and second lower threshold separated by W.
  • the normalized component risk score is determined according to the formula: ⁇ h ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ h ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
  • the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score.
  • the present disclosure may broadly be said to consist in a method for operating a sensor system to monitor health of a patient, the method comprising: receiving sensor data from a plurality of sensors via one or more advertising channels of a short-range wireless communication component; determining one or more physiological parameters of the patient based on the sensor data from the plurality of sensors; determining a health condition based on the physiological parameter; and outputting the health condition.
  • each of the plurality of sensors is associated with, attached or attachable to an item of furniture.
  • the furniture comprises one or more of a bed and a chair.
  • the processing system is operable to identify a patient ID by determining a patient ID associated with the furniture.
  • the plurality of sensors comprises an under- mattress sensor.
  • the sensor comprises an under-cushion sensor.
  • the sensors are non-contact sensors for respiratory rate and/or heart rate.
  • the hub receives the transmission data from the plurality on an advertising channel.
  • the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score.
  • the present disclosure may broadly be said to consist in a method for operating a sensor system to monitor health of a patient, the method comprising: receiving sensor data from a plurality of sensors via one or more advertising channels of a short-range wireless communication component, the sensor data indicative of one or more physiological parameters of the patient; detecting, based on the sensor data, that a health parameter of the patient is above or below a predetermined threshold; and outputting, to a healthcare provider, an indication of the health parameter to cause the healthcare provider to provide treatment to the patient.
  • detecting that the health parameter of the patient is above or below the predetermined threshold comprises comparing two or more different physiological parameters, each physiological parameter obtained from sensor data from in the plurality of sensors.
  • detecting that the health parameter of the patient is above or below the predetermined threshold comprises: determining the one or more physiological parameters from the sensor data; and determining, based on the one or more physiological parameters, the health parameter of the patient; and comparing the health parameter to the predetermined threshold.
  • the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score.
  • the present disclosure may broadly consist in a method for operating a hub for a system for monitoring a patient’s health, the method comprising: receiving, from a first sensor peripheral to the hub, a first data packet via a first advertising channel of a short-range communication component, wherein the first data packet contains sensor data from the first sensor related to a first physiological measurement of the patient; sending the first data packet to a server peripheral to the hub via a network communication component. receiving, from a second sensor peripheral to the hub, a second data packet via a second advertising channel of the short-range communication component, wherein the second data packet contains sensor data from the second sensor related to a second physiological measurement of the patient; and sending the second data packet to the server via the network communication component.
  • the first advertising channel is the same as the second advertising channel.
  • the first advertising channel is different from the second advertising channel.
  • the first physiological parameter is the same as the second physiological parameter, and wherein the method further comprises combining the first data packet and the second data packet before sending the first data packet and the second data packet to the server.
  • the network communication component is a wireless internet component.
  • the first data packet is received in a continuous stream of data packets from the first sensor via the first advertising channel.
  • the first data packet and the second data packet are sent to the server at the same time.
  • the first data packet includes a patient identifier
  • the second data packet includes the patient identifier.
  • the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score.
  • the present disclosure may broadly be said to consist in a hub for a system for monitoring health of a patient, the hub comprising: a short-range communication component; a network communication component; a processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receive, from a first sensor peripheral to the hub, a first data packet via a first advertising channel of the short- range communication component, wherein the first data packet contains sensor data from the first sensor related to a first physiological measurement of the patient; sending the first data packet to a server peripheral to the hub via the network communication component, receiving, from a second sensor peripheral to the hub, a second data packet via a second advertising channel of the short-range communication component, wherein the second data packet contains sensor data from the second sensor related to a second physiological measurement of the patient; and sending the second data packet to the server via the network communication component.
  • the present disclosure may broadly be said to consist in a system for monitoring a patient’s health, the system comprising: a central hub, the central hub comprising a short-range communication component with a plurality of advertising communication channels; a first sensor peripheral to the central hub, the first sensor configured to obtain measurements of a first physiological parameter of the patient and send first data packets to the central hub via a first advertising channel of the plurality of advertising communication channels, wherein each of the first data packets contains data related to the measurements of the first physiological parameter; and a second sensor peripheral to the central hub and the first sensor, the second sensor configured to obtain measurements of a second physiological parameter of the patient and send second data packets to the central hub via a second advertising channel of the plurality of advertising communication channels, wherein each of the second data packets contains data related to the measurements of the second physiological parameter.
  • the above two aspects may optionally comprise any of the steps or features of the following systems, where the health condition is a component risk score.
  • the present disclosure may broadly be said to consist in a patient management system comprising: a data management server in communication with a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients, the data management server configured to: receive, via a network, sensor data from the plurality of sensors; determine a component risk score for each of the plurality of patients from the sensor data; assign the plurality of patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and cause a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with a patient of the plurality of patients and their component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the value of their associated component risk score.
  • the sensor data is received over one or more advertising channels of a short-range wireless communication component.
  • the component risk score is calculated according to the method steps set out above and/or below.
  • the component risk score corresponds to a clinical risk index.
  • the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level.
  • the one or more patient identifiers are grouped into regions of the display, each region associated with an upper and lower threshold for the component risk score, said thresholds defining a plurality of risk bands.
  • the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score.
  • the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated.
  • the one or more patient identifiers are in the form of a tile.
  • the one or more patient identifiers each comprise a risk indicator.
  • the risk indicator includes a numerical value indicative of the risk level of a patient based on their component risk score and the associated risk band.
  • the risk indicator is updated in real time, as updated values of the component risk score are determined.
  • the numerical value is a rolling average.
  • the risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same.
  • the risk trend indicator is colour coded.
  • the one or more patient identifiers are grouped into regions of the display, each region associated with an upper and lower threshold for a discharge risk, the discharge risk dependent, at least in part, on the component risk score.
  • the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score.
  • the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated.
  • the one or more patient identifiers are in the form of a tile.
  • the one or more patient identifiers each comprise a discharge risk indicator.
  • the discharge risk indicator includes a numerical value indicative of the discharge risk level of a patient based on their component risk score.
  • the discharge risk indicator is updated in real time, as updated values of the component risk score are determined.
  • the numerical value is a rolling average.
  • the discharge risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same.
  • the discharge risk trend indicator is colour coded.
  • the one or more patient identifiers further comprises a display of one or more physiological parameters associated with the patient, wherein the selection and arrangement of the one or more physiological parameters is based on their contribution to the component risk score.
  • the display of the one or more physiological parameters is updated in real time.
  • the display of the one or more physiological parameters comprises a rolling average of the one or more physiological parameters.
  • the one or more patient identifiers each comprise one or more of the following elements: a patient identification number, a patient room number, a patient bed number, a patient name, and an indication of the time expired since a clinician last interacted with the patient.
  • the presence, size, and display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the component risk score.
  • the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score.
  • the second risk band is a higher risk band than the first risk band.
  • the estimated amount of time is provided by analyzing a trend in historical values of the component risk score.
  • the sensor data is received from respiratory support device comprising or in communication with the plurality of sensors.
  • the component risk score is a normalized component risk score.
  • the present disclosure may broadly be said to consist in a method of patient management comprising: receiving, via a network, sensor data from a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients; determining a component risk score for each of the plurality of patients; assigning the plurality of patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and causing a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with a patient of the plurality of patients and their component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the relative value of their associated component risk score.
  • the sensor data is received over one or more advertising channels of a short-range wireless communication component.
  • the component risk score may be calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below.
  • assigning the plurality of patients to a plurality of groups comprises re- assigning a patient from a first group having an associated risk band to a second group having a second associated risk band.
  • the method further comprises the step of generating an alert condition if the second associated risk band is associated with a higher clinical risk than the first risk band.
  • the alert condition triggers a notification to a hospital monitoring system.
  • the alert condition triggers a notification to a secondary display.
  • the secondary display is a portable computing device.
  • the portable computing device is associated with a clinician responsible for the reassigned patient.
  • the component risk score corresponds to a clinical risk index.
  • the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level.
  • the component risk score is a normalized component risk score.
  • the present disclosure may broadly be said to consist in a method of patient management comprising: receiving, via a network, sensor data from a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients; determining a component risk score for each of the plurality of patients; selecting patients from the plurality of patients based on an assigned user of the system, assigning the selected patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and causing a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with the selected patients.
  • the component risk score may be calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below.
  • the one or more patient identifiers are arranged on the display screen based on the relative value of their associated component risk score.
  • assigning the plurality of patients to a plurality of groups comprises re- assigning a patient from a first group having an associated risk band to a second group having a second associated risk band.
  • the method further comprises the step of generating an alert condition if the second associated risk band is associated with a higher clinical risk than the first risk band.
  • the alert condition triggers a notification to the assigned user.
  • the alert condition triggers a notification to a secondary display of the assigned user.
  • selecting patients from the plurality of patients is further based on a location of the assigned user and/or the display.
  • the assigned user is a clinician.
  • the selection of patients is based on the patients for which the assigned user is responsible.
  • the method comprises assigning the selected patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and causing a second display to display a graphical user interface, in a second display mode, one or more patient identifiers, each patient identifier associated with the plurality of patients.
  • the component risk score is a normalized component risk score.
  • the present disclosure may broadly be said to consist in a method of processing wireless sensor data at a server, the method comprising the steps of receiving sensor data from a plurality of wireless sensors; determining a device type associated with the received sensor data; retrieving and activating at least one handler for the received sensor data, the at least one handler comprising a driver configured to process the sensor data into parameterised data; and converting the received data into parameterised data.
  • the device type is determined by a characteristic of the received sensor data and/or a device ID encoded in the received sensor data.
  • the at least one handler corresponds to the determined device type.
  • the sensor data comprises a continuous stream of data packets.
  • the method further comprises the step of storing the parameterised data.
  • the parameterised data is stored as a time series
  • the method further comprises the step of determining an event based on the stored parameterised data.
  • the parameterised data is sensor independent, wherein measured data from multiple of the plurality of wireless sensors is interchangeable.
  • the sensor data from the plurality of wireless sensors are received from a wireless router, the wireless router forwarding the received data to the server.
  • the wireless router forwards the received data to the server in real time.
  • the sensor data are advertising packets of a short-range wireless sensor, optionally a BluetoothTM wireless sensor.
  • the step of activating a handler comprises: determining if a handler exists for the received sensor data, and otherwise instantiating a handler for the received data.
  • the step of determining a handler comprises identifying one or more features of the structure of the sensor data.
  • the step of determining a handler comprises identifying one or more features of a portion of the sensor data.
  • the portion of the sensor data comprises an advertising portion.
  • identifying one or more features comprises comparing structure of the sensor data with a plurality of known structures.
  • the received sensor data are associated with a time-stamp.
  • the received sensor data are associated with a time-stamp at the router or at the server.
  • each data packet of the received sensor data is associated with a timestamp.
  • the method further comprises the step of associating a time- stamp to the received sensor data.
  • each of the handlers is operated in a container, wherein a plurality of containers are generated to handle the sensor data from the plurality of wireless sensors.
  • the method further comprises a controller, the controller configured to monitor the handlers and received sensor data and adjust the available processing resource.
  • the received sensor data are stored in a cache (bus) before the step of determining the device type, the storage allowing capacity of the processing to be allocated.
  • the database is a time-series database.
  • the method further comprises obtaining a trust rating for each of the plurality if wireless sensors.
  • obtaining the trust rating comprises any one or more of: determining a trust rating from the sensor data, obtaining the trust rating from the handler and obtaining the trust rating from the server.
  • the method further comprises selecting between readings from the plurality of wireless sensors based on the trust rating.
  • the method further comprises comparing sensor data from a plurality of sensors.
  • the method further comprises calibrating a sensor with a lower trust rating based on a sensor with a higher trust rating.
  • the method further comprises determining an accuracy bound for the sensor based on the trust rating.
  • the method comprises calculating a component risk score based on the parameterized data.
  • the component risk score is calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below.
  • the present disclosure may broadly be said to consist in a method of processing wireless sensor data at a server, the method comprising the steps of: receiving at least one sensor data from a first sensor of a plurality of wireless sensors; identifying a first patient associated with the at least one sensor data; deriving a first parameter from the at least one sensor data; and adding the first parameter from the at least one sensor data to a time- series record in a medical record of the first patient.
  • the method further comprises the steps of: receiving at least one sensor data from a second sensor of the plurality of wireless sensors; identifying a second patient associated with the at least one sensor data; deriving a second parameter from the at least one sensor data; and adding the second parameter from the at least one sensor data to a time- series record in a medical record the second patient.
  • the first and second patient are the same patient.
  • the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a heart rate sensor, an SpO2 sensor and a temperature sensor.
  • the server receives the at least one sensor data in real time.
  • identifying a first patient comprises the steps of identifying an item of furniture associated with the at least one sensor data and identifying a patient associated with the furniture.
  • the furniture is a bed or a chair.
  • the present disclosure may broadly be said to consist in a method of collecting data from a plurality of wireless sensors, the method comprising the steps of: associating each of the plurality of wireless sensors with a patient, receiving at a server a sensor data from one of the plurality of wireless sensors, identifying the patient associated with the sensor data, processing the sensor data to identify at least one parameterised data, associating the at least one parameterised data with the patient.
  • the patient is associated with the sensor by scanning technology.
  • the method further comprises the step of storing the parameterised data in an electronic medical record of the patient, wherein the electronic measurement record comprises a time-series database.
  • the sensor data is received in real time.
  • the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a heart rate sensor, an SpO2 sensor, and a temperature sensor.
  • identifying the patient comprises the steps of identifying an item of furniture associated with the at least one sensor data and identifying the patient associated with the furniture.
  • the furniture is a bed or a chair.
  • the component method may use the system as outlined above or below and/or include any of the method steps outlined above and/or below.
  • the present disclosure may broadly be said to consist in a method of processing wireless sensor data at a server, the method comprising the steps of: receiving a sensor data from one of a plurality of wireless sensors; determining a device characteristic of the received data; processing the received data into parameterised data based on the device characteristic; and storing the parameterised data.
  • the method further comprises the steps of determining a patient ID associated with the received data, and associating the parameterised data with the patient ID.
  • determining the patient ID comprises determining a bed ID or a chair ID associated with the wireless sensor data and determining the patient ID associated with the bed ID or chair ID.
  • one of the plurality of wireless sensors comprises one or more of a temperature sensor, a respiratory rate sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor.
  • the device characteristic is the type of sensor, or the manufacturer of a sensor.
  • the method further comprises the step of determining a driver for interpreting the sensor data.
  • the driver is determined based on the device characteristic.
  • the sensor data is from a short-range wireless communication
  • the server receives the sensor data over a long-range wireless communication.
  • the short-range wireless communication is BluetoothTM and/or the long- range wireless communication is TCP/IP.
  • the method further comprises temporarily storing of received sensor data before determining the device characteristic.
  • the method further comprises temporarily storing of processed data before storing the parameterised data.
  • the temporary storage comprises a bus or cache.
  • the sensor data is received in real time.
  • the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor.
  • the method comprises calculating a component risk score based on the parameterized data.
  • the component risk score is calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below.
  • the present disclosure may broadly be said to consist in a processing system for processing measurements from a plurality of sensors to an electronic patient record having an associated patient ID, the processing system comprising: a processing server in data communications with a hub operable to receive transmissions from the plurality of sensors, and one or more databases for storing a plurality of electronic patient records therein; wherein the processing system is operable to: receive, through the hub, a sensor data from one of the plurality of sensors, identify the sensor that transmitted the sensor data, identify the patient ID associated with the sensor, determine at least one parameterised data from the sensor data, and store the parameterised data to at least one of the electronic patient records.
  • the system further comprises a medical device for providing therapy to a patient associated with the patient ID
  • the processing system is further configured to: receive, through the hub, one or more therapy parameters from the medical device, identify the patient ID associated with the medical device and/or the therapy parameters, and store the received therapy parameters to at least one of the electronic patient records.
  • the therapy parameters comprise one or more of flow rate, humidity and O2 fraction of a flow of gases for delivery to the patient.
  • the plurality of sensors comprises wearable sensors mountable to the patient.
  • the server receives the sensor data from the hub in real time.
  • the plurality of sensors comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor.
  • the hub is associated with, attached or attachable to an item of furniture.
  • the furniture comprises one or more of a bed and a chair.
  • the processing system is operable to identify the patient ID by determining a patient ID associated with the furniture.
  • the hub comprises a sensor for sensing the locator.
  • the sensor is an RFID reader.
  • the sensor has a limited range.
  • the sensor comprises an under-mattress sensor.
  • the sensor comprises an under-cushion sensor.
  • the sensors are non-contact sensors for respiratory rate and/or heart rate.
  • the hub receives the transmission data from the plurality on an advertising channel.
  • the method comprises calculating a component risk score based on the parameterized data.
  • the component risk score is calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below.
  • the present disclosure may broadly be said to consist in a system for processing patient measurements comprising: a plurality of wireless sensors; one or more databases for storing a plurality of electronic patient records therein, each patient record associated with a patient ID; a hub configured to receive wireless transmissions from the plurality of wireless sensors; and a processing server operable to: receive, through the hub, a wireless transmission from one of the plurality of wireless sensors, identify the sensor that transmitted the wireless transmission, identify the patient ID associated with the sensor, determine at least one parameterised data from the wireless transmission, and store the parameterised data to at least one of the electronic patient records.
  • the system further comprises a medical device for providing therapy to patient associated with the patient ID
  • the hub is further configured to: receive one or more therapy parameters from the medical device
  • the processing server is further operable to: identify the patient ID associated with the medical device and/or the therapy parameters and store the received therapy parameters to at least one of the electronic patient records.
  • the therapy parameters comprise one or more of flow rate, humidity and O2 fraction of a flow of gases for delivery to the patient.
  • the processing server is further operable to: retrieve and activate at least one handler, the at least one handler comprising a driver configured to process the wireless transmission into the at least one parameterised data.
  • the at least one handler corresponds to the sensor that transmitted the wireless transmission.
  • the sensor that transmitted the wireless transmission is identified by a characteristic of the wireless transmission and/or a device ID encoded in the wireless transmission.
  • the wireless transmission comprises a continuous stream of data packets.
  • the parameterised data is stored as a time series.
  • the processing server is further operable to determine an event based on the parameterised data.
  • the hub forwards the wireless transmission to the server in real time.
  • the wireless transmissions are advertising packets of a short-range wireless sensor, optionally a BluetoothTM wireless sensor.
  • the processing server receives the sensor data from the hub in real time.
  • the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor.
  • the processing server is further operable to: determine if a handler exists for the received wireless transmission, and otherwise instantiate a handler for the received wireless transmission.
  • the processing server is further operable to: identify one or more features of the structure of the received wireless transmission.
  • the processing server is further operable to: identify one or more features of a portion of the received wireless transmission.
  • the portion of received wireless transmission comprises an advertising portion.
  • the processing server is further operable to: compare the structure of the received wireless transmission with a plurality of known structures.
  • the processing server is further operable to: deactivate the handler if no additional wireless transmissions are received within a time period.
  • the hub is associated with, attached or attachable to an item of furniture.
  • the furniture comprises one or more of a bed and a chair.
  • the processing system is operable to identify the patient ID by determining a patient ID associated with the item of furniture.
  • the item of furniture has a furniture ID.
  • the hub comprises a sensor for sensing the locator.
  • the system further comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor.
  • the present disclosure may broadly be said to consist in a method of transmitting sensor measurements from a wireless sensor having at least one advertising channel or mode and at least one data channel or mode, the method comprising transmitting the sensed measurements on the at least one advertising channel or mode.
  • the method further comprises the step of encrypting the sensed measurements, optionally with a ChaCha encoding or a Diffie-Hellman Encoding.
  • the present disclosure may broadly be said to consist in a system for processing patient measurements comprising: a plurality of wireless sensors having at least one advertising channel or mode and at least one data channel or mode, wherein the wireless sensors are configured to transmit sensor data on the at least one advertising channel or mode; a hub configured to receive the sensor data from the plurality of wireless sensors over the at least one advertising channel or mode; and a processing server operable to: receive, through the hub, the sensor data from one of the plurality of wireless sensors, identify the sensor that transmitted the sensor data, determine at least one parameterised data from the sensor, and store the parameterised data.
  • any of the systems and/or methods set out above further comprise the step of: displaying the parameterised data on a display screen in a first view, wherein the parameterised data is displayed along with a corresponding patient identifier.
  • the patient identifier comprises any one or more of a patient name, a patient ID, a location identifier, and a bed identifier.
  • two or more patient identifiers and associated parameterised data are displayed in the first view.
  • the patient identifiers displayed are dependent on one or more of: a registered user of the display, a location of the display and or a registered location of the display.
  • the registered location of the display comprises a room or ward of a hospital.
  • a second view is displayed on the display screen, the second view comprising current and historical values of the parameterised data for the corresponding patient displayed as a time series.
  • the second view further includes a component risk score indicator characterising the patient’s risk of deterioration based on at least a portion of the available parameterised data.
  • the component risk score corresponds to a clinical risk index and/or an early warning score.
  • the component risk score indicator is provided in the form of a gauge, wherein the gauge is sectioned according to thresholds in the corresponding parameterised data.
  • any of the systems set out above further comprise a display system configured to display the parameterised data on a display screen in a first view, wherein the parameterised data is displayed along with a corresponding patient identifier.
  • the patient identifier comprises any one or more of a patient name, a patient ID, a location identifier and a bed identifier.
  • two or more patient identifiers and associated parameterised data are displayed in the first view.
  • the system is configured to receive a selection of a patient identifier, and on detection of the selection, display a second view on the display screen, the second view comprising current and historical values of the parameterised data for the corresponding patient displayed as a time series.
  • the display screen is configured to display as part of the second view a component risk score indicator characterising the patient’s risk of deterioration based on at least a portion of the available parameterised data.
  • the component risk score indicator indicates the value of one or more parameterised data relative one or more thresholds.
  • the one or more thresholds are customizable by a user or clinician.
  • the hub comprises a location sensor configured to sense the location of the bed.
  • the location sensor comprises an RFID reader configured to read an RFID sensor.
  • the bed is a hospital bed.
  • the processing system is configured to process the measurements to an electronic patient record.
  • the processing system comprising: a processing server in data communications with a and one or more databases for storing a plurality of electronic patient records therein; wherein the processing system is operable to: receive, through the hub, identify the sensor that transmitted the sensor data, identify the patient ID associated with the sensor, determine at least one parameterised data from the sensor data, and store the parameterised data to at least one of the electronic patient records.
  • the bed comprises one or more sensors.
  • the one or more sensors comprise a non-contact sensor to sense physiological parameters.
  • the one or more sensors comprise an under mattress sensor configured to sense physiological parameters.
  • the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level.
  • the patient parameters comprise respiratory rate and heart rate.
  • the present disclosure may broadly be said to consist in a patient monitoring system comprising: a data management server in communication with a hub, the hub wirelessly coupled to plurality of sensors configured to measure one or more physiological parameters of a plurality of patients, the data management server configured to: receive, via the hub, sensor data from the plurality of sensors; wherein at least one of the plurality of sensors comprises at least one non-contact sensor configured to measure at least one of respiratory rate and heart rate, and wherein the hub is configured to transmit the sensor data to the data management server and the data management server is configured to convert the received sensor data into parameterised data.
  • the plurality of sensors are associated with and/or coupled to an item of furniture.
  • the item of furniture is a bed or a chair.
  • the item of furniture is associated with a patient a.
  • the one or more sensors comprise an under mattress sensor.
  • the patient management system is for use in one or more of a hospital, or a home environment.
  • the patient management system is for use in an intensive care unit of a hospital.
  • the system is configured to allow connection of one or more further sensors to the hub and the data management server.
  • the data management system is configured to calculate a component risk score based, at least in part, on the parameterised data.
  • the one or more sensors comprise any one or more of a respiratory rate sensor and a heart rate sensor.
  • the one or more sensors comprise a plurality of types of sensors, each type of sensor configured to sense a different physiological parameter.
  • the sensors comprise sensors any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level.
  • the component method may use the system as outlined above or below and/or include any of the method steps outlined above and/or below.
  • Features from one or more aspects or configurations may be combined with features of one or more other aspects or configurations.
  • Figure 1 illustrates a patient monitoring system 10 in accordance with an aspect of the present disclosure.
  • Figure 2 illustrates a bed locator system arranged in a room of a facility.
  • Figure 3 illustrates a pre-processing server portion of the patient monitoring system 10 in accordance with an aspect of the present disclosure.
  • Figure 4 illustrates a post-processing server portion of the patient monitoring system 10 in accordance with an aspect of the present disclosure.
  • Figure 5 is a flow diagram illustrating a method performed at the router in accordance with an aspect of the present disclosure.
  • Figure 6 is a flow diagram illustrating a method in accordance with an aspect of the present disclosure.
  • Figure 7 is a flow diagram illustrating a method in accordance with an aspect of the present disclosure.
  • Figure 8 is a flow diagram illustrating a data collection method in accordance with an aspect of the present disclosure.
  • Figures 9 and 10 show elements of a graphical user interfaces provided on a screen of the display system.
  • Figures 11 and 12 show an exemplary earning warning score matrix from the Adult Early Warning Scoring System in use in New Zealand from 2021.
  • Figure 13 shows elements of a graphical user interfaces provided on a screen of the display system.
  • Figure 14 shows a schematic of how a component risk score and a clinical risk index may be based on patient data.
  • Figure 15 shows exemplary early warning score categories alongside their corresponding ranges of normalized clinical risk index.
  • Figures 16 shows a patient view of monitored patient data and a component risk score.
  • Figure 17 shows a patient view with multiple live patient data readings with component risk scores.
  • Figure 18 shows live patient data across time periods.
  • Figure 19 shows a radar plot of patient data at different times.
  • Figure 20 shows a group view of a plurality of patients being monitored, each represented by a tile.
  • Figure 21 shows an example tile from Figure 20.
  • Figures 22 and 23 show sections of the group view, with tiles scaled for emphasis.
  • Figure 24 shows a section of the group view where the display of tiles has been adjusted based on risk band.
  • Figure 25 shows a group view of a plurality of patients being considered for discharge, each patient represented by a tile.
  • Figure 1 shows a system that provides for the monitoring of one or more patients in a hospital or home environment.
  • the location of the patients may be referred to as a facility, covering either a hospital, medical location or a home.
  • the system provides for the collection of patient data from a plurality of sensors 20, and the subsequent transfer of that data to one or more processing servers 40 via an intermediary router and/or hub 30.
  • the terms hub and router may be used interchangeably to refer, at least, to a device configured to receive wireless communications from sensors and transmit communications to a server.
  • the sensors 20 may include patient worn sensors, sensors mounted to furniture 22, such as a patient bed 1 and/or contactless sensors.
  • the sensors 20, 22 may be attached to, or part of, a therapy device 21.
  • the sensors may be attached to, or part of, a respiratory support device or a respiratory therapy device.
  • the respiratory support device or therapy device may be a high flow therapy device (e.g. AirvoTM 2 or AirvoTM 3) or a respiratory humidifier or a THRIVETM therapy device in anesthesia or sedation.
  • the system may also communicate with a surgical humidifier or other gas delivery or gas conditioning device used in surgery or anesthetic procedures or sedation procedures.
  • the sensors may comprise different types of sensors configured to measure different physiological parameters.
  • the system is configured to monitor respiratory health of a patient, as this is often an indicator of other health issues/diseases. Further, respiratory distress or failure often triggers a patient being moved to critical care, which is resource intensive and can reduce the quality of patient outcomes as compared to early treatment of health issues/diseases.
  • Conventional systems rely on self-reporting by patients, healthcare practitioners taking periodic vital sign measurements, and/or disparately collected sensor information. However, patients frequently do not realize their condition is deteriorating until after they need critical or elevated levels of care. Similarly, periodic vital sign measurements obtain only small snapshots of the patient’s condition and may not raise concerns until after a patient needs critical or elevated levels of care.
  • the disparate collection of information from sensors can limit the availability of information from any one sensor (e.g., only available to a practitioner in the room) and/or provide an incomplete picture of a patient’s health (e.g., when a practitioner cannot see information from multiple sensors at once).
  • sensors e.g., blood pressure sensors, cardiac monitors, temperature sensors, respiratory monitors, and the like
  • conventional sensors all output in different formats for display on different devices local to the patient and/or in different user interfaces. Each device may have a proprietary format or communication protocol requiring independent monitoring and limiting the ability to combine measured data.
  • the number of sensors in a facility requires extensive collection and processing of potentially interfering signals.
  • the system and/or method provide an open architecture which allows sensors to be easily added or removed.
  • the system and/or method also allows hospitals to apply their own monitoring protocols and or customise the system protocols, monitoring protocols and/or output displays.
  • the open architecture may allow custom monitoring protocols to be implemented in a straightforward and centralised manner.
  • the present systems and methods can help allow healthcare providers to detect early-stage deterioration of a patient’s respiratory health – thereby allowing for rapid and timely intervention by a supervising clinician.
  • the systems and methods disclosed herein can use the plurality of sensors 20 to monitor various vital signs (e.g., respiratory health, cardiological health, and/or the like) continuously (or almost continuously).
  • the data from the plurality of sensors 20 can help detect, for example, respiratory deterioration early on (e.g., as soon as a change in respiratory health occurs), reducing (or eliminating) the need for self- reporting from patients and significantly supplementing periodic vital sign measurements.
  • the early identification can allow a healthcare provider to begin treatment of respiratory distress/diseases significantly earlier, which can help avoid the need to elevate patients to critical (or other high levels) care.
  • the systems and methods disclosed herein are expected to help improve patient outcomes and help reduce the resource demands associated with treating patients, thereby allowing healthcare providers to have more bandwidth and/or resources to treat other patients.
  • the disclosed systems and methods can enable data from the plurality of sensors 20 to be efficiently collected, stored, processed, and/or analyzed in a central location.
  • the systems and methods disclosed herein can use the plurality of sensors 20 to collect raw data relating to a patient and/or use the router 30 to collect the raw data from the plurality of sensors 20.
  • the plurality of sensors 20 and the router 30 can communicate using advertising channels of a short-range wireless communication protocol (e.g., BluetoothTM). Using the advertising channels to communicate the data allows any number of sensors to communicate with the router 30 without requiring a dedicated channel, a dedicated connection, and/or a specified data format.
  • a short-range wireless communication protocol e.g., BluetoothTM
  • the systems and methods disclosed herein allow a larger number and/or a wider variety of sensors to communicate with the router 30. Additionally, or alternatively, the router 30 and each of the plurality of sensors 20 requires less energy since the router 30 and the plurality of sensors 20 do not have to maintain a constant connection to each other.
  • the use of the advertising signal or packet being used to transmit sensor data optionally encoded, reduces power consumption and/or bandwidth consumption of the sensors and/or the hub. The means the sensors and/or hub uses less power or require smaller power sources to operate and makes the system easier to use as less charging is required.
  • additional sensors can be added ad hoc to customize the monitoring to a specific patient’s healthcare needs, without disrupting a network and/or requiring a network to be updated to accommodate the additional sensors.
  • the router 30 can forward the data to the processing server 40.
  • the router 30 passes the raw data directly to the processing server 40 without caching performing any other process on or with the data. This allows the data to be forwarded (and ultimately displayed) in real time or near real time – proving a better resolution view of a patient’s health condition.
  • the processing server 40 processes the raw sensor data to produce parameterised data which is subsequently stored and added to a patients electronic medical file and optionally displayed on a screen as part of patient monitor hardware either in a hospital or home environment.
  • the systems and methods described herein are expected to reduce the resource requirements to accommodate the plurality of sensors 20. Further, in contrast to conventional systems, the systems and methods described herein allow data from a wide variety of sensors to be collected, processed, displayed, and/or analyzed in a central location. DETAILED DESCRIPTION OF COMPONENTS AND OPERATIONS OF THE SYSTEM [00362] The configuration and operation of aspects of the system will now be described in further detail.
  • the plurality of sensors 20 are configured to monitor a patient and produce sensor data indicative of said patient’s status.
  • the sensors may be referred to as health sensors as they measure patient physiological parameters indicative of a patient’s health.
  • the parameters may be indicative of improving or deteriorating patient health.
  • the plurality of sensors comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, and a SpO2 sensor provided in the form of one or more wearable sensors mountable to the patient – it being noted that respiratory distress is often a key indicator of deteriorating patient health.
  • the plurality of sensors 20 may include one or more sensors provided in or under an item of furniture.
  • sensors may be capable of determining one or more physiological parameter of the patient (such as respiratory rate and heart rate).
  • physiological parameter of the patient such as respiratory rate and heart rate
  • a ballistocardiograph allows heart rate and/or respiratory rate to be measured without contact to a patient’s body.
  • any suitable sensor may be incorporated into the plurality of sensors 20 provided they operate as set out below.
  • a benefit of using one or more sensors under the mattress of the patient’s bed is that it improves comfort for the patient, by avoiding the need to otherwise wear a sensor for the parameter to be measured.
  • the plurality of sensors 20 are configured to transmit sensor data to the router 30.
  • the sensor data is in the form of raw or otherwise unprocessed data from the sensors.
  • the sensor data may be in the form of an analogue signal or alternatively a digital value representative of the analogue signal.
  • the data transmission from the plurality of sensors 20 to the router 30 is provided by a short-range wireless transmission, such as NFC (near field communication), RFID (radio frequency identification), ZigBeeTM or any other suitable means.
  • the parameterised data is then added to the patient’s electronic medical record.
  • the parameterised data is further passed to an event handler 110 which is capable of generating alerts and/or triggering action should the parameterised data fall below or exceed a predetermined threshold for a predetermined time period.
  • the parameterized data being above or below the predetermined threshold may determine if the systems outputs, to a healthcare provider or a clinician or on a display, an indication of the parameterized data (or, for example a component risk score). This may ensure appropriate care is provided to the patient, or that an alarm or automated care is provided.
  • the processing server 40 is also used to register a hospital bed against each of the plurality of sensors 20 using a bed registration service that onboards the hospital bed and associates a device ID of each sensor in the plurality of sensors 20 against a bed ID of the bed.
  • these device ID- bed ID pairs are stored in a database at the processing server 40.
  • the bed registration service is hosted outside of the processing server 40, with the processing sever 40 having access to the database 45 in which bed IDs and device IDs are stored. In an aspect this works in the bed registration service works in the same manner as the patient registration service described herein. Although beds are described the registration process could be associated with other hospital furniture, including chairs.
  • Associating the sensors with a hospital bed may reduce the complexity of tracking within the system.
  • the clinicians identify patients through the hospital bed and/or the location of the hospital bed in a particular room or ward.
  • the clinicians can be alerted directly to the location of the patient of interest when attention is required.
  • each bed may identify the bed’s location in the hospital.
  • the identification process may comprise detecting a location marker associated with a location in the hospital.
  • the location marker may be a short-range wireless device.
  • a passive short-range wireless device is used so as the location marker does not require power.
  • an RFID tag is a passive device which may be read by a hub.
  • each potential bed location may have an associated RFID tag.
  • a router 30 on the bed may detect the RFID tag when in the bed location. This detection allows an association between the bed and the bed location to be determined by the system.
  • a patient can then be associated with the bed.
  • the location of the bed may also update other recorded data or associations.
  • the location may be associated with a clinician. If moving the bed to a new location changes the clinician (e.g., a nurse or doctor) the system may update the clinician responsible for the bed to the clinician of the new location. For example, if the bed is moved between wards the clinician in charge and/or the ward processes may be automatically updated.
  • the hospital beds have an onboarding process.
  • the onboarding process may comprise associating a patient with the bed.
  • the onboarding process may associate any sensors already linked to that patient with the bed.
  • the onboarding process may associate any sensors already linked to the bed with the patient.
  • Whether a sensor is linked to a bed or a patient may depend on the whether the sensor is attached and/or connected to the bed or the patient. For example, a sensor attached to the bed frame and/or mattress may be associated with the bed, while a sensor monitoring heartrate and attached to a patient’s body may be associated with the patient (who can then be associated with the bed).
  • the staff may choose to associate a sensor with the patient and/or the bed.
  • sensors may be associated with a location.
  • an onboarding process may also be used to associate sensors with the bed, separate to, or in conjunction with, the bed ID process.
  • the system when one of more sensor(s) is/are located on the patient bed, and not directly attached to the patient assigned to that bed, the system is configured to verify the presence of the patient in the bed before processing/accepting any data from the sensor(s).
  • the presence of a patient may be detected by a pressure sensor, PIR sensor, and/or by detecting the presence of an RFID tag embedded in the patient’s ID bracelet.
  • the RFID tag may be assigned to the bed and/or patient as part of the onboarding process.
  • the bed sensors may comprise non-contact sensors to sense physiological parameters. For example an under mattress sensor may be used.
  • the bed sensors may measure any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level.
  • contact sensors may be used.
  • a contact SpO2 sensor may be used.
  • the bed sensors comprise a respiratory rate sensor and a heart rate sensor.
  • a ballistocardiograph sensor may be used to measure both heart rate and respiratory rate without contacting the patient.
  • the use of heart rate and respiratory rate typically provides an accurate component risk score, allowing the system to identify patients with potential risks quickly and without the need for contact sensors, as the patient simply needs to be on the bed and/or chair.
  • the sensor data associated with the bed may be sent through the hub (which also may be associated with the bed) to the processing server.
  • the bed provides a central location for the hub, and allows the connection of further sensors as required, or as the patient’s condition develops.
  • a haemoglobin composition sensor may be used to provide a further indication of patient health. Having the hub receive the data from a plurality of sensors over an advertising channel allows it to quickly and efficiently receive large amounts of data. The data can then be processed by a processing server and reported or display as described herein.
  • the respiratory rate and heart rate are sensed with one or more non- contact sensors.
  • the sensor may be a single sensor sensing both respiratory rate and heart rate, or individual sensors may be used.
  • Respiratory rate is an early stage indicator of patient health. As respiratory rate deviates from a normal range this is indicative of deterioration in respiratory health which is often a precursor to other more commonly diagnosed symptoms. For example if the patient has influenza, the respiratory rate and heart rate increase beyond normal (i.e. the resting respiratory rate and heart rate are higher than normal range) before any fever or runny nose of cough develops.
  • Associating the sensors with the hospital bed may also simplify the attachment of hardware.
  • the hospital bed typically has a power source to which the router 30 may be connected.
  • the hospital bed may have sensors mounted to it.
  • FIG. 2 shows six hospital beds (labelled 1 to 6) in a room, such as in a hospital ward.
  • a locator 8 such as an RFID tag is positioned behind each bed.
  • Each bed comprises or is attached to a router 30, which may be secured, for example, to a frame of the bed.
  • the router 30 may be beneath the bed, or attached to the head of the bed, or otherwise connected.
  • the hospital beds may be moveable. For example, they may be on wheels so as patients may be moved about the facility on the beds.
  • the locator 8 and the router 30 communicate to determine the position of the bed. For example, if bed 1 is moved into position it communicates with the locator 8 next to it to confirm its position in the room, or facility.
  • the communication is optionally wireless, such as where the locator system 8 is an RFID device read by the router 30, although wired or other physical connections may be used.
  • the communication has a limited range. A limited range may avoid interference or confusion between neighboring beds.
  • the communication may have a transmission distance of less than 2 meters, less than 1 meter or less than 0.5 meters.
  • the routers 30 of neighboring beds, or beds in the same room or ward may interact to determine relative positions of the beds in the room. This may be advantageous where a locator 8 is not present or is not operational.
  • the router 30 on bed 2 may obtain a measurement distance of bed 1 and bed 4 and triangulate a position based on these (or further readings). The measurement distance could be calculated by the signal strength, or angle of arrival.
  • the routers 30 may have a GPS or other location sensor configured to determine their location and reference a map of the hospital or building to determine their location.
  • Other locators 8 are possible, for example a geofence, BluetoothTM, or reference point(s) could be organized in each room or location.
  • Figure 3 depicts an aspect in which in addition to receiving sensor data from the plurality of sensors 20, the router 30 is also configured to receive data regarding the therapy being provided to the patient by one or more medical device 200.
  • a medical device 200 is a respiratory therapy device or a respiratory support device.
  • the respiratory therapy device can provide respiratory therapy or support and may be a high flow therapy device or a ventilator, or humidifier configured to provide one or more of.
  • the respiratory device may be a respiratory humidifier that may condition gases from a ventilator prior the providing gases to a patient.
  • CPAP Continuous positive airway pressure
  • NHF Nasal High Flow
  • Bilevel therapy Continuous positive airway pressure
  • the respiratory therapy/support device may be a multi-mode therapy device configured to provide both high flow therapy and Bilevel therapy.
  • the respiratory device has a flow generator, humidifier, tube and a patient interface.
  • the respiratory therapy device has sensors to record various therapy parameters such as flow, pressure, temperature, humidity.
  • the device may also transmit usage information and/or data measured by onboard sensors such as SpO2, respiratory rate and heart rate measured either directly or indirectly via other physiological parameters or indicators monitored by the medical device 200 itself.
  • one or more of the plurality of sensors 20 are provided as part of the medical device 200.
  • the skilled person would appreciate that the presently disclosed data processing methodology is independent to and agnostic of the exact and particular nature of medical device 200 provided it functions as described below.
  • the one or more medical device 200 includes a BluetoothTM communications module capable of connecting to the processing server 40 via the router 30.
  • the router 30 is able to identify the type, manufacturer and/or model of the medical device 200 by the transmitted therapy data.
  • the router 30 identifies the medical device 200 by the structure of the therapy data.
  • a device ID of the medical device 200 is encoded into the therapy data itself.
  • the sensors may comprise a haemoglobin composition sensor and an under the mattress sensor. The under the mattress sensor may sense respiratory rate and/or heart rate. In combination these two sensors can provide an early indication of patient health deterioration.
  • the therapy data is formed of one or more parameters relating to a flow rate, humidity level, dew point, usage time, pressure rate or pressure deliver, or O2 fraction of a flow of gases for delivery to the patient, or any other suitable or desired data.
  • said therapy data is broadcast to the router 30, where it is time stamped before delivery to the processing server 40.
  • the therapy date may be set by a clinician may be broadcast.
  • the therapy data is time stamped on receipt at the processing server 40.
  • the therapy data is encoded within the advertising data packets of a BluetoothTM transmission for collection by the router 30, which subsequently transmits the therapy data to the processing server 40 by IP protocol.
  • the therapy device is configured to transmit therapy data to the hub via the advertising packet.
  • the therapy device may include a short-range wireless interface, such as a BluetoothTM interface.
  • the therapy device may incorporate the therapy data into the advertising packet transmitted by the therapy device.
  • the processing server 40 is operational to process the received therapy data in the same manner as the received sensor data described above, namely by activating a handler 70 corresponding to the identified medical device, or by creating a handler 70 if one does not already exist with the appropriate driver 71. This allows for new medical devices to be added to the system without the need to reprogram the component parts of the system to account for the change in hardware – rather the processing server need only access and/or create a handler 70 and driver 71 corresponding to the new medical device.
  • one or more medical devices 200 can be removed from the system, and their corresponding handlers can be retired or otherwise deactivated such that the processing server 40 continues to function efficiently.
  • This therapy data is then able to be added to the patient’s electronic medical file as a time series along with the corresponding processed sensor data relating to the patient’s physiological parameters, providing a comprehensive and continuous treatment history alongside the corresponding physiological parameters of the patient.
  • This temporal pairing of the parameterised data describing a patient’s condition along with the therapy parameters describing the treatment conditions existing at the time the sensor data is generated provides the reader of the electronic medical record with a measure of both the efficacy of the applied therapy and a measure of the patient’s compliance to one prescribed therapy regime.
  • FIG. 4 depicts a portion of the system 10 that receives the parameterised data from the processing server 40.
  • the parameterised data can be forwarded to a sensor data engine 300 which may otherwise be referred to as a data processing engine or patient data management engine. This may either be a part of the system 10 of external to the system 10.
  • the sensor data engine 300 can update a copy of the patient’s electronic medical records, pass to a data analytics engine or prediction engine (once stripped of any personal information relating to the patient, if present) for assessment and predictive/trend analysis, generate patient specific alerts or notifications, and/or automatically populate patients forms and records as required.
  • the parameterised data is sent to a display system 310 present in either a hospital environment or a home treatment environment to visually display the parameterised data.
  • Figure 5 shows a process performed by the router 30.
  • the router scans radio bands for any transmissions.
  • a determination is made as whether any transmissions are incoming, such a transmission of sensor data from one or more of the plurality of sensors 20.
  • the router 30 is configured to scan for any known sensors registered against the patient.
  • the router 30 is able to discover newly added sensors at this stage. Once transmissions are detected, the router 30 checks for an active connection to the processing sever 40 at step S130.
  • FIG. 6 shows a process performed at the dispatcher 60 of the processing server 40.
  • the transmission related from the router 30 is received.
  • the transmission is relayed directly to the dispatcher 60.
  • transmissions from the router 30 are cached and fed to the dispatcher 60 depending on available processing resources.
  • the dispatcher 60 identifies the device that generated the received sensor data and performs a check for an active handler 70 corresponding to the identified device. If a corresponding handler 70 is located, the sensor data is forwarded to the handler 70.
  • the dispatcher 60 determines if the identified device is compatible with the system 10. If an incompatibility is detected, the device information is logged, and no further action is taken. If on the other hand the device is considered compatible, the dispatcher 60 creates a handler instance with the correct driver 71 for the identified device at step S240.
  • Figure 7 shows a further process performed at the dispatcher 60 of the processing server 40. Following receipt of sensor data from the plurality of sensors 20 via the router 30 and identification of the specific device or device type that generated the sensor data, a handler 70 is instanced with the correct driver 71 at step S310.
  • a patient registration service 41 and the associated database 45 are contacted to discover if the determined device ID is linked to a patient ID. If the device is not assigned to a patient ID, the device ID is associated with the patient ID registered to the router 30 by which the sensor data was relayed. If the device ID is discovered to be linked to a patient ID other than that registered to the router 30, the device ID is re-assigned.
  • a counter initiates to wait for a predetermined length of time during which sensor data is expected to be received. If no sensor data is relayed from the router 30 during this time, a timeout counter is initiated and incremented. When a timeout condition is reached before any sensor data is received, the handler instance self- terminates at step S370.
  • the handler will terminate immediately after processing a transmission of sensor data such that system resources are not committed to idly waiting for a transmission.
  • the timeout counter is reset at step S340, followed by the creation of a time stamp corresponding to the time of reception at step S350.
  • the transmitted sensor data is parsed by the driver. If the data is found to contain monitoring information relating to the patient, such as respiratory rate, heat rate and SpO2 data then the parameterised data, patient ID, device ID and timestamp are cached ready to be added to the database 90 and the process returns to step S330 to await further sensor data. If no monitoring information is contained in the sensor data the handler 70 returns to step S330.
  • the handler 70 is able to take corrective action in accordance with the driver 71, for example attempting to switch to another driver 71 if available.
  • an error condition is logged at the progresses to step S370 and self-terminates.
  • this process may be adapted for use with a bed ID.
  • the bed registration service may be contacted at or before S320 to determine if the device ID is associated to a bed IR and/or a patient ID. The system may then check if the bed ID is associated with a patient ID. In this, or by another process the device ID is linked to a patient ID through the bed ID.
  • Figure 8 shows a process performed at the database 90 of the processing server 40 that stores the parameterised data as a time series.
  • the database 90 receives either new parameterised data output by the handler 70 or a request for patient data already stored in the database 90.
  • a check is made at step S430 to determine if a time series exists in the database 90 for the sensor, parameter and/or patient that is the subject of the request. If a series does exist, the newly received data is appended to the existing series. Alternatively, a new series is created and the new data is added as the first entry.
  • a check is performed at step S420 as to whether the patient identified in the request is included in the database 90.
  • a corresponding error message is generated.
  • a further check is performed at step S440 to determine whether a time series exists in the database 90 for the patient and/or any particular parameter that is the subject of the request. A negative result returns an error message in response to the request. If a time series is identified, said series is interrogated at step S450 to determine if measurements exist for any specific time range identified in the request, resulting in either the requested results being returned in answer to the initial query, or an error stating that no corresponding data is available.
  • DISPLAY SYSTEM 310 [00416] Aspects relating to the display of the parameterised data will now be set out in more detail.
  • ‘real time’ and ‘substantially real time’ are used to refer to the immediate processing and display of data as soon as it is generated, transmitted and received. As such, ‘real time’ is dependent on the sampling rate of the sensor(s), the transfer rate of raw data, latency in processing the raw data into parameterised data and the refresh rate of the display itself.
  • parameterised data can be output as a time series associated with a particular patient ID and/or Bed ID and stored as part of said patient’s electronic medical record either in real time, at regular periods, or when specifically requested.
  • This parameterised data may also be displayed via display system 310 thereby allowing patients and clinicians to monitor a patient status visually as well as interact with the available data.
  • the display system 310 comprises a screen and one or more user input means.
  • Said user input means may take the form of a graphical user interface 400 operated via one or more of an integrated touch screen interface, mouse and keyboard and/or other physical control means.
  • the screen displays a graphical user interface 400 comprising a dashboard with actively monitored patients organised into groups, where an overview of the current state of the patients within each group can be accessed by a clinician via a so-called “Group View” 410.
  • This “Group View” can provide a curated view of health datapoints for each patient in the group, including the most recently received values of certain parameterised data along with patient names, ID’s and/or bed numbers as well as an indication of the location of each patient in the hospital/ward where appropriate.
  • the “Group View” may include one or more or all of the physiological parameters being monitored such as respiratory rate, heart rate and SpO2.
  • the specific selection of displayed parameters may be customized by a clinician, set at an organizational or facility level, or reflect a system default.
  • the order in which patients are displayed in the “Group View” may be alphabetical or numerical (according to either a patient’s name or ID) or may alternatively be determined by a score, such as an early warning score, associated with each patient. Patients having a higher score may appear higher or more prominently in the list.
  • a score such as an early warning score
  • An individual “Patient View” 420 is also accessible for each actively monitored patient and may be accessed directly or by selecting a single patient entry from the afore mentioned “Group View”. As shown in Figure 10, in this “Patient View” the patient name and ID are again displayed. The bed ID and location may also be displayed. Also displayed are the names and sensor IDs of the individual sensors associated with the patient, together with the associated parameterised data received from each respective sensor. In an aspect, sensor information and the associated parameterised data corresponding to each sensor is automatically added to the patient view 420 on detection of the sensor 20 forming part of the system and receipt of the corresponding data by the relay 30 or processing server 40.
  • One or more time series graphs may also be shown displaying the current and historical values of the parameters monitored by the sensors and/or medical devices linked to the patient.
  • a separate graph may be provided for each parameter (with each graph having a common timescale), or alternatively the time series of two or more parameters may be overlayed on the same graph regardless of whether the device from sensor data or a medical device.
  • the size of the time period displayed on the graphs can be adjusted by selecting from a list of pre-set values (such as 5, 10, 15, 30 minutes, or integer days, weeks or months) or by interacting with a sliding scale bar, dial or other control element forming part of the user interface 400 - thereby allowing any desired time window to be selected.
  • the portion of the time series displayed on the graphs at any one time is represented by a graphical timeline 430.
  • the highlighted region is representative of the time period visible on the graphs.
  • the length of the period of time displayed on the graphs may be increased or decreased by interacting with the graphical timeline 410 to change the size of a highlighted region.
  • the highlighted region may also be transposed along the timeline to move the displayed portion forwards or backwards in time, thereby allowing historical data to be viewed in high resolution.
  • the display system 310 also comprises an indicator 440 that may form part of either or both of the “Group View” and “Patient View” described above.
  • a separate indicator 440 may be provided for each of the monitored and displayed physiological parameters and may incorporate the most recent value of a parameter or alternatively may incorporate a rolling average over a pre-set or user selected time period.
  • the indicator is provided in the form of a radial gauge surrounding the parameter value.
  • the gauge is sectioned according to thresholds in the value of the parameter, with lower threshold provided on the left-hand side, and higher threshold provided on the right-hand side.
  • a pointer 441 is also provided, its position representative of the current parameter value displayed at the center of the gauge. [00422]
  • the sections of the gauge are determined and colour coded according to an associated state of the patient.
  • a gauge corresponding to the patient’s heart rate could have a section coloured green for values between the lower and upper thresholds of 40 and 160 bpm, which is usually considered healthy.
  • These thresholds can also be set to predetermined values associated with the facility and/or country in which the system 10 is employed. In one aspect, the system 10 is provided with a look-up table of such predetermined values and employs them automatically when its location is input and/or detected.
  • the thresholds may also be manually defined or selected on first set up of the system by a technician and may further be edited by a clinician or user according to their specific preferences. In an aspect the thresholds may be set by a facility based on, for example, the protocols used at that facility.
  • aspects of the disclosure provide for customization of both the inputs and outputs of the system, advantageously this allows for hospitals or clinicians to provide the required reporting and/or monitoring set by regulations or hospital protocols. This can be centrally managed due to the open nature of the system and the flexibility of the system architecture in processing storing and displaying the patient health parameters, patient data or ward or multiword overviews.
  • appropriate actions can be taken as defined (for example) in the table of figure 12. Additionally, or alternatively, an action may comprise raising an alarm at an appropriate hospital alarm system or automatically sending a message to a clinician containing data regarding the particular measured parameter(s) and the threshold(s) exceeded.
  • These actions may also include recording each instance (and the associated metadata) where the measured parameters of a patient are outside particular thresholds. Such instances may be added to the patient’s electronic medical records. Accordingly, if a parameter drops below or increases above a threshold or is out of a threshold range, the system can identify when this happened and for which parameter and report accordingly.
  • the patient ID or bed ID is associated with a clinician, including being associated with a location that is then associated with a clinician, the alarm may be sent directly to the associated clinician. This reduces the number of alarms or alerts for each clinician. In some cases, for example where the alarm is not responded to within a period of time or is rejected, the alarm or alert may be sent to a second clinician or to the hospital alarm system.
  • the alarm or alert may be customized to state the urgency or condition causing the alarm.
  • a graph of the physiological parameter may be included in the alarm, or the component risk score may be shown.
  • the indicator 440 is depicted as a radial gauge, the skilled person would appreciate that any suitable graphical representation may be used, such as a linear gauge, bullet graph or pie gauge.
  • Figure 13 shows a version of the above-described patient view 420 in accordance with an aspect in which the patient is receiving therapy from a medical device 200 (such as the respiratory therapy device described earlier).
  • the display includes graphical representations (for example, in the form of a time-series graph) of therapy settings over time, including an indication of the operational mode of the therapy device and usage data along alongside the corresponding measured physiological petameters and indicator 440.
  • graphical representations for example, in the form of a time-series graph
  • This allows for clinicians to observe the effectiveness of therapy and interventions by viewing any subsequent changes in the measured patient’s physiological parameters.
  • providing access to the treatment history of the patient on a shared time axis with monitored physiological parameters is useful to establish a baseline for how the patient will likely respond to therapy settings based on previously observed responses.
  • the system addresses a problem of handling sensor data from a plurality of sensors.
  • COMPONENT RISK SCORE [00433] As set out above, in clinical settings, there are many evaluation frameworks used to aggregate a variety of inputs to categorize the risk of the patient’s condition deteriorating. Often a combination of physiological measurements and subjective measures are used to derive an output that can inform care decisions, such as a score or risk band/category.
  • the Early Warning Score (EWS) framework described earlier is an example of a clinical risk index that is widely used in hospitals. For each metric or contributing physiological parameter, a score or clinical risk index is determined based on where the values of said metric or parameter falls between predetermined thresholds. Based on this score, the patient is placed in one of five colour categories or risk bands associated with framework (e.g. white, yellow, orange, red, and blue) signifying increasing risk of health deterioration.
  • framework e.g. white, yellow, orange, red, and blue
  • the illustrated example corresponds to the Early Warning Score framework described above. It is envisaged that any particular colours or risk bands may be employed.
  • a component risk score is adapted from a clinical risk index.
  • Figure 14 shows how aspects of a clinical risk index can be incorporated into a component risk score.
  • the component risk score may incorporate one or more of the measurements of a clinical risk index, or measurements related to or based upon the measurements of a clinical risk index. By using only the available measurements, and basing a score on a combination, maximum or minimum of they available measurements the component risk score is able to continuously estimate a clinical risk index.
  • clinician reported values such as consciousness
  • the component risk score may include both measurement data and clinical reported values and/or patient characteristics (e.g., age, weight, height, length of stay).
  • the intra-category range of parameter values are normalized for each contributing measurement in a component risk score. This increases the granularity of risk information available to clinicians and allows for directly comparing the relative risk posed by different measurements using a unitless value.
  • the normalized value allows the system to rank the risk scores for each of the contributing measurements within the risk band.
  • the scale may be nonlinear, so as to emphasize the changes at areas of most concern.
  • the scale may be non-linear so as to emphasize changes to high-risk patients, while the low- risk patients show less variation.
  • Using a component risk score may be particularly beneficial as it allows for tracking the patient’s risk at finer increments than the overarching risk bands or categories, making the progression of the patient more visible, as clinicians can track the overall risk of the patient in greater detail within each band and not just between bands.
  • Figure 15 shows an exemplary component risk score (in this case referencing the Early Warning Score framework described earlier) along with a corresponding normalized component risk score generated according to an aspect.
  • a normalization process for the component risk score or Early Warning Score framework may involve splitting the five risk categories or bands into ten discreet values so that a patient can be graded on a 50-point risk scale ranging from white (0) to blue (40+) across all of the risk bands. As shown in Figure 11, for each measurement type (i.e. contributing physiological parameter), the range of values corresponding to each category or risk band may vary. Accordingly, min-max normalization is employed to ensure that the outputted normalized clinical risk index always reflects the proportional distance to the next risk band, and from the previous risk band.
  • the normalized component risk score is calculated according to the equation: ⁇ ⁇ [00441]
  • the measured value is the value of a physiological parameter being obtained from sensor data (for example, a patient’s respiratory rate).
  • the lower risk threshold is the parameter value for the edge of the risk band that marks the transitions to a lower risk band.
  • the upper risk threshold is the limit on the edge of the neighboring higher risk band.
  • the lower risk score is the lower limit of the new normalized component risk score for the risk band.
  • the scaler number is equal to the normalized component risk score range applied to each risk band (i.e. 10 in this the present example - though the scaler number could be changed to any number depending on the desired point scale of the normalized component risk score).
  • the normalized clinical risk index is an improvement over non-normalized indices not just because it provides increased granularity relating to a patient’s position within each risk band, but also in that changes (and the rate of change) in the normalized component risk score toward a threshold of a risk band provide a measure of how likely (and when) a patient might transition from one risk band to another.
  • an individual component risk score or normalized component risk score (in the following the use of component risk score should be understood as also or alternatively referring to normalized component risk score, where possible) can be calculated for each of a plurality of physiological parameters including but not to respiratory rate, heart rate, SpO2, blood pressure, body temperature, carbon dioxide level and temperature.
  • the calculated individual component risk scores are then used to determine an overall or total component risk score.
  • the total component risk score is set to the highest value of the individual component risk scores.
  • the total component risk score is given by averaging the values of the individual component risk score.
  • the component risk scores may account for differences in measurements, for example a weighted average may be used, or the normalized component risk score.
  • the total component risk score is given by a weighted average of the individual component risk score, wherein the weighting is based on a predetermined rule set that may optionally depend upon the framework employed or the number and/or particular combination of physiological parameters being measured. It may also be set by the clinician according to their preferences.
  • the total component risk score is given by summing two or more of the component individual component risk scores and comparing the summed value to a predetermined threshold, wherein the threshold may again depend upon the scoring framework, the number and/or particular combination of physiological parameters being measured or be set by the clinician.
  • a graphical display of the component risk score (in this case normalized) presented as a time series.
  • This may be an individual component risk score derived from a single physiological parameter, or it may be a total component risk score derived from a plurality of physiological parameters as set out above.
  • the time series graph may be accompanied by an indicator 440 of the kind described earlier.
  • visual indicators of the risk bands associated with different thresholds of the component risk score are extended across the time axis of the graph. Figure 16 shows these in horizontal greyscale bars, but they may be coloured to match the component risk score.
  • the time series graph is updated in real time as new data is received from sensors and a more recent value of the component risk score is calculated.
  • the indicator 440 can provide a rolling average of the component risk score over a pre-set or user selected time period. Alternatively, the indicator 440 may only be updated when data is received that results in a change in the displayed value of the component risk score. The clinician is thus provided with a continuous times series representation of the patient’s risk, which constitutes an improvement over the stepwise jumps in risk bands that would otherwise be displayed without use of the component risk score.
  • Figure 17 shows a patient view in accordance with a further aspect in which the component risk score is displayed alongside live patient data as described above in relation to Figure 10.
  • the order of the graphs on screen may be such that the data relating to each physiological parameter is presented in descending order of their contribution to the total component risk score – i.e. physiological parameters that indicate a patient is at a high risk may be located further up the screen or in an otherwise more prominent position. This allows for clinicians to visually compare the trends of the component risk score alongside the constituent health measures.
  • treatment details or parameters of the therapy being applied to the patient may also be displayed as described above in relation to Figure 11.
  • a patient view may show changes to the live patient data in a plurality of time periods.
  • Figure 18 shows patient data for three time periods, although more or less may be used.
  • average data is used to represent changes to the patient data in that time period.
  • Figure 18 shows three weekly time periods 500.
  • average values have been calculated.
  • a median value 501, upper quartile 502 and lower quartile 503 are shown. This consolidates a patient’s changes over a longer period of time into a patient view. This distils the time-series data stored by the system into an overarching metric of the patient’s health.
  • interpolation may be used to connect between time periods to create a visual link between the periods.
  • the interpolation is shown as linear, but an estimated curve or alternative interpolation may be used.
  • the patient view may include risk categories 506, shown in this case as horizontal bands. These help the patient view show the changes in patient data relative to expected performance.
  • the time periods may be larger or smaller. For example, daily time periods, or hourly time periods, or four-hourly time periods, or monthly time periods, or integer days, weeks or months. The number of time periods may change, for example there may be seven, each representing a day of the week, of 4 representing weeks of a month.
  • the patient view may be switchable to view different measured data and/or may display multiple data plots in each view.
  • the patient view may have a list of pre-set values (such as 5, 10, 15, 30 minutes, or integer days, weeks or months).
  • a time-series database allows the system to quickly display the time period views and/or update them in real-time as the data can be quickly obtained from the time-series database.
  • a time-series database is a database optimized for storing and serving time series through associated pairs of time(s) and value(s). This allows the production of profiles or curves based on the data. Each data point in the database is associated with a timestamp. In some cases, the time-series database does not store data indefinitely or reduces the amount of old data stored. This may be achieved through down sampling or deletion, for example.
  • the time-series database may store a predefined time period or window f data (e.g., last year, last month, last week).
  • the timestamp may be used as a key index to improve processing of the data.
  • the present system ensures each sensor measurement has an accurate timestamp to allow entry into the time-series database.
  • One example time-series database is InfluxDBTM.
  • Figure 19 shows an alternative patient view of patient data in different time periods.
  • a radar graph is shown to represent five patient data values (in this case, respiratory rate, temperature, heart rate, SpO2 and blood pressure). Values are shown for two time periods 601, 602. These may be values at particular times or may be minimum, maximum and/or average values within the time period.
  • the radar graphs allow for the values of each measured value to be compared across the time periods. For example, a clinician may note that the heart rate has had a large increase while the blood pressure has remained more constant.
  • the radar graph may be used to show temporal changes in a set of features to a clinician without the need for them to view each individual measurement and/or review an entire time-series. Again, the time-series database is able to quickly produce the data required for these graphs because of the storage of data in time series.
  • alternatives to radar graphs can be used. For example, an area chart, a lollipop chart, a radial column chart, a stellar chart.
  • Figure 20 shows a group view in accordance with a further aspect. As depicted, the display screen is divided horizontally into sections 1000, each representing a particular risk band in the utilized component risk score framework.
  • the screen is divided into five sections 1000 corresponding to the white, yellow, orange, red and blue risk bands/categories of the Early Warning Score framework.
  • Each patient in a plurality of monitored patients is represented in the group view by a tile 1100 that is displayed in a section 1000 of the display according their component risk score and the risk band within which it falls.
  • the tile may refer to the Bed ID and/or location as well as, or instead of the patient, to allow clinicians to quickly locate a patent.
  • the display is updated to reposition the tile within its section and eventually (if the score changes enough) moved to another section corresponding to a new risk band.
  • the position of a tile with a section may be driven by a time- averaged value of the component risk score, where the average value is calculated over a period of time that may be predetermined or set by a clinician, thereby preventing a patient tile from flickering between sections of the display.
  • the transition of a patient tile from one section to another may be determined by one or more predetermined rules in addition to a time averaged value of the component risk score, for example if the value of the index designates the patient as falling within a different risk band a certain number of times within a preterminal time period.
  • the system may show hysteresis to slow transfer between sections.
  • the boundary between sections may not be a single number (e.g., 30) but instead be a higher number when entering the section (e.g., 32) and a lower number when leaving the section (e.g., 28). In this way a patient cannot move as quickly between sections and monitoring can be continued until, for example, they have fully left a high-risk section.
  • the group view may be a multi-ward view. A multi-ward view allows multiple patients to monitored across multiple rooms and/or wards simultaneously. The multi-ward view may allow a clinician to get a clear overview of all the patients in the facility or hospital, or across home care sites in a single display.
  • the multi-ward view is customizable so that a clinician can view a subset of the patients in one or more facilities. For example, the clinician may wish to view the patients they are responsible for, which may be spread across a plurality of locations.
  • the multi-ward view provides the ability to view all of these patients in real-time and to have the most important information, or most at-risk clients, shown in the most detail.
  • Each tile includes key identifying information is displayed, such as the patient’s name, id number, room, and/or bed allocation.
  • Additional health information may be displayed including but not limited to an indicator 1200 of the total component risk score associated with the patient, the most recent value of the physiological parameter which is most strongly contributing to said total component risk score, any other contributory physiological parameters that are being actively monitored and the parameters associated with any therapy the patient is receiving. Any such therapy parameters are not used in the calculation of the component risk score, but they nevertheless provide context to the clinician monitoring the patients in this view. This allows clinicians to directly compare the metrics driving health changes between patients presented on a single screen. An example tile is shown in Figure 21. [00458] In an aspect, the indicator 1200 of the total component risk score is colour coded depending on a trend in its value.
  • the indicator 1200 may be colour coded green. Conversely, a trend indicating an increasing risk may result in the indicator being colour coded red. Patients with stable indices – i.e. an score that is not trending substantially in either direction – may be colour coded grey or not colour coded. Trends in the component risk score may also be determined by a rolling average of the component risk score increasing or decreasing, where in either case, a patient tile is updated to elevate its prominence in the group view.
  • the data included on a patient tile (or equivalently bed tile) as well as the manner in which it is displayed (e.g. layout, font size, colour, typeface) is dynamically updated in real time or near real time based upon one or more of the magnitude of the component risk score of the patient, trends in the component risk score, time since updated data relating to the patient was received, or time since the patient was last observed by a clinician.
  • the display of the tile itself e.g.
  • Figures 22 and 23 show sections of the group view associated with specific risk bands, along with the patient tiles within each section. As depicted, patients with a component risk score that is trending in one direction or another have their tiles displayed more prominently within their section. In some aspects, the tiles of patients who have recently changed sections from one risk band to another are also displayed more prominently. In an aspect, this includes enlarging the patient tile and positioning it towards the top of the respective section. Any enlarged tiles within a section may be organized by the gradient of change in the component risk score, or its magnitude, or some combination of both factors.
  • enlarged tiles include more information of use to the clinician, such as an expanded set of live measurements corresponding to the physiological parameters being actively monitored for that patient. In this way, patients who are most likely to shift between sections (or risk bands) are highlighted to a clinician over patients who are likely to maintain their current level of risk.
  • Patients with a stable component risk score, or a score below a certain threshold with the risk band may have their tiles minimized and displayed towards the lower portion of the corresponding section of the display.
  • these minimized tiles include the same data as provided on the enlarged tiles, albeit with reduced size and emphasis such that patient data is still available to the clinician but not at the expense of the more prominent display of patient tiles representing patients that are more likely to require attention.
  • the display of patient tiles may differ depending on the section in which they are displayed i.e. the risk band in which the patient falls.
  • Figure 24 shows an aspect where a patient tile in the Blue section (or highest risk band) may include bolded text in a larger font.
  • the size of each section may change depending on the relative proportion of patient tiles displayed within that section.
  • the size of the white, yellow, orange and blue sections may be reduced so as to ensure all the patient tiles in the red section are visible on the display screen simultaneously at a suitable resolution and size.
  • the tiles for patients in the sections corresponding to lower risk bands may be reduced in size to accommodate the display of all patient tiles in sections corresponding to higher risk bands. These reduced tiles may show less information than would otherwise be the case, such as fewer live metrics.
  • any sections with no patient tiles may be minimized or removed from the display altogether.
  • Patients that need a clinician’s attention are the most visible, and first to be seen on the dashboard. Additionally, the clinician can view all of the aforementioned information on the patient tiles as well as the risk level associated with every patient in their care on a single screen without needing to access menus or interface with a computer mouse or touch screen. This allows the most relevant information to be presented to a clinician, from the large amount of data and information in the patient management system. Furthermore, the live, real time nature of the date being used to determine a patient’s physiological parameters and component risk score means that the patient tiles are always updating and moving around the screen accordingly. This means the display ensures that the clinician is focused on the most urgent patients and/or tasks.
  • the display of patient tiles may be dynamically adjusted depending on characteristics of the display.
  • the display may have a registered user, such as a clinician.
  • the display may then update to only show and/or to highlight and/or enlarge tiles for which the nurse is responsible. In this way the attention of the clinician is directed to the patients they manage (or the beds in their room or ward), and the limited display area focusses or only shows data on these patients.
  • the characteristic may be a location of the display.
  • the display may show and/or highlight and/or enlarge tiles in the same room as the display.
  • a display is mounted in a location such as a room or ward.
  • the display is configured to show tiles for each patient in the room or ward.
  • the display may be configured to determine, from the system, which patients are in the room or ward, and only display the patients present.
  • the manner of the display of each of the tiles may be adjusted as described above, based on the component risk score and/or how close the clinician is to the patient. For example, if the clinician is standing next to the patient the display may show substantially only that patient. This allows the display to clearly show staff the current situation in a particular location.
  • the tiles may be enlarged and/or highlighted as described previously to indicate particular concerns.
  • DISCHARGE SYSTEM [00467] Aspects relating to the display of the parameterized data have been explained with reference to monitoring patients during the the care by clinicians. However, additional views of the parametrized data may be used for other purposes. In some cases, the display may be switched between alternative views depending on clinical requirements. For example, a first view for monitoring patient wellbeing and a second view for considering whether a patient can be moved or released.
  • the alternative views may be based on a component risk score (or risk index).
  • the component risk score may be the same for each view (with, for example, a different presentation), or there may be alternative component risk scores.
  • the alternative views may be based on an alternative metric.
  • FIG. 25 shows a group view in accordance with a further aspect. This aspect is configured, for example, to allow a clinician to identify patients ready for discharge. However, alternative characteristics, or combinations of characteristics, may be used to create and display patient bands. As depicted, the display screen is divided horizontally into sections 2000, each representing a particular risk band for discharging a patient.
  • the screen is divided into five sections 2000 corresponding to example bands of risk associated with discharge of a patient.
  • the discharge score could be based on, or incorporate a component score and/or one or more values measured in real-time or near real-time.
  • Customization of a discharge view advantageously allows for hospitals or clinicians to provide the required reporting and/or monitoring set by regulations or hospital protocols before discharge. This can be centrally managed due to the open nature of the system and the flexibility of the system architecture in processing storing and displaying the patient health parameters, patient data or ward or multiword overviews.
  • Each patient in a plurality of monitored patients is represented in the group view by a tile 2100 that is displayed in a section 2000 of the display according their discharge score and the risk band within which it falls.
  • the display is updated to reposition tile the within its section and eventually (if the score changes enough) moved to another section corresponding to a new risk band.
  • the position of a tile with a section may be driven by a time-averaged value of the discharge score, where the average value is calculated over a period of time that may be preterminal or set by a clinician, thereby preventing a patient tile from flickering between sections of the display.
  • the transition of a patient tile from one section to another may be determined by one or more predetermined rules in addition to a time averaged value of the discharge score, for example if the value of the score designates the patient as falling within a different risk band a certain number of times within a preterminal time period. For example, if a patient appears to be at the lowest risk of discharge, but has only recently entered this category, or has moved regularly out of this category they may be placed in a higher risk category until the discharge score has improved.
  • Each tile includes key identifying information is displayed, such as the patient’s name, id number, and room or bed allocation.
  • Additional health information may be displayed including but not limited to an indicator 1200 of the total discharge score associated with the patient, the most recent value of the physiological parameter which is most strongly contributing to said total discharge score (e.g., the highest risk component, which might limit discharge), any other contributory physiological parameters that are being actively monitored and the parameters associated with any therapy the patient is receiving. Any such therapy parameters are not used in the calculation of the discharge score, but they nevertheless provide context to the clinician considering discharge of the patients in this view. This allows clinicals to directly compare the metrics driving health changes between patients presented on a single screen.
  • the discharge score may also, or alternatively use further algorithms or measurements to determine categories of risk associated with patient discharge. For example, an algorithm such as a decision tree, rules engine, or flow chart could be used to determine patient categories.
  • the characteristics may include the measured trends of the patient, patient characteristics (for example, age, weight, ethnicity, sex) or therapy characteristics (illness, diagnosis, therapy applied, therapeutic devices used, time under therapy).
  • the measured trends of the patient may comprise the discharge score, parts thereof, or physiological measurement data collected using a real time patient monitoring system.
  • the therapy characteristics may comprise an initial diagnosis; a record of the diagnosis over a patient’s stay at the facility; observations by caregivers or clinicians and/or comorbidities and past medical history.
  • socio-economic factors such as a patient’s support network and/or the home environment may also be considered.
  • the patient, therapy and/or socio-economic data may be inputted into the system by a clinician, patient or from an electronic medical record or patient medical record.
  • the discharge component risk score at least attempts to consider the current condition of a patient and a predicted future condition of a patient.
  • the patient characteristics may help assess the future risks of readmission and/or deterioration outside the care facility.
  • the forecasting of expected discharge could use historical data on performance of previous patients (either using the current system, or from corresponding data).
  • the system is configurable to allow discharge scores, or discharge risk levels to be adjusted in, or within, each facility. This allows each facility to configured desired discharge processes conforming to their own practices.
  • the system may allow adjustment of any one or more of inputs, weighting and categorization.
  • Further displays may use tiles and features of tiles as shown in Figures 21, 22 and 23, but with a focus on discharge score.
  • the indicator 1200 of the total discharge score is colour coded depending on a trend in its value. That is, if the most recent successive calculations of the discharge score indicate a downward trend in patient discharge risk (within a risk band or between neighboring risk bands), the indicator 1200 may be colour coded green. Conversely, a trend indicating an increasing risk may result in the indicator being colour coded red. Patients with stable indices – i.e. an index that is not trending substantially in either direction – may be colour coded grey or not colour coded.
  • the colour coding may depend on the level of risk – stable low risk may be colour coded green as this also suggests suitable for discharge. Trends in the discharge score may also be determined by a rolling average of the discharge score increasing or decreasing, where in either case, a patient tile is updated to elevate its prominence in the group view. It is envisaged that alternative visual trend indicators may be used, including the size and font used to display the current value of the discharge score, or the colour of an associated graphical element on the tile. [00475] In an aspect, the data included on a patient tile as well as the manner in which it is displayed (e.g.
  • the layout, font size, colour, typeface is dynamically updated in real time or near real time based upon one or more of the magnitude of the discharge score of the patient, trends in the discharge score, time since updated data relating to the patient was received, or time since the patient was last observed by a clinician.
  • the display of the tile itself e.g. size, background colour, outline
  • the discharge score relates to alternative measures or requirements, such as any one or more of patient monitoring, discharge, change of therapy.
  • the system may perform tasks based on the displayed data. For example, the system may identify or raise an alert of those patients that are potentially ready for discharge.
  • the system may prepare the discharge forms.
  • the discharge forms may be provided to the clinician electronically, for example by a link on the display.
  • the clinician may have to perform steps to finalize the discharge decision after receipt of the forms.
  • An indicator on the display may show that the forms, or other materials are ready.
  • the display may determine whether to display a discharge view or a monitoring view based on the patient risk. For example, where a patient is in a high-risk band the display may only show a monitoring view.
  • the system comprises a secondary display or device This may provide an alert or an alarm to a portable computing device, such as a tablet or a mobile phone.
  • An alert to a secondary device may be restricted to a portion of possible alerts. For example, alerts may only be sent to the secondary device at a certain level of risk, or based on a subset of patients (e.g., the patients the clinician is directly responsible for). In an aspect the alert may also flash or be notified on a primary display. Using a secondary display to receive targeted alerts reduces the number of alarms or alerts for each clinician. In some cases, for example where the alarm is not responded to within a period of time or is rejected, the alarm or alert may be sent to a second clinician or to the hospital alarm system. The alarm or alert may be customized to state the urgency or condition causing the alarm.
  • a graph of the physiological parameter may be included in the alarm, or the component risk score may be shown.
  • the display may only present a selection of patients in the discharge view. For example, the display may only show the lowest, or lowest two bands. This may reduce the complexity shown on the screen to focus on the most likely patients to be discharged. Attempting to determine patients appropriate for discharge can be difficult due to the large amount of information and many possible patients.
  • the use of the discharge view allows a large amount of information to be shown clearly on the display by drawing the clinician to the most relevant, or most urgent information.
  • the responsiveness of healthcare professionals to a sudden deterioration of patient’s condition can be dramatically improved without increasing the work required by the healthcare professionals themselves, but rather by utilizing the sensors and/or medical devices to continuously monitor and report on the patient’s status in real time and by providing a system that can dynamically receive and process data from such sensors and/or medical devices.
  • the real time aspect provides healthcare professionals greater visibility and certainty and allows for earlier intervention if a patient’s status deteriorates.
  • the rapid identification of patients showing signs clinical deterioration can result in an improvement in the care an outcome of patients. This is typically expressed as a reduction in the duration of care or reduced acuity of care, such as the admission to the intensive care unit (ICU) etc.
  • ICU intensive care unit
  • embodiments may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof.
  • the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium such as a storage medium or other storage(s).
  • a processor may perform the necessary tasks.
  • a code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements.
  • a code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc.
  • a storage medium may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information.
  • ROM read-only memory
  • RAM random access memory
  • magnetic disk storage mediums including magnetic disks, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information.
  • machine readable medium and “computer readable medium” include, but are not limited to portable or fixed storage devices, optical storage devices, and/or various other mediums capable of storing, containing or carrying instruction(s) and/or data, including non-transitory mediums.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, circuit, and/or state machine.
  • a processor may also be implemented as a combination of computing components, e.g., a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • the methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices.
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD- ROM, or any other form of storage medium known in the art.
  • a storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
  • One or more of the components and functions illustrated the figures may be rearranged and/or combined into a single component or embodied in several components without departing from the present disclosure. Additional elements or components may also be added without departing from the present disclosure. Additionally, the features described herein may be implemented in software, firmware, hardware, and/or any combination thereof.
  • the present disclosure can be embodied in a computer- implemented process, a machine (such as an electronic device, or a general purpose computer or other device that provides a platform on which computer programs can be executed), processes performed by these machines, or an article of manufacture.
  • a machine such as an electronic device, or a general purpose computer or other device that provides a platform on which computer programs can be executed
  • Such articles can include a computer program product or digital information product in which a computer readable storage medium containing computer program instructions or computer readable data stored thereon, and processes and machines that create and use these articles of manufacture.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Medical Informatics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • General Health & Medical Sciences (AREA)
  • Pathology (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Veterinary Medicine (AREA)
  • Surgery (AREA)
  • Molecular Biology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Biophysics (AREA)
  • Animal Behavior & Ethology (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Psychiatry (AREA)
  • Physiology (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Artificial Intelligence (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)
  • Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)

Abstract

A method of processing wireless sensor data at a server, the method comprising the steps of; receiving sensor data from a plurality of wireless sensors; determining a device type associated with the received sensor data; retrieving and activating at least one handler for the received sensor data, the at least one handler comprising a driver configured to process the sensor data into parameterised data; and converting the received data into parameterised data. A method for generating a normalized component risk score based on the measurement of one or more physiological parameters of a patient, the method comprising the steps of: receiving sensor data; determining a physiological parameter from the sensor data; determining a normalized component risk score based on the physiological parameter; outputting the normalized component risk score.

Description

PATIENT MONITORING METHOD AND SYSTEM TECHNICAL FIELD [0001] The present disclosure generally relates to the collection and remote processing of data from one or more wireless sensors. More particularly it relates to the real time collection, monitoring and display of patient data. BACKGROUND [0002] In today's healthcare environment, patients can be found in a variety of states of wellbeing, either from diseases they have, or from controlled surgical interventions. In many circumstances, patients are monitored to assess either their state of wellbeing or to identify early indications of health deterioration and identify the need for changes in treatment. Most patients in unstable states of wellbeing present with some form of respiratory failure or changes in respiratory function. [0003] Outside of specialist care environments such as ICU and cardiothoracic care the current state of the art for monitoring the state of wellbeing of a patient, and in particular monitoring for respiratory failure or changes in respiratory function is through manual observation and estimation (e.g. counting breaths manually for respiratory rate), or though using sensors coupled to the patient and which monitor one or more physiological parameters of the patient. Sensors such as pulse oximeters or heart rate sensors are typically used. Manual monitoring is only performed occasionally, while reviewing sensor data is only performed intermittently. [0004] The medical records for a patient in healthcare environment are typically kept as a paper chart at a patient’s bedside. Typically in order to keep track of the monitoring of a patient, a healthcare provider will at regular intervals make a manual note on a patient’s chart detailing the instantaneous read outs of the sensors and compare them to previous readouts over time. This places considerable limitations on the time taken for a nurse, or other healthcare provider. [0005] Electronic medical records are increasingly being used to allow for accurate and up- to-date information regarding the care received by an individual across healthcare providers. In order to deliver optimum, coordinated healthcare and most cost-effective healthcare to their patients, healthcare providers need to have ready access to an up-to-date medical history of their patients. Definitions [0006] Patient – an individual being treated for an illness or disease, or otherwise having their health or state of wellbeing monitored, this could be in a typical hospital environment, or alternatively in a home or aged care environment. SUMMARY [0007] In a first aspect the present disclosure may broadly be said to consist in a method for generating a component risk score based on the measurement of one or more physiological parameters of a patient, the method comprising the steps of: receiving sensor data; determining a physiological parameter of the patient from the sensor data; determining a component risk score based on the physiological parameter; outputting the component risk score. [0008] Optionally, the sensor data is received over one or more advertising channels of a short-range wireless communication component. [0009] Optionally, determining the component risk score comprises associating at least one of the at least one physiological parameter with a risk band of a corresponding plurality of risk bands, each risk band in the plurality of risk bands having a respective first upper and first lower threshold, the associated at least one physiological parameter falling between the first upper and first lower thresholds of the corresponding risk band. [0010] Optionally, the component risk score corresponds to a clinical risk index. Optionally, the clinical risk index corresponds to an early warning score. [0011] Optionally, the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level. [0012] Optionally the supplementary oxygen is determined by a sensor on a respiratory device and/or a sensor integrated into a respiratory device. [0013] Optionally, the risk bands correspond to predetermined Early Warning Score values. [0014] Optionally, the plurality of risk bands comprises a first risk band and second risk band. [0015] Optionally, the size of the first risk band is different to the size of the second risk band. [0016] Optionally, the size of a risk band is defined by the difference between its first upper and first lower threshold. [0017] Optionally, the physiological parameter is one of temperature, body temperature, blood pressure, respiratory rate, heart rate, carbon dioxide level, and SpO2 (blood oxygen saturation). [0018] Optionally, the physiological parameter and component risk score are stored as a time series. [0019] Optionally, the physiological parameter and component risk score are updated in real time. [0020] Optionally, the component risk score is recalculated at regular intervals of time. [0021] Optionally, the component risk score is recalculated only when new sensor data is received and an updated physiological parameter is determined. [0022] Optionally, the method further comprises the steps of: determining a second physiological parameter from the sensor data; determining a second component risk score based on the second physiological parameter; outputting the second component risk score; and determining a total component risk score based on the first and second component risk score. [0023] Optionally, determining the total component risk score comprises selecting the highest of the first and second component risk score as the total component risk score. [0024] Optionally, determining the total component risk score comprises averaging the first and second component risk score. [0025] Optionally, determining the total component risk score comprises calculating a weighted average of the first and second component risk score, wherein the weighting is based on a predetermined rule set. [0026] Optionally, determining the total component risk score comprises summing the first and second component risk score and comparing the summed value to a predetermined threshold. [0027] Optionally, the method further comprises the step of: displaying the component risk score in a first view of a display screen, wherein the component risk score is displayed along with a patient identifier, the patient identifier corresponding to a patient associated with the sensor data and the physiological parameter derived therefrom. [0028] Optionally, the patient identifier comprises any one or more of a patient name, a patient ID, a location identifier and a bed identifier. [0029] Optionally, the component risk score is displayed in the form of a gauge, wherein the gauge is sectioned according to the second upper and second lower thresholds of the plurality of risk bands. [0030] Optionally, the gauge displays a rolling average of the component risk score. [0031] Optionally, displaying the component risk score further comprises displaying a graphical time series showing current and historical values of the component risk score. [0032] Optionally, the method further comprises the step of: displaying the physiological parameter in the first view of a display screen. [0033] Optionally, displaying the physiological parameter further comprises displaying a graphical time series showing current and historical values of the physiological parameter. [0034] Optionally, the graphical time series are updated in real time as updated values are determined. [0035] Optionally, the method further comprises the steps of: displaying the second physiological parameter; displaying the second component risk score; and displaying the total component risk score. [0036] Optionally, the display of the first and second physiological parameter is arranged based on their associated first and second component risk score. [0037] Optionally, the display of the first and second physiological parameter is arranged according to the relative contribution of the first and second physiological parameter to the total component risk score. [0038] Optionally, the method further comprises the step of receiving parameters of a therapy being provided to the patient by a respiratory support device and/or usage data representing the patient’s use of the respiratory support device; and displaying said therapy parameters and/or usage data on the display screen. [0039] Optionally, the therapy parameters and/or usage data are displayed as a time series and updated in real time. [0040] Optionally, the method further comprises the step of: displaying, in a second view of a display screen, one or more patient identifiers, each associated with a patient and component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the relative value of their associated component risk score. [0041] Optionally, the one or more patient identifiers are grouped into regions of the display, each region associated with a risk band of the plurality of risk bands. [0042] Optionally, the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score. [0043] Optionally, the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated. [0044] Optionally, the one or more patient identifiers are in the form of a tile. [0045] Optionally, the one or more patient identifiers each comprise a risk indicator. [0046] Optionally, the risk indicator includes a numerical value indicative of the risk level of a patient based on their component risk score and the associated risk band. [0047] Optionally, the risk indicator is updated in real time, as updated values of the component risk score are determined. [0048] Optionally, the numerical value is a rolling average. [0049] Optionally, the risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same. [0050] Optionally, the risk trend indicator is colour coded. [0051] Optionally, the one or more patient identifiers further comprises a display of one or more physiological parameters associated with the patient, wherein the selection and arrangement of the one or more physiological parameters is based on their contribution to the component risk score. [0052] Optionally, the display of the one or more physiological parameters is updated in real time. [0053] Optionally, the display of the one or more physiological parameters comprises a rolling average of the one or more physiological parameters. [0054] Optionally, the one or more patient identifiers each comprise one or more of the following elements: a patient identification number, a patient room number, a patient bed number, a patient bed location, a patient name, and an indication of the time expired since a clinician last interacted with the patient. [0055] Optionally, the presence, size, and/or display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the component risk score. [0056] Optionally, the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score. [0057] Optionally, the second risk band is a higher risk band than the first risk band. [0058] Optionally, the estimated amount of time is provided by analyzing a trend in historical values of the component risk score. [0059] Optionally, the one or more patient identifiers are grouped into regions of the display, each region associated with a discharge risk determined, at least in part, on the component risk score. [0060] Optionally, the size and/or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score. [0061] Optionally, the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated. [0062] Optionally, the one or more patient identifiers are in the form of a tile. [0063] Optionally, the one or more patient identifiers each comprise a discharge risk indicator. [0064] Optionally, the discharge risk indicator includes a numerical value indicative of the risk level of discharging a patient based on their component risk score. [0065] Optionally, the discharge risk indicator is updated in real time, as updated values of the component risk score are determined. [0066] Optionally, the numerical value is a rolling average. [0067] Optionally, the discharge risk indicator further comprises a discharge risk trend indicator that is configured to change its state depending on whether the discharge risk level of the patient is increasing, decreasing or staying the same. [0068] Optionally, the discharge risk trend indicator is colour coded. [0069] Optionally, the one or more patient identifiers further comprises a display of one or more physiological parameters associated with the patient, wherein the selection and arrangement of the one or more physiological parameters is based on their contribution to the component risk score. [0070] Optionally, the display of the one or more physiological parameters is updated in real time. [0071] Optionally, the display of the one or more physiological parameters comprises a rolling average of the one or more physiological parameters. [0072] Optionally, the one or more patient identifiers each comprise one or more of the following elements: a patient identification number, a patient room number, a patient bed number, a patient name, and an indication of the time expired since a clinician last interacted with the patient. [0073] Optionally, the presence, size, and/or display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the discharge risk score and/or component risk score. [0074] Optionally, the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first discharge risk band, to another region of the display associated with a second discharge risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first discharge risk band, to another region of the display associated with a second discharge risk band as a result of a change in the respective component risk score. [0075] Optionally, the second risk band is a lower risk band than the first risk band. [0076] Optionally, the estimated amount of time is provided by analyzing a trend in historical values of the component risk score. [0077] Optionally, the discharge risk score depends on any one or more of patient characteristics, therapy characteristics and/or socio-economic factors. Optionally the patient characteristics comprise any one of more of: age, weight, ethnicity, and sex. Optionally the therapy characteristics comprise any one or more of: illness, diagnosis, therapy applied, therapeutic devices used, time under therapy. Optionally the socio-economic factors comprise any one or more of: patient’s support network and the home environment. [0078] Optionally the discharge risk is determined by any one or more of as a decision tree, rules engine, or flow chart. [0079] Optionally the display is configurable to switch between showing discharge risk and component risk scores. [0080] Optionally the method comprises sending an alert to the display. [0081] Optionally, the method comprises displaying summarized physiological parameters for a plurality of time periods. [0082] Optionally, the summarization comprises any one or more of a selected value, an average value, a maximum value, a minimum value, a mean value, upper quartile value, lower quartile value and a median value. [0083] Optionally, the plurality of time periods comprise an integer number of hours, days, weeks and/or months. [0084] Optionally, each of the physiological parameters is displayed on an independent axis. [0085] Optionally, the summarized physiological parameters are displayed in the form of a chart. [0086] Optionally the chart comprises any one or more of a radar chart, an area chart, a lollipop chart, a radial column chart, a stellar chart. [0087] Optionally, the chart comprises at least two time periods. [0088] Optionally, the chart displays risk categories corresponding to the physiological parameters. [0089] Optionally, the chart displays interpolated data between adjacent time periods. [0090] Optionally, the chart summarizes data from the stored time series data. [0091] In a further aspect the present disclosure may broadly be said to consist in a patient monitoring system configured to perform the methods set out above. [0092] Optionally, the patient monitoring system comprises: one or more sensors; and a processing server. [0093] Optionally, the component risk score is a normalized component risk score and/or comprises normalizing the component risk score. [0094] Optionally, determining the normalized component risk score comprises feature scaling or min-max normalization of the physiological parameter within the first thresholds of the risk band to give a measure of the position of the physiological parameter within the first thresholds of the risk band. [0095] Optionally, determining the normalized component risk score comprises standardizing the size of each risk band in the plurality of risk bands to a preferred size W, wherein each risk band has a second upper threshold and second lower threshold separated by W. [0096] Optionally, the normalized component risk score is determined according to the formula: ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ − ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ = × ^^ + ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ − ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ [0097] In an aspect the present disclosure may broadly be said to consist in a method for monitoring patients with a plurality of health sensors to identify patients with deteriorating health, the method comprising: receiving sensor data from the plurality of sensors over one or more advertising channels of a short-range wireless communication component, the sensor data based on measurements of an individual patient; determining a physiological parameter of the individual patient from the sensor data; determining a health condition based on the physiological parameter; outputting the health condition. [0098] Optionally the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score. [0099] In an aspect the present disclosure may broadly be said to consist in a method for operating a sensor system to monitor health of a patient, the method comprising: receiving sensor data from a plurality of sensors via one or more advertising channels of a short-range wireless communication component; determining one or more physiological parameters of the patient based on the sensor data from the plurality of sensors; determining a health condition based on the physiological parameter; and outputting the health condition. [00100] Optionally, each of the plurality of sensors is associated with, attached or attachable to an item of furniture. Optionally, the furniture comprises one or more of a bed and a chair. Optionally the processing system is operable to identify a patient ID by determining a patient ID associated with the furniture. Optionally the plurality of sensors comprises an under- mattress sensor. Optionally the sensor comprises an under-cushion sensor. Optionally the sensors are non-contact sensors for respiratory rate and/or heart rate. Optionally the hub receives the transmission data from the plurality on an advertising channel. [00101] Optionally the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score. [00102] In an aspect the present disclosure may broadly be said to consist in a method for operating a sensor system to monitor health of a patient, the method comprising: receiving sensor data from a plurality of sensors via one or more advertising channels of a short-range wireless communication component, the sensor data indicative of one or more physiological parameters of the patient; detecting, based on the sensor data, that a health parameter of the patient is above or below a predetermined threshold; and outputting, to a healthcare provider, an indication of the health parameter to cause the healthcare provider to provide treatment to the patient. [00103] Optionally detecting that the health parameter of the patient is above or below the predetermined threshold comprises comparing two or more different physiological parameters, each physiological parameter obtained from sensor data from in the plurality of sensors. [00104] Optionally detecting that the health parameter of the patient is above or below the predetermined threshold comprises: determining the one or more physiological parameters from the sensor data; and determining, based on the one or more physiological parameters, the health parameter of the patient; and comparing the health parameter to the predetermined threshold. [00105] Optionally the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score. [00106] In a further aspect the present disclosure may broadly consist in a method for operating a hub for a system for monitoring a patient’s health, the method comprising: receiving, from a first sensor peripheral to the hub, a first data packet via a first advertising channel of a short-range communication component, wherein the first data packet contains sensor data from the first sensor related to a first physiological measurement of the patient; sending the first data packet to a server peripheral to the hub via a network communication component. receiving, from a second sensor peripheral to the hub, a second data packet via a second advertising channel of the short-range communication component, wherein the second data packet contains sensor data from the second sensor related to a second physiological measurement of the patient; and sending the second data packet to the server via the network communication component. [00107] Optionally the first advertising channel is the same as the second advertising channel. [00108] Optionally the first advertising channel is different from the second advertising channel. [00109] Optionally further comprising at least partially processing the first data packet before sending the first data packet to the server. [00110] Optionally further comprising formatting the first data packet before sending the first data packet to the server. [00111] Optionally further comprising adding a timestamp to the first data packet. [00112] Optionally further comprising forwarding the raw data and/or unprocessed first sensor data, in the first data packet to the server. [00113] Optionally the first physiological parameter is the same as the second physiological parameter, and wherein the method further comprises combining the first data packet and the second data packet before sending the first data packet and the second data packet to the server. [00114] Optionally the network communication component is a wireless internet component. [00115] Optionally the first data packet is received in a continuous stream of data packets from the first sensor via the first advertising channel. [00116] Optionally the first data packet and the second data packet are sent to the server at the same time. [00117] Optionally, further comprising receiving, from a third sensor peripheral to the hub, a third data packet via a third advertising channel of the short-range communication component, wherein the third data packet contains sensor data from the third sensor related to a third physiological measurement of the patient. [00118] Optionally the first data packet includes a patient identifier, and wherein the second data packet includes the patient identifier. [00119] Optionally the above aspect method may optionally comprise any of the steps or features of the preceding or following aspects, where the health condition is a component risk score. [00120] In a further aspect the present disclosure may broadly be said to consist in a hub for a system for monitoring health of a patient, the hub comprising: a short-range communication component; a network communication component; a processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receive, from a first sensor peripheral to the hub, a first data packet via a first advertising channel of the short- range communication component, wherein the first data packet contains sensor data from the first sensor related to a first physiological measurement of the patient; sending the first data packet to a server peripheral to the hub via the network communication component, receiving, from a second sensor peripheral to the hub, a second data packet via a second advertising channel of the short-range communication component, wherein the second data packet contains sensor data from the second sensor related to a second physiological measurement of the patient; and sending the second data packet to the server via the network communication component. [00121] In a further aspect the present disclosure may broadly be said to consist in a system for monitoring a patient’s health, the system comprising: a central hub, the central hub comprising a short-range communication component with a plurality of advertising communication channels; a first sensor peripheral to the central hub, the first sensor configured to obtain measurements of a first physiological parameter of the patient and send first data packets to the central hub via a first advertising channel of the plurality of advertising communication channels, wherein each of the first data packets contains data related to the measurements of the first physiological parameter; and a second sensor peripheral to the central hub and the first sensor, the second sensor configured to obtain measurements of a second physiological parameter of the patient and send second data packets to the central hub via a second advertising channel of the plurality of advertising communication channels, wherein each of the second data packets contains data related to the measurements of the second physiological parameter. [00122] Optionally the above two aspects may optionally comprise any of the steps or features of the following systems, where the health condition is a component risk score. [00123] In a further aspect the present disclosure may broadly be said to consist in a patient management system comprising: a data management server in communication with a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients, the data management server configured to: receive, via a network, sensor data from the plurality of sensors; determine a component risk score for each of the plurality of patients from the sensor data; assign the plurality of patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and cause a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with a patient of the plurality of patients and their component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the value of their associated component risk score. [00124] Optionally, the sensor data is received over one or more advertising channels of a short-range wireless communication component. [00125] Optionally, the component risk score is calculated according to the method steps set out above and/or below. [00126] Optionally, the component risk score corresponds to a clinical risk index. [00127] Optionally, the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level. [00128] Optionally, the one or more patient identifiers are grouped into regions of the display, each region associated with an upper and lower threshold for the component risk score, said thresholds defining a plurality of risk bands. [00129] Optionally, the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score. [00130] Optionally, the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated. [00131] Optionally, the one or more patient identifiers are in the form of a tile. [00132] Optionally, the one or more patient identifiers each comprise a risk indicator. [00133] Optionally, the risk indicator includes a numerical value indicative of the risk level of a patient based on their component risk score and the associated risk band. [00134] Optionally, the risk indicator is updated in real time, as updated values of the component risk score are determined. [00135] Optionally, the numerical value is a rolling average. [00136] Optionally, the risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same. [00137] Optionally, the risk trend indicator is colour coded. [00138] Optionally, the one or more patient identifiers are grouped into regions of the display, each region associated with an upper and lower threshold for a discharge risk, the discharge risk dependent, at least in part, on the component risk score. [00139] Optionally, the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score. [00140] Optionally, the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated. [00141] Optionally, the one or more patient identifiers are in the form of a tile. [00142] Optionally, the one or more patient identifiers each comprise a discharge risk indicator. [00143] Optionally, the discharge risk indicator includes a numerical value indicative of the discharge risk level of a patient based on their component risk score. [00144] Optionally, the discharge risk indicator is updated in real time, as updated values of the component risk score are determined. [00145] Optionally, the numerical value is a rolling average. [00146] Optionally, the discharge risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same. [00147] Optionally, the discharge risk trend indicator is colour coded. [00148] Optionally, the one or more patient identifiers further comprises a display of one or more physiological parameters associated with the patient, wherein the selection and arrangement of the one or more physiological parameters is based on their contribution to the component risk score. [00149] Optionally, the display of the one or more physiological parameters is updated in real time. [00150] Optionally, the display of the one or more physiological parameters comprises a rolling average of the one or more physiological parameters. [00151] Optionally, the one or more patient identifiers each comprise one or more of the following elements: a patient identification number, a patient room number, a patient bed number, a patient name, and an indication of the time expired since a clinician last interacted with the patient. [00152] Optionally, the presence, size, and display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the component risk score. [00153] Optionally, the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score. [00154] Optionally, the second risk band is a higher risk band than the first risk band. [00155] Optionally, the estimated amount of time is provided by analyzing a trend in historical values of the component risk score. [00156] Optionally, the sensor data is received from respiratory support device comprising or in communication with the plurality of sensors. [00157] Optionally, the component risk score is a normalized component risk score. [00158] In a further aspect the present disclosure may broadly be said to consist in a method of patient management comprising: receiving, via a network, sensor data from a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients; determining a component risk score for each of the plurality of patients; assigning the plurality of patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and causing a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with a patient of the plurality of patients and their component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the relative value of their associated component risk score. [00159] Optionally, the sensor data is received over one or more advertising channels of a short-range wireless communication component. [00160] Optionally the component risk score may be calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below. [00161] Optionally, assigning the plurality of patients to a plurality of groups comprises re- assigning a patient from a first group having an associated risk band to a second group having a second associated risk band. [00162] Optionally, the method further comprises the step of generating an alert condition if the second associated risk band is associated with a higher clinical risk than the first risk band. [00163] Optionally, the alert condition triggers a notification to a hospital monitoring system. [00164] Optionally, the alert condition triggers a notification to a secondary display. [00165] Optionally, the secondary display is a portable computing device. Optionally the portable computing device is associated with a clinician responsible for the reassigned patient. [00166] Optionally, the component risk score corresponds to a clinical risk index. [00167] Optionally, the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level. [00168] Optionally, the component risk score is a normalized component risk score. [00169] In a further aspect the present disclosure may broadly be said to consist in a method of patient management comprising: receiving, via a network, sensor data from a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients; determining a component risk score for each of the plurality of patients; selecting patients from the plurality of patients based on an assigned user of the system, assigning the selected patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and causing a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with the selected patients. [00170] Optionally the component risk score may be calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below. [00171] Optionally, the one or more patient identifiers are arranged on the display screen based on the relative value of their associated component risk score. [00172] Optionally, assigning the plurality of patients to a plurality of groups comprises re- assigning a patient from a first group having an associated risk band to a second group having a second associated risk band. [00173] Optionally, the method further comprises the step of generating an alert condition if the second associated risk band is associated with a higher clinical risk than the first risk band. [00174] Optionally, the alert condition triggers a notification to the assigned user. [00175] Optionally, the alert condition triggers a notification to a secondary display of the assigned user. [00176] Optionally, selecting patients from the plurality of patients is further based on a location of the assigned user and/or the display. [00177] Optionally, the assigned user is a clinician. Optionally the selection of patients is based on the patients for which the assigned user is responsible. [00178] Optionally the method comprises assigning the selected patients to a plurality of groups based at least in part on the component risk score and a plurality of rules; and causing a second display to display a graphical user interface, in a second display mode, one or more patient identifiers, each patient identifier associated with the plurality of patients. [00179] Optionally, the component risk score is a normalized component risk score. [00180] In a further aspect the present disclosure may broadly be said to consist in a method of processing wireless sensor data at a server, the method comprising the steps of receiving sensor data from a plurality of wireless sensors; determining a device type associated with the received sensor data; retrieving and activating at least one handler for the received sensor data, the at least one handler comprising a driver configured to process the sensor data into parameterised data; and converting the received data into parameterised data. [00181] Optionally, the device type is determined by a characteristic of the received sensor data and/or a device ID encoded in the received sensor data. [00182] Optionally, the at least one handler corresponds to the determined device type. [00183] Optionally, the sensor data comprises a continuous stream of data packets. [00184] Optionally, the method further comprises the step of storing the parameterised data. [00185] Optionally, the parameterised data is stored as a time series [00186] Optionally, the method further comprises the step of determining an event based on the stored parameterised data. [00187] Optionally, the parameterised data is sensor independent, wherein measured data from multiple of the plurality of wireless sensors is interchangeable. [00188] Optionally, the sensor data from the plurality of wireless sensors are received from a wireless router, the wireless router forwarding the received data to the server. [00189] Optionally, the wireless router forwards the received data to the server in real time. [00190] Optionally, the sensor data are advertising packets of a short-range wireless sensor, optionally a Bluetooth™ wireless sensor. [00191] Optionally, the step of activating a handler comprises: determining if a handler exists for the received sensor data, and otherwise instantiating a handler for the received data. [00192] Optionally, the step of determining a handler comprises identifying one or more features of the structure of the sensor data. [00193] Optionally, the step of determining a handler comprises identifying one or more features of a portion of the sensor data. [00194] Optionally, the portion of the sensor data comprises an advertising portion. [00195] Optionally, identifying one or more features comprises comparing structure of the sensor data with a plurality of known structures. [00196] Optionally, the method further comprises the step of deactivating the handler if no additional sensor data are received within a time period. [00197] Optionally, the method further comprises the step of determining a patient associated with the device. [00198] Optionally, the method further comprises the step of determining an item of furniture associated with the device. [00199] Optionally, the furniture comprises one or more of a bed and a chair. [00200] Optionally, the method further comprises determining a patient associated with the furniture. Optionally, the method further comprises determining a location associated with the furniture. Optionally, determining the location comprises reading detecting a locator associated with a known location. Optionally, the locator comprises an RFID device. Optionally the location comprises an area within a hospital ward. Optionally the wireless router comprises a sensor for sensing the locator. Optionally the sensor is an RFID reader. Optionally the locator has a limited range. Optionally the sensor comprises an under-mattress sensor. Optionally the sensor comprises an under-cushion sensor. Optionally the sensors are non-contact sensors for respiratory rate and/or heart rate. [00201] Optionally, the method further comprises determining a clinician associated with the at least one of the device, location and/or furniture. Optionally, the method further comprises updating the clinician, location associated with the device. [00202] Optionally the method further comprises associating the wireless router with the furniture. [00203] Optionally, the method further comprises the step of associating the parameterised data with the determined patient. [00204] Optionally, wherein the received sensor data are associated with a time-stamp. [00205] Optionally, the received sensor data are associated with a time-stamp at the router or at the server. [00206] Optionally, each data packet of the received sensor data is associated with a timestamp. [00207] Optionally, wherein the method further comprises the step of associating a time- stamp to the received sensor data. [00208] Optionally, each of the handlers is operated in a container, wherein a plurality of containers are generated to handle the sensor data from the plurality of wireless sensors. [00209] Optionally, wherein the method further comprises a controller, the controller configured to monitor the handlers and received sensor data and adjust the available processing resource. [00210] Optionally, the received sensor data are stored in a cache (bus) before the step of determining the device type, the storage allowing capacity of the processing to be allocated. [00211] Optionally, the database is a time-series database. [00212] Optionally, the method further comprises obtaining a trust rating for each of the plurality if wireless sensors. [00213] Optionally, obtaining the trust rating comprises any one or more of: determining a trust rating from the sensor data, obtaining the trust rating from the handler and obtaining the trust rating from the server. Optionally, the method further comprises selecting between readings from the plurality of wireless sensors based on the trust rating. [00214] Optionally, the method further comprises comparing sensor data from a plurality of sensors. Optionally, the method further comprises calibrating a sensor with a lower trust rating based on a sensor with a higher trust rating. Optionally, the method further comprises determining an accuracy bound for the sensor based on the trust rating. [00215] Optionally the method comprises calculating a component risk score based on the parameterized data. Optionally the component risk score is calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below. [00216] In a further aspect the present disclosure may broadly be said to consist in a method of processing wireless sensor data at a server, the method comprising the steps of: receiving at least one sensor data from a first sensor of a plurality of wireless sensors; identifying a first patient associated with the at least one sensor data; deriving a first parameter from the at least one sensor data; and adding the first parameter from the at least one sensor data to a time- series record in a medical record of the first patient. [00217] Optionally, the method further comprises the steps of: receiving at least one sensor data from a second sensor of the plurality of wireless sensors; identifying a second patient associated with the at least one sensor data; deriving a second parameter from the at least one sensor data; and adding the second parameter from the at least one sensor data to a time- series record in a medical record the second patient. [00218] Optionally, the first and second patient are the same patient. [00219] Optionally, the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a heart rate sensor, an SpO2 sensor and a temperature sensor. [00220] Optionally, the server receives the at least one sensor data in real time. [00221] Optionally, identifying a first patient comprises the steps of identifying an item of furniture associated with the at least one sensor data and identifying a patient associated with the furniture. Optionally, the furniture is a bed or a chair. [00222] In a further aspect the present disclosure may broadly be said to consist in a method of collecting data from a plurality of wireless sensors, the method comprising the steps of: associating each of the plurality of wireless sensors with a patient, receiving at a server a sensor data from one of the plurality of wireless sensors, identifying the patient associated with the sensor data, processing the sensor data to identify at least one parameterised data, associating the at least one parameterised data with the patient. [00223] Optionally, the patient is associated with the sensor by scanning technology. [00224] Optionally, the method further comprises the step of storing the parameterised data in an electronic medical record of the patient, wherein the electronic measurement record comprises a time-series database. [00225] Optionally, the sensor data is received in real time. [00226] Optionally, the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a heart rate sensor, an SpO2 sensor, and a temperature sensor. [00227] Optionally, identifying the patient comprises the steps of identifying an item of furniture associated with the at least one sensor data and identifying the patient associated with the furniture. Optionally, the furniture is a bed or a chair. [00228] Optionally the component method may use the system as outlined above or below and/or include any of the method steps outlined above and/or below. [00229] In a further aspect the present disclosure may broadly be said to consist in a method of processing wireless sensor data at a server, the method comprising the steps of: receiving a sensor data from one of a plurality of wireless sensors; determining a device characteristic of the received data; processing the received data into parameterised data based on the device characteristic; and storing the parameterised data. [00230] Optionally, the method further comprises the steps of determining a patient ID associated with the received data, and associating the parameterised data with the patient ID. Optionally, determining the patient ID comprises determining a bed ID or a chair ID associated with the wireless sensor data and determining the patient ID associated with the bed ID or chair ID. [00231] Optionally, one of the plurality of wireless sensors comprises one or more of a temperature sensor, a respiratory rate sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor. [00232] Optionally, the device characteristic is the type of sensor, or the manufacturer of a sensor. [00233] Optionally, the method further comprises the step of determining a driver for interpreting the sensor data. [00234] Optionally, the driver is determined based on the device characteristic. [00235] Optionally, the sensor data is from a short-range wireless communication, and the server receives the sensor data over a long-range wireless communication. [00236] Optionally, the short-range wireless communication is Bluetooth™ and/or the long- range wireless communication is TCP/IP. [00237] Optionally, the method further comprises temporarily storing of received sensor data before determining the device characteristic. [00238] Optionally, the method further comprises temporarily storing of processed data before storing the parameterised data. [00239] Optionally, the temporary storage comprises a bus or cache. [00240] Optionally, the sensor data is received in real time. [00241] Optionally, the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor. [00242] Optionally the method comprises calculating a component risk score based on the parameterized data. Optionally the component risk score is calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below. [00243] In a further aspect the present disclosure may broadly be said to consist in a processing system for processing measurements from a plurality of sensors to an electronic patient record having an associated patient ID, the processing system comprising: a processing server in data communications with a hub operable to receive transmissions from the plurality of sensors, and one or more databases for storing a plurality of electronic patient records therein; wherein the processing system is operable to: receive, through the hub, a sensor data from one of the plurality of sensors, identify the sensor that transmitted the sensor data, identify the patient ID associated with the sensor, determine at least one parameterised data from the sensor data, and store the parameterised data to at least one of the electronic patient records. [00244] Optionally, the system further comprises a medical device for providing therapy to a patient associated with the patient ID, wherein the processing system is further configured to: receive, through the hub, one or more therapy parameters from the medical device, identify the patient ID associated with the medical device and/or the therapy parameters, and store the received therapy parameters to at least one of the electronic patient records. [00245] Optionally, the therapy parameters comprise one or more of flow rate, humidity and O2 fraction of a flow of gases for delivery to the patient. [00246] Optionally, the plurality of sensors comprises wearable sensors mountable to the patient. [00247] Optionally, the server receives the sensor data from the hub in real time. [00248] Optionally, the plurality of sensors comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor. [00249] Optionally, the hub is associated with, attached or attachable to an item of furniture. Optionally, the furniture comprises one or more of a bed and a chair. Optionally the processing system is operable to identify the patient ID by determining a patient ID associated with the furniture. Optionally the hub comprises a sensor for sensing the locator. Optionally the sensor is an RFID reader. Optionally the sensor has a limited range. [00250] Optionally the sensor comprises an under-mattress sensor. Optionally the sensor comprises an under-cushion sensor. Optionally the sensors are non-contact sensors for respiratory rate and/or heart rate. Optionally the hub receives the transmission data from the plurality on an advertising channel. [00251] Optionally the method comprises calculating a component risk score based on the parameterized data. Optionally the component risk score is calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below. [00252] In a further aspect the present disclosure may broadly be said to consist in a system for processing patient measurements comprising: a plurality of wireless sensors; one or more databases for storing a plurality of electronic patient records therein, each patient record associated with a patient ID; a hub configured to receive wireless transmissions from the plurality of wireless sensors; and a processing server operable to: receive, through the hub, a wireless transmission from one of the plurality of wireless sensors, identify the sensor that transmitted the wireless transmission, identify the patient ID associated with the sensor, determine at least one parameterised data from the wireless transmission, and store the parameterised data to at least one of the electronic patient records. [00253] Optionally, the system further comprises a medical device for providing therapy to patient associated with the patient ID, wherein the hub is further configured to: receive one or more therapy parameters from the medical device, and the processing server is further operable to: identify the patient ID associated with the medical device and/or the therapy parameters and store the received therapy parameters to at least one of the electronic patient records. [00254] Optionally, the therapy parameters comprise one or more of flow rate, humidity and O2 fraction of a flow of gases for delivery to the patient. [00255] Optionally, the processing server is further operable to: retrieve and activate at least one handler, the at least one handler comprising a driver configured to process the wireless transmission into the at least one parameterised data. [00256] Optionally, the at least one handler corresponds to the sensor that transmitted the wireless transmission. [00257] Optionally, the sensor that transmitted the wireless transmission is identified by a characteristic of the wireless transmission and/or a device ID encoded in the wireless transmission. [00258] Optionally, the wireless transmission comprises a continuous stream of data packets. [00259] Optionally, the parameterised data is stored as a time series. [00260] Optionally, the processing server is further operable to determine an event based on the parameterised data. [00261] Optionally, the hub forwards the wireless transmission to the server in real time. [00262] Optionally, the wireless transmissions are advertising packets of a short-range wireless sensor, optionally a Bluetooth™ wireless sensor. [00263] Optionally, the processing server receives the sensor data from the hub in real time. [00264] Optionally, the plurality of wireless sensors comprises one or more of a respiratory rate sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor. [00265] Optionally, the processing server is further operable to: determine if a handler exists for the received wireless transmission, and otherwise instantiate a handler for the received wireless transmission. [00266] Optionally, the processing server is further operable to: identify one or more features of the structure of the received wireless transmission. [00267] Optionally, the processing server is further operable to: identify one or more features of a portion of the received wireless transmission. [00268] Optionally, the portion of received wireless transmission comprises an advertising portion. [00269] Optionally, the processing server is further operable to: compare the structure of the received wireless transmission with a plurality of known structures. [00270] Optionally, the processing server is further operable to: deactivate the handler if no additional wireless transmissions are received within a time period. [00271] Optionally, the hub is associated with, attached or attachable to an item of furniture. Optionally, the furniture comprises one or more of a bed and a chair. Optionally the processing system is operable to identify the patient ID by determining a patient ID associated with the item of furniture. Optionally the item of furniture has a furniture ID. Optionally the hub comprises a sensor for sensing the locator. Optionally the sensor is an RFID reader. Optionally the sensor has a limited range. [00272] Optionally the plurality of sensors comprises an under-mattress sensor. Optionally the sensor comprises an under-cushion sensor. Optionally the sensors are non-contact sensors for respiratory rate and/or heart rate. Optionally the hub receives the transmission data from the plurality on an advertising channel. [00273] In a further aspect the present disclosure may broadly be said to consist in a wireless sensor configured to transmit on at least one advertising channel or a wireless communication system, the wireless communication system comprising: a first frequency bandwidth advertising channel; and a second frequency bandwidth data channel, wherein the wireless sensor is configured to sense a value and broadcast the sensed value on the at least one advertising channel. [00274] Optionally, the system further comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, an SpO2 sensor, a carbon dioxide sensor and a blood pressure sensor. [00275] In a further aspect the present disclosure may broadly be said to consist in a method of transmitting sensor measurements from a wireless sensor having at least one advertising channel or mode and at least one data channel or mode, the method comprising transmitting the sensed measurements on the at least one advertising channel or mode. [00276] Optionally, the method further comprises the step of encrypting the sensed measurements, optionally with a ChaCha encoding or a Diffie-Hellman Encoding. [00277] Optionally, the sensed measurements are transmitted as part of an advertising packet, the advertising packet comprises a sensed measurement and a device identification portion. [00278] Optionally, the sensed measurements are transmitted as a continuous stream of data packets. [00279] Optionally the method comprises calculating a component risk score based on the parameterized data. Optionally the component risk score is calculated by any one or more of the method steps outlined above or below and/or the system may be used as outlined above or below. [00280] In a further aspect the present disclosure may broadly be said to consist in a system for processing patient measurements comprising: a plurality of wireless sensors having at least one advertising channel or mode and at least one data channel or mode, wherein the wireless sensors are configured to transmit sensor data on the at least one advertising channel or mode; a hub configured to receive the sensor data from the plurality of wireless sensors over the at least one advertising channel or mode; and a processing server operable to: receive, through the hub, the sensor data from one of the plurality of wireless sensors, identify the sensor that transmitted the sensor data, determine at least one parameterised data from the sensor, and store the parameterised data. [00281] Optionally, any of the systems and/or methods set out above further comprise the step of: displaying the parameterised data on a display screen in a first view, wherein the parameterised data is displayed along with a corresponding patient identifier. [00282] Optionally, the patient identifier comprises any one or more of a patient name, a patient ID, a location identifier, and a bed identifier. [00283] Optionally, two or more patient identifiers and associated parameterised data are displayed in the first view. [00284] Optionally, the patient identifiers displayed are dependent on one or more of: a registered user of the display, a location of the display and or a registered location of the display. Optionally, the registered location of the display comprises a room or ward of a hospital. [00285] Optionally, on selection of a patient identifier, a second view is displayed on the display screen, the second view comprising current and historical values of the parameterised data for the corresponding patient displayed as a time series. [00286] Optionally, the second view further includes a component risk score indicator characterising the patient’s risk of deterioration based on at least a portion of the available parameterised data. [00287] Optionally the component risk score corresponds to a clinical risk index and/or an early warning score. [00288] Optionally, the component risk score indicator is provided in the form of a gauge, wherein the gauge is sectioned according to thresholds in the corresponding parameterised data. [00289] Optionally, the thresholds correspond to integer values of the component risk score. [00290] Optionally, any of the systems set out above further comprise a display system configured to display the parameterised data on a display screen in a first view, wherein the parameterised data is displayed along with a corresponding patient identifier. [00291] Optionally, the patient identifier comprises any one or more of a patient name, a patient ID, a location identifier and a bed identifier. [00292] Optionally, two or more patient identifiers and associated parameterised data are displayed in the first view. [00293] Optionally, the system is configured to receive a selection of a patient identifier, and on detection of the selection, display a second view on the display screen, the second view comprising current and historical values of the parameterised data for the corresponding patient displayed as a time series. [00294] Optionally, the display screen is configured to display as part of the second view a component risk score indicator characterising the patient’s risk of deterioration based on at least a portion of the available parameterised data. [00295] Optionally, the component risk score indicator indicates the value of one or more parameterised data relative one or more thresholds. [00296] Optionally, the one or more thresholds are customizable by a user or clinician. [00297] Optionally, depending on the value of the one or more parameterised data relative to one or more thresholds, an alarm condition is set. [00298] Optionally, the component risk score indicator is provided in the form of a gauge, wherein the gauge is sectioned according to thresholds in the corresponding parameterised data. [00299] Optionally, the thresholds correspond to integer values of the component risk score. [00300] Optionally, the component risk score is a normalized component risk score. [00301] In a further aspect the present disclosure may broadly be said to consist in an electronic device comprising: a touch-sensitive display; one or more processors; memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for carrying out the steps of any of the methods set out above. [00302] In a further aspect the present disclosure may broadly be said to consist in a bed comprising a hub operable to receive transmissions from a plurality of sensors associated with the bed and/or a patient associated with the bed, the hub configured to send measurements from the plurality of sensors to a processing system. [00303] Optionally, the hub forwards the raw sensor data to the processing system. Optionally the hub comprises a location sensor configured to sense the location of the bed. Optionally the location sensor comprises an RFID reader configured to read an RFID sensor. [00304] Optionally, the bed is a hospital bed. [00305] Optionally, the processing system is configured to process the measurements to an electronic patient record. Optionally the processing system comprising: a processing server in data communications with a and one or more databases for storing a plurality of electronic patient records therein; wherein the processing system is operable to: receive, through the hub, identify the sensor that transmitted the sensor data, identify the patient ID associated with the sensor, determine at least one parameterised data from the sensor data, and store the parameterised data to at least one of the electronic patient records. [00306] Optionally, the bed comprises one or more sensors. [00307] Optionally, the one or more sensors comprise a non-contact sensor to sense physiological parameters. [00308] Optionally, the one or more sensors comprise an under mattress sensor configured to sense physiological parameters. [00309] Optionally, the physiological parameters comprise any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level. [00310] Optionally the patient parameters comprise respiratory rate and heart rate. [00311] In a further aspect the present disclosure may broadly be said to consist in a patient monitoring system comprising: a data management server in communication with a hub, the hub wirelessly coupled to plurality of sensors configured to measure one or more physiological parameters of a plurality of patients, the data management server configured to: receive, via the hub, sensor data from the plurality of sensors; wherein at least one of the plurality of sensors comprises at least one non-contact sensor configured to measure at least one of respiratory rate and heart rate, and wherein the hub is configured to transmit the sensor data to the data management server and the data management server is configured to convert the received sensor data into parameterised data. [00312] Optionally one or more of the plurality of sensors are associated with and/or coupled to an item of furniture. Optionally wherein the item of furniture is a bed or a chair. Optionally wherein the item of furniture is associated with a patient a. Optionally using a patient ID. [00313] Optionally the one or more sensors comprise an under mattress sensor. [00314] Optionally, the patient management system is for use in one or more of a hospital, or a home environment. Optionally, wherein the patient management system is for use in an intensive care unit of a hospital. [00315] Optionally the system is configured to allow connection of one or more further sensors to the hub and the data management server. [00316] Optionally the data management system is configured to calculate a component risk score based, at least in part, on the parameterised data. [00317] Optionally the one or more sensors comprise any one or more of a respiratory rate sensor and a heart rate sensor. [00318] Optionally the one or more sensors comprise a plurality of types of sensors, each type of sensor configured to sense a different physiological parameter. [00319] Optionally the sensors comprise sensors any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level. [00320] Optionally the component method may use the system as outlined above or below and/or include any of the method steps outlined above and/or below. [00321] Features from one or more aspects or configurations may be combined with features of one or more other aspects or configurations. [00322] As used herein the term “(s)” following a noun means the plural and/or singular form of that noun. [00323] As used herein the term “and/or” means “and” or “or”, or where the context allows both. [00324] The term “comprising” as used in this specification means “consisting at least in part of”. When interpreting each statement in this specification that includes the term “comprising”, features other than that or those prefaced by the term may also be present. Related terms such as “comprise” and “comprises” are to be interpreted in the same manner. [00325] It is intended that reference to a range of numbers disclosed herein (for example, 1 to 10) also incorporates reference to all rational numbers within that range (for example, 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9 and 10) and also any range of rational numbers within that range (for example, 2 to 8, 1.5 to 5.5 and 3.1 to 4.7) and, therefore, all sub-ranges of all ranges expressly disclosed herein are hereby expressly disclosed. These are only examples of what is specifically intended and all possible combinations of numerical values between the lowest value and the highest value enumerated are to be considered to be expressly stated in this application in a similar manner. [00326] This disclosure may also be said broadly to consist in the parts, elements and features referred to or indicated in the specification of the application, individually or collectively, and any or all combinations of any two or more said parts, elements or features. [00327] Where specific integers are mentioned herein which have known equivalents in the art to which this disclosure relates, such known equivalents are deemed to be incorporated herein as if individually set forth. [00328] The disclosure consists in the foregoing and also envisages constructions of which the following gives examples only. BRIEF DESCRIPTION OF THE DRAWINGS [00329] Specific aspects and modifications thereof will become apparent to those skilled in the art from the detailed description herein having reference to the figures that follow, of which: [00330] Figure 1 illustrates a patient monitoring system 10 in accordance with an aspect of the present disclosure. [00331] Figure 2 illustrates a bed locator system arranged in a room of a facility. [00332] Figure 3 illustrates a pre-processing server portion of the patient monitoring system 10 in accordance with an aspect of the present disclosure. [00333] Figure 4 illustrates a post-processing server portion of the patient monitoring system 10 in accordance with an aspect of the present disclosure. [00334] Figure 5 is a flow diagram illustrating a method performed at the router in accordance with an aspect of the present disclosure. [00335] Figure 6 is a flow diagram illustrating a method in accordance with an aspect of the present disclosure. [00336] Figure 7 is a flow diagram illustrating a method in accordance with an aspect of the present disclosure. [00337] Figure 8 is a flow diagram illustrating a data collection method in accordance with an aspect of the present disclosure. [00338] Figures 9 and 10 show elements of a graphical user interfaces provided on a screen of the display system. [00339] Figures 11 and 12 show an exemplary earning warning score matrix from the Adult Early Warning Scoring System in use in New Zealand from 2021. [00340] Figure 13 shows elements of a graphical user interfaces provided on a screen of the display system. [00341] Figure 14 shows a schematic of how a component risk score and a clinical risk index may be based on patient data. [00342] Figure 15 shows exemplary early warning score categories alongside their corresponding ranges of normalized clinical risk index. [00343] Figures 16 shows a patient view of monitored patient data and a component risk score. [00344] Figure 17 shows a patient view with multiple live patient data readings with component risk scores. [00345] Figure 18 shows live patient data across time periods. [00346] Figure 19 shows a radar plot of patient data at different times. [00347] Figure 20 shows a group view of a plurality of patients being monitored, each represented by a tile. [00348] Figure 21 shows an example tile from Figure 20. [00349] Figures 22 and 23 show sections of the group view, with tiles scaled for emphasis. [00350] Figure 24 shows a section of the group view where the display of tiles has been adjusted based on risk band. [00351] Figure 25 shows a group view of a plurality of patients being considered for discharge, each patient represented by a tile. DETAILED DESCRIPTION [00352] Although certain aspects and examples are disclosed herein, inventive subject matter extends beyond the specifically disclosed aspects to other alternative aspects and/or uses, and to modifications and equivalents thereof. Thus, the scope of the claims or aspects appended hereto is not limited by any of the particular aspects described herein. For example, in any method or process disclosed herein, the acts or operations of the method or process may be performed in any suitable sequence and are not necessarily limited to any particular disclosed sequence. Various operations may be described as multiple discrete operations in turn, in a manner that may be helpful in understanding certain aspects; however, the order of description should not be construed to imply that these operations are order dependent. Additionally, some structures described herein may be embodied as integrated components or as separate components. For purposes of comparing various aspects, certain aspects and advantages of these aspects are described. Not necessarily all such aspects or advantages are achieved by any particular aspect. Thus, for example, various aspects may be carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other aspects or advantages as may also be taught or suggested herein. [00353] It should be emphasized that many variations and modifications may be made to the aspects described herein, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims. Further, nothing in the foregoing disclosure is intended to imply that any particular component, characteristic or process step is necessary or essential. In some aspects process or method steps described herein are implemented by the disclosed systems. In some aspects systems described herein implement one or more of the methods and processes disclosed. OVERVIEW OF THE SYSTEM [00354] Figure 1 shows a system that provides for the monitoring of one or more patients in a hospital or home environment. The location of the patients may be referred to as a facility, covering either a hospital, medical location or a home. Aspects of the present present disclosure form at least part of the system. Briefly, the system provides for the collection of patient data from a plurality of sensors 20, and the subsequent transfer of that data to one or more processing servers 40 via an intermediary router and/or hub 30. The terms hub and router may be used interchangeably to refer, at least, to a device configured to receive wireless communications from sensors and transmit communications to a server. [00355] The sensors 20 may include patient worn sensors, sensors mounted to furniture 22, such as a patient bed 1 and/or contactless sensors. The sensors 20, 22 may be attached to, or part of, a therapy device 21. For example, the sensors may be attached to, or part of, a respiratory support device or a respiratory therapy device. For example the respiratory support device or therapy device may be a high flow therapy device (e.g. Airvo™ 2 or Airvo™ 3) or a respiratory humidifier or a THRIVE™ therapy device in anesthesia or sedation. The system may also communicate with a surgical humidifier or other gas delivery or gas conditioning device used in surgery or anesthetic procedures or sedation procedures. The sensors may comprise different types of sensors configured to measure different physiological parameters. In a particular aspect, the system is configured to monitor respiratory health of a patient, as this is often an indicator of other health issues/diseases. Further, respiratory distress or failure often triggers a patient being moved to critical care, which is resource intensive and can reduce the quality of patient outcomes as compared to early treatment of health issues/diseases. [00356] Conventional systems rely on self-reporting by patients, healthcare practitioners taking periodic vital sign measurements, and/or disparately collected sensor information. However, patients frequently do not realize their condition is deteriorating until after they need critical or elevated levels of care. Similarly, periodic vital sign measurements obtain only small snapshots of the patient’s condition and may not raise concerns until after a patient needs critical or elevated levels of care. Further, the disparate collection of information from sensors (e.g., blood pressure sensors, cardiac monitors, temperature sensors, respiratory monitors, and the like) can limit the availability of information from any one sensor (e.g., only available to a practitioner in the room) and/or provide an incomplete picture of a patient’s health (e.g., when a practitioner cannot see information from multiple sensors at once). [00357] In particular, conventional sensors all output in different formats for display on different devices local to the patient and/or in different user interfaces. Each device may have a proprietary format or communication protocol requiring independent monitoring and limiting the ability to combine measured data. Moreover, the number of sensors in a facility requires extensive collection and processing of potentially interfering signals. Each of these technical deficiencies can force healthcare practitioners to be responsive only to critical needs and reduce the quality of care a patient receives and/or negatively impact patient outcomes. For example, delaying care until critical or elevated levels of care are required can negatively impact a patient’s ability to recover from a health condition/disease. Further, elevated levels of care are resource intensive, diverting the attention of healthcare practitioners and/or available space in a healthcare facility away from other patients. In some cases, the system and/or method provide an open architecture which allows sensors to be easily added or removed. In some cases the system and/or method also allows hospitals to apply their own monitoring protocols and or customise the system protocols, monitoring protocols and/or output displays. The open architecture may allow custom monitoring protocols to be implemented in a straightforward and centralised manner. For example, because the raw sensor data is processed at the server only the server processing and/or handlers need to be adjusted or customised to change the system and/or method. [00358] In some cases, to overcome these technical deficiencies in conventional systems, the present systems and methods can help allow healthcare providers to detect early-stage deterioration of a patient’s respiratory health – thereby allowing for rapid and timely intervention by a supervising clinician. For example, the systems and methods disclosed herein can use the plurality of sensors 20 to monitor various vital signs (e.g., respiratory health, cardiological health, and/or the like) continuously (or almost continuously). The data from the plurality of sensors 20 can help detect, for example, respiratory deterioration early on (e.g., as soon as a change in respiratory health occurs), reducing (or eliminating) the need for self- reporting from patients and significantly supplementing periodic vital sign measurements. In turn, the early identification can allow a healthcare provider to begin treatment of respiratory distress/diseases significantly earlier, which can help avoid the need to elevate patients to critical (or other high levels) care. Thus, the systems and methods disclosed herein are expected to help improve patient outcomes and help reduce the resource demands associated with treating patients, thereby allowing healthcare providers to have more bandwidth and/or resources to treat other patients. [00359] Further, as discussed in more detail below, the disclosed systems and methods can enable data from the plurality of sensors 20 to be efficiently collected, stored, processed, and/or analyzed in a central location. For example, the systems and methods disclosed herein can use the plurality of sensors 20 to collect raw data relating to a patient and/or use the router 30 to collect the raw data from the plurality of sensors 20. More specifically, in some cases the plurality of sensors 20 and the router 30 can communicate using advertising channels of a short-range wireless communication protocol (e.g., Bluetooth™). Using the advertising channels to communicate the data allows any number of sensors to communicate with the router 30 without requiring a dedicated channel, a dedicated connection, and/or a specified data format. As a result, the systems and methods disclosed herein allow a larger number and/or a wider variety of sensors to communicate with the router 30. Additionally, or alternatively, the router 30 and each of the plurality of sensors 20 requires less energy since the router 30 and the plurality of sensors 20 do not have to maintain a constant connection to each other. In some cases, the use of the advertising signal or packet being used to transmit sensor data, optionally encoded, reduces power consumption and/or bandwidth consumption of the sensors and/or the hub. The means the sensors and/or hub uses less power or require smaller power sources to operate and makes the system easier to use as less charging is required. [00360] Additionally, or alternatively, additional sensors can be added ad hoc to customize the monitoring to a specific patient’s healthcare needs, without disrupting a network and/or requiring a network to be updated to accommodate the additional sensors. After the router 30 receives data from the plurality of sensors, the router 30 can forward the data to the processing server 40. In an aspect, the router 30 passes the raw data directly to the processing server 40 without caching performing any other process on or with the data. This allows the data to be forwarded (and ultimately displayed) in real time or near real time – proving a better resolution view of a patient’s health condition. The processing server 40 processes the raw sensor data to produce parameterised data which is subsequently stored and added to a patients electronic medical file and optionally displayed on a screen as part of patient monitor hardware either in a hospital or home environment. [00361] Accordingly, the systems and methods described herein are expected to reduce the resource requirements to accommodate the plurality of sensors 20. Further, in contrast to conventional systems, the systems and methods described herein allow data from a wide variety of sensors to be collected, processed, displayed, and/or analyzed in a central location. DETAILED DESCRIPTION OF COMPONENTS AND OPERATIONS OF THE SYSTEM [00362] The configuration and operation of aspects of the system will now be described in further detail. [00363] In an aspect, the plurality of sensors 20 are configured to monitor a patient and produce sensor data indicative of said patient’s status. The sensors may be referred to as health sensors as they measure patient physiological parameters indicative of a patient’s health. The parameters may be indicative of improving or deteriorating patient health. [00364] In one aspect, the plurality of sensors comprises one or more of a respiratory rate sensor, a temperature sensor, a heart rate sensor, and a SpO2 sensor provided in the form of one or more wearable sensors mountable to the patient – it being noted that respiratory distress is often a key indicator of deteriorating patient health. In a further aspect, the plurality of sensors 20 may include one or more sensors provided in or under an item of furniture. For example under the mattress of the patient’s hospital bed, or a chair. These sensors may be capable of determining one or more physiological parameter of the patient (such as respiratory rate and heart rate). For example a ballistocardiograph allows heart rate and/or respiratory rate to be measured without contact to a patient’s body. The skilled person would understand that any suitable sensor may be incorporated into the plurality of sensors 20 provided they operate as set out below. [00365] A benefit of using one or more sensors under the mattress of the patient’s bed is that it improves comfort for the patient, by avoiding the need to otherwise wear a sensor for the parameter to be measured. Moreover, a healthcare provider saves time by not needing to secure any corresponding sensor to the patient, and the risk of the healthcare provider forgetting to secure the sensor, or the sensor being accidentally detached/dislodged from the patient, is avoided. A sensor provided under the mattress may also be more sanitary and should not need replacement or cleaning between different patients occupying the bed. The non- contact sensor attached to the item of furniture also reduces movement of the sensor and measurement errors associated with poor attachment of the patient to the sensor. In some cases this also improves patient compliance because the sensor requires no patient input and is merely part of an item of furniture. This means the patient requires no attachment, or action to connect to a patient other than associating the patient with the bed, or bed location, for example. [00366] In conventional systems, inaccurate sensors can skew a healthcare provider’s interpretation of data, requiring a healthcare provider to take multiple measurements using the same sensor during a periodic vital sign measurement, or to rely on an inaccurate sensor. To overcome this deficiency in an aspect current technology, the plurality of sensors 20 may include more than one sensor that sense the same parameter, wherein the system 10 is configured to take an average value to determine a measured parameter or select data from a sensor having the highest quality data – e.g. the lowest noise signal. In another aspect the system 10 may prioritise measurements from selected and/or trusted sensors. The accuracy and reliability of sensors can vary greatly between, for example, manufacturers and models, even when the underlying techniques may be similar. In other cases different sensors 20 will provide more accurate results based on different techniques, tolerances or accuracy levels (e.g., an electrocardiogram will generally be more accurate than a pulse-oximeter). By prioritising sensors which are more accurate the performance of system 10 is improved due to more accurate data being available. [00367] In an aspect the system 10 obtains a rating (e.g., a rating of the sensor’s accuracy, or trust in the sensor’s value) of each sensor 20. The rating may be provided in the signal from the sensor 20 or may be obtained in the processing servers (e.g. by a handler of the sensor), or may be obtained from a database, for example. This rating system creates a hierarchy of sensors 20, depending on the sensors available and the rating of each sensor. The hierarchy ensures the most accurate information is used. The sensor having the highest score can then be used to determine the most accurate sensor value. Where multiple sensors are available the system 10 may also monitor the accuracy of the less accurate sensor. This monitoring may be used to adjust the less accurate sensor if or when the more accurate sensor is disconnected. For example, to account for an offset or to set accuracy bounds on the sensor data. In an aspect accuracy bounds (either determined in comparison to other sensors or provided to the system 10) may be interpreted by the system to decide when to trigger and alarm or set a risk band based on the sensor accuracy. [00368] In an aspect the system uses a distance to the wireless sensor, or a strength of a wireless sensor to determine if the sensor should be processed. This enables the system to ignore sensors located too far away, reducing processing loads. [00369] The plurality of sensors 20 are configured to transmit sensor data to the router 30. In an aspect, the sensor data is in the form of raw or otherwise unprocessed data from the sensors. In the case of one or more of the plurality of sensors 20 being analogue, the sensor data may be in the form of an analogue signal or alternatively a digital value representative of the analogue signal. [00370] As discussed above, in an aspect of the present technology, the data transmission from the plurality of sensors 20 to the router 30 is provided by a short-range wireless transmission, such as NFC (near field communication), RFID (radio frequency identification), ZigBee™ or any other suitable means. In the illustrated aspect the data transmission is performed via Bluetooth™ with the sensor data encoded into advertising data packets (e.g., suitable for an advertising channel in the short-range wireless protocol). The advertising data packets are typically used to handshake or agree a communication protocol between two devices, rather the present disclosure of transmitting sensor data. Accordingly, the sensor data can be read by the router 30 without requiring the router 30 to pair with each of the plurality of sensors 20. Accordingly, the router 30 does not need to maintain individual connections with each sensor in the plurality of sensors 20. This allows the system 10 to work with any type of sensor with minimal configuration, including sensors which may otherwise be incompatible and incapable of conventionally pairing with the router 30 or processing server 40. It further enables the system 10 to work with many more sensors than would otherwise be possible if the router 30 had to fully pair with each sensor in the plurality of sensors 20. In addition, individual sensors do not need to maintain a connection with the router 30, leading to improvements in battery life. [00371] The transmission of sensor data between the plurality of sensors 20 and router 30 may therefore be thought of as connectionless, allowing for sensors to be added to or removed from the system without any of the complexity associated with handshaking and handoff. In one aspect, the advertising packets contain a Bluetooth™ MAX address/UUID unique to each device/sensor along with a payload portion that includes the sensor data. In a further aspect this payload portion includes additional information, such as the make and model of the sensor device or other metadata. In some cases, only the advertising portion of the wireless connection is used, so as to reduce the time, bandwidth and/or processing required to transmit the sensor data. [00372] In a further aspect the wireless hub receives transmissions on at least one advertising channel. The wireless communication system of the wireless hub has a first frequency bandwidth configured to receive an advertising channel from a plurality of sensors and a second frequency bandwidth data channel configured to receive data, Data transmission typically begins after a handshake is performed on the advertising channel. However, the wireless hub may be configured to monitor the advertising channel and receive a sensed value on the at least one advertising channel. Receiving sensed values on the advertising channel reduces the time required to connect to devices and allows many more devices to be connected and sent to the server. The hub may decrypt the sensed readings, optionally with a ChaCha encoding or a Diffie-Hellman Encoding. The hub may determine, or forward to the server directly, a sensed measurement portion and a device identification portion of the data on the advertising channel. Optionally, the sensed measurements are transmitted as a continuous stream of data packets. [00373] In one aspect the sensor data is sent as a continuous stream of data. In another aspect, the sensor data is sent at fixed intervals. In an alternative aspect the sensor data is encoded and sent as soon as new and/or updated data has been generated by the sensor 20 such that bandwidth is not taken up transmitting an unchanged sensor reading. In a further aspect the transmission of sensor data is promoted by a pull notification from the router 30. In a preferred aspect, the transmission of sensor data is performed in real-time. In one aspect the sensor data is sent at an interval set by the individual sensors of the plurality of sensors 20, and unknown by the processing server 40 which is nevertheless capable of accepting a transmission of sensor data at any time. In a further aspect, the system 10 is optimized for data transmission at or below 1 Hz, though may be capable of handling higher frequency data e.g. at 10 Hz. [00374] In an aspect, the plurality of sensors 20 are programmed to operate using a data protocol/data specification such that sensor data is output as per a specified format for Bluetooth™. [00375] In an aspect, the router 30 comprises a controller, antenna and power source and is configured to receive sensor data from the plurality of sensors 20 and forward said data to the processing server 40. In one aspect, the sensor data is time stamped upon receipt and prior to transmission to the processing server 40. By receiving the sensor data in Bluetooth™ advertising data packets and passing the received data on to the server 40 for processing, the router 30 is capable of operating with a large number of sensors with minimal configuration and processing requirements. The advertising data packets may be received on a common advertising channel, or from a plurality of advertising channels. This may depend on the structure or protocol of the short-range wireless communication device used. The router 30 may format or otherwise process the data packet before forwarding it to the server 30. For example, the router 30 may add a time stamp, decode the signal and/or packing the signal with other incoming signals. [00376] The manner and mechanism of transmission to the router 30 from the plurality of sensors 20 and from the router 30 to the processing server 40 need not be the same, i.e. the router acts as a gateway. For example, in the illustrated aspect the router 30 exports the data received from the plurality of sensors 20 by IP communications protocol to the processing server 40. In an alternative aspect the router 30 exports the received sensor data via ethernet to a local server. [00377] In one aspect, the router 30 is provided by a Cassia™ X2000, X1000, E1000 Bluetooth™ enterprise Bluetooth™ router, or similar device. [00378] In the illustrated aspect, the processing server 40 comprises a dispatcher 60, one or more handlers 70, an internal storage 80, a time series database 90, a processor 100 and an event hander 110. [00379] In an aspect, the sensor data is time stamped on receipt at the processing server 40 and cached. This time stamping of the received sensor data by the processing server 40 enables the system 10 to handle an irregular real-time data stream without the need to perform interpolation or time averaging. Further, the server 40 is able to make use of a single central clock, synchronizing data received from across the plurality of sensors 20 and reducing temporal errors in the data. The time stamp on the received sensor data carries through and is applied to the parametrized data output by the processing server 40, providing a time series indicative of a patient’s status. The use of the cache allows for asynchronous receipt and processing of the received sensor data from the plurality of sensors 20 such that, for example, temporary bandwidth limitations affecting the transmission of sensor data from the router 30 need not halt the processing of data already received and cached at the processing server 40. [00380] The sensor data is then passed on to a dispatcher 60 which is configured to determine the source device and/or the device type (i.e. the type of sensor by which the sensor data was generated). In an aspect this determination is carried out by identifying one or more features of at least a portion of the received sensor data, such as a Bluetooth™ MAC address/UUID or Bluetooth™ class. In one aspect, the dispatcher 60 performs pattern matching on the sensor data packets received from each individual sensor. In an alternative aspect, the source device is identified via a device ID encoded into the sensor data generated by that particular device. In one aspect, the device identification is performed by the router 30 and the device ID is transmitted to the processing server 40 along with the sensor data. [00381] Following the identification of the source device, the dispatcher 60 retrieves a driver 71 and activates a corresponding handler 70. In the event that no handler 70 exists for sensor data from the identified source device, the dispatcher 60 is operable to instantiate a handler 70. In one aspect, the processing server 40 is able to retrieve handlers 70 and drivers 71 corresponding to any potential device ID from an external source that can be constantly updated/maintained as new sensors come become available. In a further aspect, the server 40 may comprise a library of definitions of various drivers. Additionally, the server 40 may build a driver based on prestored data types and/or the plurality of sensors 20 are programmed to send standard data structures/standard types of data. The server 40 may build a custom driver based on the received sensor data and the data library. [00382] The dispatcher 60 then forwards the sensor data to the activated handler 70 which comprises a driver 71 that operates to process the sensor data into parameterised data. The handler/driver architecture described above allows the processing server 40 to process sensor data from any conceivable brand, make and model of sensor, as well as adapt to operate with any new sensors added to the system after initial setup. Further, as sensor data is processed centrally by the processing server 40, there is no need to update the router or sensor software to adapt to changes in the system 10. [00383] In one aspect, parameterised data corresponds to one or more of one patient’s physiological parameters such as respiratory rate, temperature, carbon dioxide level, heart rate and SpO2. [00384] Once parameterised, the data is sensor independent, i.e. it has a value and a unit/dimensions according to the particular parameter – no factor relating to the particular brand or model of the originating sensor is required to interpret the parameterised data. In an aspect, the dispatcher 60 deactivates the handler 70 if no additional corresponding sensor data is received within a predetermined time period or as soon as the transmission of the sensor data is resolved. [00385] In one aspect, each handler 70 runs in an independent container 72 of the processing server 40, allowing for better resource control as well as parallel processing of sensor data from different individual sensor by different handlers 70. In an alternative aspect, each container 72 contains one or more handlers 70 up to a configurable limit. [00386] Additional handlers 70 and containers 72 can be instanced as sensor data is received from additional sensors of the plurality of sensors 20. [00387] In an aspect, the drivers 71 are accessed directly by the dispatcher 60 without the use of dedicated handlers 70. [00388] The parameterised data is cached and subsequently stored by the processing server 40 in storage 80. In the illustrated aspect, the parameterised data are stored as a time series in a dedicated database 90 where a time series is a sequence of timestamp and parameterised value pairs, and for each patient ID there is provided a separate time series for each physiological parameter of the parameterised data. The pre-storage cache allows for asynchronous processing of sensor data and storage of the produced parameterised data. [00389] The parameterised data is then added to the patient’s electronic medical record. The parameterised data is further passed to an event handler 110 which is capable of generating alerts and/or triggering action should the parameterised data fall below or exceed a predetermined threshold for a predetermined time period. The parameterized data being above or below the predetermined threshold may determine if the systems outputs, to a healthcare provider or a clinician or on a display, an indication of the parameterized data (or, for example a component risk score). This may ensure appropriate care is provided to the patient, or that an alarm or automated care is provided. [00390] In an aspect, the processing server 40 is also used to register the patient against each of the plurality of sensors 20 using a patient registration service 41 that onboards the patient and associates a device ID of each sensor in the plurality of sensors 20 against a patient ID of the patient. In an aspect, personal information of the patient is also stored, though separately from the patient ID – such that patient ID can be shared and/or looked up without breaching patient privacy. In an aspect, these device ID-patient ID pairs are stored in a database at the processing server 40. In an alternative aspect, the patient registration service 41 is hosted outside of the processing server 40, with the processing sever 40 having access to the database 45 in which patient IDs and device IDs are stored. [00391] In an alternative aspect, or in combination with the previous aspect, the processing server 40 is also used to register a hospital bed against each of the plurality of sensors 20 using a bed registration service that onboards the hospital bed and associates a device ID of each sensor in the plurality of sensors 20 against a bed ID of the bed. In an aspect, these device ID- bed ID pairs are stored in a database at the processing server 40. In an alternative aspect, the bed registration service is hosted outside of the processing server 40, with the processing sever 40 having access to the database 45 in which bed IDs and device IDs are stored. In an aspect this works in the bed registration service works in the same manner as the patient registration service described herein. Although beds are described the registration process could be associated with other hospital furniture, including chairs. [00392] Associating the sensors with a hospital bed may reduce the complexity of tracking within the system. In some facilities, such as hospitals the clinicians identify patients through the hospital bed and/or the location of the hospital bed in a particular room or ward. By associating the sensors with a hospital bed, the clinicians can be alerted directly to the location of the patient of interest when attention is required. [00393] In an aspect each bed may identify the bed’s location in the hospital. The identification process may comprise detecting a location marker associated with a location in the hospital. The location marker may be a short-range wireless device. In some cases, a passive short-range wireless device is used so as the location marker does not require power. For example, an RFID tag is a passive device which may be read by a hub. For example, each potential bed location may have an associated RFID tag. A router 30 on the bed may detect the RFID tag when in the bed location. This detection allows an association between the bed and the bed location to be determined by the system. A patient can then be associated with the bed. [00394] If the bed is moved about the hospital the location of the bed can automatically update the position of the bed, and therefore the patient. The location of the bed may also update other recorded data or associations. For example, the location may be associated with a clinician. If moving the bed to a new location changes the clinician (e.g., a nurse or doctor) the system may update the clinician responsible for the bed to the clinician of the new location. For example, if the bed is moved between wards the clinician in charge and/or the ward processes may be automatically updated. [00395] In an aspect the hospital beds have an onboarding process. The onboarding process may comprise associating a patient with the bed. The onboarding process may associate any sensors already linked to that patient with the bed. The onboarding process may associate any sensors already linked to the bed with the patient. Whether a sensor is linked to a bed or a patient may depend on the whether the sensor is attached and/or connected to the bed or the patient. For example, a sensor attached to the bed frame and/or mattress may be associated with the bed, while a sensor monitoring heartrate and attached to a patient’s body may be associated with the patient (who can then be associated with the bed). In some cases, the staff may choose to associate a sensor with the patient and/or the bed. In some cases, sensors may be associated with a location. In some cases, an onboarding process may also be used to associate sensors with the bed, separate to, or in conjunction with, the bed ID process. [00396] In at least one embodiment, when one of more sensor(s) is/are located on the patient bed, and not directly attached to the patient assigned to that bed, the system is configured to verify the presence of the patient in the bed before processing/accepting any data from the sensor(s). The presence of a patient may be detected by a pressure sensor, PIR sensor, and/or by detecting the presence of an RFID tag embedded in the patient’s ID bracelet. The RFID tag may be assigned to the bed and/or patient as part of the onboarding process. The bed sensors may comprise non-contact sensors to sense physiological parameters. For example an under mattress sensor may be used. The bed sensors may measure any one or more of respiratory rate, SpO2 (blood oxygen saturation), Supplementary oxygen, temperature, body temperature, heart rate and systolic blood pressure, Carbon Dioxide level. In some cases, such as where non- contact sensors are not available, cost prohibitive, or an alternative is desired, contact sensors may be used. For example a contact SpO2 sensor may be used. [00397] In an aspect the bed sensors comprise a respiratory rate sensor and a heart rate sensor. For example, a ballistocardiograph sensor may be used to measure both heart rate and respiratory rate without contacting the patient. The use of heart rate and respiratory rate typically provides an accurate component risk score, allowing the system to identify patients with potential risks quickly and without the need for contact sensors, as the patient simply needs to be on the bed and/or chair. The sensor data associated with the bed may be sent through the hub (which also may be associated with the bed) to the processing server. Advantageously the bed provides a central location for the hub, and allows the connection of further sensors as required, or as the patient’s condition develops. Optionally a haemoglobin composition sensor may be used to provide a further indication of patient health. Having the hub receive the data from a plurality of sensors over an advertising channel allows it to quickly and efficiently receive large amounts of data. The data can then be processed by a processing server and reported or display as described herein. [00398] In an aspect the respiratory rate and heart rate are sensed with one or more non- contact sensors. The sensor may be a single sensor sensing both respiratory rate and heart rate, or individual sensors may be used. Respiratory rate is an early stage indicator of patient health. As respiratory rate deviates from a normal range this is indicative of deterioration in respiratory health which is often a precursor to other more commonly diagnosed symptoms. For example if the patient has influenza, the respiratory rate and heart rate increase beyond normal (i.e. the resting respiratory rate and heart rate are higher than normal range) before any fever or runny nose of cough develops. Therefore respiratory rate and heart rate change can be a good indicator patient needs some intervention and providing this in a non-contact sensing method attached to an item of furniture ensures that the potential condition is caught quickly and early, allowing reporting to a clinician and improving patient outcomes, for example by initiating high flow therapy. Under mattress sensing also reduces the chances of human error or missed signals, as it is automatic once the presence of a patient is detected and provides an objective measure. Using objective measures ensures a complete monitoring of all patient, including where health deterioration is not obvious to a clinician. [00399] Associating the sensors with the hospital bed may also simplify the attachment of hardware. For example, the hospital bed typically has a power source to which the router 30 may be connected. Similarly, the hospital bed may have sensors mounted to it. Where permanently mounted, or substantially permanently mounted the sensors may be permanently associated with the bed, to avoid incorrect reporting. Because the router 30 may be mounted directly to the bed it can easily be maintained or updated when the bed is not in use. [00400] In an aspect, personal information of the patient is also stored, though separately from the bed ID – such that patient information can be shared and/or looked up without breaching patient privacy. [00401] Figure 2 shows six hospital beds (labelled 1 to 6) in a room, such as in a hospital ward. A locator 8, such as an RFID tag is positioned behind each bed. Each bed comprises or is attached to a router 30, which may be secured, for example, to a frame of the bed. The router 30 may be beneath the bed, or attached to the head of the bed, or otherwise connected. The hospital beds may be moveable. For example, they may be on wheels so as patients may be moved about the facility on the beds. When each bed is moved into position, or at other times, the locator 8 and the router 30 communicate to determine the position of the bed. For example, if bed 1 is moved into position it communicates with the locator 8 next to it to confirm its position in the room, or facility. The communication is optionally wireless, such as where the locator system 8 is an RFID device read by the router 30, although wired or other physical connections may be used. [00402] In some cases, the communication has a limited range. A limited range may avoid interference or confusion between neighboring beds. For example, the communication may have a transmission distance of less than 2 meters, less than 1 meter or less than 0.5 meters. In some cases, the routers 30 of neighboring beds, or beds in the same room or ward may interact to determine relative positions of the beds in the room. This may be advantageous where a locator 8 is not present or is not operational. For example, the router 30 on bed 2 may obtain a measurement distance of bed 1 and bed 4 and triangulate a position based on these (or further readings). The measurement distance could be calculated by the signal strength, or angle of arrival. In some cases, the routers 30 may have a GPS or other location sensor configured to determine their location and reference a map of the hospital or building to determine their location. Other locators 8 are possible, for example a geofence, Bluetooth™, or reference point(s) could be organized in each room or location. [00403] Figure 3 depicts an aspect in which in addition to receiving sensor data from the plurality of sensors 20, the router 30 is also configured to receive data regarding the therapy being provided to the patient by one or more medical device 200. In an aspect, a medical device 200 is a respiratory therapy device or a respiratory support device. In one aspect, the respiratory therapy device can provide respiratory therapy or support and may be a high flow therapy device or a ventilator, or humidifier configured to provide one or more of. The respiratory device may be a respiratory humidifier that may condition gases from a ventilator prior the providing gases to a patient. CPAP (Continuous positive airway pressure), NHF (Nasal High Flow) or Bilevel therapy. The respiratory therapy/support device may be a multi-mode therapy device configured to provide both high flow therapy and Bilevel therapy. The respiratory device has a flow generator, humidifier, tube and a patient interface. The respiratory therapy device has sensors to record various therapy parameters such as flow, pressure, temperature, humidity. The device may also transmit usage information and/or data measured by onboard sensors such as SpO2, respiratory rate and heart rate measured either directly or indirectly via other physiological parameters or indicators monitored by the medical device 200 itself. In an aspect, one or more of the plurality of sensors 20 are provided as part of the medical device 200. The skilled person would appreciate that the presently disclosed data processing methodology is independent to and agnostic of the exact and particular nature of medical device 200 provided it functions as described below. In an aspect, the one or more medical device 200 includes a Bluetooth™ communications module capable of connecting to the processing server 40 via the router 30. In one aspect, the router 30 is able to identify the type, manufacturer and/or model of the medical device 200 by the transmitted therapy data. In one aspect, the router 30 identifies the medical device 200 by the structure of the therapy data. In an alternative aspect a device ID of the medical device 200 is encoded into the therapy data itself. [00404] In an aspect, the sensors may comprise a haemoglobin composition sensor and an under the mattress sensor. The under the mattress sensor may sense respiratory rate and/or heart rate. In combination these two sensors can provide an early indication of patient health deterioration. [00405] In an aspect, the therapy data is formed of one or more parameters relating to a flow rate, humidity level, dew point, usage time, pressure rate or pressure deliver, or O2 fraction of a flow of gases for delivery to the patient, or any other suitable or desired data. In an aspect, said therapy data is broadcast to the router 30, where it is time stamped before delivery to the processing server 40. In an aspect the therapy date may be set by a clinician may be broadcast. In an alternative aspect the therapy data is time stamped on receipt at the processing server 40. In one aspect, the therapy data is encoded within the advertising data packets of a Bluetooth™ transmission for collection by the router 30, which subsequently transmits the therapy data to the processing server 40 by IP protocol. In an aspect the therapy device is configured to transmit therapy data to the hub via the advertising packet. The therapy device may include a short-range wireless interface, such as a Bluetooth™ interface. The therapy device may incorporate the therapy data into the advertising packet transmitted by the therapy device. [00406] The processing server 40 is operational to process the received therapy data in the same manner as the received sensor data described above, namely by activating a handler 70 corresponding to the identified medical device, or by creating a handler 70 if one does not already exist with the appropriate driver 71. This allows for new medical devices to be added to the system without the need to reprogram the component parts of the system to account for the change in hardware – rather the processing server need only access and/or create a handler 70 and driver 71 corresponding to the new medical device. Equally, one or more medical devices 200 can be removed from the system, and their corresponding handlers can be retired or otherwise deactivated such that the processing server 40 continues to function efficiently. [00407] This therapy data is then able to be added to the patient’s electronic medical file as a time series along with the corresponding processed sensor data relating to the patient’s physiological parameters, providing a comprehensive and continuous treatment history alongside the corresponding physiological parameters of the patient. [00408] This temporal pairing of the parameterised data describing a patient’s condition along with the therapy parameters describing the treatment conditions existing at the time the sensor data is generated provides the reader of the electronic medical record with a measure of both the efficacy of the applied therapy and a measure of the patient’s compliance to one prescribed therapy regime. In one aspect this efficacy and compliance data is parameterised and stored alongside the corresponding therapy parameters and the physiological parameters of the patient. [00409] Figure 4 depicts a portion of the system 10 that receives the parameterised data from the processing server 40. As shown, the parameterised data can be forwarded to a sensor data engine 300 which may otherwise be referred to as a data processing engine or patient data management engine. This may either be a part of the system 10 of external to the system 10. The sensor data engine 300 can update a copy of the patient’s electronic medical records, pass to a data analytics engine or prediction engine (once stripped of any personal information relating to the patient, if present) for assessment and predictive/trend analysis, generate patient specific alerts or notifications, and/or automatically populate patients forms and records as required. In one aspect, the parameterised data is sent to a display system 310 present in either a hospital environment or a home treatment environment to visually display the parameterised data. [00410] Figure 5 shows a process performed by the router 30. At step S110 the router scans radio bands for any transmissions. At step S120, a determination is made as whether any transmissions are incoming, such a transmission of sensor data from one or more of the plurality of sensors 20. In an aspect, the router 30 is configured to scan for any known sensors registered against the patient. In a further aspect, the router 30 is able to discover newly added sensors at this stage. Once transmissions are detected, the router 30 checks for an active connection to the processing sever 40 at step S130. If no connection is available, the router 30 continues to scan for and cache sensor data locally. Once a connection is active, the router 30 relays the sensor data transmissions to the processing server 40. [00411] Figure 6 shows a process performed at the dispatcher 60 of the processing server 40. At step S210 the transmission related from the router 30 is received. In an aspect, the transmission is relayed directly to the dispatcher 60. In an alternative aspect, transmissions from the router 30 are cached and fed to the dispatcher 60 depending on available processing resources. At step S220, the dispatcher 60 identifies the device that generated the received sensor data and performs a check for an active handler 70 corresponding to the identified device. If a corresponding handler 70 is located, the sensor data is forwarded to the handler 70. Alternatively, in the event that no active handler 70 is found, the dispatcher 60 determines if the identified device is compatible with the system 10. If an incompatibility is detected, the device information is logged, and no further action is taken. If on the other hand the device is considered compatible, the dispatcher 60 creates a handler instance with the correct driver 71 for the identified device at step S240. [00412] Figure 7 shows a further process performed at the dispatcher 60 of the processing server 40. Following receipt of sensor data from the plurality of sensors 20 via the router 30 and identification of the specific device or device type that generated the sensor data, a handler 70 is instanced with the correct driver 71 at step S310. At step S320, a patient registration service 41 and the associated database 45 are contacted to discover if the determined device ID is linked to a patient ID. If the device is not assigned to a patient ID, the device ID is associated with the patient ID registered to the router 30 by which the sensor data was relayed. If the device ID is discovered to be linked to a patient ID other than that registered to the router 30, the device ID is re-assigned. At step S330, a counter initiates to wait for a predetermined length of time during which sensor data is expected to be received. If no sensor data is relayed from the router 30 during this time, a timeout counter is initiated and incremented. When a timeout condition is reached before any sensor data is received, the handler instance self- terminates at step S370. In one aspect, the handler will terminate immediately after processing a transmission of sensor data such that system resources are not committed to idly waiting for a transmission. On receipt of sensor data, the timeout counter is reset at step S340, followed by the creation of a time stamp corresponding to the time of reception at step S350. At step S360 the transmitted sensor data is parsed by the driver. If the data is found to contain monitoring information relating to the patient, such as respiratory rate, heat rate and SpO2 data then the parameterised data, patient ID, device ID and timestamp are cached ready to be added to the database 90 and the process returns to step S330 to await further sensor data. If no monitoring information is contained in the sensor data the handler 70 returns to step S330. In an aspect the handler 70 is able to take corrective action in accordance with the driver 71, for example attempting to switch to another driver 71 if available. In the event that the sensor data cannot be comprehended by the handler 70, an error condition is logged at the progresses to step S370 and self-terminates. [00413] In an aspect this process may be adapted for use with a bed ID. The bed registration service may be contacted at or before S320 to determine if the device ID is associated to a bed IR and/or a patient ID. The system may then check if the bed ID is associated with a patient ID. In this, or by another process the device ID is linked to a patient ID through the bed ID. [00414] Figure 8 shows a process performed at the database 90 of the processing server 40 that stores the parameterised data as a time series. At step S410, the database 90 receives either new parameterised data output by the handler 70 or a request for patient data already stored in the database 90. In the former case, a check is made at step S430 to determine if a time series exists in the database 90 for the sensor, parameter and/or patient that is the subject of the request. If a series does exist, the newly received data is appended to the existing series. Alternatively, a new series is created and the new data is added as the first entry. [00415] In the event of a request for patient data, a check is performed at step S420 as to whether the patient identified in the request is included in the database 90. If not, a corresponding error message is generated. Alternatively, a further check is performed at step S440 to determine whether a time series exists in the database 90 for the patient and/or any particular parameter that is the subject of the request. A negative result returns an error message in response to the request. If a time series is identified, said series is interrogated at step S450 to determine if measurements exist for any specific time range identified in the request, resulting in either the requested results being returned in answer to the initial query, or an error stating that no corresponding data is available. DISPLAY SYSTEM 310 [00416] Aspects relating to the display of the parameterised data will now be set out in more detail. It has been found that displaying the data as set out below makes monitoring simpler and easier for patients, users and/or clinicians. The data is further gathered in real time and displayed substantially in real time - allowing a clinician to perform real time monitoring and raise alarms in real time. Here, ‘real time’ and ‘substantially real time’ are used to refer to the immediate processing and display of data as soon as it is generated, transmitted and received. As such, ‘real time’ is dependent on the sampling rate of the sensor(s), the transfer rate of raw data, latency in processing the raw data into parameterised data and the refresh rate of the display itself. [00417] As set out above, parameterised data can be output as a time series associated with a particular patient ID and/or Bed ID and stored as part of said patient’s electronic medical record either in real time, at regular periods, or when specifically requested. This parameterised data may also be displayed via display system 310 thereby allowing patients and clinicians to monitor a patient status visually as well as interact with the available data. [00418] In one aspect, the display system 310 comprises a screen and one or more user input means. Said user input means may take the form of a graphical user interface 400 operated via one or more of an integrated touch screen interface, mouse and keyboard and/or other physical control means. Additional physical controls such as buttons, switches and knobs may also be provided around the periphery of the screen to allow a user such as a clinician to interact with the displayed information. The skilled person would understand that any suitable form of user input means may be utilised. As shown in Figure 9, the screen displays a graphical user interface 400 comprising a dashboard with actively monitored patients organised into groups, where an overview of the current state of the patients within each group can be accessed by a clinician via a so-called “Group View” 410. This “Group View” can provide a curated view of health datapoints for each patient in the group, including the most recently received values of certain parameterised data along with patient names, ID’s and/or bed numbers as well as an indication of the location of each patient in the hospital/ward where appropriate. As to which specific parameterised data are displayed in the “Group View”, this may include one or more or all of the physiological parameters being monitored such as respiratory rate, heart rate and SpO2. The specific selection of displayed parameters may be customized by a clinician, set at an organizational or facility level, or reflect a system default. The order in which patients are displayed in the “Group View” may be alphabetical or numerical (according to either a patient’s name or ID) or may alternatively be determined by a score, such as an early warning score, associated with each patient. Patients having a higher score may appear higher or more prominently in the list. Such scoring systems are described in more detail below. [00419] An individual “Patient View” 420 is also accessible for each actively monitored patient and may be accessed directly or by selecting a single patient entry from the afore mentioned “Group View”. As shown in Figure 10, in this “Patient View” the patient name and ID are again displayed. The bed ID and location may also be displayed. Also displayed are the names and sensor IDs of the individual sensors associated with the patient, together with the associated parameterised data received from each respective sensor. In an aspect, sensor information and the associated parameterised data corresponding to each sensor is automatically added to the patient view 420 on detection of the sensor 20 forming part of the system and receipt of the corresponding data by the relay 30 or processing server 40. Conversely, when a sensor is disconnected or stops transmitting data, the corresponding display elements may be removed from the patient view. Alternatively, a warning or notification may indicate the loss of data. This may allow reconnection where sensor loss was inadvertent. [00420] Where parameterised data is received or otherwise derived from one or more medical devices 200 (such as a respiratory therapy device described above), the device name and ID are displayed alongside the associated parameters in a similar manner to that described above. In an aspect, the most recent value received for each physiological parameter are displayed in tiles located in the vicinity of each sensor’s and/or medical device’s details. Where a sensor or medical device provides data on multiple parameters, a separate tile is displayed for each parameter. One or more time series graphs may also be shown displaying the current and historical values of the parameters monitored by the sensors and/or medical devices linked to the patient. A separate graph may be provided for each parameter (with each graph having a common timescale), or alternatively the time series of two or more parameters may be overlayed on the same graph regardless of whether the device from sensor data or a medical device. The size of the time period displayed on the graphs can be adjusted by selecting from a list of pre-set values (such as 5, 10, 15, 30 minutes, or integer days, weeks or months) or by interacting with a sliding scale bar, dial or other control element forming part of the user interface 400 - thereby allowing any desired time window to be selected. The portion of the time series displayed on the graphs at any one time is represented by a graphical timeline 430. In the illustrated example, the highlighted region is representative of the time period visible on the graphs. The length of the period of time displayed on the graphs may be increased or decreased by interacting with the graphical timeline 410 to change the size of a highlighted region. Similarly, the highlighted region may also be transposed along the timeline to move the displayed portion forwards or backwards in time, thereby allowing historical data to be viewed in high resolution. [00421] In a further aspect, the display system 310 also comprises an indicator 440 that may form part of either or both of the “Group View” and “Patient View” described above. A separate indicator 440 may be provided for each of the monitored and displayed physiological parameters and may incorporate the most recent value of a parameter or alternatively may incorporate a rolling average over a pre-set or user selected time period. In the aspect displayed in Figure 10, the indicator is provided in the form of a radial gauge surrounding the parameter value. The gauge is sectioned according to thresholds in the value of the parameter, with lower threshold provided on the left-hand side, and higher threshold provided on the right-hand side. A pointer 441 is also provided, its position representative of the current parameter value displayed at the center of the gauge. [00422] In an aspect, the sections of the gauge are determined and colour coded according to an associated state of the patient. For example, a gauge corresponding to the patient’s heart rate could have a section coloured green for values between the lower and upper thresholds of 40 and 160 bpm, which is usually considered healthy. These thresholds can also be set to predetermined values associated with the facility and/or country in which the system 10 is employed. In one aspect, the system 10 is provided with a look-up table of such predetermined values and employs them automatically when its location is input and/or detected. The thresholds may also be manually defined or selected on first set up of the system by a technician and may further be edited by a clinician or user according to their specific preferences. In an aspect the thresholds may be set by a facility based on, for example, the protocols used at that facility. In a particular aspect, gauge is sectioned according to the parameter thresholds of a scoring system, such as an early warning score system, and can be colour coded accordingly. [00423] Alternatively, or additionally, a gauge is provided to reflect a component risk score. The component risk score may be a single numeric value reflective of a patient’s risk of deterioration. A component risk score may be referred to as and/or represent a health parameter of the patient and vice versa, the terms being understood as interchangeable herein. In some cases, the component risk score comprises at least a subset of measurements required for a clinical risk index, such as a composite early warning score (EWS). Clinical risk indices serve to measure a patient’s risk of health deterioration through quantifying the combined effects of the risk as indicated by individual physiological parameters. Clinical risk indexes may be referred to as and/or represent a health condition of the patient and vice versa, the terms being understood as interchangeable herein. Clinical risk indices offer a comprehensive view of a patient’s condition at a point of time. However, often they include qualitative assessments and/or assessments performed by clinicians. Furthermore, they are also only valid if all measurements are available as they are typically formed by specific combination of multiple physiological parameters. A component risk score uses a plurality of sensed physiological parameters to approximate or generate a numeric value reflect of a patient’s risk of deterioration, or approximate to clinical risk indices. The component risk score and/or the health parameter may use the single physiological parameter with the highest risk level to determine the component risk score. In some cases, a component risk score is calculated for each physiological parameter, with the calculated values then being compared to determine the final component risk score, for example based on the highest value. [00424] Example clinical risk indexes include early warning scores (EWS), the NHS National Early Warning Score (NEWS) and the clinical risk index for babies (CRIB). These indexes quantify the combinatory effects of multiple physiological parameters on a patient. Processing a clinical risk index comprises collecting measurements of the parameters, classifying the risk of individual parameters and evaluating the combined effect of the individual parameters’ risk. However, if one or more parameters are missing the combined effect cannot be calculated due to the missing values and the specificity of the requirements of the indices and/or the inability to calculate the risk index. For example, some risk indexes require a clinician to review the patient and determine, for example, consciousness. Where this review is not available or cannot be measured in real-time the official risk index cannot be calculated. In this case a component risk score can be used instead. The component risk score determined the risk posed by each of the measurable (or where measurements are available). Thus, the component risk score attempts to predict a risk index, based on the measurements available. In some cases, this is equivalent as the component risk score may use the highest risk score of any one of the measured parameters, which often is equivalent to the risk index process. In some cases, multiple risk indices, or risk scores may be calculated in parallel. This may be advantageous where different indices or scores target different potential problems or categories of risk. [00425] By calculating and displaying a patient’s component risk score in real time, a clinician is able to make assessments about a patient and alter their treatment before they deteriorate too far. A score may be derived from one or more physiological parameters such as systolic blood pressure, heart rate, oxygen saturation, respiratory rate and temperature. An index may add additional physiological parameters such as level of consciousness. A score may be calculated according to an aggregate weighted system in which each of the component physiological parameters are assigned points according to the degree of physiological abnormality (i.e. deviation from the expected normal values). In some cases, the aggregate score reflects the highest risk component. The highest risk component represents the physiological parameter of highest risk to the patient. It may be calculated by calculating individual risk components for each of the physiological parameters and comparing them. This may be simplified by normalized the individual risk components before comparison. This may avoid the need to have all the data of a risk index before calculating a risk score, an advantage of a component risk score. The component may be normalised to the scale of the score. For example, if respiratory rate and temperature are monitored, with respiratory rate in yellow and temperature in red, the aggregate score would be red (or a calculated score in the red region). Normalization can help the comparison between measurements in the component risk score to determine the highest individual risk. Alternatively, the raw scores may be compared, with known relationships or scaling between the scores to address the potential different units of the individual risk scores. [00426] Figures 11 and 12 show an exemplary clinical risk index framework in the form of an early warning score matrix from the Adult Early Warning Scoring System in use in New Zealand from 2021, including the colour zones associated with each index or score value, designating risk bands or risk categories and the associated ranges of the component physiological parameters. A component risk score may include any one or more the component physiological parameters. In some cases, the component risk score may include any one or more of the the component physiological parameters which can be measured or sensed. Alternative clinical risk indices and scoring frameworks may be used. Alternative component risk scores may be developed from these frameworks. The framework employed may vary from country to country or region to region. In an aspect, the gauge is sectioned according to these score boundaries, and colour coded accordingly. In use, the particular clinical risk index framework, component risk score, and/or early warning score system adopted may also vary by patient, facility or location, with it being envisaged that separate systems (and thresholds) will be used in maternity and paediatric applications. [00427] In an aspect, each measured parameter of the component risk score is compared to one or more thresholds where the value of a measured parameter in relation to said thresholds is indicated on the display. These thresholds may relate to an early warning score matrix as shown in Figure 11, where each measured parameter is compared to corresponding thresholds defined in the early warning score framework and assigned to a corresponding risk band or risk category (white, yellow, orange, red and blue in the illustrated example). In particular, each parameter may have a number of corresponding thresholds that represent different (i.e. worsening or improving) conditions of a patient. For example, a measured respiratory rate from the patient worn sensor, under bed sensor or medical device is measured in real time or substantially real time. The measured respiratory rate is compared to the various thresholds in an early warning framework. The measured respiratory rate is classified based on comparison to the threshold. In one particular scenario, if the respiratory rate is less than 5 breaths per minute the patient is classified as being in the Blue risk band or risk category, indicating that they require urgent attention/resuscitation. Similarly, if the respiratory rate is between 5-8 then the patient is classified as being in the red risk band or risk category. Example thresholds of an early warning framework are defined in the table shown in figure 11. SpO2 (or any other measured parameter alone or in some combination) may also be used to establish a patient’s status within the early warning framework. The same or similar thresholds and/or measurements may be similarly used for a component risk score, or they may be adapted from other clinical risk indices. [00428] The system further allows for custom thresholds to be defined by a user, technician or clinician. It is envisaged that individual hospitals may set custom thresholds and may define a custom early warning framework or component risk score. For example, the component risk score may depend on the sensors or measurements normally available. Alternatively, the thresholds may be customized to each patient. Alternatively, these thresholds may be set based on ethnicity or age or BMI or any other patient parameter. Aspects of the disclosure provide for customization of both the inputs and outputs of the system, advantageously this allows for hospitals or clinicians to provide the required reporting and/or monitoring set by regulations or hospital protocols. This can be centrally managed due to the open nature of the system and the flexibility of the system architecture in processing storing and displaying the patient health parameters, patient data or ward or multiword overviews. [00429] Based on the thresholds and the determined component risk score for a patient, appropriate actions can be taken as defined (for example) in the table of figure 12. Additionally, or alternatively, an action may comprise raising an alarm at an appropriate hospital alarm system or automatically sending a message to a clinician containing data regarding the particular measured parameter(s) and the threshold(s) exceeded. These actions may also include recording each instance (and the associated metadata) where the measured parameters of a patient are outside particular thresholds. Such instances may be added to the patient’s electronic medical records. Accordingly, if a parameter drops below or increases above a threshold or is out of a threshold range, the system can identify when this happened and for which parameter and report accordingly. Where the patient ID or bed ID is associated with a clinician, including being associated with a location that is then associated with a clinician, the alarm may be sent directly to the associated clinician. This reduces the number of alarms or alerts for each clinician. In some cases, for example where the alarm is not responded to within a period of time or is rejected, the alarm or alert may be sent to a second clinician or to the hospital alarm system. The alarm or alert may be customized to state the urgency or condition causing the alarm. For example, a graph of the physiological parameter may be included in the alarm, or the component risk score may be shown. [00430] Whilst the indicator 440 is depicted as a radial gauge, the skilled person would appreciate that any suitable graphical representation may be used, such as a linear gauge, bullet graph or pie gauge. [00431] Figure 13 shows a version of the above-described patient view 420 in accordance with an aspect in which the patient is receiving therapy from a medical device 200 (such as the respiratory therapy device described earlier). Here the display includes graphical representations (for example, in the form of a time-series graph) of therapy settings over time, including an indication of the operational mode of the therapy device and usage data along alongside the corresponding measured physiological petameters and indicator 440. This allows for clinicians to observe the effectiveness of therapy and interventions by viewing any subsequent changes in the measured patient’s physiological parameters. In particular, it is envisaged that providing access to the treatment history of the patient on a shared time axis with monitored physiological parameters is useful to establish a baseline for how the patient will likely respond to therapy settings based on previously observed responses. [00432] In an aspect the system addresses a problem of handling sensor data from a plurality of sensors. While more patient information is useful to a clinician to decide on an action or therapy, when provided by a plurality of independent sensors is not straightforward to identify a patient issue. By combining the sensors outputs into a real-time display and presenting these so as to draw focus to the patients of highest concern the system provides improved sensing for patient health. COMPONENT RISK SCORE [00433] As set out above, in clinical settings, there are many evaluation frameworks used to aggregate a variety of inputs to categorize the risk of the patient’s condition deteriorating. Often a combination of physiological measurements and subjective measures are used to derive an output that can inform care decisions, such as a score or risk band/category. [00434] The Early Warning Score (EWS) framework described earlier is an example of a clinical risk index that is widely used in hospitals. For each metric or contributing physiological parameter, a score or clinical risk index is determined based on where the values of said metric or parameter falls between predetermined thresholds. Based on this score, the patient is placed in one of five colour categories or risk bands associated with framework (e.g. white, yellow, orange, red, and blue) signifying increasing risk of health deterioration. The illustrated example corresponds to the Early Warning Score framework described above. It is envisaged that any particular colours or risk bands may be employed. [00435] Conventional clinical practice is to take measurements of a patient’s physiological parameters and calculate their clinical risk index and corresponding risk band at regular intervals, thereby providing a ‘snapshot’ of the patient’s condition. However, when viewing a chart of a patient’s risk of deterioration over time, the resultant chart resembles a series of steps as and when the patient’s clinical risk index changes enough to cause a shift in the risk band/colour category. When a patient is within a single risk band for a long period of time their progression is not obvious until they change between bands. However, the physiological parameters contributing to the clinical risk index may fluctuate within the bounds of the current band/category. These fluctuations are not visible to clinicians due to the large ranges of physiological parameters that correspond to a single risk band/category. This issue is common to most clinical risk index frameworks. [00436] A further issue arises from the fact that for many clinical risk indices, the range of values for different physiological parameters that correspond to each risk band or category can be different. This makes it difficult to compare the relative risk posed by each contributory parameter to an overall risk associated with a patient. [00437] In an aspect of the present present disclosure, a component risk score is adapted from a clinical risk index. Figure 14 shows how aspects of a clinical risk index can be incorporated into a component risk score. The component risk score may incorporate one or more of the measurements of a clinical risk index, or measurements related to or based upon the measurements of a clinical risk index. By using only the available measurements, and basing a score on a combination, maximum or minimum of they available measurements the component risk score is able to continuously estimate a clinical risk index. In some cases, as shown in Figure 14, clinician reported values, such as consciousness, are not included in a component risk score. In some cases, this is because they cannot be measured in real-time, or require external evaluation. Alternatively, the component risk score may include both measurement data and clinical reported values and/or patient characteristics (e.g., age, weight, height, length of stay). In one aspect of the present disclosure the intra-category range of parameter values are normalized for each contributing measurement in a component risk score. This increases the granularity of risk information available to clinicians and allows for directly comparing the relative risk posed by different measurements using a unitless value. In some cases, the normalized value allows the system to rank the risk scores for each of the contributing measurements within the risk band. However, it is possible to use raw values and/or have risk bands specified in raw values instead. This in turn allows for tracking of patient trends within a single risk band or category with, for example, a linear scale. In some cases, the scale may be nonlinear, so as to emphasize the changes at areas of most concern. For example, the scale may be non-linear so as to emphasize changes to high-risk patients, while the low- risk patients show less variation. [00438] Using a component risk score may be particularly beneficial as it allows for tracking the patient’s risk at finer increments than the overarching risk bands or categories, making the progression of the patient more visible, as clinicians can track the overall risk of the patient in greater detail within each band and not just between bands. [00439] Figure 15 shows an exemplary component risk score (in this case referencing the Early Warning Score framework described earlier) along with a corresponding normalized component risk score generated according to an aspect. A normalization process for the component risk score or Early Warning Score framework may involve splitting the five risk categories or bands into ten discreet values so that a patient can be graded on a 50-point risk scale ranging from white (0) to blue (40+) across all of the risk bands. As shown in Figure 11, for each measurement type (i.e. contributing physiological parameter), the range of values corresponding to each category or risk band may vary. Accordingly, min-max normalization is employed to ensure that the outputted normalized clinical risk index always reflects the proportional distance to the next risk band, and from the previous risk band. [00440] In an aspect, the normalized component risk score is calculated according to the equation: ^^ ^^ [00441] Here, the measured value is the value of a physiological parameter being obtained from sensor data (for example, a patient’s respiratory rate). The lower risk threshold is the parameter value for the edge of the risk band that marks the transitions to a lower risk band. Conversely, the upper risk threshold is the limit on the edge of the neighboring higher risk band. The lower risk score is the lower limit of the new normalized component risk score for the risk band. The scaler number is equal to the normalized component risk score range applied to each risk band (i.e. 10 in this the present example - though the scaler number could be changed to any number depending on the desired point scale of the normalized component risk score). [00442] In a worked example with a single physiological parameter being monitored (e.g. respiratory rate) a patient breathing 6 times a minute will fall within the Red risk band of the Early Warning Score framework (as shown form Figure 11). According to Figure 11, this gives a lower risk threshold of 8, an upper risk threshold of 5. As can be seen from Figure 15, the lower risk score of the Red risk band is 30. Plugging these numbers into the above equation provides a normalized component risk score of 37, where the Red risk band corresponds to any normalized component risk score falling within the range of 30 to 37. It is immediately apparent therefore that this patient occupies a relatively high-risk position within their current risk band, allowing them to receive priority treatment over other patients at lower risk, but who are otherwise within the same risk band. [00443] Should the patient’s respiratory rate change to 5 or 8, whilst the conventional Early Warning Score framework would indicate only that the patient remains in the red risk band with a score of 3, their normalized component risk score will change from 37 to show the patient as being higher or lower risk within the red risk band. In this way, the normalized clinical risk index is an improvement over non-normalized indices not just because it provides increased granularity relating to a patient’s position within each risk band, but also in that changes (and the rate of change) in the normalized component risk score toward a threshold of a risk band provide a measure of how likely (and when) a patient might transition from one risk band to another. [00444] In a further aspect, an individual component risk score or normalized component risk score (in the following the use of component risk score should be understood as also or alternatively referring to normalized component risk score, where possible) can be calculated for each of a plurality of physiological parameters including but not to respiratory rate, heart rate, SpO2, blood pressure, body temperature, carbon dioxide level and temperature. The calculated individual component risk scores are then used to determine an overall or total component risk score. In an aspect, the total component risk score is set to the highest value of the individual component risk scores. In a further aspect, the total component risk score is given by averaging the values of the individual component risk score. In some cases, the component risk scores may account for differences in measurements, for example a weighted average may be used, or the normalized component risk score. In an alternative aspect, the total component risk score is given by a weighted average of the individual component risk score, wherein the weighting is based on a predetermined rule set that may optionally depend upon the framework employed or the number and/or particular combination of physiological parameters being measured. It may also be set by the clinician according to their preferences. In a yet further aspect, the total component risk score is given by summing two or more of the component individual component risk scores and comparing the summed value to a predetermined threshold, wherein the threshold may again depend upon the scoring framework, the number and/or particular combination of physiological parameters being measured or be set by the clinician. [00445] Figure 16 shows a patient view 420 in accordance with an aspect. Alongside the monitored parameterised data and corresponding sensor information there is provided a graphical display of the component risk score (in this case normalized) presented as a time series. This may be an individual component risk score derived from a single physiological parameter, or it may be a total component risk score derived from a plurality of physiological parameters as set out above. [00446] The time series graph may be accompanied by an indicator 440 of the kind described earlier. In an aspect, visual indicators of the risk bands associated with different thresholds of the component risk score are extended across the time axis of the graph. Figure 16 shows these in horizontal greyscale bars, but they may be coloured to match the component risk score. [00447] In an aspect, the time series graph is updated in real time as new data is received from sensors and a more recent value of the component risk score is calculated. The indicator 440 can provide a rolling average of the component risk score over a pre-set or user selected time period. Alternatively, the indicator 440 may only be updated when data is received that results in a change in the displayed value of the component risk score. The clinician is thus provided with a continuous times series representation of the patient’s risk, which constitutes an improvement over the stepwise jumps in risk bands that would otherwise be displayed without use of the component risk score. [00448] Figure 17 shows a patient view in accordance with a further aspect in which the component risk score is displayed alongside live patient data as described above in relation to Figure 10. This allows for clinicians to visually compare the trends of the component risk score alongside the constituent health measures. In an aspect where a total component risk score is calculated from two or more component physiological parameters, the order of the graphs on screen may be such that the data relating to each physiological parameter is presented in descending order of their contribution to the total component risk score – i.e. physiological parameters that indicate a patient is at a high risk may be located further up the screen or in an otherwise more prominent position. This allows for clinicians to visually compare the trends of the component risk score alongside the constituent health measures. [00449] In a further aspect, treatment details or parameters of the therapy being applied to the patient may also be displayed as described above in relation to Figure 11. [00450] In an aspect a patient view may show changes to the live patient data in a plurality of time periods. For example, Figure 18 shows patient data for three time periods, although more or less may be used. In each time period average data is used to represent changes to the patient data in that time period. Figure 18 shows three weekly time periods 500. In each time period 500 average values have been calculated. A median value 501, upper quartile 502 and lower quartile 503 are shown. This consolidates a patient’s changes over a longer period of time into a patient view. This distils the time-series data stored by the system into an overarching metric of the patient’s health. As shown, interpolation may be used to connect between time periods to create a visual link between the periods. The interpolation is shown as linear, but an estimated curve or alternative interpolation may be used. The patient view may include risk categories 506, shown in this case as horizontal bands. These help the patient view show the changes in patient data relative to expected performance. [00451] In some cases, the the time periods may be larger or smaller. For example, daily time periods, or hourly time periods, or four-hourly time periods, or monthly time periods, or integer days, weeks or months. The number of time periods may change, for example there may be seven, each representing a day of the week, of 4 representing weeks of a month. The patient view may be switchable to view different measured data and/or may display multiple data plots in each view. The patient view may have a list of pre-set values (such as 5, 10, 15, 30 minutes, or integer days, weeks or months). The use of a time-series database allows the system to quickly display the time period views and/or update them in real-time as the data can be quickly obtained from the time-series database. A time-series database is a database optimized for storing and serving time series through associated pairs of time(s) and value(s). This allows the production of profiles or curves based on the data. Each data point in the database is associated with a timestamp. In some cases, the time-series database does not store data indefinitely or reduces the amount of old data stored. This may be achieved through down sampling or deletion, for example. The time-series database may store a predefined time period or window f data (e.g., last year, last month, last week). The timestamp may be used as a key index to improve processing of the data. In some cases, the present system ensures each sensor measurement has an accurate timestamp to allow entry into the time-series database. One example time-series database is InfluxDB™. [00452] Figure 19 shows an alternative patient view of patient data in different time periods. A radar graph is shown to represent five patient data values (in this case, respiratory rate, temperature, heart rate, SpO2 and blood pressure). Values are shown for two time periods 601, 602. These may be values at particular times or may be minimum, maximum and/or average values within the time period. The radar graphs allow for the values of each measured value to be compared across the time periods. For example, a clinician may note that the heart rate has had a large increase while the blood pressure has remained more constant. The radar graph may be used to show temporal changes in a set of features to a clinician without the need for them to view each individual measurement and/or review an entire time-series. Again, the time-series database is able to quickly produce the data required for these graphs because of the storage of data in time series. [00453] In some cases, alternatives to radar graphs can be used. For example, an area chart, a lollipop chart, a radial column chart, a stellar chart. In each case multiple variables are represented in a single view and measurements from multiple times or time periods (or time period averages) can be shown. In some cases, risk categories 606 may be shown on the chart, so as to allow comparison of the measured data with potential risk, for example. Although two time periods are shown more or less can be used, as time series information is available an animation could show the changes over time, for example. The time period charts may also allow a determination of the accuracy or performance of sensors – as incorrect readings should stand out when reviewed by a clinician. [00454] Figure 20 shows a group view in accordance with a further aspect. As depicted, the display screen is divided horizontally into sections 1000, each representing a particular risk band in the utilized component risk score framework. In the illustrated example, the screen is divided into five sections 1000 corresponding to the white, yellow, orange, red and blue risk bands/categories of the Early Warning Score framework. [00455] Each patient in a plurality of monitored patients is represented in the group view by a tile 1100 that is displayed in a section 1000 of the display according their component risk score and the risk band within which it falls. The tile may refer to the Bed ID and/or location as well as, or instead of the patient, to allow clinicians to quickly locate a patent. As a patient’s component risk score changes, the display is updated to reposition the tile within its section and eventually (if the score changes enough) moved to another section corresponding to a new risk band. In an aspect, the position of a tile with a section may be driven by a time- averaged value of the component risk score, where the average value is calculated over a period of time that may be predetermined or set by a clinician, thereby preventing a patient tile from flickering between sections of the display. In a further aspect, the transition of a patient tile from one section to another may be determined by one or more predetermined rules in addition to a time averaged value of the component risk score, for example if the value of the index designates the patient as falling within a different risk band a certain number of times within a preterminal time period. In some cases, the system may show hysteresis to slow transfer between sections. For example, the boundary between sections may not be a single number (e.g., 30) but instead be a higher number when entering the section (e.g., 32) and a lower number when leaving the section (e.g., 28). In this way a patient cannot move as quickly between sections and monitoring can be continued until, for example, they have fully left a high-risk section. [00456] The group view may be a multi-ward view. A multi-ward view allows multiple patients to monitored across multiple rooms and/or wards simultaneously. The multi-ward view may allow a clinician to get a clear overview of all the patients in the facility or hospital, or across home care sites in a single display. In some cases, the multi-ward view is customizable so that a clinician can view a subset of the patients in one or more facilities. For example, the clinician may wish to view the patients they are responsible for, which may be spread across a plurality of locations. The multi-ward view provides the ability to view all of these patients in real-time and to have the most important information, or most at-risk clients, shown in the most detail. [00457] Each tile includes key identifying information is displayed, such as the patient’s name, id number, room, and/or bed allocation. Additional health information may be displayed including but not limited to an indicator 1200 of the total component risk score associated with the patient, the most recent value of the physiological parameter which is most strongly contributing to said total component risk score, any other contributory physiological parameters that are being actively monitored and the parameters associated with any therapy the patient is receiving. Any such therapy parameters are not used in the calculation of the component risk score, but they nevertheless provide context to the clinician monitoring the patients in this view. This allows clinicians to directly compare the metrics driving health changes between patients presented on a single screen. An example tile is shown in Figure 21. [00458] In an aspect, the indicator 1200 of the total component risk score is colour coded depending on a trend in its value. That is, if the most recent successive calculations of the component risk score indicate a downward trend in patient risk (within a risk band or between neighboring risk bands), the indicator 1200 may be colour coded green. Conversely, a trend indicating an increasing risk may result in the indicator being colour coded red. Patients with stable indices – i.e. an score that is not trending substantially in either direction – may be colour coded grey or not colour coded. Trends in the component risk score may also be determined by a rolling average of the component risk score increasing or decreasing, where in either case, a patient tile is updated to elevate its prominence in the group view. It is envisaged that alternative visual trend indicators may be used, including the size and font used to display the current value of the component risk score, or the colour of an associated graphical element on the tile. [00459] In an aspect, the data included on a patient tile (or equivalently bed tile) as well as the manner in which it is displayed (e.g. layout, font size, colour, typeface) is dynamically updated in real time or near real time based upon one or more of the magnitude of the component risk score of the patient, trends in the component risk score, time since updated data relating to the patient was received, or time since the patient was last observed by a clinician. The display of the tile itself (e.g. size, background colour, outline) may also be updated based on one or more of the above factors in real time or near real time. [00460] Figures 22 and 23 show sections of the group view associated with specific risk bands, along with the patient tiles within each section. As depicted, patients with a component risk score that is trending in one direction or another have their tiles displayed more prominently within their section. In some aspects, the tiles of patients who have recently changed sections from one risk band to another are also displayed more prominently. In an aspect, this includes enlarging the patient tile and positioning it towards the top of the respective section. Any enlarged tiles within a section may be organized by the gradient of change in the component risk score, or its magnitude, or some combination of both factors. In a particular aspect, enlarged tiles include more information of use to the clinician, such as an expanded set of live measurements corresponding to the physiological parameters being actively monitored for that patient. In this way, patients who are most likely to shift between sections (or risk bands) are highlighted to a clinician over patients who are likely to maintain their current level of risk. [00461] Patients with a stable component risk score, or a score below a certain threshold with the risk band may have their tiles minimized and displayed towards the lower portion of the corresponding section of the display. In an aspect, these minimized tiles include the same data as provided on the enlarged tiles, albeit with reduced size and emphasis such that patient data is still available to the clinician but not at the expense of the more prominent display of patient tiles representing patients that are more likely to require attention. Should the component risk score of any of these patients become unstable, their tile may be enlarged and repositioned towards the top of the section. This allows clinicians or observers of the system to determine which patients in their care are at the highest risk at a single glance, without needing to interface with controls and menus. [00462] In an aspect, the display of patient tiles may differ depending on the section in which they are displayed i.e. the risk band in which the patient falls. Figure 24 shows an aspect where a patient tile in the Blue section (or highest risk band) may include bolded text in a larger font. [00463] In an aspect, the size of each section may change depending on the relative proportion of patient tiles displayed within that section. For example, when a large number of patient tiles fall into the red sections, the size of the white, yellow, orange and blue sections may be reduced so as to ensure all the patient tiles in the red section are visible on the display screen simultaneously at a suitable resolution and size. In an alternative aspect, the tiles for patients in the sections corresponding to lower risk bands may be reduced in size to accommodate the display of all patient tiles in sections corresponding to higher risk bands. These reduced tiles may show less information than would otherwise be the case, such as fewer live metrics. In a further aspect, any sections with no patient tiles may be minimized or removed from the display altogether. The group view described above improves upon current clinical practice by streamlining risk evaluation. Patients are positioned on the screen based upon their risk level, health trends, and relative to other patients in the group. Patients that need a clinician’s attention are the most visible, and first to be seen on the dashboard. Additionally, the clinician can view all of the aforementioned information on the patient tiles as well as the risk level associated with every patient in their care on a single screen without needing to access menus or interface with a computer mouse or touch screen. This allows the most relevant information to be presented to a clinician, from the large amount of data and information in the patient management system. Furthermore, the live, real time nature of the date being used to determine a patient’s physiological parameters and component risk score means that the patient tiles are always updating and moving around the screen accordingly. This means the display ensures that the clinician is focused on the most urgent patients and/or tasks. Similarly, the use of a component risk score, optionally normalized, reduces the amount of space required for display of the information. [00464] In an aspect, the display of patient tiles (or the manner in which they are displayed) may be dynamically adjusted depending on characteristics of the display. For example, the display may have a registered user, such as a clinician. The display may then update to only show and/or to highlight and/or enlarge tiles for which the nurse is responsible. In this way the attention of the clinician is directed to the patients they manage (or the beds in their room or ward), and the limited display area focusses or only shows data on these patients. Alternatively, the characteristic may be a location of the display. For example, the display may show and/or highlight and/or enlarge tiles in the same room as the display. In some cases where the display is within RFID range of a locator system for a bed (such as the RFID system described previously. [00465] In an aspect a display is mounted in a location such as a room or ward. The display is configured to show tiles for each patient in the room or ward. The display may be configured to determine, from the system, which patients are in the room or ward, and only display the patients present. The manner of the display of each of the tiles may be adjusted as described above, based on the component risk score and/or how close the clinician is to the patient. For example, if the clinician is standing next to the patient the display may show substantially only that patient. This allows the display to clearly show staff the current situation in a particular location. The tiles may be enlarged and/or highlighted as described previously to indicate particular concerns. [00466] DISCHARGE SYSTEM [00467] Aspects relating to the display of the parameterized data have been explained with reference to monitoring patients during the the care by clinicians. However, additional views of the parametrized data may be used for other purposes. In some cases, the display may be switched between alternative views depending on clinical requirements. For example, a first view for monitoring patient wellbeing and a second view for considering whether a patient can be moved or released. The alternative views may be based on a component risk score (or risk index). The component risk score may be the same for each view (with, for example, a different presentation), or there may be alternative component risk scores. The alternative views may be based on an alternative metric. In this example we consider a discharge score. The discharge score is a measure of the risk of discharging a patient. The discharge score may consist of, or comprise, a component risk score. The discharge score may use an adjusted component risk score compared to patient monitoring, or use different measured characteristics, to better represent the risk of discharging a patient. [00468] Figure 25 shows a group view in accordance with a further aspect. This aspect is configured, for example, to allow a clinician to identify patients ready for discharge. However, alternative characteristics, or combinations of characteristics, may be used to create and display patient bands. As depicted, the display screen is divided horizontally into sections 2000, each representing a particular risk band for discharging a patient. In the illustrated example, the screen is divided into five sections 2000 corresponding to example bands of risk associated with discharge of a patient. As described with respect to a component risk score, the discharge score could be based on, or incorporate a component score and/or one or more values measured in real-time or near real-time. Customization of a discharge view advantageously allows for hospitals or clinicians to provide the required reporting and/or monitoring set by regulations or hospital protocols before discharge. This can be centrally managed due to the open nature of the system and the flexibility of the system architecture in processing storing and displaying the patient health parameters, patient data or ward or multiword overviews. [00469] Each patient in a plurality of monitored patients is represented in the group view by a tile 2100 that is displayed in a section 2000 of the display according their discharge score and the risk band within which it falls. As a patient’s discharge score changes, the display is updated to reposition tile the within its section and eventually (if the score changes enough) moved to another section corresponding to a new risk band. In an aspect, the position of a tile with a section may be driven by a time-averaged value of the discharge score, where the average value is calculated over a period of time that may be preterminal or set by a clinician, thereby preventing a patient tile from flickering between sections of the display. In a further aspect, the transition of a patient tile from one section to another may be determined by one or more predetermined rules in addition to a time averaged value of the discharge score, for example if the value of the score designates the patient as falling within a different risk band a certain number of times within a preterminal time period. For example, if a patient appears to be at the lowest risk of discharge, but has only recently entered this category, or has moved regularly out of this category they may be placed in a higher risk category until the discharge score has improved. [00470] Each tile includes key identifying information is displayed, such as the patient’s name, id number, and room or bed allocation. Additional health information may be displayed including but not limited to an indicator 1200 of the total discharge score associated with the patient, the most recent value of the physiological parameter which is most strongly contributing to said total discharge score (e.g., the highest risk component, which might limit discharge), any other contributory physiological parameters that are being actively monitored and the parameters associated with any therapy the patient is receiving. Any such therapy parameters are not used in the calculation of the discharge score, but they nevertheless provide context to the clinician considering discharge of the patients in this view. This allows clinicals to directly compare the metrics driving health changes between patients presented on a single screen. [00471] The discharge score may also, or alternatively use further algorithms or measurements to determine categories of risk associated with patient discharge. For example, an algorithm such as a decision tree, rules engine, or flow chart could be used to determine patient categories. The characteristics may include the measured trends of the patient, patient characteristics (for example, age, weight, ethnicity, sex) or therapy characteristics (illness, diagnosis, therapy applied, therapeutic devices used, time under therapy). The measured trends of the patient may comprise the discharge score, parts thereof, or physiological measurement data collected using a real time patient monitoring system. In some cases, the therapy characteristics may comprise an initial diagnosis; a record of the diagnosis over a patient’s stay at the facility; observations by caregivers or clinicians and/or comorbidities and past medical history. In some cases, socio-economic factors such as a patient’s support network and/or the home environment may also be considered. The patient, therapy and/or socio-economic data may be inputted into the system by a clinician, patient or from an electronic medical record or patient medical record. Further patient, therapy and socio- economic characteristics may be included as available. [00472] In an aspect the discharge component risk score at least attempts to consider the current condition of a patient and a predicted future condition of a patient. The patient characteristics may help assess the future risks of readmission and/or deterioration outside the care facility. The forecasting of expected discharge could use historical data on performance of previous patients (either using the current system, or from corresponding data). [00473] In an aspect the system is configurable to allow discharge scores, or discharge risk levels to be adjusted in, or within, each facility. This allows each facility to configured desired discharge processes conforming to their own practices. The system may allow adjustment of any one or more of inputs, weighting and categorization. [00474] Further displays may use tiles and features of tiles as shown in Figures 21, 22 and 23, but with a focus on discharge score. In an aspect, the indicator 1200 of the total discharge score is colour coded depending on a trend in its value. That is, if the most recent successive calculations of the discharge score indicate a downward trend in patient discharge risk (within a risk band or between neighboring risk bands), the indicator 1200 may be colour coded green. Conversely, a trend indicating an increasing risk may result in the indicator being colour coded red. Patients with stable indices – i.e. an index that is not trending substantially in either direction – may be colour coded grey or not colour coded. The colour coding may depend on the level of risk – stable low risk may be colour coded green as this also suggests suitable for discharge. Trends in the discharge score may also be determined by a rolling average of the discharge score increasing or decreasing, where in either case, a patient tile is updated to elevate its prominence in the group view. It is envisaged that alternative visual trend indicators may be used, including the size and font used to display the current value of the discharge score, or the colour of an associated graphical element on the tile. [00475] In an aspect, the data included on a patient tile as well as the manner in which it is displayed (e.g. layout, font size, colour, typeface) is dynamically updated in real time or near real time based upon one or more of the magnitude of the discharge score of the patient, trends in the discharge score, time since updated data relating to the patient was received, or time since the patient was last observed by a clinician. The display of the tile itself (e.g. size, background colour, outline) may also be updated based on one or more of the above factors in real time or near real time. While explained as a discharge score, in some aspects the discharge score relates to alternative measures or requirements, such as any one or more of patient monitoring, discharge, change of therapy. In some cases, the system may perform tasks based on the displayed data. For example, the system may identify or raise an alert of those patients that are potentially ready for discharge. For example, if a patient is showing as ready to discharge, or potentially ready to discharge, the system may prepare the discharge forms. The discharge forms may be provided to the clinician electronically, for example by a link on the display. The clinician may have to perform steps to finalize the discharge decision after receipt of the forms. An indicator on the display may show that the forms, or other materials are ready. In an aspect the display may determine whether to display a discharge view or a monitoring view based on the patient risk. For example, where a patient is in a high-risk band the display may only show a monitoring view. [00476] In an aspect the system comprises a secondary display or device This may provide an alert or an alarm to a portable computing device, such as a tablet or a mobile phone. An alert to a secondary device may be restricted to a portion of possible alerts. For example, alerts may only be sent to the secondary device at a certain level of risk, or based on a subset of patients (e.g., the patients the clinician is directly responsible for). In an aspect the alert may also flash or be notified on a primary display. Using a secondary display to receive targeted alerts reduces the number of alarms or alerts for each clinician. In some cases, for example where the alarm is not responded to within a period of time or is rejected, the alarm or alert may be sent to a second clinician or to the hospital alarm system. The alarm or alert may be customized to state the urgency or condition causing the alarm. For example, a graph of the physiological parameter may be included in the alarm, or the component risk score may be shown. [00477] In an aspect the display may only present a selection of patients in the discharge view. For example, the display may only show the lowest, or lowest two bands. This may reduce the complexity shown on the screen to focus on the most likely patients to be discharged. Attempting to determine patients appropriate for discharge can be difficult due to the large amount of information and many possible patients. The use of the discharge view allows a large amount of information to be shown clearly on the display by drawing the clinician to the most relevant, or most urgent information. [00478] The time available to a healthcare provider to monitor patients (either by direct interaction with data provided by sensors/medical devices, or by reviewing a patients updated medical records) in a healthcare environment is limited. Conventional practice is to review data outputted by patient sensors/medical devices at regular intervals, such as every four hours. One or more of the aspects described above may advantageously provide an efficient system for efficiently and continuously gathering, processing and assessing data from plurality of patient sensors and/or medical devices and automatically updating a corresponding electronic medical record and display screen in real time. This allows for remote, continuous and instantaneous automated assessments of a patient’s condition, enabling early detection of any deterioration in a patient’s health or status. [00479] Accordingly, the responsiveness of healthcare professionals to a sudden deterioration of patient’s condition can be dramatically improved without increasing the work required by the healthcare professionals themselves, but rather by utilizing the sensors and/or medical devices to continuously monitor and report on the patient’s status in real time and by providing a system that can dynamically receive and process data from such sensors and/or medical devices. In particular, the real time aspect provides healthcare professionals greater visibility and certainty and allows for earlier intervention if a patient’s status deteriorates. Further, the rapid identification of patients showing signs clinical deterioration can result in an improvement in the care an outcome of patients. This is typically expressed as a reduction in the duration of care or reduced acuity of care, such as the admission to the intensive care unit (ICU) etc. [00480] Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium such as a storage medium or other storage(s). A processor may perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc. [00481] In the foregoing, a storage medium may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The terms "machine readable medium" and "computer readable medium" include, but are not limited to portable or fixed storage devices, optical storage devices, and/or various other mediums capable of storing, containing or carrying instruction(s) and/or data, including non-transitory mediums. [00482] The various illustrative logical blocks, modules, circuits, elements, and/or components described in connection with the examples disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, circuit, and/or state machine. A processor may also be implemented as a combination of computing components, e.g., a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. [00483] The methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD- ROM, or any other form of storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. [00484] One or more of the components and functions illustrated the figures may be rearranged and/or combined into a single component or embodied in several components without departing from the present disclosure. Additional elements or components may also be added without departing from the present disclosure. Additionally, the features described herein may be implemented in software, firmware, hardware, and/or any combination thereof. [00485] In its various aspects, the present disclosure can be embodied in a computer- implemented process, a machine (such as an electronic device, or a general purpose computer or other device that provides a platform on which computer programs can be executed), processes performed by these machines, or an article of manufacture. Such articles can include a computer program product or digital information product in which a computer readable storage medium containing computer program instructions or computer readable data stored thereon, and processes and machines that create and use these articles of manufacture.

Claims

CLAIMS 1. A patient management system comprising: a data management server in communication with a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients, the data management server configured to: receive, via a network, sensor data from the plurality of sensors; determine a component risk score for each of the plurality of patients from the sensor data; assign each of the plurality of patients to corresponding one of a plurality of groups based at least in part on the component risk score and a plurality of rules; and cause a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with a patient of the plurality of patients and their component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the value of their associated component risk score.
2. The patient management system of claim 1 wherein the sensor data is received over one or more advertising channels of a short-range wireless communication component.
3. The patient management system of any of claims 1 and 2 wherein the one or more patient identifiers are grouped into regions of the display, each region associated with an upper and lower threshold for the component risk score, said thresholds defining a plurality of risk bands.
4. The patient management system of claim 3 wherein the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score.
5. The patient management system of any of claims 3 and 4 wherein the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated.
6. The patient management system of any of claims 1 to 5 wherein the one or more patient identifiers are in the form of a tile.
7. The patient management system of any of claims 1 to 6 wherein the one or more patient identifiers each comprise a risk indicator.
8. The patient management system of claim 7 wherein the risk indicator includes a numerical value indicative of the risk level of a patient based on at least one of their component risk score , and an associated risk band.
9. The patient management system of claim 8 wherein the risk indicator is updated in real time, as updated values of the component risk score are determined.
10. The patient management system of any of claims 8 and 9 wherein the numerical value is a rolling average.
11. The patient management system of any of claims 8 to 10 wherein the risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same.
12. The patient management system of claim 11 wherein the risk trend indicator is colour coded.
13. The patient management system of any of claims 1 to 12 wherein the one or more patient identifiers further comprises a display of one or more a physiological parameters associated with the patient, wherein the selection and arrangement of the one or more physiological parameters is based on their contribution to the clinical risk indicator.
14. The patient management system of claim 13 wherein the display of the one or more physiological parameters is updated in real time.
15. The patient management system of any of claims 13 or 14 wherein the display of the one or more physiological parameters comprises a rolling average of the one or more physiological parameters.
16. The patient management system of any of claims 1 to 15 wherein the one or more patient identifiers each comprise one or more of the following elements: a patient identification number, a patient room number, a patient bed number, a patient name, and an indication of the time expired since a clinician last interacted with the patient.
17. The patient management system of claim 16 wherein the presence, size, and display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the component risk score.
18. The patient management system of any of claims 16 and 17 wherein the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score.
19. The patient management system of claim 18 wherein the second risk band is a higher risk band than the first risk band.
20. The patient management system of any of claims 18 and 19 wherein the estimated amount of time is provided by analysing a trend in historical values of the component risk score.
21. The patient management system of any of claims 1 to 20 wherein the sensor data is received from respiratory support device comprising or in communication with the plurality of sensors.
22. The patient management system of any of claims 1 to 21 wherein the component risk score is a normalized component risk score.
23. A method of patient management comprising: receiving, via a network, sensor data from a plurality of sensors configured to measure one or more physiological parameters of a plurality of patients; determining a component risk score for each of the plurality of patients; assigning each of a plurality of patients to one of a plurality of groups based at least in part on the component risk score and a plurality of rules; and causing a display to display a graphical user interface, in a first display mode, one or more patient identifiers, each associated with a patient of the plurality of patients and their component risk score; wherein the one or more patient identifiers are arranged within their group of the plurality of groups on the display screen based on the relative value of their associated component risk score.
24. The method of claim 23 wherein the sensor data is received over one or more advertising channels of a short-range wireless communication protocol.
25. The method of claim 23 or 24 wherein assigning the plurality of patients to a plurality of groups comprises re-assigning a patient from a first group having an associated risk band to a second group having a second associated risk band; the method further comprising the step of generating an alert condition if the second associated risk band is associated with a higher clinical risk than the first risk band.
26. The method of claim 25 wherein the alert condition triggers a notification to a hospital monitoring system.
27. A method for generating a normalized component risk score based on the measurement of one or more physiological parameters of a patient, the method comprising the steps of: receiving sensor data; determining at least one physiological parameter of the patient from the sensor data; determining a component risk score based on the at least one physiological parameter; outputting the component risk score.
28. The method of any one of claim 27 wherein the sensor data is received over one or more advertising channels of a short-range wireless communication protocol.
29. The method of claim 27 or 28 wherein determining the component risk score comprises associating at least one of the at least one physiological parameters with a corresponding risk band of a plurality of risk bands, each risk band in the plurality of risk bands having a respective first upper and first lower threshold, the associated at least one physiological parameter falling between the first upper and first lower thresholds of the corresponding risk band.
30. The method of any claims 29 wherein the risk bands correspond to predetermined Early Warning Score values.
31. The method of any of claims 29 to 30 wherein the plurality of risk bands comprises a first risk band and second risk band.
32. The method of claim 31 wherein the size of the first risk band is different to the size of the second risk band.
33. The method of claim 32 wherein the size of a risk band is defined by the difference between its first upper and first lower threshold.
34. The method of any of claims 27 to 33 wherein the physiological parameter is one of body temperature, blood pressure, respiratory rate, heart rate, carbon dioxide level, and SpO2.
35. The method of any of claims 27 to 34 wherein the physiological parameter and component risk score are stored as a time series.
36. The method of any of claims 27 to 35 wherein the physiological parameter and component risk score are updated in real time.
37. The method any of claims 27 to 36 wherein the component risk score is recalculated at regular intervals of time.
38. The method any of claims 27 to 37 wherein the component risk score is recalculated only when new sensor data is received, and an updated physiological parameter is determined.
39. The method of claims 27 to 38 further comprising the steps of: determining a second physiological parameter from the sensor data; determining a second component risk score based on the second physiological parameter; outputting the second component risk score; and determining a total component risk score based on the first and second component risk score.
40. The method of claim 39 wherein determining the total component risk score comprises selecting the highest of the first and second component risk score as the total component risk score.
41. The method of claim 39 wherein determining the total component risk score comprises averaging the first and second component risk score.
42. The method of claim 39 wherein determining the total component risk score comprises calculating a weighted average of the first and second component risk score, wherein the weighting is based on a predetermined rule set.
43. The method of claim 39 wherein determining the total component risk score comprises summing the first and second component risk score and comparing the summed value to a predetermined threshold.
44. The method of claims 27 to 43 further comprising the step of: displaying the component risk score in a first view of a display screen, wherein the component risk score is displayed along with a patient identifier, the patient identifier corresponding to a patient associated with the sensor data and the physiological parameter derived therefrom.
45. The method of claim 44 wherein the component risk score is displayed in the form of a gauge, wherein the gauge is sectioned according to the second upper and second lower thresholds of the plurality of risk bands.
46. The method of claim 45 wherein the gauge displays a rolling average of the component risk score.
47. The method of any of claims 44 to 46 wherein displaying the component risk score further comprises displaying a graphical time series showing current and historical values of the component risk score.
48. The method of any of claims 44 to 47 further comprising the step of: displaying the physiological parameter in the first view of a display screen. 49. The method of claim 48 wherein displaying the physiological parameter further comprises displaying a graphical time series showing current and historical values of the physiological parameter.
49. The method of claim 49 wherein the graphical time series are updated in real time as updated values are determined.
50. The method of any preceding claim when dependent on claim 39, further comprising the steps of: displaying the second physiological parameter; displaying the second component risk score; and displaying the total component risk score.
51. The method of claim 50 wherein the display of the first and second physiological parameter is arranged based on their associated first and second component risk score.
52. The method of claim 50 wherein the display of the first and second physiological parameter is arranged according to the relative contribution of the first and second physiological parameter to the total component risk score.
53. The method of claims 27 to 52 further comprising the step of receiving parameters of a therapy being provided to the patient by a respiratory support device and/or usage data representing the patient’s use of the respiratory support device; and displaying said therapy parameters and/or usage data on the display screen.
54. The method of claim 53 wherein the therapy parameters and/or usage data are displayed as a time series and updated in real time.
55. The method of any of claims 44 to 54 further comprising the step of: displaying, in a second view of a display screen, one or more patient identifiers, each associated with a patient and component risk score; wherein the one or more patient identifiers are arranged on the display screen based on the relative value of their associated component risk score.
56. The method of claim 55 wherein the one or more patient identifiers are grouped into regions of the display, each region associated with a risk band of the plurality of risk bands.
57. The method of claim 56 wherein the size and or relative position of the one or more patient identifiers within its region of the display is based on one or more of the rate of change and direction of change of the corresponding component risk score.
58. The method of claim 57 wherein the arrangement of the one or more patient identifiers is updated in real time as the determined value of the associated component risk score is updated.
59. The method of any of claims 55 to 58 wherein the one or more patient identifiers are in the form of a tile.
60. The method of claim 59 wherein the one or more patient identifiers each comprise a risk indicator.
61. The method of claim 60 wherein the risk indicator includes a numerical value indicative of the risk level of a patient based on their component risk score and the associated risk band.
62. The method of any of claim 61 wherein the numerical value is a rolling average.
63. The method of claim 60 to 62 wherein the risk indicator is updated in real time, as updated values of the component risk score are determined.
64. The method of any of claims 60 to 63 wherein the risk indicator further comprises a risk trend indicator that is configured to change its state depending on whether the risk level of the patient is increasing, decreasing or staying the same.
65. The method of claim 64 wherein the risk trend indicator is colour coded.
66. The method of any of claims 55 to 65 wherein the one or more patient identifiers further comprises a display of one or more a physiological parameters associated with the patient, wherein the selection and arrangement of the one or more physiological parameters is based on their contribution to the component risk score.
67. The method of 66 wherein the display of the one or more physiological parameters is updated in real time.
68. The method of claim 67 wherein the display of the one or more physiological parameters comprises a rolling average of the one or more physiological parameters.
69. The method of any of claims 55-68 wherein the one or more patient identifiers each comprise one or more of the following elements: a patient identification number, a patient room number, a patient bed number, a patient name, and an indication of the time expired since a clinician last interacted with the patient.
70. The method of claim 69 wherein the presence, size, and/or display parameters of the one or more elements is based on one or more of the magnitude, rate of change and direction of change of the component risk score.
71. The method of claim 69 wherein the presence, size, and/or display parameters of the one or more elements is based on one or more of: the amount of time since a patient identifier has moved from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score; and the estimated amount of time until a patient identifier moves from one region of the display associated with a first risk band, to another region of the display associated with a second risk band as a result of a change in the respective component risk score.
72. The method of claim 71 wherein the second risk band is a higher risk band than the first risk band.
73. The method of any of claims 71 and 72 wherein the estimated amount of time is provided by analysing a trend in historical values of the component risk score.
74. The method of any of claims 27 to 73 comprising normalising the component risk score.
75. The method of claim 74 wherein determining the component risk score comprises feature scaling or min-max normalization of the physiological parameter within the first thresholds of the risk band to give a measure of the position of the physiological parameter within the first thresholds of the risk band.
76. The method of any of claims 74 to 75 wherein determining the normalized component risk score comprises standardizing the size of each risk band in the plurality of risk bands to a preferred size W, wherein each standardized risk band has a second upper threshold and second lower threshold separated by W.
77. The method of claim 76 wherein the normalized component risk score is determined according to the formula: ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ − ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ = × ^^ + ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ − ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ℎ ^^ ^^ ^^ 78. A patient monitoring system comprising configured to perform the method of any of claims 27-77. 79. The patient monitoring system of claim 51 comprising: one or more sensors; and a processing server. 79. A method for monitoring patients with a plurality of health sensors to identify patients with deteriorating health, the method comprising: receiving sensor data from the plurality of sensors over one or more advertising channels of a short-range wireless communication component, the sensor data based on measurements of an individual patient; determining a physiological parameter of the individual patient from the sensor data; determining a health parameter based on the physiological parameter; outputting the health parameter. 80. A method for operating a sensor system to monitor health of a patient, the method comprising: receiving sensor data from a plurality of sensors via one or more advertising channels of a short-range wireless communication component; determining two or more physiological parameters of the patient based on the sensor data from the plurality of sensors; determining a health condition based on the physiological parameters; and outputting the health condition. 81. A method for operating a sensor system to monitor health of a patient, the method comprising: receiving sensor data from a plurality of sensors via one or more advertising channels of a short-range wireless communication component, the sensor data indicative of one or more physiological parameters of the patient; detecting, based on the sensor data, that a health parameter of the patient is above or below a predetermined threshold; and outputting, to a healthcare provider, an indication of the health parameter to cause the healthcare provider to provide treatment to the patient. 81. The method of claim 80 or 81, wherein detecting that the health parameter of the patient is above or below the predetermined threshold comprises comparing different physiological parameters, each physiological parameter obtained from sensor data from the plurality of sensors. 82. The method of claim 81, wherein detecting that the health parameter of the patient is above or below the predetermined threshold comprises: determining the one or more physiological parameters from the sensor data; and determining, based on the one or more physiological parameters, the health parameter of the patient; and comparing the health parameter to the predetermined threshold. 83. A method for operating a hub for a system for monitoring a patient’s health, the method comprising: receiving, from a first sensor peripheral to the hub, a first data packet via a first advertising channel of a short-range communication component, wherein the first data packet contains sensor data from the first sensor related to a first physiological measurement of the patient; sending the first data packet to a server peripheral to the hub via a network communication component, receiving, from a second sensor peripheral to the hub, a second data packet via a second advertising channel of the short-range communication component, wherein the second data packet contains sensor data from the second sensor related to a second physiological measurement of the patient; and sending the second data packet to the server via the network communication component. 84. The method of claim 83 wherein the first advertising channel is the same as the second advertising channel. 85. The method of claim 83 wherein the first advertising channel is different from the second advertising channel. 86. The method of any of claims 83 to 85, further comprising at least partially processing the first data packet before sending the first data packet to the server. 87. The method of any of claims 83 to 86, further comprising formatting the first data packet before sending the first data packet to the server. 88. The method any of claims 83 to 87, further comprising adding a timestamp to the first data packet. 89. The method of claim 83 to 85, further comprising forwarding the raw data and/or unprocessed first sensor data, in the first data packet to the server. 90. The method of any of claims 83 to 89 wherein the first physiological parameter is the same as the second physiological parameter, and wherein the method further comprises combining the first data packet and the second data packet before sending the first data packet and the second data packet to the server. 91. The method of any of claims 83 to 90 wherein the network communication component is a wireless internet component. 92. The method of any of claims 83 to 91 wherein the first data packet is received in a continuous stream of data packets from the first sensor via the first advertising channel. 93. The method of any of claims 83 to 92 wherein the first data packet and the second data packet are sent to the server at the same time. 94. The method of any of claims 83 to 93, further comprising receiving, from a third sensor peripheral to the hub, a third data packet via a third advertising channel of the short- range communication component, wherein the third data packet contains sensor data from the third sensor related to a third physiological measurement of the patient. 95. The method of any of claims 83 to 94 wherein the first data packet includes a patient identifier, and wherein the second data packet includes the patient identifier. 96. A hub for a system for monitoring health of a patient, the hub comprising: a short-range communication component; a network communication component; a processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receive, from a first sensor peripheral to the hub, a first data packet via a first advertising channel of the short-range communication component, wherein the first data packet contains sensor data from the first sensor related to a first physiological measurement of the patient; sending the first data packet to a server peripheral to the hub via the network communication component., receiving, from a second sensor peripheral to the hub, a second data packet via a second advertising channel of the short-range communication component, wherein the second data packet contains sensor data from the second sensor related to a second physiological measurement of the patient; and sending the second data packet to the server via the network communication component. 97. A system for monitoring a patient’s health, the system comprising: a central hub, the central hub comprising a short-range communication component with a plurality of advertising communication channels; a first sensor peripheral to the central hub, the first sensor configured to obtain measurements of a first physiological parameter of the patient and send first data packets to the central hub via a first advertising channel of the plurality of advertising communication channels, wherein each of the first data packets contains data related to the measurements of the first physiological parameter; and a second sensor peripheral to the central hub and the first sensor, the second sensor configured to obtain measurements of a second physiological parameter of the patient and send second data packets to the central hub via a second advertising channel of the plurality of advertising communication channels, wherein each of the second data packets contains data related to the measurements of the second physiological parameter.
EP23888221.1A 2022-11-10 2023-11-10 Patient monitoring method and system Pending EP4616429A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AU2022903368A AU2022903368A0 (en) 2022-11-10 Patient monitoring method and system
AU2023900383A AU2023900383A0 (en) 2023-02-16 Patient monitoring method and system
AU2023902278A AU2023902278A0 (en) 2023-07-17 Patient monitoring method and system
PCT/IB2023/061350 WO2024100606A1 (en) 2022-11-10 2023-11-10 Patient monitoring method and system

Publications (1)

Publication Number Publication Date
EP4616429A1 true EP4616429A1 (en) 2025-09-17

Family

ID=91032058

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23888221.1A Pending EP4616429A1 (en) 2022-11-10 2023-11-10 Patient monitoring method and system

Country Status (6)

Country Link
EP (1) EP4616429A1 (en)
JP (1) JP2025539068A (en)
CN (1) CN120958535A (en)
AU (1) AU2023378872A1 (en)
GB (1) GB2640055A (en)
WO (1) WO2024100606A1 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119028604A (en) * 2024-07-29 2024-11-26 中国人民解放军总医院第四医学中心 A multi-channel remote rehabilitation medical service system and method based on smart watch
CN120203546A (en) * 2025-05-29 2025-06-27 深圳市威视佰科科技有限公司 Method, system and computer program product for sensing health based on fingertip wearable spectral sensor
CN121191694B (en) * 2025-11-26 2026-03-03 天津茵诺科技集团有限公司 Comprehensive service system and method based on Internet remote rehabilitation

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9968266B2 (en) * 2006-12-27 2018-05-15 Cardiac Pacemakers, Inc. Risk stratification based heart failure detection algorithm
US8373557B2 (en) * 2007-10-19 2013-02-12 Smiths Medical Asd, Inc. Method for establishing a telecommunications network for patient monitoring
AU2013215288A1 (en) * 2012-01-30 2014-07-31 Ross Medical Corporation Dynamic risk management and resource allocation and treatment system and method
WO2017089914A1 (en) * 2015-11-24 2017-06-01 Koninklijke Philips N.V. Critical care patient monitoring service recommendation using data and text mining techniques
US20170155427A1 (en) * 2015-11-30 2017-06-01 General Electric Company Wireless network transfer
CA3014761C (en) * 2016-02-17 2022-07-19 The Cleveland Clinic Foundation Systems and methods for remote monitoring of non-critically ill hospitalized patients
CN110050308A (en) * 2016-12-02 2019-07-23 心脏起搏器股份公司 Multi-sensor stroke detection
US11229406B2 (en) * 2017-03-24 2022-01-25 Medtronic Minimed, Inc. Patient-specific glucose prediction systems and methods
US20210196121A1 (en) * 2019-12-31 2021-07-01 GE Precision Healthcare LLC Patient Monitoring System and Method With Automated Patient Monitor Transfer

Also Published As

Publication number Publication date
JP2025539068A (en) 2025-12-03
GB202508678D0 (en) 2025-07-16
WO2024100606A1 (en) 2024-05-16
AU2023378872A1 (en) 2025-05-29
GB2640055A (en) 2025-10-08
CN120958535A (en) 2025-11-14

Similar Documents

Publication Publication Date Title
US12573286B2 (en) Health care sanitation monitoring system
US12062439B2 (en) Medical communication protocol translator
US20240203578A1 (en) Medical monitoring system
US11133105B2 (en) Medical monitoring system
AU2023378872A1 (en) Patient monitoring method and system
JP7045749B1 (en) Software, health condition judgment device and health condition judgment method
WO2021044520A1 (en) Software, state-of-health determination device, and state-of-health determination method
JP7639274B2 (en) Biological information processing device, information processing device, trained model generation device, and program
JP7747562B2 (en) Information processing device, information processing method, and program
TWI843032B (en) Blood oxygen monitoring method and system, and computer-readable recording medium
JP7732920B2 (en) Information processing device, information processing system, information processing method and program

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250603

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)