Integration of a Mobile-Integrated Therapy with Electronic Health Records: Lessons Learned

Abstract

Background:

Responses to the chronic disease epidemic have predominantly been standardized in their approach to date. Barriers to better health outcomes remain, and effective management requires patient-specific data and disease state knowledge be presented in methods that foster clinical decision-making and patient self-management.

Mobile technology provides a new platform for data collection and patient–provider communication. The mobile device represents a personalized platform that is available to the patient on a 24/7 basis. Mobile-integrated therapy (MIT) is the convergence of mobile technology, clinical and behavioral science, and scientifically validated clinical outcomes. In this article, we highlight the lessons learned from functional integration of a Food and Drug Administration-cleared type 2 diabetes MIT into the electronic health record (EHR) of a multiphysician practice within a large, urban, academic medical center.

Methods:

In-depth interviews were conducted with integration stakeholder groups: mobile and EHR software and information technology teams, clinical end users, project managers, and business analysts. Interviews were summarized and categorized into lessons learned using the Architecture for Integrated Mobility^® framework.

Results:

Findings from the diverse stakeholder group of a MIT–EHR integration project indicate that user workflow, software system persistence, environment configuration, device connectivity and security, organizational processes, and data exchange heuristics are key issues that must be addressed.

Conclusions:

Mobile-integrated therapy that integrates patient self-management data with medical record data provides the opportunity to understand the potential benefits of bidirectional data sharing and reporting that are most valuable in advancing better health and better care in a cost-effective way that is scalable for all chronic diseases.

Introduction

Chronic disease management is challenging for patients, for their health care providers, and for the health care system and payers who provide the infrastructure for care delivery. In 2012, spending on chronic disease in the United States represented 75% of the $2.7 trillion devoted to health care, and chronic diseases are responsible for 7 out of 10 deaths annually.¹

Effective chronic disease management requires that patient-specific data and disease state knowledge be presented to patients and providers using approaches that foster optimal clinical decisions and effective patient self-management. Standardized approaches to chronic disease management using frameworks such as the chronic care model² and the World Health Organization noncommunicable disease strategy³ have been implemented. These frameworks support an increasing role for patients and their social supports in the prevention and treatment of chronic diseases. Nonetheless, barriers to better health outcomes remain. Patients experience the burden of disease self-monitoring, limited support for chronic disease management outside the clinical setting, and short and infrequent office visits with the primary care provider. Providers lack complete, analyzed patient self-report data and ready access to relevant professional care guidelines. Finally, poorly organized paper charts, electronic health records (EHRs) that incompletely address chronic disease management, and lack of connectivity with patient-reported data are all challenges to the achievement of desired health outcomes.

Ubiquitous adoption of mobile technology throughout all population demographics, both nationally and internationally, has supported the evolution of a new platform for data collection and patient–provider communication.^4,5 The mobile phone is a personalized platform available on a 24/7 basis with the capability of providing real-time feedback (alerts and reminders as well as higher value messaging such as coaching and education), geo-location services, and other features, as well as being a flexible data-capture device. These capabilities have stimulated the development of over 18,000 mobile health (or mHealth) applications (through mid-2012)⁶ for mobile phone operating systems (e.g., iPhone, Android). These mHealth products range from health and wellness applications to comprehensive solutions used to manage specific diseases. A select group of these mHealth products are deemed “mobile medical devices,” as they fit the definition of a medical device and thus require clearance by the Food and Drug Administration (FDA)⁷ to ensure that the products are safe for their intended use.

Adoption of mHealth into the provider’s clinical and patient self-management workflows has led to the need for a further specialized category of mHealth known as mobile-integrated therapy (MIT). Mobile-integrated therapies are FDA-cleared mHealth products that also require a prescription from a provider and are deployed in a fully integrated commercial model. Further, MIT represents the convergence of mobile technology, clinical and behavioral science and scientifically validated clinical outcomes.⁸ Mobile-integrated therapy includes the elements listed in Table 1.

Table 1.

Mobile-Integrated Therapy Elements

