WO2022101647A1

WO2022101647A1 - Clinical warning score system

Info

Publication number: WO2022101647A1
Application number: PCT/GB2021/052961
Authority: WO
Inventors: Michael Ross; Andrew Watson
Original assignee: Clews Medical Limited
Priority date: 2020-11-16
Filing date: 2021-11-16
Publication date: 2022-05-19
Also published as: EP4244869A1; GB202017983D0

Abstract

There is provided system for generating a prognostic clinical warning score associated with a patient's physiological condition, said system comprising a sensor array comprising a plurality of sensors for taking a plurality of physiological readings from a patient, said sensor array operable to communicate sensor data corresponding to the physiological readings; and computer-readable instructions which, when executed by a processor, cause the processor to receive the sensor data and additional patient data related to the patient, the additional patient data including the result of a near patient capillary blood test for an inflammatory marker; process data corresponding to the received sensor data and the additional patient data to calculate a clinical warning score, and generate output clinical warning score data corresponding to the calculated clinical warning score.

Description

CLINICAL WARNING SCORE SYSTEM

Technical Field

The present invention relates to systems for generating prognostic indices, such as clinical early warning scores.

Background

Early warning scores such as the Paediatric Early Warning System (PEWS) and National Early Warning System (NEWS) are the widely accepted tools for the early detection and treatment of life-threatening conditions. The timely suspicion and subsequent identification of many significant conditions including Sepsis, Pneumonia and Meningitis, is particularly important because early stages of such conditions can be difficult to differentiate from self- limiting minor illnesses, yet if not suspected and appropriately treated, can very rapidly progress with resulting adverse sequelae, which include long term disability and death. Specifically according to NHS England there are around 250,000 cases of Sepsis alone each year in the UK and at least 46,000 people die as a result of the condition.

PEWS and NEWS use a combination of physiological measurements and structured observational descriptions to compute a numerical score indicating the severity of illness. These scores should be taken sequentially to monitor pattern and trend of illness severity.

This pattern of severity development is also an early warning indicator of prognosis.

Currently, these scoring systems require multiple different physiological and observational measurements using multiple different items of medical equipment. These values are then plotted manually, the location of each point on a graph being translated into a component score, which when added together generate a single overall clinical severity score.

At present this is a process which is expensive, demanding and inefficient of time and resources. Of further concern is that due to the multiple distractions and obstacles that often present themselves within a busy clinical setting the data collection process is often left incomplete. The values that are obtained are then charted manually, risking further human error with the consequent miscalculation of the final score. The effect of the above problems may be, on the one hand, avoidable morbidity, disability and mortality, and on the other, inappropriate escalation of care, with associated avoidable financial costs and iatrogenic adverse side effects.

Thus, although the use of early warning scores should reduce morbidity and mortality, and as a complementary outcome provide reassurance to those patients (and their carers) suffering only from minor self-limiting illness, current scores fail to fully exploit their potential to maximise predictive value of distinguishing minor self-limiting- from early significant conditions.

The embodiments of the invention have several aims. The first aim is to mitigate the problems inherent in the current manual methodology by developing a digital device to support the efficient collection of the necessary data to deliver current prognostic scores. Another is to develop enhanced sensors to generate more accurate readings which will enhance the accuracy and therefore the predictive value of current prognostic scores. The third aim is to create an effective digital platform on which it will be possible to develop enhanced methodologies, using additional data points, to author novel prognostic warning scores, or adapt existing scores, with further enhancement of predictive value . Summary of the Invention

It is an object of certain embodiments of the invention to improve the effectiveness of clinical warning scores.

Aspects of the invention facilitate creation of prognostic indices which utilises patient data obtained from a patient and patient data obtained from a personal medical record system to provide an improved scoring system, having a greater predictive value, for the management of an acutely ill patient.

It is a further object of the present invention to incorporate the features of scoring device to support the creation of a diagnostic system, and to further utilise these processes to create an effective personal medical system with the purpose of recording and monitoring acute illness events.

Various features and aspects of the invention are defined in the claims.

According to a first aspect, there is provided a system for generating a prognostic clinical warning score associated with a patient’s physiological condition, said system comprising a sensor array comprising a plurality of sensors for taking a plurality of physiological readings from a patient, said sensor array operable to communicate sensor data corresponding to the physiological readings, and computer-readable instructions which, when executed by a processor, cause the processor to receive the sensor data and additional patient data related to the patient, process data corresponding to the received sensor data and the additional patient data to calculate a clinical warning score, and generate output clinical warning score data corresponding to the calculated clinical warning score.

Optionally, the additional patient data includes the result of a near patient capillary blood test for an inflammatory marker. This may improve the usefulness and predictive value of the score by providing an indication of the patient's condition over a different (e.g. longer) timeframe than the sensor data. Additionally the result of a near patient capillary blood test for an inflammatory marker may identify additional factors which are known to correlate with illness severity, that otherwise might not be identified by the measurement and use of physiological readings alone. The use of a near patient test, rather than a laboratory test, allows delivery of the relevant inflammatory marker results within a very short timeframe, (in the region of a few minutes), which may allow this additional patient data to complement the real time physiological output of sensors to compute an enhanced Early Warning Score, and thus to facilitate significant alterations in clinical management within an effective time window of opportunity. Additionally the use of a near patient test may also reduce the cost of the system, and provide improved convenience and ease of use.

Optionally, the inflammatory marker is C-Reactive Protein.

Optionally, the result of the near patient capillary blood test is obtained from a lateral flow test device.

Optionally the result of the near patient capillary blood test is obtained from a colorimetric chemical based assay test.

Optionally the result of the near patient capillary blood test is obtained from a standalone electronic reader device.

Optionally, the instructions cause the processor to detect the result of the near patient capillary blood test. Optionally, the result is detected using the output from an optical sensor.

Optionally, the result is detected by analysing the intensity of an indicator line in an image captured using the optical sensor.

Optionally, the additional patient data is received from a user input.

Optionally, the additional patient data is received from a further sensor.

Optionally, the additional patient data is received from a database.

Optionally, the sensors include at least one of a temperature sensor configured to measure a heat flux indicative of a core body temperature, a capillary refill sensor, an ECG sensor, an optical sensor and an acoustic sensor.

Optionally, the optical sensor is a pulse oximetry optical sensor.

Optionally, the acoustic sensor is configured to generate acoustic data corresponding to respiration of a patient.

Optionally, the sensor array is positioned within a disposable envelope.

Optionally, the sensor array comprises a sensor unit configured to be positioned on a supraclavicular site.

Optionally, the sensor array comprises a sensor unit configured to be positioned on an ear site.

Optionally, the sensor array comprises a sensor unit configured to be positioned on a forehead or temple site.

Optionally, the sensor array comprises a plurality of sensor units.

Optionally, the clinical warning score algorithm is at least one of PEWS, NEWS 2, MEWS, POPS and MANChEWS.

Optionally, the instructions cause the processor to monitor clinical warning score trends over time.

Optionally, the instructions include functionality allowing near patient testing data to be processed as the additional patient data by the clinical warning score algorithm.

Optionally, the additional patient data includes the result of at least one of a near patient urinalysis, a near patient capillary blood C-Reactive Protein level, and a near patient capillary blood glucose level.

Optionally, the system further comprises a user device, wherein the user device is configured to receive the sensor data and/or the additional patient data, optionally wherein the user device is configured to receive the data via a wireless connection. Optionally the user device comprises said optical sensor (i.e. the optical sensor used to detect the result of the near patient capillary blood test). The optical sensor may be a camera.

Optionally, the user device is a personal computing device, preferably a smartphone.

Optionally, the system is configured to control the user device to communicate one or more of the clinical warning score data, the additional patient data inputs and the sensor physiological data inputs to a clinical warning score data processing system for further processing to generate output prognostic data.

Optionally, the clinical warning score data processing system is configured to perform a categorisation process. Optionally, the clinical warning score data processing system is configured to generate an alert based on the categorisation process.

Optionally, the user device is configured to transmit the sensor data to the clinical warning score data processing system using an optical code.

Optionally, the additional patient data includes at least one of physiological observational data received via an interface, biometric data, data which relates to medical history, data which relates to social history, data which relates to guided or unguided examination, and patient data received from a database.

Optionally, the additional patient data includes data which relates to symptom detail data. Optionally, the symptom detail data is tracked in real time.

Optionally, the additional patient data includes data which relates to near-patient investigations. Optionally, the near-patient investigations data is received from further medical sensors configured to communicate with the user device.

