Design and Implementation of an Electronic Health Record‐Integrated Hypertension Management Application

Abstract

Background

High blood pressure affects approximately 116 million adults in the United States. It is the leading risk factor for death and disability across the world. Unfortunately, over the past decade, hypertension control rates have decreased across the United States. Prediction models and clinical studies have shown that reducing clinician inertia alone is sufficient to reach the target of ≥80% blood pressure control. Digital health tools containing evidence‐based algorithms that are able to reduce clinician inertia are a good fit for turning the tide in blood pressure control, but careful consideration should be taken in the design process to integrate digital health interventions into the clinical workflow.

Methods

We describe the development of a provider‐facing hypertension management platform. We enumerate key steps of the development process, including needs finding, clinical workflow analysis, treatment algorithm creation, platform design and electronic health record integration. We interviewed and surveyed 5 Stanford clinicians from primary care, cardiology, and their clinical care team members (including nurses, advanced practice providers, medical assistants) to identify needs and break down the steps of clinician workflow analysis. The application design and development stage were aided by a team of approximately 15 specialists in the fields of primary care, hypertension, bioinformatics, and software development.

Conclusions

Digital monitoring holds immense potential for revolutionizing chronic disease management. Our team developed a hypertension management platform at an academic medical center to address some of the top barriers to adoption and achieving clinical outcomes. The frameworks and processes described in this article may be used for the development of a diverse range of digital health tools in the cardiovascular space.

Nonstandard Abbreviations and Acronyms

RPM

remote patient monitoring

TASMINH2

Telemonitoring and Self‐Management in the Control of Hypertension

TASMIN‐SR

Targets and Self‐Management for the Control of Blood Pressure in Stroke and At‐Risk Groups

High blood pressure (BP) affects ≈116 million adults in the United States. It is the leading risk factor for death and disability across the world, predominantly through its deleterious effects on ischemic heart disease and stroke. ¹ , ² Unfortunately, over the past decade, hypertension control rates have decreased across the United States, from ≈49% in the year 2000 to 39% in 2018. ³ The Million Hearts initiative from the US Centers for Disease Control and Prevention has the goal of reducing 1 million heart attacks and strokes in 5 years, ⁴ in part by achieving hypertension control rates of 80% ³ ; although low rates of blood pressure control are multifactorial, standardized evidence‐based algorithms have shown to help reach this goal. ⁵ , ⁶

Guidelines provide summarized up‐to‐date knowledge to aid clinicians in routine medical practice, yet implementation of guideline recommendations into clinical practice remains suboptimal. Transforming guidelines into algorithms may help bridge the gap of guideline implementation. A large‐scale program at an integrated health care system achieved 80% BP control rates with the help of a 4‐step evidence‐based algorithm that was distributed in printed documents. ⁵ Printed algorithms in addition to remote patient monitoring (RPM) have also been used in randomized control trials. In the TASMINH2 (Telemonitoring and Self‐Management in the Control of Hypertension) and TASMIN‐SR (Targets and Self‐Management for the Control of Blood Pressure in Stroke and At‐Risk Groups) trials, investigators randomized patients to home BP monitoring and self‐titration versus usual care. In both trials, the intervention achieved significant reductions in systolic BP compared with usual care (TASMINH2: median, −5.5 mm Hg [interquartile range, −2.2 to −8.8 mm Hg]; TASMIN‐SR: median, −9.2 mm Hg [interquartile range, −5.7 to −12.7 mm Hg]). ⁷ , ⁸ These studies used BP devices that transmitted data using a telephone landline and titration performed following instructions provided in a printed algorithm. ⁷ , ⁸

With the modern web‐based software, mobile apps, and electronic health record (EHR) integration, algorithmic decision tools can independently analyze data to present actionable output to support clinicians' work.

While digital health tools containing evidence‐based algorithms may help improve hypertension control, careful consideration should be taken in the design process to integrate digital health interventions into clinical workflow, facilitating adoption and achieving time savings that may enable implementation in low‐resourced settings. ⁹ , ¹⁰ To our knowledge, there is no standard user‐centered design‐based framework for the development of digital health tools in the cardiovascular and hypertension space. We describe the development of a provider‐facing hypertension management platform. We enumerate the key steps of the development process, including interviewing a diversity of stakeholders (nurses, cardiologists, primary care clinicians, and pharmacists) while conducting needs finding, consulting with a diversity of providers during clinical workflow analysis, treatment algorithm creation, platform design, and EHR integration. The frameworks and processes described in this article may be used for the development of digital health tools in the cardiovascular space (Figure 1). ¹¹

