Data transmission method and system

Abstract

Systems and method for the transmission and receival of data between one or more sensors configured to measure physiological parameters and one or more further sensors and devices. In particular relating to data transmission where a direct connection is not formed between the sensors and devices and the transmission is initiated or controlled by a remote processor. In some cases a method of receiving medical data on a first device, the method comprising the steps of: Receiving, from a remote processor, transmission parameters for a second device configured to transmit physiological parameters; Monitoring a broadcast channel; Receiving, on the broadcast channel, a data packet from the second device; Determining the physiological parameters from the second device based on the transmission parameters.

Description

DATA TRANSMISSION METHOD AND SYSTEMTECHNICAL FIELD

[0001] The present disclosure generally relates to the transmission and receival of data between one or more sensors configured to measure physiological parameters and one or more further sensors and devices. More particularly it relates data transmission where a direct connection is not formed between the sensors and devices and the transmission is initiated or controlled by a remote processor.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. 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.

[0003] The medical records for a patient in healthcare environment are typically kept as a paper chart at a patient's bedside. 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.

[0004] Regulations such as the Health Insurance Portability and Accountability Act (HIPAA) in the USA provide standards that require any system that handles sensitive medical information be appropriately secured. Specifically, the HIPAA privacy rule requires security of protected health information which includes patient identity, medical record numbers, social security numbers and more. As technology has been adopted into the health space, ensuring the security of digital data while keeping it accessible to those who need it is a challenge aswireless sensors and medical devices are constantly generating, transmitting, and storing health data.

[0005] Wireless data exchange poses security risks for sensitive medical information. For example, wireless data exchange presents an opportunity for bad actors to intercept patient information. Remote monitoring systems must manage this security risk. Transferring encrypted information over a secure connection requires energy and processing power. The demands on low power, portable, wireless sensors are even more pronounced. Further demands are placed when the information is being passed to a remote processor such as a local or remote server where there may be a lack of oversight or control of the information.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 such as a hospice or other facility.SUMMARY

[0007] In some cases, the present system and method allow for wireless sensors / devices to publicly transmit secure information to many other devices and / or sensors without direct connections being formed between the devices and / or sensors. This may be achieved by a remote processor forming a connection with one or more sensors to negotiate sensor broadcast parameters. The connection may, for example, be over a network, such as the internet, a local area network and / or an enterprise network. The sensor(s) then periodically broadcasts a data packet on a broadcast channel based on the parameters. As the data packets are broadcast openly, all devices within range of the sensor can receive the packets. The remote processor can therefore provide sensor transmission parameters to selected devices to allow them to receive the data packets. Devices without the sensor transmission parameters may be able to receive the data packets, but unable to decode them.

[0008] In some cases, this allows devices in this system to utilize the low latency of short- range communications to send and / or receive (near) real-time information without directly connecting to one another. In some cases, this means that associations between devices and patients cannot be determined by third-party observers because if a malicious party were to intercept the transmissions and could decode the information, they would have no way of knowing who the patient is and what the sensor data is being used for. If a data transmission is a one-way exchange, a malicious party is unable to communicate to the sensor.

[0009] In a first aspect the present disclosure may broadly be said to consist in a method of receiving medical data on a, or an at least one, first device, the method comprising the steps of: Receiving, from a remote processor, transmission parameters for a, or an at least one, second device configured to transmit physiological parameters; Monitoring a broadcast channel; Receiving, on the broadcast channel, at least one data packet from the second device; Determining the physiological parameters from the at least one data packet based on the transmission parameters.

[0010] In some cases the device comprises one or more of a sensor or a medical device. In some cases the sensor is a mattress sensor. In some cases the sensor is an under the mattress sensor. In some cases comprising two or more sensors. In some cases the two or more sensors comprise redundant sensors. In some cases the two or more sensors comprise two or more sensors configured to measure the same parameter. In some cases configured to combine measurements from the two or more sensors. In some cases configured to prioritise the two or more sensors. In some cases configured to received measurements from the highest priority sensor transmitting measurements. In some cases the remote processor is separate from the first and second devices. In some cases the remote processor is configured to be external to a facility in which the first and second devices are located. In some cases the remote processor comprises a server. In some cases the server is located remotely or the server is located locally. In some cases the broadcast channel comprises an advertising channel. In some cases the advertising channel is from a short-range wireless technology standard. In some cases the short-range wireless technology standard is Bluetooth™ and / or Wi-Fi ™.

[0011] In some cases comprising the step of the remote processor receiving the at least one data packet on the broadcast channel independently from the second device. In some cases the at least one data packet is received directly from the second device. In some cases the remote processor is configured to receive data packets through an intermediatory device. In some cases the intermediatory device comprises a hub or router. In some cases the intermediatory device comprises, or is a component of, a patient monitor. In some cases the patient monitor comprises a display. The display may be configured to present the received physiological parameters and / or and alarm and / or an alert. In some cases the intermediatory device comprises a converter. In some cases the converter is configured to convert between one or more of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel.

[0012] In some cases the at least one data packet is received through at least one intermediatory broadcast device. In some cases the first device receives the at least one data packet from the second device through an intermediate broadcast device. In some cases the intermediatory broadcast device comprises a converter. In some cases the converter is configured to convert between one or more of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel. In some cases the intermediate broadcast device comprises a patient monitor. In some cases the step of determining the physiological parameters comprises decrypting the at least one data packet based on the transmission parameters. In some cases the transmission parameters comprise cryptographic parameters. In some cases the cryptographic parameters comprise a private key. In some cases the private key is part of a public private key pair with the second device comprising a corresponding public key. In some cases the cryptographic parameters comprise an updating parameter. In some cases the updating parameter comprise an initialization parameter and an increment parameter. In some cases the physiological parameters comprise at least one sensitive information parameter. In some cases the transmission parameters do not include patient identification. In some cases the at least one data packet does not include patient identification.

[0013] In some cases the step of determining the physiological parameters comprises confirming the at least one data packet is relevant based on the transmission parameters. In some cases the transmission parameters comprise packet identification parameters. In some cases the packet identification parameters comprise one or more of a sensor ID, a device ID and a class ID. In some cases the first device is a medical device. In some cases the medical device is one or more of: a breathing apparatus, a respiratory apparatus, a ventilator, a positive airway pressure machine (PAP), a continuous positive airway pressure (CPAP) machine or a high-flow therapy machine. In some cases the medical device is configured to adjust an operational parameter dependent on the physiological parameters. In some cases the second device comprises a sensor. In some cases the sensor is associated with, or part of, a medical device.

[0014] In some cases comprising the step of receiving further physiological parameters from the remote processor. In some cases the further physiological parameters comprise historic physiological parameters. In some cases comprising the step of requesting, from the remote processor, the further physiological parameters. In some cases comprising the step ofdetermining combined physiological parameters by combining the physiological parameters with physiological parameters determined on the first device. In some cases combined physiological parameters comprise a parameter index. In some cases the parameter index comprises a ROX index. In some cases the parameter index is represented as a vector. In some cases comprising the step of broadcasting the combined physiological parameters. In some cases the broadcast is on one or more of the broadcast channel and a second broadcast channel. In some cases comprising the step of requesting, from the remote processor, the transmission parameters. In some cases comprising the step of requesting, from the remote processor, an update to the transmission parameters. In some cases the update is requested when the physiological parameters cannot be determined from the at least one data packet by the first device. In some cases the second device is not aware of the first device. In some cases the remote processor is not required for ongoing receiving of data packets.

[0015] In a further aspect the present disclosure may broadly be said to consist in a medical device configured to: Receive, from a remote processor, transmission parameters for a first sensor configured to transmit physiological parameters; Monitor a broadcast channel; Receive, on the broadcast channel, at least one data packet from the first sensor; Determine the physiological parameters from the at least one data packet based on the transmission parameters. In some cases the remote processor is separate from the first sensor and medical device. In some cases the remote processor is configured to be external to a facility in which the first and second devices are located. In some cases the remote processor comprises a server. In some cases the server is located remotely or the server is located locally. In some cases the broadcast channel comprises an advertising channel. In some cases the advertising channel is from a short-range wireless technology standard. In some cases the short-range wireless technology standard is Bluetooth™ and / or Wi-Fi™.

[0016] In some cases the medical device is configured to concurrently or alternatively receiving the at least one data packet via the remote processor. In some cases the medical device is configured to receive the at least one data packet directly from the second device. In some cases the medical device is configured to receive the at least one data packet is received through at least one intermediatory broadcast device. In some cases the intermediatory broadcast device comprises a converter. In some cases the converter is configured to convert between one or more of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel. In some cases the step of determining thephysiological parameters comprises decrypting the at least one data packet based on the transmission parameters. In some cases the transmission parameters comprise cryptographic parameters. In some cases the cryptographic parameters comprise a private key. In some cases the private key is part of a public private key pair with the second device comprising a corresponding public key. In some cases the cryptographic parameters comprise an updating parameter. In some cases the updating parameter comprise an initialization parameter and an increment parameter. In some cases the physiological parameters comprise at least one sensitive information parameter. In some cases the transmission parameters do not include patient identification. In some cases the at least one data packet does not include patient identification. In some cases determining the physiological parameters comprises confirming the at least one data packet is relevant based on the transmission parameters.

[0017] In some cases the transmission parameters comprise packet identification parameters. In some cases the packet identification parameters comprise one or more of a sensor ID, a device ID and a class ID. In some cases the medical device is one or more of: a breathing apparatus, a respiratory apparatus, a ventilator, a positive airway pressure machine (PAP), a continuous positive airway pressure (CPAP) machine or a high-flow therapy machine.

[0018] In some cases the medical device configured to adjust an operational parameter dependent on the physiological parameters. In some cases the first sensor is associated with, or part of, a second medical device. In some cases the medical device is configured to receive further physiological parameters from the remote processor. In some cases the further physiological parameters comprise historic physiological parameters. In some cases configured to request, from the remote processor, the further physiological parameters. In some cases configured to determine combined physiological parameters by combining the physiological parameters with physiological parameters determined on the medical device. In some cases configured to broadcast the combined physiological parameters. In some cases the broadcast is on one or more of the broadcast channel and a second broadcast channel.

[0019] In some cases configured to request, from the remote processor, the transmission parameters. In some cases configured to request, from the remote processor, an update to the transmission parameters. In some cases the update is requested when the physiological parameters cannot be determined from the at least one data packet. In some cases the medical device does not connect to the first sensor. In some cases the medical device is configured not to required connection to the remote processor for ongoing receiving of data packets. In somecases configured to receive data packets from a plurality of sensors by the same method as the first sensor. In some cases the sensor is a mattress sensor. In some cases the sensor is an under the mattress sensor. In some cases comprising two or more sensors. In some cases configured to communicate with the remote processor through an intermediatory device.

[0020] In a further aspect the present disclosure may broadly be said to consist in a messaging system for physiological parameters, the system comprising: At least one first device configured to transmit physiological parameters on a broadcast channel; At least one second device configured to: connect to a remote processor, receive transmission parameters from the remote processor; receive at least one data packet from a broadcast channel, determine the at least one data packet is associated with the at least one first device based on the transmission parameters; and determine the physiological parameters based on the at least one data packet.

[0021] In some cases the first device is a sensor. In some cases the second device is a medical device. In some cases the sensor is a mattress sensor. In some cases the sensor is an under the mattress sensor. In some cases comprising two or more sensors. In some cases the two or more sensors comprise redundant sensors. In some cases the two or more sensors comprise two or more sensors configured to measure the same parameter. In some cases configured to combine measurements from the two or more sensors. In some cases configured to prioritise the two or more sensors. In some cases configured to received measurements from the highest priority sensor transmitting measurements. In some cases comprising a remote processor configured to connect to the at least one first device and provide sensor broadcasting parameters to the at least one first device. In some cases the remote processor is configured to connect to the at least one second device and provide the transmission parameters. In some cases the remote processor is separate from the first and second devices. In some cases the remote processor is configured to be external to a facility in which the first and second devices are located. In some cases the remote processor comprises a server. In some cases the server is located remotely or the server is located locally.

[0022] In some cases the remote processor is configured to monitor the data transmission. In some cases the remote processor is configured to determine an error and / or anomaly in the data transmission. In some cases the remote processor is configured to perform a response action if an error and / or anomaly is determined. In some cases the response action comprises one of more alerts and / or alarms. In some cases the response action comprises a hierarchy of alerts and / or alarms. In some cases an alert and / or alarm is selected from the hierarchy basedon a predetermined duration of the error and / or anomaly. In some cases an alert and / or alarm is selected from the hierarchy based on the sensor which has caused the error and / or anomaly.

