MobiGuide: Guiding Clinicians and Chronic Patients Anytime, Anywhere

The trend for an aging population, which is typical for Europe and for other high-income regions, brings with it a sharp increase in the number of chronic patients and a shortage of clinicians and hospital beds. Evidence-based clinical decision-support systems are one of the promising solutions for this problem.¹⁵

In the 1990s, different research groups started to develop computer-interpretable clinical guidelines (CIGs)⁷ as a form of evidence-based decision-support systems (DSS). Narrative evidence-based clinical guidelines, focused on a single disease, and containing recommendations for the disease diagnosis and management, were manually represented in CIG formalisms, such as Asbru,¹¹ GLIF,¹ or PROforma.³ The CIGs formed a network of clinical decisions and actions and served as a knowledge base. The DSS would enact the CIG over a patient’s data, entered manually or taken directly from the electronic health record (EHR). The patient-specific recommendations would be delivered to the clinician during patient encounters.

The European MobiGuide project⁸ asked the following question: What do chronic patients want? Patients want to live normally. They want to focus on their lives and not on their disease. They do not want to go into the hospitals for long monitoring sessions but remain in their natural environments and lead their normal lives safely. Hence, we were motivated to develop a generic architecture that could support chronic patients and their clinicians.

The MobiGuide architecture is shown in Figure 1. Patients received a body-area network of mobile sensors (for example, a glucometer, a blood pressure sensor, an ECG belt) communicating via Bluetooth with a smartphone. The sensors’ biosignals were semantically integrated with hospital EHR data, patient reported outcomes and symptoms, and patient-specific DSS recommendations into a secure Patient Health Record (PHR) that followed the HL7 Virtual Medical Record standard. The DSS in MobiGuide was distributed between a full-fledged backend DSS and a local mobile DSS (mDSS). The Backend DSS had access to the full PHR and to the full CIG knowledge-base, represented in the Asbru¹¹ CIG language, and enacted through the PICARD engine.¹³ Based on the patient’s context, the Backend DSS projects, when necessary, components of the CIG knowledge to the mDSS.

Figure 1. Architecture of the MobiGuide DSS.

The MobiGuide architecture includes multiple novelties. First, the distributed decision-support architecture projects patient-specific components of the evidence-based CIGs into the local mDSS, which can thus operate independently for weeks until it detects predefined [temporal] patterns in the data (embedded within the projected CIG component). Such patterns signal that the patient’s context had significantly changed (for example, a temporal pattern indicating lack of blood-glucose-level control) and allow the mDSS to call back the Backend DSS to take control and project a new CIG component.¹⁴ This architecture is quite different from a completely central, a completely distributed, or a traditional client-server architecture.

Second, semantic data integration⁶ is based on HL7 standards, extended to allow interoperability not only of EHR, sensor, or patient-reported data, but also of DSS recommendations that were delivered to patients and clinicians.

While traditional DSSs² deliver advice to clinicians, the third novelty is a focus on patients as end-users. To support patient centrality, the formalized CIGs were also customized by adding CIG-Customized-Contexts (CCCs).⁸ Each CCC (for example, “normal schedule,” “good-glycemic-control”) defines how the CIG changes for any patient that enters this context. Contexts included also social circumstances (such as “living alone”) and preferences regarding options in the guideline whose selection depends on patients’ preferences (for example, a cost-utility trade-off).¹⁰

The fourth novelty was the continuous intelligent data analysis that detected the multivariate temporal patterns in the data, using context-sensitive clinical knowledge and fully exploiting the context-sensitive temporal properties of each clinical concept (for example, their persistence over time within each context), unlike the use of standard laboratory-test cut-off values.

The final innovation was the generic architecture, unlike domain-specific architectures. This architecture was validated with CIGs for different diseases and with different sensors: atrial fibrillation patients (with ECG and blood pressure sensors) and gestational diabetes patients (with glucometers and blood pressure sensors).

Back to Top

Scenarios of Using the System

To envision the MobiGuide system from the patient’s perspective, we describe two typical scenarios, reflecting the two patient populations who used the system for up to nine months.

