Software-driven chronic disease management: Algorithm design and implementation in a community-based blood pressure control pilot

Abstract

Background:

Optimal guideline-directed medical therapy is rarely attained in practice, resulting in inadequate control of diseases such as hypertension, with poorer results in under-resourced communities. Technology, including artificial intelligence-driven decision support and software-driven workflow transformation, can potentially improve disease outcomes at a reduced cost, although it must be integrated with a holistic approach.

Methods:

We describe the design of a software platform that enables rapid iterative remote management of >20 conditions across cardiac-kidney-metabolic disease. The platform distributes work across a care team of providers and care navigators, automates decision-making, ordering, and documentation, supports rapid incorporation of new evidence, and launches pragmatic trials. We describe software used in a 500-person community-based blood pressure control implemented as a single-arm quality improvement program. The primary endpoint was the proportion of patients meeting the Healthcare Effectiveness Data and Information Set quality measure blood pressure goal (<140/90) at 12 weeks.

Results:

A total of 1609 patients were screened, 945 (59%) were found to have uncontrolled hypertension, and 512 patients consented to join the program. The average age was 61 ± 11 years; 59% were female, and 99% self-identified as Black. Blood pressure distribution was: 10% Stage 1 (SBP 130–139 mmHg or DBP 80–89 mmHg), 69% Stage 2 (SBP 140–179 mmHg or DBP 90–119 mmHg), and 21% Stage 3 (SBP >180 mmHg or DBP >120 mmHg). Two hundred four patients (39%) proceeded to a provider encounter, and 160 of these (78%) completed the program. The Healthcare Effectiveness Data and Information Set blood pressure goal was achieved in <12 weeks of enrollment for 141 participants (69% of those enrolled, 88% of those who completed the program).

Conclusion:

Software-driven remote blood pressure is feasible, although strategies to improve patient enrollment will be needed to achieve maximum impact. Future work will be required to compare outcomes to usual care and evaluate concurrent management of multiple cardiac-kidney-metabolic conditions.

Introduction

Four decades after the publication of the first clinical cardiac guidelines, optimal guideline-directed medical therapy (GDMT) for cardiovascular disease, defined as indicated medications at clinical trial-effective doses, is implemented in fewer than 20% of patients. ¹ Likewise, for diseases such as hypertension (HTN) and hypercholesterolemia, successful attainment of guideline-recommended blood pressure (BP) and cholesterol targets is seen in only 20%–25% of patients,^{2 –4} with poorer results in individuals with low socioeconomic status. ⁵

Physicians describe the primary barriers to guideline implementation as (1) the complexity of recommendations, (2) weak evidence/knowledge gaps, and (3) the excess time required to attain these goals. ⁶ Other fields, faced with similar challenges, have adopted technological solutions, as these are uniquely suited for problems of knowledge and scale. However, for GDMT, the major proposed technological solution—clinical decision support—has largely been unsuccessful, with most software suggestions dismissed by providers and growing concerns such solutions exacerbate alert fatigue and physician burnout. ⁷ Moreover, the inherent number of time-consuming patient-provider interactions required for GDMT attainment puts further strain on a system struggling to control costs.

We sought to develop a technological solution to accelerate GDMT attainment in complex patients suffering from cardiovascular, kidney, or metabolic (CKM) disease, thereby reducing adverse cardiovascular events. Our software platform was designed with four central tenets: (1) the solution must support end-to-end medical management of multiple comorbid CKM conditions rather than merely surface pop-up suggestions; (2) the software must elevate the skill of a mid-level practitioner to that of a specialist; (3) the design should enable rapid updating to reflect new guidelines and insights from quality improvement projects; (4) the software should markedly improve provider scale and reduce burnout, through automated note writing and ordering, and by enabling a systematized predictable workflow that efficiently distributes tasks across the care team.

Herein, we describe the design and logic behind the software and implementation in a quality improvement pilot focused on BP control.

Methods

Algorithm logic and software design

An obvious temptation in building decision-recommendation software is implementing decision trees for specific diseases, resembling the flowcharts sometimes seen in clinical guidelines. Two significant problems plague this strategy: (1) any change in guidelines requires complete rewriting and testing of the code; (2) every new disease requires starting from the beginning with a newly coded decision tree. We took an entirely different approach, separating the algorithmic logic of chronic disease treatment programs (represented by code and reflected in an interactive user interface) and the specifics of individual diseases (represented by data). The process of treating diseases is abstracted and generalized as follows:

