AU2016200158A1

AU2016200158A1 - System and method for autonomous chronic disease management

Info

Publication number: AU2016200158A1
Application number: AU2016200158A
Authority: AU
Inventors: Joshua Chen Tsien Khoo
Original assignee: Individual
Current assignee: Individual
Priority date: 2015-02-06
Filing date: 2016-01-11
Publication date: 2016-08-25

Abstract

A system (100) for autonomous monitoring of patient medical conditions includes wearable monitoring devices (104), which are worn by, and associated 5 with, individual patients. A patient wearing a wearable monitoring device approaches a point-of-care medical device (106), and conducts a medical test or measurement. The wearable monitoring device automatically detects proximity to the medical device, establishes a wireless connection, mutually identifies the user and the medical device, and facilitates the recording and storage of a test or 10 measurement results at a remote server (108) location. No manual recording or reporting, either in written form or through an online interface, is required of the user.

Description

SYSTEM AND METHOD FOR AUTONOMOUS CHRONIC DISEASE

MANAGEMENT

FIELD OF THE INVENTION

The present invention relates to disease management, and particularly to methods and systems that enable patients to autonomously monitor their own health conditions, such that relevant data is made available to supervising medical practitioners.

BACKGROUND TO THE INVENTION

Technology is now available to enable many patients with chronic health problems to contribute autonomously to the monitoring of their own conditions. A wide range of point-of-care medical devices have been developed which enable tests to be conducted by a patient, each year in their own home, or at a local premises, such as at a medical centre or pharmacy, with minimal or no assistance. Such devices include blood pressure monitors, blood glucose/cholesterol/uric acid monitors, urine analysers, weight/body composition scales, pulse oximeters, Holter monitors, and so forth.

Additionally, wearable technology, such as wrist straps, smart watches, and the like, enable continuous monitoring of physiological parameters such as heart rate, heart rate variability, respiration, skin conductance, and physical activity (e.g. general activity level, pedometer and gestures), as well as providing for environmental monitoring (e.g. ambient voice, temperature, GPS location). However, a number of problems continue to limit the effectiveness of autonomous chronic disease management regimes. Some of these problems are technology related, while others relate to patient behaviour.

Conventional chronic disease management systems place a significant record-keeping burden upon the patient. Traditionally, this would include the keeping of a daily diary of activities, as well as the results of medical and physiological tests. There are a number of aspects in which such conventional systems may break down, e.g.: • failure of the patient to keep sufficiently regular and detailed records • inadvertent or deliberate mis-recording and misreporting of activity and rest results; • failure to communicate information clearly, and in a timely fashion, to a supervising physician; and • errors in diagnosis and treatment as a result of the above recording and reporting issues.

Translating the reporting function to an online interface mitigates some, but not all, of the above problems. Online reporting enables information to be stored centrally, and made immediately available to a supervising physician. Furthermore, an online interface, in combination with suitable wearable technology, can facilitate the automated download of some activity and physiological data. However, online systems still rely upon the patient to record and report regularly, and are only effective when the patient is sufficiently competent in using the online technology, makes no errors in operating the point-of-care medical devices, and is meticulously accurate in data entry of results obtained from medical tests. As will be appreciated, these are skills that may be of particular concern in the case of patients suffering from chronic diseases, and particularly the elderly.

There is, accordingly, a continuing need for improved methods and systems that are better able to facilitate autonomous chronic disease management, by further reducing the reporting burden, along with the requisite level of technical skill, of the patient. It is an object of the present invention to address this need.

SUMMARY OF THE INVENTION

In one aspect, the invention provides a wearable monitoring device comprising: a processing unit; a memory store, coupled to the processing unit; and a wireless communications interface coupled to the processing unit, wherein the memory store contains instructions executable by the processing unit to: monitor the wireless communications interface to detect proximity of a medical device; transmit a message comprising identifying information of a user associated with the wearable monitoring device and identifying information of the detected medical device to a remote electronic health record (EHR) server; receive a response from the EHR server comprising a confirmation of an association of the user with the detected medical device; and initiate a physiological data acquisition by the medical device, hereby physiological data of the user is acquired and communicated to the EHR server for storage in an EHR store associated with the user.

Advantageously, embodiments of the invention take advantage of wireless communications interfaces within the wearable monitoring device and one or more point-of-care medical devices in order to detect proximity of a user (i.e. patient) wearing the monitoring device to the medical device. The wireless communication may be, for example, via Bluetooth or Wi-Fi technology. The wearable monitoring device thus establishes a ‘body area network’ around the user, to which any point-of-care medical devices in close proximity may be connected. The wearable monitoring device may be uniquely identified or associated with the user, such that the proximity of the user to a particular medical device may be established in real time.

Consequently, embodiments of the invention enable medical tests or measurements conducted using a point-of-care medical device to be automatically associated with the user. Furthermore, the acquired medical data is uploaded to the EHR server (e.g. cloud storage), such that the user is completely relieved of responsibility for recording and reporting the results of point-of-care medical tests and measurements.

As a practical matter, a system embodying the invention enables the user, wearing the wearable monitoring device, simply to approach a point-of-care medical device, and conduct a test or measurement (either independently, or with the assistance of a trained technician, nurse, pharmacist, medical practitioner, or the like). The wearable monitoring device will automatically detect proximity to the medical device, establish a wireless connection, mutually identify the user and the medical device, and facilitate the recording and storage of a test or measurement results at a remote server location. No manual recording or reporting, either in written form or through an online interface, is required of the user.

According to embodiments of the invention, the wearable monitoring device further comprises one or more physiological and/or environmental sensors, coupled to the processing unit, which are configured to acquire physiological and/or environmental data. The data acquired by the sensors may include, for example, heart rate and heart rate variability data, respiration data, galvanic skin response data, user activity data, temperature data, audio data, and geographic location data. Sensor data may be obtained by the processing unit, under executable instruction control, and transmitted to the EHR server for storage in the EHR store associated with the user. Accordingly, a system embodying the invention is also able to acquire and store continuous or intermittent activity and environmental context information of the user. For example, physical activity of the user while wearing the wearable monitoring device may be monitored by way of an accelerometer along with suitable acceleration data processing algorithms executed by the processing unit to implement functions such as a pedometer, gesture identification, and general activity levels.