Optionally, the instructions further cause the processor to carry out a diagnostic function configured to input the clinical warning score data and additional patient data to a diagnostic algorithm and generate output diagnostic data.

Optionally, the instructions cause the processor to communicate the early warning score data and diagnostic data to an application server running a medical record system.

Optionally, the system further comprises a user device which is configured to access the medical record system.

Optionally, the early warning score data and diagnostic data is stored in a database with an associated hazard scale and/or an associated confidentiality scale.

Optionally, the application server includes functionality allowing diagnostic data to be verified/refuted.

Optionally, the instructions further cause the processor to process data corresponding to patient data in accordance with a treatment function and generate the data corresponding to the received patient data for processing in accordance with the clinical warning score algorithm which relates to the treatability of the patient. Optionally, the treatment function comprises a weighting function determined based on the data corresponding to patient data.

According to a further aspect, there is provided a method of generating a prognostic clinical warning score associated with a patient's physiological condition, the method comprising receiving sensor data from a sensor array comprising a plurality of sensors for taking a plurality of physiological readings from a patient and additional patient data related to the patient; processing data corresponding to the received sensor data and the additional patient data to calculate a clinical warning score, and generating output clinical warning score data corresponding to the calculated clinical warning score.

According to a further aspect, there is provided computer-readable instructions which, when executed by a processor, cause the processor to carry out a method of generating a prognostic clinical warning score associated with a patient’s physiological condition, the method comprising receiving sensor data from a sensor array comprising a plurality of sensors for taking a plurality of physiological readings from a patient and additional patient data related to the patient; processing data corresponding to the received sensor data and additional patient data to calculate a clinical warning score, and generating output clinical warning score data corresponding to the calculated clinical warning score. The instructions may be in the form of a computer program, such as software or firmware.

According to a further aspect, there is provided a method of generating a prognostic clinical warning score associated with a patient’s physiological condition, the method comprising receiving physiological data corresponding to a plurality of physiological readings of a patient, and additional patient data related to the patient, processing data corresponding to the received sensor data and the additional patient data to calculate a clinical warning score, and generating output clinical warning score data corresponding to the calculated clinical warning score.

Optionally, the additional patient data may include the result of a near patient capillary blood test for an inflammatory marker,

Optionally, the method may further comprise obtaining the physiological data using a sensor array comprising a plurality of sensors; and communicating the physiological data corresponding to the physiological readings.

Brief Description of the Drawings

Embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings where like parts are provided with corresponding reference numerals and in which:

Figure 1 provides a simplified schematic diagram of a clinical early warning score system arranged in accordance with certain embodiments of the invention;

Figure 2 provides a schematic diagram of primary sensor array in accordance with certain embodiments of the invention;

Figure 3 provides a schematic diagram of an interface provided by a clinical warning score application running on a user device in accordance with certain embodiments of the invention; Figure 4 provides a schematic diagram depicting processing undertaken by an example clinical warning score function in accordance with certain embodiments of the invention;

Figure 5 provides a schematic diagram of an interface provided by a clinical warning score application running on a user device in accordance with certain embodiments of the invention;

Figures 6, 7 and 8 provide schematic diagrams depicting examples of implementations of clinical warning score systems in accordance with certain embodiments of the invention;

Figures 9a, 9b and 9c provide schematic diagrams depicting a secondary sensor array in accordance with certain embodiments of the invention;

Figure 10 provides a schematic diagram depicting a secondary sensor array in accordance with certain embodiments of the invention;

Figure 11 provides a schematic diagram depicting processing undertaken by an example diagnostic function in accordance with certain embodiments of the invention;

Figures 12a and 12b provide schematic diagrams of a system arranged in accordance with certain embodiments of the invention in which an application including a diagnostic function as described with reference to Figure 11 is implemented;

Figure 13 provides a schematic diagram depicting an example of a system in which such an improved personalised medical record system is implemented;

Figure 14 provides a representation of a device having a sensor array for attachment to an ear, and

Figure 15 provides a representation of an arrangement comprising the device shown in Figure 14 secured to an ear.

Detailed Description

Figure 1 provides a schematic diagram of a clinical warning score system arranged in accordance with certain embodiments of the invention.

The system 101 includes a sensor array 102 comprising a plurality of sensors and a clinical warning score data processing system 104. The system may further comprise a user device 103.

In use the sensor array 102 is configured to be placed on a patient such that the plurality of sensors can gather physiological readings from the patient. The sensor array may comprise one or more sensor units. The sensor unit may be configured to be positioned on, for example, a region of a patient’s ear, a supraclavicular site, a forehead site or a temple site of a patient. In some arrangements, the sensor array may comprise more than one such sensor unit so that readings can be taken from multiple locations on a patient. The sensor array 102 may further comprise means via which sensor data corresponding to the physiological readings (physiological readings data) can be communicated to the user device 103.

The user device 103, provided for example by a smart phone, is arranged to receive the sensor data from the sensor array 102 and store the data in memory.

In one arrangement, the user device 103 has running thereon software providing a clinical warning score application. The clinical warning score application is configured to control the user device 103, to present to a user of the user device 103 an interface via which patient data comprising data corresponding to physical observations of the patient to which the sensor array 102 is attached can be entered.

The clinical warning score application is further configured to implement a clinical warning score function. The clinical warning score function receives as input the physiological readings data received from the sensor array and the physical observations received from the user of the user device. The clinical warning score function processes the input data in accordance with a clinical warning score algorithm to generate clinical warning score data corresponding to a clinical warning score.

The clinical warning score application is further configured to convert the clinical warning score data into a format enabling it to be conveyed to the clinical warning score data processing system 104. The clinical warning score application is arranged to control the user device to convey the clinical warning score data to the clinical warning score data processing system 104.

In one arrangement, the clinical warning score data processing system has running thereon software providing a clinical warning score data processing function which is configured to process the clinical warning score data. The nature of the processing of the clinical warning score data depends on the setting in which the system is being used.

It will be understood that the system may process the data and calculate the clinical warning score in other ways than the user device 103. For example, the data may be sent to a server with which is configured to calculate the clinical warning score. Such a server may be implemented locally, or may be a cloud server. In one arrangement, the user device 103 may be omitted, and the sensor data sent to the clinical warning score data processing system 104 from the sensor array, where the clinical warning score application is implemented. In other arrangements, the calculation may be carried out by a processor forming part of the sensor array itself.

Figure 2 provides a simplified schematic diagram depicting a more detailed view of a sensor array 201 arranged in accordance with certain embodiments of the invention and of a type that can be used in a system as described with reference to Figure 1 .

In one arrangement the sensor array 201 comprises a temperature sensor 202, an optical sensor 203 and an acoustic sensor 204. The sensor array further comprises a processor module 205 to which each sensor is connected, and which is configured to process signals from the sensors and to generate corresponding physiological reading data. The sensor array 201 further typically comprises a wireless transceiver 206 which is also connected to the processor module 205. The processor module is configured to communicate the physiological reading data to the wireless transceiver, which is arranged to transmit the physiological reading data to a user device as described above. The sensor array 201 further comprises a power supply 207, typically a suitable electrical battery, to provide electrical power to the components of the sensor array 201 . The components of the sensor array 201 are mounted within a sensor housing 209 which, in use, may be positioned within a disposable envelope. The sensor array 201 is configured so that it can be positioned at a suitable site on the human body to gather the necessary readings.

It will be understood that the particular combination of sensors described above is only one possible arrangement of sensor array, and that other combinations of sensor are possible. For example, temperature sensor 202 may be configured to measure a heat flux. The measured temperature may be indicative of a core body temperature of the patient. Such a sensor may be provided in addition to, or as an alternative to, one or more of the optical sensor and 203 and the acoustic sensor 204. Other sensors, such as a capillary refill sensor, which will be described below, may also be provided.

In one example, the sensor array is configured to be positioned in the supraclavicular fossa site of a patient as indicated in Figure 2.

Configuring the sensor array to be positioned on this supraclavicular site has a number of advantages. In particular, this site is readily accessible even if a patient is fully dressed; it is readily identifiable, even by non-medical personnel; it is not in an intimate area of a patient; it is typically hairless and sweatless, and by virtue of its proximity to the upper lobe of the patient’s lungs, the trachea and the central cardiovascular location of the subclavian artery, it is a particularly suitable site for gathering relevant and accurate physiological readings.

It will be understood that the sensor array may be configured to be positioned at other sites on the patient. For example, the sensor array may be configured to be positioned on an ear site of the patient. The ear site may be any of the ear lobe, the auricle (ear flap), external auditory meatus (ear hole) and mastoid fossa (soft area behind the ear) of the patient. Such an arrangement is described below in the context of a secondary sensor array. However, an ear site sensor array may also be used as a primary sensor array.

