Portfolio - Data, BI & Healthcare Analytics
I am a data analyst who likes getting past the surface of a number and figuring out what it actually means for the person making the decision. Since 2018, I have helped small businesses understand their traffic, customers, and marketing, then turned that information into reports they can use. I currently build reporting systems for a search and rescue organization in Alaska. I try to be direct about what the data supports, what it does not support, and when the sample is too small to trust. The aging and biology projects further down the page are where I go deepest. Each one starts by explaining the question in plain language before getting into the methods.
Filter by skill
Client analytics, Medicare policy analysis, hospital risk modeling, and tools built to support real business decisions.
My current work, for a search and rescue organization covering a remote part of western Alaska with no roads in. Six tools, each answering one question a search leader actually asks. The one I am most pleased with closed a gap that left iPhone users unable to either see or file a casualty request, because their version of the mapping app does not have that feature and cannot be modified. Rather than wait for a vendor, two small services use plain map markers as the transport, and the parser can tell the difference between a blank template and someone typing in a hurry, so it neither files an empty casualty nor throws away a real one. The rest covers a coverage model that reports a probability and refuses to declare an area searched, a callout report that will not claim a pattern until enough data supports it and hides counts small enough to identify a person in a small village, a vitals framework that raises attention but never calls an emergency on its own, and a crew board whose login fails closed because the alternative to a broken feature is a location leak. Published with the organization’s approval.
This is the only paid client project on the page, and it is the one I have worked on the longest. Since 2018, I have managed the analytics for a local alterations and tailoring shop. I built the website, set up the tracking, and create the reports the owner uses to decide when and where to advertise. Annual visits grew from 927 in 2018 to 3,020 in 2025, even with the shop receiving zero website visits for two straight months during the 2020 shutdown. Over time, the website also collected 399 contacts from people who had reached out to the business. We started using that list based on the business calendar, sending emails before prom and wedding season and during slower months when the shop had open capacity. Direct traffic later passed Google for the first time, which is consistent with more returning customers visiting the site. The full case study explains why that pattern matters, what it suggests, and why it cannot prove the emails caused the increase.
Medicare penalizes hospitals when too many patients return within 30 days of being discharged. I analyzed the government's results file for 3,055 hospitals to see what the scoring system measures and what it leaves out. More than one third of the records have no score because a hospital needs at least 25 qualifying patients before Medicare will grade it. That rule removes many small and rural hospitals from the program's view. The system also compares hospitals with one another instead of using a fixed standard, which means roughly half of graded hospitals will remain on the wrong side of the line even if care improves across the country. Finally, a hospital that performs badly for one condition is only slightly more likely to perform badly for another. That raises questions about treating six loosely related conditions as one measure of overall hospital quality. The analysis was built with SQL and Python, and the full code is published with the project.
A readmission happens when a patient returns to the hospital within 30 days of being discharged. Hospitals can be penalized when their readmission rates are too high. This project looks at which patients appear most at risk and answers the same question in six different tools. The dataset is a synthetic practice dataset containing 300 patients and was designed to resemble the structure of the Medicare program. Heart failure patients returned about 20 times more often than hip and knee replacement patients, who had the lowest risk. Patients with a follow up appointment also appeared less likely to return, but the difference was not large enough to support a confident conclusion. I reported that uncertainty instead of presenting the pattern as a proven result.
R logistic regression - Power BI dashboard - Python prediction model - Looker Studio - Google Sheets - Excel workbook
This dashboard looks at which employees are most likely to leave and where turnover is creating the greatest risk. I scored each employee using eight factors commonly connected with attrition, including overtime, pay, job satisfaction, and time with the company. I then built an interactive dashboard so managers could filter the results by department and explore the factors behind each score. Sales and Marketing showed 28 percent turnover, which was eight percentage points above the company's 15 percent target.
I built this tool to find potential clients for my own consulting practice. It runs daily, searches business listings across 1,037 cities in 38 states, and records the results in a spreadsheet that tracks outreach and follow up. The hardest part is not collecting the businesses. It is keeping the results clean. Nearby cities often return the same listings, so the pipeline has to recognize duplicate businesses and avoid counting them more than once. This is a production tool I use for my own work, not a practice exercise.
Independent research using public health and biological data to study how aging can be measured, what it predicts, and where the evidence is still limited.
The age of your body can differ from the number of years since you were born. This dashboard estimates biological age from a blood sample and shows which measurements are driving the prediction. Users can move a slider and watch the estimated age change in real time. On people the model had not seen during training, its predictions were off by about 5.7 years on average. On a completely separate group of 689 people, the error was 6.4 years. That second result matters more because it shows how the model performed on data that played no role in building it, so it is the result I lead with.
This project asks whether a body that appears older than its actual age is also at greater risk of dying. I tested that question using data from 28,510 adults in the United States who were followed by the government for as long as 19 years. The biological age estimate uses nine routine blood measurements available through a standard laboratory panel. Each additional year of biological age was associated with about a 4.5 percent increase in mortality risk. Biological age also predicted survival better than chronological age alone. The dashboard lets users filter the population by age and sex and compare the survival curves directly.
This project looks at which genes behave differently in older brain tissue compared with younger brain tissue. I found 119 genes whose activity changed reliably with age. Many of the strongest changes involved the material that insulates nerve fibers and helps signals move through the brain. The interactive explorer lets users search for any gene and see how its activity changed between the two groups. It also provides a plain language explanation of the gene's function using information pulled from the national genetics database.
Claims about supplements, diets, and fasting are everywhere, but the amount of attention an idea receives is not the same as the amount of evidence behind it. This tool grades longevity interventions using the same six criteria for every claim. It shows what has been tested in cells, animals, and humans, then compares the strength of that research with the intervention's popularity. Nothing receives the highest possible grade because that grade requires strong human research that follows people across an entire lifetime. No such study exists yet. Every score links back to the published research so users can review the evidence for themselves.
This is the modeling work behind the interactive aging clock. The project starts with roughly 450,000 chemical markers measured along the DNA of 656 people. The model narrows those markers down to 176 that are most useful for predicting age. On a completely separate group of 689 people, the average error was 6.4 years; on the held out portion of the training data it was 5.7 years. The separate group is the result that matters, because that data played no role in building the model. As an additional check, many of the markers selected by the model overlap with markers used by an established published aging clock. That overlap suggests the model identified a meaningful biological signal instead of only fitting patterns that were unique to its training data.
Aging does not affect every part of the body in the same way. It can even affect different cell types inside the same organ differently. This project examines mouse lung tissue one cell type at a time and compares age related changes across 11 cell types. The main methodological decision is just as important as the biological result. Individual cells from the same animal are not independent observations. Treating them as if they came from separate animals can make weak patterns appear statistically significant. This analysis groups the cells by animal and treats each animal as the unit of comparison, which avoids that mistake.
Web applications I designed, deployed, and continue to maintain for real users.
Loadout Oracle is a web application that lets Destiny 2 players share complete character setups with one link. It connects securely to a player's game account, retrieves live inventory data, and scores thousands of possible equipment combinations based on what the player is trying to build. The project also gave me experience maintaining a live application after launch. When an outside bot protection service started blocking legitimate traffic, I had to identify the cause and change the application so users could access it again.
CraftPath helps players make better decisions in a game where crafting an item can involve a large number of possible outcomes. The application calculates the odds of those outcomes and helps users compare their options before spending valuable resources. It is available as a browser application and as a downloadable version that uses live market prices. Building the calculation engine was only part of the work. I also had to manage releases, maintain versioned downloads, publish the repository, and make sure both versions stayed usable as the project changed.
Database analysis, dashboards, and earlier coursework that shows how my technical skills developed over time.
This project answers six business questions across four databases and uses the SQL techniques an analyst works with regularly. The most useful finding came from a mobile game dataset. A group of 210 players generated 52 percent of all revenue while representing only 9 percent of the players who spent money. That level of concentration changes how a company should think about its customers, retention strategy, and the risks of relying on a small group for most of its revenue.
This Tableau dashboard explores reported happiness across 156 countries and compares it with national wealth. Users can select a country, examine its individual results, and use the trend line to see how much of the difference in happiness can be explained by income. The project was built to be explored interactively rather than read as a fixed report.
This was one of my earlier analytics projects. It explores Grammy Awards data to look for patterns in who receives nominations and who wins. The analysis is straightforward, but the dataset gave me useful experience cleaning inconsistent information and turning it into charts that could answer a clear question. I keep it in the portfolio because it shows where I started and how my work has developed since then.
These are practice exercises from my coursework covering the fundamentals of working with data in Python. They include basic cleaning, transformation, analysis, and problem solving. I include them for completeness and to show the foundation behind the larger projects, not as one of the main portfolio highlights.
This nine part coursework series moves from basic data cleaning into statistical analysis and visualization. The exercises use sales, retail, and bike sharing data to build each skill in sequence. I keep the series in the portfolio to show the progression from early practice work to the larger independent and client projects above.