A Standards-Based Architecture Proposal for Integrating Patient mHealth Apps to Electronic Health Record Systems

Summary

Background

Mobile health Applications (mHealth Apps) are opening the way to patients’ responsible and active involvement with their own healthcare management. However, apart from Apps allowing patient’s access to their electronic health records (EHRs), mHealth Apps are currently developed as dedicated “island systems”.

Objective

Although much work has been done on patient’s access to EHRs, transfer of information from mHealth Apps to EHR systems is still low. This study proposes a standards-based architecture that can be adopted by mHealth Apps to exchange information with EHRs to support better quality of care.

Methods

Following the definition of requirements for the EHR/mHealth App information exchange recently proposed, and after reviewing current standards, we designed the architecture for EHR/mHealth App integration. Then, as a case study, we modeled a system based on the proposed architecture aimed to support home monitoring for congestive heart failure patients. We simulated such process using, on the EHR side, OpenMRS, an open source longitudinal EHR and, on the mHealth App side, the iOS platform.

Results

The integration architecture was based on the bi-directional exchange of standard documents (clinical document architecture rel2 – CDA2). In the process, the clinician “prescribes” the home monitoring procedures by creating a CDA2 prescription in the EHR that is sent, encrypted and de-identified, to the mHealth App to create the monitoring calendar. At the scheduled time, the App alerts the patient to start the monitoring. After the measurements are done, the App generates a structured CDA2-compliant monitoring report and sends it to the EHR, thus avoiding local storage.

Conclusions

The proposed architecture, even if validated only in a simulation environment, represents a step forward in the integration of personal mHealth Apps into the larger health-IT ecosystem, allowing the bi-directional data exchange between patients and healthcare professionals, supporting the patient’s engagement in self-management and self-care.

1. Introduction

Mobile personal health applications (mHealth Apps) are entering the everyday behavior of patients and populations as support for care management, health information, wellness maintenance, and personal monitoring. The increasing trend of personal mobile devices (smartphone and tablets) worldwide together with the growing number of applications available in stores under the “medicine”, “health”, and “wellness” categories are predictive of an even larger use of these technologies in the next years [1]. Different studies highlighted the potential of mHealth Apps to optimize patient’s self-management [2–8] and the advantage of mHealth Apps over traditional computer-based tools and telehealth [2, 3] especially in groups with low socioeconomic status [4]. However, the quality of mHealth Apps [9, 10] as well as their poor integration with other available healthcare information systems [11] make the mHealth App world far from being fully successful.

Ranging from information/education portals to monitoring systems and even mobile PHRs, mHealth Apps produce health information that is potentially relevant for patient’s assessment, progression, monitoring, and early detection of diseases, as well as healthy behavior tracking. Physiological monitoring of data and signals, therapy administration logs, and activity diaries are examples of the information that can be collected through available mHealth Apps.

At present, mHealth Apps are usually developed as stand-alone systems that may communicate with healthcare professionals through dedicated channels (e.g. ad-hoc developed Web platforms) or e-mail. This solution, however, despite allowing healthcare professionals to view and evaluate the data collected, creates a new set of “information silos”. Patient’s information is stored either on personal mobile devices or on Web platforms but it is not integrated with the patient’s health record. The full view on the patient’s health pathway has to be reconstructed by retrieving data and information from different systems. Also, healthcare professionals often need to re-enter patient’s clinical information into dedicated Web platforms, thus replicating existing digital data.

Conversely, the inclusion of the information coming from mHealth Apps in the patient’s record would facilitate monitoring, assessment, and decision-making, thus ultimately optimizing patient’s care.