The temperature sensor 202 is configured to generate temperature data corresponding to a skin temperature of the patient and communicate this to the processor module 205. The processor module is configured to process this temperature data and generate corresponding temperature physiological data.

The optical sensor 203 is typically a pulse oximetry optical sensor and is configured to generate optical reading data corresponding to a photoplethysmogram (PPG). The optical reading data is communicated to the processor module 205 which is configured to process the optical reading data to generate pulse physiological data corresponding to a pulse (heart rate) of the patient and oxygen saturation physiological data corresponding to oxygen saturation of the blood of the patient.

The acoustic sensor 204 is configured to generate acoustic data corresponding to the respiration of the patient. This acoustic data is communicated to the processor module 205 which is configured to process the acoustic data and generate respiratory rate physiological data.

As described above, the processor module 205 is configured to communicate the temperature physiological data, pulse physiological data, oxygen saturation physiological data, systolic blood pressure physiological data and respiratory rate physiological data to the wireless transceiver 206 for transmission to a user device. The user device can be provided by any suitable computing device typically a personal computing device such as a conventional smartphone, tablet or personal computer such as a laptop. As is well known, such devices include wireless communication transceivers, for example one or more of a Bluetooth or WiFi transceiver.

In some arrangements, the user device 103 may be combined with the clinical warning score data processing system 104.

As described above the clinical warning score application is configured to control the user device to present to a user an interface via which patient data comprising physical observation data can be input. Figure 3 provides a schematic diagram depicting such an interface. The clinical warning score application is typically implemented as software installed and running on the user device. The clinical warning score application may be in the form of an “app”, i.e. a computer program downloaded from a remote server (e.g. “an app store”) to the user device and then installed on the user device. Alternatively, some or all of the functionality performed by the application may be performed remotely on a remote computing device (e.g. a suitable application server) in accordance with conventional distributed computing/cloud computing techniques. In such examples, the software providing the interface on the user device may be provided by otherwise conventional web browsing software (a web browser). It will be understood that the software described above is an example of computer readable instructions which, when executed by a processor, cause the processor to carry out particular steps. It will also be understood that the software functionality may be carried out by other suitable types of such computer-readable instructions, such as firmware.

Figure 3 depicts a conventional smart phone 301 comprising a touch screen display 302. A graphical interface 303, in this case relevant to the “paediatric early-warning score” (PEWS) system, generated by the clinical warning score application, is displayed on the display 302 on which some examples of three data input information boxes 304, 305, 306 are displayed. Each data input information box 304, 305, 306 includes a text data 307, 308, 309 corresponding to a question relating to a physiological observation. In the example shown in Figure 3, the first text data 307 specifies the question: “Is there any difficulty with breathing ?”; the second text data 308 specifies the question: “How conscious is the patient?” and the third text data 309 specifies the question: “Is the patient receiving oxygen therapy?”.

Furthermore, in each data input information box, a number of graphical elements are displayed corresponding to potential answers to the question displayed in the data input information box.

Specifically, in the first data input information box 304, four graphical elements are provided. The first graphical element 310 specifies the answer: “None”; the second graphical element 311 specifies the answer: “Mild accessory neck muscle activity or ribmuscle retraction”; the third graphical element 312 specifies the answer: Moderate accessory neck muscle activity or rib muscle retraction”; and the fourth graphical element 313 specifies the answer: “Severe accessory neck muscle activity or rib muscle retraction.

In the second data input information box 305, four graphical elements are provided. The first graphical element 314 specifies the answer: “Alert”; the second graphical element 315 specifies the answer: “Responds to verbal stimulus”; the third graphical element 316 specifies the answer: “Responds to pain stimulus”; and the fourth graphical element 317 specifies the answer: “Unresponsive”.

In the third data input information box 305, two graphical elements are provided. The first graphical element 318 specifies the answer: “Yes” and the second graphical element 319 specifies the answer: “No”. The interface 303 is arranged such that a user can select one of the graphical elements from each data input information box. For example, the user can generate a touch input by touching an area of the touch screen display 302 which corresponds to a graphical element. In this way, the clinical warning score application can receive physical observation data from a user of the smart phone 301.

For the example, depicted in Figure 3, the clinical warning score application will receive three physical observation data inputs from a user, one corresponding to the way the patient is breathing, one corresponding to how conscious the patient is and one corresponding to whether or not the patient is receiving oxygen therapy.

The clinical warning score application performs a clinical warning score function which is described further with reference to Figure 4.

Figure 4 provides a schematic diagram depicting processing undertaken by an example clinical warning score function in accordance with certain embodiments of the invention. As described above, the physical observation data inputs are received via the interface on the user device and the sensor physiological data inputs are received via a wireless connection with the sensor array. This data is input to a clinical warning score algorithm which generates an output clinical warning score.

Typically, the clinical warning score algorithm corresponds to an “early warning” score system, for example the “NEWS 2” score system, in which each of the inputs from the physical observation data inputs is allocated a value, and each of the sensor physiological data inputs is allocated a value and an aggregate score of all of these values is generated to produce a clinical warning score. The higher the clinical warning score, the more serious the condition of the patient.

Examples of other suitable “early warning” score systems on which the clinical warning score algorithm could be based include the NHS PEWS (Paediatric Early Warning Score), MEWS, POPS and MANChEWS scoring systems.

In certain embodiments, the clinical warning score application is configured to display the clinical warning score on the interface. An example of this is shown in Figure 5. As can be seen in Figure 5, the graphical interface 303 generated by the application includes a graphical element which displays text data 501 showing the clinical warning score and further text data 502 specifying what action is recommended as a consequence of computing any clinical warning score.

As described above, the clinical warning score application is configured to control the user device to communicate one or more of the clinical warning score, the physical observation data inputs and the sensor physiological data inputs to a clinical warning score data processing system which is arranged to process this data in accordance with a setting in which the system is used.

Figure 6 provides a schematic diagram depicting an example of an implementation of a clinical warning score system in accordance with certain embodiments of the invention. The clinical warning score system is implemented in a hospital setting such as on a ward or an accident and emergency department.

A plurality of patients 601 are present, for example on a ward, each of whom have attached a sensor array 602 as described above. Medical personnel 603, such as a nursing staff, operate a user device 604 such as a tablet or smart phone on which is running a clinical warning score application of the type described above. Sensor data is transmitted from each sensor array 602 to the user device 604. The sensor data transmitted from each sensor array includes data identifying from which sensor array (and thus which patient), the sensor data is being transmitted. The interface provided by the clinical warning score application allows the medical personnel 603 to enter into the user device, via an interface, physiological observation data associated with each patient. The clinical warning score application running on the user device is arranged to perform a clinical warning score process as described above on the sensor data from each sensor array 602 and the corresponding physiological observation data to generate a clinical warning score for each patient.

The clinical warning score system further includes a clinical warning score data processing system 605 which comprises a computer system 606 (for example one or more computing devices, such as personal computers, connected via a data network) on which is running clinical warning score data processing software, and a wireless transceiver 607, provided, for example, by a WiFi access point.

The clinical warning score application running on the user device 604 is configured to periodically transmit the clinical warning score data (and optionally the sensor data and the physiological observation data) to the computer system 606 of the clinical warning score data processing system 605 via the wireless transceiver for processing by the clinical warning score data processing software. The clinical warning score data processing system is arranged to process the clinical warning score data for each patient, for example providing via a display unit a representation of the clinical warning score of each patient. The clinical warning score data processing system may further be configured to generate an alert signal - for example transmitting a message to a user device of further medical personnel, for example a smartphone of a doctor, in the event that a clinical warning score for a patient reaches a predetermined number or deteriorates by predetermined ratio.

Figure 7 provides a schematic diagram depicting another example of an implementation of a clinical warning score system in accordance with certain embodiments of the invention. The clinical warning score system is implemented in a setting in which medical personnel interact with a patient on a “one-on-one” basis, such as a paramedic treating a patient in an ambulance on the way to a medical facility such as a hospital.

Treatment is being given to a patient 701 by medical personnel 702, such as a paramedic, in a vehicle 703 such as an ambulance on the way to hospital. The paramedic 702 attaches a sensor array 704 of the type described above to the patient 701 to collect sensor data which is received by a user device 705 such as a smartphone running a clinical warning score application which is operated by the paramedic 702. The paramedic also inputs physiological observation data into the user device as described above. The clinical warning score application running on the user device is arranged to perform a clinical warning score process as described above on the sensor data from the sensor array 704 and the corresponding physiological observation data to generate a clinical warning score for the patient 701 .

