Healthcare is full of complicated processes built around equally complicated information. A single Medicaid case can involve eligibility requirements, financial documentation, income and asset verification, facility communication, agency requests, deadlines, follow-ups, case notes, reimbursement implications, and regulatory requirements. Multiply that by dozens or hundreds of cases, and suddenly the job isn’t simply processing applications. It’s managing an enormous amount of interconnected information while trying to recognize which pieces need attention first.

For years, I did that through experience, spreadsheets, reports, case notes, formulas, filters, aging reports, and a lot of mental organization.

Now I’m learning SQL, Python, database design, GitHub, APIs, and business intelligence, and I’ve realized something I didn’t expect when I started:

My healthcare career isn’t getting in the way of learning how to code. It’s teaching me how to do it.

I Was Asking Database Questions Before I Knew SQL

When I started learning SQL, the syntax was new, but the logic behind it felt strangely familiar.

Think about a Medicaid caseload as a dataset. Each case has attributes: applicant, facility, application date, eligibility status, income, assets, outstanding verification, follow-up dates, approval date, denial reason, financial exposure, and dozens of other pieces of information.

Working with that information requires constantly asking questions. Which applications are still pending? Which have been pending longer than expected? Which cases haven’t been updated recently? Which facilities have the greatest financial exposure? Which applications are waiting on documentation? Which cases require immediate follow-up?

For years, I answered those questions through spreadsheets, reports, filters, case reviews, and experience.

Then I started learning SQL and saw something like this:

SELECT *

FROM medicaid_cases

WHERE status = 'Pending'

ORDER BY application_date;

And suddenly it clicked.

I had been asking database questions for years. I just hadn’t been asking them in SQL.

The same thing happened as I learned WHERE, GROUP BY, COUNT, SUM, joins, and other SQL concepts. They weren’t just commands I needed to memorize for a course. I could immediately connect them to questions I’ve actually needed answered during my career.

That changed the way I approached learning.

Instead of asking, What does this SQL command do? I started asking, What healthcare question could I answer with it?

That distinction has made technical concepts much easier to understand.

Healthcare Taught Me to Look for the Exception

Compliance and Medicaid work train you to notice what doesn’t belong.

Sometimes it’s the missing verification holding up an application. Sometimes it’s a deadline approaching with no response. It might be a case that hasn’t been touched recently, a number that doesn’t reconcile, an application that should have moved but hasn’t, or a policy requirement that completely changes the outcome of an otherwise ordinary case.

Those exceptions matter because the consequences behind them are real. A delayed Medicaid application isn’t simply another row on a spreadsheet. It can represent months of unpaid reimbursement for a nursing facility. A documentation problem isn’t simply a missing field. It can determine whether eligibility can be established at all.

That same instinct is useful when working with data.

Suppose I run:

SELECT *

FROM medicaid_cases

WHERE days_pending > 45;

I’m not particularly interested in that query because it proves I understand a WHERE clause. I’m interested because I immediately understand the operational question behind the result:

Why are these cases still pending?

That leads to better questions. Is documentation missing? Is agency action pending? Does the facility need to provide something? Is there a recurring bottleneck in the process? Are certain types of cases taking longer? How much reimbursement is associated with those applications?

SQL can identify the records. Domain knowledge helps determine what questions should come next.

I’m beginning to understand that this is one of the biggest advantages I bring to analytics. I’m not learning how to work with data and then searching for a problem to apply it to. I already know the problems.

My Spreadsheets Were Trying to Become Systems

I’ve spent years creating and working with Medicaid Pending reports, payer aging reports, case trackers, formulas, lookup functions, conditional logic, and other Excel-based systems designed to answer operational questions.

At one point in my career, I was managing Medicaid eligibility and compliance across more than 10 long-term care and skilled nursing facilities while tracking hundreds of residents. Those spreadsheets weren’t decorative reports created so someone could admire a particularly impressive shade of conditional formatting. They existed because we needed to know what was happening.

Which cases were aging? Where was reimbursement at risk? What had changed since the previous review? What needed intervention? Which facility required attention? What documentation was outstanding?

Excel can do an extraordinary amount of work, and I still consider it an essential tool. But learning about databases and analytics made me start asking a different question:

What happens when the spreadsheet stops being the final destination?

What if the underlying information lives in a structured database? What if SQL handles recurring questions against that data? What if Python handles repetitive processing or transformations? What if a dashboard allows someone to immediately see where the greatest risk exists? What if AI can help organize and preserve case context without replacing the professional judgment required to interpret it?

Those questions stopped being hypothetical once I started building.

I’ve been developing projects around Medicaid Pending analytics and experimenting with ways to preserve weekly case context more efficiently. One of those ideas became an AI-assisted Medicaid Pending Weekly Update Log designed to turn scattered updates into organized case summaries, preserve what happened previously, and make the next action easier to identify.