Information held in the EHR store associated with the user, including physiological and environmental data, and medical measurement/test results may be accessible remotely, for example, via a web interface. Consequently, a supervising physician, or other health professional, may access a patient’s electronic health record, interpret the data and thereby better monitor and manage the general well-being of the user, so as to more effectively manage chronic disease conditions. Having reviewed the available data, a health care professional may consult with the user, for example, in person or via telephone, to provide medical or dietary advice, and/or other interventions appropriate to the management of the user’s condition.

Additionally, advice and other communications, such as reminders or alarms relating to requirements for medical tests and/or measurements, may be provided to the user via the wearable monitoring device. In particular, the memory store of the wearable monitoring device may contain further instructions executable by the processing unit to receive information from the EHR server as configured or provided by a health care professional, and to present corresponding information to the user via a user interface of the wearable monitoring device, which is coupled to the processing unit. The user interface may comprise, for example, a display, an audio output (e.g. speaker), one or more input controls or buttons, an audio input (e.g. microphone), and/or a touch screen interface. The user may be alerted to new communications immediately, or alerts may be delayed until a predetermined time, or for a predetermined time interval. For example, a communication may relate to a requirement for the user to conduct medical measurements, such as blood glucose analysis, at a particular time, or at particular predetermined intervals. The wearable monitoring device may therefore generate alarms, alerts or reminders at the relevant time or intervals, to encourage the user to perform the necessary medical tests in accordance with the recommendations of the health care professional.

As will be appreciated, while a technology cannot compel a human user to do as instructed by their health care professionals, a system embodying the invention provides substantial support enabling a cooperative and well-intentioned user to follow their prescribed monitoring program. A system embodying the invention may also be configured to identify test and measurement results that are unexpected, and likely to be incorrect. While human recording and reporting error can be eliminated via the automations and electronic communications provided by embodiments of the invention, other forms of measurement error, such as incorrect use of medical tests and measurement devices, cannot be completely eliminated. However, in many cases measurement errors will stand out as being obviously implausible, or out of trend for the particular user. Checking and processing of data by the wearable monitoring device processing unit, by the EHR server, or by another processing component within the system, may enable erroneous measurements to be immediately identified. Such erroneous measurements may be discarded or filtered out of information presented to a supervising health care professional, in order to avoid wasted time and effort that may be incurred in otherwise identifying the incorrect data. Furthermore, immediate identification of a likely or possible measurement error may enable a communication to be sent to the user, via the wearable monitoring device, to request that a further measurement be made for checking against, and/or replacement of, the questionable result.

Systems and methods embodying the invention provide many advantages including the ability to identify and establish communication between patients and doctors in between scheduled appointments, thereby reducing overheads in cost and workload within hospitals and other medical facilities, while also providing patients with improved autonomy, closer and more consistent monitoring, and potentially better health outcomes. A wearable monitoring device embodying the invention advantageously establishes a single point of direct health communication directly on the user’s person, and facilitates scheduling and performance of regular required medical tests and measurements.

Further features, benefits and advantages of the invention will be apparent from the following description of preferred embodiments, which is provided in order to illustrate the principles of the invention, and should not be taken as limiting of the scope of the invention as defined in the preceding statements, or in the claims appended hereto.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described with reference to the accompanying drawings, in which like reference numerals refer to like features, and wherein:

Figure 1 is a block diagram illustrating an exemplary system embodying the invention;

Figure 2 is a block diagram illustrating the architecture of a remote patient subsystem embodying the invention;

Figure 3 is a block diagram illustrating the architecture of a cloud server subsystem embodying the invention;

Figure 4 is a block diagram illustrating the architecture of a remote medical practitioner subsystem embodying the invention;

Figure 5 is a detailed block diagram of a remote patient subsystem embodying the invention;

Figure 6 is a block diagram illustrating a software architecture of a wearable device embodying the invention;

Figure 7 is a block diagram further illustrating embedded software modules of the architecture of Figure 6;

Figures 8A to 8E comprise a set of flowcharts illustrating methods of operation and software algorithms executable within remote patient subsystems, cloud server subsystems, and remote medical practitioner subsystems embodying the invention; and

Figures 9A and 9B comprise flowcharts illustrating methods of detecting outlier and anomalous results embodying the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Figure 1 is a block diagram illustrating a system 100 embodying the present invention.

The system 100 employs one or more communications networks 102, which may include local area networks, wired and wireless access networks, and wide area networks, including Internet connectivity, to facilitate communications between components and subsystems of the system 100.

The system 100 further includes one ore more wearable monitoring devices 104 which are worn by patients (interchangeably referred to as ‘users’ within this specification) who are subject to health monitoring, chronic disease management, or similar ongoing medical care and intervention. Further details of embodiments of the wearable devices 104 are described below with reference to Figures 5 to 7.

The system 100 further comprises one or more medical devices 106, which are generally point-of-care test and measurement devices facilitating the conduct of medical tests on a patient, for determining such parameters as blood pressure, blood glucose, cholesterol levels, uric acid levels, weight, body mass index, blood oxygen levels and so forth. Various such devices are commercially available, and full details of the operation of the various available medical devices 106 may therefore be ascertained by persons skilled in medical care, and are beyond the scope of the present discussion.

Medical devices 106 suitable for use in a system 100 embodying the invention include at least one wireless communications interface, such as a Bluetooth interface, and/or a Wi-Fi interface, to enable communications with a wearable monitoring device 104. Medical devices 106 suitable for use in the system 100 may also comprise wired or wireless communications interfaces and associated embedded communication software enabling connection to the network 102.