1. Treatment programs are assigned one or more treatment targets (Figure 1(a) and (i)), which may be a device measurement (e.g., BP), a laboratory value (e.g., hemoglobin A1c), target doses studied in clinical trials (e.g., angiotensin-converting enzyme inhibitor dose in heart failure with reduced ejection fraction) or symptoms (e.g., chronic stable angina).

2. Achieving a target requires a series of pharmacologic (Figure 1, center panel) and non-pharmacologic interventions (e.g., low potassium diet and calorie-restricted diet).

3. Pharmacologic interventions (medications) have annotated inclusion criteria, exclusion criteria, and typically many titration schedules (Figure 1(b)), defined by starting and ending doses, frequency, and titration intervals. Medications are also characterized by a list of possible side effects.

4. Side effects for medications have structured data capture (questionnaire) and treatment plans that reuse a series of actions—for example, dose reduction, temporary discontinuation with resumption of the lowest dose, and discontinuation with restriction.

5. The ranking of pharmacologic and non-pharmacologic interventions depends on patient characteristics (Figure 1(a) and (iv)). For example, type 2 diabetes mellitus with kidney disease will have a different medication prioritization ranking than type 2 diabetes mellitus with atherosclerotic cardiovascular disease or heart failure.

Figure 1.

(a) Software interface used by providers and care navigators in a sample patient. Highlighted are (i) program targets, (ii) structured inputs needed for treatment recommendations, color-coded by program, (iii) diagnostic questionnaires to capture limited medical history relevant to treatment recommendations, (iv) patient conditions that impact medication choice for the included programs—these are output by the software based on diagnostic questionnaire responses, (iv) automatically determined ICD10 codes and hierarchical coding category scores used to define patient complexity in many value-based care contracts. (b) Sample titration schedules for medication are defined by frequency, starting and ending dose, and days between dose changes. The software-recommended schedule, based partly on meeting the indicated criteria, is indicated by a green check mark. Providers may choose an alternate schedule. (c) Patient journey indicates stage transition dates, treatment choices, and program medications at each stage. (d) Schematic showing patient enrollment by the Community Health Worker (CHW), remote software-enabled comprehensive blood pressure control by the remote team, and handoff back to the primary care provider.

Because of this deliberate separation between treatment logic and individual treatment program data, new disease treatment programs merely require developing a knowledge base of pharmacologic and non-pharmacologic interventions and a ranking (described below)—but otherwise, they can use the same underlying logic and the same software interface. Consequently, new treatment programs take weeks to develop rather than months or years, and the recommendations readily reflect the latest specialty guidelines.

The software knowledge base

To date, the following programs have been developed in the CKM space:

1. Cardiac: HTN, heart failure (reduced and preserved ejection fraction, including GDMT and volume management), atrial fibrillation and atrial flutter rate control, anticoagulation, aortic disease, chronic stable angina.

2. Metabolic: type 2 diabetes mellitus, hypercholesterolemia, iron deficiency anemia, obesity (focused on GLP-1 RA).

3. Kidney: chronic kidney disease (eGFR protection), vitamin D deficiency, secondary hyperparathyroidism, anemia of chronic kidney disease, hyperkalemia, hyperphosphatemia.

The construction of a program requires the specification of one or more targets and typically detailed annotation of medications. The number of medication classes and medications varied per program. HTN requires annotation of 475 medications across 26 classes (including combination medications), type 2 diabetes comprises the description of 189 medications across 15 classes, and heart failure has 154 medications across 11 classes. As described above, each program has one or more ordered rankings of medications, which represent the order in which classes would be started (and individual medications started within classes) depending on patient criteria.

Decisions such as which titration schedule to recommend or which ranking to recommend, as well as whether inclusion or exclusion criteria of individual medications are met, depend in turn on other inputs, such as laboratory measurements (e.g., eGFR) and device measurements (e.g., recent heart rate), pregnancy and breastfeeding status, and other diagnoses (Figure 1(a) and (ii)). Thus, a given program requires representing all such inputs, which are a mixture of objective measurements and questionnaire data.

