What six years in healthcare IT actually teaches you about data

When people ask what I do, I say I'm a software engineer in healthcare IT. The follow-up is usually something like "oh, like medical devices?" — and I spend the next two minutes explaining that no, I work on the data and systems layer that sits between clinicians and information.

After six years of it, here is what I actually learned.

Data is a people problem

Every broken pipeline I have debugged, every mapping error, every field that showed up null when it shouldn't have — almost all of them traced back to a human decision made years ago that nobody documented. A field named status that meant three different things across three systems. A date format that changed when a hospital switched vendors in 2019.

The hardest part of healthcare IT is not building the system. It's understanding what the data was trying to say before you got there.

The technology is the easy part. SQL, Python, REST APIs — these are solved problems. The hard part is sitting in a room with a clinician and a billing analyst and a compliance officer and figuring out what the word "discharge" means to each of them.

Domain knowledge is the real moat

I could be replaced by a better engineer. I could not easily be replaced by a better engineer who also understands HL7, knows why FHIR matters, and has spent time understanding why a nurse documents differently from a physician.

That combination — technical skill plus domain depth — is genuinely rare. It took me years to build and I did not fully appreciate it until I started talking to people outside the industry.

What I would tell someone starting out

Learn the domain, not just the stack. Sit with the people who use the systems you build. Read the error logs like they are trying to tell you something — because they are.

Healthcare data is frustrating, underdocumented, and frequently wrong. It is also genuinely important. That combination keeps me interested.