The clinical warning score application controls the user device 705 to transmit the clinical warning score data (and optionally the sensor data and the physiological observation data) to a clinical warning score data processing system 706 located at a medical facility such as the hospital where the patient is to be treated, via for example a connection with a cellular mobile telephone network (not shown).

The clinical warning score data processing system 706 is arranged to process the clinical warning score data for the patient, and generate an alert signal - for example transmitting a message to a user device of further medical personnel, for example a smartphone of a doctor, in the event that a clinical warning score for the patient reaches a predetermined number or deteriorates by a predetermined ratio. In this way, medical personnel at the hospital can be forewarned of the severity of the illness of the patient before they arrive without the need for this information to be conveyed directly from the paramedic 702.

In one example, the clinical warning score application running on a user device is configured to encode one or more of the clinical warning scores, comprising the physical observation data inputs and the sensor physiological data inputs as an optical code, such as a bar code or two dimensional matrix code such as a QR (Quick Response) code. The clinical warning score application is configured to display the optical code on the graphical interface. The optical code can be read by a suitable optical code reader connected to the clinical warning score data processing system. Alternatively, or in addition, clinical warning score data may be inputted into electronic patient records by or using the user device.

Figure 8 provides a schematic diagram depicting an example of a clinical warning score data processing system. A user device

801 has running thereon a clinical warning score application as described above which is configured to generate an optical code

802 encoding the clinical warning score, the physical observation data inputs and the sensor physiological data inputs collected as described above. A clinical warning score data processing system 803 comprises a computer system 804 which has running thereon software adapted to decode the data (e.g. the clinical warning score, the physical observation data inputs and the sensor physiological data inputs) and process this data.

In one example, the processing comprises a categorising process in which the data is processed to determine whether or not the patient from whom the data has been gathered is potentially seriously ill and to generate a corresponding alert. The computer system is arranged to generate and display the alert message on a display unit 805 connected to the clinical warning score data processing system 803.

In one example of use of the system described in Figure 8, a sensor array of the type described with reference to Figure 2, is attached to a patient such as an infant by a carer of the infant, for example the infant’s parent. The parent of the infant has the clinical warning score application installed on their smartphone and uses this to collect the sensor physiological data from the sensor array and to input the physical observation data as described above. If the clinical warning score determined by the clinical warning score application and displayed on the interface of the parent’s smartphone indicates that the infant is particularly ill, or if the infant’s parent is particularly concerned, the parent can take the child to a medical facility, for example a hospital. A clinical warning score data processing system as described with reference to Figure 8 is present at the medical facility. On arrival, the parent can scan the optical code using the scanner of the clinical warning score data processing system. In the event that the clinical warning score data encoded in the optical code indicates that the infant might be seriously ill, an alert message is generated as described above, which can be used to alert medical staff to prioritise examination of the infant.

In the embodiment described with reference to Figure 2, the sensor array comprises a primary sensor array which, in use, is configured to be positioned on the supraclavicular site. The provision of a sensor array described with reference to Figure 2 and positioned on the supraclavicular site advantageously provides the physiological reading data necessary for calculating a clinical warning score in accordance with the NEWS 2 clinical warning score system.

However, in certain embodiments, the sensor array comprises further sensors. In particular, these further sensors may be located in a secondary sensor array which is separate, but connected to, the primary sensor array or the user device and may be provided to facilitate using a clinical warning score algorithm based on a particular clinical warning score system. The primary sensor array and the secondary sensor array may be arranged to share a power supply and may be connected to each other or to the user device by respective wires. This may help ensure that the sensor arrays remain coupled to each other and/or the user device. In other arrangements, the primary and secondary sensor arrays may be configured to communicate wirelessly with each other, or to communicate wirelessly with the user device individually.

Specifically, in one embodiment the sensor array further comprises a secondary sensor array. For example, for determination of a PEWS (paediatric early warning system) score, the secondary sensor array includes a remote capillary refill sensor arranged to conduct a capillary refill test.

In a further embodiment, the sensor array further includes an optical sensor, as a substitute for the capillary refill sensor, to generate relevant microvascular flow data.

In one arrangement, the secondary sensor array is in the form of a clip to be connected to a site on a patient’s ear. Figure 9a provides a schematic diagram depicting a secondary sensor array including a remote capillary sensor in accordance with certain embodiments of the invention.

A secondary array 901 comprises spring loaded clip biased into a closed position. Mounted within the clip is a mechanical actuator unit 902 and a capillary refill detector unit 903. The secondary array 901 further includes a controller unit 904 which is connected to the mechanical actuator unit 902 and the capillary refill detector unit 903. The controller unit 904 is connected to the data processor module of the sensor array via a suitable data link provided, for example by a wire connection.

As depicted in Figure 9b, in use the secondary array 901 is clipped to a patient’s ear site, and when activated, under the control of the controller unit 904 the mechanical actuator unit 902 moves a compression arm into the ear site for a predetermined period of time. After the predetermined period of time has elapsed, the mechanical actuator unit 902 withdraws the compression arm as depicted in Figure 9c. The capillary refill detector unit 903, which typically comprises an optical sensor comprising a light source, such as an LED and a corresponding photodetector or image capture device, is arranged to then illuminate the ear lobe and measure the reflected light and generate a signal when the light received by the photodetector indicates that capillaries in the region of the ear site subject to compression by the compression arm have refilled. The signal is communicated to the controller unit 904. The controller unit communicates capillary refill time data to the data processor module of the primary sensor array which then generates capillary refill physiological data corresponding to the capillary refill time of the patient which is then communicated to the user device as described above.

In certain embodiments, the secondary sensor array comprises a further pulse oximetry optical sensor configured to generate optical reading data corresponding to a photoplethysmogram (PPG). In certain embodiments, the further pulse oximetry sensor is mounted on the clip of the secondary sensor array. Such an embodiment is depicted schematically in Figure 10.

A further pulse oximetry sensor 1002 is mounted to the clip of a secondary sensor array 1001 corresponding to that described with reference to Figures 9a, 9b and 9c in such a way that PPG optical reading data can be collected from the patient’s ear site. The further pulse oximetry sensor 1002 is connected to the controller unit of the capillary refill sensor 1001 which is arranged to communicate the PPG optical reading data to the data processor module of the sensor array.

The data processing module of the primary sensor array is arranged to process the PPG optical reading data from the first pulse oximetry sensor located in the primary sensor array (e.g. that shown in Figure 2) with the PPG optical reading data from the further pulse oximetry sensor 1002 located in the secondary sensor array to generate systolic blood pressure physiological data corresponding to a systolic blood pressure of the patient. Typically, this is achieved by using parameters of the PPG optical reading data, such as parameters of detected waveforms, to calculate blood pressure.

In certain embodiments, the secondary sensor array further comprises an ECG sensor. This is depicted in Figure 10 which shows an ECG sensor 1003 incorporated in the clip of the secondary sensor array which is also attached to the controller unit. The ECG sensor is configured to collect electrical signals from the patient’s ear site corresponding to the initiating cardiac electrical event of the patient.

The electrical signals collected by the ECG sensor are communicated to the controller unit of the secondary sensor array and then communicated to the data processor module which is arranged to process these signals to generate ECG physiological sensor data to communicate to the user device. The ECG physiological sensor data can also be used by the data processor module of the sensor array to further process the PPG data from the PPG optical sensors to more accurately generate the systolic blood pressure physiological data. For example, the ECG physiological sensor data may provide more accurate timing data relating to the detection of cardiac output pressure fronts as described above. Additionally, the ECG physiological sensor data can be used to identify abnormal cardiac rhythms, and, for example, changes in cardiac outputs consistent with a myocardial infarction (heart attack).

Although the sensor array 901 is described above as a secondary array, it will also be understood that such an array may be used as a standalone or primary array. That is, an array configured to be attached to an ear site may be used as the only sensor array in the system, or as a primary array with another sensor array.

Further types of sensors can be used in the primary and or secondary sensor array. In other examples, a further temperature sensor may be provided in the secondary array. Such secondary temperature sensors may advantageously improve the accuracy with which patient temperature is measured by providing a second point on the patient at which it is measured.