Figure 1. Biodesign framework (Denend et al; ¹¹ top panel) and development stages of a physician‐facing EHR‐integrated hypertension management application (bottom panel).

EHR indicates electronic health record; HTN, hypertension; and MVP, minimal viable product.

Methods

The authors will make the data, methods used in analysis, and materials used to conduct the research for this study available on reasonable request. The study was approved by the Stanford University Institutional Review Board, and informed consent will be obtained from all subjects.

Needs Finding and Screening

BP management is complex, requiring implementation of many drivers for hypertension control such as standardized treatment protocols, treatment intensification, continuity of care and follow‐up, and team‐based care. ¹² The management process is a cyclical process that starts with the identification and confirmation of elevated BP, recognition of elevated BP by the clinician, lifestyle and medical interventions, and, finally, adherence to these recommendations by the patient (Figure 2). This cycle is repeated at varying intervals and barriers to optimal management can arise at each stage of the cycle. Therefore, we understood that this complex problem cannot be solved with a single digital health tool. We performed needs finding, an approach pioneered by the Stanford Byers Center of Biodesign, as our first key step in the innovation process to decide on which challenge to address in the life cycle of hypertension management. ¹¹ , ¹³ Characterizing this need required an understanding of the key barriers in hypertension management.

Figure 2. Needs finding.

The first step in the development process is to identify the unmet needs to solve from the numerous barriers in the hypertension management cycle. (1) Measure blood pressure accurately; (2) treatment intensification, clinic care, and follow‐up; (3) lifestyle adherence; (4) medication prescription and refill; and (5) medication adherence.

Identifying and Defining the Barriers in Hypertension Control

Important barriers to uncontrolled BP include, but are not limited to, medication nonadherence, lack of follow‐up appointments, and clinician inertia. To identify and understand the scale of the problem, we started with an extensive literature review of previous existing studies. We found that ≈12.4% of patients never fill an initial prescription for antihypertensive medication(s) and at least 30% of patients do not continue the medication after the initial prescription. ¹⁴ , ¹⁵ , ¹⁶ Clinician inertia, defined as the lack of treatment intensification when the BP is above goal, is estimated to range from 50% to 80% in both clinical practice and in randomized clinical trials. ¹⁷ , ¹⁸ , ¹⁹ Prediction models have estimated that reducing clinician inertia alone, compared with improving adherence or increasing follow‐up appointments, is sufficient to reach the target of ≥80% BP control. ²⁰ A large integrated health care system has demonstrated that implementing a large‐scale hypertension management program using hypertension registries, an evidence‐based medication titration algorithm, and frequent follow‐up appointments improved treatment intensification and led to BP control rates exceeding 80%. ⁵ Similar results were seen when this intervention was applied to safety net hospitals. ⁶ Next, we conducted stakeholder interviews in the primary care space assessing: 9 clinical team members’ (including medical providers, nurses, pharmacists, and medical assistants) inertia, patient communication and ease of data exchange, and patient adherence and follow‐up appointments to better understand how each one of these factors affect the hypertension management in a diversity of clinic environments and scale.

Analysis of Existing Solutions

One of the more accessible solutions to address part of this need is validated and commercially available Bluetooth BP devices. Moreover, national and international guidelines now support the use of self‐monitored BP for the management of hypertension. ²¹ Unfortunately, there has been a gap in the use of self‐monitored BP and the transfer of BP data from the patients' BP devices to the clinicians. ²² To address this problem, multiple RPM tools have emerged to provide automatic electronic transfer of patient physiologic data, including BP data. In addition, many digital health solutions have emerged for the management of hypertension, offering patient‐facing smartphone applications or provider‐facing dashboards. The majority of the patient‐facing applications display self‐monitored BP values, education, or coaching; on the provider side, dashboards offer summarized RPM data and some have the ability to support telemedicine services. ²³ , ²⁴ Unfortunately, clinicians already spend excessive time in the EHR to complete tasks related to the review of patient data, responding to in‐basket messages and ordering medications. ²⁵ , ²⁶ , ²⁷ , ²⁸ Additional BP data received by the clinician, using existing RPM solutions, without EHR integration and actionable medication recommendation could increase clinician time spent engaging with the EHR.

Need and Need Specifications

