For fourteen years, I built healthcare integrations across some of the largest and most complex health systems in the country: Mayo Clinic, UPMC, Tenet, BayCare, and Pfizer. I had a front-row seat to the same problems playing out over and over again.
- Integration tools are hard to use, expensive to learn, and require a small team of specialists to operate.
- Vendors can’t support the APIs or workflows teams actually need.
- Integration teams can’t move fast enough to keep up with demand.
And now AI is exacerbating the problem. AI needs clean, real-time data — lots of it — and the integration layer is the thing standing between the AI and that data.
The tools haven’t meaningfully changed in over a decade. They were built for a simpler time. They still work, but they’re slow, fragile, and require specialized expertise to operate. Complex workflows stretch them. Scaling them is painful. Maintaining them becomes a full-time job.
At some point, I stopped asking, How do we work around this? and started asking a different question:
What would this look like if it were rebuilt from scratch for speed and simplicity?
The answer became Fethr.
The idea behind Fethr
The core idea is simple: integration should be accessible to the people who actually understand the workflows — clinicians, operators, informaticists, and healthcare leaders — not just engineers who’ve spent years inside legacy systems.
If a subject matter expert can describe what needs to happen in plain language, the system should be able to build it. I like the idea of a world where someone connects to Epic in minutes using natural language, AI handles the complexity underneath, and the orchestration layer holds everything together.
The biggest bottlenecks I’ve seen in healthcare IT are technical. Yes, there are regulatory constraints. Yes, there are compliance requirements, legacy systems, and organizational complexity.
But at the end of the day, most of the friction comes from something simpler: systems that can’t manage real-world workflows. And this causes operational issues, which in turn cause waste in the form of lost time and money.
Hospitals aren’t short on software. They’re short on systems that actually coordinate work.
If you had something closer to a true hospital operating system — one that could orchestrate workflows across systems, automate the repetitive tasks, and adapt to how care actually happens — things would run a lot smoother.
Instead, teams are stuck stitching together disconnected tools, manually pushing data between systems, and relying on people to fill the gaps where automation should exist.
These are the main problems as I see it:
- Workflows too complex for existing engines
- Systems that can’t reliably support real-world use cases
- Platforms that require years of specialized training just to operate
Fethr is built to remove those constraints — not by pretending the complexity isn’t there, but by making it manageable for the people who already understand the problem.
Simple has to be intentional
One of the things that frustrates me most about existing integration tools is that they treat complexity as inevitable. The interface is an afterthought. The configuration is buried. The error messages are unreadable. And underneath all of it is the assumption that the person using the tool has years of experience — so it doesn’t really matter if it’s hard.
We believe the opposite.
If the tool is hard to use, it’s not finished yet.
A clean, simple interface is not a nice-to-have in healthcare integration. It’s the whole point. If a clinical informaticist who understands the workflow still has to call an engineer to build and test a pipeline, then the problem hasn’t actually been solved.
Every design decision in Fethr starts with the same question:
Could someone who understands the domain but not the technology use this confidently?
If the answer is no, we keep working.
AI is not a feature. It’s the foundation.
There’s a version of AI in software that shows up as a feature:
- A button that says “Ask AI”
- A chatbot in the corner
- A summary you can generate if you want to
That’s not what we’re building.
AI in Fethr is embedded into every layer of the platform. When a new vendor specification comes in, AI reads it and maps the fields. When a message arrives that doesn’t match the expected schema, AI identifies the variance and suggests a correction. When an interface starts behaving like a downstream system changed, AI catches it before it becomes an outage and proposes a fix.
The engine underneath is still deterministic. Rules are explicit. Transformations are auditable. Data flows exactly where it’s supposed to. AI sits on top of that foundation — accelerating work that used to take weeks, monitoring what used to require constant human attention, and correcting issues automatically so systems can stay live without someone watching dashboards at midnight.
But Fethr is not just AI-assisted. It’s AI-ready.
The same platform that processes HL7 feeds can orchestrate full AI workflows. Users can build and deploy AI agents directly inside the platform. Intelligent document processing makes it possible to extract structured data from clinical notes, referral packets, prior auth forms, and other unstructured documents that traditional integration engines usually leave untouched.
Most integration engines are built for structured data and treat everything else as out of scope.
We don’t.
We treat unstructured data as just another input to route, transform, and act on.
A note on standards
HL7 v2 is 40 years old, and it is not going away. FHIR is strong on paper, but real-world implementations are messier than the spec suggests. Every health system has proprietary schemas, custom Z-segments, and legacy formats that will outlive all of us.
So we stopped arguing about which standard wins.
If you can build fast enough, it does not really matter what is running underneath. Get an interface from request to production in hours instead of months, and suddenly the format becomes an implementation detail.
Our thesis is simple:
These standards are not going away anytime soon. Stop fighting them and build something intelligent on top of them.
We’re not betting on which standard wins.
We’re betting that if you make development fast enough, the standard stops being the bottleneck.
What we’re building next
We’re not building toward a single point solution. We’re building toward a platform that removes the bottlenecks that have made healthcare integration painfully slow for years.
AI-powered browser automation
Not every integration problem has a clean API solution. Some vendor portals do not expose APIs at all. Some workflows live inside web interfaces that were never meant to connect to anything. We’re building AI-powered browser automation that can navigate those environments, extract data, and execute workflows without waiting on vendors to build integrations that may never come.
Chrome extensions that execute workflows
We’re also building the ability to trigger Fethr workflows directly from the browser. That means a coordinator working inside a portal can kick off a data workflow without switching context, without calling IT, and without waiting days for a manual process to complete.
Cloud-first architecture
Today, the platform runs on-premises inside health system networks, which is the right answer for many environments. But it is not the only answer. We’re building a cloud deployment model that gives teams flexibility to run Fethr wherever their data lives — on-prem, in the cloud, or both.
Deeper AI across the platform
The AI capabilities we have today are the floor, not the ceiling. We’re continuing to build smarter mapping suggestions, autonomous troubleshooting agents, and AI-assisted testing that validates workflows before they touch production data. The platform gets better with every deployment, and we’re building the feedback loops that make that compounding possible.