SlideShare a Scribd company logo
Using Microservices to Design Patient-facing Research
Software
IEEE 18th International Conference on e-Science
Martin Chapman
King’s College London
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
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
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
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
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
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
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
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
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
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
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
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
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
1. Software development
The CONSULT team consistent predominantly of researchers familiar with Python and with R.
11
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
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
2. Modularity
The CONSULT team wanted to be able to switch out the existing argumentation-based
reasoner for other reasoners in the future.
12
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Thank you!
22

More Related Content

Similar to Using Microservices to Design Patient-facing Research Software

A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...
A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...
A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...
iosrjce
 
Software Process and Requirement
Software Process and RequirementSoftware Process and Requirement
Software Process and Requirement
cricket2ime
 
Software engineering introduction
Software engineering introductionSoftware engineering introduction
Software engineering introduction
Vishal Singh
 
Software Architecture for Robotics
Software Architecture for RoboticsSoftware Architecture for Robotics
Software Architecture for Robotics
Lorran Pegoretti
 
Software Evaluation
Software EvaluationSoftware Evaluation
Software Evaluation
Lori Gilbert
 
End User Computing
End User ComputingEnd User Computing
End User Computing
Ram Dutt Shukla
 
81-T48
81-T4881-T48
Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...
Editor IJCATR
 
Improved Strategy for Distributed Processing and Network Application Development
Improved Strategy for Distributed Processing and Network Application DevelopmentImproved Strategy for Distributed Processing and Network Application Development
Improved Strategy for Distributed Processing and Network Application Development
Editor IJCATR
 
Cruise
CruiseCruise
Public voice
Public voicePublic voice
Public voice
Emmanuel college
 
A Voice Based Assistant Using Google Dialogflow And Machine Learning
A Voice Based Assistant Using Google Dialogflow And Machine LearningA Voice Based Assistant Using Google Dialogflow And Machine Learning
A Voice Based Assistant Using Google Dialogflow And Machine Learning
Emily Smith
 
H1803044651
H1803044651H1803044651
H1803044651
IOSR Journals
 
health care chatbot using data science with python
health care chatbot using data science with pythonhealth care chatbot using data science with python
health care chatbot using data science with python
ROGNationYT
 
Development Tools - Abhijeet
Development Tools - AbhijeetDevelopment Tools - Abhijeet
Development Tools - Abhijeet
Abhijeet Kalsi
 
Constructing a software requirements specification and design for electronic ...
Constructing a software requirements specification and design for electronic ...Constructing a software requirements specification and design for electronic ...
Constructing a software requirements specification and design for electronic ...
Ra'Fat Al-Msie'deen
 
Report hospital
Report hospitalReport hospital
Report hospital
Rachit Gaur
 
chapter 7.docx
chapter 7.docxchapter 7.docx
chapter 7.docx
Sami Siddiqui
 
chapter 7.pdf
chapter 7.pdfchapter 7.pdf
chapter 7.pdf
Sami Siddiqui
 
Service Ecosystem
Service EcosystemService Ecosystem
Service Ecosystem
Richard Veryard
 

Similar to Using Microservices to Design Patient-facing Research Software (20)

A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...
A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...
A Generic Open Source Framework for Auto Generation of Data Manipulation Comm...
 
Software Process and Requirement
Software Process and RequirementSoftware Process and Requirement
Software Process and Requirement
 
Software engineering introduction
Software engineering introductionSoftware engineering introduction
Software engineering introduction
 
Software Architecture for Robotics
Software Architecture for RoboticsSoftware Architecture for Robotics
Software Architecture for Robotics
 
Software Evaluation
Software EvaluationSoftware Evaluation
Software Evaluation
 
End User Computing
End User ComputingEnd User Computing
End User Computing
 
81-T48
81-T4881-T48
81-T48
 
Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...
 
Improved Strategy for Distributed Processing and Network Application Development
Improved Strategy for Distributed Processing and Network Application DevelopmentImproved Strategy for Distributed Processing and Network Application Development
Improved Strategy for Distributed Processing and Network Application Development
 
Cruise
CruiseCruise
Cruise
 
Public voice
Public voicePublic voice
Public voice
 
A Voice Based Assistant Using Google Dialogflow And Machine Learning
A Voice Based Assistant Using Google Dialogflow And Machine LearningA Voice Based Assistant Using Google Dialogflow And Machine Learning
A Voice Based Assistant Using Google Dialogflow And Machine Learning
 