Figure 14 shows a device 1401 for attachment to an ear having a sensor array. The device 1401 is a clip which comprises a first jaw 1402 and a second jaw 1403 which are hinged with respect to each other. A resilient element 1404 in the form of a spring is disposed between respective pressing portions 1405, 1406 which extend from the jaws 1402, 1403 and arranged to urge the first and second jaws 1402, 1403 towards each other. The first jaw 1402 is provided with a LEDs 1407 and 1410 which are configured to emit red and infrared light for determination of oxygen saturation and pulse monitoring respectively, a laser emitter 1408 and a camera 1409 for determination of microvascular blood flow, The second jaw 1403 is provided with a sensors 1411 and 1412 which are configured to sense red and infrared light to determine oxygen saturation and pulse respectively.

Figure 15 shows the device 1401 clipped to the ear lobe (as an example of an ear site) of a patient and connected to a neckmounted control unit 1413. The control unit 1413 comprises a power supply together with a controller for controlling the sensor components of the device 1401 and a processor for processing output signals which originate from the sensor components of the device 1401. The control unit 1413 further comprises a temperature sensor which is configured to measure a temperature flux that corresponds to a core body temperature. Advantages of locating the sensors at the ear of a patient are that a good PPG signal can be obtained, and that the ear is relatively hairless and accessible which makes fixing the device 1401 in a correct position simple and repeatable. The advantage of positioning the temperature sensor on the neck and/or head is that it lies in close proximity to the major arteries of the neck thus reflecting core body temperature.

In certain embodiments the clinical warning score application running on the user device is provided with further functionality.

For example, in certain embodiments the clinical warning score application includes a configurable trend monitoring process which is arranged to monitor changes in the clinical warning score generated for patients over a period of time. Specifically, the clinical warning score application is arranged to periodically receive further sensor physiological data from the sensor array and prompt the user to provide further physical observation data from which further clinical warning score data can be generated.

The trend monitoring process can be configured to identify gradual changes and more sudden changes in the clinical warning score for a patient indicative of a change of clinical status of the patient’s condition.

In certain embodiments, the trend monitoring function is configured to control the user device to display on the interface clinical management advice based on the changes in the clinical warning score of the patient, for example suggesting that the patient is brought to the attention of a relevant and qualified medical professional. Responsive to changes in the clinical warning score of the patient, the trend monitoring function may be further configured to display on the interface a recommendation to increase the frequency with which the user provides further physical observation data.

In certain embodiments, the clinical warning score application is provided with further functionality enabling a user of the user device to enter additional patient data (i.e. data obtained separately from the sensor array). In other words, the additional patient data is derived from other means than the sensor device. In some arrangements, a user may manually enter (and thus the application may receive), via an interface of the type described with reference to Figure 3, additional information beyond simple physiological observation data. Alternatively or additionally, the patient data may be received from another sensor and/or retrieved from a database.

Such additional patient data may relate to near patient tests. A near patient test is also known as a point of care test, and is a test which does not require the use of laboratory equipment or skilled laboratory professionals in order to obtain the result. For example, a near patient test (both the obtaining of a sample and the obtaining of the result) may be carried out at a bedside in a hospital setting, in a doctor’s surgery, in a home setting or in any other location. This has the advantage that the test is cheaper, quicker and easier to carry out than a test which requires the use of a laboratory.

One example of a near patient (or point of care) test is a lateral flow test. Another example is a device containing a rapid result colorimetric chemical based assay. Afurther example is a test carried out using a standalone electronic device. Such a standalone electronic device may be hardware arranged to interpret the visual output of another test device to detect result (using, for example, an optical sensor), display or print the result, and/or communicate the result to other devices. Such a standalone electronic device may either be a dedicated device, specifically designed to provide this functionality, or this functionality may be implemented on another device, such as a smartphone. In some arrangements, the standalone electronic device may be the same device as is used to calculate the warning score. It will also be understood that results from more than one type of near patient test may be combined. Such near patient tests include, for example, results of a urinalysis test, results of a blood sugar test (such as a capillary blood glucose level), and results of a capillary blood test for an inflammatory marker, such as capillary blood C-Reactive Protein level (CRP) tests. It will be understood that near patient capillary blood tests for other inflammatory markers may also be used, and that the results of multiple tests for different inflammatory markers may be used together to compute an Early Warning Score.

As explained further below in relation to C-Reactive Protein (CRP) level, when the additional patient data includes the result of a near patient capillary blood test for an inflammatory marker, the predictive value of resulting clinical warning score may be improved. This is because the inflammatory markers may provide an indication of the condition of the patient over a longer time frame. That is, the inflammatory marker detected by the near patient capillary blood test might typically vary over a period of anywhere from 3-4 hours, to 1-2 days, depending on the particular marker. On the other hand, the physiological readings obtained by the sensor array would typically vary over a shorter timeframe. Thus, by combining readings which vary (and provide an indication of the patient’s condition and/or prognosis) over different timeframes, the usefulness and predictive value of the score may be improved.

Additionally the result of a near patient capillary blood test for an inflammatory marker may identify additional factors which correlate with illness severity that otherwise might not be identified by the detection and use of physiological readings alone. In other words, the various results (i.e. from the sensor, the result of a near patient capillary blood test, and optionally other additional patient data as described herein) may be used to “triangulate” an improved warning score and/or to refine the result of an existing warning score.

Further still, the use of a near patient test, rather than a laboratory test, may allow delivery of the relevant inflammatory marker results within a very short timeframe, of the order of several minutes, rather than several hours (or more) in the case of a laboratory test. This may allow this additional patient data to complement the real time physiological output of sensors to compute an enhanced early warning score, and thus to facilitate significant alterations in clinical management within an effective time window of opportunity. In other words, the use of a near patient test may allow changes in inflammatory markers to be measured and incorporated into the warning score quickly, in order to take account of the condition of the patient. On the other hand, if a laboratory test is used, the results are significantly slower, and the results of the test may no longer be as relevant when the result is obtained (because of the time elapsed between the test and the result), which may mean that the input into the warning score from that test is less relevant and/or useful, and that further changes to the condition and/or prognosis of the patient may have occurred in the meantime.

Data from a near patient urinalysis test in respect of the quantitative presence of one or more of protein, glucose, blood, ketones, leukocytes, nitrites, abnormal pH, abnormal Specific Gravity, bilirubin and excess urobilinogen may be used as additional patient data. The co-existence of specific abnormal constituents in the urine is likely to have a detrimental effect on prognostic outcome. Some of these abnormal constituents, such as ketones, may relate to levels of severity of illness. Others, such as protein or blood, may relate to possible underlying illness, either diagnosed or undiagnosed. Thus, knowledge of the presence or absence of such factors, and their incorporation into the early warning score, may improve the usefulness and predictive value of the score.

C-Reactive Protein (CRP) level is a highly responsive and sensitive indicator of a biochemical response to inflammation. Such inflammation may be caused by bacterial infection, malignancy and auto immune conditions. The response typically is within a time frame of 3-4 hours. Thus, the incorporation of a CRP level into the early warning score as additional patient data can, combined with vital signs observation, provide an indication of both current prognosis and biochemistry factors. This may improve the usefulness and predictive value of the score.

Blood glucose levels can be high in acute conditions such as myocardial infarction and diabetes. Levels can be low in bacterial conditions such as meningitis or septicaemia. Thus, the incorporation of a blood glucose level into the early warning score as additional patient data can, combined with vital signs observation, provide an indication of both current prognosis and biochemistry factors. This may improve the usefulness and predictive value of the score.

In some arrangements, the clinical warning score application may also include functionality which allows the result of a near patient test (such as a near patient capillary blood test, including but not limited to a test for inflammatory markers) to be detected by the application. For example, the user device may include an optical sensor such as a camera. The optical sensor may be used to detect the result of the test.

For example, in a near patient test, such as a lateral flow test or urinalysis test, the result of the test may be indicated by the presence or absence of an indicator line on the test device. The presence or absence of the indicatory line may provide a binary result, such as an indication of whether the result is positive or negative, an indication of a value in relation to a threshold. The clinical warning score application may contain functionality to detect the presence or absence of such a line. This functionality may use image recognition. For example, the application may receive an image of the test device (either from an optical sensor of the user device, or from another source such as a database or other separate imaging device) and detect the result of the test from the image.

In addition to the presence or absence of an indicator line, this functionality may also provide a quantitative result rather than a binary result. For example, the intensity or colour of an indicator line may be detected from an image, and converted into a numerical result by the clinical warning score application or by a separate application.

In the above arrangements where the result is detected by the application, regardless of whether a positive/negative result or a quantitative result, the result can be incorporated into the calculation of the clinical warning score. This may result in both improvement of accuracy, usefulness and predictive value of the warning score, and increased convenience and lower cost.