As such, we saw a need to develop a software that reduces clinician burden while managing patient hypertension by providing actionable guideline‐based medication recommendations. The system must allow the clinicians to adjust patients’ BP outside of face‐to‐face encounters and either saves them time or allow them to generate revenue that would offset any increased effort and cost. It would be desirable to have ways to improve workflow by providing integration with the EHR. Also, it would be favorable to design a product that falls within current reimbursement or Current Procedural Terminology codes.

Clinical Workflow Analysis

Early in the design process, we prioritized integration of our tool into the routine clinic workflow, as this has been shown to improve adoption and outcomes. ²⁹ Workflow analysis is defined as a set of physical and mental tasks required to be performed by personnel in a set environment. ³⁰ Different methods to evaluate workflow are available, including direct observation, EHR audits, and staff reporting. ³¹ The 4 steps we used for workflow analysis include (1) identification of discrete workflow components, (2) workflow assessment, (3) triangulation, and (4) stakeholder proposal. ²⁹

First, we used feedback from our team of clinicians (cardiologists, nephrologists, and primary care physicians at Stanford Hospital) to identify distinct tasks involved in hypertension management in current clinical practice (Figure 3). In general, stakeholders involved in hypertension management include the patient, medical assistant(s), nurse(s) or advanced practice provider(s), and physician(s). The following were identified as part of the workflow: Step 1: The patient measures their BP at home and either transfers the raw BP values to the health care team via email or directly into EHR if using a Bluetooth‐enabled device or physical copy during the next in‐person visit. Step 2: The medical assistant receives BP values, prioritizes the multiple messages received, and relays this information to the nurse or directly to the physician. In most cases, the clinical staff do not calculate BP averages from those values, but instead eyeball the values to decide if they are above the patient's goal. Step 3: Finally, the clinician must review these readings; patient notes; patient's EHR including allergies, current antihypertensive medications (if any), recent dose changes, and laboratory results, all possibly in different tabs in the EHR, to decide if and which medication(s) to titrate.

Figure 3. Workflow analysis.

Simplified workflow analysis of patient tasks, clinic staff tasks, and HrtEx hypertension management platform tasks starting with BP measurement and finalizing with the intensification of medical therapy. BP indicates blood pressure; EHR, electronic health record; and MA, medical assistant.

Product Design, Testing, and Development

We envisioned a final version of the software that would have an embedded titration algorithm for actionable medication recommendations, integration to push actionable data to the EHR, and bidirectional communication with the EHR allowing the query of vital signs, medication list, allergies, and laboratory results. Our 1.0 version was easily modifiable and allowed the automatic electronic transfer of BP data through a Bluetooth‐enabled BP device but required manual entry of these laboratory data and other medications.

We tested the 1.0 version at 5 cardiology and primary care clinics of a tertiary referral academic medical center. Eligible clinicians were providers that regularly treat patients with hypertension. Eligible patients had essential hypertension (BP ≥140/90 mm Hg), were on <3 antihypertensives, and owned a smartphone. Primary outcomes were user engagement, user feedback, and change from baseline in systolic and diastolic BP. We enrolled a total of 18 patients with a mean age of 51±11 years; 94% were men with a mean (±SD) systolic BP of 133±8 mm Hg and mean follow‐up of 8.8 weeks. Clinician feedback focused on 2 areas: (1) increased medication customization and (2) notification or alerts when a medication change was needed. Patient feedback centered on improving BP monitoring device connectivity and decreasing steps between BP and smartphone application setup. At 12‐week follow‐up, the mean (±SD) weekly BP readings transmitted per patient were 11±8 readings per week. There was a mean decrease in systolic BP of 14.4 mm Hg (95% CI: 9–17.8 mm Hg).

Based on lessons learned from the initial prototype testing of version 1.0 and workflow analysis, we proposed 5 key features of our 2.0 version of the digital health tool: (1) secure query of BP data, laboratory values, medication list, and allergies from the EHR; (2) algorithm to consistently calculate BP averages and decide on next BP medication titration step on the basis of a clinician prespecified BP target and medication titration sequence; (3) to push the summarized actionable data into the EHR for the clinician to accept or decline the recommendation; (4) updating medication data in the EHR; and (5) submission of new prescription, if indicated. These core features may free time and reduce human error from nonclinical and clinical staff, analyze key data points used in hypertension management (calculate averages and review laboratory data), and provide actionable data to clinicians in their usual workflow.