H1803044651
H1803044651H1803044651
H1803044651
 
health care chatbot using data science with python
health care chatbot using data science with pythonhealth care chatbot using data science with python
health care chatbot using data science with python
 
Development Tools - Abhijeet
Development Tools - AbhijeetDevelopment Tools - Abhijeet
Development Tools - Abhijeet
 
Constructing a software requirements specification and design for electronic ...
Constructing a software requirements specification and design for electronic ...Constructing a software requirements specification and design for electronic ...
Constructing a software requirements specification and design for electronic ...
 
Report hospital
Report hospitalReport hospital
Report hospital
 
chapter 7.docx
chapter 7.docxchapter 7.docx
chapter 7.docx
 
chapter 7.pdf
chapter 7.pdfchapter 7.pdf
chapter 7.pdf
 
Service Ecosystem
Service EcosystemService Ecosystem
Service Ecosystem
 

More from Martin Chapman

Principles of Health Informatics: Artificial intelligence and machine learning
Principles of Health Informatics: Artificial intelligence and machine learningPrinciples of Health Informatics: Artificial intelligence and machine learning
Principles of Health Informatics: Artificial intelligence and machine learning
Martin Chapman
 
Principles of Health Informatics: Clinical decision support systems
Principles of Health Informatics: Clinical decision support systemsPrinciples of Health Informatics: Clinical decision support systems
Principles of Health Informatics: Clinical decision support systems
Martin Chapman
 
Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...
Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...
Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...
Martin Chapman
 
Technical Validation through Automated Testing
Technical Validation through Automated TestingTechnical Validation through Automated Testing
Technical Validation through Automated Testing
Martin Chapman
 
Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...
Martin Chapman
 
Using AI to autonomously identify diseases within groups of patients
Using AI to autonomously identify diseases within groups of patientsUsing AI to autonomously identify diseases within groups of patients
Using AI to autonomously identify diseases within groups of patients
Martin Chapman
 
Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...
Martin Chapman
 
Principles of Health Informatics: Evaluating medical software
Principles of Health Informatics: Evaluating medical softwarePrinciples of Health Informatics: Evaluating medical software
Principles of Health Informatics: Evaluating medical software
Martin Chapman
 
Principles of Health Informatics: Usability of medical software
Principles of Health Informatics: Usability of medical softwarePrinciples of Health Informatics: Usability of medical software
Principles of Health Informatics: Usability of medical software
Martin Chapman
 
Principles of Health Informatics: Social networks, telehealth, and mobile health
Principles of Health Informatics: Social networks, telehealth, and mobile healthPrinciples of Health Informatics: Social networks, telehealth, and mobile health
Principles of Health Informatics: Social networks, telehealth, and mobile health
Martin Chapman
 
Principles of Health Informatics: Communication systems in healthcare
Principles of Health Informatics: Communication systems in healthcarePrinciples of Health Informatics: Communication systems in healthcare
Principles of Health Informatics: Communication systems in healthcare
Martin Chapman
 
Principles of Health Informatics: Terminologies and classification systems
Principles of Health Informatics: Terminologies and classification systemsPrinciples of Health Informatics: Terminologies and classification systems
Principles of Health Informatics: Terminologies and classification systems
Martin Chapman
 
Principles of Health Informatics: Representing medical knowledge
Principles of Health Informatics: Representing medical knowledgePrinciples of Health Informatics: Representing medical knowledge
Principles of Health Informatics: Representing medical knowledge
Martin Chapman
 
Principles of Health Informatics: Informatics skills - searching and making d...
Principles of Health Informatics: Informatics skills - searching and making d...Principles of Health Informatics: Informatics skills - searching and making d...
Principles of Health Informatics: Informatics skills - searching and making d...
Martin Chapman
 
Principles of Health Informatics: Informatics skills - communicating, structu...
Principles of Health Informatics: Informatics skills - communicating, structu...Principles of Health Informatics: Informatics skills - communicating, structu...
Principles of Health Informatics: Informatics skills - communicating, structu...
Martin Chapman
 
Principles of Health Informatics: Models, information, and information systems
Principles of Health Informatics: Models, information, and information systemsPrinciples of Health Informatics: Models, information, and information systems
Principles of Health Informatics: Models, information, and information systems
Martin Chapman
 
Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...
Martin Chapman
 