Mobile device and/or Web portals for health care providers, patients, and caregivers Incorporation of evidence-based guidelines with team-based health care FDA-cleared, prescription only, indicated for use to support the management of a particular disease(s) Clinical and behavioral data collection, storage, and analysis Logging patient-entered data (e.g., food consumption, blood glucose values) Integral sensors (e.g., energy expenditure derived from global positioning system and accelerometer inputs in mobile phones) Interfaces to wearable or embedded sensors (e.g., continuous glucose monitor) Integrated behavioral and clinical content that serves as a foundation for evidence-based intervention design and delivery Automated, personalized, tailored, and contextual patient coaching that supports self-management of healthy behaviors, medication regimens, symptoms, and physiologic measures; coaching shall include both real-time and longitudinally based feedback messaging in response to data entered and analyzed; messaging is temporally tailored and delivered to the patient in an engaging manner Automated, patient-specific clinical decision support for providers that enhances adherence to evidence-based clinical guidelines and is presented in the format that best fits their workflow Outcomes reporting at a patient, population, provider, and program level Established processes for prescribing, training end users, and providing ongoing customer care and product support

In some instances, MIT may be developed as a solitary, comprehensive application. However, it also will be desirable for a MIT system to be capable of integrating modular sensor components as they are developed. For example, in the WellDoc system, users currently enter blood glucose values manually. However, as glucose sensing and recording devices evolve, it can be expected that glucose sensor data will be seamlessly ported into the MIT system. Likewise, as activity (energy expenditure) sensors are developed, the MIT system will have the capability of directly importing that data as well. Mobile-integrated therapy solutions also must address two additional implementation prerequisites: (1) human factors analysis, which is a precursor and necessary condition for FDA clearance, and (2) published clinical outcomes as a precursor to reimbursement via a suitable industry code.

The WellDoc diabetes Rx platform is the industry’s first, and currently only, solution to fulfill these characteristics. It is an FDA-cleared class II medical device for use by adults with type 2 diabetes. The WellDoc MIT system provides real-time, contextually relevant coaching and education. Feedback is tailored to patient treatment plans and to patient behavioral readiness to support lifestyle decisions and treatment plan adherence. Additionally, it provides physicians with clinical decision support to help them individualize and optimize treatment guidelines for patients. The WellDoc solution has been evaluated in two randomized controlled clinical trials and demonstrated statistically signifcant improvement in glycemic control in patients with type 2 diabetes compared with standard care.^9,10 It has also shown positive impact on health care utilization in a demonstration project.¹¹

The purpose of the analysis presented in this article was to obtain feedback on the functional integration of the WellDoc MIT solution with the Allscripts Enterprise^® EHR used in a multispecialty physician practice of a large, urban, academic medical center from the integration project stakeholders.

Methods

The WellDoc patient mobile and Web-based diabetes MIT was integrated with the Allscripts EHR to support bidirectional administrative and clinical data sharing between the two systems. The diabetes MIT supports the workflow of capturing the quantity and variety of inputs required for daily self-management (i.e., blood glucose, medications, blood pressure); as such, it is a good model of the potential benefits and barriers to functional integration for other chronic disease states.

Structured interviews were conducted with each stakeholder group over a 2-week period at the end of the development and software validation phases of the integration project. The interviewees included the mobile development and testing teams, the EHR software consultant group, the clinical practice information technology (IT) team, clinical end users, project managers, and business analysts. Each stakeholder group responded to structured and open-ended questions using in-person, telephonic, and electronic methods to facilitate the broadest participation. The interviews were summarized and categorized into “lessons learned” using a structured framework to ensure that human, technical, and organizational factors were comprehensively addressed.

We employed a two-step approach to obtain and synthesize lessons learned. First, we invoked Architecture for Integrated Mobility^® (AIM),¹² a mobile solution reference architecture that was developed as a model for defining the “layers” and best practices for integrating mobile-enabled solutions into mainstream management systems. Unlike models such as Open Systems Interconnect,¹³ which focus solely on the technical aspects of the solution, AIM takes a holistic, business, and consumer-centric approach to addressing all aspects of a technology-driven solution. Architecture for Integrated Mobility provided a set of eight layers within which lessons could be catalogued (Table 2). In the second step, we captured lessons learned for each layer in AIM through in-depth interviews with each stakeholder group. We invoked the Ishikawa method¹⁴ with its inherent flexibility to accommodate multidimensional inputs from diverse stakeholders to sense, cluster, and synthesize the common themes and the detailed lessons learned as applied to this integration project.