Although an ECG sensor is described above in relation to data collected by the sensor array, ECG measurements may also be obtained separately from the sensor array and incorporated into the early warning score as additional patient data. The use of an ECG measurement (either by the sensor array, or as additional patient data) may have several benefits. It may establish, if present, a diagnosis of atrial fibrillation which may cause artefacts in the readings of pulse rate and blood pressure. Having such a diagnosis may allow such artefacts to be taken into account in the calculation of the score. Further, co-morbidity of a heart condition is likely to have an detrimental effect on prognostic outcome. Thus knowledge of such factors is may improve the usefulness and predictive value of the score.

It will be understood that the above examples of additional patient data may be incorporated into existing early warning scores (such as PEWS or NEWS), or may be used with other measurements (such as the sensor data) to produce new early warning score. The provision of this additional patient data relating to the results of near patient tests means that improved clinical warning score algorithms can be used by the clinical warning score function because this additional patient data can also be attributed a value and used in the calculation of the clinical warning score. For example, the presence of urinary ketones are an indicator of dehydration and level of fever. Low blood sugars may be an indicator of septicaemia and high levels of blood sugar may be an indicator of high cortisol levels associated with pathological stress situations.

This set of additional datapoints will facilitate the generation of improved quality of clinical early warning scores and other prognostic indices.

In certain examples, rather than this additional information being input to the user device manually, instead, the application may control the user device to receive, the information wirelessly, for example via medical test equipment provided with wireless communication means.

In certain embodiments, the application is arranged to control the sensor array to generate multiple readings from each sensor before clinical warning score data is generated. For example, each sensor reading may be recorded and used at least five times over 30 seconds, for example, to reduce errors arising due to regression to the mean.

In the absence of an existing working diagnosis the availability of a clinical early warning score which is a measure of illness severity may in certain situations provide circumstantial evidence to indicate a ‘more likely’ diagnosis.

For example, an infant with symptoms of a respiratory infection and a low PEWS score suggests an upper respiratory infection but an infant presenting with respiratory symptoms with a high PEWS score is likely to indicate something more serious such as pneumonia. This process however does not replace the procedure for arriving at a formal diagnosis comprising the inclusion of all the relevant data points and issues which are listed below.

In the context of having the benefit of a known diagnosis the additional benefit of a co-existing Early Warning Score confers additional reassurance by creating a more tightly controlled clinical information environment by the monitoring of the fluctuating severity within the context of a known diagnostic condition.

Thus further embodiments of the application running on the user device may be enhanced by the provision of a diagnostic function, such as a differential diagnostic function, which receives as inputs the output clinical warning score from the clinical warning score function as described above in addition to other relevant clinical patient data (additional patient data) as now described and data from all of the above relevant sources. The diagnostic function processes the clinical warning score data and the additional patient data and the data from the above relevant sources in accordance with a diagnostic algorithm to generate output diagnostic data.

The output diagnostic data corresponds to a ‘most likely’ or differential diagnosis to account for a presentation of a given set of symptoms in combination with the data from the relevant sources. Figure 11 provides a schematic diagram depicting processing undertaken by an example diagnostic function implemented by an application running on a user device in accordance with certain embodiments of the invention. One or more types of predetermined additional patient data is received by the user device and input to a diagnostic algorithm. At the same time, data including output clinical warning score data from the clinical warning score function is also input to the diagnostic algorithm. The diagnostic score algorithm implements a Bayesian diagnostic function in which, based on the input data including clinical warning score and the input additional patient data, the likelihood of a number of diagnoses is determined. The diagnosis that the Bayesian diagnostic function determines is most likely is output as diagnostic data and display, for example, on the display screen of the user device. As will be appreciated, each additional element of additional patient data corresponds to a further “data point” to be processed by the Bayesian diagnostic function, and therefore increases the accuracy of the likely diagnosis associated with the diagnostic data.

The combination of having the benefit of a ‘most likely’ diagnosis and the additional benefit of an individual or series of co-existing early warning scores confers very significant additional clinical precision by supporting the monitoring the fluctuating illness severity within the context of the most likely diagnostic condition.

The combination of ‘most likely diagnosis' and early warning scores is a novel prognostic indicator, which may be termed herein 'the ‘diagnosis-specific’ prognostic score. This score will be calculated by comparing of the usual natural history of a specific illness for previous similar patients with the same diagnosis correlated with relevant early warning scores for this episode for the same condition.

As is explained in more detail below, the additional patient data to be used by the diagnostic function can come from a number of different sources. For example, the additional patient data can be entered directly to the user device, via a suitable interface; can be provided by further sensors wirelessly connected to the user device (i.e. further medical sensors other than those forming part of the sensor array), or can be retrieved from a patient data database including with permission the patient’s own health care record managed by medical professionals.

As is explained in more detail below, the additional patient data entered directly to the user device can include biometric data, symptom detail data collected in a structured format, real-time symptom diary data, physical sign information data derived from guided or unguided self-examination, and data associated with results of near-patient investigations.

In certain embodiments, the application comprises functionality which prompts a user to manually enter, via a suitable interface, data corresponding to certain types of additional patient data. Examples are detailed below and it will be understood that embodiments of the invention can be configured to process one or more or any combination of the following types of additional data. The interface via which the additional patient is manually entered can correspond substantially to that described with reference to Figure 3, comprising, for example graphical elements that can display questions to be answered/information to be input and provide further graphical elements that can be selected by a user to enter answers to predetermined questions. Further graphical elements may enable a user to enter alphanumeric characters to provide data that needs to be entered via text and/or number such as a patient's weight or height.

In certain embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, data relating to biometric data which includes information such as the weight, height, age and ethnic origin of a patient.

In certain embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, data relating to symptom data. Symptom data relates to further physical observations relating to a patient. In some examples the additional patient data relating to symptom data is in the form a structured conditional questionnaire, presented to a user of the application via the interface and comprising questions to which a yes/no answer can be provided, and the answer to which determines follow up questions. Examples of the way in such a conditional question structure can be arranged is as follows:

Is the patient coughing? If yes is there any sputum? If yes, what is the colour of the sputum? Is the patient vomiting? If yes, is there any blood? Does the patient have a runny nose? If yes, is the discharge clear? Does the patient have poor feeding? If yes, when did the patient last feed? Does the patient have pain on passing urine? If yes, is the pain early or late in the micturition process? Does the patient have pain on inspiration? If yes, where is the pain? Does the patient have chest pain? If yes, is the pain acute onset? Which side is the chest pain?

As will be appreciated by the preceding examples, such conditional sequence questioning leads to a series of contingent answers which can form additional patient data.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, “in real time” symptoms as they present in the form of a diary. This enables the delivery of a more accurate profile of both the presence of symptoms and the temporal progression of various symptoms.

In some embodiments, the application is provided with functionality which enables a user of the application to enables a user of the application to enter, via the interface, data relating to previous medical history of the patient.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to the social history of the patient such as employment status and educational levels achieved.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to the social history of the patient such as alcohol, tobacco and street drugs used.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to clinically relevant medication history.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to clinically relevant allergy history.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to clinically relevant family history, with easy user interface to indicate precise relationship, to include both diagnoses of individuals and the results of genetic analysis.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to further physical examinations. In certain such embodiments, the application is provided with functionality that controls the user device to display guided examination and/or self-examination advice providing the user with instructions to conduct examinations and to thereby provide further physical observation data. Typically, the guided examination advice is in the format of videos or via a sequence of suitable diagrams.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to near patient medical test results including, pregnancy test, detailed eight parameter dipstick urinalysis results and capillary blood sugar will all provide extra important data points to assist the formulation of a preferred- or differential diagnosis.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to genetic information of the patient and also of genetically related relatives.

In one embodiment these results are inputted manually. In a further embodiment these results are transmitted wirelessly to the receiving station and then made available either to a clinician for consideration and/or presented to a system capable of Artificial Intelligence for analysis and interpretation.

In some embodiments, the application is provided with functionality which enables a user of the application to enter, via the interface, patient data relating to data output from further sensors i.e. further medical sensors other than those forming part of the sensor array and not connected to the sensor array.

In certain embodiments the application is arranged to control the user device to receive further additional patient data from further sensors. The further sensors may be part of a sensor array of the type described above or may be separate from the sensor array. In keeping with the sensors of the sensor array, the further sensors are arranged to communicate sensor data, typically via a wireless link, to the user device operated by medical personnel. Examples of the further sensors include ECG probes, attachable skin and mouth cameras, digital stethoscopes, ultrasound probes, peak expiratory flow meters, still and video cameras.