[0023] In some cases the at least one first device is one or more of a sensor or a medical device. In some cases the at least one second device is one or more of a sensor or a medical device. In some cases the broadcast channel comprises an advertising channel. In some cases the advertising channel is from a short-range wireless technology standard. In some cases the short-range wireless technology standard is Bluetooth™. In some cases comprising the step of the remote processor receiving the at least one data packet on the broadcast channel independently from the first device. In some cases the at least one data packet is received directly from the first device. In some cases the at least one data packet is received through at least one intermediatory broadcast device (or intermediatory broadcaster) between the first and second devices. In some cases the intermediatory broadcast device comprises a converter. In some cases the converter is configured to convert between one or more of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel. In some cases the intermediatory broadcast device comprises a patient monitor.

[0024] In some cases determining the physiological parameters comprises decrypting the at least one data packet based on the transmission parameters. In some cases the transmission parameters comprise cryptographic parameters. In some cases the cryptographic parameters comprise a private key. In some cases the private key is part of a public private key pair with the second device comprising a corresponding public key. In some cases the cryptographic parameters comprise an updating parameter. In some cases the updating parameter comprise an initialization parameter and an increment parameter. In some cases the physiological parameters comprise at least one sensitive information parameter. In some cases the transmission parameters do not include patient identification. In some cases the at least one data packet does not include patient identification.

[0025] In some cases determining the physiological parameters comprises confirming the at least one data packet is relevant based on the transmission parameters. In some cases the transmission parameters comprise packet identification parameters. In some cases the packet identification parameters comprise one or more of a sensor ID, a device ID and a class ID. In some cases one or more of the first device and the second device is a medical device. In some cases the medical device is one or more of: a breathing apparatus, a respiratory apparatus, aventilator, a positive airway pressure machine (PAP), a continuous positive airway pressure (CPAP) machine or a high-flow therapy machine. In some cases the medical device is configured to adjust an operational parameter dependent on the physiological parameters. In some cases the second device comprises a sensor. In some cases the sensor is associated with, or part of, a medical device. In some cases the second device is configured to receive further physiological parameters from the remote processor. In some cases the further physiological parameters comprise historic physiological parameters. In some cases the second device is configured to request, from the remote processor, the further physiological parameters.

[0026] In some cases the at least one first device and / or the at least one second device are configure to connect to the remote processor through an intermediatory device. In some cases the intermediatory device comprises a hub or router. In some cases the intermediatory device comprises, or is a component of, a patient monitor. In some cases the patient monitor comprises a display. The display may be configured to present the received physiological parameters and / or and alarm and / or an alert. In some cases the intermediatory device comprises a converter. In some cases the converter is configured to convert between one or more of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel.

[0027] In some cases the second device is configured to determine combined physiological parameters by combining the physiological parameters with physiological parameters determined on the first device. In some cases the second device is configured to broadcast the combined physiological parameters. In some cases the broadcast is on one or more of the broadcast channel and a second broadcast channel. In some cases the second device is configured to request, from the remote processor, the transmission parameters. In some cases the second device is configured to request from the remote processor, an update to the transmission parameters. In some cases the update is requested when the physiological parameters cannot be determined from the at least one data packet by the first device. In some cases the first device is not aware of the second device. In some cases the remote processor is not required for ongoing receiving of the one or more data packets. In some cases the remote processor is configured to monitor the status of one or more of the first and second devices. In some cases the remote processor is configured to update one or more of the transmission parameters and the broadcast parameters based on the monitored status. In some cases the remote processor is configured to receive the data packets on the broadcast channelconcurrently with the second device. In some cases the remote processor is configured to store one or more associations between a patient and the at least one first and second devices. In some cases comprising a plurality of first devices and a plurality of second devices each associated with one of a plurality of patients, wherein the remote processor is configured to authorize physiological parameters being passed between patients.

[0028] In a further aspect the present disclosure may broadly be said to consist in a method of messaging between at least one first device and at least one second device, the method comprising the steps of: The at least one first device transmitting physiological parameters on a broadcasting channel; The at least one second device receiving sensor transmission parameters from a remote processor; and The at least one second device determining the physiological parameters transmitted by the at least one first device based on the sensor transmission parameters.

[0029] In some cases the first device is a sensor. In some cases the sensor is a mattress sensor. In some cases the sensor is an under the mattress sensor. In some cases comprising two or more sensors. In some cases the two or more sensors comprise redundant sensors. In some cases the second device is a medical device. In some cases comprising the remote processor, the remote processor configured to connect to the at least one first device and provide sensor broadcasting parameters to the at least one first device. In some cases the remote processor is configured to connect to the at least one second device and provide the transmission parameters. In some cases the remote processor is separate from the first and second devices. In some cases the remote processor is configured to be external to a facility in which the first and second devices are located. In some cases the remote processor comprises a server. In some cases the server is located remotely, or the server is located locally. In some cases connection to the server is configured through an intermediatory device. In some cases the at least one first device is one or more of a sensor or a medical device. In some cases the at least one second device is one or more of a sensor or a medical device.

[0030] In some cases the broadcast channel comprises an advertising channel. In some cases the advertising channel is from a short-range wireless technology standard. In some cases the short-range wireless technology standard is Bluetooth™. In some cases comprising the step of the remote processor receiving the at least one data packet on the broadcast channel independently from the first device. In some cases the at least one data packet is received by the second device directly from the first device. In some cases the at least one datapacket is through at least one intermediatory broadcast device (or intermediately broadcaster) between the first and second devices. In some cases the intermediatory broadcast device comprises a converter. In some cases the converter is configured to convert between one or more of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel. In some cases the intermediate broadcast device comprises a patient monitor. In some cases determining the physiological parameters comprises decrypting the at least one data packet based on the transmission parameters. In some cases the transmission parameters comprise cryptographic parameters. In some cases the cryptographic parameters comprise a private key. In some cases the private key is part of a public private key pair with the second device comprising a corresponding public key. In some cases the cryptographic parameters comprise an updating parameter. In some cases the updating parameter comprise an initialization parameter and an increment parameter. In some cases the physiological parameters comprise at least one sensitive information parameter.

[0031] In some cases the transmission parameters do not include patient identification. In some cases the at least one data packet does not include patient identification. In some cases determining the physiological parameters comprises confirming the at least one data packet is relevant based on the transmission parameters. In some cases the transmission parameters comprise packet identification parameters. In some cases the packet identification parameters comprise one or more of a sensor ID, a device ID and a class ID. In some cases one or more of the first device and the second device is a medical device. In some cases the medical device is one or more of: a breathing apparatus, a respiratory apparatus, a ventilator, a positive airway pressure machine (PAP), a continuous positive airway pressure (CPAP) machine or a high-flow therapy machine. In some cases the medical device is configured to adjust an operational parameter dependent on the physiological parameters. In some cases the second device comprises a sensor. In some cases the sensor is associated with, or part of, a medical device.

[0032] In some cases the second device is configured to receive further physiological parameters from the remote processor. In some cases the further physiological parameters comprise historic physiological parameters. In some cases the second device is configured to request, from the remote processor, the further physiological parameters. In some cases the second device is configured to determine combined physiological parameters by combining the physiological parameters with physiological parameters determined on the first device. In some cases the second device is configured to broadcast the combined physiologicalparameters. In some cases the broadcast is on one or more of the broadcast channel and a second broadcast channel. In some cases the second device is configured to request, from the remote processor, the transmission parameters.

[0033] In some cases the second device is configured to request from the remote processor, an update to the transmission parameters. In some cases the update is requested when the physiological parameters cannot be determined from the at least one data packet by the first device. In some cases the first device is not aware of the second device. In some cases the remote processor is not required for ongoing receiving of the one or more data packets. In some cases the remote processor is configured to monitor the status of one or more of the first and second devices. In some cases the remote processor is configured to update one or more of the transmission parameters and the broadcast parameters based on the monitored status. In some cases the remote processor is configured to receive the data packets on the broadcast channel concurrently with the second device. In some cases the remote processor is configured to store one or more associations between a patient and the at least one first and second devices. In some cases comprising a plurality of first devices and a plurality of second devices each associated with one of a plurality of patients, wherein the remote processor is configured to authorize physiological parameters being passed between patients.

[0034] In a further aspect the present disclosure may broadly be said to consist in a method for a remote processor to authorizing transmission of medical data between an at least one first device and an at least one second device, the method comprising the steps of: Determining sensor broadcast parameters for at least one first device configured to broadcast physiological parameters; Transmitting the sensor broadcast parameters to the at least one first device; Determining at least one second device to receive the physiological parameters; Transmitting, to the at least one second device, transmission parameters, wherein the transmission parameters allow the at least one second device to determine the physiological parameters broadcast by the at least one first device.

[0035] In some cases the at least one first device is a sensor. In some cases the sensor is a mattress sensor. In some cases the sensor is an under the mattress sensor. In some cases comprising two or more sensors. In some cases the two or more sensors comprise redundant sensors. In some cases the second device is a medical device. In some cases the remote processor is configured to connect to the at least one first device and provide sensor broadcasting parameters to the at least one first device. In some cases the remote processoris configured to connect to the at least one second device and provide the transmission parameters. In some cases the remote processor is separate from the first and second devices. In some cases the remote processor is configured to be external to a facility in which the first and second devices are located. In some cases the remote processor comprises a server. In some cases the server is located remotely, or the server is located locally.

[0036] In some cases wherein the broadcast parameters are associated with a broadcast channel. In some cases the broadcast channel comprises an advertising channel. In some cases the advertising channel is from a short-range wireless technology standard. In some cases the short-range wireless technology standard is Bluetooth™. In some cases comprising the step of the remote processor independently from the second device receiving at least one data packet from the first device using the transmission parameters. In some cases the sensor broadcast parameters and the transmission parameters allow at least one data packet to be received by the second device directly from the first device. In some cases the at least one data packet is through at least one intermediatory broadcast device (or intermediatory broadcaster) between the first and second devices.

[0037] In some cases determining the physiological parameters comprises decrypting the at least one data packet based on the transmission parameters. In some cases the transmission parameters comprise cryptographic parameters. In some cases the cryptographic parameters comprise a private key. In some cases the private key is part of a public private key pair with the second device comprising a corresponding public key. In some cases the cryptographic parameters comprise an updating parameter. In some cases the updating parameter comprise an initialization parameter and an increment parameter. In some cases the physiological parameters comprise at least one sensitive information parameter. In some cases the transmission parameters do not include patient identification. In some cases the at least one data packet does not include patient identification. In some cases determining the physiological parameters comprises confirming the at least one data packet me based on the transmission parameters. In some cases the transmission parameters comprise packet identification parameters. In some cases the packet identification parameters comprise one or more of a sensor ID, a device ID and a class ID.

[0038] In some cases one or more of the first device and the second device is a medical device. In some cases the medical device is one or more of: a breathing apparatus, a respiratory apparatus, a ventilator, a positive airway pressure machine (PAP), a continuous positive airwaypressure (CPAP) machine or a high-flow therapy machine. In some cases the medical device is configured to adjust an operational parameter dependent on the physiological parameters. In some cases the second device comprises a sensor. In some cases the sensor is associated with, or part of, a medical device. In some cases the remote processor is configured to transmit further physiological parameters to the second device. In some cases the further physiological parameters comprise historic physiological parameters. In some cases the remote processor is configured to receive a request, from the second device, for the further physiological parameters. In some cases the remote processor is configured to receive a request, from the second device, for the transmission parameters and / or an update to the transmission parameters. In some cases the first device is not aware of the second device. In some cases the remote processor is not required for ongoing receiving of the one or more data packets.

[0039] In some cases the remote processor is configured to monitor the status of one or more of the first and second devices. In some cases the remote processor is configured to update one or more of the transmission parameters and the broadcast parameters based on the monitored status. In some cases the remote processor is configured to receive the data packets on the broadcast channel concurrently with the second device. In some cases the remote processor is configured to store one or more associations between a patient and the at least one first and second devices. In some cases comprising a plurality of first devices and a plurality of second devices each associated with one of a plurality of patients, wherein the remote processor is configured to authorize physiological parameters being passed between patients. In some cases the remote processor is configured to monitor physiological parameters received from the at least one first device and physiological parameters received from the at least one second device and determine that the second device is receiving physiological parameters correctly.

