Thanh Pham
4 min
Thanh Pham’s professional journey highlights the critical intersection of data engineering and real-world application. Starting with retail analytics at Target, Pham identified how data-driven insights into product placement and marketing strategies could optimize business outcomes. This foundational experience transitioned into large-scale data engineering at FPT Software, where the focus shifted to building a robust data platform for a national pharmacy chain. By utilizing dbt and PySpark, the team processed 4 TB of real-time data monthly, successfully standardizing information to World Health Organization requirements.
The project achieved significant technical milestones by optimizing database performance. By transitioning to a JSON-based storage architecture within MongoDB, the team reduced storage requirements by 98% and improved data processing speeds by over 30%. This architecture allowed for the seamless integration of real-time updates, which were essential for the pharmacy chain's operational needs. These improvements demonstrate the tangible impact of well-structured data pipelines on system efficiency.
Despite successes in data engineering, the transition to predictive modeling—specifically for vaccine scheduling—revealed the inherent difficulties of applying machine learning to complex medical datasets. Initial models, such as Logistic Regression and Random Forest, yielded only 35% accuracy. This limitation highlighted the need for more sophisticated approaches to handle the multifaceted variables of patient medical history and vaccination schedules. This experience serves as the primary motivation for pursuing advanced academic training in Data Science, with a specific focus on optimizing machine learning models for healthcare applications.
Sam: What does the paper propose as the path forward? [[RP_SECTION:multi-state-modeling-approach|Multi-state modeling approach]]
Alex: Multi-state modeling. Instead of treating prediction as a classification problem—vaccinated or not, at risk or not—you model patient care as a series of transitions between clinical states. That reframes the task from a static snapshot to a dynamic trajectory, which is what the clinical reality actually looks like. The argument is that the robust infrastructure provides clean, indexed data, but without a model that can reason about state transitions, you're either fast or accurate—not both.
Sam: That's a meaningful architectural shift. It also implies a tighter coupling between the data engineering layer and the clinical modeling layer than most pipelines are designed for. [[RP_SECTION:engineering-and-modeling-integration|Engineering and modeling integration]]
Alex: That's the core tension the paper surfaces. The engineering pipeline and the statistical framework were developed somewhat independently, and the mismatch showed up in the evaluation metrics. The infrastructure team solved their problem. The modeling team inherited a feature space that didn't encode the domain logic they needed. When those two roles aren't integrated from the start, you get exactly this outcome—a high-performance pipeline producing low-performance predictions.
Sam: Which is a sobering result for anyone building clinical decision support tools. The headline infrastructure metrics looked strong. The model utility didn't follow.
Alex: And that's the finding worth carrying forward. Speed and storage are engineering benchmarks. Predictive utility is a clinical benchmark. They don't automatically align, and this deployment is a clear illustration of what happens when you optimize for one without designing for the other. The next step—multi-state modeling integrated with that infrastructure—is where the real test begins.
Sam: Thanks for listening to ResearchPod.