reflect - an epsrc iaa project exploring the impact of wearable data on personalised decision support

wearable

about

The epsrc consult project developed a decision-support system characterised by its integration of computational argumentation (a form of AI) with wearable device data.

reflect is an epsrc iaa project that aims to generalise and optimise the wearable data collection logic developed within consult, in order to provide this data to other AI-based decision-support systems.

In doing so, the impact of wearable data on the operation of these systems, and thus on personalised patient healthcare, can be further explored.

 


people

martin chapman - pi vasa curcin - co-pi abigail g-medhin - data scientist abhiram ravikuar - research software engineer
Dr. Martin
Chapman
Dr. Vasa
Curcin
Abigail
G-Medhin
Abhiram
Ravikumar
PI Co-PI Data Scientist Research Software Engineer

partners

metadvice

devices

withings garmin

 


software

To generalise consult’s wearable data logic, reflect packages this logic as a set of new components - developed on top of a new software stack - that are designed to be deployed to a newly defined server architecture. These components then combine to collect, and provide access to, wearable data.

 

components

reflect’s core components are as follows:

  • user (microservice) - presents a patient-optimised interface that allows users, or a GP on their behalf, to connect their wearable devices - via the device vendor - with reflect
  • notify (function) - receives data from the wearable devices, via the device vendors' servers
  • convert (function) - standardises the data received from multiple vendors to fhir, to ensure a unified data format is presented to third-party systems
  • api (microservice) - allows decision-support systems to access the collected data

View all reflect software repositories.

 

stack

reflect’s components are built on top of the following software stack:

 

architecture

reflect’s software components are designed to be deployed to a Kubernetes cluster (or to Minikube for testing), to ensure the scalability demands of external reasoners are met. This cluster can be realised by a cloud provider such as AWS as follows:

Here, a VPC provides both public and private subnets, with the latter holding the replicated nodes to which reflect’s software components are deployed. These components communicate via an internal load balancer, while external requests (such as incoming device data) are received via a web-facing load balancer.

This configuration can be viewed here.

 

flow

To provide decision-support systems with access to wearable device data, reflect’s components combine as follows:

1. device connection

A user navigates to the reflect web application in order to associate a unique patient ID (such as an NHS number) with the data collected from various devices, which they proceed to authorise via each device vendor’s server.

2. data storage

When new data is collected by a patient’s device, it is forwarded to the reflect servers. Here, the data is securely cached before being standardised to fhir, and then stored in a HAPI FHIR server.

3. data retrieval

Using a patient ID (collected separately), a third-party decision-support system calls the reflect servers for the latest data available on that patient.

 

screenshots