[0040] In a further aspect the present disclosure may broadly be said to consist in a remote processor configured to authorizing transmission of medical data between at least one first device and at least one second, by: Determining sensor broadcast parameters for the at least first device configured to broadcast physiological parameters; Transmitting the sensor broadcast parameters to the at least one first device; Determining at least one second device to received the physiological parameters; Transmitting to the at least one second device transmission parameters, wherein the transmission parameters allow the at least one second device to determine physiological parameters broadcast by the at least one first device.

[0041] In some cases the first device is a sensor. In some cases the sensor is a mattress sensor. In some cases the sensor is an under the mattress sensor. In some cases comprising two or more sensors. In some cases the two or more sensors comprise redundant sensors. In some cases the second device is a medical device. In some cases the remote processor is configured to connect to the at least one first device and provide sensor broadcasting parameters to the at least one first device. In some cases the remote processor is configured to connect to the at least one second device and provide the transmission parameters. In some cases the remote processor is separate from the first and second devices. In some cases the remote processor is configured to be external to a facility in which the first and second devices are located. In some cases the remote processor comprises a server. In some cases the server is located remotely, or the server is located locally. In some cases wherein the broadcast parameters are associated with a broadcast channel. In some cases the broadcast channel comprises an advertising channel. In some cases the advertising channel is from a short-range wireless technology standard. In some cases the short-range wireless technology standard is Bluetooth™.

[0042] In some cases the remote processor is configured to, independently from the second device, receive at least one data packet from the first device using the transmission parameters. In some cases the sensor broadcast parameters and the transmission parameters allow at least one data packet to be received by the second device directly from the first device. In some cases the at least one data packet is through at least one intermediatory broadcast device (or intermediatory broadcaster) between the first and second devices. In some cases determining the physiological parameters comprises decrypting the at least one data packet based on the transmission parameters. In some cases the transmission parameters comprise cryptographic parameters. In some cases the cryptographic parameters comprise a private key. In some cases the private key is part of a public private key pair with the second device comprising a corresponding public key. In some cases the cryptographic parameters comprise an updating parameter. In some cases the updating parameter comprise an initialization parameter and an increment parameter. In some cases the physiological parameters comprise at least one sensitive information parameter. In some cases the transmission parameters do not include patient identification. In some cases determining the physiological parameters comprises confirming the at least one data packet is relevant based on the transmission parameters.

[0043] In some cases the transmission parameters comprise packet identification parameters. In some cases the packet identification parameters comprise one or more of a sensor ID, a device ID and a class ID. In some cases one or more of the first device and the second device is a medical device. In some cases the medical device is one or more of: a breathing apparatus, a respiratory apparatus, a ventilator, a positive airway pressure machine (PAP), a continuous positive airway pressure (CPAP) machine or a high-flow therapy machine. In some cases the medical device is configured to adjust an operational parameter dependent on the physiological parameters. In some cases the second device comprises a sensor. In some cases the sensor is associated with, or part of, a medical device. In some cases the remote processor is configured to transmit further physiological parameters to the second device. In some cases the further physiological parameters comprise historic physiological parameters. In some cases the remote processor is configured to receive a request, from the second device, for the further physiological parameters.

[0044] In some cases the remote processor is configured to receive a request, from the second device, for the transmission parameters and / or an update to the transmission parameters. In some cases the first device is not aware of the second device. In some cases remote processor is not required for ongoing receiving of the one or more data packets. In some cases the remote processor is configured to allow ongoing transmission of data packets directly between the first device and second device. In some cases the remote processor is configured to monitor the status of one or more of the first and second devices. In some cases the remote processor is configured to update one or more of the transmission parameters and the broadcast parameters based on the monitored status.

[0045] In some cases the remote processor is configured to receive the data packets on the broadcast channel concurrently with the second device. In some cases the remote processor is configured to store one or more associations between a patient and the at least one first and second devices. In some cases comprising a plurality of first devices and a plurality of second devices each associated with one of a plurality of patients, wherein the remote processor is configured to authorize physiological parameters being passed between patients. In some cases the remote processor is configured to monitor physiological parameters received from the at least one first device and physiological parameters received from the at least one second device and determine that the second device is receiving physiological parameters correctly.

[0046] In a further aspect the present disclosure may broadly be said to consist in a messaging system comprising a remote processor configured to: Initialize broadcast parameters with at least one first device; Initialize transmission parameters configured to allow receipt of data packets transmitted the broadcast parameters with an at least one second device; Wherein the first device and the second device are able to directly communicate on a broadcast channel based on the broadcast parameters and the transmission parameters.

[0047] In some cases the remote processor does not act as an intermediatory for data packets on the broadcast channel. In some cases the at least one first device is a sensor. In some cases the sensor is a mattress sensor. In some cases the sensor is an under the mattress sensor. In some cases comprising two or more sensors. In some cases the two or more sensors comprise redundant sensors. In some cases the two or more sensors comprise two or more sensors configured to measure the same parameter. In some cases configured to combine measurements from the two or more sensors. In some cases configured to prioritise the two or more sensors. In some cases configured to received measurements from the highest priority sensor transmitting measurements.

[0048] In some cases the at least one second device is a medical device. In some cases the remote processor is configured to initialize broadcast parameters by connecting to the at least one first device and providing sensor broadcasting parameters to the at least one first device. In some cases the remote processor is configured to initialize transmission parameters by connecting to the at least one second device and providing the transmission parameters. In some cases the remote processor is configured to disconnect from one or more of the at least one first and at least one second devices after initialization. In some cases the remote processor is configured to monitor one or more of the at least one first and at least one second devices after initialization. In some cases the remote processor is configured to confirm the receipt and / or accuracy of data received by the at least one second device. In some cases the at least one first device communicates on a broadcast channel received by the at least one second device. In some cases the first device is not aware of the communication being received by the at least one second device. In some cases the communication is on a broadcast channel. In some cases the data packets are received through at least one intermediatory broadcast device. In some cases the first device receives the at least one data packet from the second device through an intermediate broadcast device. In some cases the intermediatory broadcast device comprises a converter. In some cases the converter is configured to convert between one ormore of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel. In some cases the intermediate broadcast device comprises a patient monitor

[0049] In some cases the remote processor is configured to receive data packets through an intermediatory device. In some cases the intermediatory device comprises a hub or router. In some cases the intermediatory device comprises, or is a component of, a patient monitor. In some cases the patient monitor comprises a display. The display may be configured to present the received physiological parameters and / or and alarm and / or an alert. In some cases the intermediatory device comprises a converter. In some cases the converter is configured to convert between one or more of: a data type; a data format; a communication protocol; a data security level; a data encoding and / or a broadcast channel.

[0050] In a further aspect the present disclosure may broadly be said to consist in a messaging system comprising a remote processor configured to: Initialize broadcast parameters on an at least one first device; Initialize transmission parameters configured to receive the broadcast parameters on an at least one second device; Wherein the first device and the second device form a private network independent from the remote processor.

[0051] In some cases the remote processor does not act as an intermediatory for data packets on the private network. In some cases the first device is a sensor. In some cases the second device is a medical device. In some cases the remote processor is configured to initialize broadcast parameters by connecting to the at least one first device and providing sensor broadcasting parameters to the at least one first device. In some cases the remote processor is configured to initialize transmission parameters by connecting to the at least one second device and providing the transmission parameters. In some cases the remote processor is configured to disconnect from one or more of the first and second devices after initialization. In some cases the remote processor is configured to monitor one or more of the first and second devices after initialization. In some cases the remote processor is configured to confirm the receipt and / or accuracy of data received by the second device. In some cases the private network comprises a broadcast channel on which the first device communicates data packets channel received by the second device. In some cases the first device is not aware of the communication being received by the second device. In some cases the private network is encrypted by parameters in the broadcast parameters and transmission parameters. In some cases further devices can receive communications on the private network but are unable todecode the data packets until initialized with transmission parameters from the remote processor.

[0052] In a further aspect the present disclosure may broadly be said to consist in a messaging system comprising: A first communication channel between a remote processor and one or more first devices, the first communication channel configured to initialize broadcast parameters of the first devices; A second communication channel between the remote processor and one or more second devices, the first communication channel configured to initialize transmission parameters configured to allow the second devices to receive the broadcast parameters; A broadcast communication channel providing for the communication between the one or more first devices and the one or more second devices, as configured by the first and second communication channel.

[0053] In some cases the configuration of the broadcast communication channel is independently negotiated by the remote processor with the first device, and the second device. In some cases the remote processor does not act as an intermediatory for data packets on the broadcast communication channel. In some cases the first device comprises a sensor. In some cases the second device comprises a medical device. In some cases the remote processor is configured to connect to the one or more first devices on the first communication channel. In some cases the remote processor is configured connect to the one or more second devices on the second communication channel. In some cases the remote processor is configured to disconnect from one or more of the first and second communication channels after initialization. In some cases the remote processor is configured to monitor one or more of the first and second communication channels after initialization. In some cases the remote processor is configured to confirm the receipt and / or accuracy of data packets received by the second device. In some cases the first device is not aware of the broadcast communication being received by the second device. In some cases the broadcast communication channel is encrypted based on parameters in the broadcast parameters and transmission parameters. In some cases further devices can receive communications on the broadcast communication channel but are unable to decode the communications until initialized with the transmission parameters from the remote processor.

[0054] 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.

[0055] Features from one or more aspects or configurations may be combined with features of one or more other aspects or configurations.

[0056] As used herein the term "(s)" following a noun means the plural and / or singular form of that noun.

[0057] As used herein the term "and / or" means "and" or "or", or where the context allows both.

[0058] 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 orthose prefaced by the term may also be present. Related terms such as "comprise" and "comprises" are to be interpreted in the same manner.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] The disclosure consists in the foregoing and also envisages constructions of which the following gives examples only.BRIEF DESCRIPTION OF THE DRAWINGS

[0063] 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:

[0064] Figure 1 illustrates a patient monitoring system in accordance with an aspect of the present disclosure.

[0065] Figure 2 illustrates a pre-processing server portion of the patient monitoring system in accordance with an aspect of the present disclosure.

[0066] Figure 3 illustrates a post-processing server portion of the patient monitoring system in accordance with an aspect of the present disclosure.

[0067] Figure 4 is a flow diagram illustrating a method performed at the router in accordance with an aspect of the present disclosure.

[0068] Figure 5 is a flow diagram illustrating a method in accordance with an aspect of the present disclosure.

[0069] Figure 6 is a flow diagram illustrating a method in accordance with an aspect of the present disclosure.

[0070] Figure 7 illustrates a system arrangement for data transfer between a sensor and a medical device.

[0071] Figure 8 illustrates a system arrangement for data transfer between a sensor and a medical device.

[0072] Figure 9 is an information flow diagram showing the connection of a sensor and medical device by a remote processor.

[0073] Figure 10 is an information flow diagram showing the disconnection of a sensor and medical device by a remote processor.

[0074] Figure 11 is an information flow diagram showing the connection of a sensor and medical device by a remote processor, with the remote processor then removed from the network.

[0075] Figure 12 is an information flow diagram showing the connection of a sensor and medical device by a remote processor with a repeater.

[0076] Figure 13 is an information flow diagram showing the connection of a sensor and multiple medical devices by a remote processor.

[0077] Figure 14 illustrates an example data packet.

[0078] Figure 15 shows a patient monitor comprising a router.

[0079] Figure 16 shows a patient monitor acting as an intermediatory broadcast device.

[0080] Figure 17 shows an intermediatory device and an intermediatory broadcast device comprising converters.DETAILED DESCRIPTION

[0081] 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.

[0082] 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.

[0083] In some cases, the system is applied in a patient monitoring environment. One suitable patient monitoring environment is described in PCT / IB2023 / 061350 (published as W02024100606A1 ), incorporated herein by reference. However other patient monitoring environments may also be used.

[0084] Figure 1 shows a system that provides forthe 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, hospice, end of life facility, other medical facility,or a home. Aspects of the 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 intermediatory device, shown as a router and / or hub 30. The terms hub and router may be used interchangeably to refer, at least, to an intermediatory device configured to receive wireless communications from sensors and transmit communications to a server.

