Diabetes is a uniquely quantifiable disease, and as technology and data have proliferated over the past two decades, so have the tools to manage diabetes. Patients and providers have at their disposal devices, applications, and data platforms that generate immense amounts of data, provide critical insights into a patient’s disease, and allow for personalization of treatment plans. However, the proliferation of options also comes with new burdens for providers: selecting the right tool, getting buy-in from leadership, defining the business case, integration with existing systems, implementation, and maintenance of the new technology. The complexity of these steps can be overwhelming and sometimes lead to inaction, depriving patients and providers of the advantages of technology-assisted diabetes care.

Digital health has enormous potential to positively transform the landscape of diabetes management. Ever expanding, the field encompasses a broad set of concepts and technologies, including telehealth, mobile applications, wearables, artificial intelligence, and precision medicine (1–3). The ongoing push to reach this potential has led to a staggering proliferation of digital health solutions. In 2021, more than 350,000 digital health applications are currently available to consumers, with 90,000 of these introduced just since 2020 (4). Funding for digital health companies reached $57.2 billion in 2021, an increase of 79% from 2020 (5). This rapid growth has been paired with a relative lack of standardized frameworks aiding with solution discovery, clinical integration and evaluation. This leaves stakeholders with challenges in planning and execution of an effective implementation of a digital health solution. High profile examples of problematic implementations have demonstrated that the implementation of an intervention is as important as the intervention itself in achieving the desired end goal (6–9).

Conceptually, the adoption of digital health solutions can be thought of as occurring in five interconnected phases ( Figure 1 ):

There are a number of existing frameworks to help guide much of this process, but relatively little attention has been focused on integration (phase 3). In this article, we provide a brief overview of common approaches to various phases in this process, and describe the integration framework we have developed at our institution.

Within the context of healthcare delivery, a needs assessment is the process by which individuals or teams gather and analyze information about the needs of a specific patient population in order to understand the gaps in their care, the causes of those gaps, and how those gaps might be closed (10). Several research and operational needs assessment frameworks have been developed and published by organizations like the CDC (11), WHO (12), NHS (13), Johns Hopkins University (14, 15), the University of Kansas (16, 17), the American Medical Association (18), and the Agency for Healthcare Research and Quality (19).

Health equity is a critical component of any Diabetes-related needs assessment. Diabetes prevalence, morbidity and mortality disproportionately impacts low-income communities and communities of color (20). Social determinants of health (SDoH) are principal drivers of these disparities, and the ability to access technology and the internet is increasingly being recognized as a contributing factor to healthcare disparities; a concept referred to as the digital divide (21). Thus, every healthcare organization considering digital health solutions should be keenly aware of the impact they have on vulnerable populations and their ability to meaningfully access and receive technology-enabled care.

Identifying solutions is often an iterative process, and at healthcare institutions, it is sometimes conducted through a formal Request for Proposals (RFP), typically managed by Information Technology (IT) Services. The growing number of emerging solutions leaves organizations the increasingly difficult task of discerning effective, high quality and high value solutions from a crowded landscape. There is a growing body of standards-based frameworks and resources to assist stakeholders in identifying optimal digital health interventions, including:

A number of implementation theories and frameworks already exist that can be used to guide diabetes technology implementations, such as Normalization Process Theory (NPT) (27, 28), Consolidated Framework for Implementation Research (CFIR) (29–31), Reach Effectiveness Adoption Implementation Maintenance (RE-AIM) Framework (32), and Proctor’s Framework for Implementation Research (33). Nelson et al. published a narrative review in 2020 that provides an overview of various implementation frameworks used in technology-delivered diabetes self-care interventions (34). Many of these implementation frameworks are comprehensive and include, at least in part, aspects of needs assessment, integration, implementation, and evaluation. However, they are principally focused on the clinical implementation, and less so on the technical work required to onboard and integrate a new technology into a clinical setting.

Evaluation of digital health solutions presents a unique challenge compared to other interventions. The speed of software development and rapid iteration cycles are inherently mismatched with the length and time-cycle of randomized controlled trials or most means of traditional evidence generation (35, 36). This incongruence has produced a digital health evidence gap, resulting in low levels of rigorously evaluated applications and a lack of objective information for stakeholders to accurately assess an interventions usability, functionality, safety, effectiveness, accessibility and value. This gap is being addressed with an increasing body of guidance and proposed frameworks addressing the evaluation of digital health solutions, from governmental agencies, industry-based consortiums and academic institutions (35):