The system 100 further includes a server platform 108. According to embodiments of the invention, the server platform 108 is a cloud computing platform, an exemplary architecture of which is described in greater detail below with reference to Figure 3. In general, the server platform 108 comprises one or more computing nodes, each of which includes at least one processing unit 110, operably associated with a memory store 112, and a network interface 114 for connection to the network 102. The memory store 112 may consist of volatile and/or non-volatile memory, including read only memory (ROM), flash memory, and random access memory (RAM). The memory store 112 may contain program instructions and transient data relating to the operation of the server system 108, including operating system programs and data, as well as other executable application software necessary for the normal functioning of the server platform 108.

As shown in Figure 1, the server system 108 further comprises a storage area network interface 115, operably associated with the processor 110, providing access to one or more external database storage units 116. The database storage units 116 may contain programs and data relevant to the general operation of the server platform 108, including executable code, web page templates and content, and so forth. The database storage units 116 also contain databases of information relating to the ongoing operation of the system 100, including information about patients/users of the system, their associated wearable monitoring devices 104, connected devices 106, and collected health care data, i.e. electronic health records (EHRs) of the users.

The system 100 further includes one or more medical practitioner access terminals 120. A medical practitioner access terminal 120 may be a conventional personal computer running web browser software, which is thereby able to access information obtained by the server platform 108 via a web interface implemented by web server software components executing on the server platform 108. Alternatively, the medical practitioner terminal 120 may comprise an application executing on a desktop or mobile device, such as a personal computer, a laptop, a tablet, or a smart phone, which may provide equivalent access to data maintained by the server platform 108, for example by a web-based application programming interface (API) implemented on the server platform 108.

Additionally, the system 100 includes one or more mobile application hosts 122, each of which may comprise a mobile computing device (e.g. a tablet or smart phone), or a personal computing device (e.g. a desktop PC or notebook), or an alternative gateway computing platform.

As shown, the mobile application host 122 comprises a central processing unit 124 which is coupled to an internal memory store 126, a network interface 128, and a user interface 130. The network interface 128 may be a wireless interface, such as a Wi-Fi interface. The user interface 130 may include a touchscreen interface, a display, a keypad, buttons, keyboard or other input devices, a microphone, a camera, and/or other input/output devices and components.

The memory store 126 includes a body of program instructions 132 which, when executed by the processor 124, enable the mobile application host 122 to implement functions and features of a health monitoring and management system embodying the invention. For example, the mobile application host 122 may be configured, via appropriate programming, to communicate with wearable monitoring devices 104 and/or connected medical devices 106 in order to gather and record patient data, and/or to generate notifications and other information, such as notifications and alarms relating to a user’s schedule of medical tests and measurements to be conducted using connected medical devices 106.

The memory store 112 of the server platform 108 also contains a body of program instructions 118 which, when executed by the processor 110, implement functions and features of a health monitoring and management system embodying the invention. Further details of such functions and features are described below, particularly with reference to Figure 3, and the flowcharts of Figure 8.

Figure 2 is a block diagram illustrating the architecture 200 of a remote patient subsystem embodying the invention. The remote patient subsystem 200 comprises a patient/user 202, a wearable monitoring device 104, which is worn by the user 202, a mobile application host 122, one or more connected medical devices 106, all of which are directly or indirectly able to access the network 102 via an access point 204. A region surrounding the user 202 and associated wearable device 104 is indicated by the perimeter 206. This perimeter 206 represents a region within which a wireless transmitter/receiver of the wearable device 104 is configured to detect the presence of other communicating devices. The detection may be performed using Bluetooth technologies, e.g. Bluetooth Low Energy (BLE) Beacon technology, or any other suitable wireless technology.

Each connected medical device 106 also has a wireless local communications capability, the range of which is indicated by the perimeter 208.

Overall, the perimeter 206 represents a ‘body area network’ of the user 202, while the perimeter 208 represents a wireless area network of each medical device 106. Also shown in Figure 2 is a region of overlap 210 between the patient body area network 206 and the medical device wireless area network 208.

When such an overlap area 210 exists, i.e. when the user 202 is in close proximity to one or more connected medical devices 106, the wearable device 104 is able to detect the presence of the connected medical device 106 (and vice versa), such that a communications channel may be established between the wearable device 104 and a medical device 106. As will be described in greater detail below, particularly with reference to the flowcharts in Figure 8, this proximity detection function is used by embodiments of the invention to automatically associate the user 202 with a corresponding connected medical device 106, such that medical test or measurement results may be recorded, and automatically associated with an EHR of the user within a database, without the need for any data recording or entry by the user.

Turning now to Figure 3, there is shown a block diagram illustrating the architecture 300 of a cloud server subsystem embodying the invention. The cloud server subsystem 300 is connected to the network 102, and configured to receive data from other subsystems, such as the remote patient subsystem 200, to process and store that data, and also to provide remote access to the stored data.

The architecture of the cloud server subsystem 300 comprises data collection component 302 and data access components 304.

The data collection components 302 comprise a load balancing component 306 (e.g. the HAProxy load balancer, available from www.haproxv.org)· The load balancing component 306 distributes incoming requests among a set of collector socket components 308. Incoming messages are queued by a message queue service component 310. The messages are subsequently de-queued by data handlers within a data handler component 312. The data handlers process the messages, extract and interpret the data contained within the messages, and transfer the resulting data, as appropriate, to database storage 314.

Incoming data may include, for example, results of medical tests or measurements performed by a user 202 via a connected medical device 106, such that a data handler within the component 312 is able to associate the results with the corresponding user, and store the results within an EHR of the user within the database storage 314.

The database storage 314 may be implemented using any suitable database system, for example MongoDB (available from www.monaodb.org). and preferably provides redundant storage for failure handling and recovery, to ensure high reliability and availability, such as the MongoDB replication set 316.

The data access component 304 may be implemented using suitable web server technology, such as the Apache server and associated components, available from the Apache Software Foundation at www.apache.ora. These include session manager 318 and message queuing 320 components, API components 322, and a web load balancing component 324, for distributing incoming access requests across the API component 322.

Figure 4 is a block diagram illustrating the architecture 400 of a remote medical practitioner subsystem embodying the invention. The remote medical practitioner subsystem 400 enables a doctor or other health care worker associated with a patient 202 to access the patient’s EHR which is stored within the cloud server subsystem 300.