Picture Maria, a 65-year-old atrial fibrillation patient from Italy. Maria told her cardiologist that sometimes, when she is walking her dog she feels anxious because she does not know if she is having an atrial fibrillation event and is not sure if she should take her emergency pill, which she carries with her. Her doctor enrolls her to the MobiGuide system. She receives a smartphone with the MobiGuide app and a mobile ECGs sensor with a belt (as shown in Figure 2) she wears beneath her shirt. When Maria reports her symptoms, she is instructed by the mDSS system to activate the ECG sensor.

Figure 2. The MobiGuide app; ECG sensor with chest belt, and an atrial fibrillation event detected by the ECG sensor.

In the MobiGuide project, ECG data of patients such as Maria was collected by the sensor and abstracted into one-minute sessions. To increase specificity and prevent false alarms, the DSS’ atrial fibrillation detection algorithm monitored for patterns of two or more sessions with atrial fibrillation events within a 10-minute period. Detected sessions were stored in the PHR. When such sessions were detected for eligible patients (depending on their medication therapy and clinical and social parameters), the DSS also checked that no recommendation for the emergency pill has been delivered in the past four hours. Under these terms, the system recommended to the patient to rest, take the emergency pill, and then measure the ECG for another 30-minute session. Clinicians could see the data saved into the PHR, and could receive recommendations from the system, supporting a potential cardioversion procedure (such as an ablation procedure).

The second scenario concerns Montse, a young pregnant woman from Spain with gestational diabetes. Montse sets the system in the appropriate context, which currently happens to be her “holiday” context. In this context, she wakes up a bit later, hence her recommendations for measuring blood glucose before breakfast and after her meals are delivered accordingly. At first, she needs to measure her blood glucose four times a day, every day, as her [composite] context is “holiday” and “bad blood-glucose control.” But since her reporting is highly compliant, and since her blood glucose is under control, the system changes the [composite] context to “holiday” and “good blood-glucose control” and advises her to measure her blood-glucose four times a day, only twice a week. Hence, the system monitors Montse’s compliance and metabolic control, and accordingly applies evidence-based plans regarding diet, exercise, and measurement schedule, and sends her personalized, context-sensitive reminders.

However, after several weeks, Montse’s blood glucose is too high. The MobiGuide system (following a Call Back to the central server triggered by the blood-glucose values’ pattern, and a projection of a new therapy component) goes back to recommending daily measurements. In parallel, the system also advises Montse’s managing physician to start insulin. Thus, it asks Montse to see her doctor before the next scheduled visit. The doctor, who had received the MobiGuide system’s recommendation, agrees with it, and starts insulin earlier than she would have done if the system had not alerted her. The MobiGuide system also sends Montse feedback and education, and when needed, advises regarding the addition of carbohydrates if the pre-prandial blood sugar is repeatedly too low.

Back to Top

System Evaluation

MobiGuide was evaluated in a long clinical pilot with 10 atrial fibrillation patients in Italy and 20 gestational diabetes patients in Spain, who were using the system for three to nine months.⁹

The main benefit to patients was that they stayed at home yet felt better cared for and safer. Their compliance to measurements was high and for the gestational diabetes patients, in which data from a historical cohort were available, a higher compliance of the MobiGuide cohort was observed relative to the historical cohort, reaching 75% for atrial fibrillation patients and 99% for gestational diabetes patients. Relative to the historical cohort, blood pressure was significantly lower in the MobiGuide cohort and there was a trend for fewer C-sections in the MobiGuide cohort, due to the better glycemic control and the lower birth weight of the babies. Moreover, most MobiGuide patients reported an improvement in their quality of life in the EuroQoL questionnaire.

---

This architecture is quite different from a completely central, a completely distributed, or a traditional client-server architecture.

---

Clinicians used the system even outside patient visits, demonstrating its value to them. Atrial fibrillation clinicians changed a long-time diagnosis for two patients, after realizing from the ECG data stored in the PHR that these patients had in fact other arrhythmias that had been wrongly diagnosed. Gestational diabetes clinicians started insulin earlier for two patients, as recommended by the system, thus enhancing the patients and the embryos’ safety. From the clinicians’ questionnaire we learned they found the system useful to identify priorities, increase productivity, and they valued the fact that the patient data measured between visits was available to them, which made the patient visits more effective due to availability of data and increased patients’ safety.