The development team was split into 2 groups that met separately once a week. The product development team consisted of junior clinical researchers (cardiologist, nephrologist, and general practitioners) and software engineers that together developed and tested initial prototypes. The second team consisted of junior and senior clinical researchers that would deliberate key design features and trial design. The development team would present prototypes to junior and senior clinical researchers consisting of ≈15 specialists in the areas of primary care, cardiology, nephrology, hypertension, and bioinformatics. Decisions were made following feedback from the pilot study, voting during meetings, and informal feedback from clinician and patient.

Application Design

In addition to needs finding and workflow stakeholder analysis, we performed a landscape analysis of the identified existing physician‐facing platforms for RPM and chronic disease management in the market. The available features were presented to and reviewed by the different stakeholders, including clinicians and nurses managing patients with hypertension, to identify our dashboard must haves. Lessons learned from existing solutions underscored that provider time is valuable. Clinicians have limited time to learn and interact with another dashboard. ³² Based on our landscape analysis, we concluded that the essential concepts of our platform must include:

• Interoperability: a separate web application with a dashboard was created to host the algorithm and allow integration into a range of EHR systems via standardized interfaces. Any of the health care team members can log into the dashboard to view patients enrolled in the system. However, the goal was for clinicians to directly receive actionable data within the EHR and to avoid the need for using another digital platform.

• Usability: allow filtering the patient list in the main dashboard view to highlight the ones who have a pending medication recommendation. It would require an extra click to view all the patients enrolled in the system, including those with controlled BP and no medication recommendations.

• EHR integration: the ability to pull from and to push data into the EHR while conducting data analysis by the computed evidence‐based algorithm in the platform. The data in the platform reflect the data in the EHR. As such, the ground truth is the patient's medical record.

Treatment Algorithm Creation

Transforming guidelines into algorithms helps to bridge the gap of guideline implementation, ⁵ , ⁷ , ⁸ though different methods exist to translate these guidelines into a computerized format, reviewed in detail before. ³³ , ³⁴ , ³⁵ We briefly describe the key steps we used from the process described by Shiffman and colleagues ³⁵ that guided our translation of hypertension guidelines into a coded algorithm.

The first step in guideline implementation is to decide which guideline or set of guidelines are best suited for translation. In the case of hypertension management, it was critical to determine who will be the end user, both the type of clinician and the patient population, and whether titration was intended during clinic visits or remotely. The clinician end users regularly manage patients with primary hypertension: physicians from internal medicine, primary care/family medicine, cardiology, and nephrology. We targeted patients with primary hypertension that are eligible for first‐ or second‐line agents, whereas patients with labile hypertension, orthostatic hypotension, multiple allergies, or hypertension requiring more than 5 antihypertensives are best suited for management independent of our algorithm. As our intervention was intended for remote titration, we used the 2017 ACC/AHA/AAPA/ABC/ACPM/AGS/APhA/ASH/ASPC/NMA/PCNA Guideline ³⁶ for the Prevention, Detection, Evaluation, and Management of high Blood Pressure in Adults and the 2020 Self‐Measured Blood Pressure Monitoring at Home: A Joint Policy Statement from the American Heart Association and American Medical Association. ²¹

Once guideline selection was complete, we used the following series of steps to refine its content (Table). ³⁵

Table .

Guideline Implementation Process

Guideline selection	2017 Hypertension Clinical Practice Guidelines, 36 2018 Resistant Hypertension AHA Scientific Statement, 37 and 2020 SMBP AHA Joint Policy Statement 21
Markup Identify and tag medication recommendations to be implemented	Two separate class 1 recommendations: Use of BP‐lowering medication is recommended for primary prevention of CVD in adults with no history of CVD and with an estimated 10‐year ASCVD risk <10% and an SBP of 140 mm Hg or higher or a DBP of 90 mm Hg or higher “For initiation of antihypertensive drug therapy, first‐line agents include thiazide diuretics, CCBs, and ACE inhibitors or ARBs”
Atomization The process of extracting and refining single concepts from the recommendation's text	Use ACEI if blood pressure is >140/90 mm Hg
Deabstraction Adjusting the recommendation as an action that permits operationalization	Order next sequence of medication selected if BP is >140/90 mm Hg
Disambiguation Determine a single interpretation for the recommendation	Order lisinopril when SBP is >140 or DBP is >90 mm Hg
Verification of completeness Assures the recommendation provides guidance in all situations the clinician might encounter	Order lisinopril when SBP when 2‐week average SBP is >140 mm Hg or DBP is >90 mm Hg and there is no allergy and potassium is <5 mmol/L
Build executable statements	If 2‐week average [SBP] is over [140 mm Hg] or [DBP] is over [90 mm Hg] AND [allergy] is absent AND [serum potassium] <[5 mmol/L] THEN order [lisinopril]
Identify origins and insertions The team implementing the guidelines must identify the source of decision variables and the insertion point of the output	Insertions (SBP, DBP, HR, sodium, potassium, creatinine, eGFR, allergies, medication list) are obtained from patient's chart (C‐CDA) Output is a medication recommendation (NDC, dose, and frequency) sent as an in‐basket message