Using CWL to support EHR-based phenotyping
Using CWL to support EHR-based phenotypingUsing CWL to support EHR-based phenotyping
Using CWL to support EHR-based phenotyping
Martin Chapman
 
Phenoflow: An Architecture for Computable Phenotypes
Phenoflow: An Architecture for Computable PhenotypesPhenoflow: An Architecture for Computable Phenotypes
Phenoflow: An Architecture for Computable Phenotypes
Martin Chapman
 
Phenoflow 2021
Phenoflow 2021Phenoflow 2021
Phenoflow 2021
Martin Chapman
 

More from Martin Chapman (20)

Principles of Health Informatics: Artificial intelligence and machine learning
Principles of Health Informatics: Artificial intelligence and machine learningPrinciples of Health Informatics: Artificial intelligence and machine learning
Principles of Health Informatics: Artificial intelligence and machine learning
 
Principles of Health Informatics: Clinical decision support systems
Principles of Health Informatics: Clinical decision support systemsPrinciples of Health Informatics: Clinical decision support systems
Principles of Health Informatics: Clinical decision support systems
 
Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...
Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...
Mechanisms for Integrating Real Data into Search Game Simulations: An Applica...
 
Technical Validation through Automated Testing
Technical Validation through Automated TestingTechnical Validation through Automated Testing
Technical Validation through Automated Testing
 
Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...
 
Using AI to autonomously identify diseases within groups of patients
Using AI to autonomously identify diseases within groups of patientsUsing AI to autonomously identify diseases within groups of patients
Using AI to autonomously identify diseases within groups of patients
 
Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...
 
Principles of Health Informatics: Evaluating medical software
Principles of Health Informatics: Evaluating medical softwarePrinciples of Health Informatics: Evaluating medical software
Principles of Health Informatics: Evaluating medical software
 
Principles of Health Informatics: Usability of medical software
Principles of Health Informatics: Usability of medical softwarePrinciples of Health Informatics: Usability of medical software
Principles of Health Informatics: Usability of medical software
 
Principles of Health Informatics: Social networks, telehealth, and mobile health
Principles of Health Informatics: Social networks, telehealth, and mobile healthPrinciples of Health Informatics: Social networks, telehealth, and mobile health
Principles of Health Informatics: Social networks, telehealth, and mobile health
 
Principles of Health Informatics: Communication systems in healthcare
Principles of Health Informatics: Communication systems in healthcarePrinciples of Health Informatics: Communication systems in healthcare
Principles of Health Informatics: Communication systems in healthcare
 
Principles of Health Informatics: Terminologies and classification systems
Principles of Health Informatics: Terminologies and classification systemsPrinciples of Health Informatics: Terminologies and classification systems
Principles of Health Informatics: Terminologies and classification systems
 
Principles of Health Informatics: Representing medical knowledge
Principles of Health Informatics: Representing medical knowledgePrinciples of Health Informatics: Representing medical knowledge
Principles of Health Informatics: Representing medical knowledge
 
Principles of Health Informatics: Informatics skills - searching and making d...
Principles of Health Informatics: Informatics skills - searching and making d...Principles of Health Informatics: Informatics skills - searching and making d...
Principles of Health Informatics: Informatics skills - searching and making d...
 
Principles of Health Informatics: Informatics skills - communicating, structu...
Principles of Health Informatics: Informatics skills - communicating, structu...Principles of Health Informatics: Informatics skills - communicating, structu...
Principles of Health Informatics: Informatics skills - communicating, structu...
 
Principles of Health Informatics: Models, information, and information systems
Principles of Health Informatics: Models, information, and information systemsPrinciples of Health Informatics: Models, information, and information systems
Principles of Health Informatics: Models, information, and information systems
 
Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...Using AI to understand how preventative interventions can improve the health ...
Using AI to understand how preventative interventions can improve the health ...
 
Using CWL to support EHR-based phenotyping
Using CWL to support EHR-based phenotypingUsing CWL to support EHR-based phenotyping
Using CWL to support EHR-based phenotyping
 
Phenoflow: An Architecture for Computable Phenotypes
Phenoflow: An Architecture for Computable PhenotypesPhenoflow: An Architecture for Computable Phenotypes
Phenoflow: An Architecture for Computable Phenotypes
 
