1. Using Microservices to Design Patient-facing Research
Software
IEEE 18th International Conference on e-Science
Martin Chapman
King’s College London

2. Traditional research software
Software that facilitates research is usually designed to be used by researchers themselves.
Figure 1: An agent-based model (ABM) of crowds around the London Eye.
1

3. Modern research software
Increasingly, research software is also designed for other users, where the focus of the research
is the outcome of interactions with this software. In the health informatics research domain,
these users are often patients.
Figure 2: The ‘ZOE’ COVID symptom tracking application.
2

4. Researchers vs. patients i
Developing software that can both facilitate research and effective patient interactions
presents a number of challenges:
• Software development. The research to be conducted may necessitate the use of
certain languages (e.g. a certain package that is only available in Python), which might
not match the languages that are best for developing software for potentially large
groups of patients (e.g. V8-compiled Javascript).
3

5. Researchers vs. patients i
Developing software that can both facilitate research and effective patient interactions
presents a number of challenges:
• Software development. The research to be conducted may necessitate the use of
certain languages (e.g. a certain package that is only available in Python), which might
not match the languages that are best for developing software for potentially large
groups of patients (e.g. V8-compiled Javascript).
• Modularity. Researchers naturally want to change parts of a system (e.g. a
recommendation engine) in order to facilitate different experiments. These experiments,
which might affect stability, are typically avoided in live, patient-facing systems.
3

6. Researchers vs. patients i
Developing software that can both facilitate research and effective patient interactions
presents a number of challenges:
• Software development. The research to be conducted may necessitate the use of
certain languages (e.g. a certain package that is only available in Python), which might
not match the languages that are best for developing software for potentially large
groups of patients (e.g. V8-compiled Javascript).
• Modularity. Researchers naturally want to change parts of a system (e.g. a
recommendation engine) in order to facilitate different experiments. These experiments,
which might affect stability, are typically avoided in live, patient-facing systems.
• Processing time. Similarly, the components experimented with might have longer
execution times. Long execution times should be minimised in medical systems where
expedient responses are often essential.
3

7. Researchers vs. patients ii
Developing software that can facilitate both research and effective patient interactions presents
a number of challenges:
• Reproducibility: Researchers want their methodology to be reproducible, and a
component of this is the availability of the software used to produce results. For
patient-facing systems, especially those that deal with health data, it may not be
possible/preferable to share part of a system (e.g. a proprietary health data schema).
4

8. Researchers vs. patients ii
Developing software that can facilitate both research and effective patient interactions presents
a number of challenges:
• Reproducibility: Researchers want their methodology to be reproducible, and a
component of this is the availability of the software used to produce results. For
patient-facing systems, especially those that deal with health data, it may not be
possible/preferable to share part of a system (e.g. a proprietary health data schema).
• Data quality: Researchers are likely to want to experiment with complex data sources
(high-volume, heterogeneous, etc.), and use them as input to their software. In health
systems, data sources need to be as accurate and stable as possible to ensure correct
interventions.
4

9. Microservices
To try and address some of these issues we can consider how to structure our software.
Figure 3: Example customer information microservice. Newman, 2019
A microservice design approach suggests that a system should be separated into individual
communicating services (often via HTTP), each of which provides a single piece of overall
system functionality.
5

10. Microservices in industry
The use of microservices in industrial settings (and in the wider software development
community) is commonplace.
However (at least in our experience) patient-facing research software does not adopt industry
paradigms like this.
Wider goal: encourage the use of established software engineering techniques when developing
(patient-facing) research software.
6

11. Impact of microservices
1. Software development. Each service can be built using a different language, allowing
languages to be combined. Technological heterogeneity
2. Modularity. Service logic can be replaced with minimal impact to the rest of the
system (and services can be used in other systems). Replaceability and Composability
3. Processing time. Functionality with long execution times can be isolated, ensuring the
remainder of the system is not affected. Resilience
4. Reproducibility. A system can be deployed even in the absence of certain components.
Ease of deployment
5. Data quality. The components of a system can be replicated in order to ensure
sufficient data capture. Scalability
7

