Toward a Clinical Point of Care Tool for Managing Heart Failure

Abstract

Management of heart failure is a major challenge in health care. Optimal management of heart failure requires adherence to evidence-based clinical guidelines. The nearly 80-page guideline for heart failure management is very complex. As a result, clinical guidelines are difficult to implement and are adopted slowly by the medical community at large. In this paper we describe a heart failure treatment adviser system which automates the reasoning process required to comply with the heart failure management guideline. The system is able to correctly compute guideline- compliant treatment recommendations for a given patient. For each recommendation, justification is also given by the system. We illustrate the technical aspect of the implementation of the system as well as some primitive user interfaces associated with the system’s core functionality. A simulated case is presented with system-generated recommendations and justifications.

1. Introduction

Heart Failure (HF) is the inability of the heart to keep up with the demands of the body; as a result, an inadequate of amount of blood is supplied to the human body and pressure in the heart can rise. This can cause congestion of blood in the lungs, abdomen and legs. All of this culminates in symptoms of exercise intolerance. Half of the people diagnosed with HF die within five years¹. The cost of this disease to the economy is huge. Statistics show that there are 11 million physician visits and 875,000 hospitalizations per year due to HF. About 25% of patient with heart failure are readmitted to a hospital or visit an emergency room within thirty days of treatment.

Heart failure cannot be cured but only be managed. A standard approach to managing heart failure has been to have a committee of experts develop practice guidelines that all physicians should follow. American College of Cardiology Foundation (ACC)/American Heart Association (AHA) published the 2013 Guideline for the Management of Heart Failure and 2016/2017 Focused Update (refereed collectively as the Guideline)^2–4. The Guideline was created by a multi-disciplinary committee of experts who thoroughly reviewed the best available clinical evidence on heart failure management. It represents a consensus among experts on the appropriate treatment of heart failure⁵.

Although evidence-based guidelines should be the basis for all disease management⁶, physicians’ adherence to them has been very poor⁷. Studies showed that compliance is as low as 30% for most disciplines⁸. Based on these studies and our interview with the cardiologists, we believe the compliance with the Guideline among heart failure care providers is far from ideal.

Reasons behind the noncompliance with clinical guidelines include lack of awareness, lack of familiarity, lack of motivation and external barriers⁷. One major reason for the lack of familiarity is the complexity of the rules in the Guideline. Take one rule in the 2013 Guideline for example²:

“Aldosterone receptor antagonists (or mineralocorticoid receptor antagonists) are recommended in patients with NYHA class II—IV HF and who have LVEF of 35% or less, unless contraindicated, to reduce morbidity and mortality. Patients with NYHA class II HF should have a history of prior cardiovascular hospitalization or elevated plasma natriuretic peptide levels to be considered for aldosterone receptor antagonists. Creatinine should be 2.5 mg/dL or less in men or 2.0 mg/dL or less in women (or estimated glomerular filtration rate >30 mL/min/1.73 m²), and potassium should be less than 5.0 mEq/L. Careful monitoring of potassium, renal function, and diuretic dosing should be performed at initiation and closely followed thereafter to minimize risk of hyperkalemia and renal insufficiency”

We believe it is impossible for humans to follow all the statements described in this nearly 80-page guideline even if they want to. Our claim is backed up by recent advances in both psychology and cognitive science. According to prior research conducted by Halford et al.⁹, a model defined by 4 variables is at the limit of processing capacity of human mind. The Guideline, however, has around 40 variables associated with HF mortality and morbidity, which obviously exceeds this limit. In addition, the mental model theory holds that it is much harder for humans to establish a conclusion about what is necessary than about what is possible¹⁰. In evidence-based HF management, the healthcare providers’ job is to give necessary treatment plans while strictly following a 80-page guideline, which is extremely hard, if not impossible. Likewise, establishing the safety of pharmacological treatments is error-prone since humans tend not to consider all possibilities when it comes to contraindications.

The contribution of this paper is the implementation of the justification functionality of the heart failure treatment adviser system¹¹ along with the system’s graphical user interface. The purpose of the system is to help overcome the cognitive difficulties faced by physicians in implementing the Guideline. The heart failure treatment adviser system automates all the rules in Guideline and thus able to give recommendations with justifications like a real human physician who strictly follows the Guideline, even under the condition of incomplete information about the patient¹². We adopted a novel and powerful programming paradigm called answer set programming (ASP)¹³ for developing the reasoning engine for the system. ASP facilitates the modeling of human-style commonsense reasoning¹⁴. Commonsense reasoning is non-monotonic¹⁵, which means that conclusions that were drawn earlier may have to be revised as more information becomes available. For example, normally ACE inhibitors should be given to a patient with heart failure with reduced ejection fraction (HFrEF)². But the care provider should avoid ACE inhibitors once he/she knows that the patient in question has a history of angioedema². Here the new information about the patient causes the care provider to modify her treatment plan.

