Why healthcare in US is so expensive. From the perspective of a software developer.
By: Jordan Maxwell
Tags: Hospital, Dotnet, Healthcare, Programing, Medical

I just wrapped up a programming contract at one of the largest hospital chains in the US. Can’t tell you which one, but if you google Top Hospital Chains in US, it’ll be right there. It gave me a very small glimpse into why US healthcare is so freaking expensive and is likely to remain that way regardless of what reforms are enacted in the years to come.

When I started the contract I was struck by how few IT employees the hospital had relative to the army of people that the multiple contracted consulting companies brought to bear. Which makes sense: software development is not the native expertise of the hospital —treating patients is. However, that has a cost.

The consulting companies write “consulting company” code. What does that mean? It means that the code base is complex for the sake of complexity. Which means that the consulting company will be needed to stick around (and extract fees) to maintain the code with a ton of resources.

Let me give you an example. Logging. And mind you, this isn’t logging for some life saving medical device, which is important. We are just logging to record an API call for some minor action on the hospital website.

If I was paying for development out of my own pocket, I’d receive the action, hand it off to a logging library like Log4Net or Serilog and let it dump the data into storage of some sort. Easy, reliable and mission accomplished. How does a consulting company do this?

The call comes in via the API Gateway and makes its way to our code. The code does what it does then logs the action onto a service bus. That in itself kicks off a Lambda function which reads message from the service bus and inserts it into the database. The entire interaction happens on AWS, which itself isn’t cheap.

Another money sink is the insane amount of unit tests, integration tests, contract tests, monkey tests, assertion tests, mutation tests, selenium tests, load tests, failover tests (yes, in the cloud — the irony) and other types that I don’t even remember now. Half the time the tests are basically testing a thin wrapper over AWS functionality.

If you know anything about .NET Core, then you know that pretty much everything is done via Dependency Injection, which means multiple parameters to a constructor. Now imagine that you needed to make a minor change to the functionality and it involved adding a new parameter to the constructor. It took you 10 minutes to finish it. Yey — you are fast! Now go change a 100 tests that broke because the constructor signature changed.

So every change in functionality becomes a slog where 90% of your time and company money is spent on fixing tests.

Sure, if you are writing tests for something important like a medical device or the Crew Dragon where lives are at stake — by all means, go to town. But we are talking about a website. Unit and integration tests should be more than enough.

These examples are but tiny insights into the insanity that I’ve observed first hand. This code will need to be maintained for years to come — it’ll probably become more complicated over the years just because the baseline is complicated. And more expensive to maintain.

If this wastefulness is prevalent throughout the system, there is very little reason to hope that the healthcare in US will become affordable at any point regardless of what reforms come our way in the near future.

Maybe this meme looks apropos.