Clinical Decision Support LLM in Immunology
Advisor: Bhattacharya
Internship Location: Stanford University
Onsite Mentor: Dr. Holden T. Maecker, Professor of Microbiology and Immunology at Stanford University
The main goal of this project is to build an interpretable decision-support large language model that assists clinicians in immunology cases in hospitalized/ICU patients. While existing LLMs like BioGPT and Med-PaLM achieve near-expert performance on medical exams, they lack application in real-world clinical support. This research will help work toward creating an LLM that provides actual support in clinical decision-making by focusing on diagnosis and suggesting the next best steps and treatments for the patients. This work is significant because it could help future physicians rapidly narrow down potential causes for symptoms (especially in high-stress situations), improve diagnostic precision, and reduce medical error rates, which are currently estimated to contribute to up to 10% of all deaths in the U.S.. Conducted as remote computational research, I will complete this project at the Maecker Lab at Stanford University, with my External Advisor Dr. Holden Maecker, a Professor of Immunology and Microbiology.
To address this topic, I will utilize the Demo MIMIC-IV clinical dataset to build a transformer model that uses a self-attention mechanism to process the interconnected patient data. Initially, I will investigate the dataset and guideline documents, followed by implementing baseline models. I will then integrate RAG and SHAP into GPT-OSS for reasoning and recommendations by retrieving clinical guideline passages and passing them with structured patient features to the model, ensuring both credibility and interpretability. Finally, I will optimize the model through hyperparameter optimization and evaluate its performance through multiple metrics. I expect this work to produce an interpretable prototype capable of suggesting likely diagnoses and treatment steps given patient hospital notes and laboratory data, contributing to a vision of much more effective and personalized healthcare that also relieves the burden of clinician burnout and physician shortages.
Project Blog
Week 1: (2/23-2/27) - Welcome to my blog!
Welcome everyone! I’m Aanya, and this is my blog bringing you along my journey of creating an LLM, or large language model, for clinical decision support (specifically in immunology). First, let me give you some background on why I chose this project in the first place!
The potential for a model like this is amazing, and working towards building one is crucial because they could significantly improve our healthcare system. Currently, 47% of healthcare workers are burning out and there is an expected shortage of up to 124,000 physicians in the US alone by 2034. A new tool like this model would relieve the burden on the healthcare system and its workers. Especially in high-stress situations, such an LLM could improve diagnostic precision and reduce error rates by helping physicians narrow down potential causes based on patient symptoms, reducing hospital stays and accelerating recovery.
What am I even attempting to create? An LLM, or a large language model, is a type of natural language processing (NLP) model built from neural network architectures. Just like any machine learning model, it needs to be trained. In an LLM’s methodology, there are two critical phases: pre-training and fine-tuning. To summarize simply, the pre-training phase is where models learn by processing extensive amounts of unlabeled textual data, using different techniques to gain a deep understanding of the data. By the end, it will not only understand the meaning of, but also the context between the concepts that consist of the data it has been trained on (oftentimes different words and phrases).
To build a well-functioning LLM, massive amounts of general textual data and computational power are needed. Thus, I plan to apply an open-source LLM, GPT-OSS, that has already been pre-trained. To specialize it for our context, I will take advantage of the second phase: fine-tuning. Here, the model’s parameters are optimized using task-specific, labeled datasets of much more limited scale (like the one I will use in this project), enhancing performance on these tasks.
Even more specifically, our LLM will have a transformer model structure. This is defined by a self-attention mechanism: an encoder that processes the input data and encodes it into embeddings, which are then used by a decoder to understand the relationships among the data and generate output. By weighing the importance of different parts of the input, transformer models are able to process large amounts of highly interconnected information, which is highly useful with the complexity of medical data. You’ve probably heard of at least one famous transformer in computational biology – AlphaFold2, which predicts 3D protein structures from amino acid sequences by combining known information about preexisting protein structures and amino acid sequences. Similarly, there are models in genomics and single-cell data, like scGPT and Geneformer that are used for cell-type annotation, multi-omic integration, and investigating the behavior of gene regulatory networks.
Now, some of you might be wondering if LLMs are so prominent these days, why hasn’t such a model already been created? The research for large language models in clinical decision support is still highly limited (though promising!). BioGPT and Med-PaLM, designed by Microsoft and Google, have been trained extensively to achieve extremely high performance on medical exams (roughly 80%). However, they lack the application of clinical support, mostly used against question-answer tasks and medical exams rather than real-world data.
So, coming back to my main point, my goal with this project is to build an interpretable large language model that identifies potential diagnoses and suggests next steps for treatment based on all the available patient data. Interpretability is a key requirement and highlight of this project, important to emphasize in such a sensitive field. We should clearly be able to understand the model’s reasoning (how it is making its decision) and avoid the black-box issue common in machine learning. As these can be life-and-death situations, the aim will continue to be building a model for decision support, not meant to replace physicians with people’s lives in the balance.
With this plan, I started on my project. My plan for the first week involved reading through previous literature on building and processing a database of clinical practice guidelines for fine-tuning my model. I delved into a paper I had found promising, Developing search strategies for clinical practice guidelines in SUMSearch and Google Scholar [1].
My goal was to understand how to effectively search for medical papers (specifically called clinical practice guidelines or CPGs) that would form the database for fine-tuning my model. One key takeaway was the MeSH system. MeSH, or Medical Subject Headings, is the National Library of Medicine (NLM)’s established vocabulary used to search over the biomedical and health-related journals in MEDLINE and PubMed, allowing for much more precise and structured search that can highly improve search accuracy. The paper compared the use of MeSH terms + common terms for CPGs in two different search engines, SUMSearch and Google Scholar and found the common term “guideline” to be the best option. However, the outdated nature of the paper made it hard for me to trust the results. In fact, SUMSearch is no longer accessible, and so I looked into similar, more recent papers to see what progress had been since then and if more popular search engines/databases had appeared since then [2, 3, 4, 5].
However, this topic isn’t really explored, and it was difficult to find papers that addressed the same question. After reviewing a few papers, I found that phrasing searches in variations of the PICO format, a well-known standard for medical searches, are the most common. The only new search database I found mentioned in this literature (besides the original PubMED) was MacPLUS. PICO stands for population, intervention, control, and outcome, and it proves to be a useful way to effectively find CPGs as it provides specific, clear questioning. Here’s an example with each part defined:
In adults with type 2 diabetes (P, population), is intermittent fasting (I, intervention/treatment) more effective than a standard diet (C, control) in improving glycemic control (O, outcome)?
MeSH terms continued to be a prominent theme in my literature review, using boolean terms (and, not, or) to combine them with the search format. I knew then my next step is to go back to my own data and understand the patient data to pull or translate clear MeSH terms that I could then find CPGs for.
So, I introduce you to our dataset: the MIMIC-IV Demo Dataset. It is a set of de-identified electronic health records publicly available for analysis, recording the visit data of patients admitted to the emergency department or ICU for immunological problems in the Deaconess Medical Center. Through five different files/tables, it records demographic data, admission details, medication records, lab measurements, charting, procedures, and physician notes.
Investigating the data has introduced my first set of obstacles in this project. Each stay recorded has an ICD title. ICD, or International Classification of Diseases, is another system created by WHO to classify diagnoses, symptoms, and procedures. This leads to my first question: How should I convert the various ICD titles (there are 288 unique ones in the data!) to MeSH terms easily?
Thus, a main goal for me next week is to research the existence of systems or keys that have already done this, to avoid doing this manually. This would require a lot of biological research that could derail the timeline of my project. Another problem that arose was the existence of multiple ICDs for the same stay. When I found rows with the same stay ID, I investigated further and found that the difference was in ICDs, meaning that a patient was given multiple ICDs during their visit. This is my second obstacle of the week, and an aim for next week: understanding how to best process the data for the LLM so that the interconnected nature of the multiple ICDs, as they are based on the same symptoms, is understood.
Let me know your thoughts on how to tackle these issues! Next week, I will address these two issues and complete my search for the CPGs, finalizing how to find them and how they will be processed into the LLM.
[1] Haase, A., Follmann, M., Skipka, G., & Kirchner, H. (2007). Developing search strategies for clinical practice guidelines in SUMSearch and Google Scholar and assessing their retrieval performance. BMC medical research methodology, 7, 28. https://doi.org/10.1186/1471-2288-7-28
[2] Atkinson, L. Z., & Cipriani, A. (2018). How to Carry out a Literature Search for a Systematic Review: a Practical Guide. BJPsych Advances, 24(2), 74–82. https://doi.org/10.1192/bja.2017.3
[3] L. Martínez García, Sanabria, A., Araya, I., Lawson, J., I. Solà, Rwm. Vernooij, D. López, E. García Álvarez, Mm. Trujillo-Martín, I. Etxeandia-Ikobaltzeta, A. Kotzeva, D. Rigau, A. Louro-González, L. Barajas-Nava, Campo, del, Estrada, M., Gracia, J., F. Salcedo-Fernandez, Haynes, R., & P. Alonso-Coello. (2015). Efficiency of pragmatic search strategies to update clinical guidelines recommendations. BMC Medical Research Methodology, 15(1). https://doi.org/10.1186/s12874-015-0058-2
[4] Mancin, S., Sguanci, M., Andreoli, D., Soekeland, F., Anastasi, G., Piredda, M., & Grazia, M. (2023). Systematic Review of Clinical Practice Guidelines and Systematic Reviews: A method for conducting comprehensive analysis. MethodsX, 12(1), 102532–102532. https://doi.org/10.1016/j.mex.2023.102532
[5] Seguin, A., Haynes, R. B., Carballo, S., Iorio, A., Perrier, A., & Agoritsas, T. (2020). Translating Clinical Questions by Physicians Into Searchable Queries: Analytical Survey Study. JMIR Medical Education, 6(1), e16777. https://doi.org/10.2196/16777
Week 2: (3/2-3/6) - Deep Dive into Clinical Practical Guidelines!
Welcome back to my blog! This week, I will discuss how I completed preparing and cleaning the data, as well as looking more into how to look for and process the CPGs (or clinical practical guidelines).
The data was messy with many missing values and unnecessary columns. The few missing values perpetrated as the size of the data increased, as more information on each stay was added to the final data. Thus, I had to go back and clean the data, dropping irrelevant columns like medication class code. For the information recorded at triage and vitals taken during the visit, I dropped all stays with missing data, as there was no way to manually input these values or drop the entire feature. As I merged the data, I made sure to only include stays where information was available for all features.
As I mentioned in my last post, I was also looking for a system of conversion between the ICD terms of the MIMIC Demo-IV dataset and the MeSH terms used in searching for CPGs. Originally, I found an article that discussed a possible way through the ULMS (Unified Medical Language System) [1]. However, after discussing with my mentors and attempting to use the online system, I realized that the two terminologies were too different to have a direct conversion. ICDs are used by medical professionals for notetaking and patient records, while MeSH was created to help organize and look through academic research in medicine more easily.
Since there are too many unique ICDs in the data to manually search for MeSH equivalents or medical advice for each one, my new idea is to group the ICD titles into fewer, more general topics using AI. From there, I would find correlating MeSH terms for these larger concepts and search from there. I also plan to expand my search to systematic reviews and credible online sources like AMA, Mayo Clinic, and Cleveland Clinic, as these have already done the work of a thorough literature review and summarizing the results. Comparing the results of Gemini and Claude when the list of ICD titles and the purpose was inputted, I chose to use Claude’s classification. It provided 18 groups instead of 14, allowing more nuance without increasing the search needed by much.
The other problem was how to efficiently tell how much and which literature would be best for the LLM. In my literature review, I found that recent research has started using transformer models to retrieve the medical literature and improve their representation for input into the models [2] . These models extract the core information organized in a PICO format, and then assess the quality and ambiguity of the clinical recommendations in the literature, minimizing bias. Previous projects have used these models to create their own corpuses, huge databases of medical literature that have already gone through processing [3, 4].
For next week, I will continue investigating the best path forward regarding the medical literature needed to finetune the LLM. Maybe the strengths of these models (extracting the important information in the PICO format and labelling recommendation strength) can be combined to apply onto new medical literature I collect, though this may be limited by computational power.
If you have worked with LLMs before, let me know what advice you have for best preparing the input data for the model! Next week, I will learn more about machine learning, and make a final decision on fine-tuning the LLM before starting the process.
[1] Cimino, J. J., Johnson, S. B., Peng, P., & Aguirre, A. (1993). From ICD9-CM to MeSH using the UMLS: a how-to guide. Proceedings. Symposium on Computer Applications in Medical Care, 730–734. https://pubmed.ncbi.nlm.nih.gov/8130572/
[2] Xu, Z., Ma, H., Ding, Y., Zhang, G., Weng, C., & Peng, Y. (2025). Natural Language Processing in Support of Evidence-based Medicine: A Scoping Review. Findings of the Association for Computational Linguistics: ACL 2025, 21421–21443. https://doi.org/10.18653/v1/2025.findings-acl.1103
[3] Nye, B., Li, J. J., Patel, R., Yang, Y., Marshall, I. J., Ani Nenkova, & Wallace, B. C. (2018). A Corpus with Multi-Level Annotations of Patients, Interventions and Outcomes to Support Language Processing for Medical Literature. Proceedings of the Conference. Association for Computational Linguistics. Meeting, 2018, 197. https://pmc.ncbi.nlm.nih.gov/articles/PMC6174533/
[4] Read, J., Velldal, E., Cavazza, M., & Georg, G. (2016). A Corpus of Clinical Practice Guidelines Annotated with the Importance of Recommendations. ACL Anthology, 1724–1731. https://aclanthology.org/L16-1272/
Week 3: (3/9-3/13) - Lots Of Literature on CPGs and Machine Learning!
Welcome back to my blog! This week, I completed more literature review and came to a final decision on how to train the LLM on CPG textual data. I also started learning about the theoretical foundation behind the machine learning concepts I am applying in this project! As I mentioned last week, a major question was how to handle the clinical practice guidelines (CPGs). Specifically, I was confused on how to structure and process them before going into the model. I read through several papers to better understand how others have approached this.
One of the most useful was a paper on the Shiffman model, a 13-step framework (from 2004) for converting guideline text into clinical decision support specifications [1]. The steps range from selecting guidelines and marking them up, all the way to designing the user interface. The steps that required the most team discussion in real implementations were unique: guideline selection, user interface design, and verification of completeness. This aligns with the obstacles of my own project, because selecting valid, applicable medical knowledge is hard, and usability is what determines whether clinicians will even use the tool (something important to consider in the future if I decide to develop this LLM further).
The paper also proposed 8 new steps that the original Shiffman model missed, two of which are integral to my project. The first, guideline reconciliation, addresses what happens when multiple CPGs disagree with each other. The second, "Map Terminology," covers a challenge I already ran into last week: the fact that different systems (like ICD codes vs. MeSH terms vs. whatever the CPG uses) don't map cleanly onto each other. It was validating to see these are common problems in the growing field that researchers are struggling with, though the paper did not provide clear solutions.
Another paper introduced process mining, a technique for analyzing whether real-world sequences of care actually follow the steps laid out in a guideline [2]. There are three steps: process discovery (building a model from observed behavior), conformance checking (comparing real behavior to the expected model), and process enhancement (improving a model based on the data). Once my model is producing recommendations, I hope to learn more about the topic and see if process mining is a way to verify that following those recommendations would actually result in guideline-compliant care.
I also read a scoping review on fine-tuning healthcare language models, which reinforced my approach of domain adaptation, continuing a pre-trained model's training with healthcare-specific data [3]. However, it introduced a new issue: fine-tuning on a lot of knowledge-intensive data can actually hurt a model's ability to handle long-context understanding, because the model becomes more narrow and less exposed to diverse data and longer sequences. This matters for my project because clinical reasoning often requires synthesizing a lot of information at once. The paper highlighted RAG (Retrieval-Augmented Generation) as a key solution, which ensured that this is the right approach in our pipeline. This is because rather than trying to cram all clinical knowledge into the model's parameters, RAG allows the model to look up relevant information at inference time.
On top of all the literature, I also got through several key chapters of the ML textbook this week [4]. I focused on the sections most directly relevant to my project: Bayes' Rule and conditional independence (Chapter 2) and decision theory and loss functions (Chapter 5). Reading these back-to-back with the clinical literature was genuinely helpful. For example, understanding Bayes' Rule, where you start with a prior (ex: how common is a disease?), update with a likelihood (ex: given the disease, how probable is this lab result?), and arrive at a posterior (ex: updated probability after seeing the evidence), gave me a much better understanding of how the Bayesian Updating baseline will actually work.
With this background information, I decided that instead of manually collecting, processing, and annotating CPGs from scratch, I will use EBM-NLP directly (the publicly available dataset of 5,000 labeled RCT (Randomized Controlled Trial) abstracts annotated in PICO format that I discussed last week). Of course, I will have to make sure next week that it still applies to all the ICDs/clinical topics covered in the MIMIC-IV data. I will also create and train the first baseline model, logistic regression, which uses only the MIMIC-IV data and not the textual data of the CPGs. If you've worked with a pre-existing LLM corpus before, I'd love to know how you approached checking whether a corpus actually covers your target domain and how you applied it onto your own LLM!
[1] Tso, G. J., Tu, S. W., Oshiro, C., Martins, S., Ashcraft, M., Yuen, K. W., Wang, D., Robinson, A., Heidenreich, P. A., & Goldstein, M. K. (2017). Automating Guidelines for Clinical Decision Support: Knowledge Engineering and Implementation. AMIA ... Annual Symposium proceedings. AMIA Symposium, 2016, 1189–1198. https://pmc.ncbi.nlm.nih.gov/articles/PMC5333329/
[2] Vanwersch, R. J. B., Shahzad, K., Rojas, I. I., Pinggera, J., Mendling, J., Reijers, H. A., & Fahland, D. (2016). A process mining approach for clinical guidelines compliance. BMC Medical Informatics and Decision Making. https://pmc.ncbi.nlm.nih.gov/
[3] Kalyan, K. S. (2024). Health care language models and their fine-tuning for information extraction: Scoping review. JMIR Medical Informatics. https://doi.org/10.2196/58041
[4] Murphy, K. P. (2022). Probabilistic Machine Learning: An Introduction. The MIT Press.
Week 4: (3/16-3/20) - Corpus Selection, Baseline Models, and the Challenges Ahead
Welcome back to my blog! Today I’m going to discuss my progress for the week, which included finishing my machine learning book and taking a better look into implementing the baseline models, specifically logistic regression [1]. I also ran into some unexpected obstacles with the corpus I had decided from last week, EBM-NLP, that caused me to pivot.
One of the main goals from last week was to check if EBM-NLP covered all the topics in the MIMIC-IV dataset being implemented for this project. The authors detail EBM-NLP as a corpus with 5000 articles covering RCTs, which are randomized controlled trials) [2]. However, it mentions an emphasis on cardiovascular diseases, cancer, and autism. This is not reflected in MIMIC-IV, where trauma/injury, gastrointestinal, diabetes/metabolic disorders, and “other category” diagnoses were the most popular.
This led me to pivot to CREST, the other corpus I had found during this literature review [3]. The creators of CREST do not mention any specific biomedical topics, and pull from biomedical academic articles from the National Guideline Clearinghouse, a public database maintained by the federal Agency for Healthcare Research and Quality. This sourcing is actually more applicable to the project, as it is not just recent trials but scientifically-backed guidelines. I also plan on emailing the authors/creators of CREST and requesting the code (which is not publicly available), so that I can add in CPGs from my own online research when any possible gaps in knowledge are identified.
During this week, I also wrapped up the book I had been reading last week on machine learning. In Chapter 10, I reviewed the basics of logistic regression. It was particularly interesting to dive deeper into regularization, like L2 regularization, where the loss function is changed to punish large weights and thus prevent overfitting.
I covered Chapter 15, which is neural networks for sequences. I learnt about RNNs (recurrent neural networks) and LSTMs (long short term memory), the precursors to transformer models. I gained a much deeper understanding of how they create output sequences using context from both directions of the input through a “cell state” (essentially “long-term memory”) and “hidden state” (basically “short-term memory"), which are updated at each element using different “gates”. Chapter 15 also discussed how attention differentiates transformer models from previous sequential models, something I will look into more detail through next week in a different article.
Chapter 18 covered decision trees and Random Forests, explaining how they work via recursive partitioning, where the data is split into smaller and smaller groups by asking a series of questions. I learnt that a strength of Random Forest was bagging, where repeated random sampling is used at each node to prevent outliers from having a large effect.
I also learnt about Gradient Boosting, where the trees are built sequentially rather than in parallel (which is Random Forest). This is definitely something I will explore further as an alternative to Random Forest as a baseline model, as it essentially applies gradient descent to the decision tree structure by building each tree to fix the mistakes of the previous ones using residuals.
Finally, I started investigating how I would implement logistic regression with my cleaned MIMIC-IV dataset. I quickly ran into some issues that I would love any advice on. Since each patient stay has multiple ICDs, a simple logistic regression cannot be applied. Multilabel classification must be used instead, where the labels are non-exclusive. Luckily, this is possible with functions in the sklearn library.
However, this led to my next problem, as there are too many labels (almost 171). From the research I have done so far, I’ve found a couple of possible solutions for this, and I would love to hear any suggestions you might have as well! The first option is to use a one-vs-rest approach, where each ICD title becomes a binary target, and one logistic regression is trained per label. This is a common approach in multilabel classification, but with many ICDs appearing only once, there is several imbalance and so this could cause many problems. My current best approach is to take the labels which appear more than once (only 59), which are much more reliable targets (reducing sparsity and noise) and are thus much more practical for the scope of the project. If this doesn’t work next week, I will try using the general categories I have created for each label, though I would like to avoid this since it is quite a coarse classification.
The other problem I found was featurizing the temporal and categorical data, as their organization in arrays after cleaning the dataset is not a possible input for any of the machine learning models. After brainstorming, I think richer summaries like variability or range might be a better way than just mean or median in capturing the temporal nature of many of the features. For the medications (which are essentially categorical data), I could use the same multi-hot encoding that I plan on trying for the ICD titles. I will also try looking for pre-existing medical embeddings for drug names. If this exists, I could average the embeddings of all the medications in the array for each patient and thus capture their properties and relationships in one number.
Next week, I plan to continue researching how to featurize the data for machine learning models (as the cleaning has already been done). Please let me know your thoughts if you have run into any similar struggles or have any suggestions on how to quickly process my data. I will also take a deeper dive into the transformer structure with the original paper from 2017. Once the data has been appropriately featurized, I will much more efficiently be able to train the baseline models, hopefully by the end of next week!
Thanks for reading, and I hope to see you next week!
[1] Murphy, K. P. (2022). Probabilistic Machine Learning: An Introduction. The MIT Press.
[2] Nye, B., Li, J. J., Patel, R., Yang, Y., Marshall, I. J., Ani Nenkova, & Wallace, B. C. (2018). A Corpus with Multi-Level Annotations of Patients, Interventions and Outcomes to Support Language Processing for Medical Literature. Proceedings of the Conference. Association for Computational Linguistics. Meeting, 2018, 197. https://pmc.ncbi.nlm.nih.gov/articles/PMC6174533/
[3] Read, J., Velldal, E., Cavazza, M., & Georg, G. (2016). A Corpus of Clinical Practice Guidelines Annotated with the Importance of Recommendations. ACL Anthology, 1724–1731. https://aclanthology.org/L16-1272/
Week 5: (3/23-3/27) Feature Engineering Challenges and Unexpected Performance of Logistic Regression
Welcome back! This week was a large step into beginning to build the actual machine learning models I will train with the data. However, it was also a reality check in terms of how messy and unpredictable real-world machine learning can be.
My main goal this week was to finalize how I featurized the MIMIC-IV data and get solid baseline models up and running. While I made meaningful progress, my original plan has largely been delayed as a lot of things took significantly longer than expected.
The biggest time investment this week ended up being cleaning and transforming the data into something usable for machine learning models. Many of the features, especially vitals, were stored as string-encoded arrays, sometimes even with string values inside them (for example, something like `[“4.0”, 4.0]` instead of a numeric value). This meant I had to carefully parse each column, convert strings into actual arrays, and then decide how to summarize them.
For features that only contained a single value, I just extracted the float directly. But for features that represented temporal data (multiple values over time), I wasn’t sure what the right representation would be. After discussing with my external advisor, Dr. Maecker, and noting that most of the arrays had only two or three values, I decided to summarize the temporal features using the mean of each array and the trend (last - first). Thus, each of the original columns containing arrays of variable lengths were replaced with two columns of floats (numbers).
There were also smaller preprocessing decisions like handling missing values by imputing medians (as there were very few), capping extreme values (like pain scores above 10), and removing features that shouldn’t influence predictions (like subject IDs or timestamps of admission). I also encoded categorial features like race and gender using a label encoder.
For string categorical variables like medications, there were over hundreds of unique strings in each column. To address this, I used one-hot encoding on both columns, the medical record of the patient and the medications administered during the stay, but only after limiting it to the most frequent values (roughly those that appeared more than 10 times) to avoid extreme sparsity.
All of this took much longer than I initially expected. Once I finally had a clean feature set, I trained my first baseline model: a logistic regression using a one-vs-rest approach for multilabel classification across the most frequent ICD titles. I first considered only 59 ICD titles (the most common ones), as those are the ones that appear more than once in the dataset. Thus, I removed all other ICDs from the ICD_title column and then used a MultiLabelBinarizer to encode the labels (and the possibility of having multiple labels) effectively for the logistic regression.
Unfortunately, the results were not great. Although there was a training accuracy of 94%, the test accuracy was around 7.7%. The image below shows a more detailed view of the poor performance on some of the ICD titles, as the precision, recall, and F1 score (which together consider how well the model did at identifying false positives and false negatives) are largely zero. I believe this massive gap is due to severe overfitting, which is when the model essentially memorizes the training data and fails to generalize to the testing data as it does not gain any actual insights. I anticipated some drop in performance, but not to this extent. I brainstormed through a few possible reasons for this:
There are too many labels (the label space is too sparse), even after filtering.
The features available may not be informative enough in their current form.
Important temporal or relational structure in the data is being lost during featurization.
Overall, my main concern is that logistic regression might simply be too simple for this level of complexity. To see if this is true, I will try and fix the overfitting, and see how much that improves performance. I plan to reduce the label space further or try grouping the ICDs into their broader categories as I considered last week. I will also try and look for alternative feature encodings for medications and other categorical variables.
I would love some advice: if you’ve worked with high-dimensional, sparse, or multilabel medical data, what approaches have worked well for you? How do you balance simplifying the problem (fewer labels, aggregated features) with preserving meaningful clinical detail?
Alongside this, I also considered how I would implement the retrieval component of the project using CREST. The idea is to parse the guideline text, embed it into a vector store, and retrieve relevant recommendations based on patient data, weighted by importance labels (like strong vs. weak recommendations). This will eventually connect to the LLM component, but for now, my focus is on getting the baseline models working properly.
For next week, my goals are very clear: improve the logistic regression model and get more meaningful results, while also implementing and running the other two baseline models, Random Forest and Bayesian Updating, with proper hyperparameter tuning. I hope to see much better results. Stay tuned!
Week 6: (3/30-4/3) - Testing Baseline ML Models for ICD Classification (And Why They Failed)
Welcome back to my blog! This week was a very humbling one. As I finished training the baseline models, the results had a clear and unfortunate conclusion: models like Logistic Regression, Random Forest, and Bayesian Logistic Regression are simply not built for the complexity of this problem.
My first priority for this week was tackling the logistic regression performance, seeing how much I could fix the overfitting. I tried three different approaches. First, I dropped all rows that didn't have any of the top 59 ICD titles, which reduced the dataset from 126 to 106 rows. Training accuracy was 95%, but test accuracy dropped even further to about 4.5%. Next, I reduced the label space even more aggressively to only the top 16 titles (those appearing at least 4 times), leaving just 65 rows. Training accuracy remained high at 96%, but test accuracy fell to 0%. These approaches didn’t improve test performance, likely due to the large amount of rows not included with each filtering.
Finally, I tried grouping ICDs into their broader categories to reduce the label space while preserving some clinical meaning (though this was not ideal). Training accuracy dropped to a more reasonable 76%, but test accuracy was still completely zero. At this point, it was clear that reducing the label space wasn't fixing the fundamental problem, convincing me further that the model was just structurally too simple for this kind of high-dimensional, sparse multilabel problem.
Then, I tried to implement a Random Forest using the same MultiLabelBinarizer and MultiOutputClassifier setup, to see if it did any better. Unfortunately, the performance was again disappointing, with massive overfitting and zero test accuracy (1.0 train accuracy!). To fight this, I constrained the trees directly: setting a maximum depth of 5, requiring at least 5 samples per leaf, and at least 10 samples before each split. This brought training accuracy down to 0.83, a promising sign that the model was no longer just memorizing the training data, but this was not enough as test accuracy remained at zero.
That's when I had the idea to apply cross-validation to both models. Rather than relying on a single train-test split, cross-validation rotates through multiple subsets of the data (5-fold meaning five different splits), giving a much more reliable picture of true performance without overfitting. I also merged a few smaller ICD categories together, consolidating the three categories with fewer than 6 total occurrences and combining surgical & device complications with trauma & injury to reduce noise. The results were definitely better than the zeros I had been seeing before: logistic regression achieved a mean F1 score of 0.24, and random forest reached 0.16. However, they are still not clinically meaningful, reinforcing my original hypothesis. Both models are too simple to capture the complex, interdependent relationships between features that clinical reasoning requires. While disappointing, this takeaway actually showcases the need for the project’s more powerful approach of an LLM.
With the classical baselines exhausted, I started exploring Bayesian logistic regression. As I covered in my reading a few weeks ago, Bayesian updating lets you combine a prior belief with observed evidence to produce a posterior distribution over predictions, rather than a single point estimate. This is particularly well-suited to this problem: it handles class imbalance more gracefully, is more robust to overfitting with limited data, and provides interpretable credible intervals. While I didn’t hold a lot of hope, I wanted to confirm the performance before moving on to training the LLM. For my model, I assumed a prior of 0 for each feature coefficient as built-in regularization, and modeled each ICD label as a Bernoulli outcome since each is either applied or not.
My first attempt was to use the PYMC library, the standard tool for probabilistic programming in Python, but I kept running into installation issues even after resolving several dependency conflicts between libraries. So, as a workaround, I implemented a scikit-learn approximation: fitting logistic regression with L2 regularization across many bootstrap-resampled versions of the training data. In the end, it provides an excellent approximation of the results (posterior distribution of coefficient values) of an ideal Bayesian model from the PYMC library. Unfortunately, the runtime for this (with cross-validation) is much longer and so I was not able to include the results in this blog post, but I’ll dive into them next week!
In parallel, I've been working on installing GPT-OSS, the open-source language model I plan to fine-tune. I ran into a major compatibility issue with the torch library required to load models from HuggingFace. Investigating and debugging the problem, I found that torch couldn’t be installed with the Python version I had been using, requiring me to downgrade from Python 3.13 to 3.12. This allowed me to successfully install the model, which I’m very excited to start training next week!
If you've worked with Bayesian approaches on small or imbalanced datasets, I'd love to hear your experience and whether you faced similar issues. For next week, I plan on training GPT-OSS with the CREST corpus and the MIMIC-IV dataset, finally reincorporating the information that was lost in featurizing for the baseline models and (hopefully!) getting much clearer and clinically accurate results. Stay tuned for the blog!
Week 7: (4/6-4/10) - Switching Models, Bayesian Results, and Finally Prepping the LLM Inputs
Welcome back to my blog! This week marked a major turning point in the project: wrapping up the baseline models, resolving the last of the environment issues, and finally getting all of the input data ready to train the LLM.
To start, I confirmed the GPT-OSS installation, which came with its own set of debugging hurdles. I had accidentally created a virtual environment inside another one while troubleshooting last week, which caused a confusing chain of issues. The main problem turned out to be that my file was still running on the old kernel, so even after remaking the environments and fixing the version issues, nothing was actually updating until I restarted it. On top of that, I had to downgrade NumPy to a compatible version. After all of that, though, I ran into a more fundamental problem: running a model of that scale locally on my Mac would be painfully slow. So, I pivoted to using the HuggingFace interface instead, which allows me to access larger models with the limited computational power of my computer.
One thing I realized was that with the free version of HuggingFace, larger models are at a higher risk of timing out. This was a large motivation in why I switched from GPT-OSS to BioMistral as my initial LLM, a significantly smaller model that was specifically pre-trained on biomedical literature. Given the domain of this project, this feels like a much more natural fit than a general-purpose model, and its size makes it far more practical to work with given my computational constraints.
I also finally have the Bayesian logistic regression results to share. After running cross-validation, the overall macro F1 score came out to 0.1936 ± 0.0454. As I suspected, this is roughly the same as the logistic regression and Random Forest. This conclusively confirms what the past two weeks have been pointing to: classical machine learning models, regardless of how they are tuned or structured, simply do not have the capacity to capture the complexity of this data. While disappointing, it is also exactly the motivation for the rest of this project. The LLM approach is a necessity to build a potentially useful clinical decision support model.
With the baseline chapter now closed, I shifted my focus to preparing the inputs for BioMistral. The first major task was figuring out how to parse and format CREST for fine-tuning, which I plan to do in Google Colab (since fine-tuning can't easily be done locally on my Mac). The CREST files are stored as XML with HTML-formatted text, so I parsed through the files to extract the key components from each: the title of the paper, the developer (the organization that published it), the recommendation grade, and the actual recommendation text. These were saved into a unified dataframe.
When inspecting this dataframe, I realized that the recommendation grading system was not automatically unified. CREST pulls from many different sources, each using their own classification scheme, making it impossible to compare recommendations across guidelines without standardization. However, the CREST folder included a schemes.xml file that mapped each scheme ID to a general strength category. I went back into my file parsing loop to extract the scheme ID alongside each recommendation and wrote a function to apply this mapping, normalizing everything into a single system: strong, weak, moderate, consensus (meaning generally considered true among clinicians), and inconclusive. I dropped inconclusive recommendations, as they would not be useful or reliable inputs for clinical decision support.
The other big realization I had this week was clarifying how MIMIC-IV and CREST actually fit together in the pipeline, since I had been thinking about them somewhat interchangeably. They are actually serving two distinct stages. MIMIC-IV will help BioMistral learn to go from patient symptoms to a diagnosis, while CREST (paired with RAG) will support the second stage: going from a diagnosis to treatment recommendations, complete with the accompanying citation and strength of the recommendation. I also started exploring whether CREST could support the first stage too. Since many clinical guidelines do mention patient presentations, contraindications, and symptoms within the recommendation text, I could potentially use BioMistral to extract those symptoms from the CREST text, and then incorporate them into the first stage as well. This is something I plan to dive into first thing next week. I’d love to hear your thoughts or suggestions on using an LLM to extract structured information (like symptoms or contraindications) from unstructured clinical text.
For MIMIC-IV specifically, I worked on structuring the data as a text prompt for the model. The plan is to pass all numerical features as properties in the prompt of the model, while the textual values (like medications or chief complaints) will be incorporated directly into the prompt itself. Now that both dataframes (from CREST and MIMIC-IV) are formatted and ready, all of the input data is finally in place.
Next week, I will turn both dataframes into text prompts, make a final decision on whether to extract symptoms from CREST for the first stage, and train BioMistral on both pipeline stages. I plan to integrate SHAP and RAG into the first and second stage of the pipeline respectively. If you've used SHAP (or any other interpretability tool) on an LLM before, I'd love to hear your experiences and what tools you used, as well as if there is anything I should be prepared for. Stay tuned to see my progress!
Week 8: (4/13-4/17) - Clarifying the Pipeline With Text Prompts and the Initial Dive Into Interpretability
Welcome back to my blog! This week I finalized the text prompt formats for both datasets, dug deep into two important papers, and defined my pipeline even more, clarifying confusing steps in between. To start, I want to share what I learned from two papers I read this week on how incorporating interpretability would affect this project.
The first was a paper on retrieval-augmented generation, or RAG, in healthcare [1]. As I've mentioned in previous posts, I plan for RAG to be a core component of my pipeline, and this paper really explained why this is so important. The key idea is that RAG addresses gaps in a model's knowledge by pulling in relevant external medical knowledge at inference time, then using that evidence to generate a response. The standard pipeline has three steps: indexing (external data is chunked and embedded into vectors for a database), retrieval (the user query is encoded and matched to the most relevant chunks), and generation (the model uses both the query and the retrieved evidence to produce an answer). One of the most compelling points is that RAG is more flexible and easier to update than fine-tuning when guidelines or practices change. However, it’s important to keep in mind that it can still inherit bias from its retrieved sources and may perform poorly for underrepresented groups if the source material is sparse.
The second paper I read was the original SHAP paper, "A Unified Approach to Interpreting Model Predictions” [2]. SHAP focuses on a single prediction and assigns each feature a contribution score for that specific instance, combining the same underlying additive feature attribution idea of most explanation methods.
The features can be thought of like "players" in a game, where the payout is the model's prediction. A positive value means the feature pushed the prediction up, a negative value means it pushed it down, and the magnitude tells you how strongly it mattered. This is built on three axioms: local accuracy (the explanation should exactly match the model's prediction for the specific input being explained), missingness (a feature that is absent should get zero contribution), and consistency (if a feature becomes more important in the model, its attribution should not decrease). The paper also covers several variants, the most relevant being KernelSHAP, a model-agnostic method that explains any model by perturbing features and observing how the output changes.
However, the paper raises an important caveat: the explanation still depends on how "missing" features affect predictions, which doesn’t directly apply to an LLM as words cannot literally be removed without replacement. This caution applies directly to my situation, since integrating SHAP with an LLM is significantly harder than with a model like logistic regression, where numerical feature contributions are straightforward to define. This is something I plan to consider carefully next week as I decide whether or not SHAP can still be integrated.
On the data preparation side, this week was all about converting both MIMIC-IV and CREST into text prompts for fine-tuning. For MIMIC-IV, I decided to separate the vitals from the information recorded at admission, since they represent different types of patient data. I also chose not to include medications administered during the visit for now, saving that for Stage 2 when CREST enters the picture, though the patient's existing medical record is included. I also incorporated a trend label instead of just using the numerical value of the trend in the vitals. Since raw numbers for trends would be hard and confusing for a model to interpret, I created a label that simply classifies each vital as increasing, decreasing, or stable based on the values over time, making it much cleaner and easier for the model to understand.
For CREST, I similarly worked out a text prompt format to capture the key components from each guideline entry.
With both formats in place, I also updated my overall pipeline. I'm now redefining its phases: Phase 1 is continued pre-training (CPT) on raw MIMIC and CREST so that the model learns the medical domain. Phase 2 is instruction fine-tuning so that the model learns to predict ICD codes and generate recommendations, and it is in this phase I will incorporate RAG. With the given patient details, the model will predict the ICD diagnosis using the MIMIC text prompt above. Then, RAG will serve as the connection between MIMIC and CREST, matching the ICD of the predicted diagnosis to the CREST guideline topic using semantic similarity. Finally, the model would generate recommendations and corresponding strengths through the CREST text prompt, citing the retrieved guidelines with the developer of each recommendation.
This new Phase 1 is based on the new topic I discovered this week, where I learned and explored continued pre-training (CPT). CPT exposes the model to domain knowledge before fine-tuning on any specific task. So, in my project, it would give BioMistral general familiarity with both datasets before it has to learn the actual prediction task. After thinking through how to connect MIMIC and CREST between all three phases, I landed on an approach for the CPT stage: simply shuffle both datasets together. The model doesn't care about the order since it's just absorbing information, and the shuffled format encourages the model to keep both domains (the datasets and their formats) in mind simultaneously.
There are potential benefits to CPT: an easier learning curve for fine-tuning (since medical abbreviations and patterns will already be familiar by the time task-specific training starts), slightly better handling of rare ICD codes that appear only a few times, and better generalization overall. Still, the downsides are also worth noting: it takes extra time and compute, and CPT is generally most useful when you have large amounts of unlabeled textual data, which BioMistral has already seen in its original pre-training. I’m not sure how useful CPT will be, which is why I am running it this week to see if the compute is feasible before committing to it.
For next week, the big goals are integrating RAG to connect the MIMIC and CREST phases of the pipeline, and investigating whether SHAP can still be incorporated in a meaningful way given the move to an LLM. The numerical contribution of each feature is much harder to define in this context compared to something like logistic regression, so this will require some creative thinking. Stay tuned!
[1] Yang, R., Ning, Y., Keppo, E., Liu, M., Hong, C., Bitterman, D. S., Chiat, J., Shu, D., & Liu, N. (2025). Retrieval-augmented generation for generative artificial intelligence in health care. Npj Health Systems, 2(1), 1–5. https://doi.org/10.1038/s44401-024-00004-1
[2] Lundberg, S. M., & Lee, S.-I. (2017). A Unified Approach to Interpreting Model Predictions. Semantic Scholar. https://www.semanticscholar.org/paper/A-Unified-Approach-to-Interpreting-Model-Lundberg-Lee/442e10a3c6640ded9408622005e3c2a8906ce4c2
Week 9: (4/21-4/25) - Closing the Loop: Implementing RAG and Executing the Pipeline
Welcome back to my blog! This week was a productive one, where I finally closed the loop on several major open questions from the past few weeks. I made a final decision on SHAP, implemented the full RAG pipeline, and structured all of the code for the project into a clean, working system.
Firstly, I continued my reading on interpretability, this time through Christoph Molnar's Interpretability book [1]. One of the main takeaways was that there is actually no single mathematical definition of interpretability. Molnar frames it through two lenses: a cause-based definition (the degree to which a human can understand the cause of a decision) and a predictive one (the degree to which a human can consistently predict the model's result). The need for interpretability is because a correct prediction alone does not fully solve the underlying task, extremely relevant to clinical decision support where understanding the reasoning is just as critical
He also discussed the various types of interpretability methods. He distinguishes between intrinsic methods (where interpretability is built into the model structure itself, like a decision tree) and post hoc methods (where interpretation is applied after training). He differentiates between the scope of interpretability as well, from understanding a single prediction all the way to comprehending the entire model's behavior. He also touches on what makes explanations feel "human-friendly", especially selected explanations focused on one or two key causes - something I kept in mind for my pipeline to eventually reflect.
One major question I had this week was whether SHAP could realistically be integrated into this pipeline. After careful consideration, I decided not to implement SHAP. The core issue is that SHAP requires a scalar output to attribute feature contributions to. Generative LLMs like BioMistral use tokens, not class probabilities, which means there is no clean scalar to attribute back to. On top of that, SHAP is computationally expensive, and running it on my local setup is not feasible. Finally, clinical features like lab values and vitals are often correlated with each other, which violates SHAP's core independence assumption and would make the attributions unreliable anyway. The RAG component still serves the same purpose of interpretability in a much more natural way: by finding and citing the specific clinical guidelines that informed each recommendation, the model's reasoning is transparent without needing a separate explanation layer.
That brings me to the main goal of this week: implementing the full RAG flow. The final version has five steps: First, A patient note rendered from MIMIC features is inputted into BioMistral. Second, BioMistral outputs a structured JSON containing an ICD diagnosis guess with an explanation and a retrieval query, a short text string used to search CREST. Third, CREST topics are retrieved using that query via FAISS (Facebook AI Similarity Search), a library that indexes vectors and finds the nearest matches to a query vector extremely quickly. Fourth, BioMistral is re-prompted with the retrieved CREST recommendation and its strength. Finally, BioMistral generates the final treatment recommendation grounded in those CREST guidelines, with inline citations of the developer and recommendation strength.
I used S-PubMedBert-MS-MARCO as the embedding model, a biomedical-specific model that understands clinical language natively and so is much better suited for this matching than a general embedding. Retrieval is performed over the concatenation of each guideline's title and text. The text helps overcome any vagueness in the title, while being truncated enough to stay within reasonable prompt lengths.
To keep everything organized and modular, I separated the overall pipeline of the project into four distinct notebooks.
Embedding with RAG - The first embeds every CREST guideline and then builds and saves the FAISS index. I tested this with a few sample queries, and the results were interesting: a vague prompt like "dehydration and weakness" returned fairly poor matches, while something more specific like "lung cancer" retrieved relevant, high-quality guidelines.
Fine-tuning Stage 1 (MIMIC) - The second notebook fine-tunes BioMistral-7B using LoRA (a computationally lighter way to finetune models) to predict, from a patient record, the ICD diagnosis titles, medications administered during the visit, and the short retrieval query for CREST.
Fine-tuning Stage 2 (CREST) - The third notebook adds a LoRA adapter trained on CREST guidelines to teach BioMistral the correct output format and habit for citation, specifically every recommendation must end with a developer and strength label. It is important to note that this adapter learns format and citation fidelity, not clinical correctness. It is trained on synthetic query and recommendation pairs derived purely from CREST rows, so no MIMIC patient labels are involved. Instead, two randomly chosen incorrect guidelines are included, and the model is trained to choose the correct one of the three.
Putting it all together - The fourth notebook wires everything into a single predict() function that runs a patient row through all five steps end-to-end.
Since both fine-tuning stages need to run separately (and take a couple hours), the full results will be included in next week's blog post once the entire pipeline is complete. With the CPT + fine-tuning, I am worried about having runtime issues (as I've seen others encounter), so I'd love to know what approaches you may have used to solve this! Mrs. Bhattacharya, my advisor, also suggested building the web app in parallel to display the input and output of the LLM. This week, I started planning that out. The app will take structured patient inputs (race, sex, chief complaint, pain scale, pre-existing conditions, medications, and vitals at both admission and during the stay) and output the diagnosis predictions sorted by recommendation strength.
Next week, I plan to evaluate the results of both fine-tuning stages once they complete, and build the web app using vibecoding. I'd love to hear from anyone who has worked on clinical LLM pipelines - specifically, how did you evaluate the quality of retrieval results, since it’s harder to decipher in a medical context? Stay tuned for next week!
Week 10: (4/28-5/2) - Implementing Fine-tuning, Building the Web App, and GPU Limits
Welcome back to my blog! This week had both exciting developments but also the runtime problems I had anticipated last week. I ran the fine-tuning stages for BioMistral, got a working demo of the web app up, and ran into many computational constraints.
My first priority this week was running the Stage 1 fine-tuning (on the MIMIC dataset). I started with 2 epochs to get a baseline sense of how the model was behaving.
The results were promising enough to push forward, so I decided to try 5 epochs to see if the model could squeeze out more learning without overfitting. The training and validation loss curves were promising, as both were decreasing. The larger drops and lower values for the training loss in comparison to validation loss (which was starting to stagnate) is something I plan to keep an eye out for, as this could be an early sign of overfitting, which is why I limited the number of epochs at this point. The image below only shows 4 epochs as the last batch (due to the number of rows in MIMIC) was not the same size, and so its output doesn't get printed in the table as it doesn't register it as a "full epoch" (though the training happened). I then got a first look at some example outputs from Stage 1!
The format and general clinical domain are solid, but the predictions are noticeably more vague compared to the ground truth. This actually makes a lot of sense given the constraints: MIMIC is a small dataset, so there's only so much the model can learn from it alone. The specificity should improve significantly once Stage 2 and RAG are integrated, as those will ground the model in the actual clinical guidelines. One specific example was that the model predicted morphine as a treatment but missed LORazepam, a sedative. Without context about the specific trauma (a car crash) or what the patient likely presented like in the moment, the model couldn't have reasonably predicted that one. Morphine for pain management post-surgery is still a reasonable clinical call, so this is still a good sign that the model is thinking in the right direction (though imprecise).
Moving onto Stage 2, things got complicated. I ran into GPU limits midway through training, which halted progress entirely while I waited for them to recover. Unfortunately, the GPU limit hadn’t reset a day or two later. So, after some research, I decided to pivot to Kaggle Notebooks, which has been a much more reliable environment. It has 30 hours of GPU time per week that resets weekly, access to the same GPUs, and wouldn’t stop mid-runtime like Colab would if I ran something overnight.
While dealing with the GPU situation, I also created my web app, which I had planned to start building in parallel. I created a PLAN.md file to vibecode the full webpage, which connects the predict() function in the pipeline notebook to the backend. The architecture uses a Next.js frontend, and to run the site, you run the final pipeline notebook, which prints an ngrok URL that gets added to the environment, and then launches a Docker container. Though a new URL is needed each time the website is launched, this should be fine for a demo.
I first built a dummy hardcoded version just to get a sense of how everything would look and feel before the model was fully connected.
Overall, the original dummy version looked really good. There were a few issues to clean up on the input side: fixing the race options, verifying the disposition and acuity options. After discussing with my external advisor Dr. Maecker, I also decided to switch vitals from mean and trend format to a direct list to make input easier. The updated webpage looked great, and I’ll make sure to revisit it again next week when I get my LLM to work.
As for Stage 2, the results from my first run unfortunately didn't save, which meant rerunning from scratch. Watching the loss curves more carefully this time, I noticed the model was overfitting at 5 epochs (training loss dropped sharply while validation stagnated), so I brought it down to 3 epochs and am considering trying 4 next (the image below only shows 2 epochs for the same reason I mentioned above). Unfortunately, when I went to run the full pipeline, I realized I hadn’t properly saved the adapters (the fine-tuning) from previous notebooks, meaning I will have to rerun everything this weekend and properly save the results. While this sort of setback is frustrating so late in the week, using Kaggle has still been extremely helpful and I’m glad it’s a quick fix.
I'm also thought about evaluation now that real outputs are close. A few approaches I considered: finding a test set with established "gold standard" answers to compare predictions against, sending input-output pairs to Dr. Maecker for a more expert review, and building a custom rubric around safety, actionability, and clinical appropriateness. Discussing with Dr. Maecker, I’ve decided to follow both of the latter options: making sure to look at all three tenets when considering the outcomes of the model. Here is a more detailed description of each tenet:
Safety = How safe the suggested treatment is and the balance of risk (how the suggested treatment could affect the person taking into account the actual chance of the potential diagnosis)
Actionability = How vague or specific the suggested next steps are (whether confirming diagnosis or providing a treatment)
Clinical appropriateness = Ranging from correct, partially correct, reasonable but suboptimal, or incorrect, it would detail overall how appropriate the treatment is for the patient
For next week, I plan to evaluate the outputs using the rubric above, and even consider hyperparameter tuning, though computational limits will constrain how much I can do this. If I am able to, I hope to optimize the learning rate and LoRA rank (essentially the amount of parameters of the model we are reevaluating (from pretraining) with fine-tuning). If you've done hyperparameter tuning under tight compute budgets, I'd love to hear how you prioritized what to tune and when to stop. Stay tuned for next week!
Week 11: (5/4 - 5/8) - Hyperparameter Tuning, Slide, Revisions, and Results!
Welcome back to my blog! This week was a lighter but still productive one as I wrapped up the project, focused on squeezing more performance out of the model through hyperparameter optimization, cleaning up the web app, and refining the project presentation.
The first thing I tackled was a few lingering issues with the web app. The main fix was removing the patient record that was incorrectly showing up at the end of the treatment recommendations output, which was cluttering the final display, alongside some general formatting cleanup. Small things, but they go a long way in making the demo feel polished.
The bulk of my time this week went into hyperparameter tuning, specifically experimenting with the LoRA rank and learning rate. My first experiment was increasing the LoRA rank from r = 16 to r = 32 for Stage 1. In LoRA fine-tuning, the rank controls how many trainable parameters are reintroduced into the model, and so a higher rank means more capacity to learn task-specific patterns. However, the results were disappointing: the results looked almost identical to before (the loss curves barely changed). This was a pretty clear signal that the bottleneck isn't the model's capacity, but rather the size and diversity of the training data itself.
I then tried adjusting the learning rate, bumping it up to 1e-4 to see if a more conservative update step would help. The loss curves immediately increased, so I brought it back to the original and am planning to stick to the current value of 2e-4. For Stage 2, I ran the same r = 32 experiment and saw severe overfitting, significantly worse than Stage 1, which confirmed that r = 16 is the right call for that stage too. At this point, I think the model has learned as much as it can from the available data. My next idea was to try increasing the max_seq_length from 2048 to 3072, since there's a chance that longer patient records and guideline texts are getting truncated, which could explain why the model keeps hitting a ceiling. However, the same loss results were found, proving a similar conclusion that the LLM has learned all it can. Below I've attached one patient case as a demo of the LLM's output!
On the presentation side, I spent a large part of the week working through feedback on my slides and decided to make the switch from Google Slides to Canva for a cleaner, better aesthetic. After seeing my cohort’s presentations, some ideas I have include: the main changes were adding title slides between sections to improve the flow, adding a dedicated research question slide upfront, and reordering the content so that the pipeline is explained before diving into the baseline models.
Looking at the slides as a whole, I'm also thinking more carefully about what context I can add. One thing that stands out to me is the “Next Steps” section at the end, which discusses how this project could fit into a broader ecosystem of AI tools in healthcare. Specifically, the connection to ambient clinical documentation tools (like Nuance DAX Copilot, Abridge, and Nabla) that listen to doctor-patient conversations and auto-generate clinical notes is really compelling. Pairing an LLM like mine with tools like those would allow the model to work with consistently structured, high-quality clinical notes, which is one of the biggest limitations of the current approach given how messy real-world patient data can be.
Finally, I sent the model's outputs to Dr. Maecker for evaluation using the rubric we discussed last week: safety, actionability, and clinical appropriateness. I'm curious to see how the outputs hold up under expert review, especially as the training data for this project was sparse. That feedback will be included in next week's post (along with the final presentation). Stay tuned!
Week 12: (5/11 - 5/15) - Final Takeaways: Reflecting on the Project and Making Final Fixes!
Welcome back to my blog! This is the last post before the final presentation, and I’m excited to walk you through my last week.
The main technical goal this week was addressing a critical flaw I had identified in the pipeline after receiving feedback on the demo outputs: the final recommendations were very off for all five patients.
After investigating further, I was able to pinpoint exactly where things were breaking down. In the original pipeline, Stage 1 was generating retrieval queries by just restating the predicted ICD titles, producing things like "guidelines for weakness, dehydration." These vague queries caused FAISS to default to whatever was most represented in the CREST index, completely ignoring the actual patient condition.
The fix was to replace those vague queries with proper clinical ones. I used the Groq API (specifically Llama) to generate MeSH-based boolean queries for each MIMIC patient using all the patient information from the note and the predicted ICD and administered medications. This meant things like ("Central Venous Catheter Infections" OR "Catheter-Related Infections") AND ("Antibiotic Therapy"). These became the retrieval query labels in the Stage 1 training data, so that when BioMistral fine-tunes on them, it learns to output specific clinical terminology instead of vague restatements.
The before and after results were pretty striking. After retraining Stage 1 on the improved labels, 4 out of 5 patients received at least partially relevant recommendations. Patient 5 (laryngitis) received a recommendation that included azithromycin, which exactly matches the ground truth medication. Patient 3 (dyspnea) received a COPD guideline that explicitly recommended investigating BNP and troponin to rule out congestive heart failure, which is the actual diagnosis.
That said, the results are still far from perfect, and I think it's important to be honest about that. Patient 2's foot infection still retrieved pressure ulcer guidelines despite the improved query, which points to a separate issue: the CREST index itself is imbalanced, with certain guideline categories heavily overrepresented. Patient 4 was also tricky. The recommendations weren't completely irrelevant, as they picked up on something real in the patient's medication history. However, they weren't safe or actionable for what the patient was actually presenting with, which is what matters most in a clinical setting.
Beyond the technical fixes, I also spent a significant chunk of this week rehearsing and refining my slides. Stepping back and looking at the project as a whole, I think the biggest thing I'm taking away is how much you learn from building something that doesn't fully work. The baseline models failing completely turned out to be the clearest possible evidence that classical ML wasn't the right tool for this problem, and that made the strongest argument for an LLM approach. Finding out that the retrieval query was the bottleneck, and being able to diagnose it and fix it was also really satisfying. I came into this project thinking the hardest part would be the model itself. It turned out the hardest parts were the data pipeline (as I spent weeks researching how to find and process clinical practical guidelines in the context of my project), and the retrieval design given the limits on the scope of my project, both in terms of computational power and data available.
Stay tuned - I will be posting the recording of my final presentation and my full GitHub on Sunday!
Post 13: Final Post: Presentation Recording & Thanks
Welcome back to my last blog! I've attached a recording of my final presentation, along with the slides and Github link to my code. I wanted to take a moment to thank my advisors Mrs. Bhattacharya and Dr. Maecker for their help throughout this journey. I'm so grateful for their guidance, which was truly essential in completing my project. Thank you to everyone reading for following along the last twelve weeks, I learnt so much from this project and hope you did too!
Github: https://github.com/aanya21gupta/senior-project
Slides: https://docs.google.com/presentation/d/10-QqIqgVWq2KurYazOa4t5vfl86sXLVf4MMS8C1njTY/edit?usp=sharing
Presentation: https://drive.google.com/file/d/1sF75V9w0xJNSmeQHEvhlbFo_RUUTr4BK/view?usp=sharing