This is in line with the concept of electronic health information exchange (HIE) that, according to healthIT.gov “allows doctors, nurses, pharmacists, other health care providers and patients to appropriately access and securely share a patient’s vital medical information electronically—improving the speed, quality, safety and cost of patient care” (http://www.healthit.gov/providers-professionals/health-information-exchange/what-hie). HIE envisages the creation of a “health IT ecosystem” in which data are securely exchanged among providers, patients can access their healthcare documents, and clinical research benefits of the aggregated data collected in the clinical setting [12,13]. The inclusion of mHealth Apps in the HIE perspective would open the way to individual patient’s contribution to their own health record, thus allowing a two-way exchange from professional health information systems to patient-managed digital health/wellness systems.

At present, available standards and recommendations already describe document exchange for both electronic health records (EHRs) and personal health records (PHRs). Current policies boost cross-institutional EHR interoperability to allow data sharing [14,15] and standards provide the specifications for EHR/EHR communication [16]. PHRs, representing the life-long collection of health-related documents managed by the patients themselves [17] have a history of oscillatory success [18,19]: the perceived “unreliability” of patient-managed data included in PHRs have been one of the main drawbacks [20] since initiatives like the Blue Button [21] provided a way for patients to access their EHRs and download clinical documents. Following previous suggestions of patient’s accessible EHRs [22], the Integrating the Healthcare (IHE). IHE Patient Care Coordination (PCC) Technical Framework now includes the XPHR profile that describes the integration scenario for the PHR/EHR exchange of content [23]. However, this scenario does not include mHealth Apps and still leaves partially undefined the “upload” of data coming from patient-managed systems to the EHR.

All these observations claim for the need of feasible architectures, describing the “anatomy” and the “physiology” of systems managing the exchange of information between mHealth Apps and EHRs. Here we propose a standards-based architecture that may be adopted by mHealth App developer and EHR providers to facilitate the bi-directional exchange of information between these two IT systems that represent the everyday practice for patients (mHealth Apps) and for healthcare professionals (EHRs).

2. Methods

2.1 Conceptual framework for the integration

The architecture is based on the functional requirements for the bi-directional exchange of information between EHRs and consumer health informatics applications recently defined in [11]:

• R1. The exchange of faithful information. As described in the ISO 13606 standard regarding healthcare information exchange [16], this requirement implies preserving the original meaning intended by the author.

• R2. Data protection. This includes Confidentiality (access protection), Integrity (maintenance of data accuracy), Availability (data accessible upon demand), Accountability (responsibility on data content) and Disaster Recovery [24,25]. It should be noted that mobile devices are unsafe environments, thus enhancing the importance of data protection.

• R3. Interoperability. Enabling data exchange, interoperability is important to ensure flexibility, according to the “not-one-fit-all” concept [12,22,26]. This includes at least technological interoperability (e.g., standard communication architectures), and semantic interoperability (e.g., shared terminologies/ontologies).

• R4. Patient education. In the mHealth App domain, patients are the main participants involved in the generation and maintenance of health-related information. It is therefore essential to both enhance their “health literacy” [27,28] and to create a “culture of custodianship” [22] related to the nature of personal health information.

• R5. Research and evidence-based practice. As previously shown for patient-accessible EHRs [22], it is important to provide evidence of the benefits and limitations of the approach thus prompting further research aimed at optimizing the integration environment and architecture.

These requirements are fulfilled by the implementation of specific building blocks [11]:

• B1. The Concept Translator block that implements the technical solution to take into account the “health literacy” issue.

• B2. The Security Tools block is needed to ensure authorized access to the EHR system.

• B3. Standard Document and Communication Architectures to ensure interoperability.

• B4. The Educational Tools block to provide qualified information sources for both patients and clinicians.

• B5. The Feedback System to collect user’s experience and feedback on the system use.

The architecture also has to satisfy a set of non-functional requirements (e.g., quality attributes) constraining the design as a whole, as described in Table 1. The evaluation of the quality attributes at the architectural level followed a scenario-based approach [29], in which a set of scenarios is defined to represent the quality attribute (►Table 1). The changes required by the architecture to satisfy each scenario were used to evaluate the architecture design.

Table 1.

Non-functional requirements and evaluation scenarios

NON-FUNCTIONAL REQUIREMENT	DEFINITION	EVALUATION SCENARIOS
Development NFRs
Maintainability	Ability of the architecture to support the changes needed by the software in the case if changing requirements	S1.1 – Introduction of a new OS version for the mHealth App
		S1.2 – Update of the current version of the EHR system
		S1.3 – Introduction of a new data protection rule
		S1.4 – Introduction of new health information exchange standard versions
Flexibility	Ability of the architecture to support the development of new software solution for a different case study	S2.1 – mHealth App developed for a different OS
		S2.2 – Introduction of a new EHR system
		S2.3 – Development of a mHealth App for monitoring a different pathology
Scalability	Reliability of the architecture in a changed workload	S3.1 – Increased number of monitored patients (multiple access)
		S3.2 – Increased complexity of the parameters to be reported to the EHR
Operational NFRs
Reliability	Ability of the architecture to ensure the transmission of reliable data	S4.1 – Creation of a duplicate patient on the EHR side (same patient with two different patient IDs)
Fault-tolerance	Ability of the architecture to resist to system failures	S5.1 – Lack of internet connection on the mHealth App side
		S5.2 – Access system failure on the EHR side

To design the standard-based architecture that implemented these requirements and building blocks, we first reviewed the current literature and the available standards, guidelines, and recommendations regarding health information exchange, to define the present available and applicable technical solutions. The information sources were PubMed for journal papers, the International Standard Organization (ISO) with particular reference to the Technical Committee devoted to Health Informatics (ISO/TC 215), the Food and Drug Administration (FDA), the Health Level 7 (HL7) initiative, and the Integrating the Healthcare Enterprise (IHE) initiative.

2.2 Case study process modeling

As a case study for validating the proposed architecture, we considered the process of home monitoring for patients at risk of congestive heart failure. The process was modeled through the Unified Modeling Language (UML), according to an activity-centric approach that focused on the activities executed by different components with available resources. Using a top-down strategy, the modeling started from the definition of the process metamodel that was then refined to include more details. The metamodel was developed using the UML activity and use-case diagrams. According to the best practices for healthcare process modeling, the model was developed involving domain experts [30].

Then, UML was used to create the specifications of the system implementing our proposed architecture in the specific case study. The reference class diagram representing the classes and methods needed for the integration as well as the sequence diagrams describing the behavior of the system were designed.

2.3 Proof of concept

To simulate the integration environment, we developed a prototype based, for the EHR side, on OpenMRS (www.openmrs.org), an open-access EHR system originally designed for developing countries, and, for the mHealth App side, on a mobile application implemented for the iOS environment.

On the EHR side, OpenMRS provided the basic tools for the creation of a longitudinal EHR that follows the patient’s care pathway collecting all the interactions during clinic visits, exams, diagnoses, and therapies [31–33]. OpenMRS has a big collaborative development and implementation community that makes available to all OpenMRS users all the forms and modules developed/implemented for each single OpenMRS application, thus sharing source code and experience, and facilitating the implementation of new OpenMRS setups. OpenMRS is based on a modular architecture grounded on a common information model with entities: person, patient, encounter, observation, user, form, concept, order, and group. Each patient/user is a person. The patient is followed horizontally in a series of encounters in which observations are recorded. A concept dictionary is used to semantically map all the information stored in OpenMRS.

Patient’s data in OpenMRS are collected through forms. Forms can be developed in HTML to answer specific recording needs, provided that all the information collected is mapped in the concept dictionary. Additional functionalities to OpenMRS are included through modules.

The OpenMRS Standalone version was used for the simulation, and customized to (1) include in the concept dictionary all the concepts (and their SNOMED-CT and LOINC mappings) needed for the simulation, (2) create the forms for the management of congestive heart failure patients, and (3) implement the document exchange with the mHealth App using the available REST services.

On the patient side, the mHealth App prototype was developed using XCode 6.0 and designed to run on all Apple devices. The App was designed following the classical model-view-controller (MVC) approach. The development process started from the definition of the interface, with the mock-ups reviewed by domain experts and updated accordingly. The data model was implemented in SQLite according to the specified UML class diagram. The App was designed to collect and manage monitoring information and medication information.

3 Results

3.1 The standards-based architecture

By reviewing the current norms, standards, and recommendations available both at the European, US, and, in general, international levels regarding health information exchange in the light of the available EHR functional models (as defined by the HL7 RIM, the ISO/HL7 10871 norm, and the OpenEHR initiative), we identified four main health information exchange categories represented: the EHR-EHR data exchange within the same institution, the EHR-EHR data cross-institutional exchange, the EHR-PHR exchange, and the EHR-Clinical Report Form (CRF) exchange. The ISO 13606 [16] family provided the general framework for EHR-EHR communication, including the reference model (part 1), the specification of semantic archetypes for semantic interoperability, data consistency and data quality (part 2 and 3), the management of security issues (part 4), and the interface specifications (part 5). HL7 version 3 and IHE integration profiles provided the specifications for the implementation of the communication architecture. Healthcare data and information are exchanged either using standard messages (HL7-based) or using structured documents (HL7 Clinical Document Architecture, release 2, CDA-2). For example, some CDA-2 implementation guides ground the exchange of structured documents between PHRs (PHR-PHR exchange) and between CRFs (CRF-CRF exchange). ►Figure 1 shows the available standards and integration profiles for the communication between EHRs, PHRs, and CRFs.

Fig. 1.

Integration profiles and exchange standards between EHRs, PHRs, and CRFs.

Even though none of the available standards considers mHealth Apps as an information source for clinical information or documents, the review showed that the standard information exchange between health documental systems is always mediated by structured standard clinical document (CDA-2 documents). For this reason, we designed our architecture based on the same principle (►Figure 2).

Fig. 2.

General Architecture of the information exchange between the personal mHealth App and the EHR system. A- EHR system side. B- mHealth App side.

As represented in ►Figure 2, the connection between the EHR side and the mHealth App side is implemented by the exchange of encrypted XML-based CDA-2 structured documents. The document sent from the EHR to the mHealth App could be broadly defined as a “prescription”, representing an indication of action that comes from the clinician and it is direct to the patient (e.g., monitoring action, rehabilitation exercise, medication regimen, nutritional advice, etc.). The content of the prescription depends on the specific patient’s condition. The prescription is generated as a structured clinical document in the EHR (►Figure 2A) using the standard terminology implemented in the EHR, and it is uploaded in the EHR system clinical data repository. The structured CDA document to be sent to the patient is then created starting from the original prescription that is “translated” for patients understanding using UMLS mapping to the Consumer Health Vocabulary (CHV). The document must contain only the patient identification number and not the patient’s demographic information that are stored in the demographic data repository on the EHR side. After encryption, the document is sent by the EHR and then received by the mHealth App (►Figure 2B) that sets the appropriate actions (e.g., medication/monitoring remainders, rehabilitation exercises to be presented to the patient, etc.). The patient, using the App, generates monitoring information that can be either logging data (e.g., medication compliance tracking) or data/signals coming from monitoring devices. Whatever the information type, the mHealth App, generates, encrypts and sends to the EHR a structured CDA-2 “monitoring report”, with appropriate header, metadata, and content, but without any patient identification information. Also, the App should not store in the device memory the information generated and sent. Once the “monitoring report” is received by the EHR (►Figure 2A), it should not be stored within the clinical data repository, but it should be sent to a dedicated repository (Monitoring Data Repository in ►Figure 2A) that can be managed according to the Cross-Enterprise Document Sharing (XDS) IHE profile for information retrieval.

►Table 2 reports the present standards that can be used, after proper adaptation, to implement this architecture.

Table 2.

Standards identified as useful for the architecture implementation.

Available standard	Use	Adaptation required
Experimental CDA2 – Personal Healthcare Monitoring Report (PHMR)	To represent monitoring data coming from devices	Manage de-identification
IHE profile Patient Care Coordination – XPHR	To define the basic transactions between EHR and mobile App	Change from PHR to mHealth AppManage document upload from mHealth to EHR
IHE IT Infrastructure profile – XDS	To define the basic document exchange transactions	Include prescriptions and monitoring data
ISO 13606–4	Security management	Consider that the device is an unsafe environment
ISO 13606–2 and –3OpenEHR archetypes	Manage semantic interoperability	Define concepts suitable for the patient side
Blue Button Transform (U.S. Realm)	Transform CDA2 documents in ASCII text for use on mobile	Depends on the final structure of the document exchanged

The architectural design is essentially based on the service oriented architecture (SOA) approach, since the two sides of the communication implement specific services aimed to create, read, and exchange the XML-based CDA-2 structured documents. This makes the architecture independent from the systems on which it is implemented, thus ensuring the satisfaction of some quality attributes. In fact, any change or update of either the mHealth App operating system, or the EHR system (evaluation scenarios S1.1, S1.2, S2.1, S2.2, ►Table 1), or even the development of a mHealth App to treat or monitor a new pathology (S2.3, ►Table 1) do not affect the integration architecture per se, but the systems exposing the services. Conversely, the introduction of, for instance, a new data protection rule (S1.3, ►Table 1) may require a transformation of the architecture, at least for what regards data de-identification. In case of the introduction of new versions of the standards here considered, the services exposed by the two sides will require re-design. The architecture scalability as represented in S3.1 and S3.2 (►Table 1) mainly depends on the performances of the EHR system (S3.1) and on the speed of the mHealth App in creating the standard documents and managing its complexity (S3.2). This implies that the service implementation (and not the architecture per se) needs to take into account these quality attributes to be optimized. The architecture, as it is, cannot manage the case described in S4.1 (►Table 1), because it is based on the assumption that the patient ID is unique, and univocally identifies the de-identified data once they are sent to the EHR. Hence, if the patient is erroneously assigned to two different IDs, the architecture will not be able to merge them. Finally, the fault-tolerance (S5.1 and S5.2, ►Table 1) depends on the time window required by the specific clinical application. In non-urgent clinical conditions (such as home monitoring for chronic conditions), the mHealth App can wait to send the monitoring report when the device is connected to the Internet (S5.1) or when the access to the EHR is recovered (S5.2), and temporarily save the encrypted file. In other conditions, where the timing is an essential requirement (such as monitoring high-risk patients), a failure in the network connection implies a lack of responsiveness.

3.2 Case study process modeling

To provide a proof of concept of the architecture described, we considered the process of home monitoring of patients at risk of congestive heart failure. As shown in ►Figure 3, the process starts with the patient admission for an acute episode. After proper management of the acute episode, the clinician prescribes patient’s monitoring at home and patient’s home therapy using the institutional EHR system. The prescription, including both the monitoring and the medication instructions, is sent to the patient’s mHealth App. After receiving the prescription, the App creates the monitoring and medication calendar accordingly. At the scheduled time, the App prompts an alert to the patient to do an action (start the monitoring session or take the medication). The action produces a result (the medication administration log or the result of the monitoring) that generates a report. The report is sent back directly to the institutional EHR where is connected, through the patient’s ID, to the patient’s EHR. The clinician will then review it to decide whether or not to call the patient for a visit.

Fig. 3.

High-level metamodel of the process of integrated monitoring for patients at risk of congestive heart failure.

The metamodel highlights the existence of two main documents that need to be exchanged between the mHealth App and the EHR, namely the monitoring/medication prescription and the monitoring/medication report (personal healthcare monitoring report, PHMR).

►Figure 4 and ►Figure 5 show the logic of the information flow to implement the standards-based architecture in this specific case study. The data model for the mHealth App side is shown in the UML class diagram in ►Figure 6. In the model, a prescription is composed by different activities that can be either monitoring activities or medications. Each activity has an “activity type” and includes all the information relevant to be carried out (frequency, total number of times, starting date, etc.). When performed, each activity generates a set of “measurements” that represent the value (either a numeric value, or a signal, or a log information) of coded “observations” that will be then collected in the PHMR.

Fig. 4.

UML Sequence diagram of the prescription generation on the EHR side

Fig. 5.

UML Sequence diagram of the personal health monitoring report generation on the mHealth App side.

Fig. 6.

UML Class diagram representing the data model for the mHealth App side.

3.3 Proof of Concept

According to the above specifications defined by the UML model, and to validate the proposed architecture, we developed a prototype system.

On the EHR side, the OpenMRS forms for the management of patients at risk of congestive heart failure were implemented (►Figure 7, left side), also including “infobuttons” directly querying PubMed according to the clinical concepts included in the form. Through the “order entry” OpenMRS module, the clinician can prescribe the monitoring program that is translated to a CDA-2 document using the “CDA-2 generator module” of OpenMRS.

Fig. 7.

System interface of the present prototype.

The patient then accesses the mHealth App and requests the new prescription that generates the monitoring calendar (►Figure 7, right side). The App prompts an alert when a calendar event is scheduled. When all the activities scheduled in an event are completed, the PHMR is generated and sent to OpenMRS. The PHMR is generated according to a CDA-2 XML template based on the CDA-2 PHMR specification (CDAR2_IG_PHMRPTS_R1.1_DSTU_2010OCT) adapted to fulfill the requirements of the mHealth App/EHR data exchange. More specifically, the template is classically organized in a structured header and a structured body. In the header, the ClinicalDocument/confidentialityCode is set to “L” since data are de-identified and the mobile phone is supposed unsafe; in the ClinicalDocument/recordTarget/patientRole field, only the patient identification number is allowed to ensure that data are sent de-identified. The ClinicalDocument/author is the patient (through his/her ID) and the ClinicalDocument/author/assignedPerson is the mobile phone. The ClinicalDocument/informationRecipient, that in the original template is optional, in this case is mandatory to define the healthcare institution that will receive the document. For the ClinicalDocument/documentationOf/serviceEvent field, we defined a new classCode (“MOBILE”) and we set the ID @root and @extension as referring to the prescription received. The body of the document is composed of four mandatory sections:

• Results (LOINC 30954–2),

• Medical Equipment (LOINC 46264–8),

• Medications (LOINC 10160–0),

• Purpose (LOINC 48764–5).

To implement the mapping between the clinical concepts and the CHV concepts, Observations were mapped also using UMLS concept unique identifiers. “Medications” represent the logs of drug administrations and their adverse effects (if any) and the “Purpose” section is needed to report the reason for monitoring (that is included in the prescription) or the reason of an unscheduled monitoring.

The App interface is shown in ►Figure 7 (right side). The App, apart from its two main functionalities (i.e., download the prescription and perform monitoring activities) also includes an “info-button“ that links to the Medline Plus page dedicated to congestive heart failure, as well as an ICE (In-Case-of-Emergency) button that is intended to directly call the doctor/caregiver in case of emergency, according to the contact information that are stored in the Settings page of the App itself. The App does not include any patient’s identification information (e.g., name, address, social security number). Only caregiver contacts are stored in the device. Also, the application is protected by a password that belongs to the patient. The patient has the possibility to allow the caregiver to access the App through a pair username/password that is defined by the patient him/her self. In this way, even in the case that someone else than the patient or the caregiver finds the mobile device, the patient’s data and the medical condition are protected.

4. Discussion

In this work we have outlined a standards-based architecture that can be adopted in the development of mHealth Apps to allow a bi-directional communication with EHRs, answering the present need of specifications for including patient generated data from mobile applications to the EHR. The architecture is essentially based on the exchange of structured clinical documents in a de-identified fashion, and on the use of the mHealth App not to store the patient generated data but as a “gateway” for the information that is immediately transferred to the EHR to avoid the harmful possibility of stolen data.

Even though still in a prototype phase, our proof-of-concept for the home monitoring of patients at risk of congestive heart failure, showed the feasibility of the approach. The prototype system, in fact, implements all the functional requirements and building blocks previously defined as essential to ensure the accurate and safe data exchange between EHRs and mHealth Apps: the “concept translator block” was implemented by mapping the clinical concepts included in the structured documents using the Unified Medical Language System (UMLS) and, then, translating them using the Consumer Health Vocabulary (CHV); the “security tools block” was implemented by exchanging only de-identified data (data not containing personal identification information of the patient, but only a code representing the patient’s identifier on the EHR side), and by avoiding the storage of health information on the device. The “standard document and communication architecture” was implemented by using new CDA-2 document templates for data exchange. The “educational tool block” was represented by the connection to qualified information sources, such as MedlinePlus. At the present development stage only the “Feedback System” is lacking, but it will be in the future included as a logging systems to collect user’s experience and feedback on the system use. The architecture also satisfied the non-functional requirements defined for the present application scenario. The application of the proposed architecture is not limited to the case of patients at risk of congestive heart failure, but can be potentially adapted to any other mHealth App promoting patient’s self-management. The only possible drawback regards the response time needed for the specific patient’s condition: the absence of network connection or the inability of the EHR system to be accessed, in fact, may delay the information exchange thus causing, in turn, a delay in the intervention. The architecture may prove to be useful, for instance, in diabetes self-management: diabetic patients benefit from mHealth Apps providing remainders and educational tools, but the efficacy of such approaches is enhanced when telemonitoring strategies are added [34, 35], and data are provided directly to the physician. Applying the proposed architecture would imply providing monitoring data directly to the patient’s EHR instead of to a dedicated telehealth system, thus optimizing data integration.

The present implementation only assesses the technological feasibility of the integration architecture and not the usability or the appropriateness of the mHealth App to the clinical problem. Also, it does not investigate whether and how the use of a system that integrates a patient’s mHealth App and his/her EHR improves patient’s care or healthcare professional practice. This kind of assessment requires the development of a full service, and not only of a system prototype, and it is not in the scope of this work. In addition, the full implementation of the two-way EHR/mHealth App information exchange would require the patient to access his/her EHR to view longitudinal data. Since no data are stored in the mHealth App, but are all sent to the EHR, the patient can review his/her data by accessing the EHR system. At the proof-of-concept level, this functionality was however not implemented because the prototype focused on the data upload from the mHealth App to the EHR, while the patients’ access to EHRs has been already proved as feasible (e.g., blue button initiative [21]).

However, even considering the mentioned limitations, the architecture and the approach here described may be useful for the research community involved in integrated care research, being a starting point and a specification definition for the development of systems and services implementing the bi-directional data exchange between mHealth Apps and the EHR. The architecture proposed does not conflict with the user-oriented design approach that is needed to ensure mHealth App usability [26], but represents a step forward in the integration of personal mHealth Apps into the larger health-IT ecosystem envisaged by HIE, thus supporting patient’s engagement in self-management and self-care and, ultimately, allowing better care and clinical outcomes.