Finally, for every side effect–medication pair, a recommended treatment action is provided, such as reducing the medication dosage, temporarily holding the medication and restarting after some criteria are met, and permanently stopping and restricting the medication. For example, the recommended action for ankle edema with amlodipine is dose reduction; for cough with lisinopril, a dose-equivalent transition to an angiotensin receptor blocker is recommended. A complete program includes a recommended plan for all such pairs.

Medication recommendation algorithm

The medication recommendation algorithm attempts to systematize the logic behind treatment guidelines. The software has pre-defined all inputs needed to make a medication recommendation for a program, including a combination of laboratory values, device measurements, demographic information, and questionnaires regarding existing symptoms and comorbidities. One of the user interface’s goals is to capture the minimum needed for a guideline-consistent decision to be made for a given program (Figure 1(ii)). This parsimony contrasts with an Electronic Health Record (EHR), which passively represents all patient information and requires users to sift through it to find what they need. Additional programs may require further inputs, but in general, there is considerable overlap between different programs (e.g., heart failure with preserved ejection fraction and HTN), which results in increasing efficiency as more programs are managed concurrently (Figure 1(ii), multiple colored dots). The software has a recency expectation for all measurements, which depends on patient characteristics. For example, whether an available estimated glomerular filtration rate (eGFR) is considered recent enough to be used depends on past variations in eGFR, recent minimum eGFR, existing medications, and existing comorbidities. The software highlights the values it believes need updating—however, the provider can override these based on personal risk tolerance and the difficulty of obtaining new data. Once all requisite inputs are provided, the software presents a medication recommendation (Figure 1(a)—black card shown for one program).

The medication recommendation algorithm distinguishes Category A medications with class-specific mortality or morbidity benefit for one or more patient indications (Figure 1(a) and (iv)) and Category B medications, which address the primary treatment target, but without class-specific morbidity or mortality benefit. For example, in type 2 diabetes mellitus with chronic kidney disease, a sodium-glucose cotransporter 2 (SGLT2) inhibitor would be Category A, while a sulfonylurea would be Category B. The recommendation logic is as follows:

1. If a medication with morbidity or mortality benefit (Category A) meets inclusion criteria, it is recommended.

2. If there is no Category A medication (or the patient is already on all of these) and an existing medication is not a maximum dose (as determined by the titration schedule), the software recommends the uptitration of an existing medication.

3. If no Category A medication exists and all existing medications are at a maximum dose, the software recommends initiating a Category B medication. Consistent with treatment guidelines, Category B medications that address more than one comorbidity (e.g., HTN and rate control in atrial fibrillation in a patient with uncontrolled heart rate—Figure 1(a) and (iv)) are preferred over those that address only the program indication (i.e., HTN).

4. If a Category A medication is precluded by an existing Category B medication (e.g., carvedilol vs atenolol in heart failure with reduced ejection fraction), a dose-equivalent substitution is proposed.

5. A proposed medication is checked against a list of patient-level restrictions at all these steps. Restrictions extend the concept of allergies and include medications not tolerated because of side effects or patient or provider preference. Intolerances have a finer level of control than allergies and can be dose-specific. For example, if the user has leg swelling above an amlodipine dose of 5 mg, a dose-specific restriction of amlodipine as an ingredient can be set at 5 mg (by the software or user).

Treatment stages

Every program follows a consistent set of stages, as described below (Figure 1(c)). This structure ensures a predictable progression through the treatment program, which is essential for maximizing scale and program outcomes. On any given day, navigators and providers prioritize those tasks (and those patients) needed for stage progression. Moreover, consistency in the patient journey allows navigators and providers to rapidly move to the next step required for a given patient without reviewing multiple notes. Finally, stages facilitate reporting to track productivity metrics (e.g., number of patients with >X days spent in stage Y).

1. Data intake: demographic data is gathered, patients are equipped with home devices if required, historical laboratory data is obtained, and medication reconciliation is performed. The software captures all specific data elements needed for a guideline-consistent decision for a given treatment program. Elements missing or not considered sufficiently recent by the software require an active override by the provider. A subset of this data is typically pulled from an EHR but requires additional annotation, including corroboration with the patient.

2. Medication baseline: The software makes a treatment recommendation and captures a baseline set of additional medication-specific details related to potential side effects. For example, before initiating amlodipine, a short baseline peripheral edema questionnaire is captured. To meet FDA requirements for decision support, ⁸ a transparent rationale is provided for any medication recommendation, including a link to specific treatment guidelines (including page numbers). Providers may decline the recommendation and either (i) input a medication restriction and request a different software recommendation or (ii) initiate their own recommendation within the software.