We have conducted an experimental study involving 10 simulated and 20 real patients with heart failure to validate the efficacy of the heart failure treatment adviser system. Out of the 179 stage C recommendations made by the system, 168 are validated by expert cardiologists. The reasons for the missed and discordant recommendations are insufficient system input, knowledge outside the Guideline and differing reasoning style that were not modeled in the system at the time of validation. The details of validation and the corresponding analysis can be found in other publications^{12, 16}. Note that we illustrate in the paper how the heart failure treatment adviser system works by analyzing a simulated patient with heart failure.

2. Methods

2.1. HF Guideline

The Guideline has around 60 rules regarding the treatment options for heart failure. Those rules are categorized based on four progressive stages of heart failure. Treatment recommendations at each stage are aimed at reducing risk factors (stage A), treating structural heart disease (stage B) and reducing morbidity and mortality (stage C and D). In the Guideline, the relevant information about a patient includes²:

• 3 pieces of demographics information: gender; age; race

• 10 measurements: weight; creatinine; potassium; left bundle branch block; non left bundle branch block; QRS duration; ejection fraction; NYHA class; ACC/AHA stage; sinus rhythm

• 25 types of HF-related diseases and symptoms: sleep apnea; acute coronary syndrome; myocardial infarction; diabetes; stroke; fluid retention; angioedema; ischemic attack; thromboembolism; elevated plasma natriuretic peptide level; asymptomatic ischemic cardiomyopathy; atrial fibrillation; myocardial ischemia; lipid disorders; acute profound hemodynamic compromise; obesity; angina; threatened end organ dysfunction; ischemic heart disease; structural cardiac abnormalities; atrioventricular block; hypertension; dilated cardiomyopathy; volume overload; coronary artery disease

The possible recommended treatments are the following²:

• 13 pharmacological treatments: Angiotensin Converting Enzyme (ACE) inhibitors; Angiotensin Receptor Blockers (ARBs); Beta blockers; Statin; Diuretics; Aldosterone Receptor Antagonists; Digoxin; Inotropes; Anticoagulants; Omege-3 fatty acids; Hydralazine and Isosorbide Dinitrate; Angiotensin Receptor-Neprilysin Inhibitors (ARNIs); Ivabradine

• 9 management objectives: systolic blood pressure control; diastolic blood pressure control; obesity control; diabetes control; tobacco avoidance; cardiotoxic agents avoidance; atrial fibrillation control; sodium restriction; water restriction;

• 4 device/surgical therapies: implantable cardioverter-defibrillator; cardiac resynchronization therapy; mechanical circulatory support; coronary revascularization

2.2. ASP Implementation of HF Guideline

The heart failure treatment adviser system consists of two major components: rule database and fact table. The rule database covers all knowledge in the Guideline. The fact table contains the relevant information of the patient with heart failure such as demographics, history of illness, history of medication, daily symptoms, contraindications, risk factors as well as lab results. These information comes from two external sources: Electronic health records (EHR) and clinical notes. Currently the patient’s information is coded manually by system developer but automatic generation of ASP facts from the EHR and clinical notes is planned as future work.

Figure 1 displays the architecture of the heart failure treatment adviser system. When asked to give treatment options for a patient, the system generates a normal logic program by attaching the patient’s fact table to the Guideline rule document and then uses the ASP engine to compute the solution (answer set) of that program. The answer set includes all the guideline-compliant treatment recommendations for the patient in question.

Figure 1:

The architecture of heart failure treatment adviser system

All the rules in Guideline are written in one of the forms of commonsense reasoning patterns. We identified and formalized seven reoccurring knowledge patterns across the Guideline¹¹:

• aggressive reasoning: make a recommendation if the conditions are met; no evidence of contraindication means there is no contraindication.

• conservative reasoning: make a recommendation if the conditions are met and the explicit proof of no contraindication is available.

• Anti-recommendation: a recommendation is prohibited if the evidence of at least one contraindication is present.

• Preference: make the first-line recommendation whenever possible. If not, use the second-line recommendation

• Concomitant choice: if a recommendation is made, some other recommendations are automatically in effect unless they are contraindicated.

• Indispensable choice: if a recommendation is made, some other choices must also be made; if those choices can’t be made, then the first choice is revoked.

• Incompatible choice: certain recommendations can’t be in effect at the same time.