Phenoflow 2021
Phenoflow 2021Phenoflow 2021
Phenoflow 2021
 

Recently uploaded

HYPERTENSION - SLIDE SHARE PRESENTATION.
HYPERTENSION - SLIDE SHARE PRESENTATION.HYPERTENSION - SLIDE SHARE PRESENTATION.
HYPERTENSION - SLIDE SHARE PRESENTATION.
deepaannamalai16
 
writing about opinions about Australia the movie
writing about opinions about Australia the moviewriting about opinions about Australia the movie
writing about opinions about Australia the movie
Nicholas Montgomery
 
Nutrition Inc FY 2024, 4 - Hour Training
Nutrition Inc FY 2024, 4 - Hour TrainingNutrition Inc FY 2024, 4 - Hour Training
Nutrition Inc FY 2024, 4 - Hour Training
melliereed
 
Electric Fetus - Record Store Scavenger Hunt
Electric Fetus - Record Store Scavenger HuntElectric Fetus - Record Store Scavenger Hunt
Electric Fetus - Record Store Scavenger Hunt
RamseyBerglund
 
Lifelines of National Economy chapter for Class 10 STUDY MATERIAL PDF
Lifelines of National Economy chapter for Class 10 STUDY MATERIAL PDFLifelines of National Economy chapter for Class 10 STUDY MATERIAL PDF
Lifelines of National Economy chapter for Class 10 STUDY MATERIAL PDF
Vivekanand Anglo Vedic Academy
 
Présentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptx
Présentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptxPrésentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptx
Présentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptx
siemaillard
 
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptxPengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Fajar Baskoro
 
BBR 2024 Summer Sessions Interview Training
BBR  2024 Summer Sessions Interview TrainingBBR  2024 Summer Sessions Interview Training
BBR 2024 Summer Sessions Interview Training
Katrina Pritchard
 
RESULTS OF THE EVALUATION QUESTIONNAIRE.pptx
RESULTS OF THE EVALUATION QUESTIONNAIRE.pptxRESULTS OF THE EVALUATION QUESTIONNAIRE.pptx
RESULTS OF THE EVALUATION QUESTIONNAIRE.pptx
zuzanka
 
مصحف القراءات العشر أعد أحرف الخلاف سمير بسيوني.pdf
مصحف القراءات العشر   أعد أحرف الخلاف سمير بسيوني.pdfمصحف القراءات العشر   أعد أحرف الخلاف سمير بسيوني.pdf
مصحف القراءات العشر أعد أحرف الخلاف سمير بسيوني.pdf
سمير بسيوني
 
Chapter wise All Notes of First year Basic Civil Engineering.pptx
Chapter wise All Notes of First year Basic Civil Engineering.pptxChapter wise All Notes of First year Basic Civil Engineering.pptx
Chapter wise All Notes of First year Basic Civil Engineering.pptx
Denish Jangid
 
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UPLAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
RAHUL
 
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptxC1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
mulvey2
 
Benner "Expanding Pathways to Publishing Careers"
Benner "Expanding Pathways to Publishing Careers"Benner "Expanding Pathways to Publishing Careers"
Benner "Expanding Pathways to Publishing Careers"
National Information Standards Organization (NISO)
 
Mule event processing models | MuleSoft Mysore Meetup #47
Mule event processing models | MuleSoft Mysore Meetup #47Mule event processing models | MuleSoft Mysore Meetup #47
Mule event processing models | MuleSoft Mysore Meetup #47
MysoreMuleSoftMeetup
 
A Visual Guide to 1 Samuel | A Tale of Two Hearts
A Visual Guide to 1 Samuel | A Tale of Two HeartsA Visual Guide to 1 Samuel | A Tale of Two Hearts
A Visual Guide to 1 Samuel | A Tale of Two Hearts
Steve Thomason
 
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
Nguyen Thanh Tu Collection
 
Standardized tool for Intelligence test.
Standardized tool for Intelligence test.Standardized tool for Intelligence test.
Standardized tool for Intelligence test.
deepaannamalai16
 
How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17
Celine George
 
Philippine Edukasyong Pantahanan at Pangkabuhayan (EPP) Curriculum
Philippine Edukasyong Pantahanan at Pangkabuhayan (EPP) CurriculumPhilippine Edukasyong Pantahanan at Pangkabuhayan (EPP) Curriculum
Philippine Edukasyong Pantahanan at Pangkabuhayan (EPP) Curriculum
MJDuyan
 

