Abstract
Background:
This study reviews the state of diabetes information technology (IT) initiatives and presents a set of recommendations for improvement based on interviews with commercial IT innovators.
Materials and Methods:
Semistructured interviews were conducted with 10 technology developers, representing 12 of the most successful IT companies in the world. Average interview time was approximately 45 min. Interviews were audio-recorded, transcribed, and entered into ATLAS.ti for qualitative data analysis. Themes were identified through a process of selective and open coding by three researchers.
Results:
We identified two practices, common among successful IT companies, that have allowed them to avoid or surmount the challenges that confront healthcare professionals involved in diabetes IT development: (1) employing a diverse research team of software developers and engineers, statisticians, consumers, and business people and (2) conducting rigorous research and analytics on technology use and user preferences.
Conclusions:
Because of the nature of their respective fields, healthcare professionals and commercial innovators face different constraints. With these in mind we present three recommendations, informed by practices shared by successful commercial developers, for those involved in developing diabetes IT programming: (1) include software engineers on the implementation team throughout the intervention, (2) conduct more extensive baseline testing of users and monitor the usage data derived from the technology itself, and (3) pursue Institutional Review Board–exempt research.
Introduction
Technology is a pillar of the Chronic Care Model. Information technology (IT) systems play a critical role in orchestrating different team members and monitoring a host of clinical and behavioral outcomes. IT is considered an important component of programs to manage chronic diseases—most commonly for diabetes. 5,6 Well-designed software platforms enable multidisciplinary care teams to share information. Decision-support programs plug patient information into validated algorithms to predict potential effects of proposed therapeutic regimens. IT-based disease management is increasingly essential for patients with chronic conditions, who often have lengthy and complicated medical histories. Cell phones and Web sites facilitate information sharing while supporting patient self-management. Diabetes registries provide critical information about individual patients and offer a powerful tool for population-level surveillance. 7 Moreover, the policy environment favors wider use of technology in healthcare, with $27 billion in government incentives available to doctors and hospitals for adopting electronic health records. 8 For these reasons, healthcare providers are increasingly incorporating IT into their practices.
In spite of IT's promise, diabetes programming that makes use of new technologies is plagued with technical and operational problems. 9 –12 We consider these shortcomings and ask why IT has had such limited success in improving diabetes management and what can be done by healthcare providers to advance their diabetes IT programs. In attempting to answer these questions, we turn to a source that public health professionals have historically neglected: the commercial world.
Healthcare providers concerned with innovation constantly grapple with the problem of developing healthcare technologies that providers and patients will utilize. Their challenges with maintaining user interest in diabetes IT programming stand in stark contrast to the success of numerous consumer technologies. For-profit companies are able to develop technologies that generate demand. Although examples from the commercial world can only be extended so far into the field of public health, the exploratory research presented here is based on the conviction that there are important lessons to be learned from the commercial sector's successful design and diffusion strategies.
This article begins with an overview of diabetes IT initiatives, including types of programs and their common strengths and weaknesses, informed by a review of the literature. Our review suggests these programs must improve considerably to realize their full potential. The article proceeds by presenting our findings from interviews with 10 technology developers, representing 12 of the most successful IT companies in the world. We identify two practices, common among successful IT companies, that have allowed them to avoid or surmount the challenges that confront healthcare professionals involved in diabetes IT: (1) employing a diverse team of software developers and engineers, statisticians, consumers, and business people and (2) conducting rigorous research and analytics on technology use and user preferences. The first practice is virtually absent from diabetes IT programs. The second, research, is conducted by healthcare professionals, but its highly inconsistent quality was the most arresting finding of our literature review. We conclude by considering the constraints that make these practices more difficult for healthcare professionals than commercial innovators. These constraints provide a lens for making recommendations for healthcare professionals interested in launching successful diabetes IT programs.
State of Diabetes IT
Healthcare providers and policymakers alike have come to emphasize the role of technology in supporting chronic disease management, leading to an explosion of diverse pilot programs in the last decade. Most IT-based diabetes interventions are implemented in outpatient settings. Providers conduct teleconsultations to provide timely diabetes management support via computers, cell phones, and videoconferencing equipment. Patients upload glucometer readings onto Web-based portals so that physicians, nurses, case managers, and even dieticians and pharmacists can provide feedback. Electronic health records include diabetes-specific portals and registries and network with telemonitoring applications.
While those technologies facilitate communication between patients and providers, other diabetes IT programs serve as a resource for one group or the other. For example, educational computer games target children with Type 1 diabetes. Mobile applications allow users to track caloric intake, levels of physical activity and blood glucose levels for better self-management. Web sites with information on symptoms and self-care strategies also serve as patient resources. Similarly, Web sites, mobile applications, and electronic health records offer healthcare providers referencing tools and decision support for diabetes treatment.
Based on our review, the most successful diabetes IT tool is teleophthalmology for diabetic retinopathy. 13 –15 Cellular phones equipped with digital cameras take high-resolution photographs for diagnosis of diabetes-related vision impairment. Cell phone-based digital imaging demonstrates levels of sensitivity and specificity to diabetic retinopathy comparable to those of clinic-based examinations. Teleophthalmology also serves as a cost-effective method of expanding screening to remote and underserved areas. Teleophthalmology differs from the broader field of diabetes IT in that it is a screening tool and has thus far only been evaluated for its accuracy and cost-effectiveness. It has yet to be incorporated as part of a systematic screening effort and evaluated for its impact on limiting vision loss.
For all of its successes, teleophthalmology is an outlier in diabetes IT. Studies that examine other technologies have been far more ambiguous in characterizing the tools' impact as successful. The following summarizes the impact of diabetes IT programs reported in the peer-reviewed literature. We examine five themes related to diabetes IT: technical function, operational fit, clinical outcomes, behavioral outcomes, and satisfaction outcomes.
Technical function
Diabetes IT interventions regularly encounter unanticipated hardware and software issues that frustrate patients and providers. Patients may distrust readings from technologies that need regular calibration, as is the case with some real-time blood glucose monitoring devices. 12
Additionally, many IT systems need time offline for regular maintenance, such as software upgrades and server updates. Programs that rely on mobile devices must also reckon with battery life issues. 16 During periods of heavy use, Web-based platforms may not have the bandwidth to support additional traffic. 17 These disruptions are not necessarily reported by users, which can lead to lost data transfers. 9 –11 The issues have critical implications for scaling up, as many programs are conducted as preliminary pilots with small patient populations.
Operational fit
Most diabetes IT programs have not been implemented with sufficient attention to operational issues, leading to deleterious effects on provider workflow. Because workflow structure is rarely prepared to absorb new technologies or programs, healthcare professionals spend more time providing treatment. 10,18,19 Initial drops in productivity are customary as users become familiar with new technology, 19,20 but some programs continue to demand more time or are not well reconciled with existing processes. 10,18,21,22 Disrupted workflow is a common complaint of providers newly introduced to diabetes IT. Healthcare providers who have not been consulted in the design phases or who lack appropriate training may perform “work-arounds,” with harmful implications for data collection and patient care. 19 Ongoing disease management means ongoing data collection, and few diabetes IT programs make organizational changes to process the surfeit of patient information they receive—leaving providers unable to parse data. 11,22 Faced with the daunting task of interpreting reams of information, providers do not always provide timely feedback to patients. Nevertheless, a perverse consequence of digitizing patient–provider communication is patients'unfulfilled expectations of immediate feedback from clinicians, all the more so when there are no guidelines governing such interaction. 9,10,18,23
Clinical outcomes
Overall, clinical results are unpersuasive for programs that support disease management through teleconferencing or computer or mobile phone-based platforms. Diabetes IT programs place a heavy emphasis on hemoglobin A1c values, a measure considered problematic for pilot studies of short duration. 24 Other studies consider low-density lipoprotein cholesterol, blood pressure, and body mass index. Using these indicators, the evidence supporting telehealth programs is generally weak. 18,20,21,24 –26 Indeed, studies that include a control group receiving some form of disease management support report no significant difference between diabetes IT and usual care. 10,11 This finding is less surprising given the aforementioned challenges around technical functioning and operational fit. Diabetes IT appears to benefit those with type 2 diabetes more than those with type 1, potentially because insulin dosing is more difficult to calibrate for the latter, and because IT supports the lifestyle changes more critical to managing the former. 9
Behavioral outcomes
On the whole, the literature suggests that diabetes IT does have a positive effect on patient behavior and self-care. Telemedicine programs that link patients with clinicians resulted in improved communication and increased levels of self-care. 10,11,25 However, improved communication does not always translate to greater levels of self-care: large numbers of patients do not comply with Web-based diabetes management programs. 9 Telemedicine programs linked into diabetes-specific portals embedded in an electronic health record system fare better, resulting in more frequent eye and foot examinations and increased blood glucose testing. 18,22 In spite of these findings, many articles lack sufficient evidence to draw definitive conclusions regarding impact on behavior, a point to which we return below.
Satisfaction outcomes
Overall, patients express high levels of satisfaction with diabetes IT, and the programs have a positive impact on sense of self-efficacy toward disease management. 10,11,27 With telemedicine programs, patients appreciate time saved not traveling to see a provider. 21 It is not surprising that training in the technology and observed improvements in clinical outcomes are strong predictors of satisfaction for patients and providers alike. 9,17,20,28 Conversely, reoccurring technical issues cause frustration, leading to high levels of attrition. 10,18,28
The above review suggests that diabetes IT has yet to improve disease management to the extent anticipated by the Chronic Care Model. Many of the aforementioned shortcomings arise from inadequate implementation and user attrition. By contrast, the most successful commercial IT companies have developed technologies that operate seamlessly and generate significant consumer demand. In the next section, we draw from 10 interviews with commercial innovators to present two practices common among successful IT companies that might be exported to the field of public health and diabetes IT.
Lessons from the Commercial World
Methods
To identify potential strategies for improving diabetes IT, we approached commercial innovators who have successfully diffused other types of information technologies. We used industry rankings from the following sources to compile a list of the most commercially successful companies: Amazon Best Sellers List, Apple Store Top Medical Apps, Best in KLAS, Bloomberg BusinessWeek, Fast Company, and Gizmodo. It is not surprising that most companies recurred on these lists. With these rankings, we generated a list of 27 companies considered top-tier innovators: Amazon, Apple, eBay, Epic Systems Corp., Epocrates, Facebook, Foursquare, GE Healthcare, Google, Groupon, IBM, Intel, Microsoft, Motorola, Netflix, Nikon, Nintendo, Nokia, Oracle, Panasonic, Pandora, Priceline, Samsung, Skyscape, Twitter, and WebMD. We approached developers from this list for interviews. Specific individuals working at these companies were identified through a review of Web sites, newspapers, and industry journals. When we were unable to identify a specific developer using this strategy, we contacted the company and were directed to executive developers.
We secured 10 interviews with members of development teams whose work experience spans 12 of our targeted companies. The interviewees were selected based on experience in a managerial position at their respective organizations, availability to respond to questions, and consent to participate in the study. Six of the 10 interviews were conducted with current employees, and five respondents had worked previously at companies on the list. Of the latter, three reported having quit to work elsewhere or on different projects, and two were laid off after a period of downsizing. Respondents performed different functions on their development teams, with seven specializing in software engineering, two in statistics, one in business development, and one medical scientist. Length of employment ranged from 7 months to 25 years.
Interviews were semistructured and averaged 45 min. Respondents answered questions related to managing the design process with an emphasis on human resources, team organization, incentives, and training. A slightly modified interview guide was used with developers of healthcare technologies to capture industry trends. Interviews were audio-recorded and transcribed.
Interview transcripts were uploaded into ATLAS.ti for qualitative data analysis. Coding was both selective and open, 29 where the former were defined at the onset based on themes identified during the diabetes IT literature review. Three researchers coded the transcripts and conferred to obtain agreement.
Several targeted companies were unavailable for comment. Apple, Epic Systems Corp., Groupon, Priceline.com, and Samsung have company policies prohibiting employees from giving interviews. However, we interviewed a former Apple employee involved in software development who was willing to participate. For companies with non-disclosure agreements, we collected interview transcripts that had been sanctioned for release by executives and publicly available from newspaper or journals. We analyzed secondary source material using the same qualitative methodology described above.
Results
Our qualitative analysis identified two practices common among successful commercial innovators, which appear to be absent from diabetes IT programs. We describe these below and discuss how they can be incorporated into diabetes IT programming in the section that follows.
Team diversity
When companies identify an idea they want to develop into a product, a team is assembled, and various corporate divisions—including systems, research, analytics, engineering, sales, and marketing—front a member to participate. Academic and professional backgrounds vary, spanning the arts, computer science, business, and statistics. One respondent noted musical composers as a great engineering asset because of their ability to meticulously interpret coding languages. Depending on the level of hierarchy in a given firm, these diverse development teams have more or less creative control over the ideas that are developed into products and the form they ultimately take.
Such diversity can be a source of irritation. Four respondents noted that software engineers express frustration at having to compromise their vision for business developers. Nevertheless, three of the engineers observed that the interventions of business colleagues help to make products attractive to consumers. The innovation process involves a series of critiques that capture all elements of the potential market. Statisticians and researchers with an understanding of the behavior of the end-user play as big a role as software technicians. For example, one firm grappled with the decision to develop a highly sophisticated computed tomography scanner that could produce 256 simultaneous images of the human body, before finally settling on a less advanced imaging device that would generate fewer images but would be easier for healthcare providers to visually process. Software engineers concerned with producing the most advanced technology possible butted heads with business developers focused on practical application. In this case, practical application won the day. Nevertheless, in other cases, it is the software engineers who have to disabuse the business developers of unrealistic hopes for the capabilities of technology. Incorporating a diverse range of perspectives subjects ideas to a creative friction that ultimately leads to a more polished product.
Research
The commercial innovators in our sample describe an almost religious devotion to research. The companies use a broad spectrum of research methodologies to evaluate interest in their products, including interviews, ethnographic observation, surveys, and focus group discussions. They conduct research rapidly and involve large samples and iterative consultation. Nevertheless, these research strategies were seen as relatively basic. One respondent expressed disappointment at the breadth of research at a firm at which he had been employed as a high-level engineer:
“I asked [the company executives], “What's your process to improve usability and user experience?” The answer was that we were using user focus groups. So I said, “That's not what I asked. I asked about usability—do we have a usability test lab?” And they were looking at me with kind of wide eyes…that made me kind of nervous because they were not doing any in-the-lab usability testing where the best [testing is] when the user is not even aware that she is being studied. We did not have that.”
The same respondent noted that toward the end of his tenure, the company changed its attitude toward research, reorienting its operations toward ongoing analysis of usage data that would “bring back the data to the center.” Indeed, the company is now one of the most successful at developing analytics for usage data.
According to this respondent and five others, the superior method of conducting research was through technology-use analytics. Gathering data from the technology products themselves is a common research strategy to model consumer behavior. For Web-based platforms, online monitoring of site use is complemented by regular technical evaluations of the quality of data transfers. Logging customers' Web site activities, such as session time, hyperlinks clicked, the sequence in which they are clicked, and the queries submitted, provides a wealth of raw data that helps infer customer needs:
We have information about everything that happens on site [and] by everything I mean the complete user behavior…[We] develop models for what [we] want to measure and there are a lot of different metrics that we have…These metrics…figure out how happy the user is with regards to our search. If they are happy, there are certain events that happen more frequently than others. There are certain transitions that even happen…If they are not happy, the chain tends to break or some of the events don't happen at the level they are supposed to or at the frequency that they [are] supposed to happen …
Each search term and hyperlink click are scrutinized to determine what drives customer interest and to develop profiles for different types of consumers. Raw usage data are the foundation of sophisticated analytics for monitoring user satisfaction.
Companies also test ideas in beta versions, using responses to the piloted prototypes to adapt their innovations. As one commercial developer noted, an innovation may “not [be] a full-fledged idea, but [the company] want[s] to get it out to see what users think. [The company] will have tons of new projects and then they will cancel some of them if they are not picking up.” Beta-testing provides statistical comparisons between the established design and the innovation on that design and allows companies to make inferences about the determinants of consumer behavior. This research drives the design and redesign of products.
Discussion
We found that the practices of commercial developers contrast with those of healthcare professionals in academic settings in important ways. These differences can be attributed in part to different structural constraints. Nevertheless, the work of commercial developers presents new ideas for improving diabetes IT programming.
Team diversity
Where team composition is concerned, the development teams of diabetes IT programs are composed almost exclusively of healthcare professionals, working through their own hospitals, clinics, or university-based interventions. Software engineers are hired as consultants to design the technology based on the dictates of healthcare professionals. Beyond the design stages of the diabetes IT, technicians or engineers may be brought onboard when technology issues arise, but they are not standing members of the program team. 19 Indeed, one commercial developer who collaborates with doctors on commercial health projects believes that healthcare professionals underestimate the complexity of software design and assume they are capable of doing the same work themselves. The technical functioning of diabetes IT is often taken for granted in public health interventions.
As a result of the limited role given to software experts, there is no continuous monitoring of technical implementation. Studies on diabetes IT rarely examine speed and frequency of data transfers. Regular monitoring of platform usage and connectivity issues is not consistently implemented, which means healthcare providers are slow to react to technical problems. 16,21 Unanticipated issues can lead to diabetes IT programs going over budget. 19 The technology generates a great deal of data on how it is being used, but without a software analyst to extract data on usage, a valuable source of information on process outcomes is lost. Instead, findings about technology performance appear to be taken from patient or provider satisfaction surveys completed after the program has concluded.
Diabetes IT programs also suffer from a lack of other expertise. In particular, there is an absence of professionals who focus on understanding end-users on their own terms. In IT companies, this role is typically played by people involved in business and marketing. Absent these perspectives, many healthcare providers commission technologies that present information in a didactic way. This form of messaging has limited potential with patients and providers alike. Growing evidence suggests that conventional methods of health education are ineffective at eliciting behavior change. One respondent, speaking about a doctor, noted, “… scientists are wonderful people. They are a hundred times smarter than me, personally…but sometimes their scientific ideas don't have a hard connection to the end-user.” It is not enough to tell people what they should be doing; health messaging must speak to patients' values, aspirations, and desires. 30 –32 This is more likely to be the foremost design objective when the development team is diverse.
Research
To be sure, healthcare providers conduct research on the implementation of their diabetes IT programming. However, the quality of the research is often poor. Most studies on diabetes IT neglect (or do not report) users' baseline understanding of diabetes and technology, critical variables in determining the appropriateness of a technology intervention and the likelihood of attrition. 24 Studies rarely consider potential confounders, such as whether the diabetes IT intervention constitutes a change in the level of usual care. 16,20 When IT is deployed in a healthcare setting, there is little preliminary research on how the technology will be incorporated into existing workflow. 10,14,33,34 The scale of research is smaller compared with commercial monitoring, with smaller study populations, shorter timeframes, and fewer outcomes of interest.
Moreover, healthcare providers involved in diabetes IT do not share commercial innovators' preoccupation with usage data. Very few studies used the technologies themselves as a source of data, beyond the data solicited directly from patients or providers. Usage data are not just critical for characterizing users; they are essential for identifying technical problems that frustrate users and cause attrition. For diabetes IT programs, such problems are often only identified during interviews or surveys of users that occur at the end of the intervention. Neglect of usage data may be a function of the limited expertise of the study team. Commercial development teams have the software engineers to derive usage data from technology and the marketing experts to interpret consumer motives behind every mouse click.
Institutional constraints
In drawing lessons from the commercial world, it is important to note that the healthcare professionals who design and implement diabetes IT interventions face constraints that make following these practices difficult. Most obviously, they lack the funds to invest in diverse personnel and relentless research efforts. For the most part, diabetes IT programs emerge from medical universities or nonprofit clinical settings, institutions that rely on grants of finite duration. As a result, projects are limited in what they can accomplish. Even when providers implement a project of limited scope, they can find themselves going over budget, especially on technical costs. 19
A second difference between the commercial world and the field of healthcare is the type of “product” each is selling. Using the Internet to network with friends, watch movies, or buy goods is likely more appealing to most than using it to manage a chronic disease. The former is a type of entertainment, and the latter is a service crucial for maintaining health. Success is about convincing potential consumers of the differences between the two and packaging the healthcare service so that it entices both patients and providers to use it.
A third constraint comes from the Health Insurance Portability and Accountability Act (HIPAA), which does not apply to most of the companies in our sample but does govern the research activities of healthcare professionals. Under HIPAA, human subject research is closely monitored by Institutional Review Boards (IRBs) that vet study designs prior to their implementation. Every variable under investigation must be justified to a regulatory body that approves all data collection tools. The process inadvertently places administrative hurdles in the way of research innovation and makes exploratory research difficult. 35
A fourth and related issue concerns the nature of the information traveling through IT-based media. Health status is a more sensitive line of inquiry than entertainment preferences. Self-reported information on diabetes management is likely to be subject to greater reporting bias. Netflix can prompt its members to rate movies on a regular basis without offense, but prompts about diet and exercise are more likely to elicit a defensive response that may affect the quality of reporting or participation in the program.
Recommendations
As the previous section suggests, the metaphor of commercial innovation can only be taken so far in the field of healthcare. When abstracting lessons from commercial practices, it is important to be aware of these issues and how they limit healthcare providers in program development and implementation.
Diversify the development team to the extent possible. With a limited set of funds, it is not possible to recruit and hire experts from the fields of engineering, statistics, business, and marketing. However, any attempt at diversifying the team responsible for designing and implementing the intervention may see significant gains. In particular, it is critical to prioritize the involvement of a software engineer in the development and implementation of the program. A software engineer will regularly monitor data transfers and identify and address problems before users experience them or they trigger costly repairs. Moreover, engineers can derive usage data to shed light on user preferences. In our sample, people with marketing analytics experience typically completed this data analysis. Absent such a person, a team of research-oriented healthcare professionals could undertake the same analysis, although it might not be as sophisticated.
Include more variables. There is no way for healthcare professionals to achieve the same level of study participation as commercial innovators, who do not have to adhere to the same recruitment constraints. Financial constraints impose limitations on the size and duration of research conducted in the field of healthcare, as well. Nevertheless, there are additional variables that should be included in data collection instruments that would contribute only marginally to overall cost. First, pre- and post-study questionnaires must include items that address overall understanding of diabetes, comfort with technology, and motivation to control diabetes. Second, usage data from IT platforms should be monitored on an ongoing basis to identify technical shortcomings when they occur and allow their immediate redress, improving process outcomes. Ongoing technical monitoring also enables user profiling, which can be used to improve the program interface, thereby promoting greater user satisfaction, lower rates of attrition, and fewer workarounds.
Pursue IRB exemption. The experience of commercial developers suggests that iterative technology development in response to ongoing user feedback is the most effective way of designing an IT product that appeals to customers. Ideally, usage data are interpreted, users are profiled, and prompts are modified to solicit greater feedback from different segments of the study population. However, HIPAA presents administrative hurdles to innovations in how IT programs are implemented. Under HIPAA, changing the intervention's interface based on data collected during the study is neither simple nor expeditious. Depending on the IRB and the type of amendment requested, an IRB amendment can take anywhere from 2 weeks to 2 months to review and approve. Given a lengthy wait time for amendment approvals, a small sample size, and a short study period, study design modifications will only muddy the theoretical link between the treatment and the outcomes of interest. It is no wonder then that so few healthcare professionals make such modifications.
Two potential solutions present themselves. First, it may be worthwhile to develop a product to completion before considering IRB-approved research. For the most part, diabetes IT is not experimental. IT is by and large a medium for conveying self-management support. Research conducted as part of normal clinical service delivery is not necessarily subject to IRB review. Standard monitoring and evaluation procedures, carried out as part of routine operational practice, are likely to be exempted under 45 CFR 46, the legislation that protects human research subjects. Conducting research in this way means that findings are used only internally, for the betterment of the program, and cannot be reported to the public. Once a successful prototype has been developed, a more rigorous study design can be put in place for IRB review.
A second strategy may be necessary when IRB exemption is not an available option. Sometimes institutional factors, such as funding and publication, demand IRB approval. In such cases, researchers should consider developing an IRB protocol that accommodates a more iterative design process. IRB protocols can be written with built-in provisions for modifying the IT based on specified parameters, such as revising a Web site to improve usability. Clearly defining what does or does not warrant an IRB amendment in the original protocol can help to mitigate impediments to the product development process.
Conclusions
IT is critical to the Chronic Care Model. Increasingly, clinicians involved in diabetes care are adopting IT platforms to facilitate ongoing disease management. In spite of a glut of pilot programs testing diabetes IT, most researchers are agnostic about the impact. Our research with commercial innovators suggests that many of the challenges faced by healthcare professionals could be surmounted if they adopted two practices: employ a program development team with diverse expertise and conduct rigorous research, including larger sample sizes, longer study periods, and more outcome variables. However, these practices are easier said than done for healthcare professionals who implement programming while negotiating substantial funding constraints, a cumbersome regulatory framework, and sensitivities around the disclosure of private information. Still, such practices can still be adopted, although to a lesser extent. Our recommendations for healthcare professionals interested in diabetes will help reduce technical glitches and improve usability for the diabetes IT user, ultimately helping to lower attrition and increase adherence to the intervention.
Footnotes
Acknowledgments
The authors would like to thank our editor, Annie Alley, for her assistance in preparing the manuscript. This project was supported by a grant from HCL Technologies. HCL did not participate in the design or conduct of the article, nor were they involved in the approval of the manuscript for publication.
Author Disclosure Statement
No competing financial interests exist.