Each single knowledge pattern is easy to understand and model, but the meaning of the conglomerate of them is not straightforward. For instance, ARBs may look reasonable due to one rule that dictates its prescription which follows aggressive reasoning pattern. But when ACE inhibitors are recommended for the same patient ARBs should not be included in the medication list because of a rule that prefers ACE inhibitors over ARBs which follows preference pattern. We make use of ASP to model the above knowledge patterns faithfully. The ability of ASP’s to model defaults, strong/weak exceptions, preferences, etc.¹⁴ makes it ideally suited for modeling these knowledge patterns.

ASP is a declarative programming paradigm for solving hard combinatorial search problems and automation of reasoning which are primarily NP-hard¹³. A rule in ASP program follows the form

$$p:-q_1,\dots ,q_m,not{r}_1,\dots ,not{r}_n.$$

where m ≥ 0 and n ≥ 0. The part before “:-” is called the head of the rule and the one after “:-” is the body of the rule. Each of p and q_i (∀_i ≤ m) is a literal; each not r_j (∀_j ≤ n) is a literal of default negation. A negative condition not r_i is shown to hold by showing that the positive condition r_i fails to hold. It is read declaratively as a logical implication: p if q₁ and …and q_m and not r₁ and …and not r_n. Note that default negations not p is different from classical negation ¬p. Their difference can be illustrated by coding a simple piece of commonsense knowledge: a school bus may cross railway tracks if there is no approaching train. Using classical negation to express this rule looks like:

$$cross:-\neg train$$

It means it is okay to cross the railway if we know explicitly that no train is approaching. Had we used default negation, the rule would be:

$$cross:-\neg nottrain$$

It says it is okay to cross the railway tracks in the absence of information about an approaching train.

An example of ASP can be seen in Figure 2. The solution, or the stable model of this program is {p, s}. The first rule in Figure 2 is satisfied by this solution because p is a fact. The second rule is satisfied because its body does not apply. The last rule is also satisfied because both of its body and head are true.

Figure 2:

An example of answer set program

The heart failure treatment adviser system was built based on two core concepts: recommendation and contraindication. A recommendation can be translated into an action or an activity that can be implemented and measured. A contraindication is a specific situation in which a drug, procedure, or surgery should not be used because it may be harmful to the person. We have observed four facts in the 2013 Guideline: (i) Multiple rules can trigger a recommendation; (ii) Multiple rules can lead to a contraindication; (iii) A recommendation of a treatment cannot be made if at least one contraindication for that treatment is present; and, (iv) A recommendation/contraindication can impact the recommendation/contraindication of other treatments^{11, 12}.

In the system, recommendations are naturally modeled at the head of a rule while contraindications are put at the body of a rule with either classical negation or default negation before them. With the help of knowledge patterns and core concepts, all rules in Guideline for the treatment of ACC/AHA stage A to D are systematically coded in ASP. For example, consider the following stage C rule²:

“In patients with a current or recent history of fluid retention, beta blockers should not be prescribed without diuretics.”

This rule can be coded using answer set programming as follows:

RULE 1: recommendation(beta_blockers, class_1): -

not absent_indispensable_choice(beta_blockers),

not rejection(beta_blockers), evidence(accf_stage_c),

diagnosis(hf_with_reduced_ef).

RULE 2: absent_indispensable_choice(beta_blockers): -

not recommendation(diuretics, class_1),

diagnosis(hf_with_reduced_ef), evidence(accf_stage_c),

current_or_recent_history_of_fluid_retention.

RULE 3: recommendation(diuretics, class_1): -

recommendation(beta_blockers, class_1),

diagnosis(hf_with_reduced_ef),

not rejection(diuretics), evidence(accf_stage_c),

current_or_recent_history_of_fluid_retention.

Note that the rules use default negation for the contraindication of beta blockers and diuretics. To illustrate the code above, let us study the behavior of the system for a patient who has heart failure with reduced ejection (HFrEF) and is in ACC/AHA stage C. According to the 2013 Guideline, our system would recommend beta blockers (RULE 1 & RULE 2). If we add the information that the patient has a history of fluid retention, then the system will add diuretics (RULE 3). However, if diuretics are contraindicated for any reason, the system would not recommend beta blockers either (i.e., these rules will be taken out of consideration). The rule above actually follows the indispensable choice pattern in which if a choice is made, some other choices must also be made; if those choices cannot be made, then the first choice is revoked.

3. Results

The following analysis is based on a simulated patient with heart failure. Suppose there is a female patient who is in ACC/AHA stage C, belongs to NYHA class III and has been diagnosed with myocardial ischemia, atrial fibrillation and coronary artery disease. She also suffers from sleep apnea, fluid retention and hypertension. Her left ventricular ejection fraction (LVEF) is 35%. There is evidence that she has ischemic etiology of heart failure. Her electrocardiogram (ECG) has sinus rhythm and a left bundle branch block (LBBB) pattern with a QRS duration of 180ms. The blood test says her creatinine is 1.8 mg/dL and potassium is 4.9 mEg/L. She has a history of stroke. It has been 40 days since the acute myocardial infarction happened to her. Her doctor assessed that her expected survival duration is about 3 years. The above facts are stored as logic program atoms in the system as shown in Figure 3.