Recently uploaded (20)

HYPERTENSION - SLIDE SHARE PRESENTATION.
HYPERTENSION - SLIDE SHARE PRESENTATION.HYPERTENSION - SLIDE SHARE PRESENTATION.
HYPERTENSION - SLIDE SHARE PRESENTATION.
 
writing about opinions about Australia the movie
writing about opinions about Australia the moviewriting about opinions about Australia the movie
writing about opinions about Australia the movie
 
Nutrition Inc FY 2024, 4 - Hour Training
Nutrition Inc FY 2024, 4 - Hour TrainingNutrition Inc FY 2024, 4 - Hour Training
Nutrition Inc FY 2024, 4 - Hour Training
 
Electric Fetus - Record Store Scavenger Hunt
Electric Fetus - Record Store Scavenger HuntElectric Fetus - Record Store Scavenger Hunt
Electric Fetus - Record Store Scavenger Hunt
 
Lifelines of National Economy chapter for Class 10 STUDY MATERIAL PDF
Lifelines of National Economy chapter for Class 10 STUDY MATERIAL PDFLifelines of National Economy chapter for Class 10 STUDY MATERIAL PDF
Lifelines of National Economy chapter for Class 10 STUDY MATERIAL PDF
 
Présentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptx
Présentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptxPrésentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptx
Présentationvvvvvvvvvvvvvvvvvvvvvvvvvvvv2.pptx
 
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptxPengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptx
 
BBR 2024 Summer Sessions Interview Training
BBR  2024 Summer Sessions Interview TrainingBBR  2024 Summer Sessions Interview Training
BBR 2024 Summer Sessions Interview Training
 
RESULTS OF THE EVALUATION QUESTIONNAIRE.pptx
RESULTS OF THE EVALUATION QUESTIONNAIRE.pptxRESULTS OF THE EVALUATION QUESTIONNAIRE.pptx
RESULTS OF THE EVALUATION QUESTIONNAIRE.pptx
 
مصحف القراءات العشر أعد أحرف الخلاف سمير بسيوني.pdf
مصحف القراءات العشر   أعد أحرف الخلاف سمير بسيوني.pdfمصحف القراءات العشر   أعد أحرف الخلاف سمير بسيوني.pdf
مصحف القراءات العشر أعد أحرف الخلاف سمير بسيوني.pdf
 
Chapter wise All Notes of First year Basic Civil Engineering.pptx
Chapter wise All Notes of First year Basic Civil Engineering.pptxChapter wise All Notes of First year Basic Civil Engineering.pptx
Chapter wise All Notes of First year Basic Civil Engineering.pptx
 
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UPLAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
 
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptxC1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
C1 Rubenstein AP HuG xxxxxxxxxxxxxx.pptx
 
Benner "Expanding Pathways to Publishing Careers"
Benner "Expanding Pathways to Publishing Careers"Benner "Expanding Pathways to Publishing Careers"
Benner "Expanding Pathways to Publishing Careers"
 
Mule event processing models | MuleSoft Mysore Meetup #47
Mule event processing models | MuleSoft Mysore Meetup #47Mule event processing models | MuleSoft Mysore Meetup #47
Mule event processing models | MuleSoft Mysore Meetup #47
 
A Visual Guide to 1 Samuel | A Tale of Two Hearts
A Visual Guide to 1 Samuel | A Tale of Two HeartsA Visual Guide to 1 Samuel | A Tale of Two Hearts
A Visual Guide to 1 Samuel | A Tale of Two Hearts
 
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
 
Standardized tool for Intelligence test.
Standardized tool for Intelligence test.Standardized tool for Intelligence test.
Standardized tool for Intelligence test.
 
How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17How to Make a Field Mandatory in Odoo 17
How to Make a Field Mandatory in Odoo 17
 
Philippine Edukasyong Pantahanan at Pangkabuhayan (EPP) Curriculum
Philippine Edukasyong Pantahanan at Pangkabuhayan (EPP) CurriculumPhilippine Edukasyong Pantahanan at Pangkabuhayan (EPP) Curriculum
Philippine Edukasyong Pantahanan at Pangkabuhayan (EPP) Curriculum
 

Using Microservices to Design Patient-facing Research Software

  • 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