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.