HealthLeap

HealthLeap screens every adult inpatient in a hospital, every day, for conditions that tend to slip past a one-time screen at admission. Our core product predicts malnutrition risk, by reading labs, vitals, notes, and various EHR data in order to write a daily risk score into the patient's chart each morning. This helps a dietitian start their day with the highest-risk patients at the top of the list, rather than having to sift through individual patient charts. Malnutrition is common in hospitals, and is also severely under-captured, leading to longer hospital stays and worse outcomes.

simulation

before healthleapafter healthleap

unassessedmild to severe

Hospitals today use nurse screenings and manual chart review to identify malnutrition risk. However, a majority of patients are never assessed by a dietitian, and many patients fall through the cracks due to missed reassessments on long hospital stays.

malnutrition diagnoses · live0 diagnosed · 0 missed · ~0/day

My journey to HealthLeap#

I joined in January 2026 to help my friend Tamir onboard two new hospital systems onto the HealthLeap platform. The existing machine learning pipeline, built by an engineering team that had all since departed, had trapped the world's best malnutrition models in a systems engineering mess. I was the first founding engineer of the new team, and helped establish some of the core technology and processes we use today. Six months later, we're at ~10 engineers, a much bigger overall headcount/office, and far fewer 3 am pages to the on-call engineer.

Some of my initial projects involved:

• Revamping our AWS infrastructure. Some resources existed in IaC (Terraform), while others were manually configured in the AWS console. I worked on bringing everything into IaC, and on hiring a founding infrastructure engineer who knows 10x more than I do.

• Removing wall-clock timing from the pipeline. Several stages of the pipeline depended on wall-clock timing - pull data from hospitals at 2 am, run the model at 3 am, update the dashboard at 4 am, etc. This meant that a slow or failed process could end up blocking the pipeline or passing stale data to downstream services. We ended up completely reworking the orchestrator (Dagster) so the pipeline runs as a data pipeline should.

• Integrating two hospital systems simultaneously. I thought adding a new hospital would simply be a matter of updating some configuration. By going through every detail of the integration process myself, I saw the full scope of customization that goes into every Epic deployment, as well as the organizational requirements for getting our changes approved by hospital leadership.

• SOC2 compliance. I created a "personal MCP" which combined Drata's public API and Notion's API to automate the documentation and evidence collection for a clean SOC2 report. This was my first time going through the entire motion of SOC 2 Type 2 end-to-end. The "final boss" of the SOC2 audit was the auditors themselves, since ours were quite intent on providing a thorough assessment.

Dimensionality reduction for clinical models#

One of my favorite projects was an investigation into dimensionality reduction of diagnosis codes that are used by our malnutrition risk model.

A patient's diagnosis history is one of the strongest signals the model has, and the obvious encoding is one feature per ICD-10-CM code. However, ICD-10-CM is a complex taxonomy with around seventy thousand codes, and any given patient only touches a few dozen. This leads to an enormous and sparse feature space, and one where the model does not generalize well on codes it hasn't seen before. For example, type 2 diabetes might be represented by hundreds of different codes that depend on the patient's associated complication. A model learning a separate weight for each of them generalizes from none of them.

Clinical hierarchies#

There are four clinical hierarchies that I've found useful in my past work in health information exchange:

• HCC categories are the condition-category hierarchy Medicare uses for risk adjustment.
• PheWAS phecodes come out of PheWAS research and group ICD codes into phenotypes.
• CCSR groupings are AHRQ's Clinical Classifications Software Refined, which buckets every ICD-10 code into a few hundred clinical categories.
• SNOMED subsumption rules are released in the UMLS metathesaurus, and describe subsumption ("is-a") relationships that can roll any concept up to a more general one.

Instead of feeding raw codes to the model, the pipeline rolls them up through clinical hierarchies that already exist: HCC categories, PheWAS phecodes, CCSR groupings, and SNOMED subsumption rules that walk a specific concept up to a clinically meaningful ancestor. Tens of thousands of sparse features became a few hundred dense ones that a clinician can actually read. AUROC and AUPRC both improved by 1-2% across our deployed models, and explainability features like SHAP values suddenly began surfacing meaningful patterns in both diagnosis and medication history.

Getting data from hospitals#

The model is only as good as the data reaching it, and the data lives in FHIR servers inside hospital networks. I work on the systems engineering between those servers and our machine learning team: pulling resources reliably, normalizing what comes back, and landing it in a shape the ML side can use. The goal is that a data scientist queries a table of lab results and never has to learn what a FHIR Bundle is.

Interfacing with hospital IT#

Every deployment runs through a hospital IT department, and in my time serving as the engineering point of contact for those teams, I learned a lot.

The most important learning was around "stakeholder management". Hospital IT teams are careful for good reasons, and they are stakeholders - if something goes wrong with an integration, they will share in our blame. I learned the importance of clearly communicating IT requirements from the mistakes of not clearly communicating our level of urgency. Communication shortfalls led to VPN access being delayed for a week due to a hospital IT member's holiday, a misconfiguration between our HL7 ADT interfaces, and more. If I might leave the reader with a lasting analogy of hospital IT teams, it is this:

Hospital IT teams are like the line cooks of a 3 Michelin star restaurant. They are under tremendous pressure to deliver on time and with a certain precision. They know their own station, and they know it completely. If you can put in your order for something and get the line cooks excited about what you're eating, you'll be satiated in a matter of weeks. If you falter or let your appetite get the best of you, you'll only be eating a few months from now.

Integrating with hospital IT involves security reviews, network access, service accounts, go-live scheduling, and live debugging sessions. When an interface stops sending data, the response to the hospital IT team must be immediate, but the ideal response is a preemptive. The best general advice for integrating with hospitals is to have extraordinary monitoring, because you will need to perform retroactive analysis from time to time.s

Every EHR is different#

Our hospitals mostly run Epic, and no two Epic installations are alike, but there is also the Smart on FHIR standard which is supported by virtually all modern EHRs. This allows a developer to configure different EHR constructs into a consistent vocabulary that is domain-specific to their requirements. One of my lasting realizations is that every integration requires an up-front analysis of where the exact required information lives in the EHR, and how to read it efficiently.

Dashboards to change behavior#

My current project involves developing analytics dashboards for hospitals to drive reimbursement revenue. Catching a patient earlier only matters if the care team acts on the flag, so the dashboards show what happened after the model fired: whether at-risk patients were seen, how long it took, and how that varies across units. The point is to give hospital leadership the evidence to change policy, and to give care teams a reason to change habits. A risk score in a chart is easy to ignore. A trend line in front of the people who set policy is harder to ignore.