EUROCON, COHEAT, Novi Sad, Serbia, 2019

1. A Microservice Architecture for the Design of
Computer-Interpretable Guideline Processing
Tools
Paper: 08828
Martin Chapman and Vasa Curcin
King’s College London

2. Terminology i
Clinical Practice Guidelines (CPGs)
• ‘Systematically developed statements to assist practitioner and
patient decisions about appropriate health care for specific
clinical circumstances’ [3].
Computer-Interpetable Guidelines (CIGs)
• Representations of CIGs that are computer processable.
1

3. Terminology ii
CIG formalisms
• GLIF3 [5], Proforma [7] and GLARE [8].
CIG reasoners
• Interactions [9].
• Patient personalisation [6].
CIG formalism + CIG reasoner = CIG processing tool.
2

4. Decision-support systems (DSSs) and CIG processing tools.
A (clinical) decision support system (DSS) is designed to provide a
clinician, or patient, with recommendations in order to assist with
clinical decision making [2].
The output of CIG processing tools are a natural data source for DSSs.
• First, formalise medical knowledge.
• Autonomously invoke processing on guidelines, and use the
results.
3

5. Integration challenges
Geared for human interaction.
• No autonomous interaction.
No standard communication between CIG formalisms (stores) and
reasoners.
• Data redundancy.
• Limited interactivity across different tools.
Difficult technical deployment and limited resilience and scalability.
4

6. RESTful Microservices
A microservice architecture separates the features of a system into
individual services [4].
Microservices are often also RESTful (Representational State
Transfer), which means that the functionality of the systems they
contain can be invoked using URIs that are defined as a part of that
service’s Application Programming Interface (API) [1].
5

7. A Microservice Architecture for Guideline Processing Tools i
Services
1. Interaction: exposes the functionality offered by the tool.
2. Reasoner: encapsulates the tool’s reasoner.
3. Store: encapsulates the software required to store CPG
information.
Endpoints
1. Create guideline sets.
2. Add or delete new guideline information or knowledge.
3. Retrieve guideline information.
4. Invoke processing.
6

8. A Microservice Architecture for Guideline Processing Tools ii
Clinician GUI Decision-making Interaction Reasoner Store
Input
Send
Store
Confirm
Confirm
Confirm
Trigger
Call
Retrieve
Guidelines
Process
Response
Response
Process
Addresses these issues. How?
7

9. Tools designed under this architecture...
Increase interoperability through well-defined services and
endpoints.
Facilitate autonomous communication by providing RESTful
endpoints with machine-processable responses.
Are resilient by having an interaction proxy to the reasoner.
Scale, by allowing components of the system, such as the reasoner,
that may receive heavy load to be replicated.
Integrate with other processing tools also designed under the
architecture
• Same store, multiple reasoners; reusability.
• Different stores, same reasoner; technological heterogeneity.
8

10. Case Study: Interaction tool redesign. i
Redesigning Zamborlini et al’s guideline interaction tool.
Web Interface Prolog Reasoner GuidelinesService
SWISH
Interaction
Interaction API
(JS Server)
Reasoner
Reasoner API
(Prolog Server)
Prolog Reasoner
Store Store API API Guidelines
Apache Jena Fuseki
9

11. Case Study: Interaction tool redesign. ii
Table 1: Endpoints for the reconfigured interaction tool
Microservice Endpoints Instantiation
Interaction
/guideline/create/ N
/guideline/add/ N
/guideline/drug/add Y
/guideline/transition/add Y
/guideline/belief/add Y
/guideline/.+/delete N
/guideline/drug/get Y
/guideline/drug/effect/get Y
/guidelines/interactions Y
Reasoner /guidelines/.+ -
Store /guideline/.+ -
10

12. Case Study: DSS Integration
The redesigned guideline interaction tool has been integrated with
two DSSs:
1. CONSULT, assisting stroke patients in self-managing their
treatments: https://consult.kcl.ac.uk/.
2. ROAD2H, providing access to healthcare in low and
middle-income countries: http://www.road2h.org/.
Calls are made to the tool by the DSS’s decision-making component.
11

13. References i
R. T. Fielding.
Architectural styles and the design of network-based software
architectures.
Ph.d. thesis, University of California Irvine, 2000.
D. L. Hunt, R. B. Haynes, S. E. Hanna, and K. Smith.
Effects of Computer-Based Clinical Decision Support Systems
on Physician Performance and Patient Outcomes.
JAMA, 280(15):1339, oct 1998.
Institute of Medicine.
Clinical Practice Guidelines: Directions for a New Program.
Technical Report 8, Institute of Medicine, 1990.
12

14. References ii
S. Newman.
Building Microservices.
O’Reilly Media, Inc., 1st edition, 2015.
M. Peleg, A. A. Boxwala, O. Ogunyemi, Q. Zeng, S. Tu, R. Lacson,
E. Bernstam, N. Ash, P. Mork, L. Ohno-Machado, E. H. Shortliffe,
and R. A. Greenes.
GLIF3: the evolution of a guideline representation format.
AMIA Symposium, pages 645–9, 2000.
D. Riaño, F. Real, J. A. López-Vallverdú, F. Campana, S. Ercolani,
P. Mecocci, R. Annicchiarico, and C. Caltagirone.
An ontology-based personalization of health-care knowledge
to support clinical decisions for chronically ill patients.
JBI, 45(3):429–446, 2012.
13

15. References iii
D. R. Sutton and J. Fox.
The Syntax and Semantics of the PROforma Guideline Modeling
Language.
JAMIA, 10(5):433–443, sep 2003.
P. Terenziani, P. Terenziani, S. Montani, S. Montani, A. Bottrighi,
A. Bottrighi, M. Torchio, M. Torchio, G. Molino, G. Molino,
G. Correndo, and G. Correndo.
The GLARE approach to clinical guidelines: Main features.
In Studies in HTI, volume 101, pages 162–166, 2004.
V. Zamborlini, J. Wielemaker, M. Da Silveira, C. Pruski, A. Ten Teije,
and F. Van Harmelen.
SWISH for prototyping clinical guideline interactions theory.
In CEUR, volume 1795, 2016.
14