Back to Top

Discussion

Our experience with the MobiGuide system demonstrated that, given a good mobile network infrastructure, evidence-based guidelines that can be fully disambiguated and formalized, and a motivated clinical and technological supporting team, it is possible to operationalize successfully a large-scale complicated system such as MobiGuide, which features distributed decision support, based on computer-interpretable clinical guidelines, personalized to patient preferences and contexts, and generalizable to different clinical domains. Its successful impact has been evaluated with patients of two types, in two countries, who have used the system for up to nine months.

Managing patients at home implies multiple economic benefits. First, better compliance of patients results in better clinical outcomes. Second, the system can follow up patients remotely, and can thus save unnecessary visits when they are doing well and do not require clinic visits or hospitalization for close monitoring. Moreover, patients who require a faster intervention are detected quickly, enhancing the level of care. (for example, in some cases, the DSS system referred the gestational diabetes patient to the clinic for earlier insulin intervention when conservative measures were deemed to be insufficient).

---

In the MobiGuide project, ECG data of patients was collected by the sensor and abstracted into one-minute sessions.

---

We believe the MobiGuide architecture is highly scalable; it is generic with respect to medical knowledge engineering and with respect to context-sensitive application, and thus depends in no way on the particular CIG to be formalized, as clearly proven in the current evaluation (and in other projects by the team members, in other clinical domains.^12,13 Its data-security infrastructure has been developed with a large population in mind.

Using innovative systems such as MobiGuide for routine management at home of chronic patients raises multiple intriguing legal issues. First, who is responsible if something goes wrong? Surprisingly, at least at the time the MobiGuide project was developed and tested, the legal situation in the E.U. was that the hardware (smartphone) manufacturer might well be considered as the party at fault if the phone is used to transmit a potentially harmful message. Such a situation might hamper the development and use of systems that can improve patient care and reduce its costs. There are initiatives to move the burden to the software developer, as seems more reasonable. Furthermore, on a more semantic (rather than syntactic) level, specific proposals were made in the past to assess the blame according to the chain of knowledge management and application, from the medical expert, through the knowledge engineer, software developers, sensor developers, and clinicians, and put the blame squarely where it really belongs (for example, a faulty representation of the clinical guideline; or an incomplete application of a correct representation).

There are also other legal obstacles preventing unhampered use of systems such as MobiGuide throughout Europe (or the world), such as the problem of transporting patient data across borders: in some countries, current national laws often forbid that option, making universal accessibility of personalized care to patients traveling across national borders very tricky.

In addition to legal obstacles, healthcare institutions could raise organizational barriers. As a matter of fact, although systems such as MobiGuide potentially lead to multiple health and economic benefits, their routine implementation does require significant organizational and workflow changes. For example, care providers need (re) education, such as how to best exploit evidence-based decision-support systems and not be over-owed by them; also patients need (re) education, since patients need to get used to the implications of empowerment, on one hand, but accountability, on the other hand; eventually, human resources need to be reallocated to cope with remote patient monitoring.

Research shows that at least one-third of the patients want empowerment and an informed process of care,² and perhaps the use of such a system (and especially its personalization options) should start with that patient segment.

To better address patients’ needs and maximize the probability of success also beyond the pilot studies, systems like MobiGuide should probably be extended with additional functionalities. One of them is addressing the overall patient’s well-being, considering mental well-being, nutrition, exercise, and support for adverse drug effects and multimorbidity. In this sense, the E.U. project Cancer Patients Better Life Experience (CAPABLE; see https://capable-project.eu), although based on different technologies, can be seen as an extension of MobiGuide. It will address the well-being of patients by offering also non-medication evidence-based therapies from the mindfulness, positive psychology, and physical exercise domains, grounded in behavior change theories, and fitting interventions to the patient’s clinical goals and ability.^4,5

Back to Top

Conclusion

MobiGuide is an extraordinary example of an artificial intelligence system that monitors and manages patients remotely, as a solution to the efficient outpatient monitoring in Europe and could provide a solution to the expected shortage of doctors in Europe and around the world. It also inspired further projects that hopefully will overcome some of the highlighted limitations.

Acknowledgment. This study was partially funded by the European Commission 7^th Framework Program, grant #287811.