[0085] The sensors 20 may include patient worn sensors, sensors mounted to objects associated with the patient (such as a pillow or sheet), 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 20, 22 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. The system may also communicate with a surgical humidifier or other gas delivery or gas conditioning devices used in surgery or anesthetic procedures or sedation procedures. The sensors 20 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. In some cases, respiratory health is monitored by respiratory rate and blood oxygen levels. In some cases, these may be measured or inferred from one or more of respiratory rate (RR), heart rate (HR), and SpO2. 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. The therapy device may receive data from multiple sensors 20, 22.

[0086] 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 20, 22 (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., onlyavailable 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).

[0087] 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, in some case the raw sensor data is processed at the server, and only the server processing and / or handlers need to be adjusted or customised to change the system and / or method.

[0088] 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 selfreporting from patients and significantly supplementing periodic vital sign measurements. In turn, this 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 expectedto 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.

[0089] 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 and / or shared between devices. 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 a broadcast channel, such as advertising channels of a short-range wireless communication protocol (e.g., Bluetooth™, or Zigbee™).

[0090] 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. The data may be encoded and / or encrypted. 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.

[0091] 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 electronicmedical file and optionally displayed on a screen as part of patient monitor hardware either in a hospital or home environment.

[0092] In some cases, the plurality of sensors 20, 22 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.

[0093] In some cases, the plurality of sensors 20 comprise one or more of a respiratory rate sensor, a temperature sensor, a blood pressure sensor, a heart rate sensor, a heart rate variability sensor, a CO2 (carbon di-oxide) sensor to measure CO2 in exhaled air, a CO2 sensor to measure CO2 in blood, an 02 (oxygen) sensor to measure CO2 in blood, an FiO2 sensor, a pulse oximetry sensor, and a SpO2 sensor. In some cases, the plurality of sensors 20 are configured to measure and / or transmit an index. An index is a combination of one or more measurements. For example, an index may comprise a combination of heart rate and respiratory rate, or respiratory rate and oxygen saturation. An example index is ROX index. ROX index is a combination of oxygen saturation (optionally measured by pulse oximetry / oxygen fraction (FiO2)) and respiratory rate. In some cases, the sensor may provide a vector output of the sensed parameter and / or index. The vector output comprises a magnitude and direction. The direction may indicate a trend in the parameter.

[0094] The plurality of sensors may be provided in the form of one or more wearable sensors mountable to the patient. The plurality of sensors may comprise one or more sensors configured to measure a physiological parameter. The plurality of sensors may comprise one or more sensors configured to measure a biometric parameter. The plurality of sensors may comprise one or more biometric sensors. In some cases, the plurality of sensors 20 may include one or more sensors associated with (e.g., provided in, on, or under) an item of furniture. For example, under the mattress of a bed (such as 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 plurality of sensors 20 may comprise one or more non-contact sensors. The non-contact sensors may be located on the patient and / or associated with (e.g. in or on or underneath) one or more objects associated with the patient. Example objects include patient clothing, patient bed or chair linen and patient supports. For example, the non-contact sensors may be located in a mattress oron a patient pillow. 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.

[0095] The plurality of sensors 20 may comprise one or more redundant sensors. One or more of the sensors 20 may measure the same, or a related parameter, to at least one of the other sensors. The presence of redundant sensors 20 allows measurement to be maintained if missing values occur and / or sensor errors. In some cases, redundant sensors 20 allow a comparison between sensors 20. In some cases, one or more of the redundant sensors 20 have a different association with the patient. For example, a first sensor may be associated with furniture (e.g., a mattress) associated with the patient, a second sensor may be worn by the patient and a third sensor may be associated with an item of clothing of the patient. When the patient is on the mattress all sensors 20 may provide measurements. However, if the patient moves away from the bed the mattress sensor may stop providing accurate data. The system may instead collect data from the patient worn sensor or clothing sensor. If, for example, the patient enters the shower, only the patient worn sensor may provide a reading. In this way the system can ensure measurements in different situations due to the redundant sensors. The system may be particularly advantageous for under mattress sensors. This is because the system allows for continuous transmission of data from these sensors without requiring the patient bed to be wired. In some cases the system is also able to accommodate changes or disruption in received signals due to movement of the patient and / or mattress.

[0096] Where multiple measurements are received the system and / or medical devices may be configured to average measured results or prioritise some measurements. For example, the system and / or device may be 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. The system or each medical device (or router / remote processor) may prioritise measurements from selected and / or trusted sensors 20. In some cases a primary sensor may be identified. For example, the primary sensor may be an under (or in) mattress sensor. The primary sensor may be the preferred sensor for measurements. The accuracy and reliability of sensors 20 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 prioritisingsensors which are more accurate the performance of system or devices is improved due to more accurate data being available.

[0097] In some cases, the system, remote processor and / or each medical device obtains a rating (e.g., a rating of the sensor's 20 accuracy, ortrust in the sensor's 20 value) of each sensor 20. The rating may be provided in the signal from the sensor 20 or may be obtained from the remote processor, 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 20 having the highest score can then be used to determine the most accurate sensor value. Where multiple sensors 20 are available the remote processor or medical device may also monitor the accuracy of a less accurate sensor 20. 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.

[0098] The plurality of sensors 20 may be 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.

[0099] As discussed above, in an aspect of the present technology, the data transmission from the plurality of sensors 20, 22 (to the router 30 or other devices) 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). Wi-Fi™ and its advertising data packets may also or alternatively be used. 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, or other devices without requiring the router 30 or other devices to pair with each of the plurality of sensors 20. Accordingly, the router 30 or other devices do not need to maintain individual connections with each sensor in the plurality of sensors 20. This allowsthe 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.

[0100] The transmission of sensor data between the plurality of sensors 20 and router 30 or other devices 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™ MAC address / UUlD 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.

[0101] In some cases the wireless hub or router 30 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.

[0102] In some cases the sensor data is sent as a continuous stream of data. In some cases, the sensor data is sent at fixed intervals. In an alternative the sensor data is encoded and sent as soon as new and / or updated data has been generated by the sensor(s) 20 such that bandwidth is not taken up transmitting an unchanged sensor reading. In a further aspect thetransmission of sensor data is promoted by a pull notification from the router 30. In one example, the transmission of sensor data is performed in real-time. In one example 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.

[0103] In an aspect, the router 30 (or other intermediatory device) 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.

[0104] 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. In one aspect, the router 30 is provided by a Cassia™ X2000, X1000, E1000 Bluetooth™ enterprise Bluetooth™ router, or similar device.

[0105] 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.

[0106] In an example, 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 centralclock, 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.

[0107] The sensor data is then passed on to a dispatcher 60 which is configured to determine the source device and / orthe 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 / UUlD 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.

[0108] 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.

[0109] 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 processedcentrally by the processing server 40, there is no need to update the router or sensor software to adapt to changes in the system 10.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] Additional handlers 70 and containers 72 can be instanced as sensor data is received from additional sensors of the plurality of sensors 20.

[0114] In an aspect, the drivers 71 are accessed directly by the dispatcher 60 without the use of dedicated handlers 70.

[0115] 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.

[0116] The parameterised data is then added to the patient's electronic medical record. The parameterised data is further passed to an event handler 1 10 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.

[0117] 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 server40. 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.

[0118] 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 server40, 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.

[0119] In at least one example, when one of more sensor(s) 20 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) 20. 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.

[0120] 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.

[0121] Figure 2 depicts an aspect in which in addition to receiving sensor data from the plurality of sensors 20, the router 30 (as an example intermediatory device) is also configured to receive data regarding the therapy being provided to the patient by one or more medical devices 200. In one example, a medical device 200 is a respiratory therapy device or a respiratory support device. In one example, 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 may have a flow generator, humidifier, tube and a patient interface. The respiratory therapy device 200 may have sensors to record various therapy parameters such as flow, pressure, temperature, humidity. The device 200 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.

[0122] In an aspect, the sensors 20, 22 may comprise a haemoglobin composition sensor and an under the mattress sensor. The under the mattress sensor 22 may sense respiratory rate and / or heart rate.

[0123] 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 02 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 an intermediatory device, such as 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.

[0124] The processing server 40 is operational to process the received therapy data in the same manner as the received sensor data described above.

[0125] Figure 3 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.

[0126] Figure 4 shows a process performed by an intermediatory device, such as router 30. At step S1 10 the router scans radio bands for any transmissions. At step S120, a determination is made as to whether any transmissions are incoming, such a transmission of sensor data fromone or more of the plurality of sensors 20, 22. In an aspect, the router 30 is configured to scan for any known sensors 20, 22 registered against the patient. In a further aspect, the router 30 is able to discover newly added sensors 20, 22 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.

[0127] Figure 5 shows a process performed at the dispatcher 60 of the processing server 40. At step S210 the transmission related from the intermediatory device, such as 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.

[0128] Figure 6 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, 22 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-termi nates at step S370. In one aspect, the handler will terminateimmediately 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-termi nates.

[0129] 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.

[0130] In some cases, a patient monitoring system, such as patient monitoring system 10, may need to transmit data between sensors 20 and other devices. For example, as shown in Figures 7 and 8, one or more sensors 20 may measure physiological parameters that form an input to a medical device 200 orto a further sensor 20. In one example a respiratory rate sensor measures a respiratory rate which is passed to a respiratory support apparatus which uses the respiratory rate to configure the respiratory support operation. Sensors 20 can be directly connected (for example, wired or wirelessly) to a medical device 200. However, a direct connection requires negotiating a communication channel between the devices and / or pairing the devices. In some cases, the physiological parameters are transmitted from the sensor 20 to a remote processor 400 and are then transmitted from the remote processor400 to the medical device 200. However, the transmission to a remote processor 400 increases signal latency and introduces a longer communication channel, which may be more difficult to secure. In some cases, the remote processor 400 or network may be unavailable which, if required for transmission, will cause issues for data collection and operation of the medical device 200. In some cases, transmission through the remote processor 400 increases a network bandwidth required, increasing costs and / or reducing reliability.

[0131] In some cases, the medical device 200 is configured to receive a sensor 20 transmission on a broadcast channel 650. In some cases, this is advantageous because it does not require a negotiated connection between the medical device 200 and the sensor 20. In some cases, the sensor 20 is not aware of the medical device 200, or medical devices 200, monitoring the broadcast channel 650. By using a broadcast channel 650 the sensor measurements (for example the physiological parameters) can be sent to one or more devices 200 without the need to negotiate between the sensor 20 and the medical device 200. In some cases, the sensor 20 does not have to be aware of the devices 200 receiving the signal. In some cases, the devices 200 do not have to be aware of the sensors 20 transmitting the signal.

[0132] In some cases, a remote processor 400 manages, supervises, or monitors and arranges the transmission. A remote processor 400 is a processor external to the medical device 200 and to the sensor 20. The remote processor may therefore be referred to as an external processor. The remote processor 400 may form part of an external computing device, such as a hub, an edge server, a local server and / or a remote server. In some cases, the remote processor 400 is a server, such as processing server 40 described above. The server may be local server. For example, the server (or at least a portion of the server) may be located in the building, such as a hospital or clinic. The server may be a remote server. For example, the server (or at least a portion of the server) may be located in a cloud environment or at a location remote from the hospital or clinic.

[0133] In some cases, an intermediatory device (which may be referred to as an intermediatory communicator), such as the router or hub 30 described above, or other suitable device, is used to communicate between the server 400 and the sensor(s) 20 and / or devices(s) 200. For example, the intermediatory device may be configured to directly transmit short-range wireless communications (such as Bluetooth™) to the server 400.

[0134] As shown in Figure 15 a patient monitor 700 may comprise the intermediary device 730. The patient monitor 700 may be associated with a patient. The patient monitor 700 may comprise a display 710 suitable to display measurements associated with the patient. The measurements may be measurements from the sensors 20. The patient monitor 700 may transmit data to therapy devices and / or further sensors 20. The patient monitor 700 may communicate with and / or receive data from, the remote processor 400 and / or medical devices 200. In some cases, the patient monitor 700 provides an interface and / or controller between the sensors 20 and the medical device 200. For example, the patient monitor 700 may have anintermediatory device 730, such as a router or hub, as a component within a shared housing, or otherwise communicatively coupled with the patient monitor 700.