Table 2.

Architecture for Integrated Mobility Framework

Layer 1: Users	Stakeholders who use the system throughout the solution’s lifecycle
Layer 2: Application	The feature set and attributes of the software solution that is deployed
Layer 3: Environment	The physical, regulatory, and security elements of both the mobile and EHR software
Layer 4: Devices	The end user mobile Internet devices or hardware that are being used (e.g., cellphones, computers) to deliver the MIT solution and their unique attributes
Layer 5: Network connectivity	The properties of the interfaces that must be considered to ensure proper persistence, resilience, and availability to support integration
Layer 6: Services	Awareness, education, and training required to ensure maximum value to all users
Layer 7: Core integration	The data standards, data mapping, and application/systems/workflow integration
Layer 8: Operating model	The operating and business aspects of the project, including industry observations, cross-enterprise collaboration, and open innovation

Results

The key lessons learned are summarized here. The supporting observations about each layer are detailed in Table 3.

Table 3.

Lessons Learneda^a

AIM layer 1: Users	The integration of MITs into EHRs must carefully map all users with the functions and features of the application. Each user must be able to take actions within the integrated system in a way that best fits their personal day-to-day life and workflow.
Supporting material	Unlike the consumer-only applications obtained from, e.g., iTunes, Google Play, where the application user is usually the patient only, the stakeholders may include all levels of health care providers, patient’s support network, MIT application support (trainer, IT staff, EHR vendor, MIT vendor), and additional care team members. Actions that may be taken within the integrated MIT solution include patient and provider registration, production of clinical data (data logging, laboratory data interface, and sensor data transmission), clinical documentation, medication management (e.g., prescribing, reconciliation, monitoring), clinical data review and certification, care plan development and authorization, care plan execution, and quality assurance review. Each action should map to the users who are expected to participate in that specific action and should consider the following: Role equivalency: Does a provider’s role as defined in the MIT solution match the role in the integrated EHR environment? How is role equivalency achieved? For example, within the MIT, only a single primary care provider may be enabled with provider-class user rights, whereas the EHR permits multiple providers. Data display: Different user classes will require different data presentation formats, and effort must be made to understand the data needs of each user group. Workflow management: How should actions be configured to best adapt to current workflow protocols for different types of health care providers while incorporating the patient-centric care coordination that is being promoted through initiatives such as the patient-centered medical home15 and accountable care organizations?16 For example, during the MIT-EHR integration, we realized that medication reconciliation will be a major and, likely, a general problem of integration. The clinical decision support engine within a MIT will require a validated medication list; however, the structured medication list within an EHR may not be accurate or sufficiently detailed. For example, the structured medication list may not accurately detail a patient’s insulin regimen (e.g., insulin:carbohydrate ratio, correction bolus). While drug databases are fairly standard, EHR and MIT systems may not use the same database and/or same version of a common drug database. A common terminology across disparate databases, e.g., RxNorm, can make interoperability of medication lists easier; however, it requires that both the MIT and EHR systems be able to map uniquely to the terminology. Hence specific workflows may need to be developed to ensure that the MIT has an accurate medication list. Modeling these workflows is crucial to ensuring accuracy in medication management between the MIT and EHR.
AIM layer 2: Application	MIT should be designed in an open, interoperable fashion to accommodate integration of many MITs into the same EHR environment.
Supporting material	Prior to integration, it is imperative to capture dependencies from other MITs and the inherent features within the EHR. Which data fields will be duplicated, and which will be required as the “trusted source” by other applications? Understanding the different requirements around the view and use of data across the MIT and EHR systems is critical to supporting how data from the MIT is made available/updated in the EHR system. Most MIT solutions tend to be designed from the patient perspective, whereas EHRs are architected for the provider. Therefore, MITs that are integrated into the EHR environment must be analyzed to ensure that duplicate or even conflicting efforts/entries on the part of the patient and provider are not permitted.
AIM layer 3: Environment	The configuration of multiple operating environments for the integrated MIT-EHR system is critical. Data continuity, integrity, HIPAA-compliant security, and end user liability are considered in this layer and should be embedded within the MIT application.
Supporting material	The environment includes the physical and logical configuration of infrastructure, software, and security mechanisms. By virtue of the electronic nature of the EHR, data and network connectivity is assumed. To ensure data continuity and integrity between multiple systems, data security best practices, which include demilitarized zones, redundancy, geo-failover, and recovery, are employed to manage exceptions such as crashes and platform malfunction.17 Data entered into or collected by the mobile devices are stored on the central servers from which it can be retrieved in the event of a mobile device failure. Also, a security architecture allowing secure and HIPAA-compliant sharing of PHI should be embedded within the MIT application. In certain environments, legal terms and conditions are also important, such as those that outline any liability for the end user. Such considerations are contemplated in this layer and often require organizational and legal review. Many issues were uncovered during the scoping, installation, provisioning, and acceptance activities. Infrastructure Firewalls on both ends should be compatible. We experienced many difficulties in configuration due to inherent variations between different manufacturers’ networking equipment. Capacity, reliability, and availability of servers should be assessed to ensure that interfaces do not shut down with dynamic and variable volumes of data traffic. Configuration and management Staging and production environments should be identical in order to isolate and restrict troubleshooting to application-related issues. In many cases, secure sockets layer certificates were not replicated in both environments, causing issues in the production environment. Trusted third-party, rather than self-signed, certificates should be used for authentication. The purpose of a self-signed certificate is to replicate a secure means of communication in local/development environments; it should not be used in the production environment. Setting up the production environment is a long-lead-time item and should be completed early enough so as not to become critical path. Also, there should be advanced planning for anticipated new releases of critical software components. In our case, preproduction testing was done on a version of the EHR software that was scheduled for upgrade at approximately the same time as the production release of the WellDoc MIT-Allscripts Enterprise interfaces. The release of the new EHR version then necessitated retesting of the interfaces. Security must be “built-in.” In order to comply with PHI and HIPAA policy, proper encryption (e.g., National Institute of Standards and Technology-certified AES-256) techniques on devices, on the link, and on the servers is required. Token-based authentication can then establish and manage a data connection between the MIT device and the EHR securely. The MIT solution should be an inherently secure application, therefore simplifying the VPN architecture between the cloud-side of the MIT solution and the EHR (as opposed to trying to extend the VPN to the mobile client side).
AIM layer 4: Devices	The integration of MITs and EHRs must seamlessly accommodate multiple mobile Internet devices, operating systems, user interfaces, physical characteristics (e.g., screen resolution), and secure over-the-air provisioning such that revision control can be effectively managed.
Supporting material	There are two alternative architectures to leverage when implementing any mobile solution:18 one that takes advantage of the native operating system capabilities (e.g., iOS, Android, Windows) and the other that implements Web-based solutions (e.g., HTML5). The former is typically employed when user engagement is required, the latter when transaction efficiency is the goal. In the realm of mobile health, driving and sustaining patient engagement is critical, and therefore the former architecture is preferred. However, this implementation does not come without its challenges: Multiple code bases must be maintained for each mobile operating system. Therefore, common-domain, logic-driven design should be employed when developing the MIT solution, such that the maximum amount of code (at the data layer, logic layer, and user interface layers) is common across multiple operating systems. Within a given operating system, different mobile devices may have different resolutions. To optimize user experience and to avoid “stretchy” or “compressed” images and text due to pixelation, it is helpful to refactor each “code build” to ensure that the MIT is available in different screen resolutions to match the resolutions of the many devices available. This problem is particularly inherent to Android OS phones and Java (J2ME) phones; it is less an issue when it comes to iOS since there are only two resolutions in this entire platform. Patients will prefer to use their current mobile device to access the MIT solution as well as their usual applications compared with using a separate mobile device for the MIT. Therefore, the MIT solution must be available on many phone models. Also, a procedure must be established to certify new mobile devices and associated operating systems as compatible with the MIT soon afiter these devices are marketed.
AIM layer 5: Network connectivity	In order to accommodate the connectivity restrictions imposed by most health care environments, the MIT must function in multiple connectivity modalities such as “always connected,” “periodically connected,” and “sparsely connected.” However, due to the narrow-band nature of the data layer associated with many MITs, the need for network resources (e.g., spectrum, bandwidth) is not generally a limiting factor.
Supporting material	Wireless network coverage in many hospitals and care facilities is poor due to the nature of the construction of such facilities (lead-lined exam rooms, high volume of interior walls) and the fear of cellular interference with key medical equipment and diagnostic devices. Therefore, in the absence of distributed antenna systems or other in-building wireless systems,18 MITs are best architected to operate in hybrid client-cloud mode. That is, the MIT solution must perform its basic functions (e.g., patient coaching and feedback) in both offline and online modes. Offline operation capability adds complexity to coding, securing, and testing the mobile application but serves the higher-level purpose of ensuring application persistence in multiple environments.
AIM layer 6: Services	Awareness, education, training, and customer support are required to maximize the value of the MIT-EHR integration for all users.
Supporting material	At this stage of the project, we are preparing the resources and processes to implement the integrated solution in a clinical trial. We will report these findings in a future paper. Ideally, using the system is highly intuitive for both patients and providers; however, past experience has indicated that users need orientation to the product features and, depending on their technology sophistication, may need additional “getting started” training. Ongoing customer support, well-trained in the use of the technology, is vital for success. Future lessons learned in this domain will inform industry best approaches that can include face-to-face training, computer-based training, and self-directed training.
AIM layer 7: Core integration	Successful integration of the MIT with an EHR requires adherence to interoperability standard(s) and mapping of customized interface specifications.
Supporting material	Interchange standard: It is not sufficient to declare that MIT-EHR integration will adhere to a data interchange standard such as HL7. In order for an EHR and MIT to share data, both systems must adhere to a set of rules that define common data formats and behavior. While EHRs have some commonality, for the most part, adherence to these standards is a new domain space for MITs. Thus the mapping between data fields in the MIT and the EHR; the rules behind data integration (e.g., resolution of conflicts between different data sources); and the ongoing management, cleansing, and maintenance of these different data sources must also be detailed. Additionally, different EHRs may not adhere to HL7 standards in the same way. A MIT may need to be customized for each individual EHR for data exchange to occur. Mapping data objects: It is important to ensure that results in the MIT and EHR be mapped to each other correctly. For example, blood glucose in the MIT generally refers to a capillary blood glucose measurement performed by the patient, whereas blood glucose in the EHR may be a serum glucose measured by a central laboratory. The two systems require common terminology with common coded values in order to correctly map the data each system collects. Furthermore, integration of self-reported and system-generated data is a challenge in terms of display and interpretation of these different data sources. Key to successful data exchange is identifcation of a single, trusted source of truth when multiple sources exist that can be updated at varying frequencies. In this case, the introduction of data from the mobile device provides an advantage in that the data are logically connected to the patient and are the most up-to-date and transportable. Therefore, it is critical to establish temporal and truth rules for data exchange between the mobile and EHR. Currently, most, if not all, EHRs do not have the capability to capture real-time, patient-sourced data. Data storage location: The EHR generally is not structured to store data generated in real time by patients, such as patient-logged capillary blood glucose or data streaming from sensors or mobile devices. Hence, data storage must be distributed between the MIT and the EHR. Workflow integration: It is important to evaluate not only the new workflows that arise from MIT-EHR integration, but also, and more importantly, the effect on existing workflow. For example, the MIT’s patient registration process had a workflow and data capture sequence quite different from that in the EHR.
AIM layer 8: Operating model	In order achieve program objectives with the optimum levels of cycle-time performance, cost, and quality, an interdisciplinary, cross-enterprise development model should be employed.
	Integration of two emerging and nascent platforms is always more complex than forecast. Cross-enterprise collaboration should include a cross-functional steering committee to assign resources, resolve issues, and own success; a cross-functional core team execute the project successfully; visibility into program success, obstacles, and corrective measures via a program scorecard; and frequent and structured cross-enterprise communication. Plans must include provisions for backup resources that can “step in” when needed. A spiral development process allows for multiple, iterative “sprints” and successive integration enhancements and is more favorable than a linear, “waterfall” model that tries to define the total realm of integration requirements prior to development. During intense project periods (e.g., requirements sign-off, testing, and acceptance) the frequency of communication among development team members should increase.

