
Every clinician who makes the move into health IT spends a lot of time worrying about the technical gap.
Do I know enough about databases? Can I hold my own in a conversation about integrations? Am I going to get exposed as someone who doesn't actually understand how the software works?
That anxiety is understandable, and it's also mostly misplaced. The tech is learnable. You can get comfortable with SQL, understand what an API is and why it matters, navigate a ticketing system, read a technical spec well enough to ask good questions. None of that is out of reach for someone who memorized pharmacokinetics or learned to read a deteriorating patient from across the room. If anything, clinicians tend to underestimate how much raw problem-solving capacity they bring with them.
The thing that actually catches people off guard is the identity shift.
In clinical practice, you have standing. You've built expertise over years — in some cases, over a decade or more. People come to you with questions. When something goes wrong, you know what to do. Your judgment is trusted because it's been earned and tested, often in high-stakes situations.
When you move into health IT, especially early in the transition, most of that standing doesn't transfer. You're in rooms with people who've been doing this longer than you. Your clinical background is an asset, but it doesn't automatically translate into credibility in the new environment. You have to earn it again, in a different arena, by different rules.
That adjustment is harder than learning Jira. A lot of people in the middle of it feel like they've stepped backward — like they traded competence for a title change. Some don't make it through that phase. They go back to clinical roles, not because they couldn't do the health IT work, but because the discomfort of being new again was something nobody had warned them about.
The mistake most clinicians make when transitioning is leading with what they were, not what they can see.
"I was a pharmacist for eight years" is a credential. It tells someone where you came from. It doesn't tell them why it matters for what they're building or implementing.
The more useful framing is specific and translational: you know what happens to CPOE alert thresholds at 2am during a shift change when the covering physician doesn't know the patient. You know what a formulary override looks like from the clinical side versus the IT side. You know why the pharmacy team disabled that alert three months after go-live, and it wasn't because they didn't care about safety — it was because the alert fired on 94% of orders and stopped meaning anything.
That's not a credential. That's a perspective most people in the room don't have and can't easily acquire. The engineers who built the system have never stood at a Pyxis during a code. The project managers who ran the implementation have never verified a high-alert medication order at the end of a twelve-hour shift.
You have. That's worth something, but you have to learn how to make it legible to people who operate in a completely different language.
The biggest practical challenge in the early part of a career transition is learning to translate clinical knowledge into health IT value.
Get pieces like this in your inbox every week. No spam, unsubscribe anytime.
This isn't about dumbing things down or abandoning the depth you've built. It's about connecting what you know to the problems the team is actually trying to solve. A workflow inefficiency that costs thirty seconds per medication verification pass doesn't mean much in the abstract. When you can explain that on a 300-bed unit, that's thirty seconds multiplied by however many verifications per shift, across however many pharmacists, and that the cumulative load is what's driving workarounds that create real dispensing risk — that's a conversation that lands differently.
The translation also runs the other direction. One of the most valuable things a clinician can do early in a health IT role is close the gap on the technical vocabulary fast enough to participate in cross-functional conversations without needing a translator. You don't need to be an engineer. You need to be able to sit in a sprint review and understand what's being discussed well enough to ask whether the proposed solution will actually work in the clinical environment it's being built for.
That combination — clinical depth plus enough technical literacy to operate in health IT settings — is genuinely rare. It's what health IT organizations need and regularly struggle to find. Most people have one or the other.
It's rarely a clean handoff. Most clinicians who make this move do it in stages: a role that bridges both worlds, an informatics position that still requires clinical credentialing, a project that puts them at the intersection of workflow and technology. The full transition into a non-clinical health IT role often happens gradually, over two or three years, as the new expertise accumulates and the clinical identity becomes one input rather than the primary one.
The people who do it well tend to share a few things. They stay curious about the technical side without being intimidated by it. They're willing to be the least experienced person in the room on certain topics while still being the most experienced person in the room on others. They find the overlap between what they know and what the organization needs, and they work from there.
They also don't apologize for the clinical background. The instinct, especially early, is to minimize it — to present yourself as a tech person who happens to have a clinical degree, as if the clinical part is something to move past. That instinct is wrong. The clinical background is the differentiator. The goal isn't to become a health IT professional who used to be a clinician. It's to become someone who operates at the intersection of both, and does it better because of the combination.
If you're in clinical practice and thinking about making this move, the most useful question isn't whether you can learn the tech. You can.
The more honest question is whether you're ready to be new again — to give up the standing you've earned, to spend time proving yourself in a different context, to work through the discomfort of not knowing things that your colleagues know, while also having knowledge they don't.
That's a real cost. For most people who make the transition and stay, it's worth it. But it's worth going in with eyes open about what the adjustment actually involves, rather than finding out when you're already in the middle of it.
Jason Potts, PharmD
Hospital pharmacist and health IT product manager. Writing about the intersection of clinical practice and technology at Clinical to Code.
Clinical insights delivered to your inbox. No spam.