[0135] As shown in Figure 17 the intermediatory device (such as router 30) may comprise a converter 310. The converter 310 may be configured to process received data. For example, the converter 310 may convert the format of the received data. For example, the converter 310 may change a communication protocol of the received data. For example, the converter 310 may change the security of the received data. The intermediatory device may then transmit the converted data. For example, the converter 310 may allow data to be transferred between networks with different access requirements and / or security. The intermediatory device may receive data from a plurality of sensors 20 with a first level of security. The intermediatory device may process the received data into processed data. The processed data may be patient specific and require a higher second level of security (or conversely the processed data may be anonymized requiring a lower second level of security). The converter 310 may then convert the processed data into an alternative communication protocol for further transmission. In an example the intermediatory device may receive data in a first format, the converter 310 may converter the data into a second format, and the intermediatory device may transmit the data in the second format. This allows transmission between different networks, and / or different communication profiles and / or different broadcast channels.

[0136] For example, the intermediatory device may receive data and intend transmission of the data to a medical device 200. The medical device may have a device specific format. The converter 310 may thus convert the received data to the device specific format before the intermediatory device transmits the data. For example, the intermediatory may receive the data on a channel with a first communication protocol, the converter 310, may convert the data for transmission on a second communication protocol. This may allow data to be transmitted between open and closed protocols, or from open and proprietary protocols. For example, the first communication channel may comprise Bluetooth™ or Wi-Fi™ while the second communication channel may be proprietary or secure (or vice-versa). Both communication channels may be broadcast channels. This allows sensors and / or devices 200 which are not capable of, for example, Bluetooth™ communications (or the protocol used in the network) to form part of the network. In some cases, converter 310 comprises a wired connection or is configured to be physically connected to one or more sensors 20 or devices 200. This allows devices not capable of wireless communication to be connected to the system. For example,an electrical connector may be provided on the converter 310 or the intermediatory device. The electrical connector may be a USB connector (of any suitable type, including type-C). RS232 connector or other wired interface.

[0137] As also shown in Figure 17 a or the converter 310 may be in intermediatory broadcast device 600 (described in further detail below). This allows the converter to convert signals without involving, for example, intermediatory device (such as router 30). The converter 310 may operate as described above. In some cases, the converter 310 may be configured to convert all received signals for re-transmission by intermediatory broadcast device 600. In some cases, the converter 310 may be communicatively coupled to the medical device 200. For example, the converter may have a physical connection to the medical device (e.g., be connected by a wire or as a dongle). The converter 310 may this receive a wireless transmission of data and convert the data into the format of the medical device 200.

[0138] In some cases, the remote processor400 is configured to manage the sensor 20 data transmission. The remote processor 400 may first identify a sensor 20 present at a location. The location may be a building, such as a hospital, or a portion thereof. The remote processor 400 may identify the sensor 20 by receiving an advertising signal or other known identification for sensors 20 (in particular for wireless sensors). The remote processor 400 may then connect to the sensor 20. Connecting to the sensor 20 may comprise negotiating a communication channel between the remote processor 400 and the sensor 20. The remote processor 400 may then transmit sensor broadcast parameters to sensor 20. The sensor broadcast parameters may instruct the sensor 20 on the required characteristics of transmissions of physiological parameters within the system (or of the communication protocol). For example, the broadcast parameters may include one or more of encryption settings, broadcast channel settings, broadcast frequency requirements, broadcast rules, data packet length, data packet format, data packet identifiers, time periods to send parameters and other relevant data. The remote processor 400 may comprise a database storing patient information. The remote processor400 may associate each sensor 20 and / or device 200 with a patient. In some cases, this association is only stored on the remote processor 400 to improve information security. The remote processor 400 can then supervise the data transfer between sensors 20 and devices 200 associated with the same patient. For example, if a high flow therapy device changes into a mode which requires SpO2 measurements to operate, the remote processor 400 can communicate the sensor broadcast parameters to the SpO2 sensor and sensor transmissionparameters to the high flow therapy device, allowing transmission of the SpO2 data to the high flow therapy device.

[0139] In some cases, the sensor broadcast parameters comprise instructions on the format of a data packet to be broadcast from the sensor 20. For example, the data packet may comprise identification portion and a data portion. The identification portion may be configured to identify the sensor 20, or to provide an identification to allow a receiving device 200 to determine the source or relevance of the data packet. The identification portion may provide information about the sensor 20 or the type of data packets expected from a particular sensor 20. For example, the identification portion may include packet identification parameters such as one or more of: a sensor ID, a device ID, or a class ID. These may then be included in or looked for in a data packet to or from the sensor 20. The identification portion may allow rapid identification of relevant data packets (which may also be encrypted) and reduce or avoid the unnecessary reading of data packets not associated with physiological parameters for the medical device 200. In some case the packet identification parameters may comprise characteristics of the data packets, such as length, frequency, or periodicity.

[0140] The data portion may comprise physiological parameters. In some cases, these are physiological parameters measured by the sensor 20. In some cases, the physiological parameters are a combination of the measured physiological parameters and physiological parameters provided by a further sensor.

[0141] In some cases, the sensor broadcast parameters comprise encryption parameters. Encryption parameters allow the sensor 20 to encrypt data packets (or portions of the data packets). For example, each data packet may comprise an identification portion to allow a device 200 to identify relevant data packets and an encrypted data portion. However, because of the encryption unknown or unauthorized devices 200 cannot access the encrypted data portion.

[0142] Encryption of the sensor broadcast parameters may use one or more suitable encryption methods. Asymmetric cryptography may be used. For example, public key cryptography may be used. The remote processor 400 may store the private key while providing the public key to the sensor 20 in the sensor broadcast parameters. The sensor can then encrypt the physiological parameters with the public key.

[0143] In some cases, the encryption may use a device characteristic to salt or otherwise encrypt the data packet. A salt comprises data fed as an additional data (i.e. additional to thesensed data) to a function that encrypts (e.g. hashes) that data. By using a device characteristic in the encryption method receivers of the data packet can confirm that the expected, or authorized, device has sent the data. For example, the encryption may be encrypted based, in part, on an address of the sensor 20, such as a MAC address. Then, a receiver of the data packet can decrypt the data packet using, in part, the address of the server 20. This means that it is more difficult for a third party to pretend to be a valid device. Other device characteristics or encryption methods may be used as required. Possible encryption methods include stream ciphers such as ChaCha20 or Sals20. ChaCha20-Poly1305 provides a system for appending a MAC (Message authentication code) to the cipher. In some cases, a cipher which maintains a fixed length of the data packet is advantageous as it allows control of the length of the data packet or avoids increasing the length of data packets.

[0144] In some cases, the encryption may use an updating parameter to allow a receiver of the data packet to confirm receipt of adjacent transmissions or to ameliorate the risk of third- party transmissions being inserted to the broadcast channel. For example, the sensor transmission parameters and / or the sensor broadcast parameters may include an initialization parameter and an increment parameter. The initialization parameter and the increment parameter may be set by the remote processor 400. The sensor 20 may then, when sending a data packet, include an incremented value with each data packet and / or use the incremented value as part of the encryption. The medical device 200, on receiving a data packet, may review the incremented value, or attempt to decrypt the data packet using the next incremented value. Where the medical device 200 is unable to decrypt the data packet it may make a series of attempts to decrypt the data packet. For example, the medical device 200 may try several further increments. In some cases, the medical device 200 may contact the remote processor 400 to update current incremented value and / or report an error. Using an updating parameter allows the devices authorized to access the data to be controlled without needing to change the public private key pair and / or to ensure the medical device is receiving the desired information.

[0145] In one example of an updating parameter each time the sensor 20 broadcasts a data packet an initialization vector is incremented. Upon reception of a data packet, the device 200 correspondingly increments their copy of the initialization vector. When a device 200 misses a message (for example by going offline or leaving reception range of the sensor 20), its initialization vector will desynchronize from the sensor 20 rendering subsequent data packetsindecipherable. Upon discovering this condition, the device 200 can first attempt to resynchronize the initialization vector with the data packets received from the sensor 20. The device 200 has the initialization vector from the last successfully decrypted message and the increment size. Through a process of trial and error the device 200 can attempt to decrypt new messages with multiple increments of the initialization vector to resynchronize. If this is unsuccessful, it can re-request sensor transmission parameters from the remote processor 400 which will have remained receiving the data packets or can resynchronize with the sensor 20. If the remote processor 400 stops receiving transmissions from the sensor, for example, if the patient wearing it goes out of range, the encryption negotiation process could begin anew between the remote processor 400 and sensor 20. Following this, the remote processor 400 can re-distribute the new sensor transmission parameters to the devices 200 that previously had access.

[0146] Encryption of the signal may be particularly advantageous where the physiological parameters are considered sensitive information or patient information. In these cases, encrypting the data allows the system to control access to the sensitive information by, for example, controlling who is able to decrypt or decode the data. In some cases, the data packets do not include patient identification. In some cases the data packets only include measurement data. This may be possible because the remote processor 400 controls the access to the data packets and can therefore authorize a sensor 20 to broadcast data and / or a medical device 200 to receive data without needing to form a connection or be aware of the sensor 20 or device 200 sending or receiving the information. This also allows the communication to take place without the medical device 200 or sensor 20 requiring patient identification or details, as all of this information can be controlled by the remote processor 400. By maintaining sensitive data only on the remote processor 400 and / or by controlling access to certain medical devices 200 sensitive information can be kept secure, or at least the system can ameliorate risks of linking communicating sensitive information with, or linked to, specific patient details.

[0147] Once the remote processor 400 has sent the sensor broadcast parameters to the sensor 20 the remote processor 400 may disconnect from the sensor 20. The remote processor 400 is now able to receive data packets on a broadcast channel instead of requiring a direct connection. For example, the data packets may be on an advertising channel. One example uses the advertising channel of a Bluetooth™ system. However other broadcast channels are known, such a UDP broadcast channel, or in other wireless systems. Broadcast channels allowone-to-many transmissions without requiring a negotiated connection and / or a constant communication channel between devices. In many cases this allows the remote processor 400 to receive more data packets because a constant communication channel is not required. For example, many communication protocols have a limited number of concurrent connections, but are capable of receive many more broadcast channels, Bluetooth™ may be limited to 20 direct connections, however a Bluetooth™ device can monitor hundreds or thousands of Bluetooth™ advertising channels. Use of the broadcast channel also allows the sensor 20 to send data packets to multiple devices 200 or other sensors 20 without needing updates or changes, or a connection to the remote processor. This reduces the overhead and complexity of the system.

[0148] The remote processor 400 may also initialize and / or manage a device 200 to receive data packets from sensor(s) 20. In some cases, this allows the remote processor 400 to supervise data transmission between sensor(s) 20 and a medical device 200 (or other sensor(s) 20) without forming part of the communication channel and therefore reducing latency. In some cases, it also allows the medical device 200 to directly receive physiological parameters from a sensor 20 without requiring a direct connection or a handshake, process with the sensor 20. The remote processor 400 may provide the necessary information for the medical device 200 to identify and understand or decode data packets from the sensor 20.

[0149] In some cases, the remote processor 400 is configured to transmit sensor transmission parameters to the medical device 200. The sensor transmission parameters comprise instructions on the format of a data packet to be received from the sensor 20. For example, the data packet may comprise identification portion and a data portion. The identification portion may be configured to allow identification the sensor 20, so that the medical device 200 can determine correct sources to receive data packets from. In some cases, the sensor transmission parameters comprise decryption parameters. Decryption parameters allow the device 200 to decrypt data packets (or portions of the data packets) received from sensor 20. For example, each data packet may comprise an identification portion to allow a device 200 to identify relevant data packets and an encrypted data portion. By receiving the sensor transmission parameters from the remote processor 400 the medical device 200 is able to, or becomes authorized to, access the encrypted data portion.

[0150] Using the remote processor 400, which may be a local or remote server, for example, to manage and send communication parameters to both the sensor 20 and medical device200, allows the medical device 200 to operate independently of any patient information, sensor handling information or cryptography details. These can be managed by the remote processor 400. Both the remote processor400 and one or more other devices 200 can receive and decode the broadcast channel and therefore have access to the physiological parameters. This allows the remote processor 400 to process and / or record the details of the physiological parameters, to form a patient record, for example, while separately allowing the medical device(s) 200 to access the physiological parameters directly for use in the medical device 200 or combination with physiological parameters measured by the medical device. The remote processor 400 may process the physiological parameters and / or sensor data as described above, for example with reference to Figure 1.

[0151] By controlling and sending cryptographic information to authorized devices 200 third parties are prevented from accessing physiological parameters of, for example, patients. Even if a third party was able to gain access to data packets because the patient specific information may be stored on the remote processor 400 the third party does not have access to this sensitive information.

