Building custom connections between individual devices and health care organizations is costly and introduces data management inefficiencies. For organizations interested in remotely monitoring multiple types of health data via different PGD devices, one approach is to select 1 or a few device vendors for each data type and develop custom connections for each device to the electronic health record (EHR) [9]. Not only is this approach redundant, costly, and maintenance heavy, the dependence on vendor- or device-specific custom connections reduces flexibility to add or substitute new devices in the future.

We can identify opportunities for streamlining the pipeline if we segment the 3 major functional components of PGD integration:

Currently, each PGD device manages its own acquisition, storage, and data usage, while each health care organization acts as a third party to multiple query endpoints, with each requiring their own integration into clinical workflow. Data standards would enable PGD from multiple devices to flow through a single pipeline instead of multiple pipelines, with each serving 1 device.

PGD are acquired from patients via a diverse and growing ecosystem of health tracking apps, wearables, and sensors [10]. Typically, a device will require a patient to download a smartphone app to establish an account and pull data from the device to the smartphone through Bluetooth to store on the device company’s cloud. Many devices provide an app or online dashboard where a patient or their physician can view tracked data [11-13].

Once data are acquired by the device, patients provide consent for data sharing either directly or via a separate PGD aggregator app that will serve the data to third-party solutions and their users (Figure 1). Existing aggregator apps include Apple Health, Google Fit, CommonHealth, Human API, and Validic. Apple Health and Google Fit allow patients to further share their data with any participating third party in the iOS and Android ecosystem, respectively, but with somewhat opaque rules by which third parties can request data and without any evaluation of clinical validity or security. CommonHealth, a nonprofit entrant to the personal health record/aggregator app space, differs by establishing a Common Trust Framework [14] in which patients can consent to share downloaded EHR or device data with trusted apps and services running on their phone. This framework is a neutral, independent set of rules that is developed through open-community governance.

Data-sharing consent can be granted at different levels of granularity. Patients may authorize their clinician to access only their BP data, while authorizing a clinical trial they are enrolled in access to BP, step count, weight, and calorie tracking data. Consent may also be revoked entirely or temporarily withheld for privacy or other reasons (eg, withholding weight data while on vacation).

Once patients consent to data sharing, an aggregator app’s service processes their consent to mediate data transfer. PGD aggregation service components include authenticating third-party data requests, resolving whose data are being requested, managing authorization and consent, securely storing data (if needed), mapping data to standardized format(s), and exporting data in the desired standardized format to the third party.

Third-party users occupying the distal end of the PGD integration pipeline include health care organizations, researchers, and patients themselves (eg, consumers of an app that provides predictive analytics for blood glucose control). Many third parties want to be device agnostic. For example, a company providing decision support for BP management would want to accept BP data from any FDA-cleared brand and model of wireless BP cuff. Many third parties may also need to integrate heterogeneous data sources, such as reconciling sleep data from a smartwatch and a dedicated sleep sensor. Third parties would enjoy great efficiencies if PGD were available in a common data and metadata standard by not needing to divine the contextual meaning or metadata of PGD acquired from different sources. A standardized endpoint from a PGD aggregator would support the ideal of collecting PGD once and reusing them for multiple purposes.

Home BP monitoring (HBPM) programs, in which dedicated staff monitor the home BPs of a panel of patients with hypertension for treatment support and adjustment, have shown efficacy in improving BP control [27]. Health care organizations are thus increasingly interested in establishing HBPM programs [8], which are reimbursable under several Centers for Medicare & Medicaid Services (CMS) billing codes but only if home BP measurements are acquired via wireless-connected cuffs and written directly into the health care organization’s EHR [28]. We illustrate the PGD Integration Pipeline using the example of integrating wireless BP data into an EHR.

Currently, home BPs from connected devices can be brought into an HBPM program through several pathways. One pathway is for patients to manually enter home BPs into an EHR patient portal. Despite its simplicity, this approach has many downsides. Using patient portals is challenging for patients with language barriers and low technology skills [29]. Manual reporting may result in fewer datapoints, is difficult to sustain over time [30], and evaluation and management of manually reported BP data are not reimbursable by CMS under the remote physiologic monitoring codes [28].

Another approach involves a partnership between a health care organization and a single wireless BP cuff company which will offer that company’s online dashboard for clinicians to view. The need for clinicians to login to the company’s website outside of their EHR severely disrupts workflow and is usually vehemently opposed by clinicians. Moreover, to qualify for CMS reimbursement, a custom interface has to be built and maintained to write data from that company into the EHR. Not only is this time-consuming and expensive, but it also severely limits flexibility. Adding another brand of cuff would require an entirely new integration effort and online dashboard. Inertia to stay only with the initial company would be high. Such “vendor-lock” is inadvisable in a fast-changing digital health world.

An emerging approach takes advantage of Apple Health and Google Fit as PGD aggregators. At University of California, San Francisco (UCSF), which is on the Epic system, a pilot project is allowing clinicians to prescribe HBPM and have that prescription displayed on their patients’ MyChart portal. Patients use one of several brands of cuffs, download both the device’s app and the MyChart app onto their smartphone, and use Apple Health or Google Fit to consent and direct their BP data from the device’s app into Epic. The ingested data can then be viewed within Epic and evaluation and management can be billed under CMS codes. This approach has the benefits of being device-agnostic, billable, and integrated into the EHR-based workflow. However, it is reliant on, and constrained by, Epic, MyChart, Apple Health, and Google Fit functionality and usability. Indeed, as of this writing, Google Fit has “temporarily stopped” accepting connected BP values and other “sensitive” health data types including body temperature and oxygen saturation [31]. Moreover, using PGD aggregators without data standards–driven infrastructure impairs robust PGD validation and use. For example, device manufacturer data are unavailable for query from either Apple Health or Google Fit endpoints.