ACE indicates angiotensin‐converting enzyme; ACEI, angiotensin‐converting enzyme inhibitor; ARB, angiotensin type 1 receptor blocker; AHA, American Heart Association; ASCVD, atherosclerotic cardiovascular disease; BP, blood pressure; CCB, calcium channel blocker; C‐CDA, Consolidated Clinical Document Architecture; CVD, cardiovascular disease; DBP, diastolic blood pressure; eGFR, estimated glomerular filtration rate; HR, heart rate; NDC, national drug code; SBP, systolic blood pressure; and SMBP, self‐measured blood pressure.

Step 1: Atomization, for guideline implementation, involves extracting single concepts from the guidelines' general text. These concepts were written in a concise form, presented in the active voice, and decision variables occupying the <value> element.

Step 2: The deabstraction process was used to modifying imprecise single concepts into precise decision statements executable by the computed algorithm once the data are entered.

Step 3: Next we removed uncertainty by creating a single interpretation recommendation statement through the disambiguation process.

Step 4: Finally, we performed a verification of completeness to ensure that all the possible scenarios are considered, and when complete, the statements can be translated into if‐then computable statements.

This algorithm code is hosted in a web service where clinicians preselect the medication sequence they want to use in advance (Figure 4). If the specific criteria are met, the algorithm recommends a medication titration based on the clinician's prespecified selection. For ease of use, clinicians are provided with default prescription trees that include first‐ and second‐line agents. The first step is usually a combination pill with an angiotensin‐converting enzyme inhibitor and thiazide‐type diuretic. Nevertheless, we learned from stakeholder feedback that providing clinicians the flexibility to edit or create the prescription sequence they want to use and the BP threshold for individual patients or cohorts of patients is critical to clinician acceptability (Figure 4). Once the algorithm is implemented into the dashboard, extensive testing is performed with simulated data. Initial implementation is an iterative process with certain rules requiring modification based on the results from algorithm testing and feedback from the clinicians.

Figure 4. Prescription tree templates.

Default prescription trees are available, but clinicians can edit and create default prescription trees for their clinic or edit the sequence for specific patients. ACEI indicates angiotensin‐converting enzyme inhibitor; CCB, calcium‐channel blocker; CKD, chronic kidney disease; HCTZ, hydrochlorothiazide; and MRA, mineralocorticoid receptor antagonist.

EHR Integration

A critical component of guideline implementation is the integration of the guideline's computerized algorithm into clinical workflow. Early in the design process, we had to decide between building the algorithm into the EHR and risking scalability into other health care systems or a separate web dashboard with integration into the EHR and the complexity of integrating into diverse EHR and clinical workflows. Other variables to consider include the target health care provider (pharmacists, advance practice providers, physicians), levels of personnel support, EHR customizability and interoperability, and BP device technologies (cellular versus Bluetooth). A separate platform with bidirectional transfer of data from the EHR allows workflow integration into a tertiary referral academic center but may limit the ability to quickly scale into other clinical sites such as a stand‐alone platform, for example, with incoming data from laboratory and BP device vendors.

An important functionality of our product is the integration into the EHR. The data workflow includes the transfer of data from (1) the patient's BP cuff to the smartphone app, (2) smartphone app to the EHR, (3) pull of data from the EHR to be analyzed by the evidence‐based algorithm that generates a medication recommendation based on a clinician prespecified medication sequence, and (4) push of actionable data into an in‐basket message that generates an orders‐only encounter with an unsigned order for the clinician to accept or decline following current practice (Figure 5). Accomplishing this goal required a concerted effort from a multidisciplinary team of (1) hypertension specialists, (2) bioinformaticians, (3) a software engineer vendor with experience in digital health platform development, (4) a middleware vendor with experience in secure connections between health care systems, and (5) EHR information technology support.