^aPHI, protected health information; VPN, virtual private network; HL7, Health Level 7.

Layer 1: Users

The integration of MITs into EHRs must carefully map all users with the functions and features of the applications. Each user must be able to take actions within the integrated system in a manner that best fits personal day-to-day life and clinical or business workflow.

Layer 2: Application

The MIT should be designed in an open, interoperable fashion to accommodate the integration of many MITs into the same EHR environment.

Layer 3: Environment

The configuration of multiple operating environments for the integrated MIT–EHR system is critical. Data continuity, integrity, and Health Insurance Portability and Accountability Act (HIPAA)-compliant security, and end user liability are considered in this layer.

Layer 4: Devices

The integration of MITs and EHRs must seamlessly accommodate multiple mobile devices, operating systems, user interfaces, and physical characteristics (e.g., screen resolution) and enable secure over-the-air provisioning so that revision control can be effectively managed.

Layer 5: Network Connectivity

In order to accommodate connectivity constraints and limitations imposed by most health care environments, the MIT must function in multiple connectivity modalities such as “always connected,” “periodically connected,” and “sparsely connected.” However, due to the narrow-band nature of the data layer associated with many MITs, the need for extensive network resources (e.g., spectrum, bandwidth) is not generally a limiting factor.

Layer 6: Supporting Services

