reflect - an epsrc iaa project exploring the impact of wearable data on personalised decision support
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
 |  |  |  |
|---|---|---|---|
| Dr. Martin Chapman | Dr. Vasa Curcin | Abigail G-Medhin | Abhiram Ravikumar |
| PI | Co-PI | Data Scientist | Research Software Engineer |
partners
 |
|---|
devices
 |  |
|---|
publications
M. Chapman, A. G-Medhin, I. Sassoon, N. Kokciyan, E. Sklar, V. Curcin
Using Microservices to Design Patient-facing Research Software
IEEE 18th International Conference on eScience (2022)
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 - withreflectnotify(function) - receives data from the wearable devices, via the device vendors’ serversconvert(function) - standardises the data received from multiple vendors tofhir, to ensure a unified data format is presented to third-party systemsapi(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.
