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



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.



martin chapman - pivasa curcin - co-piabigail g-medhin - data scientistabhiram ravikuar - research software engineer
Dr. Martin
Dr. Vasa
PICo-PIData ScientistResearch Software Engineer







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)



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.



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.



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



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.



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.