Integration is the process of aligning a new technology with existing technical systems and operational processes. This process has multiple stakeholders from across an organization, ranging from legal and compliance, to IT services, to clinic staff. At large institutions, there may be Project Management Offices (PMO) who are responsible for shepherding new integrations through multiple governance and approval committees, but even then, the process can be complex. During this phase, the contractual, compliance, financial, and technical realities of a project come into sharp focus. Missing a step or doing them out of order can lead to significant delays and potentially wasted resources. To address these issues, we have developed a practical, simplified framework for integrating diabetes data and technology solutions that can guide clinicians and clinical leaders on the critical steps in adopting and implementing a new technology, based on our experience (36, 42–45). This model does not replace but rather complements the previously mentioned implementation frameworks, which pick up where our model leaves off.

Our framework ( Figure 1 ) consists of eight sequential steps, presented in Table 1 with a brief description and a series of questions project teams should ask themselves. To illustrate the framework in action, we present a brief case study based on our local experience.

Hospital System EPTR has identified a gap in the management of their diabetes population using Medtrix continuous glucose monitoring (CGM) devices. An internal root cause analysis pointed to a lack of available structured CGM data/metrics in the EHR has increased the time needed to document clinical notes, creating additional administrative burden on clinicians. To address this, it has been recommended that EPTR create a CGM data integration with Medtrix. From a patient perspective, Medtrix is the most commonly used CGM in our patient population. Many patients do not have access to the internet at home, so they upload their data during clinic visits using hospital computers or hospital wifi. This process is time consuming for patients and staff, and also needs to be addressed.

With this recommendation, EPTR clinical and IT leadership began to assess the feasibility/capability in planning and implementing a CGM data integration. The planning consisted in evaluating the technical, security and legal, financial, and operational considerations in play.

To assess the technical capacities of EPTR, IT leadership requested and reviewed integration strategy documentation from Medtrix. During technical calls with Medtrix, it was determined that EPTR’s current capability to send and receive EHR HL7 messages externally through a third-party integration vendor, made EPTR a great candidate for this type of integration. For providers, they would continue to use the existing computerized physician order entry (CPOE) function to request CGM data within the EHR.

With recent security breaches within the healthcare industry, EPTR’s information security and legal teams have implemented a variety of processes to mitigate liability and risk. EPTR’s IT security team requested comprehensive technical details of Medtrix’s IT security posture and data management. In addition to executing the vendor’s Data Subscription Agreement, detailing the services and cost of the integration, a separate security addendum provided by EPTR was added. The addendum ensures Medtrix has industry standard security practices and maintains certain service levels. With Medtrix’s status as a hybrid covered entity under HIPAA, no Business Associate Agreement needed to be executed. From a legal perspective, the type of data provided through the integration service falls under the Treatment, Payment, and operations clause, but to decrease liability, data is requested via CPOE orders and not pushed automatically to the EHR.

EPTR’s financial assessment consisted of three considerations: Medtrix’s annual data subscription fee of $8,000, internal project team labor cost, and cost of maintaining the integration. Much of the project team’s cost will come from IT design/development work and testing of the HL7 messages and CPOE order sets. Maintenance cost was determined to remain relatively low. Any additional data being requested through the CGM integration can be worked on by EPTR’s internal clinical systems and integration team.

Even though the main objective of a CGM data integration is meant to reduce or eliminate repetitive administrative workflows, it does introduce new ones. Previously, clinical staff was tasked with logging into Medtrix’s data platform to download, print out an AGP report, hand it to the physician, and scan the document into the EHR. With the new CGM data integration, clinical staff were now tasked with submitting CPOE orders to ensure patient consent and account linkage. Once consent is provided by the patient via email, clinical staff can submit a secondary CPOE order to request CGM data for a particular timeframe. Fortunately, no additional staff was needed to accommodate this new workflow but did require adjustments to clinic workflow.

After a comprehensive review of the feasibility of this effort, clinical and IT leadership created a business case to present to EPTR’s capital committee. Not only was the business case essential to requesting capital funds to implement the project, it also provided the institution the rationale of how this new technology was beneficial to their patients and clinicians. The benefits consisted of the following: remote patient monitoring within the EHR, improve clinical documentation with structured glucose metrics (see trend analysis in a flowsheet/results review), eliminate need to print out and scan reports, use structured data for population health management, help achieve value-based metrics, and may provide additional reimbursement.

