Abstract
Background:
The rapid advancement of diabetes technology, including continuous glucose monitors (CGMs), insulin pumps, and automated insulin delivery systems, has revolutionized diabetes management. However, current care delivery paradigms have not kept pace, prolonging suboptimal health outcomes for youth with type 1 diabetes (T1D). A significant obstacle is the siloed nature of clinical data. This article explores integrating CGM data for multiple vendors into electronic health records (EHRs) to unify diabetes data in health care practices.
Methods:
This article describes the integration of diabetes device data, following Integration of Continuous Glucose Monitoring Data into the Electronic Health Record (iCoDE) specifications, in the EHR at an urban, tertiary, academic pediatric medical center serving approximately 500,000 pediatric lives in Southwest Ohio. The Diabetes Center provides specialized interdisciplinary care for about 2200 patients with diabetes, with an average of 200+ new onset cases/year. This project is part of the Cincinnati Children’s Diabetes Clinic Initiative (ConnecT1D), funded by the Helmsley Charitable Trust, aiming to reorient diabetes care from quarterly visits to continuous, proactive care.
Results:
By evaluating 6 key factors for integration (data sources types, clinical workflows, level of integration, visualizations, sustainable account management, and optimization), we successfully achieved structural interoperability of CGM device data for 3 vendor platforms into the results section of the EHR using HL7 v2.x.
Discussion:
We present practical tips to optimize the integration experience: identify the problem, mobilize resources, negotiate contracts early, evaluate and optimize the workflow, celebrate early wins, prepare for (inevitable) stumbling blocks, keep asking questions, implement change management techniques, and evaluate integration acceptance, iterate, and monitor.
Conclusion:
While beneficial for patients and clinical workflows, integration of vendor CGM data into the EHR currently requires significant resources. Challenges remain in optimizing workflows, mapping data, and vendor variability. Ongoing monitoring, maintenance, and optimization are necessary as technology and workflows evolve.
Introduction
Background
The rapid advancement of diabetes technology, including continuous glucose monitors (CGMs), insulin pumps, and automated insulin delivery systems, has transformed diabetes management and contributed to improved glycemic control.1–3 As these technologies advance, the volume and complexity of associated data also increase. However, the current care delivery models have not adapted accordingly, contributing to persistent gaps in health outcomes for youth with type 1 diabetes (T1D) and complicating efforts to deliver consistent, high-quality care. One major barrier to diabetes care is the fragmented nature of clinical data. Diabetes device data and clinical data often reside in separate systems, limiting the efficiency of clinical decision-making and leading to significant manual transcription of data.
This article examines integration of CGM data into electronic health records (EHRs) as a strategy to unify diabetes data and streamline clinical workflows. The availability of discrete CGM data elements is relevant for individual encounters, population health initiatives, 4 and sharing de-identified data to national learning networks (T1DX-QI)5–10 and international benchmarking (SWEET).11–13 In addition, discrete data pulls reduce the reliance on manual transcription, which has the opportunity to reduce provider cognitive burden, improve safety, and improve data quality for research and quality improvement (QI) efforts.
We describe the pragmatic implementation of multivendor CGM data integration within an academic pediatric Diabetes Center’s EHR system based on Integration of Continuous Glucose Monitoring Data into the Electronic Health Record (iCoDE) Standard Project. 14 This includes discussion about participants, stakeholders, technical components, project timeline, resources, key decision points, learnings, and practical tips.
Our goal is to provide a resource for clinicians and health care organizations working to align diabetes technology with care delivery. By sharing our experience, we aim to support ongoing efforts to improve the usability of diabetes data within clinical workflows.
Previous work
Unifying disparate health care data in a clinically usable manner remains cumbersome. Radiology saw early success with integration, largely due to the widespread adoption of DICOM® (Digital Imaging and Communications in Medicine), a standard for storing, transmitting, processing, and displaying medical images. 15 In the diabetes space, the development of the Ambulatory Glucose Profile (AGP)16–18 is a similar success and critical to the adoption of standardized clinical metrics and visualizations across CGM vendors. Over the past several years, multiple groups have worked toward integrating CGM data into the EHR.19–23 Initial standardized CGM metrics were established via international consensus in 2019. 24 In 2021, the Diabetes Technology Society launched of the iCoDE Project, an effort to bring together stakeholders from across industries to develop both technical specifications and workflows to facilitate CGM-EHR integration. 25 The resulting 2022 iCoDE Report: CGM-EHR Integration Standards and Recommendations provides technical and operational guidance. These published standards provide crucial direction for the application of technical specifications and workflows to facilitate data integration, serving as the basis for this work.
Overview
Setting
Cincinnati Children’s Hospital Medical Center is an urban, tertiary, academic pediatric medical center located in Southwest Ohio. It serves approximately 500,000 children and utilizes a single instance of Epic (Epic Systems Corporation, Verona, Wisconsin) for both inpatient and ambulatory settings. The Diabetes Center provides specialized care for approximately 2200 patients with diabetes, with an average of 200+ new onset cases/year. The patient population is 85% White, 10% Black, 2% Hispanic/Latino, 1% Asian, and 2% fall into other racial/ethnic categories. Insurance coverage includes 58% with private insurance, 29% with public insurance, and 13% who are self-pay or uninsured. The Diabetes Center operates four clinical locations and one mobile care clinic. The multidisciplinary team includes 16 physicians, 8 APRNs, 15 Certified Diabetes Care and Education Specialists (CDCES), 5 social workers, 2 PhD psychologists (1 CDCES), community health workers, community partnership, and families. Administrative care coordinators, clinical quality specialists, and data analysts contribute to comprehensive clinical care.
The project, ConnecT1D,26,27 is part of the Cincinnati Children’s Diabetes Clinic Initiative, funded by the Helmsley Charitable Trust, which aims to reorient diabetes care from quarterly visits to longitudinal, continuous, and proactive care. The global objective of ConnecT1D is health care delivery system redesign that optimizes supports in clinic and at home through (1) quality improvement initiatives that enhance access to diabetes technology to address health disparities and improve population management between appointments, and (2) a unified clinical information system infrastructure that integrates currently siloed diabetes device data and EHR systems. The scope of this article is to describe the process, decisions, and learnings of integrating patient’s diabetes device data directly into the patient’s EHR by interfacing with multiple vendor systems.
Participants/stakeholders
Before negotiating contracts with vendors, we obtained organizational support and assembled a diverse team that represented a range of stakeholders and expertise. This team consisted of clinical staff, patients, support staff, clinical informatics, consultants, technical team, and external teams (Table 1). We found the following experience critical to the team: diabetes (first-hand or lived), quality improvement (especially change management), workflow, education, and EHR “super use.” We also found that having a clinical informaticist was important in streamlining communication between clinical and technical teams.
List of Team Constituents and Roles
Lists all the team groups and members for the overall project.
RN, registered nurse; MA, medical assistant; T1D, type 1 diabetes; IS, information services; EHR, electronic health record.
Our work was guided by an advisory board composed of members from clinical leadership, operational leadership, research and quality improvement leadership as well as patient/parent representatives.
Technical components
The discovery, analysis, and design of the infrastructure to support this project required significant planning. During this planning process, we considered different levels of interoperability to enable integration between vendor platforms and the EHR.
There are four levels of interoperability among data exchange systems: (1) foundational interoperability, which enables basic data exchange between systems; (2) structural interoperability, which leverages standardized structures, formats, and syntax; (3) semantic interoperability, which supports shared understanding through common vocabularies and code sets; and (4) organizational interoperability, which involves the policies, governance structures, and workflows that facilitate secure information sharing (Fig. 1). 28 Together, these dimensions enable timely, accurate, and meaningful data exchange essential for improving health outcomes. 29
Levels of interoperability as defined by Healthcare Information and Management Systems Society (HIMSS). 28 Demonstrates the four levels of interoperability, what they consist of, and examples of associated standards. Trusted Exchange Framework and Common Agreement (TEFCA), Health Insurance Portability and Accountability Act (HIPPA), General Data Protection Regulation (GDPR), Logical Observation Identifiers names and Codes (LOINC), International Classification of Diseases (ICD), Current Procedural Terminology (CPT), Health Level (HL), Clinical Document Architecture (CDA), Fast Healthcare Interoperability Resources (FHIR), United States Core Data for Interoperability (USCDI), Consolidated Clinical Document Architecture (C-CDA), Extensible Markup Language (XML), Hypertext Transfer Protocol Secure (HTTPS), Transport Layer Security (TLS), Security Assertion Markup Language (SAML), and OAuth (Open Authorization).
For this project, message exchange standards played a central role. We used HL7 v2 (Health Level Seven version 2), an international standard for health care messaging. 30 In a typical HL7 setup, data flows from the vendor platform to the EHR via a middleware integration layer, facilitated by an integration engine (Fig. 2). Although HL7 Fast Healthcare Interoperability Resources (FHIR) 31 offers a modern, API (Application Programming Interface) based approach that supports granular data exchange and patient-facing applications, our 2022 decision to use HL7 v2 was based on vendor readiness and infrastructure maturity at the time. Since then, some vendors have begun releasing FHIR-based integrations.32,33
Data exchange overview. After a clinician places an order in the electronic health record (EHR) for diabetes device data (1), that request leads to the vendor matching the patient (2), takes the data and formats it into a message (3) which is transferred to a middleware integration platform (4) where additional processing is completed (5) to then be forwarded to an locally owned enterprise interface engine (6) which adds local information (7) and then is transferred to the EHR via the electronic data interchange (8) and is stored into the EHR database (9) and shared back to the clinician (10).
During the planning phase, we explored multiple vendor source systems (Abbott, Dreamed, Glooko, Tidepool) and the capabilities of our local EHR (Epic, Epic Systems Corporation, Verona, Wisconsin). We identified three common integration strategies across vendors: (1) embedded links in the EHR that navigate to the patient within the vendor platform, (2) ingesting PDF (Portable Document Format) summaries (e.g., the AGP) (Foundational Interoperability-Level 1); and (3) structured data integration of discrete, standardized metrics (Structural Interoperability-Level 2).
Timeline and resources
Our project for integrating diabetes device data into the EHR aligned with an existing 3-year diabetes clinical innovation grant. Representatives from the integration team (Table 1) met for an hour at least twice monthly for 3 years to maintain a routine cadence of communication throughout the long-term project. Focused work for the technical and clinical teams occurred asynchronously between the larger team meetings. Planning and preparation began about 6 months before initial vendor contracting in Spring of 2022, and optimization continues to the present day (2025) (Fig. 3 for timeline). Throughout the project lifecycle, modifications to the scope or design were documented. We tracked unforeseen issues and their subsequent resolution across all phases of the project (discovery, development, deployment, and postdeployment). A project manager played a central role in facilitating cross-functional collaboration, coordinating internal and vendor resources, and ensuring that we continued to meet our objectives.
Timeline of our project work includes considerable lead time for contracting and business use agreement execution. Notably, vendor 1 did not require any payment, which abbreviated the contracting timeline considerably compared with subsequent vendors.
From a resourcing standpoint, Table 2 summarizes the different team efforts required for this project. This highlights the significant financial and resource effort required for this kind of work. As familiarity increases with requirements for integration, future timelines and resources could be streamlined.
Effort Broken Down by Groups
Decision Points and Learnings
We have achieved structural interoperability with local semantic harmonization of CGM device data from three vendor platforms within the results section of our EHR. Our clinicians place an order to view a patient’s CGM data, which populates as discrete data rows in the laboratory results (“Results Review”) section of our EHR with a link to a PDF version of AGP. The data rows are standardized based upon 2019 Consensus Standards 24 (Table 3) across vendors, which facilitate efficient review by the clinician within the EHR. In addition, team members can launch one vendor platform directly from the EHR, allowing them to access additional data details, including discrete values and individual days on the web-based platform without multiple login steps. We encountered several critical decision points throughout the process, and we describe those decision points and associated early learnings in the following sections.
2019 International Consensus Standardized Continuous Glucose Monitor Metrics for Clinical Care,* Including Both the 10 Discrete Standardized CGM Metrics as Well as the Visualization
*Reference 24.
CGM, continuous glucose monitor.
Data sources and types
Selecting our data sources from the available diabetes technology vendors and third-party aggregator platforms presented the first critical decision point. To guide decision-making, we inventoried the most common devices used by our patient population, the distribution of those devices, any existing contracts for data use or potential charges, and any existing account links between vendors and our center. This information directed us toward vendors that aligned best with our center’s goals.
Since the goal of this integration was to make access to diabetes device data easier for clinicians, we needed to organize the data coming from multiple sources. There are existing standards for 10 discrete CGM metrics and AGP using the 2019 International Consensus (Table 3) and iCoDE.24,25 While all vendors provided the core metrics and AGP, some offered additional nonstandard fields (Supplementary Data S1). Vendors offer additional reports, including optional reporting periods (7, 14, 30, 60, 90 days), and vendor-dependent formatting of glucose pattern visualizations via PDF reports beyond the standard AGP.
Selecting which of available data to include as part of integration was a significant task for the project team since these choices impact subsequent data visualization in the EHR. Frequently, the vendors could not share specific reports and data elements (beyond standard metrics) until after contracts were signed, which delayed decision-making. The clinical and technical teams worked together to harmonize the available discrete metrics from different vendors into a consistent naming convention. For consistency and simplicity, the team elected to only use the 14-day time interval as standard for CGM integration into the EHR at our institution. To supplement the PDF of the AGP, one vendor allowed our team to select the most relevant reports to be included as part of PDF integration. Some vendors did not offer alterations to the data elements included in their PDF reports. For the vendor that permitted customization, we surveyed our center’s diabetes providers to ensure we only included those data elements that received a majority vote for inclusion. This reduced the total size of the PDF report by approximately 50%, making it more manageable for review during the clinic encounter. Remaining device data remained accessible via vendor portals but were not incorporated into the EHR.
We decided against incorporating raw CGM data due to both technical and strategic factors. At the time of planning (2022), raw data pathways often relied on consumer-facing platforms since aggregator vendors could not support raw data streams reliably. Although technically possible now, processing raw data in a local data lake did not support our primary goal of embedding data into the EHR workflow and following the application of iCoDE principles.
Clinical workflow
To guide the technical team in identifying and building the best solutions, the clinical team reviewed the existing clinical workflow and described their desired improvements. There are two methods of data retrieval: (1) pulled when ordered or (2) automatically pushed at regular intervals. Our center elected to focus on data pulls, meaning a clinician when placed an order triggers the EHR to pull data from the vendor. From a workload perspective, clinicians preferred to request data when relevant, rather than sort through a continuous flow of pushed data from devices into the EHR. The choices for order types included standard orders (one-time or standing) or point of care (POC) orders. Choosing the best order type for a given clinical context required consideration of who could place orders, who could sign orders, when the data would appear, and who would be responsible for acting on the results. Initially, for simplicity of the EHR build, our center implemented standard one-time orders. Subsequently, after trialing the workflow for several weeks, our team pursued standing orders in EHR that only need to be signed once and can be released by any staff member at future visits much like our existing POC HbA1c order. We linked the orders to clinic preference lists and grouped orders by vendor (as applicable).
To train our clinical teams about changes to our process, job aids and presentation materials were created by a working group of invested providers, nurses, and CDCES leadership. Curated tools incorporated vendor materials and internally created instructions with corresponding screenshots from our EHR testing environment. The working group started by identifying representatives from each clinical role (providers, nurses, and medical assistants) to receive education in the months leading up to “go-live” who became our early adopters. These early adopters were effective champions because they shared their real-time experiences during clinics, helped familiarize others with the new processes, and gathered feedback to refine the rollout. During the month preceding the “go-live,” the working group disseminated the education materials via multiple modalities—email, documents uploaded to shared drives, and reminders during division presentations. Continued education and adaptability have proven essential to sustaining engagement and optimizing implementation.
To support the implementation of new integration processes, our clinic undertook a comprehensive transition from a historically manual workflow to a streamlined, digital approach. Previously, device data were uploaded via USB cables to vendor-specific platforms, printed—often generating 10–20 pages of color material per patient—and then manually transcribed into discrete data fields within the EHR. This process was time-consuming and resource intensive. Transitioning to a digital workflow required thoughtful planning to minimize disruption and address reluctance to change, particularly from providers accustomed to paper-based workflows. To facilitate the transition, we reconfigured workstations to ensure two screens for simultaneous viewing of diabetes technology data and the EHR. While some providers were initially hesitant to adopt the new workflow, ongoing support and the enhanced functionality of digital tools have led to widespread acceptance. Printed reports remain available as a backup, but digital review has become the new standard. As a result, paper and toner usage in clinic have decreased, aligning with broader goals of sustainability and operational efficiency.
Level of integration
We implemented all three approaches (embedded links, PDF ingestion, and structured data) and observed distinct advantages and limitations. Embedded links facilitate seamless access during clinical encounters, but rely on vendor-hosted interfaces and offer minimal population health utility. PDF ingestion allows for richer data display within the EHR, but is not machine-readable and requires manual review. Structured data integration provides the highest level of utility by enabling automated workflows and population-level analysis, but required more complex mapping and standardization work.
Although most vendors now support standard fields for standard metrics, the consistency and reliability of data mapping remain variable. Additional effort was required to align external data with internal EHR fields and achieve local semantic harmonization (i.e., consistent data experience for internal clinical users regardless of source [Supplementary Data S1]). Through these efforts, we achieved consistent representation of 10 standardized metrics across multiple vendors within our EHR (Supplementary Data S2).
In our experience, this level of interoperability is adequate for this type of endeavor where the health system is primarily a data consumer. For clinical endeavors that require bidirectional data exchange, higher levels of interoperability (e.g., semantic interoperability) may be critical. While only one vendor currently supports direct navigation with embedded authentication for seamless clinician access, this approach presents an important opportunity to reduce friction in clinical workflows, despite its limitations for longitudinal or population-level interventions.
Visualization
After selecting and organizing our data, we needed to decide on how to display it within our EHR system, Epic (Epic Systems Corporation, Verona, Wisconsin). While the exact functionality and options are EHR vendor specific, the general choice is between storing data as laboratory results (“Results Review”) and in other discrete fields (“Flowsheets”) as offered by the EHR vendor (Table 4).
Comparison of Flowsheets and Results Review
AGP, ambulatory glucose profile; EHR, electronic health record.
In our EHR, flowsheets provide discrete documentation of various data types (such as vital signs, patient reported outcomes, and so on). They are managed by the ambulatory EHR team and offer significant flexibility and customization options. Our existing clinical workflow relies heavily on flowsheets, but they have limited visibility to patients and members of the health care team outside of the Diabetes Center. Data contained in flow sheets are not shared via health information exchanges, which limits visibility for primary care providers and adult providers when pediatric patients transition care.
In our EHR, results review displays laboratory and imaging results. It is managed by the laboratory EHR team and is capable of sharing results via patient portals (Supplementary Data S3) along with functionality related to classical laboratory result processes (such as billing or abnormal flags). Results review offers organizational visibility, the ability to combine standard endocrinology laboratory testing, and both discrete and PDF data from CGM in one location. Results review displays historical data, with options to view trends, and triggers downstream events such as notification messages to clinicians and patients. To conform with the College of American Pathologists regulations, results that appeared in the EHR must properly indicate that they originated from a patient source and were not validated within the institution’s laboratory. As a result, the use of the results review function required approval from the laboratory medical director.
Both approaches require the construction of new visualization tools and can feed data directly into progress notes. Our EHR allows for clinician facing visualizations (such as Synopsis) that bring together information from results, flowsheets, and orders. 34 However, the development of these visualizations was outside the scope of this project and has not yet been completed in our environment.
Despite working closely with us, our EHR vendor did not have any initial recommendations for ideal data visualization/storage location. There continues to be uncertainty about future development for EHR vendors in this area. Ultimately, our team chose the results review function so that CGM metrics could be visible with other endocrinology laboratory values (Supplementary Data S2 and Supplementary Data S3). Other benefits that influenced this choice include the ability to combine both discrete and PDF data in one location, the option to view historical data and trends, and the inclusion of notification to clinicians and patients that were relevant to clinical care.
Sustainable account management
For successful intergation, patients and accounts must be linked. There are three critical components of account management. The first is establishing accounts, the second is linking the patient’s EHR and vendor accounts, and the third is maintaining that link. As a by-product of the COVID-19 pandemic, our clinic started off with a high percentage of linked diabetes device accounts to platforms. High uptake of linked diabetes devices enabled rapid use of integration after go-live.
The second component is linking EHR and vendor accounts. Vendors use different criteria for matching, but the following are used most often: name, date of birth (DOB), and email address. Sometimes medical record numbers can be used. DOB and e-mails can present complications for pediatric patients because parents often substitute their information for the patient’s information when setting up an account with the device vendor or data platform, some of which cannot be changed in real time due to permissions. Additional issues with DOB include inversion of the month and day.
The third requirement is maintaining linkage, which requires each patient to have only one vendor account. There are several different ways in which patient accounts can be created, some of which are automatic processes that cannot be deactivated. Duplicate accounts happen when one account is created by the clinic for a new diabetes device, with a subsequent second account created by the family (perhaps when setting up a new device or downloading the vendor app on their own). When attempting to link the family account to clinic, the vendor, instead of merging accounts, creates a second separate clinic account. In fact, about one-third of all accounts from our largest vendor were duplicates. All accounts (3109) were manually reviewed, 1080 were identified as duplicates (by name) or had not been seen in clinic in >2 years, which the vendor was able to delete. However, there were another 753 accounts that were created by our clinic, but had never been “activated” by the patient. These accounts had to be manually deleted by our team, which takes ∼ 1 h for 50 accounts. In our ongoing review, 10 duplicate accounts are identified per quarter for deletion. This means that for optimal integration, it is important to implement ongoing maintenance to maintain appropriate linkage for each patient.
Optimization
In the months immediately following the launch, our data showed low utilization of the new data orders. Our team reacted by implementing post “go-live” optimization efforts. Early adopters collected open response feedback from colleagues and their own experience. Workflow optimizations include changing timing of data order to previsit planning, improving ordering process by switching to standing orders, improving the location of results in results tree (next to our diabetes laboratory results), and addition of more utilized vendors that resulted in an increase in orders over time (Supplementary Data S4). We now see an average of 170 data orders per month.
We gathered qualitative feedback from members of our patient and family advisory board. An analysis of this feedback demonstrated that patient families were excited to see CGM results in their patient portals alongside other diabetes laboratory data. Families felt that this colocation allows for easier tracking and monitoring. Families also note that seeing CGM data in patient portals helps resolve issues around keeping tabs on multiple children.
Practical Tips to Start and Sustain Device Integration
Based on our experience, we present the following tips to optimize your CGM data integration experience (Table 5).
List of Tips to Optimize Your Integration Experience
Identify the problem
Start by identifying the problem you hope to solve in your clinical environment. Integration requires significant effort, resources, and ongoing maintenance for an optimal clinical experience. Successful integration will involve taking inventory of your clinic, patients, and data platforms. It is helpful to review iCoDE reports which provide technical specifications and workflows developed by stakeholders from across industries to facilitate CGM-EHR integration. 25 A clearly defined problem will assist in making decisions around opportunities to improve existing systems or pursue new alternatives.
Mobilize resources
You will need persistent, potentially multiyear engagement from stakeholders in numerous domains, including clinical teams, patients, support staff, technical teams, and vendor teams (Table 1). Due to inherent differences in institutional EHRs, we found it helpful to collaborate with peer institutions who had either undergone or were in the process of similar integration. Two invaluable resources include EHR vendor experts (such as the Epic Taskforce) and members who participated in iCoDE. Foster an ongoing communication pathway with your vendors as this is important to the sustainability of this project for post “go-live” troubleshooting. Finally, seek institutional support early to ensure that appropriate resources are mobilized and committed for the duration of the project.
Negotiate contracts early
The contract negotiation process often includes more than the business agreement to determine data sharing guidelines. Additional components include security, privacy, technical, and hardware evaluations. This often means gathering inputs from multiple team members with legal, technical, security, and clinical perspectives. It is also important to recognize that the diabetes device landscape continues to evolve and change. Take inventory of your current contracts and explore an opportunity to amend or modify them before creating an entirely new contract. In our work, the average time to reach a signed contract was 10 months. Through this process we learned that some of the clinical and technical considerations as well as inventory of existing device and platform utilization can be done while awaiting the contract process to expedite project completion.
Evaluate and optimize the workflow
A thorough evaluation and optimization of baseline workflow processes is critical to success. This allows for pinpointing critical components of the EHR build such as where to put the data (Table 4), note templates, organization of orders, and ideal visualization tools for the data. In the case of vendors that offer both discrete data and PDFs, it is important to consider how one might navigate between data sources as part of the process. Evaluation should also include decisions addressing billing codes to promote sustainability of the new processes.
Celebrate early wins
Highlight initial accomplishments to build momentum and excitement for the effort, especially among those not involved in the day-to-day project work. This momentum is a key component of project sustainability. 35 We achieved our biggest “early win” when we successfully linked vendor platforms directly to the EHR. The easily navigable embedded links eliminated the use of multiple logins and patient identification issues, a long-standing pain point for our clinic. This was also one of the fundamental changes that permitted the transition to digital data review in the clinical environment and the subsequent reduction in resource utilization (such as paper and toner) as previously described. In addition, embedded links significantly decreased the burden of diabetes device report creation and printing on the medical assistants rooming patients, thereby allowing for redistribution of time and skills to other aspects of clinical care.
Prepare for (inevitable) stumbling blocks
Despite careful planning, there will always be surprises and unexpected decisions that arise during the integration process. With regard to test environments, make sure your team has the skills to setup test patients in the appropriate environments for testing. Requirements include ensuring appropriate access to testing environments and communication with vendors around when/how test data are updated and refreshed. One vendor required an organizational logo as part of their enrollment e-mail. The message and logo had to be approved and go through marketing and legal, which led to significant delays. Understanding all the artifacts the vendor will need from your organization allows you to begin these internal processes in a timely manner, thereby preventing or mitigating delays. We were able to temporarily solve this problem with a blank image.
Keep asking questions
The process of data integration is extensive and spans many disciplines. Therefore, it is critical to keep asking questions of vendors, the clinical team, and the technical teams. One of the biggest risks to a successful integration effort is making assumptions without verification from appropriate team members. A clinical informaticist can help streamline communication and ensure that the different teams are fully aligned.
Implement change management techniques
Numerous quality improvement principles helped us optimize the work. We have already addressed principles such as optimizing the workflow before integrating technology, identifying early wins, understanding the problem you are trying to solve, assembling a team, and obtaining appropriate buy-in. Principles of small tests of change (1 patient, 1 provider, 1 team, etc.) allow for smoother go-live scenarios by testing and troubleshooting at a smaller scale with support to work out initial kinks as we built up to a clinic-wide go-live. In addition, recognizing the cadence of your team and ensuring forward momentum can be difficult if there are delays at certain steps such clinical decision or resource allocation.
As with any change in the clinical environment, it is critical to develop appropriate education and training. Clinicians must understand the opportunities and limitations of different data sources to ensure safe and effective patient care.
Translating a previous paper-based workflow of printing out reports also requires attention to the physical environment and changes that may be necessary such as changes in computer setup or configuration to allow for sharing of digital reports with patients and families.
Evaluate integration acceptance, iterate, and monitor
Evaluate your initial integration efforts by exploring how well you solved the initial problem you set out to solve. Engage frontline users and collect their experiences to ensure that the time and effort are rewarded or identify adjustments to the process to improve its usability.
Frontline users expect and require access to—and trust in—the data to provide patient care. Problems with reliability or ability to obtain the data can quickly lead to users abandoning the new process. Having a process for rapid problem identification and troubleshooting is critical for long-term success. An identified point person plays a critical role in gathering and escalating issues for effective troubleshooting. We recommend frequent communication with the clinical staff as issues are resolved, so they recognize the value of their input in ongoing process improvement.
Some EHR systems or interface engine monitoring can provide insight into the frequency of order placement as well as errors that arise allowing for ongoing monitoring and optimization.
Since we have concluded the initial project work of this integration, further developments or changes will need to go through our standard operational ticketing workflows which are triaged based on the site of care (ambulatory) and associated resource allocation needs. It is helpful to know what this process will look like at your organization after the completion of the initial project work.
Conclusions
In this work, we describe the successful implementation of multivendor CGM data integration within an academic pediatric Diabetes Center’s EHR system based on iCoDE Standard Project. 14 We share our process and decisions for choosing data sources and types, optimizing and evaluating clinical workflows, matching level of integration with clinical need, and choosing data visualization and storage location in the EHR that best meets the objectives of the organization. The functionality of ordering CGM data elements for review directly into the EHR replaces the manual transcription of 10 fields in our documentation, eliminates the need to log into separate vendor platforms, and replaces printing digital reports. These changes improve patient safety, reduce clinician burden, and improve resource utilization. We have early feedback from patients who value being able to see CGM results with their other diabetes laboratory data in their health system patient portal. Clinicians report satisfaction with a streamlined workflow, and the clinic has benefited from operational efficiencies based on reduced check-in times and reduction of printed reports. We hope that by sharing our experience and learnings, we can support similar endeavors of other clinical centers and decrease the overall burden of subsequent integration efforts.
While we continue to be optimistic about the impact of this work, the effort to fully integrate diabetes device data is dynamic and ongoing. Currently, integration continues to involve pragmatic challenges, 36 including mapping efforts, vendor variability, limited technical expertise, and ongoing maintenance, that collectively limit widespread adoption. We look forward to additional standards from iCoDE 2 for insulin dose data to expand the possibilities of discrete diabetes device data within the EHR. Ongoing advances in data integration will better support clinicians and patients, enable quality improvement and health services research, reduce burden, and facilitate improved outcomes for those impacted by diabetes.
Authors’ Contributions
M.I.K.: Investigation (equal), methods (equal), writing—original draft (lead), visualization (Tables 1–5, Fig. 3, supplement 1–4, lead), and writing—review and editing (equal); R.L.: Investigation (equal), methods (equal), writing—original draft (supporting), and writing—review and editing (equal); W.G.: Investigation (equal), methods (equal), and writing—review and editing (equal); S.T.: Investigation (equal) and writing—review and editing (equal); B.V.: Project administration (co-lead) and writing—review and editing (equal); G.M.: Investigation (equal) and writing—review and editing (equal); B.M.: Project administration (co-lead), visualization (lead, Fig. 3), and writing—review and editing (equal); N.-H.Y.J.: Conceptualization (co-lead) and writing—review and editing (equal); J.E.: Methods (equal), visualization (lead, Fig. 1), and writing—review and editing (equal); S.D.C.: Conceptualization (co-lead), funding acquisition (lead), investigation (equal), methods (equal), writing—original draft (supporting), and writing—review and editing (equal).
Footnotes
Acknowledgments
The authors would like to thank Ashley DuNova for the graphic design work of Figure 2 and Juli Bick for her help with 
.
Author Disclosure Statement
N.-H.Y.J. is a consultant for Medtronic and Tzield. J.E. is a consultant for Glooko, Dexcom, and Sanofi.
Funding Information
This work was funded by the Leona M. and Harry B Helmsley Charitable Trust.
Supplemental Material
References
Supplementary Material
Please find the following supplemental material available below.
For Open Access articles published under a Creative Commons License, all supplemental material carries the same license as the article it is associated with.
For non-Open Access articles published, all supplemental material carries a non-exclusive license, and permission requests for re-use of supplemental material or any part of supplemental material shall be sent directly to the copyright owner as specified in the copyright notice associated with the article.