The remote medical practitioner subsystem 400 includes a suitable access component 402 for accessing the network 102, and an access terminal 120, which may be a conventional PC or other computing device executing web browser software, or a fixed or mobile computing device executing an application which is configured to provide equivalent access to data stored within the cloud server subsystem 300.

As will be appreciated, the remote patient subsystem 200, the cloud server subsystem 300, and the remote medical practitioner subsystem 400 facilitate a health monitoring and management process having improved efficiency and reliability compared with conventional approaches. A patient 202 is able to function autonomously from a supervising medical practitioner, by wearing a wearable monitoring device 104, and using point-of-care connected medical devices 106 to conduct appropriate medical tests and measurements according to a schedule that is managed with the assistance of notifications, alarms or reminders communicated via the wearable monitoring device 104, and the mobile application host 122. The wearable monitoring device 104 automatically detects proximity to the required medical device 106, and facilitates the recording and storage of test and measurement results within the cloud server subsystem 300. Results are automatically stored within an EHR of the patient 202.

Information held in the EHR of the patient 202 is accessible to a supervising medical practitioner via remote access to the cloud server subsystem 300. The medical practitioner may therefore access the patient’s EHR, interpret the data, and thereby better monitor and manage the general well-being of the patient, so as to more-effectively manage patient health, including chronic disease conditions. The medical practitioner may then consult with the user via telephone, or communications through the system 100, in order to provide medical or dietary advice, and/or other interventions appropriate to the management of the patient’s condition.

Overall, the system embodying the invention provides for improved and more-consistent monitoring and management of ongoing health conditions, while reducing the requirement for face-to-face consultations, thereby reducing overheads in cost and workloads within hospitals and other medical facilities, while also providing patients with improved autonomy and potentially better health outcomes.

Figure 5 shows a detailed block diagram 500 of the remote patient subsystem 200, and particularly of the wearable monitoring device 104. As shown, the wearable monitoring device 104 comprises two processing units, a monitoring coprocessor 502 and an application coprocessor 504. The monitoring coprocessor 502 is designed to operate continuously, interfacing with various sensors incorporated into the wearable device 104, and is therefore configured for low power consumption. A suitable processor core for implementing the monitoring coprocessor is the ARM Cortex M3, although other implementation options will, of course, be apparent to persons skilled in the art of electronic design.

The application processor 504 is configured to implement functions such as communications, data login, signal processing, and user interactions, and thus typically consumes higher power than the monitoring coprocessor 502. However, the application processor 504 may be inactive, and in a standby, or low power consumption, state for a majority of the time. A suitable processing core for the application processor 504 is the ARM Cortex A8, although other implementation options will be apparent to persons skilled in the art of electronic design.

Modules executing on the monitoring coprocessor include a sensor front end 506, responsible for gathering sensor data and transfer to the application coprocessor 504. The sensor front end 506 interfaces with a module 508 for gathering sensor data, and associated parameters, from a set of internal sensors included in the wearable device 104. The sensor front end 506 also interfaces to storage 510, which is used for temporary recording of sensor data and parameters, prior to transfer of the application processor 504.

As indicated by the block 512, internal sensors provided in the wearable device 104 may include ECG sensors, skin conductance sensors, accelerometer, gyroscope, temperature sensors, microphone, bone conductance transducer, among others. Parameters associated with the sensors may include heart rate and heart rate variability, activity level classification, pedometer, skin surface temperature, ambient noise estimation, geographic location, and so forth. Parameters may also specify security and/or operations such as event logging, and authorisation for performing measurements, accessing user health record information, and providing on-device medical feedback.

Software modules executing on the application processor may operate under control of a suitable mobile operating system, such as Android. The application, or applications, executing on the application processor 504 implement higher level functionality than the monitoring coprocessor 502. A digital signal processing (DSP) module 514, is configured to collect data from the sensor front end 506 of the monitoring coprocessor 502, to perform any required processing on that data in order to obtain desired physiological or environmental results (e.g. pedometer and activity level functions require processing of accelerometer and gyroscope data, along with other physiological parameters in order to assess user activity and exertion). Processed and/or raw data may be stored within the storage memory 516 of the application processor. A transmission module 518 is responsible for wireless communications, using one or more wireless communication technologies such as Bluetooth or Wi-Fi, and including communications with the mobile application host 122 and one or more connected medical devices 106.

The application processor 504 is also responsible for implementation of a user interface 520. User interface components managed by the user interface module 520 may include a display, an audio output, one or more input controls or buttons, audio input, and/or a touchscreen interface. The wearable device 104 may take the form of a plain band, a decorative item, or a multifunctional item, such as a smart watch.

As shown in Figure 5, the wearable device 104 communicates with connected medical devices 106 via a Bluetooth channel 522, and with the mobile application host and/or other access points via a Wi-Fi channel 526. The mobile application host 122 may also communicate with connected medical devices 106 via Bluetooth or Wi-Fi channels 528. Alternatively, the mobile application host 122 may not have a direct communication channel to one or more connected medical devices 106. In this case, indirect communication can be established via the wearable device, either in realtime, or via storage and subsequent transfer of information via the wearable device 104. In particular, and as will be discussed further in relation to the flowcharts of Figure 8, systems embodying the invention may employ synchronisation of data amongst devices within the remote patient subsystem 200, the cloud server subsystem 300, and the remote medical practitioner subsystem 400. The synchronisation mechanism ensures that data relating to the user, including relevant elements of the EFIR, are consistently maintained by all devices requiring such data.

Figure 6 is a block diagram 600 illustrating in greater detail the software architecture of an application executing on the application processor 504 of a wearable device 104.