Awareness, education, training, and customer support are required to maximize the value of the MIT–EHR integration for all users.

Layer 7: Core Integration

Successful integration of the MIT with an EHR requires adherence to interoperability standard(s) and mapping of customized interface specifications.

Layer 8: Operating Model

An interdisciplinary, cross-enterprise development model should be employed in order to achieve program objectives with the optimum levels of cycle-time performance, cost, and quality.

Discussion

Health care applications for wireless communication platforms have proliferated greatly. These applications are generally patient centric and problem or disease specific. They may collect or log data in real time; but as personal applications, they generally lack the capability of further interacting with care providers. Additionally, simply transmitting raw data from patients to physicians does not lead to benefits in health or economic outcomes.¹⁹

In addition, in the absence of clinical testing and FDA clearance, their functions may be limited to record keeping and general supportive coaching rather than more specific, individual therapeutic recommendations. In contrast, MIT combines patient-oriented interfaces with provider-oriented interfaces while sharing data analysis, feedback, and decision support that enable patient self-management in coordination with the physician treatment. Within the context of a MIT system, data collected through the integrated system inform targeted behavioral coaching that prompts the patient to initiate and/or maintain self-care behaviors that support their individual treatment plans and enhance their quality of life. For the patient, benefits of this integration may include improved treatment adherence, frequent reinforcement of treatment goals in between scheduled provider visits, improved understanding of the impact of behavior on disease control, as well as access to educational resources and specific reminders about standards of care. The unique contribution of MIT for patient self-management is the ability to integrate the tailored behavioral support in the context of their unique clinical treatment plan and provide messaging at the contextually and temporally relevant moment to infuence their daily decision making.²⁰ For the provider, the benefits may include improved outcomes, achievement of quality standards of care, improved medication prescribing, greater efciency, and increased patient satisfaction.

