Clinical Decision Support for Heart Failure: from guidelines to code

Situation

Heart failure (HF) management requires frequent medication adjustments — titrating ACE inhibitors, beta-blockers, MRAs, and SGLT2 inhibitors to target doses while monitoring for contraindications, tolerability, and patient-specific comorbidities. The AHA/ACC guidelines define the framework, but applying them to individual patients demands integrating dozens of variables: vitals, lab values, prior titration history, contraindication flags, and adherence data.

The Vitally Health platform serves care managers who follow chronic heart failure patients remotely. The need: a decision support layer that could surface the next best medication action for each patient encounter, grounded in guidelines and tailored to the individual.

The translation problem

Clinical guidelines are written in natural language for clinicians. Converting them to code means resolving ambiguity:

• "Consider dose reduction if symptomatic hypotension" — what threshold? Which medication? Which timeframe?
• "Target dose should be achieved if tolerated" — how is tolerance assessed from structured data?
• Contraindication rules interact in complex ways: a patient might be contraindicated for one drug due to renal function, while another drug's dose calculation depends on the same lab value.

The first phase of the project was less about machine learning and more about structured clinical reasoning: working with clinicians to convert narrative guidelines into explicit decision tables, categorical encodings, and prioritized rule sets.

Design decisions

Why a hybrid rule-and-model approach?

Pure rule systems are transparent and safe but brittle — they can't generalize to edge cases not explicitly covered. Pure ML models generalize but are harder to audit and explain to clinicians and regulators. The hybrid approach layers ML ranking on top of rule-based filtering:

1. Rule-based filtering eliminates contraindicated or inappropriate options for a patient.
2. The ML model ranks the remaining options by predicted benefit, incorporating patient-specific context.
3. The output is a ranked shortlist with rule-based explanations for why certain options were excluded.

Encodings. Comorbidities, vital signs, lab values, and contraindications were encoded as categorical and ordinal features with clinically meaningful boundaries (e.g., eGFR thresholds from guidelines). This made the model's inputs interpretable and the feature engineering auditable by the clinical team.

Deployment. FastAPI + Pydantic for request validation and auto-documentation; AWS Lambda for serverless, cost-effective deployment that scales with usage; integration with the platform's existing patient data pipeline.

What I learned

The hardest part wasn't the ML. It was the knowledge engineering — taking implicit clinical expertise and making it explicit enough to encode without losing the nuance that makes guidelines actually useful. Two lessons stood out:

Explainability is a feature, not a constraint. In a regulated clinical context, a model that can't explain its recommendation is a model the care team won't trust and won't use. Designing for explainability from the start (hybrid rules + model, transparent encodings) made adoption easier.

The gap between research and production in healthcare is wide. The path from a working Jupyter notebook to a deployed service that a clinician trusts involves validation, auditability, version control for models, and careful handling of edge cases that a benchmark dataset would never surface. This project deepened my respect for that gap — and for the engineering discipline required to close it responsibly.