Figure 5. EHR integrated data flow.

Data flow: (1) BP data are transferred from a Bluetooth BPM to a smartphone application. (2) The smartphone application then transfers data to the EHR. (3) The hypertension management platform (HrtEx) queries data (medication list, blood work, allergies, vital signs) from the EHR every 24 hours to be analyzed by an algorithm. (5) If the 2‐week average BP is above the patient's predefined goal, a medication recommendation is sent to the EHR to the treating clinician's in‐basket message. With 1 click, the message opens an orders‐only encounter that presents a concise summary of the data used to generate the clinician's preselected medication recommendation and a pending medication order waiting to be signed by the treating clinician. BP indicates blood pressure; BPM, blood pressure monitor; and EHR, electronic health record.

To meet patient privacy protection requirements, the EHR‐independent platform is hosted on Health Insurance Portability and Accountability Act–compliant cloud infrastructure provided by Google Cloud and managed by the health care system where the platform is being deployed. Data are encrypted both at rest and in flight. Providers can securely authenticate using the institution's single sign‐on mechanism. The medication recommendations are sent to the provider assigned to that specific patient.

EHR integration allows our evidence‐based algorithm to analyze data elements (medication list, laboratory results, allergies) from the EHR, potentially freeing up time for the health care team (medical assistant and nurses). It also allows calculation of BP averages and data visualization. The patient‐specific data and recommendation is then pushed into a dedicated in‐basket message for the clinician, making decision making easier. EHR integration into regular clinician workflow also eliminates or minimizes the learning curve required to use the intervention. The in‐basket message opens an orders‐only encounter that has 2 important components: (1) a section of our web dashboard rendered in a browser instance inhere the EHR (iframe) that summarizes the data used to generate the medication recommendation, and (2) loading of an unsigned order for the clinician to accept or decline based on the information provided in the iframe. To limit the number of in‐basket messages, recommendations are sent only if the 2‐week average BP is above goal, and messages are not sent if the BP is controlled. Several features are customizable based on user feedback. The medication recommendations can be programmed on the basis of target BP or average BP over a longer interval, or automated blood work reminders can be added.

Anticipated Outcomes

A hypertension digital health intervention may lead to improvement in BP control, but adoption in the clinical setting may be limited by incompatibility with clinician workflow. Ultimately, a digital health intervention could unintentionally lead to an increase in resources, time, and effort. On the other hand, a digital health intervention may not improve BP control but lead to improvement in clinician workflow, leading to adoption in the clinical setting. Workflow analysis is an important tool, not only to understand how the implementation of a digital health intervention can best align with the clinical workflow, but also to understand what outcomes to monitor once the intervention has been implemented. To evaluate the implementation of the hypertension digital health system, workflow analysis will be conducted through surveys and data collected in a randomized clinical trial. Effectiveness outcomes, such as percentage of patients with controlled BP and average per patient decrease in BP; percentage of the accepted, declined, and postponed recommendations generated; and the number of weekly in‐basket messages received by medical assistants, nurse practitioners, and physicians will be tracked before and after implementing the hypertension management tool.

Other probable outcomes are identifying and diagnosing barriers in terms of sociodemographic factors. Our platform is a clinician‐facing dashboard that helps address clinician inertia and facilitate more efficient BP control. However, as we have remote monitoring devices involved in the care pathway, there are chances that we may encounter roadblocks to (1) access to BP devices, (2) availability of smartphone, or (3) technological soundness, which are in turn dependent on social determinants of Health like income level, education, access to health care, race and ethnicity, and language. Implementing a remote monitoring modality brings challenges with our patients. They not only require a smartphone but also need to be sufficiently tech savvy to connect their BP device to their phone to facilitate data transfer. Troubleshooting this will need more manpower and time. Perhaps ensuring that our patients have more resources to tackle their digital literacy limitations can empower them to use remote monitoring devices more efficiently.

Conclusions

Digital monitoring systems are largely unrealized but potentially valuable tools in caring for patients with chronic diseases such as hypertension. Our team developed a digital health hypertension management platform at an academic medical center to address some of the top barriers to adoption and achieving clinical outcomes: clinician inertia, reducing overall clinician time spent managing hypertension, and EHR integration.

Sources of Funding

This work was supported by the American Heart Association Research Supplement to Promote Diversity in Science Award # 872376.

Disclosures

None.