The application comprises an environmental context module (ECM) 602, which executes in a number of different states depending upon the context and status of the wearable device 104. A shutdown/start state 604 is responsible for managing activation and deactivation of the application at power-on (e.g. initialising android operating system and launching the embedded application) and at power-off (e.g. ensuring data synchronisation and integrity, and graceful shutdown of the application. A first operational state 606 is a ‘select’ state, which is responsible for monitoring, connection and management of connections to one or more mobile application hosts or other external access points, e.g. 122a, 122b.

When the application is active, i.e. the application processor 504 is not in the inactive or standby state, the ‘select’ function 606 of the ECM 602 monitors the wireless communications interface (e.g. Wi-Fi interface) for accessible mobile application hosts and/or other access points, and establishes and maintains communications links where available. A second operational state 608 is a ‘listen’ state which monitors the current usage scenario (e.g. which other states are active), communicates with a connected external mobile application host or access point in order to obtain status data 614, and monitors other signals, such as ‘keep alive’ signals, required for correct operation of the application. A third operational state 610 has primary responsibility for communications with connected medical devices 106. The medical device communications state 610 manages the wireless interface, an in particular is responsible for detection of proximity of Bluetooth-enabled medical devices 106, managing and maintaining Bluetooth identity information, and for Bluetooth data transfer. A fourth operational state 612 is a ‘controls’ state responsible for managing communications, including transmission frequency and transmission/listen intervals. A timing process 616 is responsible for monitoring and maintaining local time reference, to ensure that the wearable device 104 remains synchronised with the rest of the system. The timing process 616 has access to a global time reference 620, and maintains a corresponding local time reference 622. The timing process 616 is also able to communicate with external timing processors, e.g. 618, as part of overall system synchronisation mechanisms. The timing processor 616 also provides an interface 624, enabling other modules to access timing reference information.

Functions of the timing process 616 include: • tracking time synchronisation between local and global time references; • employing the underlining android operating system timing mechanisms to synchronise local clocks with external and global time references; • maintaining accurate time synchronisation between multiple local devices; • monitoring and recording clock drift; • controlling time correction and maintaining time references for all other modules; and • maintaining records of time corrections. A communication module 626 provides communications services to other modules, in particular for communication with external mobile application hosts and other access points. The communications module 626 includes a transmission process 628 and a receiver process 630.

Functions of the communications module 626 include: • all queuing and transmission of data; • listening for, receiving and queueing incoming data transmitted from external devices; • wireless communications interface control, including frequency and mode of operation, as specified by the environmental context module 622 controls state 612; • receiving and packaging data, i.e. implementing common data transfer formats and protocols (e.g. JSON over TCP/IP) for reliable communication and transfer of information with external devices; and • interfacing with the user interface module 640 (described below) for implementing bidirectional notifications between all components of the system. A signal and storage module 632 provides the interface between the application processor 504 and monitoring coprocessor 502. The signal and storage module 632 includes a signal interface 634, for sensor control and data acquisition, and flash storage 636 for long-term, non-volatile storage of captured data. The signal and storage module 632 interfaces to volatile RAM storage 638, which may be used for transfer of data to the communications module 626 ready for transmission.

It should be noted that an audio sensor, i.e. microphone, of the wearable device 104 may be shared between a sensor function (e.g. measurement of ambient noise), and a user interface function (e.g. capture of speech in order to provide speech recognition functions, voice control operation, and/or voice communications with other subsystems. Multiplexing and synchronisation of audio input is managed by a synchronisation module 635.

Functions of the signal and storage module 632 include: • acquiring raw sensor data from sensor hardware, independent of other modules and of whether the application processor is active; • transfer of raw data to the DSP module 514 for processing and generation of output data; • maintaining time references, a timing module and a sensor heartbeat to ensure reliable continuous monitoring of sensor data; • execution of DSP module when the application processor is active, including signal quality assessment and sensor hardware control/adjustment; • storage of raw and processed data within flash memory 636; • control of sensor data sample rate and time stamping of acquired data; • control and management of storage format; • implementation of compression (if required) before storage; and • transfer of data to the communications module 626, including compression (if required), via RAM storage 638. A user interface module 640 is responsible for interactions with the user of the wearable device 104. Functions of the user interface module 640 include: • deriving timing from the timing process 616; • interfacing with hardware buttons 642 for providing user interaction with the wearable device 104; • providing an audio interface 648, including output (speaker) and input (microphone) to notify and communicate with the user; • receiving and transmitting notifications and other messages, and maintaining these in memory 644 separate from the signal and storage module 632 memories 636, 638; and • controlling visual output devices, such as hardware LEDs 646.

As noted above, audio input (i.e. microphone) is shared with the signal and storage module 632. The synchronisation module 635 manages this sharing. In general, the audio input is used as a sensor, however when the user interacts with the user interface module 640, e.g. via activation of hardware button 642, the synchronisation module 635 is employed to transfer access to the microphone from the signal and storage module 632 to the user interface module 640.

Figure 7 is a block diagram further illustrating the embedded software modules implementing the architecture 600 shown in Figure 6. All processes of the application execute in parallel, under control of the android operating system, which manages multi-tasking and inter-process communication of the processes executing on one or more processor cores. As shown in Figure 7, the processes include environmental context process 602, user interface process 640, transmission and receiver processes 628, 630 of the communications module 626, the timing process 616, and raw signal acquisition process 704, DSP process 708, associated with RAM and flash storage 636, 638 of the signal and storage module 632. The raw signal acquisition process 704 accesses the hardware sensors 702. The DSP process 708 accesses (i.e. reads and stores) processed parameters 706 such as heart rate, heart rate variability, activity, temperature and so forth.

Figures 8A to 8E comprise a set of flowcharts illustrating methods of operation and software algorithms employed within a system embodying the invention.

Turning first to Figure 8A, there is shown a procedure for implementation by a wearable monitoring device 104. The procedure 800 encompasses initialisation, user verification, and medical device detection. The procedure starts at step 802, and proceeds at 804 to determine whether or not the wearable device 104 is already initialised and associated with the wearer/user. If not, at step 806 the device identifies the user. This may be by requiring the user to enter a code using buttons or other user interface components, or by using a biometric input to identify the user. Once the user has been identified, the wearable device 104 communicates with the server platform 108 at step 808 in order to obtain a temporary user ID (UID) for the user. Step 810 takes place at the server 108, and comprises generating the temporary UID and associating it with the account of the identified user. This information is stored in the server cache/database 812.

Once the device 104 has been initialised, it proceeds to create the body area network (i.e. wireless communications perimeter 206) at step 814. For security purposes, the temporary UID associated with the user has an expiration period. This ensures that, if another user gains access to the wearable device 104, it will not retain an association with original user for a significant period of time, which would compromise security of the user’s medical records. Therefore, at 816 a time of expiry is indicated, which will result in a disassociation of the temporary UID with the user account, and subsequent re-initialisation and allocation of a new temporary UID.

While the timer has not expired, and other events do not occur, the wearable device 104 maintains and manages the body area network at step 818. Throughout this period, the device 104 will regularly search for connected medical devices 106 within the body area network indicated at 820. If a medical device is discovered during the periodic scan, according to the test at 822, then communication with the medical device 106 will be established, and both the wearable device 104 and the medical device 106 will prepare for measurements. In particular, at step 824 the wearable device 104 accesses the server platform 108 in order to report contact with the connected medical device 106. At the same time, at step 826, the connected medical device 106 will access the server platform 108. At step 828, the server platform 108 verifies the information received from both the wearable device 104 and the connected medical device 106 to confirm that the data matches. If not, this may indicate a problem with the temporary UID, and therefore the wearable device 104 is returned to the initialisation step 804. If the information matches, then further details of the user on the wearable device and connected medical device are checked at step 830. If an incorrect user is identified, a notification is generated at step 832, and the user will be required to re-identify via the initialisation step 804.

If all user and connected medical device details are verified correctly, the system moves on to an EHR synchronisation procedure, illustrated in Figure 8B, in preparation for performing a medical measurement.

At step 902, a synchronisation process is commenced for the specific user. At step 904, the server platform 108 is accessed to enable synchronisation of user data, including the user EHR. It should be noted that this synchronisation may be performed across all relevant devices associated with the remote patient, including the wearable monitoring device 104, the mobile application host 122, and one or more connected medical devices 106.

Various user information is then updated and synchronised between devices. At step 906, information associated with the user in relation to test/measurement schedules (i.e. periodic medical tests/measurements) and thresholds (i.e. tests/measurements performed when specified environmental/physiological conditions are satisfied) is synchronised. If any error or other problem occurs in this step, the synchronisation process is restarted from step 902. Otherwise, at step 908, all relevant connected equipment and the mobile application 126 are synchronised. Again, any error or other problem results in a restart of the synchronisation process, at step 902.

At step 910 a data update occurs across all relevant connected medical devices 106, the mobile application 126, and the wearable device 104. A notification of successful synchronisation and completion of the data update is then presented on the wearable device 104 and/or the mobile application host 122, at step 912. In parallel with the data update, the connected medical devices 106 and the mobile application host 122 perform additional housekeeping operations relating to multi-user support and measurement recording. In particular, at step 914 local memory 916 of the mobile application host 122 and the connected medical devices 106 is updated, and information relevant to the current user is retrieved. As will be appreciated, the connected medical devices 106 and the mobile application host 122 may be shared among a number of users, as distinct from the wearable device 104 which is generally associated with a single user.

At 918, a check is performed to determine whether the current user is due to perform a test/measurement using the detected connected medical device 106. If so, then a notification is generated at step 920 on all devices and at the mobile application host 122. Otherwise, as indicated at step 922, the system enters a state of standby for a possible manual measurement, and also continues background monitoring (i.e. through steps 818, 820, 822). It will be appreciated that the user may simply be passing by the detected connected medical device 106, with no intention of taking any measurement, or alternatively may be intending to take a measurement that is not part of the normal schedule for that user.

In the event that a measurement is due and/or otherwise proceeds, the relevant process is now described with reference to the further flowchart of Figure 8C.

At step 1002, the user completes a measurement using the detected connected medical device 106. The user may take the measurement independently, or with the assistance of a trained technician, nurse, or other assistant. At the same time, if the user is wearing the wearable monitoring device 104, as tested at 1004, the device conducts a measurement of the current context for the user at step 1006. This context includes physiological and/or environmental parameters, as determined by the sensors provided within the wearable device such as have been described above with reference to Figure 5. These contextual measurements enable the physiological and/or environmental factors to be taken into account in assessing the validity of the test/measurement results obtained from step 1002.

Accordingly, at 1008 the system checks the measurement result against prior results in the patient’s history, and the environmental/physiological context (if available). In the event that the measurement appears inconsistent with past measurements, and may therefore be inaccurate due to measurement error or other factors, an indication is generated at step 1010, which may be via the wearable device 104, the mobile application host 122, and/or the connected medical device 106. The recommended action in this case is to repeat the measurement, and the user makes a decision as to whether to follow the recommendation at 1012. If the user declines to repeat the measurement, at step 1014 annotations are added to the measurement record to indicate its doubtful status, such that this may be taken into account in subsequent processing and/or evaluation by a remote medical practitioner.

Alternatively, if the user follows the recommendation at 1012, preparations are made to repeat the measurement at step 1016, and a new measurement is taken at 1002.

Following completion of a measurement, at step 1018, the server platform 108 is accessed, in order to upload and update the patient’s EFIR with the new measurement results. Upon completion of the update, various synchronisation and housekeeping functions are performed, as illustrated by the further flowchart in Figure 8D.

Specifically, at step 1102 a body area network and connected medical device maintenance routine is commenced. This includes synchronisation of the mobile application 126, at step 1104, an update of the connected medical device schedule, at step 1106, an update of the wearable device patient management information, at step 1108, and synchronisation of the context data acquired at step 1006 with the user’s records, at step 1110.

The system then checks, at step 1112, whether a further scheduled measurement is due. If not, then the user may move away from the connected medical device 106, and the wearable device returns to maintaining and managing the body area network, at step 818 shown in Figure 8A. Otherwise, the requirement for a further scheduled measurement is indicated on the wearable device 104, the mobile application host 122, and/or the connected medical device 106, at step 1114.

As will be appreciated, the processes described in Figures 8A to 8D result in the ongoing maintenance and update of patient records, including scheduling, notification and recording of tests/measurements performed by the patient using one or more connected medical devices 106. This results in an evolving medical record, i.e. the patient’s EHR, maintained by the server platform 108. This patient EHR is thereby accessible to a medical practitioner, such as the user’s supervising doctor, and this remote access capability is described schematically in the flowchart of Figure 8E.

In particular, when the supervising practitioner wishes to review the progress of a patient, this commences at step 1202. The medical practitioner may, for example, log into the system via a web interface, or a dedicated application, as has previously been described with reference to Figures 3 and 4. At step 1204, the medical practitioner is able to access and review a selected patient’s EHR. From here, the system may provide various operations to support the ongoing management of the patient’s health condition.

For example, at step 1206 the medical practitioner may be able to use the interface to the system to set new appointments, specify medical procedures, prepare notes, and refer the patient to other health care professionals. This information will be transferred to the server platform 108, and can be used to notify the user, and other medical practitioners, of changes, new requirements, schedules, and appointments.

Additionally, at step 1208, the medical practitioner may be able to set recommendations for a patient. These may include, for example, dietary, exercise and/or rest recommendations. These, again, may be notified to the patient via the system, through the server platform 108 and to the mobile application host 122 and/or the wearable device 104.

The medical practitioner may also set or update the monitoring schedule for the patient, including specific times or conditions under which further medical tests or measurements should be performed using the connected medical devices 106.

As noted, all of the above information is transferred to the server platform 108, and synchronised with the other devices in the system, including connected medical devices 106, mobile application hosts 126, and wearable devices 104, in the manner described above with reference to Figure 8B. Accordingly, a server access routine 1212 connects to the server platform 108, and updates the dynamic patient management interface 1214, the monitoring schedule 1216, and data relating to expected measurement results and ranges 1218.

Once the review and any updates have been completed by the medical practitioner, a current monitoring schedule is established 1220, and the practitioner may decide, at 1222, to review further patient records, or to end their interactions with the system, at step 1224.

Turning now to Figures 9A and 9B, there are shown flowcharts 1300, 1400 illustrating methods of detecting outlier and anomalous results, e.g. for validating patient measurements, as required at step 1008 of the process illustrated in the flowchart of Figure 8C.

More particularly, Figure 9A shows a flowchart 1300 of an automatic outlier detection process. As shown, at step 1302 a medical practitioner, such as a patient’s supervising doctor, prescribes a monitoring schema comprising such parameters as measurement frequency, thresholds for performance of tests under specified conditions, type and range of measurements, and so forth. At step 1304 (corresponding, in at least some embodiments, with the measurement step 1002 shown in Figure 8C) a prescribed patient measurement is performed, and the measurement results, along with other contextual, environmental and physiological parameters obtained. At step 1306, an automated outlier detection process commences. This process gathers historical data 1308 from the user’s EHR, which is stored within the system storage 1310 (i.e. local cache memory and/or the server/cache database 812).

Various techniques may be used to classify the newly received information, as part of the process of detecting outliers. Two are illustrated in Figure 9A. A first method is statistical classification 1312, in which the patient historical data is employed as a ‘training set’ which has previously been classified according to the techniques described herein, with respect to both Figures 9A and 9B. The classifier 1312 employs statistical methods to assess the likelihood that the new measurement is consistent with past measurements of the user under similar contextual conditions, so as to classify it within an existing result set, or as a possible outlier. In a parallel classification method, a first step of dimensionality reduction 1314 is performed, in order to reduce the number of independent variables (e.g. context parameters). A spatial proximity classification step 1316 is then employed to assess whether the new measurement is clustered with an existing set of historical measurements within a reduced multidimensional space. The results from multiple classifiers, such as the statistical modelling classifier 1312 and spatial proximity classifier 1316, are then combined in an overall classification step 1318 in order to make a final decision whether to classify the new measurement within an existing set, or mark it as a possible outlier.

The result of classification step 1318 is used to make a decision 1320 as to whether or not to process the new measurement as a possible outlier. If so, then at step 1322 a notification message is generated, and transmitted back to the user who is then informed 1324, e.g. via the wearable device 104, a connected medical device 106, and/or the mobile application host 122, that the measurement is considered suspect, and recommending retesting. The user may follow the recommendation, or elect to override, at step 1326. If the user overrides the recommendation of retesting, then a corresponding comment is received and stored to the system storage 1310 at step 1328. Additionally, the potentially anomalous measurement result is flagged for further investigation at step 1330. For example, the user’s supervising medical practitioner may later review the flagged result, and make a professional assessment as to whether the result is indeed anomalous, or reflects a real change that may require medical intervention.

Alternatively, if the user accepts the recommendation to repeat the measurement, this is indicated at step 1332, after which the process returns to measurement step 1304.

In the event that the classification step 1318 does not identify the new measurement as a possible outlier, control passes to step 1334, in which the new measurement, and associated contextual parameters, are recorded in the user’s EHR within the system memory store 310. At step 1336, a notification message is generated and transmitted back to the user, e.g. via the wearable device 104, a connected medical device 106, and/or the mobile application host 122, informing the user, at step 1338, of the successful measurement.

Figure 9B shows a flowchart 1400 illustrating a manual outlier override and anomaly detection process. The process 1400 is employed to gather expert input from a doctor, or other professional practitioner, so as to improve the quality of the historical data contained within each patient’s EHR, and improve the performance of the automatic outlier detection process 1300. At any time, a professional practitioner may access the system, for example via a web interface, in order to review 1402 any possible anomalous or outlying results that have been flagged. For each such result, the practitioner may decide 1404 to exclude or retain the suspect result. If the practitioner decides to exclude the result, it is removed from use in any further analysis, at step 1406. Either way, the patient EHR is updated at 1408, and the changes recorded in the system storage 1410. The practitioner is then presented 1412 with updated information based upon any changes to the patient EHR.

Additionally, contents of patient EHRs recorded within the system storage 1410, and which may be updated from time to time with new measurement data and/or changes resulting from professional review, are monitored by a data mining process 1414. This process extracts patient data from the system database, which is then analysed to identify any further possible anomalies. The analysis may comprise, for example, dimensionality reduction 1416, classification 1418, and clustering 1420, in order to identify the presence of any abnormal clusters which may be emerging within the patient data held within the database. If no anomalies are identified 1422, updated informatics regarding the patient historical data is stored 1425 within the EHR. However, in the event that an anomaly is identified, tracking information is stored 1428 within the EHR, and the supervising medical practitioner is informed 1426 of the new information, such that a professional verification or review of the trend may subsequently be conducted.

The foregoing description has been provided to illustrate various exemplary features of specific embodiments of the invention. However, this description is not intended to be limiting of the scope of the invention, which encompasses implementation variations falling within the knowledge and capabilities of the person skilled in the art. Throughout the description, a number of aspects of the implementation which may be subject to variation have been identified. Furthermore, certain features have been described in part and/or by way of example, while the potential for additional, extended and/or analogous features has been indicated. However, the fact that variations and extensions have not been discussed in relation to other features should not be taken to imply that such variations and extensions are not possible, or do not fall within the scope of the invention. Rather, the scope of the present invention is as defined in the claims appended hereto.

Claims

CLAIMS:

1. A wearable monitoring device comprising: a processing unit; a memory store, coupled to the processing unit; and a wireless communications interface coupled to the processing unit, wherein the memory store contains instructions executable by the processing unit to: monitor the wireless communications interface to detect proximity of a medical device; transmit a message comprising identifying information of a user associated with the wearable monitoring device and identifying information of the detected medical device to a remote electronic health record (EHR) server; receive a response from the EHR server comprising a confirmation of an association of the user with the detected medical device; and initiate a physiological data acquisition by the medical device, whereby physiological data of the user is acquired and communicated to the EHR server for storage in an EHR store associated with the user.
2. The wearable monitoring device of claim 1 which further comprises one or more physiological and/or environmental sensors, coupled to the processing unit, which are configured to acquire physiological and/or environmental data.
3. The wearable monitoring device of claim 2 wherein sensor data is obtained by the processing unit, under executable instruction control, and transmitted to the EHR server for storage in the EHR store associated with the user.
4. The wearable monitoring device of claim 1 wherein the memory store contains further instructions executable by the processing unit to receive information from the EHR server as configured or provided by a health care professional, and to present corresponding information to the user via a user interface of the wearable monitoring device, which is coupled to the processing unit.
5. A method of patient management comprising: providing a user with a wearable monitoring device which includes a wireless communications interface configured to detect proximity of a medical device; detecting proximity of the user to a medical device; transmitting, by the wearable monitoring device, a message comprising identifying information of a user associated with the wearable monitoring device and identifying information of the detected medical device to a remote electronic health record (EHR) server; receiving, by the wearable monitoring device, a response from the EHR server comprising a confirmation of an association of the user with the detected medical device; performing, using the detected medical device, a physiological data acquisition, whereby physiological data of the user is acquired; communicating, to the EHR server, the acquired physiological data of the user; and storing the acquired physiological data of the user in an EHR store associated with the user.
6. The method of claim 5 further comprising evaluating the acquired physiological data of the user to determine whether or not it represents an anomalous or outlying result in relation to historical patient data held within the EHR store associated with the user.
7. The method of claim 6 further comprising performing, using the detected medical device, a further physiological data acquisition, whereby additional physiological data of the user is acquired, in the event that the acquired physiological data of the user is determined to represent an anomalous or outlying result.
8. The method of claim 6 further comprising storing the acquired physiological data of the user in the EHR store associated with the user for further evaluation, in the event that the acquired physiological data of the user is determined to represent an anomalous or outlying result.
9. The method of claim 6 wherein evaluating the acquired physiological data of the user comprises processing the acquired physiological data using a classification procedure which employs the historical patient data as a training set.
10. The method of claim 9 wherein the classification procedure comprises one or more of: a dimensionality reduction procedure; a spatial proximity classification procedure; and a statistical modelling classification procedure.
11. A system for patient management comprising: a wearable monitoring device which includes a wireless communications interface configured for data communication and proximity detection; at least one connected medical device having a data communications interface; a server computing system in communication with the wearable monitoring device and the connected medical device via one or more data communications networks, wherein the server computing system is arranged to access a data store comprising an electronic health record (EHR) of a user associated with the wearable monitoring device; wherein the wearable monitoring device comprises a processor configured to detect proximity of the user to the connected medical device and to transmit a message comprising identifying information of a user associated with the wearable monitoring device and identifying information of the detected medical device to the server computing system; wherein the server computing system comprises a processor configured to transmit, in response to the message from the wearable monitoring device, a confirmation of an association of the user with the detected connected medical device; wherein the connected medical device is configured to perform a physiological data acquisition, whereby physiological data of the user is acquired and communicated via the data communications networks to the server computing system; and wherein the server computing system processor is further configured to store the acquired physiological data of the user in the EHR of the user.
12. The system of claim 11 further comprising a processor configured to evaluate the acquired physiological data of the user to determine whether or not it represents an anomalous or outlying result in relation to historical patient data held within the EHR of the user.
13. The system of claim 12 wherein the server computing system processor is further configured to store the acquired physiological data of the user in the EHR of the user for further evaluation, in the event that the acquired physiological data of the user is determined to represent an anomalous or outlying result.
14. The system of claim 12 wherein the processor configured to evaluate the acquired physiological data of the user processes the acquired physiological data using a classification procedure which employs the historical patient data as a training set.
15. The system of claim 11 wherein the server computing system processor is further configured to implement an interface adapted to enable a supervising user to access, review and update the EHR of the user.
16. The system of claim 11 further comprising a mobile application host in communication with one or more of the wearable monitoring device, the connected medical device and the server computer system, wherein the mobile application host is configured to implement one or more functions selected from: gathering and recording user data; displaying user notifications; and generating alarms relating to a schedule of measurements to be conducted by the user using the connected medical device.