It’s been a long time coming, but as of this post, I’m mostly off GitHub. If I didn’t need it for work, I’d have deleted my account entirely. Unfortunately, our organization still relies pretty heavily on some features, at least for the time being.
My open source projects have been relocated and their GitHub repositories have been archived. This site, which was previously hosted on GitHub Pages, has also been moved.
Like many others, I’ve been uneasy about GitHub’s direction ever since the Microsoft acquisition. The acquisition itself was pretty ironic given the company’s historically hostile stance towards open source. For a while, though, things mostly stayed the same.
Over time, that changed. Between the continued enshitification of the user experience, the organizations they continue to do business with, and the increasingly questionable actions and practices around AI, I finally hit my limit. Every other thing they do feels like a middle finger to the developer community, and I’m over it.
Countless others have already written about this in far more detail than I will here, so I’m not going to turn this into another one of those posts. If you’re curious, you can easily find plenty of discussion on places like lobste.rs or the orange site.
Codeberg is a non-profit alternative powered by Forgejo. All of my semi-active open source projects have been moved there, and you can find me at https://codeberg.org/hernanat.
Hosting open source projects on a community-run, non-profit platform feels far more aligned with the ideals of open source than keeping them on a commercialized slop app that I no longer enjoy using. The community is growing quickly, and I’m interested to see whether the operating model holds up long term.
Even if it doesn’t, it felt worth the risk to get away from what Microsoft has turned a service I once loved into.
I kept putting this off because I assumed it would be a pain in the ass, but the actual migration ended up being surprisingly painless. Codeberg provides a tool for migrating repositories from a number of providers, including GitHub.
For each repo, all I had to do was provide a link, check a couple of boxes, and supply an API key for the migration. The entire process, including archiving the old repositories, took less than ten minutes. After that, I went through and purged a bunch of long-dead repos from my GitHub account as well.
This part was less pleasant. This site is a Jekyll blog that I had been hosting on GitHub Pages for quite some time. Codeberg offers a similar Pages feature, but it is currently in maintenance mode after being maintained by a single person for a long time.
On top of that, some users have reported intermittent availability issues, so I decided it probably wasn’t something I wanted to rely on yet.
In the end, I migrated the site to a cheap DigitalOcean droplet for the time being. It’s less convenient, but it gives me an excuse to play around with nginx and other things I don’t usually touch, which has been fun. When I’m feeling less lazy, I’ll put together a sane deployment process and probably write about it.
If you’re thinking about exiting GitHub yourself, I’d encourage you to give Codeberg a try. Some notable projects, like Zig, have already moved over, which gives it more credibility than it might have otherwise.
Right now my only real complaint is that things can feel a bit slow at times, but with more projects, more users, and so – hopefully – more resources and funding, I expect that to improve. I’m also looking into how I can contribute myself. Stay tuned.
]]>Other people spent more time writing actual responses (more power to you), but after reading it myself, all I could do was cackle and say: What a lazy and uninformed shit post lol.
Cheers.
]]>At this point most of us devs have been beaten down by the nonstop hype and hate around AI tools (primarily dev tools). Depending on who is talking, these things are either going to 10x our productivity, put us all out of work before lunch, or are so worthless we should not touch them at all. A lot of that noise is complete bullshit. Non-technical C-Suiters, VCs, and sales types love to hype this stuff because there is almost always a financial angle, or they are just riding the latest hype train (blockchain flashbacks, anyone?). On the other end of the spectrum, the people who dismiss the tools outright are usually reacting more to their own hangups than to the tools themselves.
Like a lot of folks in the industry, I am skeptical of anything that promises magical productivity boosts. My team has also been asked to increase our use of AI tools, which means I have had plenty of chances to mess with them in real work. This post is about how I actually use them, where they help, where they fall flat, and how I sift through all the hype and doom. It is all anecdotal and based on my own experience. I am not an AI expert. I am just a dev who has spent enough time with these tools to have opinions.
Every day on my LinkedIn feed, on certain news channels, and across the internet in general, I see the same AI hype posts from some CxO, VC, or other suit talking about how AI is going to render us obsolete or 100x our productivity. Then there are the endless announcements about a new company using AI to revolutionize X (just do a find + replace with using blockchain to revolutionize X … same energy).
This isn’t an original thought, as many have said it before me, but: I genuinely believe that most of this hype exists for financial reasons, and I can’t take anyone who plays into shit in this manner seriously.
Posts telling you to get on the AI train before it’s too late are trying to get you using their products so they can make money off you. Companies bragging about how they are ReVoLuTiOnIzInG something with AI are usually doing it to check a box for VCs. The guests on these news shows are often investors or company reps with a direct or indirect financial interest in the success of the technology. All of it blends together after a while, and it’s exhausting.
On the other end of the spectrum are the devs who refuse to use AI tools and / or will not put in the effort to learn how to use them productively, then dismiss the whole thing as garbage. I am not talking about people with valid environmental or ethical concerns here; a lot of those I actually agree with. No, I am talking about something else entirely.
I’ve had conversations with other devs in person and online, lurked on various threads, read people’s blogs, and I’ve formed a fairly consistent opinion: some people just don’t want to use these tools regardless of how good or bad they are. In some cases, instead of saying that and moving on, they come up with all sorts of negative shit to try and justify it (there are plenty of lazy anti-AI tool rants out there, not going to restate them here).
Why? Honestly, I think there are a bunch of reasons, but one stands out: programmers typically like to program. For some people, their love for the craft fuels their reluctance to use AI code generation tools. One of the joys of programming is encountering interesting problems and building your own working solutions. There is a real sense of satisfaction there, and it can feel like you are being robbed of that if the LLM is doing most of the heavy lifting.
I’ve been using AI in various ways for fun since the OpenAI beta, and more recently I have been using the technology daily at work. When I first got into the beta, my reaction was basically hey, neat toy and I used it to answer simple questions and generate some funny stories. Coding with it initially sucked.
The landscape has changed a lot since then – tons of AI coding tools out there, more competing LLMs, and a handful of services that make integrating with LLMs pretty painless.
Ok, so how am I actually using this stuff?
First and foremost, Google search is unusable for me at this point (and their AI-generated answers at the top are a joke lol). If I use a search engine at all, it’s DuckDuckGo, but a lot of the time I am taking advantage of the fact that I can just ask ChatGPT and it will respond with an answer and links I can click into. The quality of the responses has gotten noticeably better, so it’s hard for me not to use it.
I have my primary LLM tool hooked up to various MCP servers, which I use to write and iterate on things like ERDs, tickets, and other non-code-y tasks. I encounter a lot more of this sort of work now at this stage in my career, and I am not going to lie: I still hate it.
Previously, ERDs took me longer than they should have because I loathe writing them. With an AI tool wired into the MCP server for our knowledge base, I can just have a conversation with the LLM, point it to relevant code, docs, and tickets, and “write” the document section by section. Similarly, I hate writing tickets … but AI helps here too! I still have to read and correct the output, but the back-and-forth makes the process suck a lot less.
One of the biggest killers of motivation for me is work that is easy, quick, and / or completely uninteresting. Historically, I would put these tasks off, feel annoyed about doing them, move slower than I should, and then get stressed out because they piled up. Meanwhile I would gravitate to the interesting stuff, letting the mundane mountain grow.
AI tools have helped me a lot here. This category of work is basically perfect for an AI agent, and the agent is often faster than I would be even on my best day. On a recent project involving a migration between two repos, the entire thing was 90% boring grunt work, moving and renaming files. I generated an ERD and a set of tickets (using the conversational flow I mentioned above), then handed each one to a coding agent and let it run.
The whole project took a fraction of the time it would have taken manually. I found myself reviewing code and making only minor changes (and since it was not a greenfield effort, there was not much for the AI to screw up anyway). The agents also handled linter issues, test breakages, and other cleanup. This all allowed me to shift my focus to other things as needed without being so stressed about it … honestly felt like a win.
I am not much of a writer. I mostly write the way I talk, which people either love or hate. For this blog I try to clean it up a little, so I have given ChatGPT a set of instructions (after a lot of trial and error) to help keep things in my voice while making the writing readable.
I take it section by section and usually feed the tool a pile of run-on sentences, 5000 swear words, and a dozen tangents. What comes back is something properly punctuated, with about 85 percent fewer swear words and most of the tangents removed. Hate on it if you want, but the biggest thing that has kept me from blogging for years is that I hate the way I write. The AI assistance makes me hate it slightly less.
There is a bunch that AI tooling is great at. There is also a lot it’s still ass at, and for everything else I’ve just decided I don’t want to use it at this point.
AI does not handle complexity well, and the problem gets worse the longer your session runs and the more context you shove through it.
I had a project that was legitimately complicated and required a lot of context about code, business expectations, and interactions between different systems. I said fuck it, let’s try to vibe this, shared an ERD, multiple tickets, various docs, and some tribal knowledge into the session, and hoped for the best. The result was a huge mess and me wanting to throw my laptop. And of course I blew through the context window almost immediately.
I did not abandon AI entirely for the remainder of the project, but I had to be way more surgical than I planned, and the initial thrashing was time wasted.
Sometimes you point an LLM at a test failure and it fixes it the right way,
no problem. Other times, it tries to mock out the universe and rewrite half
the test suite so that 1 == 3 passes. Similarly, sometimes it can debug an
issue, other times it just throws shit at the wall hoping something will
stick.
I am at the point where I can tell pretty quickly when I am going to have to step in and tell the AI to sit down and shut up, but it still irritates me to no end. In the past I tried thrashing with no, look at <x> only for the tool to agree with me and then immediately do something else wrong. Big lesson: learn to cut your losses quickly.
I don’t use AI coding tools in my personal projects, at least not yet. Even though I use them daily at work and get real productivity out of them, that is not the point of my personal projects. When I am building something on the side, I want to have fun and usually learn something new, not crank out tasks faster.
I’m not ruling out using AI for personal stuff in the future, but right now I have my programming life split into two boxes: my personal box where I code by hand, and my professional box where I code by hand and vibe. So far, I have been happier keeping that separation.
AI tools are useful means to some ends. I don’t believe they are going to steal my job, no matter how often we hear that line, and I don’t think they are so utterly useless that you should ignore them. I don’t love any of these tools so much as I simply use them because they are usually good enough. I use OpenAI’s and Anthropic’s tools a lot, but I am by no means a fanboy of either.
My general advice is this: don’t be so starry-eyed that you forget your responsibility to think, and don’t be so negative that you dismiss an entire category of tools. In my experience, there are clear productivity gains once you learn your way around. On the other hand, you will also learn when it’s time to shut down the session and blow the dust off your text editor ;)
There is a lot more I could say, but we will leave it here for now. Thanks for stopping by!
]]>Note: If you’re already comfortable with flakes and overlays, this post may be boring to you. This is more for my own memory than anything else. I do recommend reading the posts I’ve linked out to if you are unfamiliar with anything below.
I’ve used Nix for a while – on my Mac with nix-darwin and home-manager, dev environments with devenv.sh, and even for this blog – but I’m no expert. Today I finally grokked overlays after reading this awesome blog post, and wrote a minimal Nix flake for Zig.
Mitchell Hashimoto maintains a Zig
overlay that I’d been using via
nix shell 'github:mitchellh/zig-overlay#master' or in devenv. This time I
wanted to use it in a flake and share the result.
I’m on a MacBook with Apple silicon, but I also use a Fedora laptop, so I
wanted the flake to work on both. I avoided flake-utils on purpose – partly to
learn, partly to see what’s really going on without convenience helpers. Here’s
the flake with comments:
# flake.nix
{
description = "A very basic flake";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
zig = {
url = "github:mitchellh/zig-overlay";
inputs = {
nixpkgs.follows = "nixpkgs";
};
};
};
outputs =
{
self,
zig,
nixpkgs,
}:
let
systems = [
"aarch64-darwin"
"x86_64-linux"
];
# see https://nixos.org/manual/nixpkgs/stable/#function-library-lib.attrsets.genAttrs
# we're going to use this function below to define dev shells for all
# systems. the flake-utils package has an `eachSystem` function that
# accomplishes something similar.
forAllSystems = nixpkgs.lib.genAttrs systems;
in
{
devShells = forAllSystems (
system:
let
pkgs = import nixpkgs {
inherit system;
# overlay is going to make pkgs.zigpkgs available,
# which allows us to install whatever version of Zig we want
# including nightly (which I’m using below).
overlays = [ zig.overlays.default ];
};
in
{
default = pkgs.mkShell {
nativeBuildInputs = with pkgs; [
# Going to be hooking into libgit2 for this particular project.
libgit2
# install the nightly build
zigpkgs.master
];
};
}
);
};
}
Now you should be able to do something like the following:
~/workspace/zig/git-lore/ > nix develop --command $SHELL
~/workspace/zig/git-lore/ > zig version
0.16.0-dev.23+47a2f2dda
~/workspace/zig/git-lore/ >
That’s it! Nothing groundbreaking, but it was fun to get set up. I’ve got a few other Nix-y posts in mind that might be more interesting. Let me know if there’s anything you’d like me to dive into.
Flake without the comments or libgit2 dependency provided below for your
convenience.
{
description = "A very basic flake";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
zig = {
url = "github:mitchellh/zig-overlay";
inputs = {
nixpkgs.follows = "nixpkgs";
};
};
};
outputs =
{
self,
zig,
nixpkgs,
}:
let
systems = [
"aarch64-darwin"
"x86_64-linux"
];
forAllSystems = nixpkgs.lib.genAttrs systems;
in
{
devShells = forAllSystems (
system:
let
pkgs = import nixpkgs {
inherit system;
overlays = [ zig.overlays.default ];
};
in
{
default = pkgs.mkShell {
nativeBuildInputs = with pkgs; [
zigpkgs.master
];
};
}
);
};
}
Click here to just get to the point.
I want to know if anyone is actually visiting this site. I’m not selling anything or trying to turn my blog into some alternative revenue stream (how silly of me, I know). I just want to know if I’m getting visitors, and maybe a couple of other things related to the content I put up. To accomplish this, I need some sort of analytics solution.
This site is built using Jekyll and its default theme Minima. There are various plugins and themes that can hook into 3rd-party analytics, but installing a dependency or swapping themes just to get a script tag included on my site’s pages seemed way too over the top. It would also just be another thing to break and give me headaches later on.
In this post, I’ll walk through a straightforward approach to setting up analytics on your Jekyll blog using the default Minima theme using Plausible.
Disclaimer: I don’t have any relationship with Plausible other than being a user of their product at the time of this writing.
The need for a third-party analytics tool comes from the fact that this site is hosted using GitHub Pages. I don’t have access to any traffic data like I would if I were hosting everything myself.
Conventional wisdom says to slap some BigBrother Analytics onto your site and call it a day. I don’t like that approach. The internet is full of posts about problems with those tools, so I’ll spare you that rant. I just want to answer a few basic questions about whether anyone is actually reading this site, and maybe if there are some types of posts generating more views than others – no need to hand over any data to adtech in the process.
I decided to try out Plausible because I’ve heard and read a lot of good things about their “less creepy” approach to analytics. It seems to support my use case without feeding visitor data into the adtech meat grinder, so it felt worth giving them a shot.
My gem setup is pretty barebones as of this writing:
I’m not going to go into getting the site setup on GitHub pages here, GitHub has guides for that. This assumes you’ve already gone through those.
_includes/head.html file from the Minima theme to
_includes/head.html in your Jekyll site directoryThat’s it. I’ll go into details on points 3 & 4 since those are the most involved.
_config/head.htmlv3 of Minima will support a _includes/custom-head.html file, but that
hasn’t been released yet. For v2.5.x, the way to customize the head section
is to copy the _includes/head.html file from the theme. This process is
described in the
customization
instructions for the 2.5-stable branch. You can find the file
here.
That file looks something like this:
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
{%- seo -%}
<link rel="stylesheet" href="{{ "/assets/main.css" | relative_url }}">
{%- feed_meta -%}
{%- if jekyll.environment == 'production' and site.google_analytics -%}
{%- include google-analytics.html -%}
{%- endif -%}
</head>
You’ll notice that by default it includes some Google Analytics stuff. Since we’re not using that, remove it and replace it with your Plausible script tag. Your modified file should look like this:
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
{%- seo -%}
<link rel="stylesheet" href="{{ "/assets/main.css" | relative_url }}">
{%- feed_meta -%}
{%- if jekyll.environment == 'production' -%}
<script defer data-domain="blog.antfeedr.com" src="https://plausible.io/js/script.js"></script>
{%- endif -%}
</head>
That’s it! When Minima v3 is released, the only upgrade step you’ll need to
take, other than updating the gem for the theme, is to switch your setup to
use _includes/custom-head.html instead of _includes/head.html. No need
to use any extra Jekyll plugins or special themes.
✌️
]]>In a previous post, I talked about my time in healthtech. Over the years, that experience has also led me to read a lot of books about the U.S. healthcare system.
In this post, I want to share a few recommendations for anyone looking to expand their bookshelf.
I considered just posting a simple list, but that felt lazy. Instead, I’ve added some thoughts on why each book stood out to me. Feel free to skip through if you just want the titles – I’ve put them at the top of each section for your convenience (one of my pet peeves on recommendation blogs is needing to read someone’s entire life story before getting to the actual point, so I’ve tried to avoid doing something like that here).
Note: These books are not listed in any particular order.
Full Title: America’s Bitter Pill: Money, Politics, Backroom Deals, and the Fight to Fix Our Broken Healthcare System
Author: Steven Brill
This book digs into the Affordable Care Act (ACA) – or “Obamacare” – and examines how it was crafted, implemented, and how it has played out since. Steven Brill, a lawyer and journalist, does a great job breaking down the backroom deals, political struggles, and lobbying efforts that shaped the law.
One thing I found fascinating was how some of the same entities railing against the ACA were involved in writing it (including the parts they now complain about). Brill also dives into the broader impact of the law on the industry and, ultimately, on people like you and me.
Full Title: The Price We Pay: What Broke American Health Care – and How to Fix It
Author: Marty Makary, MD
This book takes a hard look at what’s wrong with American healthcare and why costs are so out of control. Dr. Marty Makary, a surgeon and public health researcher, focuses on issues like price-gouging, opaque billing, and unnecessary procedures. He doesn’t just criticize – he also explores how these practices hurt patients and what can be done to fix them.
What stood out to me were the real-life stories woven throughout the book. It’s not just about policy; it’s about people and the impact these issues have on their lives. Makary also highlights efforts to improve transparency and return healthcare to its core mission: helping patients.
Full Title: The American Health Care Paradox: Why Spending More Is Getting Us Less
Authors: Elizabeth H. Bradley and Lauren A. Taylor
This book tackles a big question: why does the U.S. spend more on healthcare than most other countries but still see worse outcomes? Bradley and Taylor argue that part of the answer lies in how little we invest in social services like housing, education, and nutrition, which are critical to overall health.
One key point they make is how the U.S. separates healthcare and social services, while other countries integrate the two. They use examples from places like Sweden and Denmark to show how combining these efforts can lead to better results and lower costs.
Full Title: An American Sickness: How Healthcare Became Big Business and How You Can Take It Back
Author: Elisabeth Rosenthal
Shout out to Jack for recommending this book to me years ago!
This book dives into how U.S. healthcare evolved into a profit-driven industry. Elisabeth Rosenthal, a physician and journalist, explains how financial incentives have shaped every part of the system – from hospitals to insurance companies to pharmaceutical firms – often at the expense of patients.
What sets this book apart is how Rosenthal combines real-world examples with practical advice. She doesn’t just lay out the problems; she also offers strategies for navigating the system as a consumer and ideas for creating a more patient-focused approach.
Full Title: The Healing of America: A Global Quest for Better, Cheaper, and Fairer Health Care
Author: T. R. Reid
This book explores how other countries manage healthcare and what the U.S. might learn from them. T. R. Reid travels to countries like France, Germany, Japan, the U.K., and Canada to understand their systems and compare them to ours. He also discusses systems in other nations he studied but didn’t visit as part of the research for this book.
Reid does a great job breaking down the strengths and weaknesses of each approach. While the book highlights areas where the U.S. could improve, it focuses on practical comparisons rather than ideology. It’s a thoughtful look at what works elsewhere and how those ideas might apply here.
There are plenty of other books out there, but these five are the ones that have stuck with me. There’s a lot about our healthcare system that’s fundamentally broken, but many of us struggle to pinpoint exactly what those issues are. I often see blame placed in one specific area depending on who I’m talking to – like regulation, or the insurance industry – but the reality is much more complicated.
The discussions across these books cover a lot of ground and provide a broader understanding of the system’s challenges. I think they leave the reader better equipped to engage in conversations about healthcare in the US and, hopefully, inspire some creative solutions.
Happy reading ✌️
]]>I’ve spent the better part of eight years building software for various healthcare technology companies. Each role came with its own set of challenges, as well as the opportunity to work with a different part (or parts) of the US healthcare system.
Lately, I’ve been reflecting on my time in healthtech – how it’s shaped my career, influenced my approach to building software, and broadened my perspective on the roles and responsibilities of those who both envision and deliver the solutions in this field. This post attempts to explore some of that.
Without getting into my whole life story, how I ended up here is kind of funny. As a senior in college, I got a call to interview for a job that I didn’t even remember applying for. I was stoked because my goal was to land something before graduation and then chill for the rest of senior year. I ended up getting the job, and that’s pretty much how it all started. At the time, I had zero idea what I was actually getting myself into.
US healthcare is, to say the least, kind of insane. Those of us in healthtech get to look at it from a bunch of different angles as we try to build coherent solutions for what often feel like incoherent problem spaces. It can be wildly frustrating, but at least it’s never boring!
Anyways, for better or worse, I’ve stuck around.
Over the years, there have been opportunities to explore other industries – fintech, real estate, you name it. But nothing ever felt compelling enough to make the jump (even though some of the offers – looking at you, fintech companies – were very tempting).
Ultimately, I think it boils down to three things keeping me around:
I want to build things that can positively impact people’s lives. Working in healthtech provides me with tons of opportunities to make contributions that can help improve patient health outcomes.
There is no shortage of unique problems that are interesting, meaningful, and lucky for me, solvable with software. This makes it pretty easy to find things to stay engaged.
There are lots of existing solutions that could be improved, to put it nicely. This leaves a ton of room to launch competing products that do things better. Bonus points if it ever involves unseating bigger players ;)
To be clear, while I find the work exciting and rewarding (and endlessly frustrating), I’m not here to defend the healthcare industry. Many of the problems we are now tasked with solving stem from the inefficiencies and overcomplications created by the industry itself. That’s a topic for another day.
While thinking about what to write for this, one of the hardest parts was trying to figure out what was worth including. A bunch of stuff got tossed out, but in the end I still ended up settling on five things.
The first three try to convey the ways in which I believe us technologists fit into healthcare and what our responsibilities are beyond just shipping code. The last two attempt to discuss some examples of the more frustrating things you can run into.
I couldn’t help it with the corny section title, sorry.
Tech people love to “disrupt” and “revolutionize” things – at least that’s what a lot of places claim to be doing most of the time. But in healthcare, “moving fast and breaking things” runs the risk of causing bigger problems than users just being mildly inconvenienced by our iterations.
Breaking scheduling for a surgeon isn’t the same as breaking a feature in a social media app. Iterating rapidly on your UX might be fine for an e-commerce site, but it’s far from ideal when a nurse is trying to update patient information and the application keeps changing on them.
For physicians, software issues – whether a bug, bad UI, or poor performance – make an already difficult job even harder. Slow or inefficient software can delay them during patient visits, in turn affecting every other patient they need to see that day.
Of course, no one is going to build perfect software – that’s not the goal. Instead, I am arguing that as solution builders, we have a duty to minimize our potential to harm our users’ ability to perform their roles in healthcare.
Working on healthcare tech solutions usually means dealing with patient data at some point. My approach to dealing with it is simple: treat patient data like it’s your own. Don’t do anything with it that you wouldn’t want someone to do with your own data, even if it might technically be fine under HIPAA.
This mindset is not only respectful to patients but also reduces the likelihood of HIPAA violations. Ask yourself (HIPAA aside):
There is also the risk that all this information ends up in a data breach. The danger is always there, but sprinkling PHI around needlessly and / or not properly storing it increases the odds that something ends up going wrong. A data breach would obviously be catastrophic for your business, but it’s usually the patients that end up with the shortest end of the stick.
Imagine you’re a patient, and some tech company you’ve never heard of experiences a data breach including names, addresses, social security numbers, and more. One of your providers happens to be a customer of theirs. Suddenly, you’re facing identity theft, scam calls, and other fallout – all while you could also be trying to deal with your health issues. Feels bad.
Tech people are always gonna try and tech, I know. However, not every challenge needs a line of code to solve it. This probably applies to most industries, but it is especially true in healthcare, where many of the hardest problems are inherently human. Similarly, trying to remove people from the equation (e.g., automation) isn’t always the best solution, and it could even end up leaving you worse off.
One example that stands out to me is the growing number of solutions focused on minimizing, if not eliminating, face-to-face interactions between providers and patients. I’m not saying telehealth is bad – it’s not. There are tons of things you used to have to visit a doctor’s office for that can now be handled over the phone. That’s awesome! My concern is with solutions that aim to replace all in-person interactions between patients and providers.
As it turns out, many of these places are missing the mark due to something pretty obvious: patients generally prefer direct interactions with their provider when it comes to something as important as their health. Providers, likewise, value the opportunity to work directly with their patients.
My current company has remained cognizant of this for our physical therapy business, and it’s proven successful. We’re fortunate to receive a lot of positive feedback from both patients and physical therapists, a good amount of which has nothing to do with the software solutions we’ve built.
PTs enjoy working with patients 1:1 for an entire session instead of juggling multiple patients as they often do in a clinic setting. Similarly, patients appreciate having a provider dedicated to them for the full session rather than being handed a list of exercises and left on their own.
Our success lies in how we use technology to facilitate and improve the in-person physical therapy experience, not replace it. By focusing on enabling meaningful interactions rather than removing them, we’ve built a model that works to the benefit of both providers and patients.
It’s 2024, and you’d think we’d be done with the laborious paper-pushing fax workflows of the past. In many industries, that’s true … but not in healthcare! Even organizations using tech solutions daily still rely on fax.
The obvious question is why? We know modern tech solutions can replace paper and fax workflows in theory, so why hasn’t it happened everywhere? The answer is complicated.
Let’s say you’ve convinced part of a healthcare organization to adopt your shiny new software product that beautifully captures their key workflows. Everything looks great until someone points out that the old process also involved sending faxes to various internal and external recipients – billing, insurance, others – depending on the circumstances. Your software didn’t account for this, and apparently, there is no other option. Faxing is non-negotiable.
So, what do you do? You scream into the void, then discover that to both your horror and relief, there are services that provide APIs for faxing. You can even set up a number to receive faxes and have them sent directly to your application. Begrudgingly, you add functionality to your app for sending and receiving faxes, helping at least one team move their fax machine “to the cloud”.
The takeaway here is that healthcare professionals aren’t stuck sending faxes because they enjoy it. The problem is that, no matter how great your solution is for some individual organization, they still need to exchange information with countless others who might literally only use their fax machine as their main form of sending and receiving information. Whether it’s due to leadership not prioritizing tech adoption or straight-up reluctance – “this works fine for me, I don’t need your fancy application!” – fax machines remain the lowest common denominator.
Healthcare tech is unfortunately one of those industries where if you really want to jump in the game, you have to have the money to do it. It’s a real shame because as I have mentioned before, there are tons of problems that are meaningful, interesting, and solvable with software. There are also a ton of opportunities to disrupt large industry players that have grown complacent and are now contributing to more of the inefficiencies and waste that plague our healthcare system. Sadly, though, there are just too many things making the barrier to entry way too high for a lot of potential newcomers.
Why is it so expensive? Some argue it’s the regulations, others might argue it’s price gouging. It’s probably a bit of both. The regulations do require you to do certain things which ultimately cost money. At the same time, the price points for some third parties can be outrageous, oftentimes for no clear reason. A general rule of thumb is to add one or two more zeroes to what a reasonable person would expect to pay.
On the other hand, there are also a handful of industry giants that gatekeep things you might want or even need access to in order for your business to function. They tend to charge you for them too because, well, they can.
For example: there are organizations out there that legitimately will not even consider buying into a software solution if it doesn’t have a plugin for whatever big name EHR system they use (I’m trying not to name drop because I don’t want to get myself in trouble). From their perspective it makes sense: keeping everything unified under a single system allows the organization to standardize and focus on becoming efficient within that system. Introducing another system just causes friction. You can do what they are asking, but first you have to pay the toll: Big EHR wants wants their cut for the privilege of working your product into their system. So … how bad do you want the customer?
Big EHR loves this arrangement – they get more money, you build and maintain things that are pretty much additional service offerings for their own system, and oh they get a cut of your revenue if you ever end up charging money for your app within their marketplace.
There are a ton of other things, but I’m sure you get the point. It’s a sad state of things, but who knows? Anything can happen!
I don’t really ever write anything, but hopefully there were at least some interesting things up in there. Maybe at some point I’ll go into some of the crazy stuff, we’ll see.
I am likely to remain in healthtech for the foreseeable future, regardless of how frustrating it gets. As some of my friends and I like to joke: once you’re in here, you’re never getting out. At the end of the day, it’s fun to work on things that will hopefully end up making some aspects of this crazy system a little better.
]]>