12. CONSULT i
We can demonstrate each of these benefits in the context of CONSULT, a decision-support
system for stroke patients that was developed under the microservice paradigm.
Figure 4: CONSULT’s dashboard interface Figure 5: CONSULT’s chatbot interface
8

13. CONSULT ii
Blood pressure
(Withings API)
Pulse and Activity
(Garmin API)
Heart Rate / ECG
(Medibiosense API)
EHR
(EMIS)
Device
Integration
(Withings)
Device
Integration
(Garmin)
Device
Integration
(Vitalpatch)
Sensor-FHIR
converter
EHR Integration
(EMIS)
EHR-FHIR
converter
FHIR Health
Data Server
Message
Passer
Dialogue
Manager
Authentication
Server
Provenance
Server
Data
Miner
Argumentation
Engine
Tablet
Browser
Chat
Server
UI backend
PC
Browser
Sensor data
Sensor
data
Sensor
data
EHR
data
FHIR resources
FHIR resources
FHIR resources
Processed
patient data
Patient
data
Substitution
Credentials
Processed
patient data
Processed patient data,
goal
Results
Dialogue responses
Data summaries, tips
Figure 6: CONSULT’s microservice architecture
9

14. CONSULT iii
CONSULT’s full architecture is shown on the previous slide, with each line representing the
transfer of data between two services.
Here, we will consider three (simplified) example flows:
user dialogue manager argumentation engine
A user interacting with the chatbot.
user dashboard health data store
A user viewing (a summary of) their health data.
wearable device sensor integration health data store
Sensor data being passed to the system.
10

15. 1. Software development
The CONSULT team consistent predominantly of researchers familiar with Python and with R.
11

16. 1. Software development
The CONSULT team consistent predominantly of researchers familiar with Python and with R.
The use of microservices allowed us to combine these technologies with languages traditionally
better suited for scalable application development (e.g. Javascript):
user dialogue manager argumentation engine
11

17. 1. Software development
The CONSULT team consistent predominantly of researchers familiar with Python and with R.
The use of microservices allowed us to combine these technologies with languages traditionally
better suited for scalable application development (e.g. Javascript):
user dialogue manager argumentation engine
Caveat: Not all languages are optimised to work as service-based entities (e.g. R).
11

18. 2. Modularity
The CONSULT team wanted to be able to switch out the existing argumentation-based
reasoner for other reasoners in the future.
12

19. 2. Modularity
The CONSULT team wanted to be able to switch out the existing argumentation-based
reasoner for other reasoners in the future.
The use of microservices ensured a separation between interface and logic, making it possible
for this to take place:
user dialogue manager API Logic
Argumentation
Engine
12

20. 2. Modularity
The CONSULT team wanted to be able to switch out the existing argumentation-based
reasoner for other reasoners in the future.
The use of microservices ensured a separation between interface and logic, making it possible
for this to take place:
user dialogue manager API Logic
Argumentation
Engine
Caveat: Owing to the variety of reasoners that might be used, we did not deem it possible
to achieve complete API and logic separation (i.e. modifications to the interface were
inevitable). We developed a dialogue syntax, with modifiable endpoint references, as a
potential way to offset this.
12

21. REFLECT
The presence of encapsulated logic also allowed CONSULT’s services to be used elsewhere:
Blood pressure
(Withings API)
Pulse and Activity
(Garmin API)
Heart Rate / ECG
(Medibiosense API)
Device
Integration
(Withings)
Device
Integration
(Garmin)
Device
Integration
(Vitalpatch)
Sensor-FHIR
converter
FHIR server
Metadvice’s
cardiometabolic
DSS services
Sensor data
Sensor
data
Sensor data
FHIR resources
FHIR resources
Figure 7: The REFLECT architecture
13