The optimal approach of using data standards throughout the BP integration pipeline offers many benefits. First, if device vendors adhered to data and metadata standards (eg, Open mHealth/IEEE 1752.1.1), the meaning and context of BP and other PGD would be captured for posterity at the source, which is ideal for downstream use, auditing, and regulatory oversight. If BP data are not standardized at the source, a standards-based PGD aggregator such as CommonHealth can ingest and map BP data from multiple vendors into Open mHealth or FHIR for standardized export. Health care organizations using a standards-based PGD aggregator are ensured that BP data will come in a consistent format with the same clinical contextual information and metadata, regardless of the cuff’s brand or model. This device-agnostic predictability within a single integration pipeline yields great flexibility: multiple types of PGD from different device vendors can be integrated.

For health care organizations, standardization can facilitate data integration into workflow and writing into the EHR for billing. EHRs in the United States must now by law support HL7 FHIR data and protocol standards [32]. This allows EHRs to receive and display PGD using SMART-on-FHIR [33] protocols to launch dashboards directly in the EHR without requiring separate login. The mPROVE project at UCSF is taking this approach [34], displaying patient-reported outcomes and BP data in the BRIDGE SMART-on-FHIR dashboard [35]. Using SMART-on-FHIR frees data display and decision support presentation from the constraints of the EHR. While still in early adoption, SMART-on-FHIR technology has tremendous promise to augment the distal end of the PGD integration pipeline.

Another valuable benefit of data standardization for health care organizations is increased efficiency of data integration [36]. Instead of having to build and maintain custom connections to multiple device vendors, an organization receiving PGD in a common predictable format such as Open mHealth/IEEE 1752.1.1 can reuse the same interface for bringing PGD into their EHR or clinical workflow. Going forward, this singular interface can accommodate any new PGD data type that is supported by the data standard. The organization can flexibly switch to any other PGD aggregator that supports the same data standard because the PGD remains consistent for interfacing into the EHR.

Finally, the promise of PGD will be realized only if patients trust how their PGD will be handled, and if collecting, consenting, understanding, and sharing PGD are sufficiently easy to do [37]. To the extent that standardization of the PGD integration pipeline reduces data silos, multiple identities and accounts, and a profusion of opaque data-sharing mechanisms, trust will be enhanced for all parties and PGD integrity and value will be increased.

Today’s mHealth data ecosystem—where multiple apps, devices, and proprietary aggregators each export data in their own data formats with little context or metadata—is suboptimal for unleashing the full capabilities of mHealth technologies to improve clinical care. Standards are key to successful data interchangeability and should be adopted broadly to enable device-agnostic solutions and modularity and to simplify the PGD ecosystem while simultaneously supporting data validation and data integrity.

Deployment of PGD solutions in clinical care needs to extend beyond interoperability and integration. Various frameworks and best practices exist for choosing and deploying mHealth apps and sensors. HL7’s Consumer Mobile Health Applications Functional Framework (cMHAFF) provides industry guidance and common methods to assess the “foundational characteristics,” including but not limited to security, privacy, data access, data export, and transparency/disclosure of conditions, of mHealth apps [38]. HL7’s App Data Exchange (ADE) project documents the functional requirements and provides a framework supporting data exchange between mHealth devices, apps, and other parts of the health IT Infrastructure [39]. The ADE project references mHealth data standards such as Open mHealth/IEEE 1752.1.1 and IEEE 11073.

By themselves, neither cMHAFF nor ADE address the clinical validity or value of an mHealth solution. The DiMe Playbook is a “comprehensive ‘how-to’ guide” on developing, selecting, and deploying digital biomarkers. It addresses digital biomarker verification, analytical validation, and clinical validation (V3) as well as the role of standards such as Open mHealth/IEEE 1752.1.1 in data integration [40].

Like privacy, data provenance and interoperability should be intentionally designed into a system up-front rather than shoehorned into it later on [41]. For the mHealth ecosystem, a mix of frameworks, official data standards and protocols, and best practices as reviewed above is beginning to paint a path out of today’s fragmented silos. For the PGD integration pipeline in particular, the path includes PGD devices and mHealth apps exporting and consuming digital biomarkers in the Open mHealth/IEEE 1752.1 format where appropriate; expanding the data types standardized by Open mHealth/IEEE 1752.1; data aggregators exporting PGD in both their current format (to ensure backward compatibility) and Open mHealth/IEEE 1752.1 format (to transition toward standardized interoperability); and finally, wide adoption of the Open mHealth-to-FHIR implementation guide as the common FHIR observation resource profile for PGD [42]. These steps offer a glidepath for the ecosystem to transition to data and metadata standards that themselves evolve to accommodate new digital biomarkers and new metadata frameworks. Further research is needed on scalable metadata acquisition and management, biomarker validation platforms, and interoperability with the broader internet of things.

The clinical value of PGD from mHealth apps and sensors is currently limited by difficult and inefficient integration into routine clinical care. Major components of the PGD integration pipeline include PGD acquisition, PGD aggregation, and third-party solutions that consume PGD to deliver end value for clinical care and clinical research, all while retaining people’s control on their data and trust in the process. Standardization of data and metadata along the entire PGD integration pipeline is crucial for ensuring device-agnostic, modular, flexible, multipurpose, and thus lower-cost integration into clinical workflow. The value of efficient integration of PGD data will increase revenue streams, reduce overhead, improve data integrity, and facilitate patient trust. PGD aggregation services that offer standards-based PGD integration play a vital role in transitioning from today’s siloed friction-heavy data ecosystem to a low-friction interoperating system that our patients deserve. Health leaders responsible for remote monitoring and other PGD programs should seek out and adopt pipeline-based approaches to standardize the integration of PGD into clinical care.