[0152] In one example the remote processor 400 uses public private key encryption. The public key is sent to sensor 20 to encrypt the data packets. The private key is held by the remote processor 400 to decode the data packets. However, the remote processor 400 may also send the private key to the medical device 200 to allow the medical device to independently decode the data packets. The private key (or other cryptographic information) may be transmitted to the medical device 200 on receipt of a request from medical device 200 or based on the remote processor's 400 determination of the medical device 200 and / or patient need, for example. A public private key pair provides a simple cryptographic system for the medical device 200, however other cryptographic systems may be used. Other cryptographic systems may be used involving transmitted and stored data or codes.

[0153] The use of a broadcast channel allows the remote processor 400, the one or more medical devices 200 and / or one or more further sensors 20, to all receive data packets. If the sensor transmission parameters are also available to the devices 200, the devices 200 can read data packets encoded with the sensor broadcast parameters. A broadcast channel allows one- to-many transmissions of data packets, for example from the sensor 20. A broadcast channel may be an advertising channel, although other broadcast channels may be used. A broadcast channel may intermittently or periodically send data configured to be receivable by multipledevices. In some cases, the length of a data packet may be minimized to reduce required broadcast power or bandwidth. In some cases, a broadcast channel does not negotiate a connection with other devices, allowing all devices to receive broadcast data packets if able to receive data packets by the specified communication protocol.

[0154] Thus the multiple devices 400, 20, 200 may independently receive the same transmissions from the sensor 20 and to process these independently, possibly for different purposes. For example, the medical device 200 may adjust a medical setting, such as an operational parameter, based on the sensor, while the remote processor 400 may store the physiological parameters and / or calculate a health score. While broadcast channels, such as advertising channels have been described, alternative one-to-many communications channels can be used. In some cases, it is advantageous to select a communication channel which does not require a negotiated connection to reduce complexity in the system, although it is also possible to use a negotiated connection if desired. Operational parameters may comprise one or more of a temperature, flow or humidity parameter. Operational parameters may comprise an on / off parameter.

[0155] In some cases, the sensor 20 transmits directly to the medical device 200. However, an intermediatory broadcast device 600 (shown in Figure 12, which may be referred to as an intermediatory broadcaster), such as a repeater or extender may also be used. In some cases, the intermediatory broadcast device 600 allows the medical device 200 to be moved further from the sensor 20 or ensure better coverage of the room or building where sensing is taking place. In one example the intermediatory broadcast device 600 allows the medical device 200 to continue receiving sensor readings as the patient is moved or away from the medical device 200. The intermediatory broadcast device 600 may be associated with the server 400. For example, the intermediatory broadcast device 600 may be the intermediatory device (e.g., the hub or router 30) discussed previously. A router 30 may, for example, both receive data packets for the remote processor 400 and rebroadcast the data packets to other sensors 20 or devices 200. The intermediatory broadcast device 600 may be a medical device 200 (which is or is not configured to also process the data packet).