3. Medication initiation: the date of medication initiation, which determines the timing of subsequent stages, is captured by the care navigator. Any obstacles to starting a medication (pharmacy problems, reluctance) are identified and resolved at the time. Medication orders and templated notes reflecting pertinent data and rationale (including references) are automatically written to the EHR.

4. Early toxicity check: an early check on side effects is performed for frail patients, usually 2–3 days after medication initiation.

5. Medication evaluation: A structured assessment is performed at a pre-determined interval from the medication starting date, as specified in the titration schedule. This involves semi-quantitative capturing of side effects and evaluation of the medication’s efficacy targets (relative to baseline). Based on these evaluations, the next step is proposed, such as initiating a new medication, up-titrating an existing medication, launching a toxicity plan, or moving the patient to maintenance and monitoring.

6. Maintenance and monitoring: Patients at goal have periodic check-ins by the navigator to ensure the availability of prescriptions, review the medication list, and survey possible late-developing side effects. The software monitors targets, and patients may re-enter the active treatment stage if needed.

Patient flow

Typically, navigators perform Data Intake onboarding tasks (explaining program expectations, gathering demographic, care team, and pharmacy information, device ordering and activation, and medication reconciliation), and capture some elements required for the Data Intake stage. This takes approximately 45 min. Next, in a single call lasting 15 min plus 3 min per additional program, providers complete the Data Intake and Medication Baseline stages and start the Medication Initiation stage. A prescription is generated by the software and signed by the provider, and automated notes are generated and sent to the primary care provider and any other care team members. On a subsequent call or via text message, the navigator confirms the Medication Initiation date (exactly when the medication was started) and may capture the patient symptoms to complete the Early Tox Stage. Providers perform the Med Evaluation stage, which typically takes 5 min. Given that getting patients to the program goal requires 4–8 titrations, the total time provider time required is minimal, and rapid iterative titrations result in patients reaching goals in <12 weeks. Moreover, the lower-cost navigators are available to maximize patient engagement, overcome logical obstacles to care, gather complaints and concerns, and provide targeted reminders focused on measurement and medication adherence.

Additional software features

The software also includes:

1. Automated determination of ICD10 codes—used for risk adjustment in some value-based care contracts (Figure 1(a) and (v)).

2. Automated generation of a full treatment summary, including medications and doses, side effects, and diagnoses to facilitate prior authorization of medications.

3. Presentation of a graphical treatment journey, including all medication changes and side effects (Figure 1(c)).

4. Structured capture of social determinants of health (SDOH).

5. Automated ingestion and parsing of laboratory reports in PDF form from Quest and LabCorp.

6. Transparent explanations for all software recommendations.

7. Pragmatic trials: all patients receive six random labels (A vs B, C vs D, etc.). Medication rankings can be altered to reflect these labels to conduct factorial randomized trials within the software for quality improvement. For example, patients with label A may receive a different generic angiotensin receptor blocker than those with label B.

8. Two-way synchronization (read-write) with EHRs.

A HTN quality improvement pilot

