Hello fellow Messorians,
If you ask a healthcare data analyst what they do all day, you'll get one of two answers. Either "I write SQL and build dashboards," which is true but very vague. Or a long, frustrated sigh, which is closer to the truth but also kinda vague.
The real answer is more interesting, and if you're a student, an early-career analyst, or a clinician thinking about pivoting into this work, it's the answer that will actually help you decide whether the role is for you.
Let me walk you through what a typical day actually looks like.
8:30 AM. Triage, not coding.
The first 30 minutes are almost never SQL. You open your inbox, your messaging app, and your ticket queue. Two things are usually waiting for you.
The first is an overnight pipeline alert. A scheduled data refresh failed, or finished with warnings, or completed but produced numbers that look wrong. You triage. Sometimes it's nothing. Sometimes a source system pushed a change that broke an upstream mapping and you'll spend the next hour figuring out which column suddenly has nulls.
The second is the stakeholder backlog. 3 people messaged you yesterday afternoon asking for "a quick number." None of these will be quick. Each one needs you to figure out what they're actually asking before you write a single line of SQL.
9:00 AM. The stakeholder meeting.
A clinical operations leader wants a report on something that sounds simple. Pick anything. "Show me our 30-day readmissions for heart failure patients."
This is where the job actually begins.
That sentence contains at least four definitions you have to nail down before you can pull a single row. What counts as a heart failure patient (primary diagnosis only, or any diagnosis on the encounter)? What counts as a readmission (any admission within 30 days, or only clinically related ones)? Which 30 days (calendar days, business days, from discharge or from admission)? Which hospitals (just yours, the system, partner facilities)?
The stakeholder will tell you "you know what I mean." You don't. They don't either. Your job in this meeting is to surface that gap before you go build the wrong thing.
This is the part nobody tells you about in school. The hard part of healthcare data work isn't the SQL. It's the translation between a clinical or operational question and a data model that wasn't designed to answer it.
10:30 AM. The actual SQL.
Now you write code. You query the EHR data warehouse, or your enterprise data platform, or whatever your shop runs on. You join encounters to diagnoses to discharge dispositions. You filter by date ranges. You handle the edge cases. You realize halfway through that the discharge disposition codes have changed over the last two years and you need to map the old codes to the new ones before any of this is comparable.
This is the part of the job that's most fun, if you like puzzles. It's also the part that's smaller than people expect. Maybe two to three hours of focused query work on a good day. On a bad day, much less.
12:00 PM. Validation, the part nobody respects.
You have a number. The question is whether you trust it.
This is where junior analysts get burned. You write a clean query, you get a result, you send it to the stakeholder. Then you find out a week later that the number was wrong because there's a sister table you didn't know about, or a flag that's set differently in inpatient versus outpatient data, or a single department that codes things their own way.
A good healthcare data analyst spends almost as much time validating a number as producing it. You cross-check against another source. You spot-check individual records. You compare to last quarter's number and ask whether the change is plausible. You ask a clinician whether the number passes the sniff test before you put it in front of leadership.
The unglamorous skill that separates a junior analyst from a senior one is this validation instinct. The senior analyst doesn't trust their own SQL until they've proven it three ways.
2:00 PM. The data issue.
Today's data issue is that you found something weird. The readmission rate for one of the cardiac units is suspiciously low. Either they are exceptional, or there is a coding pattern, a missing data feed, or a workflow change that explains it.
You spend an hour investigating. You pull the underlying records. You talk to the data steward for that source system. You find out that two months ago the unit changed how they document transfers, and your encounter logic is now counting some of them incorrectly.
This kind of detective work is most of the value an experienced healthcare data analyst delivers, and it's almost invisible to leadership. The number you reported is now correct because you didn't trust it. Nobody will know you saved the team from making a decision on bad data, but you did.
3:30 PM. The dashboard.
You update the dashboard for the leadership meeting tomorrow. Power BI, Tableau, Epic, whatever your shop uses. You add a filter, you fix a chart that was misleading, you write the tooltip that explains what the number actually means.
Dashboards are the most visible part of the job and the least intellectually interesting. They matter because executives will scroll through your work in fifteen seconds and make a decision from it. A good dashboard makes the right interpretation obvious. A bad one buries the lede. The skill here is editorial, not technical.
4:30 PM. Documentation and the next ticket.
You write down what you did. The query. The decisions. The exclusions. The edge cases. You do this because in three months somebody will ask you why the readmission number doesn't match a different report, and you need to be able to explain the difference instantly.
Then you pick up the next ticket and start the loop again.
What this job really is
If you take one thing from this, take this. The role is not "person who writes SQL in healthcare." It's translator, validator, and storyteller, with SQL as the underlying skill.
The people who thrive in this work are the ones who are comfortable sitting in ambiguity, asking good questions of clinicians and operators, and treating data as a clue rather than an answer.
If that sounds interesting, you'd probably be great at this. If you want a pure technical role where the question is well-defined when you receive it, healthcare analytics will frustrate you within six months.
The good news is that the job market for people who can do this well is wide open right now. The hidden news is that very few schools or bootcamps prepare you for the translation and validation parts, which are the parts that actually make you valuable.
Until next week.
Sharif
Founder, Informessor
