reflect - an epsrc iaa project exploring the impact of wearable data on personalised decision support
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.
|PI||Co-PI||Data Scientist||Research 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)
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
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
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.