In this article, we have highlighted key “lessons learned” from the integration of a MIT system for management of type 2 diabetes with an EHR. Using diabetes as a model for integrating patient self-management data with medical record data provides the opportunity to understand the potential benefits of bidirectional data sharing and reporting that are most valuable in advancing better health and better care in a cost-effective fashion and that are generalizable to other chronic diseases. Potential advantages of this integration and bidirectional communications capability include the following:

• •Time to review a patient’s chart will be reduced, and a more accurate clinical evaluation will be enabled. The MIT solution’s data presented within the EHR environment are more organized and do not rely on the patient presenting incomplete, paper-based records or logbooks. Accuracy is increased, and context for patient self-reported data is available. Provided with a more robust picture of the patient’s status over time, the effectiveness of a short office visit with a patient increases.
• •MIT–EHR-integrated tools provide a longitudinal view of chronic disease progression, the actions of the patient over time, and the efficacy of the plan of care between visits. Also, MIT–EHR may result in the generation of meaningful discussion points based on issues derived from patient self-reported data.
• •Clinical visits may become productive because patient-generated data that are not consistently available during a visit (e.g., patient frequently forgets to bring their blood glucose meter or logbook) would be available within the EHR, and more importantly, the data will have already been analyzed and translated into patient-level decision support.
• •Comprehensive data are available for quality review and quality assurance and can support programmatic outcomes reporting.