[0156] Figure 16 shows an example in which a patient monitor 700 (optionally comprising display 710) acts as an intermediatory broadcast device 600. The patient monitor 700 is configured to receive data from the sensor 20 and / or medical device 200. In some cases the patient monitor 700 also transmits data to the sensor 20 and / or medical device 200. The patientmonitor 700 may also communicate (either by a broadcast channel, or over an alternative communication channel (e.g. a data transmission channel) with the intermediatory device such as hub or router 30. In some cases, as shown in Figure 15 the patient monitor 700 communicates directly with remote server 400. Although a single sensor 20 is shown it will be understood this encompasses a plurality of sensors 20. In some cases the patient monitor 700 is instead (or also) connected to the remote processor 400 independently and / or receives data from the remote processor 400 through the intermediatory device rather than direct from the sensors 20 or medical devices 200.

[0157] In some cases, the remote processor 400 has access to previous physiological parameters received from the sensor 20, or access to data storage containing previous physiological parameters of the patient associated with the medical device 200. In some cases, the remote processor 400 may provide this data to the medical device 200. Providing the physiological parameters to the medical device 200 may provide a calibration or initializing of the medical device 200 to be performed, for example. In one example it may allow for the medical device 200 to obtain physiological parameters from periods in which it was unable to receive data packets from the sensor 20 on the broadcast signal. For example, where physiological parameters appear missing or incorrect or where historical data is required, the medical device 200 could request data from the remote processor 400. For instance, this may avoid a need to wait for additional physiological parameters. In some cases, the remote processor 400 provides physiological parameters to the medical device 200 when the remote processor 400 is able to process data more quickly than the medical device 200 or where additional processing on the remote processor 400 is faster.

[0158] In some cases, the medical device 200 may initiate the physiological parameters transmission by sending a request for physiological parameters to the remote processor 400. Alternatively, the remote processer 400 may manage the system by determining the physiological parameters required by the medical device 200 and determining a sensor measuring the required physiological parameter(s). The remote processor 400 may then instruct the sensor 20 to broadcast the physiological parameters and provide the medical device 200 the parameters necessary to read the broadcast data packets. The remote processor 400 could activate this by forming connections to the sensor 20 and medical device. This may, such as in Bluetooth™, be enabled based on an advertising signal. Therefore, in some cases neither the sensor 20 nor the medical device 200 need to have details of each other or form aconnection between one-another. In some cases, the medical device 200 is configured to request an update to the sensor transmission parameters, such as where data packets have not been received for some time, or when data packets cannot be decrypted. In some cases, the remote processor 400 is configured to update the sensor transmission parameters, such as when a more accurate sensor is associated with the patient of the medical device 200. In some cases, the remote processor 400 is configured to remove a private key from the medical device 200 to prevent further transmission of physiological parameters to the medical device 200.

[0159] In some cases, the system can continue to operate when the remote processor 400 is not present. This is because after the remote processor 400 has arranged the connection between the sensor 20 and the medical device 200 the remote processor 400 is not required for the data packets to be transferred. However, in many cases the remote processor 400 will remain to monitor or supervise the connection, to provide a second pathway for physiological parameters in case of any system failures and / or store data from the sensor 20 and / or medical device 200. For example, the stored information may be provided to a display (for example the display of a patient monitor or a display at or near the patient and / or a clinician) or patient monitoring system.

[0160] The system has been primarily described herein with reference to a sensor 20 and a medical device 200. It will be understood that the sensor 20 may form part of, or be integral with, a medical device 200 (for example a different medical device). In some cases, a sensor 20 attached to a first medical device 200 will broadcast a physiological parameter to a second medical device 200. In some cases, a first sensor 20 will broadcast a physiological parameter to a second sensor 20. The second sensor may combine the received physiological parameter with a sensed physiological parameter to create a more accurate or combined physiological parameters, for example. Combined parameters may comprise a health index or physiological parameters based on multiple independent measurements, for example. In some cases, the combined physiological parameter is then broadcast on the same broadcast channel, so as to allow additional devices 200 and / or the remote processor 400 to receive the combined physiological parameters. In some cases the combined physiological parameter is broadcast on a second broadcast channel. This may, for example, make the combined physiological parameter available to a different set of devices 200 and / or sensors 20.

[0161] In some cases, the group of sensors 20 and medical devices 200 may simply been seen as nodes of the broadcasting network. The remote processor 400 manages each of thenodes to control the physiological parameters being transmitted by each node and / or the physiological parameters being received by each node. In this way the system is able to share physiological parameters amongst two or more nodes of the system, and in some cases more than ten different nodes. This increases the depth of data available to a clinician or user of the system. A medical device 200 may also comprise one or more sensors. However, these will typically be directly connected to the medical device so not require the described communication system.

[0162] The term sensor 20 broadly covers any device or apparatus configured to measure or sense a value. In the described system the sensors 20 are configured to measure one or more physiological parameters. Physiological parameters refer to the measurable characteristics of living organisms. The data may describe the functions and processes occurring on or within the body. Examples of physiological parameters include heart rate, blood pressure, body temperature, oxygen saturation, respiratory rate, muscle strength, metabolic rate, and hormonal levels. Physiological parameters are often used in clinical settings for the assessment and diagnosis of various medical conditions.

[0163] The term medical device 200 broadly covers devices or apparatus configured for medical assistance. For example, the medical device 200 may be a respiratory device. The medical device may be one or more of a breathing apparatus, a respiratory apparatus, a ventilator, a positive airway pressure machine (PAP), a continuous positive airway pressure (CPAP) machine or a high-flow therapy machine. In some cases, the medical device 200 is configured to use the physiological parameters to adjust the operation of the medical device 200, for example to improve patient comfort or safety. For example, the sensor 20 may monitor a patient heart rate and the medical device 200 may be a respiratory apparatus configured to increase a flow rate with increased heart rate.

[0164] The system has been described with reference to a medical device 200. However, in some cases the system may also be applied to a broader range of sensor 20 and device networks. For example, in residential or industrial monitoring the system may be used to control the communication between a plurality of sensors and one or more devices. For example, the devices may perform environmental control of a building or location. For example, one or more temperature sensors may be linked to an HVAC. In these cases the sensors may monitor one or more environmental and / or industrial and / or residential parameters.

[0165] The sensors 20 and / or the medical devices 200 described may be independent of the system. The sensors 20 may be developed independently of the system to provide accurate physiological parameters. As the system can be agnostic to the specific working of the sensor 20 the sensor merely has to be able to operate on a broadcast channel and to configure its broadcast channel based on the instructions of the remote processor 400. Similarly, the system may be agnostic to the medical devices 200 used, provided they can monitor a broadcast channel and can configure the monitoring based on the instructions of the remote processor 400. The sensors 20 are able to transmit data packets intermittently and / or periodically. Because the sensors 20 do not form a continuous connection with the remote processor 400 or the devices 200 frequent data transfer is not required to maintain an active connection, reducing communication traffic when no sensor 20 updates are being sent. The system has particular application for wireless sensors, although wires sensors may also connected to a wireless transmitter. Example sensors 20 include pulse oximeters, actigraphy sensors, blood- sugar monitors, insulin pumps, and thermometers.

[0166] The system has been described with sensors 20 and device 200. However, in many cases the sensors 20 will not be permanent. For example, in a hospital setting a patient may have different sensors 20 connected and disconnected as their treatment and / or monitoring changes. As described above the sensors 20 may be detected by the remote processor 400, such as a processing server 40, and associated with the relevant patient. The remote processor 400 can then determine whether to provide measurements from the new sensor 20 to one or more medical devices 200 and provide sensor transmission parameters and sensor broadcast parameters as required. For example, if a more accurate sensor 20 is connected the medical device 200 may be instructed to receive the more accurate data. Alternatively, if a sensor 20 is removed, the remote processor 400 may supply sensor broadcast parameters for an alternative sensor 20 still connected to the patient. Thus the system may form a network comprising one or more sensors 20 and one or more medical devices 200 or a plurality of sensors. Optionally the remote processor 400 forms part of the network, although the network may continue to operate when the remote processor is removed.

[0167] The system may also be considered from a network perspective, or of the communication channels within a network. The network may be considered to contain the remote processor 400, the transmitting devices such as sensors 20 and receiving device such as medical device 200. Some devices 20, 200 may act as both transmitters and receivers. Insome cases the remote processor 400 activates a communication channel to engage a sensor, this is a direct connection between the devices in the network. The remote processor then initialises a broadcast channel, or the broadcast of data packets on the broadcast channel, by supplying broadcast parameters to the sensor (or other transmitting device). The remote processor is able to receive these transmissions, but as yet other devices, even if they receive the transmission, are unable to read the data packets and / or any physiological parameters within them. The remote processor then (or when requested by a receiving device or after determining the information should be sent to a receiving device) activates a communication channel to engage a receiving device such as medical device 200. This is a second direct connection between devices in the network.

[0168] The remote processor 400 then initialised the transmission parameters on the receiving device. The transmission parameters allow the receiving device to read the broadcast data packets of the transmitting device. The transmitting device and receiving device can then communicate without the remote processor needing to be an intermediatory (although it may choose to monitor and / or update the network as required, or also receive the data packets). This reduces the burden on the remote processor. The broadcast channel may be understood as a private network because, although it is broadcast so that any device may receive the data packets, only devices configured by the remote processor have access to the data in the data packets. The remote processor can choose whether to also be part of the private network (by receiving data packets) or to allow the network to operate independently. In some cases the system allows the remote processor 400 to configure the private network so that no direct connection or negotiated connection is required between transmitting and receiving devices.

[0169] Figure 7 shows a system arrangement with the remote processor 400 shown as a server separated from a router 30 configured to pass short-range wireless communications to the remote processor 400. The dotted line represents a remote server, although a local server or other remote processor 400 may be used. Figure 7 shows an arrangement where both the sensor 20 and the medical device 200 are connected to the remote processor400. This requires data transmissions to pass through the remote processor 400 and for the remote processor 400 to maintain the connection to the sensor 20 and the medical device. This may increase latency of communication and introduce additional security risks. In figure 7 the dashed line represents the separation of the router 30 and the remote processor 400 which is shown as a remote server or cloud server.

[0170] The connection between an intermediatory device, such as router 30, and the remote processor 400 may be through a network. The network may comprise a local area network (LAN) or wide area network (WAN) or an enterprise network. The network may comprise the internet, or allow transmission through the internet. Any suitable transmission may be used to transmit data from the router 30 to the remote processor 400. One or more additional devices may be present in the network, or pass data between the router 30 and the remote processor 400. In some cases, at least a portion of the network is wireless. For example, an intermediatory device, such as router 30 may communicate with the remote processor 400, at least in part, by Wi-Fi.

[0171] Figure 8 shows a system arrangement which has adapted from the system of Figure 7 to improve the communication method. Now the remote processor 400 has connected to the sensor 20 and the medical device 200 to initialize transmission and receival parameters but does not need to maintain a two-way connection. Instead, either or both of the sensor 20 and the medical device 200 send information on a broadcast channel. The sensor 20 sends physiological parameters on the broadcast channel 650. Because the broadcast channel is a one-to-many communication channel the physiological parameters can be received by both the remote processor 400 and the (one or more) medical device 200. The remote processor 400 has also initiated the medical device 200 to receive data on the broadcast channel 650 from the sensor 20. The medical device 200 may also use a broadcast channel 650, or a connection, to the remote processor 400 to provide feedback or data to the remote processor 400 on its operation.

[0172] Figure 9 shows an information flow diagram of the connection between the remote processor 400, sensor 20 and medical device 200. Alternative order of operations is possible. In the illustrated example the remote processor 400 receives an indication, such as an advertising message from the sensor 20. The remote processor 400 decides to connect to the sensor 20 and performs the necessary handshake or process. The remote processor 400 then sends the sensor 20 sensor broadcast parameters which outline the format, contents and / or encryption required to be transmitted on the broadcast channel 650. The sensor 20 then starts transmitting data packets on the broadcast channel. However, the data packets may only be understood by devices having the sensor transmission parameters. The sensor transmission parameters allow processing of data packets sent with the sensor broadcast parameter. At thisstep the remote processor 400 is able to receive the data packets but the medical device 200 is unable to.

[0173] If the remote processor 400 determines the medical device 200 should have access to the data packets (or the physiological parameters within the data packets) the remote processor 400 will respond to the advertising signal of the medical device 200 to form a connection with the medical device 200. Alternatively, the medical device may request access to some physical parameter value supplied by sensor 20. The medical device 200 does not need to know the specific sensor 20 supplying the physiological parameters. Once a connection has formed between the medical device 200 and the remote processor 400 the medical device 200 can receive the sensor transmission parameters. The medical device 200 is then able to receive and process the data packets from the sensor 20.

[0174] Figure 10 is an information flow diagram beginning where the remote processor 400 and the medical device 200 have been authorized to receive data packets from the sensor 20. In this example the remote processor 400 determines to update the sensor broadcast parameters on the sensor 20. This could be a periodic change for security, or to prevent previously connected medical devices 200 from receiving the data packets. The remote processor 400 connects to the sensor 20 and sends updated sensor broadcast parameters. The medical device 200 is then unable to process the broadcast data packets because the stored sensor transmission parameters no longer correlate to the sensor broadcast parameters. To retain the ability to receive the data packets the device 200 must connect to the remote processor400 and request updated sensor transmission parameters. The remote processor400 may determine if this is allowable before providing these. In some cases, the remote processor 400 may be configured to instead connect to the medical device 200 and remove the previously stored sensor transmission parameters.

[0175] Figure 1 1 shows a connection formed in a similar way to Figure 9. However, once the broadcast channel 650 is operational the remote processor 400 is removed and the sensor 20 and the medical device 200 are able to continue transmitting and receiving data packets respectively. This provides resilience to the network because the data transfer can continue without the remote processor 400 involvement. In some cases, the sensor 20 and the medical device 200 will not even notice the remote processor 400 being removed. This is because they are not in continuous connection with the remote processor400 but have only been instructedto broadcast data packets which the remote processor 400 can receive. This allows more devices to be connected to the remote processor 400.

[0176] Figure 12 shows a connection formed in a similar way to Figure 9 but with an intermediatory broadcast device 600 used to repeat or extend the broadcast channel 650. The intermediatory broadcast device 600 may be a repeater configured to extend the range of the short-range wireless transmission, or to ensure that the broadcast channel is available across a location or building. Although shown as only acting between the sensor 20 and the medical device 200 in some cases the intermediate broadcast device 600 also repeats or extends signals between the remote processor 400 and the sensor 20 and / or the medical device 200.

[0177] Figure 13 shows a connection formed between a sensor 20 and multiple medical devices 200a and 200b. This allows a single sensor to provide physiological parameters to multiple devices as required. In similar arrangements multiple sensors may broadcast one or more physiological parameters. In some cases, a sensor 20 may broadcast a physiological parameter to a second sensor 20 which broadcast a combined physiological parameter to a medical device 200. Figure 13 shows a similar approach to the information flow diagram of Figure 10 except each medical device 200a, 200b, is independently provided with the sensor transmission parameters before they are able to process the data packets on the broadcast channel 650. Because the broadcast channel is a one-to-many channel many devices can receive the data packets with low latency. In an alternative arrangement the first medical device 200a could receive the physiological parameters and amend or combine them before broadcasting them (with different sensor broadcast parameters provided by the remote processor 400) to the second medical device 200b.

[0178] Figure 14 shows an example data packet 700 for the broadcast channel. The example data packet 700 is an advertising packet from a Bluetooth™ communication protocol, but other systems may be used. The data packet comprises a header portion 702 and a payload. The payload is shown divided into two portions, an identification portion 703 and a data portion 704. The identification portion may be used to provide an identifier which is readable to any device 200, 400 receiving the broadcast channel. This can be used to identify if the data packet is of interest or relevant to the device 200, 400. The data portion 704 is where the physiological parameter is stored. Where encryption is used devices 200, 400 are unable to read the data portion unless they have the sensor transmission parameters. However, they can use the identification portion to reduce the number of potential data packets 700 they must review.

[0179] In one example the initialization of a sensor 20 comprises the remote processor 400: initializing public and private keys, sending the public key to the sensor 20, configuring an initialization vector (IV) and increment size, configuring an encryption system for the data packets such as the x25519 protocol or another public-key cryptography technique, and sending this sensor broadcast parameters to the sensor 20. The remote processor 400 can then disconnect from the sensor 20. When the sensor 400 has new measurements of physiological parameters it transmits the physiological parameters embedded in a Bluetooth or BLE advertising packet in accordance with the sensor broadcast parameters set by the remote processor 400, so the remote processor 400 can decrypt the data. While the sensor 20 is transmitting information, any device within range can receive the data packets. However, without sensor broadcast parameters corresponding to the sensor transmission parameters they are unable to process the data packets. Devices 200 can pair and connect (in the Bluetooth™ sense or based on the short-range wireless communications method) to the external process and request access to the physiological parameters. If there is an active sensor 20 measuring the physiological parameter for the same patient, the remote processor 400 returns the sensor broadcast parameters necessary to decode the transmissions from the sensor 20. Upon receiving the sensor broadcast parameters device 200 can end the connection with the remote processor 400 and receive and / or decode the transmissions of the measurement sensor 20 independently.

[0180] The proposed system can have several advantages for patient data security. Because patient specific details may be stored only on the remote processor 400 the patient associations are not known to the sensor(s) 20 or device(s) 200. In some cases the data packets do not contain the identity of the patient using the device 200. This means that third-party observers cannot determine the identity of the patient from the sensors 20 or the transmissions on the broadcast channel 650. Patient and device association can be kept on a need-to-know basis. In some cases: the sensor 20 transmitting data does not know what devices are receiving it and / or the sensor 20 does not know the identity of the patient it is monitoring; the medical devices 200 do not know the identity of the patient the sensor is monitoring, only that it is associated with the same patient it is connected to.

[0181] In some cases, the system allows for devices 200 to receive secure data from wireless sensors 20 and decode the data without connecting directly to the sensors 20. This can lower resource costs on the wireless sensors - the battery and processing requirements are reducedas Bluetooth connections are not needed to be maintained to transmit measurements. This allows many devices to receive and act on sensor data (any device within range to receive), whereas a wireless sensor may only support, for example, 1 or 2 Bluetooth connections if one- to-one connections are required.

[0182] In some cases, the remote processor 400 manages relationships between sensors 20 and / or devices 200 but does not distribute data between the sensors 20 and / or devices 200. Advantageously devices 200 utilizing sensor 20 data are therefore not reliant on contact with the remote processor 400 beyond initially transferring the necessary broadcast parameters. Thus, if the remote processor 400 is unavailable - through a Bluetooth™ hub going offline for example - the device 200 can continue to receive transmissions from the wireless sensors 20.

[0183] In some cases, the remote processor 400 monitors the data transmission of the sensors 20 and / or medical devices 200. For example, the remote processor 400 may continuously monitor the data transmission from a sensor 20 or device 200. The remote processor 400 may determine that there is an error in a data transmission and / or an absence of a data transmission. The remote processor 400 may be configured to perform a response action where a data transmission error occurs. The response action may be configured for a particular patient and / or for a particular location (e.g., a hospital). For example, the remote processor 400 may determine a sensor has ceased transmitting data. The remote processor 400 may monitor a time period (duration) in which the sensor has not transmitted data. Where the time period exceeds a threshold period the remote processor 400 may send an alarm and / or message to a clinician and / or a patient monitor display. Multiple time periods may be applied. Each time period may have an associated response action. The response actions may escalate with longer time periods. For example, a display alarm may become an audible alarm, orthe volume of an alarm may increase. The response action may depend on which sensor has caused the error and / or anomaly. For example an important and / or primary sensor may cause a higher level alert and / or alarm.

[0184] A patient specific response action and / or threshold may be set. For example, a hypercapnic patient may require a shorter threshold, if no sensor is detected for 25 minutes then an alarm is raised and / or alerts sent to the clinician and / or the patient monitor display is updated. Another patient may have a period of 45 minutes. The remote processor may change the response action if a redundant measurement is available. For example, a lower level of alert or alarm may be sent. A hospital specific response allows clinicians to follow hospitalprocedures. The hospital specific response allows a hospital (or other location) to define a specific response protocol (i.e. a predetermined series of response actions). The response actions may represent a selected medical practice regarding alerts and alarms. In some case the remote processor monitors and / or stores sensor data. The remote processor 400 may review received data and determine an anomaly in the sensor data. An anomaly may be detected by measurements being out of range, or by comparison to other sensors, for example. The remote processor 400 may send an alert or alarm that a sensor 20 appears to be malfunctioning. In some cases an alert is a message. The message may be sent to one or more people or devices. For example an alert may be sent to a patient monitor and / or one or more clinician, such as nurses. An alarm comprises a visual and / or audio portion. An alarm may also comprise a message with the visual and / or audio portion. Alarms may be configured on one or more devices. The alarms may be configured on the devices dependent on the severity of the alarm. For example, alarms may be configured on one or more of a medical device (e.g. a respiratory device such as an Airvo™. For example alarms may be configured in a room of the patient. For example, alarms may be configured on a ward, or for a group of patients. In some cases an alarm is configured at a monitoring station separate from the patient. Alarms may be configured in multiple locations, dependent on severity.

[0185] Considering a Bluetooth™ based protocol the system may use the advertising functionality built in which allows for nodes 20, 200 to facilitate the establishment of a one-to- one connection. A node 20,200 advertising in this capacity is referred to as a 'peripheral'. A node 20, 200 transmitting advertising packets without the intention of forming a connection - i.e., are transmitting data - are 'broadcasters. Advertising packets as conceived by the Bluetooth™ standard are open and accessible to any node 20, 200 within range of the broadcast. In the present system further advantages are shown where data encryption and security are provided for health monitoring applications, while retaining the benefits of one- to-many broadcasting.

[0186] The system could utilize alternative communication protocols instead of Bluetooth. Examples include ZigBee, RFID, Wi-Fi, cellular technology, 4G, 5G or any other radio-based protocol, or any wired protocol, such as UDP. Where available a broadcast channel (e.g. an advertising packet) may be used to improve data transmission) The broadcast is configured to transmit information without requiring confirmation of a connection. This information may be received by a plurality of other devices using the same communication protocol. In some cases,a combination of communication protocols is used. For example, Bluetooth™ may be used between a sensor 20 and a device 200, while Wi-Fi™ is used between the sensor 20 and the intermediatory device such as router 30. In some case a first plurality of sensors 20 use a first communication protocol (e.g. Bluetooth™) while a second plurality of sensors 20 use a second communication protocol (e.g. Wi-Fi™). In some cases Wi-Fi is used as the communication protocol. Wi-Fi has an advertising packet which may be used as the broadcast channel. Wi-Fi may be used between some or all of the nodes 20, 200 and / or between the nodes 20, 200 and intermediatory device and / or remote processor 400.

[0187] A specific example of a connection is now described. In this example a secure session is initiated with the remote processor 400 generating a public private key pair using elliptic curve cryptography. The public key is written to the sensor 20 via entering a secure session command to the security characteristic. In this embodiment the elliptic Curve 25519 is used for the public private key. Upon receiving the enter secure session command, the sensor 20 generates its own key pair using the same technique. The remote processor 400 then reads the sensor's 20 public key by reading the security characteristic which will return the public key of the sensor 20. The remote processor 400 then writes a random initialization vector (in this implementation 12 bytes) and increment style to the sensor 20. The sensor receiving an initialization vector completes the secure session handshake and the remote processor 400 and the sensor use their own private key and the received public key to generate a symmetric key using an asymmetric key-exchange technique. This embodiment uses X25519 Diffie- Hellman key generation. The sensor 20 is now in secure session mode. Once in secure session mode, the service data payload (for example the physiological parameter) advertised by the device 200 is encrypted with an encryption technique using the calculated key and the initialization vector. In this example the stream Cipher ChaCha20 is used however, a block cipher such as AES or an alternative stream cipher like Salsa20 could be used instead. For each subsequent broadcast message, the initialization vector is incremented by the increment step specified when the vector was written to the sensor 20.

[0188] In some cases, alternative cryptographic techniques are used. Once the device has entered a secure session, transmitted data is encoded using an encryption scheme. In some cases a stream cipher such as ChaCha20 or a variant thereof is used. These have an advantage that encrypted data will have the exact same length as the source data it came from. Alternatively, a block cipher could be used if additional space is allowed. In some casesChaCha20-Poly1305 could be used. This uses the same encryption as ChaCha20, however appends a MAC (Message Authentication Code) to the encrypted data that can be used as a checksum to verify its authenticity and / or the transmitting device of the message. The MAC code, however, adds 16 bytes to the message's length. Alternatively, a fixed verification code may be used.

[0189] While encryption such as ChaCha20 can provide strong encryption, on its own it provides no way to verify that the decrypted message is authentic. Adding to the message can be used to determine, that once decrypted, the information received is what was sent. In some cases ChaCha20-CRC is used to add message authentication. In ChaCha20-CRC mode a CCITT16 checksum is calculated and appended to the message, the entire message including the checksum is then encrypted using ChaCha20 encryption with the calculated key and current IV. On receipt the message is decrypted then the checksum recalculated. If the checksum matches it can be reasonably assumed the message is authentic. A CCITT16 checksum provides 65535 possible checksums, so there is a 1 in 65535 chance that corrupted or tampered data, or an out of sync IV, may result in a correct checksum. This approach results in only two bytes of overhead on top of the unencrypted message. Using a MAC address to verify messages in a ChaCha20 implementation adds 16 bytes to the payload size.

[0190] Furthermore, examples 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.

[0191] 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.

[0192] The various illustrative logical blocks, processors, 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.

[0193] 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.

[0194] 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.

[0195] 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 includea 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

CLAIMS1 . A messaging system for physiological parameters, the system comprising:At least one first device configured to transmit physiological parameters on a broadcast channel;At least one second device configured to: connect to a remote processor, receive transmission parameters from the remote processor; receive at least one data packet from a broadcast channel, determine the at least one data packet is associated with the at least one first device based on the transmission parameters; and determine the physiological parameters based on the at least one data packet.

2. The messaging system as claimed in claim 1 wherein the first device is a sensor.

3. The messaging system as claimed in claimed in any one of claims 1 and 2 wherein the second device is a medical device.

4. The messaging system as claimed in claimed in any one of claims 1 to 3 comprising a remote processor configured to connect to the at least one first device and provide sensor broadcasting parameters to the at least one first device.

5. The messaging system as claimed in claim 4 wherein the remote processor is configured to connect to the at least one second device and provide the transmission parameters.

6. The messaging system as claimed in any one of claims 4 to 5 wherein the remote processor is separate from the first and second devices.

7. The messaging system as claimed in any one of claims 4 to 6 wherein the remote processor is configured to be external to a facility in which the first and second devices are located.

8. The messaging system as claimed in any one of claims 4 to 7 wherein the remote processor comprises a server.

9. The messaging system as claimed in claim 8 wherein the server is located remotely or the server is located locally.

10. The messaging system as claimed in any one of claims 1 to 9 wherein the at least one first device is one or more of a sensor or a medical device.1 1 . The messaging system as claimed in any one of claims 1 to 10 wherein the at least one second device is one or more of a sensor or a medical device.

12. The messaging system of any one of claims 1 to 11 wherein the broadcast channel comprises an advertising channel.

13. The messaging system as claimed in claim 12 wherein the advertising channel is from a short-range wireless technology standard.

14. The messaging system as claimed in claim 13 wherein the short-range wireless technology standard is Bluetooth™.

15. The messaging system as claimed in any one of claims 1 to 14 comprising the step of the remote processor receiving the at least one data packet on the broadcast channel independently from the first device.

16. The messaging system as claimed in any one of claims 1 to 15 wherein the at least one data packet is received directly from the first device.

17. The messaging system as claimed in any one of claims 1 to 16 wherein the at least one data packet is received through at least one intermediatory broadcast device between the first and second devices.

18. The messaging system as claimed in any one of claims 1 to 17 wherein determining the physiological parameters comprises decrypting the at least one data packet based on the transmission parameters.

19. The messaging system as claimed in any one of claims 1 to 18 wherein the transmission parameters comprise cryptographic parameters.

20. The messaging system as claimed in claim 19 wherein the cryptographic parameters comprise a private key.21 . The messaging system as claimed in claim 20 wherein the private key is part of a public private key pair with the second device comprising a corresponding public key.

22. The messaging system as claimed in any one of claims 19 to 21 wherein the cryptographic parameters comprise an updating parameter.

23. The messaging system as claimed in claim 22 wherein the updating parameter comprises an initialization parameter and an increment parameter.

24. The messaging system as claimed in claim 23 wherein the physiological parameters comprise at least one sensitive information parameter.

25. The messaging system as claimed in any one of claims 1 to 24 wherein the transmission parameters do not include patient identification.

26. The messaging system as claimed in any one of claims 1 to 25 wherein the at least one data packet does not include patient identification.

27. The messaging system as claimed in any one of claims 1 to 26 wherein determining the physiological parameters comprises confirming the at least one data packet is relevant based on the transmission parameters.

28. The messaging system as claimed in any one of claims 1 to 27 wherein the transmission parameters comprise packet identification parameters.

29. The messaging system as claimed in claim 28 wherein the packet identification parameters comprise one or more of a sensor ID, a device ID and a class ID.

30. The messaging system as claimed in any one of claims 1 to 29 wherein one or more of the first device and the second device is a medical device.

31. The messaging system as claimed in claim 30 wherein the medical device is one or more of: a breathing apparatus, a respiratory apparatus, a ventilator, a positive airway pressure machine (PAP), a continuous positive airway pressure (CPAP) machine or a high-flow therapy machine.

32. The messaging system as claimed in any one of claims 30 to 31 wherein the medical device is configured to adjust an operational parameter dependent on the physiological parameters.

33. The messaging system as claimed in any one of claims 1 to 32 wherein the second device comprises a sensor.

34. The messaging system as claimed in claim 33 wherein the sensor is associated with, or part of, a medical device.

35. The messaging system as claimed in claim 33 or 34 wherein the second device is configured to receive further physiological parameters from the remote processor.

36. The messaging system as claimed in claim 35 wherein the further physiological parameters comprise historic physiological parameters.

37. The messaging system as claimed in any one of claims 35 to 36 wherein the second device is configured to request, from the remote processor, the further physiological parameters.

38. The messaging system as claimed in any one of claims 1 to 37 wherein the second device is configured to determine combined physiological parameters by combining the physiological parameters with physiological parameters determined on the first device.

39. The messaging system as claimed in claim 38 wherein the second device is configured to broadcast the combined physiological parameters.

40. The messaging system as claimed in claim 39 wherein the broadcast is on one or more of the broadcast channel and a second broadcast channel.41 . The messaging system as claimed in any one of claims 1 to 40 wherein the second device is configured to request, from the remote processor, the transmission parameters.

42. The messaging system as claimed in any one of claims 1 to 41 wherein the second device is configured to request from the remote processor, an update to the transmission parameters.

43. The messaging system as claimed in claim 42 wherein the update is requested when the physiological parameters cannot be determined from the at least one data packet by the first device.

44. The messaging system as claimed in any one of claims 1 to 43 wherein the first device is not aware of the second device.

45. The messaging system as claimed in any one of claims 1 to 44 wherein the remote processor is not required for ongoing receiving of the one or more data packets.

46. The messaging system as claimed in any one of claims 1 to 45 wherein the remote processor is configured to monitor the status of one or more of the first and second devices.

47. The messaging system of claim 46 wherein the remote processor is configured to update one or more of the transmission parameters and the broadcast parameters based on the monitored status.

48. The messaging system as claimed in any one of claims 1 to 47 wherein the remote processor is configured to receive the data packets on the broadcast channel concurrently with the second device.

49. The messaging system as claimed in any one of claims 1 to 48 wherein the remote processor is configured to store one or more associations between a patient and the at least one first and second devices.

50. The messaging system as claimed in any one of claims 1 to 49 comprising a plurality of first devices and a plurality of second devices each associated with one of a plurality of patients, wherein the remote processor is configured to authorize physiological parameters being passed between patients.51 . A messaging system comprising a remote processor configured to:Initialize broadcast parameters on at least one first device;Initialize transmission parameters configured to receive the broadcast parameters on at least one second device;Wherein the first device and the second device form a private network independent from the remote processor.

52. The messaging system of claim 51 wherein the remote processor does not act as an intermediatory for data packets on the private network.

53. The messaging system as claimed in any one of claims 51 or 52 wherein the at least one first device is a sensor.

54. The messaging system as claimed in any one of claims 51 to 53 wherein the at least one second device is a medical device.

55. The messaging system as claimed in any one of claims 51 to 54 wherein the remote processor is configured to initialize broadcast parameters by connecting to the at least one first device and providing sensor broadcasting parameters to the at least one first device.

56. The messaging system as claimed in any one of claims 51 to 55 wherein the remote processor is configured to initialize transmission parameters by connecting to the at least one second device and providing the transmission parameters.

57. The messaging system as claimed in any one of claims 51 or 56 wherein the remote processor is configured to disconnect from one or more of the at least one first and at least one second devices after initialization.

58. The messaging system as claimed in any one of claims 51 to 57 wherein the remote processor is configured to monitor one or more of the at least one first and at least one second devices after initialization.

59. The messaging system as claimed in any one of claims 51 to 58 wherein the remote processor is configured to confirm the receipt and / or accuracy of data received by the at least one second device.

60. The messaging system as claimed in any one of claims 51 to 59 wherein the private network comprises a broadcast channel on which the first device communicates data packets channel received by the at least one second device.61 . The messaging system as claimed in any one of claims 51 to 60 wherein the at least one first device is not aware of the communication being received by the at least one second device.

62. The messaging system as claimed in any one of claims 51 to 61 wherein the private network is encrypted by parameters in the broadcast parameters and transmission parameters.

63. The messaging system as claimed in any one of claims 51 to 62 wherein further devices can receive communications on the private network but are unable to decode the data packets until initialized with transmission parameters from the remote processor.

Images