We used this software in a clinical workflow to manage HTN in the context of a proof-of-concept quality improvement project. Ethical approval was not sought for the present study because it meets criteria for quality improvement activities following guidance provided by the U.S. Department of Health and Human Services (https://www.hhs.gov/ohrp/regulations-and-policy/guidance/faq/quality-improvement-activities/index.html). From April 2022 to January 2023, we launched a single-arm interventional pilot focused on BP control in collaboration with the Detroit Association of Black Associations (DABO). Written informed consent was obtained from all subjects before the study. Specifically, all patients provided digital informed consent to receive care in the context of a time-limited BP control program. The primary tracked measure was the proportion of enrolled individuals at the end of 12 weeks who met the Healthcare Effectiveness Data and Information Set (HEDIS) quality measure BP goal (<140/90), as this directly impacts payer ratings by the Center for Medicare and Medicaid Services. We also captured the number of medications at baseline and goal and the proportion of patients measuring BP at the recommended frequency.

Patient identification

Community Health Workers screened patients for HTN. Screening sessions occurred at neighborhood locations and events held at the community center. CHWs were supported by a nurse practitioner if any medical needs arose. Inclusion criteria consisted of patients above the age of 18 years with uncontrolled BP (a systolic BP > 140 mmHg or diastolic BP > 90 mmHg on two distinct measurements). Exclusion criteria included (1) not having the capacity to sign an informed consent form; and (2) not having sufficient visual and hearing ability to be managed remotely via telehealth. Informed consent was obtained in person, with the help of a tablet, to capture an electronic signature.

Those who signed the informed consent form received a cellular-enabled BP cuff (Withings BPM Pro) for self-measured BP (Home Wi-Fi service or a smartphone were not required). Patients were encouraged to measure BP at least two times a day. All patients had a baseline comprehensive metabolic profile at the time of consent, collected by an on-site phlebotomist. Patients had a follow-up phone call with a care navigator who explained the remote pharmacologic management approach in greater detail, including program expectations. Patients were asked if they agreed to proceed with medical management via the program provider, and if so, an initial remote encounter was scheduled. Since the primary objective was evaluating the feasibility of using the software platform for BP control, those who proceeded to medical management were considered formally enrolled in the program. Medication management and laboratory testing were provided at no cost.

Social determinants of health

In addition to BP control, SDOH needs were captured with the help of a software implementation of the American Association of Family Physicians Social Needs Screening Tool (https://bit.ly/4aYcZLr), focusing on housing, food, transportation, utilities, childcare, employment, and finances. Patients with identified and addressable SDOH needs were helped within DABO (e.g., food assistance) or referred to external organizations that could provide aid.

Management

Patients obtained medications at local pharmacies and short-duration prescriptions were used until an optimal medication plan was achieved. If there were transportation challenges, patients were referred to local pharmacies that offered home delivery services. Navigators spoke regularly with patients about whether they were able to fill their prescriptions and whether they had any difficulty taking the medications as prescribed. After the attainment of BP goals and monitoring for an additional 4–16 weeks, HTN care was transferred back to the patient’s primary care physicians, who received a software-generated structured summary of the patient’s course in the program.

Statistical analysis

Summary statistics were computed for demographic details, number of anti-hypertensive medications, SDOH questionnaire data, proportion of patients at goal, and BP measurement adherence. Costs of the program were computed based on device costs and personnel costs for the provider and navigators.

Results

A total of 1609 patients were screened, 945 (59%) were found to have uncontrolled HTN, and 512 patients consented to join the program. The average age of consented patients was 61 ± 11 years; participants were more likely to be female (59%) and self-identify as Black (99%). Providers were available at the screening to determine whether immediate treatment or referral to urgent care or the emergency department was required. Patients found with HTN upon screening who declined to join the program were surveyed for underlying reasons. The primary reason was concern about multiple providers making treatment decisions for them, as many already had a primary care provider.

Among the 512 participants, home BP readings revealed the following distribution: 10% Stage 1 (SBP 130–139 mmHg or DBP 80–89 mmHg), 69% Stage 2 (SBP 140–179 mmHg or DBP 90–119 mmHg), and 21% Stage 3 (SBP >180 mmHg or DBP >120 mmHg). Of the 512 patients, 204 patients (39%) proceeded to a provider encounter. One hundred and sixty (78%) patients completed the program. At entry, the average number of anti-hypertensive medications was 1.5 ± 1.1, with only 12% of individuals taking no anti-hypertensive medications. Thus, the patients predominantly had been diagnosed with HTN but were not at goal.

The primary HEDIS BP goal was achieved in <12 weeks of enrollment for 141 participants (69% of those enrolled, 88% of those who completed the program). Of these, 74 patients (36% of those enrolled, 46% of those who completed) met the American College of Cardiology/American Heart Association Hypertension Guidelines (ACC/AHA) BP targets of ⩽130/80. The number of HTN medications at goal was 2.6 ± 0.7. Compliance with twice daily BP measurements, defined as the proportion of patients who had, on average, at least 5 of 7 days with two or more BP measurements, was 83%.

Regarding SDOH, 210 participants were screened and referred for services to address SDOH challenges. The most frequently described concerns were related to food (60%), digital connectivity (37%), utilities (30%), and housing (27%). When offered, assistance was accepted for >80% of services.

Discussion

Our program demonstrated the feasibility of a holistic approach combining technology-based systematization and scaling with a high amount of personal attention provided by CHW and care navigators and attention to obstacles to care, including SDOH, typically seen as outside of the purview of the medical profession. Medication-specific anticipated side effects were also monitored proactively, and the high frequency of medication titrations (every 7–10 days) resulted in patients seeing benefits rapidly. We believe that this concerted approach helps build the trust required for the behavior change to achieve chronic disease goals, which in this case represented regular BP measurement, promptly picking up medications at the pharmacy, reporting side effects, and regular medication adherence.

Our work builds on other algorithmic efforts for chronic disease management, including HTN, hypercholesterolemia, and heart failure.^9,10 The primary difference from other work is that this project took place outside of the context of a traditional academic medical center or integrated delivery network, in a setting where there are additional challenges to care, including lack of smartphone access or Wi-Fi, food and housing insecurity, and transportation limitations that interfere with obtaining labs and medications. There was, accordingly, heavy community-based involvement in management, with the participation of centers specialized in resolving SDOH gaps and the involvement of CHWs. We also infer from the published methods that the level of technology used was more limited than what we have developed. In terms of targeted BP control programs in under-represented communities, a recent study focused on BP control in African American and Latino patients post-stroke. ¹¹ They described a high success rate compared to their control group; however, their stated personnel and technology costs were approximately 5-fold those of our program ($1594 vs $325). We suspect that the software backbone of our approach is critical to making it cost-effective.

In our study, although there was a high proportion of achievement of the primary HEDIS quality measure BP goal, a smaller proportion reached the ACC/AHA target of less than 130/80 in the treatment timeframe. We note several reasons for this. The primary challenge was the inability to reach patients at the frequency needed for rapid medication titrations. A related challenge was that because of the high initial BP, a larger number of medication titrations, including potentially adding four or more medication classes to achieve tighter BP control. This would require many more medication titration intervals (and thus a more extended program duration) and was typically met with greater patient resistance.

We are nonetheless heartened by these initial results and believe a technology-based yet highly personalized approach has the potential to overcome the historic low attainment of GDMT, even in under-resourced populations. A compelling business case for targeted chronic disease management exists among payers (or payer-provider groups) who are in one of two groups: (1) those at risk for total cost of care, which may be impacted by successful GDMT (e.g., in heart failure); (2) those involved in government contracts (particularly Medicare Advantage) where plan ratings and therefore reimbursement per member are partly determined by HEDIS quality measures including BP target attainment, glycated hemoglobin target attainment, and adherence to anti-hypertensives, anti-diabetes medications, and statins. GDMT and quality targets have been difficult to attain in practice or require substantial decreases in panel size. The resources needed for rapid iterative titrations are unavailable for most providers, and there are few technology solutions for optimal decision-making and scaling. A service or software solution that enables quality metric achievement and/or reduced resource utilization at low cost would represent a valuable contribution to the market.

Moreover, technology-based approaches can do far more than managing single disease verticals. For example, they can enable the management of diseases across specialty boundaries, a necessity for patients with interdependent conditions such as cardiometabolic and renal disease. ¹² Furthermore, they bring us one step closer to realizing a learning system that can systematically identify and overcome gaps in effectiveness, thereby developing tailored optimal approaches to individual patient populations. ¹³

Limitations

The primary limitations of this study include the lack of a control group and the lack of sustained monitoring of BP control beyond the study’s limits. To address this, we are undertaking a six-state cluster-randomized trial comparing our intervention to usual care with a full year of follow-up. The relatively low proportion of initially consented patients who agreed to undergo medical management via the program (39%) is also a limitation, and it is challenging to extrapolate control percentages to the larger population, given possible selection bias.

Given attrition at multiple steps along our pipeline, systematic efforts are needed to improve enrollment. Along those lines, we have found that the proportion of patients who agree to join the program is much higher (>80%) when the recruitment overture is made by a nurse or provider familiar to the patient, although the throughput of enrollment is lower. In contrast, our experience with outreach by payer recruitment teams results in approximately a 20% enrollment rate with much higher throughput. Efforts that combine endorsement by the existing care team and yet maintain high volumes of outreach will be ideal and may require payer incentives for existing providers while supplying them with designated resources for outreach.

A final limitation is that a formal sample size calculation and justification were not performed.

Conclusion

We have developed a software platform for chronic disease management and demonstrate the feasibility of its use in a BP control program. Further work will be needed to evaluate the economic impact of the solution, test methods to maximize patient enrollment, and study the additional complexities of managing multiple concurrent conditions on the platform.