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.