We have identified several issues that are likely to be common to most MIT–EHR integration programs: users, workflow, and data. Many different user classes will have access to the MIT. These different classes of users will have different requirements for system rights, data entry, display, and so forth. During the planning and initial stages of the integration project, it is important that all potential user groups be involved. Hence, a multispecialty development team is required. Also, systems integration should be closely coupled to analysis and review of workflow. In order to obtain maximum support from the different users and to simplify training, integrated system workflow should follow the current procedures or, ideally, be simplified (i.e., reduced time and effort to complete tasks within the integrated system). Finally, integration will bring together data derived from different sources and with different levels of reliability. It is necessary to distinguish the source of origin of similar data (e.g., self-monitored capillary glucose, serum glucose, and continuous monitor glucose value) and establish the “source of truth” rules for bidirectional data exchange.

A clinical study is in progress to evaluate the impact of integrating patient mobile diabetes solution with the provider EHR by measuring the impact on health, care quality, and costs. This study will provide information on how interfacing of patient self-reported data and clinical data can work to deliver both real-time feedback and longitudinal coaching to patients and clinical decision support to providers—and how that will impact diabetes care metrics. Additionally, parallel activities that anticipate the national electronic record initiatives for the Health Information Technology for Economic and Clinical Health Meaningful Use rules will be incorporated.²¹

Conclusions

These lessons learned will help accelerate the integration of mobile-integrated therapies into electronic medical records, which may improve the quality and costs associated with treating chronic diseases in the United States along with other clinical, health system, and policy innovations. As MIT and EHR solutions mature, standard configurations and “recipes” for different levels of integration (e.g., data integration only, systems and application integration, workflow integration), hopefully, will be developed. Finally, we expect that this summary of initial lessons learned will help create models for the health industry to leverage in future mobile and IT innovations.

Glossary

(AHI)

apnea/hypopnea index

(AIM)

Architecture for Integrated Mobility

(EHR)

electronic health record

(FDA)

Food and Drug Administration

(HIPAA)

Health Insurance Portability and Accountability Act

(IT)

information technology

(MIT)

mobile-integrated therapy

Funding

This project is supported through United States Congressional funding with administrative oversight by Air Force Medical Support Agency/Medical Modernization and Innovations. This material is based upon work supported by the 773 ESS/PK, contract number FA17014-10-C-0031. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily refect the views of the 773 ESS/PK.

Disclosures

Anand K. Iyer and Malinda M. Peeples are employees and equity holders of WellDoc. Joshua L. Cohen has received honoraria from WellDoc.

Acknowledgments

The technical work was completed by Enterprise Human Resources Integration; the George Washington University Medical Faculty Associates Information Technology Department; and WellDoc analysis, IT, and operations teams. Special thanks to Thomas Antony (WellDoc) and Anthony Nuzzo (EHR Intergration Sevices) for project management and to Marcella Maamari, Vandana Toteja, and Nikol Reyes (George Washington University Medical Faculty Associates) for their IT support.