The goal isn’t to have AI make Medicaid decisions. It shouldn’t.

The goal is to reduce the administrative friction surrounding the decision so the person responsible for making it has better information available.

That’s a very different use of technology.

Learning to Code Is Making Me Question Processes I’ve Accepted for Years

One of the strangest consequences of learning technology has nothing to do with syntax.

I’m reconsidering processes I’ve accepted as normal for years.

Healthcare workers become incredibly good at operating inside imperfect systems. When a system doesn’t quite work, someone creates a spreadsheet. When the spreadsheet doesn’t cover something, someone creates another tracker. When information has to move between systems, someone manually copies it. When nobody can remember why a step exists, everyone keeps doing it because apparently angering the ancient workflow gods is considered an unacceptable operational risk.

Eventually, the workaround becomes the process.

Learning to build has made me start looking at those workflows differently. Instead of asking, How can I perform this task faster? I’m increasingly asking, Why does this task exist in this form at all?

Could the information be captured once instead of repeatedly?

Could structured data eliminate some manual reconciliation?

Could a query surface the cases requiring attention instead of someone manually reviewing every case?

Could automation remove repetitive administrative work while keeping professional judgment exactly where it belongs?

Those are much more interesting questions than simply trying to make an inefficient process slightly faster.

And they’re questions I probably wouldn’t know to ask if I hadn’t spent years inside those workflows.

Domain Knowledge Changes What You Build

When I first started exploring analytics and technology more seriously, part of me thought I was beginning an entirely new career path. I assumed I would have to somehow catch up with people who had been coding for years and temporarily put my healthcare experience on a shelf while I became “technical enough.”

I don’t see it that way anymore.

I’m not replacing healthcare expertise with technical skills. I’m adding technical skills to healthcare expertise.

That distinction matters because domain knowledge changes the kinds of systems you imagine building.

I can learn SQL using a sample database filled with fictional customers and retail orders. There’s nothing wrong with that. It teaches the syntax.

But healthcare data means something different to me because I understand what can exist behind a row.

I know why an aging case matters operationally. I know why preserving case history matters when multiple people are involved. I know how a seemingly minor documentation issue can delay significant reimbursement. I understand why regulatory requirements cannot simply disappear because automation would make a workflow more convenient.

I also understand why AI needs boundaries in these systems.

There are tasks where AI can be enormously useful: organizing information, summarizing case history, identifying missing fields, structuring notes, assisting with repetitive documentation, or helping someone navigate a large volume of information.

Then there are decisions requiring professional judgment, policy interpretation, verification, accountability, and human oversight.

Knowing the difference isn’t primarily a programming skill.

It’s a domain skill.

And I’ve already spent decades developing it.

The Code Is Only One Layer

I’m still early in this technical part of my career, and there is an enormous amount I don’t know yet. Oddly enough, becoming more aware of how much there is to learn has made me less interested in collecting technologies simply so I can list them as skills.

I want to understand how they connect.

A database gives information structure. SQL allows me to interrogate that information. Python can transform data and automate parts of a workflow. APIs allow systems to exchange information. Business intelligence tools can turn rows of data into something a person can quickly understand and act on. GitHub gives me a place to document the work, track changes, and increasingly create a visible record of what I’m learning to build.

Once I started seeing those connections, the technologies stopped looking like separate courses on a learning roadmap.

They started looking like components of a system.

And systems make sense to me.

Healthcare taught me to think that way long before I ever opened a code editor.

Maybe Experience Isn’t Something You Have to Escape

There’s a common narrative around career transitions that suggests becoming something new requires leaving the old version of yourself behind.

Start over. Reinvent yourself. Choose a completely different path.

I’m beginning to think some of the most interesting transitions happen when you do the opposite.

You bring the old expertise with you.

My healthcare career taught me how to investigate complicated situations. It taught me to interpret rules, document decisions, recognize exceptions, track cases through long processes, identify risk, and understand that a number without context can be dangerously misleading.

It taught me to ask what happened, why it happened, what’s missing, who needs to act, and what happens next.

SQL is giving me another language for asking those questions. Python is giving me another way to solve some of them. Databases are giving me another way to organize the information. Dashboards are giving me another way to communicate what matters. Building projects is giving me a way to take problems I’ve thought about for years and finally experiment with better ways of solving them.

I originally thought I was learning technology so I could move beyond what I’d been doing.

Instead, I’m discovering something much more interesting.

I’m not leaving my healthcare career behind to learn how to code. My healthcare career may be the reason learning to code makes so much sense.

Follow What I’m Building

I’m documenting my transition from healthcare operations and Medicaid compliance into data, analytics, and technology through real projects.

Portfolio · GitHub · LinkedIn · Newsletter