The Jobs Behind the Industry

A hospital's software team includes plenty of engineers who have never treated a patient, and its clinical staff includes plenty of doctors and nurses who have never written a line of code. Both groups build health tech every day, just from different ends: engineers ship the record system, clinicians decide what has to appear on the screen during a three-minute visit before the next patient is waiting.

Neither group alone gets it right. An engineer who has never sat through a real appointment will build a form with fields nobody fills in correctly. A clinician who has never seen a database schema will ask for something that takes six months instead of six days. The gap between those two mistakes is where an entire category of job exists.

Clinical informaticists are usually nurses or doctors who moved into software, and they are the ones who catch that a dropdown menu is going to get misread at 2 a.m. by someone on their fourteenth patient of the shift. On a Tuesday, that might mean sitting in on a nurses' shift-change meeting to hear which alert everyone has quietly learned to click through unread, then filing a change request against the exact screen that produces it.

Health data analysts turn years of visit records into an answer to a specific question — which patients are likely to miss a follow-up, which unit is running over budget — without needing to touch the underlying software at all. A Tuesday for one of them looks like a SQL query against last quarter's appointment data, followed by a fifteen-minute meeting explaining what the number actually means to someone who does not read query results for a living.

Product managers on clinical software write the requirements an engineering team builds against, and the job is mostly translation: turning “nurses keep missing this allergy alert” into a specific, buildable change to a specific screen, then sitting through the engineering standup to defend why that change is the one worth doing this sprint.

Regulatory and compliance specialists decide whether a feature can ship at all under HIPAA or FDA rules covered later in this track — a role that barely exists outside regulated industries, and exists constantly here. Their Tuesday can be a single paragraph of a submission document, re-drafted for the fourth time, because one imprecise word changes what the software is legally allowed to claim it does.

Implementation and training specialists are the ones who actually go on-site when a hospital switches record systems, running a week of hands-on sessions for nurses who have used the old system for a decade and have exactly one shift to learn the new one. It is one of the few roles here that spends more time in a hospital hallway than at a desk.

None of the five roles above require the same degree, and most people who end up in one did not study “health tech” directly — there is rarely a major with that exact name. What actually prepares you is closer to a mix: a technical track plus deliberate exposure to how care happens.

This is the part career advice usually skips, and it changes how long a path takes. Data analysis, product management, and regulatory work do not require a clinical licence at any point — you can walk in with a technical or policy degree and never sit a nursing or medical board exam.

Clinical informatics is the mixed case. Plenty of working informaticists hold an active RN or MD and treat the role as a second career built on top of clinical practice — that pathway usually leads to the most senior positions, up to Chief Medical Information Officer, which in most hospitals is an MD role by expectation, not just tradition. But a growing share of entry-level informatics and implementation jobs hire straight out of a health informatics master's programme, no licence required, especially at software vendors rather than hospitals themselves.

Nobody expects a nursing degree and a computer science degree from the same person. What actually gets you hired is being able to hold a conversation with both sides without an interpreter — reading a data schema well enough to ask an engineer a precise question, and sitting through a clinical workflow well enough to know which step is about to break under a new feature.