Keywords HL7 FHIR - multi-agent systems - clinical decision support - telemedicine
Background and Significance
Background and Significance
Innovations in information and communication technologies provide a promising way
to bridge the gap between a patient's home and the clinic through telemedicine services.[1 ]
[2 ] This new digital health care model (often known as e-health ) aims to promote patient self-sufficiency, self-management, and empowerment.[3 ]
[4 ] Smartphones, tablets, and smartwatches support the collection and transmission of
clinical data—patient-reported outcomes (PROs) and patient-generated data (PGD)—which
can be integrated with clinical data in the electronic health record (EHR) for a comprehensive
overview of the patient state. Data mining and artificial intelligence (AI) techniques
help in automating the analysis of the huge amount of information collected.[5 ]
This work was conducted in the context of the European Union (EU)-funded CAPABLE project.
CAPABLE focuses on the exploitation of big data (in particular PROs and PGD) using
AI techniques to effectively monitor cancer patients. The authors developed a multi-agent
system (MAS) that acquires data from patients and provides them with coaching and
their doctors with clinical decision support. This article focuses on the distributed
software agent architecture of CAPABLE and its core component—the Case Manager (CM)—that
acts as an orchestrator for the agent activities. CAPABLE will be deployed at two
clinical centers, Istituti Clinici Scientifici Maugeri (ICSM) in Pavia, Italy, and
National Cancer Institute (NKI) in Amsterdam, The Netherlands, where the concept will
be tested in a pilot study involving different cancer types.
Opportunities and Challenges of Multiagent Systems
MASs consist of a network of loosely coupled, intelligent, autonomous entities that
dynamically interact to solve problems falling beyond the expertise of a single entity.[6 ] There is a growing interest in using MASs in a medical context where problems are
inherently complex and interdisciplinary, requiring heterogeneous knowledge sources
to process data collected at different sites.[7 ]
[8 ]
[9 ]
[10 ] Agents involved in a MAS often communicate through a shared data repository called
a blackboard (the so-called Blackboard Architecture).[11 ] To save agents from continuously querying the blackboard, a control agent is usually
introduced. When an agent can potentially contribute to the problem-solving process,
it is activated by the control agent in response to specific triggering events generated
by changes on the blackboard. Thus, each agent must first inform the control agent
about the type of events it is interested in. Such an event-based Blackboard Architecture
is adopted in several contexts exploiting MASs and is widely referenced in the literature.[12 ]
[13 ]
[14 ]
[15 ]
MASs rely on interoperability at technical, semantic, and process levels. Communication
standards allow technical interoperability, but semantic interoperability is also
needed since agents must know how to properly interpret any exchanged data in order
to use them appropriately. A well-known syntactic and semantic standard for improving
interoperability between different health care applications is HL7 (Health Level 7)
FHIR (Fast Healthcare Interoperability Resources).[16 ]
[17 ] FHIR has gained strong acceptance by health care information system developers and
is now widely adopted for representing and sharing clinical information in systems
providing various functionalities including decision support.[18 ]
[19 ]
[20 ]
[21 ]
Agents rely on various Data Sources including the EHR and other hospital information
systems, various types of sensors, and other applications targeting patients and doctors.
Data items are mapped to unique concepts using standardized terminologies such as
SNOMED CT,[22 ] RxNorm,[23 ] LOINC,[24 ]
[25 ] or the ICD Family.[26 ]
The CAPABLE System as a MAS
The high-level architecture adopted by CAPABLE is shown in [Fig. 1 ]. PROs are entered by patients through forms or questionnaires on smartphones while
PGD are acquired using wearable or environmental sensors. Data collected at regular
visits are available from the EHR. All these data are saved on a shared Data Platform
(DP), representing the system blackboard, which makes them available to patients and
doctors for perusal and to other agents for automated processing. Because of the multidisciplinary
nature of the knowledge involved, we have leveraged standards-based and service model
approaches of other architectures to implement a distributed decision support system
(DSS) based on Computer Interpretable Guidelines (CIGs) applied by agents.[27 ]
[28 ] This provides flexibility in representing knowledge and makes agents responsible
for recognizing when they can use their specific problem-solving skills and contribute
new data and information. The main agents that encapsulate the required knowledge
sources for processing data are:
Fig. 1 The big picture illustrating the CAPABLE architecture and its primary components
acting as independent agents that encapsulate the Knowledge Sources required for processing patient data.
CIG Engine : manages CIGs by instantiating and executing them for specific patients in cooperation
with the other agents.
Virtual Coach (VC): provides patients with coaching and motivational support controlled by CIGs
and workflows, expert-based rules, and models based on behavior change theories, in
particular the Fogg behavior model.[29 ] These support modalities follow the recommended intervention strategies proposed
in the ICT4PEM framework.[30 ]
Multimorbidity Controller (GoCom): checks for and mitigates any conflict caused by recommendations coming from
multiple CIGs. GoCom is goal-oriented and uses hierarchical goal-tree structures to
represent the patients' problems and treatments. Drug–drug interactions and guideline
recommendation interactions are detected and mitigated automatically. Alternative
options for nonconflicting treatment combinations are stored in the DP and afterwards
presented to the physician by the graphical user interface.
Physician DSS (PDSS): supports clinicians with hints and action suggestions from active CIGs.
Knowledge-Data Ontology Mapper : computes clinical abstractions on raw data, PROs, and PGD concerning the patient.
In PDSS and VC, most knowledge is captured through CIGs expressed in the PROforma
language, which models clinical processes as formal networks of tasks with logical
conditions governing their execution.[31 ] Additionally, VC relies on a few algorithms implemented as internal modules. These
algorithms are more computationally demanding and are more effectively implemented
outside of PROforma. GoCom relies on domain knowledge provided by external sources
(i.e., repositories with drug characteristics including potential interactions) and
on a specialized planning algorithm which constructs goal trees from PROforma CIGs
and is implemented directly in GoCom.
In CAPABLE agents are triggered by Events that are associated with conditions occurring on the blackboard. This is shown in
[Fig. 1 ] through narrow arrows representing the control flow as opposed to wide arrows representing
data and information flow. Events allow agents to set up a cooperative process dynamically
shaped on an opportunistic basis following the incremental addition of information
to the DP. Consequently, there is a strong need to orchestrate the efforts of all
the agents. This translates into triggering an agent whenever a data pattern recognized
and handled by that agent appears in the DP. This is accomplished by the CM which
is described in the next sections.
Materials and Methods
Exploiting the HL7 FHIR Standard in CAPABLE
All data in CAPABLE, either generated by the system or extracted from the EHR, are
internally stored in the DP using OMOP (Observational Medical Outcomes Partnership)
Common Data Model (CDM). OMOP-CDM was chosen to store patient data, instead of direct
FHIR persistence, to simplify the longitudinal analysis at the end of the pilot studies.
This is possible with tools developed within the OHDSI (Observational Health Data
Sciences and Informatics) initiative that leverage the ontology and connected vocabularies
on which OMOP-CDM is based.
However, for exchanging data within CAPABLE, instead of using the traditional clinical
document-centric approach, we preferred the compositive approach adopted by HL7 FHIR
R4 where health care information entities are represented as independent modular elements
called resources .[32 ] Using the FHIR REST Application Programming Interface (API), the only way to access
the data, all patient information is exchanged externally between data sources and
the DP and between the DP and the agents in the form of FHIR resources. FHIR resources
exchanged with the DP are transformed on-the-fly and mapped into OMOP elements leveraging
the OMOPonFHIR open-source software.[33 ]
Designing the FHIR-Based Case Manager
FHIR natively allows a push-based mechanism for notifying systems through its Subscriptions,
but we decided not to use it in CAPABLE for two reasons. First, Subscriptions have
a maturity level score of 3, which means that they are halfway between draft and normative,
and we were unsure about their implementation state in OMOPonFHIR . Second, and foremost, that mechanism considers each resource individually while
we wished to aggregate resources into clinically meaningful patterns.
The CM was designed for programmable behavior, to avoid hard-coding any relationship
among data required to trigger the various agents. Doing so would have linked the
CM closely to all other agents, mixing up the responsibilities of the developers and
deeply affecting the possibility of easily adding new agents.
The key to the programmable CM architecture is the Rule , which is a directive representing an event and encapsulating the conditions upon
which an agent is triggered by the CM. As shown in [Fig. 2 ], rules are dynamically loaded/unloaded to/from the CM by the agents whenever they
need to introduce or alter the data patterns causing their activation. Following the
loading of a new rule, the CM starts monitoring the DP and generates events that are
signaled to the interested agent whenever the rule conditions are met.
Fig. 2 Interaction of an Agent with the Case Manager: Agents subscribe with the Case Manager
through Rules and are notified by it through Events .
Devising a syntax for the rule language was simplified by the adoption of FHIR. Rules
are written in JSON and filter conditions for data on the DP leverage the syntax adopted
by FHIR searches ([Fig. 3 ] shows the rule productions expressed in the enhanced Backus–Naur form). Besides
clauses with filter conditions, agents may also add JavaScript code to check the FHIR
resources retrieved by the rule as a group, which represents the main difference from
FHIR Subscriptions. If the group passes the check, the event is generated and signaled
to the agent.
Fig. 3 The syntax adopted by Rules used by the Case Manager expressed in enhanced Backus–Naur form. Nonterminal symbols
are in bold with Rule being the top-level goal. Keyword terminals are in italic. Repetition symbols have
the usual meaning such as: “ + ” (one or more) and “?” (at most one).
[Fig. 4 ] shows a rule triggering events for patients whose recent fever Observations constitute
a monotonically increasing series including at least three values in the past 72 hours.
This is an artificial example that does not represent any specific piece of knowledge
in CAPABLE and only serves the purpose of contrasting the FHIR subscription approach
that always considers each resource individually. Lines 5 to 8 search for an active
Patient, while lines 9 to 14 search for his/her fever Observations in the past 72 hours.
Both queries rely on the FHIR syntax for searches. The operator rtge (line 13) implemented by the CM is an extension of the FHIR ge operator. It computes the time reference offsetting the current time by a period
expressed with the ISO 8601 standard. Since the time period is negative (i.e., −72 hours),
it searches for Observations with an effectiveDateTime greater than or equal to 72 hours in the past. The monotonic fever increase is expressed
by adding a JavaScript function checkFeverIncreasing() to the rule, which scans all the fever readings extracted and increments a variable
(bucket ) if they are increasing. Finally, the last JavaScript predicate returns true if a
Patient was actually found (Var1.length == 1 ) having at least three fever readings (Var2.length ≥ 3 ) and with checkFeverIncreasing() counting at least two intervals (i.e., among three values). If the predicate returns
true, the event is triggered and delivered to the interested agent.
Fig. 4 Example of a Case Manager rule. The rule triggers events for patients whose fever
Observations end with a monotonically increasing series including at least three values
collected during the past 72 hours.
Results
The CM has been developed as a Web service on top of the Jersey Framework API and
the Grizzly HTTP Engine. It is a separate module, written in Java, following the Observer pattern along with the DP which plays the role of the Observable notifying the CM about every change in data. This process is depicted in [Fig. 5 ] illustrating the acquisition of a new piece of data (New Data ) concerning a patient-reported symptom. The CM is informed about the new resource
by the DP and compares it to the conditions of every existing rule. If the resource
matches a rule's conditions, it is added to the evaluation set of that rule and the
JavaScript code is invoked on that set for possibly generating the corresponding event.
This approach enables the CM to behave as a highly responsive scheduler notifying
agents about their events of interest. Moreover, expressing the conditions for generating
events through declarative rules is an effective way for decoupling the implementation
of the CM from that of the agents. In the [Supplementary Appendices ] (available in the online version), we provide two sample use cases for better understanding
how the process orchestrated by the CM develops.
Fig. 5 The Case Manager acting as an Event scheduler. New information added to the Data Platform is signaled to the Case Manager
that matches it against all known rules and adds it to the evaluation sets of the
relevant ones (i.e., B, C). Following any change in the evaluation set, the JavaScript
code is eventually invoked and possibly an Event is generated (i.e., B).
Further flexibility is achieved through additional features offered by the rule syntax.
These allow (1) periodically flushing the evaluation sets to discard obsolete resources;
(2) periodically re-evaluating rules to generate additional (time-dependent) events
even in the absence of new resources; and (3) evaluating a rule for a single patient
or multiple patients (even though for diagnostic or therapeutic purposes data must
be analyzed on a per-patient basis, for higher level decisions data collected across
all patients may need to be checked). Finally, rules may be marked as Message Queues modeling the exchange of messages between agents, so that the CM can also play the
role of a plain broker. In this case, notifications will be triggered by every single
resource (referenced by the rule) when it is added to the DP and the notification
contents will include by design just the single resource representing the message
exchanged. This brokering role of the CM removes the need for direct interaction among
the agents and helps further enforce their decoupling as separate entities.
Validation
The CM together with other agents has been validated through approximately 20 clinical
scenarios addressing the treatment of cancer side effects. We used real patients'
data to create the scenarios with each one encompassing several segments representing
different time periods. For each segment, we prepared FHIR resources and we developed
a simulator to load them automatically preserving their relative time distances.[34 ] Based on the information loaded in the DP, the CM generates the right events for
the specific agents that manage the clinical case, according to the embedded knowledge
(e.g., PROforma CIGs). The simulator also allows checkpoints to be set up to automatically
verify the generation of the relevant events by the CM as well as the expected actions
and recommendations by the agents. All simulations confirmed the correct behavior
of the CM. The CAPABLE system is now being installed at the two hospitals, ICSM and
NKI, where the pilot studies will be accomplished, and enrollment is expected to start
shortly.
Discussion
When the CAPABLE consortium was assembled, each partner brought their methodological
and development expertise to devise an infrastructure composed of multiple independent
agents supporting both patients and doctors. It immediately became clear that enabling
communication and coordination among agents required:
The first requirement was satisfied by introducing FHIR across the whole system. To
address the second one, we did not want to set up separate communication channels
for all pairs of interacting agents since this approach had major limitations and
lacked scalability. Instead, our solution relied on the DP for data sharing and the
CM for encapsulating and operationalizing the knowledge required to coordinate the
agents. This approach is more comprehensive and unifying, much easier to manage, and
consistent with the efforts of layering knowledge into separate levels, adopting different
representation formalisms, which is a recurring issue in complex clinical AI applications.[36 ]
The CM was conceived based on our previous experiences with MASs.[37 ] Since we adopted FHIR, we designed the CM to support interoperability among loosely
coupled agents leveraging it as a common semantic framework. This helped in enforcing
a standard representation of medical information and ensuring proper interpretation
thereof.[38 ] The most distinguishing feature of the CM is that, instead of encapsulating the
knowledge that controls the overall behavior of the system,[39 ] it is completely customizable through a configuration language leveraged by the
very same agents that it is expected to drive. This reduces coupling among agents
allowing the integration of new ones.
In this context the CM shares some similarity with Arden Syntax (AS) rules.[40 ] Specifically, both allow defining events that trigger specific actions. AS rules
also specify action implementations in their action slots . However, they are limited to performing basic computations, displaying messages,
or storing data in the patient record. Another well-known limitation of AS is the
lack of an underlying data representation, which requires defining mappings to a specific
data repository. Adopting FHIR, the CM overcomes this limitation making the coordination
knowledge independent of an underlying data repository.
Another language for formally representing clinical rules is GDL (Guideline Definition
Language) leveraging the openEHR Reference Model and Archetype Model.[41 ]
[42 ] However, actions in GDL rules are limited to setting values of variables and data
times, so it is less powerful than AS. While there are certain similarities between
GDL and CM rules they have a different purpose. GDL rules specify both activation
conditions and actions and are meant to be executed by a single agent. CM rules instead
only specify the activation conditions to trigger a specific agent and the corresponding
actions are chosen by the triggered agent. In other words, CM rules separate coordination
knowledge from domain knowledge offsetting the responsibility to execute triggered
actions onto specific agents, thus becoming orchestration rules for the distributed
environment. Since CAPABLE uses FHIR, the PROforma formalism for representing CIGs
seemed to be a better choice than GDL.
The CM is seen as an enabling technology introducing Dependency Injection and making available the Inversion of Control principle in a standard and declarative way as opposed to approaches based on proprietary
solutions.[43 ]
[44 ] Leveraging the semantic layer provided by FHIR, the CM supports a consistent expressive
language that the various agents use to define their events of interest. Those definitions
are dynamically sent by the agents to the CM that interprets them and starts monitoring
the DP. Thus, the CM is eventually able to drive agent activation without any prior
knowledge about their functionality. Finally, upon generating events that result in
the activation of a target agent, the CM also hands over the evidence causing those
activations, i.e., involved FHIR resources, for further inspection.
We believe that the proposed solution may be useful in other scenarios as well, as
it supports integration of legacy clinical systems through agent-like wrappers relying
on the services provided by DP and CM. One of the fields that may benefit from our
proposal is telemedicine. Despite positive outcomes of pilot studies, telemedical
solutions often fail to enter routine practice. Among the reasons, besides the possibly
disrupting impact on the organizational workflow,[45 ] there is an inherent difficulty in bringing telemedicine into practice due to the
multitude of different proprietary and possibly incompatible standards that are always
used in relevant research projects.[46 ] Current technology in clinical applications still focuses on data silos offering
very limited interoperability among each other.[47 ]
[48 ] Solving this issue could result instead in a wealth of large-scale services built
on top of already existing modules for which there is already a growing interest.[49 ]
The proposed architecture may be proficiently exploited for the distributed management
of comorbidities that are increasingly found as the populations grow older.[50 ]
[51 ] In particular, multi-morbidity conditions often generate contradictory requirements
that are difficult to address.[52 ] C3-cloud is another interesting project addressing comorbidity, even though in that
case interaction mitigation is done manually by physicians that agree on a particular
treatment.[53 ] Within CAPABLE, GoCom mitigates interactions automatically considering a large number
of possible interactions without modeling them ahead of time.
Despite its potential, our work has limitations since the architecture has been implemented
on a very small scale. Assembling telemedicine services from existing components and
rendering them as autonomous independent agents requires additional middleware, particularly
for supporting shared care. Brokers are needed to help the CM in accessing patient
data shared across several institutions using standardized APIs as well as for allowing
specialized components to access it.[54 ] As a design choice, the CM did not leverage FHIR Subscriptions which trigger events
checking resources individually. Doing so would have enhanced the CM's integration
with FHIR. However, this seemed too much of a stretch in the design since CM triggers
not only events upon the acquisition of new resources, but also upon missing data
or by periodically re-evaluating rules. Nevertheless, the need to match the FHIR standard
imposes a limitation on the syntax for specifying the conditions in rules. Within
the CM we enhanced that syntax using JavaScript code, which is a procedural language,
while a declarative approach would probably be a better choice. Finally, data availability
is a challenge for CIG-based systems whose authors often shift the responsibility
of checking their presence onto users.[50 ] In CAPABLE this is mitigated by the fact that the dynamics of patients' evolution
is much slower than the system response. Moreover, CM rules are always used in “isolation”
and do not constitute reasoning chains. When a rule is activated, it generates an
event triggering an agent. Thus, we offset the responsibility from the CM onto the
specific agent involved, while handling it at the infrastructural level could have
resulted in a more general solution.
As a final remark, telemedicine systems may harm the patient. Thus, they must comply
with the regulations of the country where they are used. In the EU, this is accomplished
through the Medical Device Regulation 201/745 (MDR) of the EU Parliament.[55 ] According to the MDR (Annex VIII, Chapter III, Point 6, Rule 11), CAPABLE falls
into risk class IIa. This had an impact on the activities of the project, especially
regarding the clinical study taking place during its final year. Our goal is not to
commercialize the system, which would require obtaining a CE marking, but just to
assess its effectiveness in the pilot study. According to MDR Art. 62, a clinical
investigation demonstrating the benefits of a device (without the CE marking) requires,
besides other activities, preparation of a risk assessment according to ISO 14971,
receiving a nonnegative opinion by the ethics committee of the institution responsible
for the investigation, and authorization by the government of the member states involved.
Thus, after receiving the approval of the local ethics committees of ICSM and NKI,
we submitted notifications to the notified bodies of the government of the two countries
involved.
Clinical Relevance Statement
Clinical Relevance Statement
In CAPABLE we inherently needed to share structured information among several agents
to implement the Case Manager as an orchestrator. Thus, sharing data is essential
and was facilitated adopting FHIR, enhancing it with suitable terminology mappings.
We accomplished this task using well-established standards such as SNOMED CT, LOINC,
and OMOP-CDM. Besides simplifying data exchange, we believe that this approach enforces
a higher quality of the collected data and helps in producing more reliable coaching
and decision recommendations. Finally, using OMOP-CDM allows clinical researchers
to share and reuse large libraries of statistical tools already developed by the scientific
community.
Multiple Choice Questions
Multiple Choice Questions
Which architecture was chosen by the authors for the implementation of an advanced
clinical decision support system?
Standalone monolithic architecture
Decision support embedded into the electronic health record
Multi-agent system architecture
Service-oriented architecture
Correct Answer: The correct answer is option c. A multi-agent system allowed partitioning the competencies
among the various agents. For each agent the most appropriate representation formalisms
and development tools were adopted, reusing many software libraries already developed
by the researchers participating in the project. Coordinating the agents was also
simpler through the implementation of the Case Manager.
If a complex system needs to be assembled reusing n existing components, what approach would minimize the development efforts required
to enable information exchange among those?
Devising a specific format for data representation and rewriting the internals of
every component so that they all eventually conform to that single format.
Coupling each of the components with as many services as needed to independently perform
the conversions to/from any other one, possibly resulting in up to (n* (n − 1))/2 separate services.
Choosing components that only use the same information model (concept and terminologies).
Defining a common information model for the whole system, then mapping the requirements
of each component to that common model using mapping services, resulting in up to
n services.
Correct Answer: The correct answer is option d. Each component of our system uses its own information
model that possibly differs from that adopted by others. This allows greater flexibility
in selecting the most appropriate software tools for processing information. Mapping
services may be adopted in case a conversion among different standards is required.
Which of the following approaches to coordination has been used by the authors as
being the most flexible (in terms of decoupling the agents) and effective (in terms
of the impact on a shared data repository)?
Hard coding the coordination strategies within each agent, so that they are also implicitly
aware of the strategies of all the remaining ones
Designing a separate component to which agents dynamically declare their activation
conditions and by which they are activated whenever those conditions are met
Designing a separate component that hard codes all the coordination strategies and
drives the activation of the agents as needed
Adopting a shared data repository that is queried by the agents searching themselves
for their activation conditions
Correct Answer: The correct answer is option b. Even though the development of a fully customizable
component is not trivial, it is the approach that maximizes decoupling of the agents.
In our system, the Case Manager follows the Inversion of Control paradigm and can be configured directly by the agents that it is supposed to notify.