22. 3. Processing time i
The argumentation-based reasoner was associated with longer execution times.
user dialogue manager argumentation engine
This risked affecting the response time of other parts of the system:
user dashboard health data store
14

23. 3. Processing time ii
The use of microservices ensures that interactions with the argumentation engine are a distinct
flow, and other flows are unaffected:
t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10
Time
0
5
10
15
20
Response
time
(secs)
argumentation
dashboard
Figure 8: Independence of argumentation engine and dashboard services
15

24. 3. Processing time iii
Caveat: Flows containing the dialogue manager still have to wait. However, other services in
the flow (e.g. the dialogue manager) remain responsive to report on longer execution times.
user dialogue manager argumentation engine
16

25. 4. Ease of deployment
We wanted the observations made based on the use of CONSULT to potentially be
reproduced, but were not comfortable releasing (the schema of) our health data server as a
part of the architecture.
user dashboard health data store
wearable device sensor integration health data store
17

26. 4. Ease of deployment
We wanted the observations made based on the use of CONSULT to potentially be
reproduced, but were not comfortable releasing (the schema of) our health data server as a
part of the architecture.
user dashboard health data store
wearable device sensor integration health data store
Microservices ensure deployment is still possible in the absence of certain services. New users
are able to plug new services into the architecture (e.g. a replacement health data store).
17

27. 4. Ease of deployment
We wanted the observations made based on the use of CONSULT to potentially be
reproduced, but were not comfortable releasing (the schema of) our health data server as a
part of the architecture.
user dashboard health data store
wearable device sensor integration health data store
Microservices ensure deployment is still possible in the absence of certain services. New users
are able to plug new services into the architecture (e.g. a replacement health data store).
Caveat: The use of services might actually hinder deployment, if too many are used and
the architecture becomes overly complex. A balance needs to be found between having
services with a limited remit and having an appropriate number of services so as to ensure
intelligibility.
17

28. 5. Scalability
We wanted to be able to have complex data sources as input to the system (e.g. wearable
device data) without losing any data.
18

29. 5. Scalability
We wanted to be able to have complex data sources as input to the system (e.g. wearable
device data) without losing any data.
Service replication ensures high volumes of data can be collected; the use of a queue ensures
data is not lost if a service enters an error state:
wearable device sensor integration
sensor integration
sensor integration
health data store
queue
queue
queue
18

30. 5. Scalability i
We can, again, see this
in practice:
monolithic CONSULT
0
20000
40000
60000
80000
100000
120000
140000
Average
responses
Ok
Timeout
Figure 9: How CONSULT responds to high load vs. an emulated monolithic
architecture
19

31. 5. Scalability ii
Caveat: Replicating services has a limited impact in some areas of the system; it does not,
for example, extend to distributed processing in the case of the argumentation engine.
user dialogue manager argumentation engine
20

32. Limitations and considerations
• Monolithic architectures are not always a bad way to structure software. If well
resourced, they too can solve many of the problems we have identified. However, we
believe that a microservice approach achieves the benefits we have seen by design.
• The use of a microservice architecture, while solving many problems, has no impact on
user interface design, a key component of patient-friendly software.
• Microservices may introduce new issues (e.g. questions of governance).
21

33. Summary and Future Work
• It can be difficult to develop a piece of software that facilitates research and is suitable
for use by patients.
• We believe developing software for these purposes under the microservice architecture
paradigm can address this issue.
• Despite its impact, we have identified limitations with the application of the paradigm. In
some cases, we have tried to offset these limitations with additional contributions (e.g.
a dialogue templating syntax), but some issues remain and should be considered when
using a microservice approach.
• Overall, we want to encourage the use of established software engineering techniques
when software is developed for research with patients.
Future work will, among other things, explore the impact of the paradigm on other users, such
as general practitioners (GPs).
22

34. Thank you!
22