Once the budget was approved and contracts were executed, a project manager was assigned to implement the data integration. A project charter was developed to provide a detailed project plan and to receive approvals from the various stakeholders involved. After assigning project resources internally from clinical and IT dept, a project kick-off call was held with Medtrix’s project team. It was at this stage where a communication campaign was created, to make providers and staff aware of the implementation of the CGM integration. This allowed the Endocrinology dept and its staff to understand the new technology, but also become aware of the change in their workflow.

The actual implementation of the CGM data integration was carefully planned out and documented within the project charter. For the design phase, the clinical project team worked to define the glucose metrics and the data timeframe preferred. Once defined, IT resources began to work on defining the HL7 messaging to send and receive data for the integration. In addition, a CPOE order set was also designed to allow clinicians to order the sending of patient consents via email to patients and orders for 14, 30, 45, 90 days of glucose data. Clinical staff were also engaged to map out their existing workflow and work to define a new one with the new integration in place. Within the execution phase, the various components were tested to ensure data flow between EPRT EHR and Medtrix. Clinical staff were asked to run through the new workflow within a test environment.

Before go-live, 3 weeks were dedicated to developing training guides and providing virtual or in person training on the new technology and workflow. Go live support was also provided on the day of and 2 weeks after. To ensure project success and identify potential improvements, a report was created to track the usage of the CPOE CGM order sets, and the amount of data transferred through the integration. A dashboard was also created to help with population management using the structure data.

Technical and operational integration are critical for the successful implementation of any digital health project. For experienced teams and institutions with robust project management practices, these may be second nature, but even at the most innovative institutions there can be oversights and failures. In the same way that checklists have improved many aspects of safety and quality across healthcare (indeed, across most industries), team may wish to create their own local checklists of processes, individuals, and governing bodies that correspond to the 8 steps in the integration framework, and systematically implement it for all digital health projects.

Some of the components of our proposed Integration Framework may sound familiar or even redundant to teams familiar with the needs assessment, implementation, and evaluation frameworks briefly reviewed here. This was done deliberately; many of these steps, if not addressed at this stage, can lead to critical system failures during implementation and evaluation, resulting in failed implementation, wasted funds and effort, possible patient harm, and liability exposure. For teams interested in implementing our approach, we do not recommend duplicating work or steps, but rather consider the process from beginning to end across all 5 phases, selecting their preferred frameworks, and then mapping the steps of the integration framework to their cognates in other frameworks. This will allow teams to address each step comprehensively in the appropriate phase (e.g., Step 1, ensuring patient access and acceptability, may already be part of your needs assessment or solution identification).

In our experience, many diabetes data and technology solutions do not have explicit patient processes, workflows, or technical capacity requirements, which leads to implementations that are frustrating for the patient, family, provider, and care team. Our hope is that following the outlined steps will facilitate the adoption of technologies that increase patient engagement and empowerment in regard to accessing and reviewing diabetes data. Many patients with diabetes don’t currently have the ability or tools needed to access their data. Not only will increased access improve current care, patients will learn life-long skills related to diabetes care and improve self-efficacy. Finally, successful digital health implementations can enable improved patient care in synchronous and asynchronous models.

There are limitations to the integration framework. It represents a single institution’s experience and has not undergone more robust vetting. It is intentionally generic to accommodate a variety of data and technology solutions, but this means that more detailed information for specific modalities, such as telehealth, continuous glucose monitoring, and school-based care, is not covered. It also assumes that an organization has people and processes in place to address many of the steps discussed (for example, information security assessment), and as such may not be as helpful in resource-limited settings. Finally, this framework assumes local or institutional management of resources; the framework may need to be adapted to meet the needs of large health systems or countries with national public health systems.

Despite these limitations, we believe that following this practical framework can help reduce friction, prevent delays, and avoid potentially disastrous oversights during the technology selection and implementation process. We hope that others find this tool useful in their own implementations of diabetes data and technology.

JE conceived the manuscript, wrote the first draft, and developed the figures. SC, PS, MT, and JR contributed to the conception and refinement of the manuscript, as well as to writing sections of the manuscript. All authors contributed to manuscript revision, read, and approved the submitted version.

This work was supported by the Food and Drug Administration under award number P50FD006425 for The West Coast Consortium for Technology & Innovation in Pediatrics, and by grants UL1TR001855 and UL1TR000130 from the National Center for Advancing Translational Science (NCATS) of the U.S. National Institutes of Health. The funding sources had no involvement in the development of this manuscript or in the decision to submit the paper for publication. The content is solely the responsibility of the authors and does not necessarily represent the official views of the FDA or the NIH.

JE is a paid consultant for AI Health.

The remaining authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.