Figure 3:

Representation of a patient’s information in heart failure treatment adviser system

To present the patient’s information in a human-readable manner to a physician user, a look-up table is used to map the atoms in Figure 3 to English phrases or sentences. Below are some excerpts from the look-up table:

evidence(male)=The gender is male

history(ischemic_heart_disease) = History of ischemic heart disease

diagnosis(atrial_fibrillation) = Atrial fibrillation

contraindication(beta_blockers) = Beta blockers are contraindicated

The effect of using such a look-up table can be seen in Figure 5, which displays the patient’s information in English. Next step is to get all guideline-compliant treatment recommendations for this patient. The system computes the solution (answer set) for the normal logic program that consists of the facts in Figure 3 and all the Guideline rules. The computed answer set is shown in Figure 4. The guideline-compliant recommendations can be easily extracted from the original answer set by performing simple keyword matching on atoms starting with “recommendation”. Note this patient is in ACC stage C so measures listed as class I recommendations for her in stage A and B are also recommended where appropriate. To save some space we list only the answer set for stage C.

Figure 5:

Display of a patient’s information in GUI

Figure 4:

Answer set computed by the heart failure treatment adviser system

The final list of treatment recommendations is displayed in GUI as in Figure 6, which is self-explanatory.

Figure 6:

Recommendation shown in GUI

For any recommendation given by the heart failure treatment adviser system, the justification can be produced by the underlying ASP engine called s(ASP)^{17, 18}. s(ASP) system’s query-driven nature makes it only explores the reasoning space that is needed to reach a recommendation. Therefore the justification, essentially the reasoning trace, for a given recommendation is naturally available on demand. For instance, the justification for the implantable cardioverter defibrillator (ICD) in Figure 6 is shown in Figure 7:

Figure 7:

Justification shown in GUI

4. Discussion and Conclusion

In this paper we illustrated the implementation and some primitive user interfaces of the heart failure treatment adviser system. The system takes a heart failure patient’s information as input and produces a set of guideline-compliant treatment recommendations as output. For each recommendation given by the system, the justification (reasoning trace) is available on demand.

Efforts are being made to refine the system so that it can serve as a point of care tool for physicians to use during a clinic visit to augment care via real-time feedback of guideline-compliant HF treatment recommendations and contraindications. As has been discussed, even when the clinical guidelines are readily accessible, the complexity of the rules in guideline makes it virtually impossible for physicians to follow them faithfully. This issue is further compounded by the fact that clinical guidelines are updated with new discoveries and knowledge. In the case of guideline for heart failure management, it has been updated in 2016 and 2017 since its debut in 2013^{3, 4}. The heart failure treatment adviser system faithfully mimics the reasoning that an unerring human physician would perform in treating a heart failure patient while precisely following the Guideline. This system, functioning as a competent assistant for human physicians, is undoubtedly helpful in improving their compliance with clinical guidelines.

We foresee that the system can be quite useful in several scenarios. It can help the patients manage their conditions in regions where heart failure specialists are inadequate. The system can also be further developed into an educational tool that allows cardiologist trainees to practice heart failure management in a safe environment. In a previous publication we illustrated the realization of abductive reasoning in the heart failure treatment adviser system¹⁹. The ability to perform abductive reasoning enables the system to gives real-time clues to help user correct their non-guidelinecompliant treatment plan. On the population level, the system can be used as a powerful analysis engine that provides feedback to clinical leadership and health system administration regarding the overall quality of heart failure care. For example, the system can provide the summary of clinical performance of heart failure care over a specified period of time. This serves as a foundation for audit and feedback, which has been proven effective in enhancing the adoption and implementation of clinical practice guidelines.²⁰.

There have been earlier attempts to develop such clinical decision support system to manage HF^{21, 22}. HEARTFAID²³ was an European project that modeled European guidelines using Semantic Web Technology.

Future work includes adding interfaces for EHRs and clinical notes to our system. Automatic generation of patient information as ASP facts from EHRs and clinical notes is necessary for this system to become a point of care tool in clinical practice. Popular medical data exchange standards such as HL7 and FHIR will be used to interface the system with EHRs. It would also be helpful if the system not only points out what information is missing with respect to a care option, but also provides user with a link that fetches relevant results from the local EHR system. Automatic identification of relevant rules from the guideline for a given recommendation is also a nice addition which will make the system more informative to its physician users.