Some thoughts on healthcare tech

Some thoughts on working in healthcare technology and the associated challenges.

Systemic vs. “real” problems

I typically think about healthcare technology companies working in one of these two spaces. Systemic problems are those created by the healthcare system as it runs currently. They’re not endemic to healthcare itself, but stem from the problems that have arisen in our convoluted, and extremely poorly executed, healthcare delivery.

For example, if I create an app that integrates Epic’s EMR/EHR software with Cerner’s software, I’m definitely solving a problem, but it’s not an intrinsic problem to human health - it’s a problem that massive, interlocking systems have given rise to.

Real problems are problems that deal directly with human health or more directly with healthcare delivery. Step counters, CGM’s, X-Ray image generators/processors, MRI software, etc. These obviously aren’t completely seperate from insurance or healthcare as a whole, but they tend to address direct delivery concerns.

I’m not trying to down-play the importance of companies trying to fix “systemic” problems. They’re certainly real issues, but they do only exist as a result of poor interoperability, poor legislation, obfuscated data, or just laziness. There’s money to be made here, but it can be a little depressing knowing you’ve spent years of your life “fixing” a problem that didn’t have to exist.

Real problems have their own pitfalls, though they’re less apparent. Healthcare and “health” in general are incredibly dynamic and finicky spaces. Step counters might seem like a good idea, but they could also discourage more rigorous forms of exercise and give people an excuse to get out of going to the gym or lifting weights. Likewise, as with Apple Health products, they could simply be used to gather more data or as a marketing excuse to strap a mentally damaging product to your wrist.

Point being: behavorial and public health solutions are tricky too and it’s not always apparent that a new technology or solution will have the intended benefit.

I think I’d personally rather work on more real problems, but sometimes working within a system can change it, and I admire people trying. It’s just very, very difficult.

Engineers are not doctors

I’m going to make some generalizations here.

I read an article once about medical school application essays. The long-and-short of it was that they pretty much all boil down to the applicant saying “I want to be a doctor because I want to help people.” By and large, people become doctors (and nurses, PAs, pharmacists, etc.) because they want to help people.

This is not true of engineers at healthcare technology companies. I personally went into the healthcare tech space because I thought I could apply my skill set (engineering) to help people. Not all, or even most, engineers at Optum take this attitude. They very well do the job for money, job stability, or “interesting challenges” - all the things that would get you rejected from a medical school application. They do not want to engage with the larger healthcare system they work in, they do not want to think beyond the tech stack, and they definitely do not want to talk to the users. In other words, they’re typical engineers.

So, for someone like me, the environment you work in feels nothing like the reason you entered the field. This is especially true if you work on a system problem and not a real problem. You wind up so set back from the reality of healthcare, that you never get to experience the impact that you have.

I don’t want to sound naive here. It’s certainly possible to work in an urgent care office or dentist’s office where everyone is completely dispassionate about their work. But at least there you’re still able to interact with patients and make a tangible impact. In healthcare tech, you’re often in that same setting and you’re 5+ nodes away from ever interacting with a patient, doctor, or end-user.

Conclusion

If you’re going into healthcare tech, try to be choosey about where you go. It’s easy to get slotted into a role that feels no different than any other generic software company and it’s easy to wind up working on man-made problems that have dubious “real” value.