If I ever end up in New York and bump into the SubwayTakes guy, here’s my take: We can’t build truly effective healthcare AI systems without modernizing the developer experience first.
In 2021, I joined the biomedical research centre at University College London Hospitals (UCLH) as an NLP software developer. My work focused on information extraction systems deployed in live clinical settings, including a real-time medical coding tool currently deployed across major NHS hospitals.
But I wasn’t just writing code. I worked with a small team of experts, and we operated like a startup within the larger research institute and the NHS. I oversaw the end-to-end process of the entire project, not just the engineering. That meant everything from navigating the lengthy governance process to talking to real clinician users and patients.
This made me care deeply about the impact and consequences of what I was building. I felt like I was personally guaranteeing that our code upheld the Hippocratic Oath, even though I wasn't the only one responsible for it.
More importantly, it was a constant reminder that algorithms are merely a means to an end. We build these systems to serve people — that means trustworthy, safe, and usable tools that deliver tangible benefits to clinicians and patients.
I think that was one of the reasons why it bothered me so deeply that the process of developing software in healthcare is neither efficient nor fit for purpose. And why I eventually decided to leave to try solving the problem.
The Problem
Big Picture: Nothing is in Python
Building modern software for healthcare systems is a pain. It is slow, manual, and repetitive. Almost all of the AI/ML ecosystem lives in Python, but almost none of healthcare infrastructure does. The tools to bridge this gap are few and far between.
During my time at UCLH, this meant I often felt like I was taking this Big Messy Thing and trying to squeeze it into a box that resembled as close to a normal Python developer experience as possible.
What about integration engines? Traditional integration engines are bulky, batch-oriented, and built for organizations — not developers. They focus on enterprise features rather than developer experience, not to mention the infrastructure overhead and legacy scripting languages that come with them.
To confirm the Python/healthcare infrastructure gap wasn’t just my experience, I looked through every open source library on healthcare AI and infrastructure on GitHub1. After many hours of filtering and labelling, I found 402 repositories.
At first glance, there are far more tools in infrastructure than AI/ML development. While there's a growing ecosystem written in modern web development languages, many established frameworks are still incompatible with the modern AI/ML stack. The fact that the top two starred repos in this category are OpenEMR (a community-maintained 20-year-old PHP workhorse) and Medplum (a YC-backed “Firebase for healthcare” platform) shows how the ecosystem spans from legacy to cutting-edge.
What’s also revealing is where people are spending their effort. Almost half of the tools in the infrastructure category are focused on interoperability. Their primary purpose is to make it easier to work with, convert, and exchange data between different healthcare formats such as FHIR and HL7.
What is FHIR? Boy am I glad you asked.
Zoning in: FHIR is difficult
FHIR (Fast Healthcare Interoperability Resources) is a HL7 International standard designed to make healthcare data exchange easier by using modern web technologies (think REST API + JSON). It’s supposed to be the universal language that lets different healthcare systems talk to each other, and the foundation for the next generation of healthcare applications.
The adoption stats are promising: As of 2019, 84% of US hospitals have adopted FHIR-enabled technology, and a recent HL7 survey showed 54% of global healthcare experts expect a strong increase in FHIR adoption.
It all sounds great, except very few people are versed in FHIR. HL7 itself cites this as the biggest barrier to adoption, year after year. I've been on both sides of the hiring process for healthcare projects where "knowledge of HL7 FHIR" is listed as a nice-to-have alongside knowledge of microservices architecture, as if they were equally accessible experiences.
The thing is, unlike AWS and Azure, FHIR expertise2 doesn’t scale. The few developers who do become FHIR experts become bottlenecks, and everyone else builds workarounds or avoids the healthcare data entirely.
From a developer experience perspective, FHIR becomes a hidden knowledge burden you're expected to pick up on the job. Your choices are:
Work around it by converting to custom data structures you’re more comfortable with
Spend an exorbitant amount of time trying to understand it without losing your mind
Neither is ideal: you're either losing efficiency in engineering or time.
Knowing the standard isn’t even the end of the story. People adapt standards. Every healthcare organization speaks its own data dialect. An eye hospital has different needs from a pediatric hospital, which are both more specialized than a general hospital. FHIR is designed to be permissive to allow these variations, but that also makes it harder to interoperate on a systemic level.
It's very much not a case of plug-and-play when you want to talk to multiple different healthcare systems. In other words, healthcare data systems are not composable.
Finally, most healthcare data isn't even in FHIR yet. Legacy systems use FHIR's older HL7 siblings:
HL7v2: A pipe-delimited messaging standard for patient admissions, lab results, and medication orders (still used by 95% of US healthcare organizations!)
CDA: An XML-based standard for clinical documents like discharge summaries, imaging reports, and care continuity records (hello, unstructured data)
Each of these legacy standards come with their own set of eccentricities and kinks, and they’re almost certainly not documented anywhere.
All of this contributes to a development experience that is slow, manual, and time-consuming.
I hated that. I hated that we just accept working with healthcare data is difficult because that's the way it's always been. Think about all the healthcare problems that never get solved because smart engineers are stuck fighting data formats. I think it grossly limits our potential to work together and build better applications.
But maybe it doesn't have to be like this.
The Solution
HealthChain is an open-source Python framework that bridges the gap between AI/ML and healthcare data. It lets you connect AI models to EHR systems, FHIR APIs, and legacy healthcare formats in just a few lines of code, powered by modern tools like FastAPI and Pydantic.
HealthChain started as a side project. It was a collection of utility tools that would’ve made my life easier if I had to do everything all over again. The early version focused on sandbox testing and reference implementations of specific EHR integration points.
After presenting this version at a couple of NHS AI hackathons and conferences, I noticed that although people were enthusiastic about the concept, very few had enough knowledge on FHIR and EHRs to even get started.
The barrier to entry was still too high. It needed more abstraction: something that would let any AI engineer build what I built, without spending years navigating through FHIRly hell (no pun intended).
I wanted to build something that was AI-ready from the ground up that was also compatible with the boring acronyms of healthcare — HL7, FHIR, CDA. And I wanted it to feel as natural as loading a DataFrame in Pandas or deploying a Docker container.
This meant there were a few non-negotiables design principles:
FHIR as the central data structure
Extensibility through composition
Developer-first experience (rarely a top priority for existing solutions in healthcare)
How It Works in Practice
Here’s how these principles translate into actual code. Let’s look at a real example: a clinical documentation improvement service that processes doctor’s notes and extracts billing codes.
Building the pipeline is straightforward:
The gist is that it’s the same DAG pattern ML engineers are familiar with, but it’s FHIR-native under the hood. Which means no more custom data structures and endless conversion code!
The real magic happens when you connect this pipeline to healthcare data sources. If you have to deal with legacy formats, fear not, the InteropEngine will handle conversions between FHIR and CDA, HL7v2. It’s a template-driven converter, so mappings live in config files, not buried in your code. An adapter further bridges the gap and lets you parse and format pipeline objects directly from requests and responses.
The reality is you almost always need multiple data sources. Patient data from your EHR, billing codes from another system, lab results from a third. Instead of building separate integrations for each one, HealthChain lets you mix modern FHIR APIs with legacy systems in the same application:
Finally, deploying should feel seamless to any Python developer. HealthChainAPI is FastAPI under the hood, but with healthcare-specific features: automatic authentication management, routing, and service discovery endpoints.
Each of these steps used to require separate vendors, custom engineering, or months of integration work. Now you can go from model to production in just a few lines of Python code. I think that's pretty neat.
The Future
Healthcare AI is a hard problem. It deserves the best engineers working alongside clinical experts and policymakers. But you can’t attract or retain tech talent on Windows 95 with a dial-up modem.
Months of developer time spent on wrangling with data sources is time that could’ve been spent on building safer, more reliable AI systems that deliver real benefits. True innovation and collaboration can only happen when engineers engage with healthcare problems instead of barely surviving them.
I want to imagine a future where healthcare AI is as easy as web development. A clinician can partner with an engineer and spin up a prototype in a week. Startups can focus on delivering value instead of reinventing the data plumbing. Open-source pipelines can be shared, audited, and improved across research institutions.
In that world, clinicians get decision support tools that actually fit their workflows. Patients benefit from earlier diagnoses, fewer errors, and more personalized care. And health systems see real returns: faster development cycles, reduced duplication, better resource allocation.
That’s the future I want to build, and HealthChain is just the first step in that direction. But this kind of change can only happen when we start building together.
You can check out the code on GitHub, join the conversation in Discord, or dive into the Documentation.
If you’re building healthcare AI, dealing with EHR integrations, or just curious about any of this: reach out or connect with me! I’d love to hear what you’re working on :)
Search was conduced using the keywords "healthcare ai", "ehr", "hl7", "fhir" of repositories with >= 20 stars as of 2025-07-04, filtering for low quality or unmaintained repos. I also went through repos created within the last year with >=5 stars to check for very recent development. Tutorials and lists are excluded from analysis. Labels and quality control may not be super exact, there was a lot to go through!
HL7 does offer official FHIR training and certification by the way. It costs $1000 for non-members and only runs 3 times a year. I am sadly not certified.
[url=https://healthcluster.co/saudi-arabia/]saudi medical cloud[/url]
The best part about the Health Cluster software solutions is they offer HL7 integration, which allows data integration from multiple sources like labs, pharmacies, finance, and ERs, optimizing the Saudi Medical cloud care domain with dental PMS software in Saudi Arabia.
Thanks so much for building this Jennifer. I hope this makes a massive difference to the developer experience. I faced the same problems over 20 years ago, back then everyone was working in Java and XSLT, but the same issues arose.
Finally it feels this problem is solvable!