In certain embodiments, the application running on the user device is configured to retrieve patient data from a patient data database. The patient data stored on the patient data database includes different types of patient data including medical history data, medical examination data, patient investigation result data and patient genetic information data.

Example medical history data includes data relating to structured relevant retrospective symptom questionnaires, real time symptom diaries, previous medical history, family history, medication and allergy history social history, and lifestyle history. Some or all of this data may have been exported from an external medical record associated with the patient. Examples of medical examination data include biometric data such as height and weight. Examples of near patient investigation result data includes data associated with urinalysis and random capillary sugar investigations. Examples of genetic Information data include data relating to genetic investigations conducted on the patient and on members of the patient's family.

Figures 12a and 12b provide a schematic diagram of a system arranged in accordance with certain embodiments of the invention in which an application including a diagnostic function as described with reference to Figure 11 is implemented and running on a user device 1201 . These figures also incorporate elements shown in Figure 6, which are described above.

The application running on the user device 1201 is configured to receive physiological data from a sensor array 1202 of the type described above and physical observation data entered via a user of the user device and generate a corresponding clinical warning score using the clinical warning score function as described above.

The application is further configured to receive patient data manually entered by a user of the user device via an interface 1203; patient data from one or more further sensors 1204 which communicate wirelessly with the user device 1201 (and do not form part of the sensor array 1201) and patient data retrieved from a patient information database 1205. The clinical warning score generated by the clinical warning score function and the patient data are input to the diagnostic function to generate output diagnostic data.

The patient information database 1205 is connected to a computer system 1206 on which is running clinical warning score data processing software as described above. The software running on the computer system 1206 is arranged to retrieve patient information data from the patient information database 1205 and communicate it to the user device 1201 for processing by the diagnostic function of the application running on the user device 1201.

The patient information data received via the computer system 1206 from the patient information database 1205, the additional sensor data received from the further sensors 1204 and the manually entered patient data entered via the interface together form the additional patient data which is processed along with the clinical warning score data by the diagnostic algorithm to generate diagnostic data.

The following provide examples of diagnostic data corresponding to a likely diagnosis generated by the diagnostic function based on input clinical warning score data and input additional patient data.

Additional Data

Techniques in accordance with examples of the invention can be used to facilitate the creation of an improved personalised medical record system.

Figure 13 provides a schematic diagram depicting an example of a system in which such an improved personalised medical record system is implemented.

Figure 13 shows a user device 1301 of the type described above and on which is running a diagnostic application as described above. The diagnostic application is arranged to receive data relating to patient including sensor data, physiological observation data and additional patient data as described, for example, with reference to Figure 12 (e.g. patient information data extracted from a patient information database, further manually entered patient data and further sensor data). The diagnostic application provides a clinical warning score function for generating clinical warning score data and a diagnostic function for generating diagnostic data. The diagnostic application is further configured to communicate, via a suitable wireless access point 1302 and data network 1303, the data received relating to a patient and the data generated relating to the patient (e.g. the diagnostic data and the clinical warning score data) to an application server 1304 on which is running patient data record management application. The patient data record management application is arranged to process the data relating to the patient received from the user device 1301 to generate a patient data record. The patient data record includes, in a suitably organised format, data collected at the user device and communicated to the application server 1304. In this way, the patient data record can include data relating to a patient that includes: patient data extracted from one or more patient information databases (e.g. medical history data, medical examination data, patient investigation result data and patient genetic information data); diagnostic data generated by a diagnostic function and clinical warning score data generated by a clinical warning score function. Typically, the diagnostic data and clinical warning score data will be associated with a record of the data used at the time to generate the particular clinical warning score and particular diagnostic data. The diagnostic data and clinical warning score data will also typically be associated with a time stamp indicative of a date and time at which this data was generated.

The system depicted in Figure 13 includes a further user device 1305, for example a personal computing device such as a personal computer such as a desktop or laptop, tablet, smart phone, smart television etc, which is connected via the data network 1303 to the application server 1304. The further user device 1305 has running thereon suitable client software (for example a web browser) providing an interface enabling an authorised user of the user device (for example a patient or patient’s carer) to access, via the patient data record management system, the patient data record stored on the application server 1304. Such access is typically controlled by conventional information security techniques such as a user account and password to be established and authenticated before access is granted.

The client software running on the further user device 1305 operating in conjunction with the patient data record management system is configured to enable the patient data record to be viewed on the further user device 1305. In certain embodiments, further functionality is provided, for example enabling the user of the further user device 1305 to associate elements of the patient data record with a specific value on a confidentiality scale. For example, such a scale may include 10 values: 1 meaning that the patient data in question can be shared with anyone; 3 meaning that the patient data can be shared only with medical personnel; 6 meaning that the patient data can be shared with medical personnel only with explicit consent of, for example, the patient, and 10 meaning that patient data must never be shared, but with a flag in the record indicating that an item of confidential information has been withheld. In certain examples, this functionality is configured to automatically assign elements of the patient data record with a value on the confidentiality scale based on a coding classification system. For example, where appropriate, the patient data can be associated with a patient data type, and each patient data type is assigned a confidentiality value on the confidentiality scale. For example, data pertaining to a patient’s medical record associated with an orthopaedic fracture may be assigned a lower confidentiality score than gynaecological operations.

The patient data record may represent a personal medical sickness record both fully owned and completely controlled by the patient or nominated carer. Thus the contents, organisation and distribution of the personal medical sickness record will be fully determined by the patient or designated carer.

To support the lay member of the public being able to navigate and organise this record the system will provide essential organisational informatic tools as described below.

Each data items will be flagged with specific qualifiers to assist internal organisation of the record and the subsequent control of outside distribution of elements which will include prognostic indicators as described below.

One example of such a qualifier, is a 'significance' qualifier representing the long term medical significance of a clinical or clinically related data item within the patient data. Relevant items are flagged with a numerical scale from 0 - 10, each with a clinically relevant definition. Such a feature may be advantageous when filtering and displaying the patient data record.

Another example is a ‘certainty’ qualifier reflecting the level of certainty of the diagnosis.

Such a feature may be advantageous when providing an accurate record of the medical history Relevant items are flagged with a numerical scale from 0 - 10, each with a clinically relevant definition.

Another example is a ‘severity/quality of life’ qualifier reflecting the severity and effects on life quality for the condition during the index period. Relevant items are flagged with a numerical scale from 0 - 10, each with a relevant definition. Such a feature may be advantageous when providing an accurate record of the state of functionality either full or reduced.

A further example of a specific qualifier helpful for the organisation and distribution of records is a ‘confidentiality qualifier’ whereby relevant items are flagged with a numerical scale from 0 - 10, each with a definition. Such a feature may be advantageous when displaying and also distributing the patient data record.

A further example of a specific qualifier helpful for the organisation and distribution of records is a ‘hazard qualifier’ whereby relevant items are flagged with a numerical scale from 0 - 10, each with a definition. Such a feature may be advantageous when using a new prognostic index as described below when delivering treatment or passing care to a new health care provider.

A further example of a specific qualifier helpful for the organisation and distribution of records is a ‘treatability qualifier’ whereby relevant items are flagged with a numerical scale from 0 - 10, each with a definition. Such a feature may be advantageous when using a new prognostic index as described below when delivering treatment or passing care to a new health care provider.

A further embodiment would use all of the suitable contributing data in the personal medical record system, including but not exclusive to biometric data, medical conditions, clinical procedures, social factors, family history, medication history, substance use, real time symptomology, allergy history, self-examination and genetic history fin order that the system computes two additional prognostic indices, such as herein described below.

The first prognostic index is a ‘treatability prognostic index’ which, taking into account diagnosis and severity would provide an indication on the benefits of treatment. Specific elements of the patient data may be associated with patient treatability reflecting the degree to which, for example, the patient can be treated successfully. Additional patient data such as biometric data, previous medical history data, substance use history and genetic information data may, for example, be used to inform whether treatment of the patient is likely to be successful. In certain embodiments, patient data may be processed to generate weighting data which corresponds to the treatability of the patient. Output data corresponding to the patient’s physiological condition may therefore be generated which comprises or incorporates weighting data. Such data may be used to generate a prognostic index for assessing a patient’s suitability for treatment. The treatability application provides a function for generating clinical warning score data which can be used to determine whether treatment of the patient is likely to be successful.

The second prognostic index is a ‘hazard prognostic index’ giving a score as to how likely it is that the patient will represent a clinical hazard to those peers and professionals giving care.

