There has been a rapid increase in novel anticancer therapies, with >150 new approvals since 2000 alone [1,2]. Many of these have been associated with dramatic improvements in survival [3,4]. However, concurrently, cardiotoxicity is a potentially severe adverse effect of novel cancer therapies which limits the use of several effective cancer therapies. Cardiovascular disease has become increasingly common among patients with cancer receiving novel cancer therapies, with a reported incidence of up to 38% [5,6]. Patients with cancer who develop concurrent cardiovascular disease, including cardiotoxic arrhythmias, heart failure, hypertension, and myocarditis, have worse long-term quality of life (QOL) and poorer outcomes [1,7]. Yet, most of these events are missed until severe morbidity or death occurs [6,8]. Thus, early recognition of cardiotoxic events in high-risk patients with cancer is paramount [9-16].

Mobile health (mHealth) has been investigated to screen for cancer-related symptomatology (eg, pain and chemotherapy side effects) and to improve QOL and outcomes in patients with cancer. In particular, mHealth apps and symptom-reporting systems are powerful tools to improve QOL, symptom detection, and survival [17-24]. Prior work shows that patients with cancer are willing to use mHealth apps and tend to be compliant with electronic symptom reporting [25]. Yet, to date, there have been no studies examining mHealth for symptom-tracking for cancer-related cardiotoxicity [26]. Given the severe consequences of cardiotoxicity, there may be a role for mHealth in screening for this complication and improving QOL among patients at high risk for cardiotoxicity.

As a first step to closing this gap, we sought to determine considerations for the design and implementation of an mHealth symptom-tracking tool for early recognition of cardiotoxicity in patients with cancer. We explored this issue using the socio-technical systems (STS) framework to model complex interactions between goals, people, processes, infrastructure, culture, and technology.

Health care systems operate within complex adaptive environments that are constantly evolving, particularly in the high-pressure context of care delivery [27]. This dynamic setting makes the implementation of Health Information Technology interventions, such as mHealth apps, a formidable challenge. While several conceptual models exist that examine the implementation of technology innovations in health care, they are usually limited in scope [27]. Importantly, many of these models fail to address the intricate relationships that exist between different dimensions of implementing technology innovations in a health care setting such as those related to the deployment of an mHealth app.

The STS framework offers a systems-oriented perspective on organizations (Figure 1). Within this framework, readiness and implementation are considered within the context of various interconnected subsystems. Overcoming barriers to the implementation of digital tools in health care, including mHealth apps, involves addressing challenges like organizational readiness and the alignment between the tool and existing workflows [28]. Sociotechnical theory asserts that the successful implementation of mHealth interventions is contingent on both technical factors, such as ease of use, and social and organizational factors, including leadership support.

Sociotechnical theory posits that the successful implementation of mHealth is a function of both technical (eg, ease of use) and social and organizational factors (eg, leadership support) [29-31]. The associated STS framework [32] is composed of six domains [33]: (1) goals: This encompasses performance metrics and objectives that guide the implementation efforts. (2) People: This refers to individuals within the system, including their attitudes, behaviors, skills, and competencies. (3) Infrastructure: Physical and financial assets necessary for the implementation, ensuring adequate resources. (4) Technology: The technological components, tools, and equipment required for the intervention. (5) Culture: Shared norms, beliefs, and values that influence the organizational environment. (6) Processes: Work practices and organizational structure that influence how the intervention is integrated.

We selected this framework to explore the design and possibility of implementation of the app into a health system. Further, our approach emphasizes a strong focus on user-centeredness. Specifically, we have applied the STS framework in relation to patients, who are the primary end users. Their perspectives offer valuable insights into critical factors such as design preferences, expected features, and the willingness to adopt the app. Additionally, we have also engaged health care providers, who play a significant role not only in receiving the app’s data but also in the early identification of cardiotoxicity. By considering viewpoints from both patients and providers, our study aims to provide a deeper understanding of how mHealth implementations can be aligned with the specific needs of these essential stakeholders.

Our research addresses a significant gap in the current literature. While numerous studies have separately investigated the viewpoints of patients or providers in the context of mHealth, the synergistic interaction between these perspectives has often been overlooked [34-36].

Our study seeks to bridge this gap by acknowledging the essential interdependence between the perspectives of patients and providers within the intricate domain of mHealth. By using this approach, we intend to enhance the comprehension of effectively integrating the sociotechnical complexities of mHealth with the distinct requirements of these crucial stakeholders.

This study was approved by The Ohio State Cancer Institutional Review Board (#2021C0018). All participants consented verbally before any study procedures. Patients were also provided the consent document via email before beginning any study procedures. All study documents were deidentified and files were saved to a secure server behind institutional firewalls. Study documents were saved with the date and time of the interview rather than participants’ names, and names were replaced with codes (eg, Participant 1 and cardiologist 1).

Table 2 describes the current state of cardiotoxicity symptom tracking and reporting at the institution, mapped onto the STS framework. There is no systematic process for patients to report potential cardiotoxicity symptoms. Rather, it is up to patients to recognize and choose to contact their provider via phone or patient portal. Alternatively, symptoms may go unreported until a patient has a clinic visit, causing delays in cardiotoxicity recognition. Providers also reported that patients may not recall symptoms during their appointment, and thus it may go unreported entirely. There is no standardized process for incorporating symptom information into the EHR, and no process for providers or staff to regularly manage symptom reports. Cardiologist 1 expounded upon this by describing a potential barrier to such a process, wherein providers and staff would need billable time for this:

Table 3 describes the goal state of a more robust, timely cardiotoxicity symptom reporting and recognition process leveraging mHealth. Providers posited it would give patients an alternative method to report symptoms, and patients would be motivated to use the app if they understood that it was a faster way to communicate with their provider. Providers suggested that the app could also prompt discussion during appointments:

Providers cautioned that to ensure adoption, the app should be straightforward and simple, and not ask too much of patients, for example,

Providers suggested that patients should be able to customize the app, such as whether they wanted it to send them reminders to report symptoms.

Providers mentioned that oncology, cardiology, and primary care should all be involved when a patient shows potential signs of cardiotoxicity, to allow them to codevelop a plan. This is explained here:

In terms of EHR integration, the institution requires that data from external apps be reviewed by a clinician before adding it to the patient record, challenging the idea of a full EHR-app integration. Providers described how a similar goal could be achieved while working within this constraint, such as having concerning patient symptom data trigger an alert in the patient portal or provider in-basket.

Providers indicated that signs and symptoms indicative of cardiotoxicity, that should be added to the symptom-tracking app, included: chest pain or tightness, shortness of breath, heart racing or palpitations, syncope, lightheadedness, edema, and excessive fatigue.

There was no current standardized process for patients to report symptoms. Most patients indicated waiting until appointments to discuss symptoms, unless they felt that it was urgent, in which case they would call or message their provider’s office. For example, 1 patient stated (Table S1 in Multimedia Appendix 1):

As shown in Table 4, all patients indicated an interest in tracking symptoms via a mobile app. Participants foresaw using these data in 2 ways: first, by allowing them to see trends in their symptoms and symptom severity, and second, to communicate symptoms to their provider. Toward the former, patients desired a bar chart display to see their (cardiotoxicity) symptoms over weekly, monthly, and yearly time periods. Toward the latter, participants expressed interest in sending their symptoms and related questions via the app, to get their providers’ feedback and interpretations. Some also hoped that the app could alert them and their provider if a concern needed to be addressed immediately.

Patients indicated that an app would need to be easy to use. For example, when asked about prior apps that were disliked, 1 patient indicated the following:

On the flip side, patients indicated liking apps that were simple. For example, when asked about an app that the patient liked, they indicated:

Participants indicated an interest in additional app features, including educational resources and the ability to build a community of other patients with cancer and survivors (eg, discussion board), as exemplified by 1 patient:

Figures 3 and 4 show the app design resulting from the co-design process. Figure 3 displays the front page of the app, as well as the symptom tracking feature wherein participants can indicate and rate their symptoms. These ratings would ideally serve 2 purposes: first, to provide an early alert to providers of concerning symptoms indicative of potential cardiotoxicity via regular transmission of these data to clinical staff and second, to be maintained within the app to inform a chart to allow for visualizing patterns over time. Toward the latter, Figure 4 shows the graph display preferred by patients (a bar chart style) which allows patients to view their symptoms and severity of symptoms over time. Patients indicated being interested in viewing this for their own knowledge, and both patients and providers indicated interest in using these graphs during clinic visits to inform clinical care.

This study evaluated providers’ and patients’ perspectives on the design and implementation of a novel cardio-oncology mHealth app (for symptom reporting and early cardiotoxicity recognition). Providers and patients expressed positive attitudes and described barriers to early cardiotoxicity reporting. Findings suggest that the app should be designed for patients with cancer at higher risk for cardiotoxicity, should motivate patients to log symptoms, and should allow providers to collaboratively comanage symptoms efficiently.

A key factor of success identified is to motivate the users to engage in symptom-logging behaviors for an extended period [42]. Both patients and providers suggested that designing the app to be simple, and to allow patients to tailor the app to their preferences, would facilitate app engagement. Further, providers suggested that explaining the benefits of the app (eg, more efficient communication) would help motivate patients to adhere to symptom logging.

Our findings are in agreement with prior work [34,35] showing that digital solutions have the potential to address unmet needs, such as facilitating symptom monitoring, detecting adverse effects, improving cancer self-management, and empowering patients. However, similar to prior work [42], providers suggested that a lack of billable time assigned to monitoring and managing app symptom reports would be a barrier.

Similar to prior work [43], providers expressed that it would be ideal to incorporate app data into the EHR to enhance patient-centered care. However, cultural and infrastructure-related barriers complicate this. Alternative modes (eg, in-basket messages and linking to the patient portal) could be considered. Providers also indicated that the app could facilitate face-to-face doctor-patient communication (eg, reviewing symptom logs during appointments). Data generated and recorded from mHealth apps may be considered billable or admissible to the patient health care record, given the potentially significant influence on patient outcomes. This would leverage the current insurance bundled health care delivery mode, with the patient’s desire for quick and effective ways to communicate with providers via verifiable and self-reported information. Practically, patients may be allowed to opt-in to having their mHealth data recorded within the EHR (eg, similar to Epic’s “MyChart” system).

Providers have previously expressed concerns that during critical situations, patients may report severe symptoms to an app, expecting that it is being actively monitored [35]. This concern seems well-founded based on our data. It is unlikely that this would be the case without additional personnel for this role. Thus, we suggest the app include notifications and that urgent or severe symptom should be reported another way (eg, by calling the provider’s office, going to the emergency room, or calling 911).

The STS framework played a significant role in understanding the implementation of the cardio-oncology mHealth app. The six domains of the STS framework were instrumental in guiding our study: (1) goals: The study focused on understanding performance metrics and objectives, aiming to design an app that effectively addresses the needs of both providers and patients for early cardiotoxicity recognition. (2) People: Providers and patients—the pivotal end users—were the lens through which the STS framework was operationalized in this study. Their attitudes, behaviors, and competencies shaped the app’s design. Providers expressed the need for patient motivation to engage in symptom-logging behavior over an extended period, emphasizing simplicity and personalization. Patient adherence was seen to be fostered by explaining the benefits of efficient communication enabled by the app. (3) Infrastructure: The study recognized the significance of sufficient physical and financial resources for implementing the app effectively. Challenges in allocating billable time for monitoring app reports were acknowledged as a potential barrier, indicating a need for resource allocation. (4) Technology: The technological components required for the mHealth app were central to the study’s evaluation. It was emphasized that the app should not replace urgent traditional communication methods for severe symptoms, suggesting a need for clear technological boundaries. (5) Culture: Shared norms and values influence the organizational environment. Integrating app data into the EHR was identified as a cultural challenge at this institution. As part of a broader organizational culture around information security [44], the institution had organizational policies that disallowed external apps to write data to the EHR. Alternative methods, like in-basket messages or patient portal links, were proposed. (6) Processes: Work practices and organizational structure were taken into account. The study highlighted the potential role of the app in facilitating doctor-patient communication, allowing for symptom review during appointments and potentially integrating app-generated data into patient records.

Consistent with prior research, the study found that mHealth apps have the potential to address unmet health care needs by enhancing symptom monitoring, supporting patient self-management, and improving communication. However, the study also underscored challenges related to resource allocation and integration with existing health care practices. The findings suggest that for successful implementation, the app should be carefully tailored to address these technical, organizational, and behavioral considerations.

Concerns raised by providers about patients expecting active monitoring of severe symptoms through the app were acknowledged. To address this, we recommended incorporating notifications within the app to guide patients on reporting urgent or severe symptoms through appropriate channels, such as calling the provider’s office, seeking emergency care, or dialing 911. The STS framework facilitated a comprehensive understanding of the app’s potential, its challenges, and strategies to ensure successful adoption and use within the health care ecosystem.

While this study leveraged a multidisciplinary group of cardio-oncology specialists, the providers were from 1 hospital, and our sample size was small. However, our small sample was largely due to a small population, which was widely represented: participants included 2 out of 3 (67%) of the institution’s cardio-oncologists, and over half of the physicians affiliated with the clinical cardio-oncology program. Implementation in other types of institutions should also be explored, as sociotechnical factors likely vary in relation to organizational size and resources. This evaluation focused on cardiotoxicity given the serious consequences to patients. In addition, most transcripts were coded by only 1 individual, although all coding was reviewed by the first author. Further, patient recruitment was challenging, and thus we were limited in obtaining information from patients who have experience with more novel cancer therapies with higher rates of cardiotoxic effects. In future work, we will be better resourced to selectively recruit this specialized group. Regardless, 67% (n=4) of our patients sampled did indicate having 1 or more indicators of potential cardiotoxicity related to cancer therapy, with 1 reporting having developed a cardiac condition. We also acknowledge that the decision to recruit patients from outside the institution may have limited what we were able to learn about how to implement the app in this particular organization.

This study focused solely on symptom trackers or monitors. However, we acknowledge that some patients see cardiotoxic injury well before the onset of symptoms. We also note that emerging biomarkers, including blood or imaging-based biomarkers for example, may further advance the ability to detect and track cancer treatment-induced cardiotoxicity well before the onset of clinical symptoms and the manifestation of more advanced disease. In future work, we plan to consider the concurrent leveraging of other clinical tests with this app. With many at-home, single-lead electrocardiogram (ECG) machines and wearable smartwatches with single-lead ECG functionality, it may be possible to incorporate such data into an app. These data could be logged with other clinical data in the app alongside home blood pressure readings and heart rate monitoring data from wearable technology to facilitate rapid triage of new, potentially worrisome symptoms of cardiotoxicity. We will consider further integration with emerging smartwatch application data.

mHealth can play a role in early recognition of clinical complications of cancer treatment, such as cardiotoxicity. However, incorporation of mobile apps into clinical care requires working through persons, systems, and technology-related barriers to ensure success.

Providers and patients perceived that a patient-facing symptom-reporting app would be beneficial to increase early recognition of cancer treatment-related cardiotoxicity, as current processes are perceived to lead to delays in recognition and treatment. However, sociotechnical barriers include the lack of a process for multidisciplinary providers to have allocated time to review app data and collaborate on care plans, infrastructure-related challenges limiting how mHealth data can be incorporated into the EHR, and designing an app that is simple and tailored to patients to motivate use.