The first and second prognostic indices support the role of peer and professional care givers, and also in the event that the patient’s care is transferred to a different service provider, provide anticipatory guidance for the new service providers.

The patient data record management system may be configured to enable access to the patient data record by other patient record data systems and the confidentiality scale attributed by a user to aspects of the patient data record may be used to determine what data is shared.

Similarly, in further examples, specific elements of the patient data may be associated with a significance value on a significance scale reflecting the importance of, for example, a symptom or a condition in the patient data. Such a feature may be advantageous when filtering and displaying the patient data record.

Similarly, in further examples, specific elements of the patient data may be associated with a hazard value on a “hazard scale” reflecting the degree to which, for example a diagnosis relates to an infectious disease. Again, such a feature may be advantageous when filtering and displaying the patient data record.

In certain embodiments, further functionality enables a user of the further user device 1305 to classify diagnostic data by verifying or refuting the associated diagnostic data, for example, after further clinical investigations have been performed. In certain examples, such classification of the verification data can be extracted and used to further improve the diagnostic algorithm performed by the diagnostic function.

In certain embodiments, specific elements of the patient data may be associated with patient treatability reflecting the degree to which, for example, the patient can be treated successfully. Additional patient data such as biometric data, previous medical history data, substance use history and genetic information data may, for example, be used to inform whether treatment of the patient is likely to be successful. In certain embodiments, patient data may be processed to generate weighting data which corresponds to the treatability of the patient. Output data corresponding to the patient’s physiological condition may therefore be generated which comprises or incorporates weighting data. Such data may be used to generate a prognostic index for assessing a patient’s suitability for treatment.

For example, a user device of the type described above with respect to other embodiments may be provided on which is running a treatability application having a treatment function. The treatability application is arranged to receive data relating to the patient including sensor data and patient data as described, for example, with respect to the Diagnostic Function (for example, patient information data extracted from a patient information database and/or further manually entered patient data). The treatability application provides a function for generating clinical warning score data which can be used to determine whether treatment of the patient is likely to be successful. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singu lar/pl u ral permutations may be expressly set forth herein for sake of clarity.

It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims are generally intended as “open" terms (e.g., the term “including" should be interpreted as “including but not limited to,” the term “having" should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., “a” and/or “an” should be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations).

It will be appreciated that various embodiments of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope of the present disclosure. Accordingly, the various embodiments disclosed herein are not intended to be limiting, with the true scope being indicated by the following claims.

Claims

28 CLAIMS

1 . A system for generating a prognostic clinical warning score associated with a patient’s physiological condition, said system comprising: a sensor array comprising a plurality of sensors for taking a plurality of physiological readings from a patient, said sensor array operable to communicate sensor data corresponding to the physiological readings; and computer-readable instructions which, when executed by a processor, cause the processor to: receive the sensor data and additional patient data related to the patient, the additional patient data including the result of a near patient capillary blood test for an inflammatory marker; process data corresponding to the received sensor data and the additional patient data to calculate a clinical warning score, and generate output clinical warning score data corresponding to the calculated clinical warning score.

2. The system of claim 1 , wherein the inflammatory marker is C-Reactive Protein.

3. The system of claim 1 or 2, wherein the result of the near patient capillary blood test is obtained from a lateral flow test device.

4. The system of claim 1 , 2 or 3, wherein the result of the near patient capillary blood test is obtained from a colorimetric chemical based assay device.

5. The system of any one of the previous claims, wherein the result of the near patient capillary blood test is obtained from a standalone electronic reader device.

6. The system of any one of the previous claims, wherein the instructions cause the processor to detect the result of the near patient capillary blood test.

7. The system of claim 6, wherein the result is detected using the output from an optical sensor.

8. The system of claim 7, wherein the result is detected by analysing the intensity and/or colour of an indicator line in an image captured using the optical sensor.

9. The system of any preceding claim, wherein the additional patient data is received from a user input.

10. The system of any preceding claim, wherein the additional patient data is received from a further sensor.

11 . The system of any preceding claim, wherein the additional patient data is received from a database.

12. The system of any one of the previous claims, wherein the sensors include at least one of a temperature sensor configured to measure a heat flux indicative of a core body temperature, a capillary refill sensor, an ECG sensor, an optical sensor or an acoustic sensor.

13. The system of claim 12, wherein the optical sensor is a pulse oximetry optical sensor.

14. The system of claim 12 or 13, wherein the acoustic sensor is configured to generate acoustic data corresponding to respiration of a patient.

15. The system of any one of the previous claims, wherein the sensor array is positioned within a disposable envelope.

16. The system of any one of the previous claims, wherein the sensor array comprises a sensor unit configured to be positioned on a supraclavicular site.

17. The system of any one of the previous claims, wherein the sensor array comprises a sensor unit configured to be positioned on an ear site.

18. The system of any one of the previous claims, wherein the sensor array comprises a sensor unit configured to be positioned on a forehead or temple site.

19. The system of any one of the previous claims, wherein the sensor array comprises a plurality of sensor units.

20. The system of any one of the previous claims, wherein the clinical warning score algorithm is at least one of PEWS, NEWS 2, MEWS, POPS and MANChEWS.

21 . The system of any one of the previous claims, wherein the instructions cause the processor to monitor clinical warning score trends over time.

22. The system of any one of the previous claims, wherein the instructions include functionality allowing near patient testing data to be processed as the additional patient data by the clinical warning score algorithm.

23. The system of any one of the previous claims, wherein the additional patient data includes the result of at least one of a near patient urinalysis, a near patient capillary blood C-Reactive Protein level, and a near patient capillary blood glucose level.

24. The system of any one of the previous claims, further comprising a user device, wherein the user device is configured to receive the sensor data and/or the additional patient data, optionally wherein the user device is configured to receive the data via a wireless connection.

25. The system of claims 7 and 24, wherein the user device comprises said optical sensor.

26. The system of claim 24 or 25, wherein the user device is a personal computing device, preferably a smartphone.

27. The system of claim 24, 25 or 26, wherein the system is configured to control the user device to communicate one or more of the clinical warning score data, the additional patient data inputs and the sensor physiological data inputs to a clinical warning score data processing system for further processing to generate output prognostic data.

28. The system of claim 27, wherein the clinical warning score data processing system is configured to perform a categorisation process, optionally wherein the clinical warning score data processing system is configured to generate an alert based on the categorisation process

29. The system of claim 27 or 28, wherein the user device is configured to transmit the sensor data to the clinical warning score data processing system using an optical code.

30. The system of any one of the previous claims, wherein the additional patient data includes at least one of: physiological observational data received via an interface; biometric data; data which relates to medical history; data which relates to social history; data which relates to guided or unguided examination; and patient data received from a database.

31. The system of any one of the preceding claims, wherein the additional patient data includes data which relates to symptom detail data; optionally wherein the symptom detail data is tracked in real time.

32. The system of any one of the preceding claims, wherein the additional patient data includes data which relates to nearpatient investigations; optionally wherein the near-patient investigations data is received from further medical sensors configured to communicate with the user device.

33. The system of any one of the preceding claims, wherein the instructions further cause the processor to carry out a diagnostic function configured to input the clinical warning score data and additional patient data to a diagnostic algorithm and generate output diagnostic data.

34. The system of claim 33, wherein the instructions cause the processor to communicate the early warning score data and diagnostic data to an application server running a medical record system.

35. The system of claim 34, further comprising a user device which is configured to access the medical record system.

36. The system of claim 34 or 35, wherein the early warning score data and diagnostic data is stored in a database with an associated hazard scale and/or an associated confidentiality scale.

37. The system of claim 34, 35 or 36, wherein the application server includes functionality allowing diagnostic data to be verified/refuted. The system of any one of the preceding claims, wherein the instructions further cause the processor to process data corresponding to patient data in accordance with a treatment function and generate the data corresponding to the received patient data for processing in accordance with the clinical warning score algorithm which relates to the treatability of the patient; optionally wherein the treatment function comprises a weighting function determined based on the data corresponding to patient data. A method of generating a prognostic clinical warning score associated with a patient’s physiological condition, the method comprising: receiving physiological data corresponding to a plurality of physiological readings of a patient, and additional patient data related to the patient, the additional patient data including the result of a near patient capillary blood test for an inflammatory marker; processing data corresponding to the received sensor data and the additional patient data to calculate a clinical warning score, and generating output clinical warning score data corresponding to the calculated clinical warning score. The method of claim 39, further comprising: obtaining the physiological data using a sensor array comprising a plurality of sensors; and communicating the physiological data corresponding to the physiological readings.