Ever since I read Chip Huyen’s blog post What I learned from looking at 900 most popular open source AI tools, I’ve wanted to do the same for the healthcare AI landscape. Is there even such as thing as a healthcare AI stack? There is one now!
Data
I searched GitHub using the keywords healthcare ai, ehr, fhir, hl7 and topics healthcare + ai, healthcare + llm. My initial search yielded 1183 unique results: not bad, but a first pass through the dataset showed that many of these repos were either archived or had low development activity. 1
To filter for quality, I restricted my results for repos with star counts >= 20 and last commit dates within the last 2 years.
To ensure I’m also catching recent development and projects, I went through repos with low star counts that were created after 2023-01-01 to include tools particularly worth highlighting. I added additional topic searches including machine-learning, deep-learning, as well as specific key terms like mcp, omop, mimic. 2
138 were references, tutorials, and public archives; 24 were lists. These can be extremely useful references but excluded from the analysis as they were not software tools themselves.
You can check out the full dataset here and explore the interactive visualizations here.
The methodology and code is available on GitHub. Everything was manually labelled/reviewed, so if I’ve missed anything, please let me know!
The Healthcare AI Stack
Unlike the general AI/ML stack, where most tools fit into model, application, or infrastructure development, it was much harder to draw neat boundaries in the healthcare AI space. I tried to stick roughly to the general ML stack:
Infrastructure
The plumbing that makes it all possible — includes open source EHRs (openemr, ehrbase), FHIR servers, and general tooling for security, serving, and analytics on big data platforms (google/fhir-data-pipes).Interoperability
Half infrastructure, half tooling, this is where all your converters, gateways (fasten-onprem, nextgenhealthcare/connect), data validation (fhir.resources, apple/fhirmodels), and client SDKs (hapi-fhir, firely-net-sdk) live. It’s all about connecting systems and transforming data.Model Development
This layer is similar to a general AI/ML definition, but applied to a healthcare-specific context. Includes tooling for modeling & training (MONAI, PyHealth), synthetic data (synthea), dataset processing (mimic-code), and evaluation / benchmarks.Healthcare AI (HAI) Engineering
An emerging layer. I define this as tools for integrating and productionizing AI systems into healthcare environments; in other words, it’s about making AI work for healthcare applications. It includes deployment frameworks (monai-deploy, healthchain), demo projects, and MCP servers.
(App Development)
The modernization of the healthcare infrastructure stack means that there are more dev tools built on top of modern web languages like Typescript/Javascript. This is not usually part of an AI engineering stack, but I thought it was cool to highlight and show the adoption of FHIR.
(Model Repos)
These are repositories that contain the running code for specific models. In most cases, these are associated with specific research papers.
Both categories are included in the spreadsheet, but excluded from the analysis.
Interoperability: the hidden tax layer
Interoperability is a word we like to throw around in healthcare a lot, but what is interoperability, and who is it for? I’m going to take a practical, developer-centric definition here: how do I get my data from A to B as efficiently as possible without losing information. I roughly categorized the tools into the following subcategories:
Client SDKs: Usually to interact with FHIR servers. Hi, can I get some data, please?
Gateways & Connectors: Integration engines, APIs, gateways that get data from A to B. It might offer some components below as part of its offering
Converters & Transformers: It just gets data from format A to format B, without the infrastructure
Data Standards & Mapping: While conversion refers to structural transformation (getting data from format A to format B), mapping refers to semantic transformation: given format X and format Y, how do we translate the meaning in X to Y with minimal information loss? It’s not just reshaping, but also preserving what the data actually means across different coding systems (Think SNOMED CT, LOINC, OMOP). I also included CQLs here, which is about extracting additional semantic meaning.
Data Models & Validation: Data structures that contain and validate data in various formats. Spiritually, it’s the engineering equivalent of checking if you turned the stove off before leaving the house.
I think of this layer as the “hidden tax layer” in healthcare AI. It’s essentially infrastructure masquerading as data preprocessing because no one else is going to get your data exactly the way you want it, and it always ends up more work than you expect; there’s nothing worse than the feeling of finding out you’re running a half-marathon when you thought you were done at 10k.
The most popular tools in this category are interoperability products such as Mirth Connect (close sourced since July 2025, RIP), Fasten Health, Metriport, as well as open sourced projects from Google and Microsoft. The only repo in the top 10 tools in this layer owned by an individual is fhir.resources: a Pydantic implementation of FHIR resources (which I’m eternally grateful for).
And there are many, many more: over half of the tools (54%) in this layer fall under the subcategory of Data Models & Validation or Client SDKs: implementations and ports of various healthcare standards, validated in different languages. It seems like the work is not done when data is converted from one format to another: devs still need tooling to work with them.
Model Development: everything is still on FHIR
Research labs dominate this layer. Here we are concerned with the basic AI/ML workflow of data processing / feature extraction → training → evaluation. What makes this layer interesting is that you have to look at it in context: these tools were developed on top of a more mature AI/ML ecosystem, presumably to satisfy a need that was lacking.
Dataset Processing
To my surprise, we’re still seeing a lot of FHIR converters at this level, just aimed at data scientists. This is somewhat of an anomaly: as you go higher up the stack, you expect to find less low-level infrastructure concerns. But here lies the dilemma of productionizing AI/ML systems in healthcare: to deploy models into real-world use cases, your inputs and outputs need to be in the right ComplexHealthCareFormat™. The options are:
Train your entire model in ComplexHealthCareFormat™ end-to-end. You avoid converting your data, but it requires enormous compute, infrastructure, and resources. Basically, only an option if you’re Google.
Convert your data from ComplexHealthCareFormat™ to a more ML friendly format (CSVs, Pandas DataFrames) — i.e. the normal option.
The fundamental problem here is research and production speak different languages. Researchers train on nice, tabular MIMIC extracts (CSVs, SQL databases), but production systems speak FHIR APIs and HL7 streams. You can build a great model on MIMIC, but the moment you want to put it in the real world, you’re back to wrestling with ComplexHealthCareFormat™.
And you can see this mismatch reflected in the tooling. FHIR to Pandas, MIMIC to FHIR, Synthea to OMOP, FHIR to R — everyone’s building bridges for between training and production. It’s common to see “do-all” tools: yes, this is a FHIR converter, but it’ll also connect to servers, flatten your resources, and do your laundry for you. If I wanted to get something up and running quickly, I’d have to sift through many, many tools before I find one that does just the right number of things without adding bloat. Sort of like a precarious game of Tetris where you either only get those weird Z shaped pieces or squares and nothing in between to fill the gap.
Healthcare data is ridiculously specific. What works for one hospital won’t work for the next, even if they look similar on paper. So everyone ends up building their own bridge. It’s not that data scientists want to deal with format conversion; it’s that the training-to-production gap hasn’t been solved yet.
Evaluations
Another interesting thing to see is the uptick in evaluation frameworks since the GenAI boom. In no particular order, some of the recent development I found the most interesting:
epic-open-source/seismometer: a suit of AI model evaluation tools by Epic (yes, the same Epic that’s notoriously protective of its inner workings and has never open sourced anything in the past 40 years it’s been in business)
som-shahlab/ehrshot-benchmark: A benchmark for few-shot evaluation of foundation models on EHR data, consisting of de-identified longitudinal data of 6,739 patients from Stanford Medicine. I love MIMIC, but it’s great to see more EHR benchmarks with fully open datasets and weights.
flexpa/llm-fhir-eval: I seriously think there’s a lot of potential in using LLMs for FHIR generation and validation, given its structured nature. It’s something I want to get around to eventually once I’m done staring at spreadsheets, so it’s great to see Flexpa’s initiative on this (does anyone know what happened to FHIR GPT? I swear it used to be on HF)
Not included in GitHub’s dataset but also worth a mention is OpenAI’s HealthBench dataset (available on HuggingFace), notable for being the only benchmark with an accompanying real-world clinical deployment study.
HAI Engineering: an emerging layer
Healthcare AI Engineering is the newest layer, only 12–18 months old at best. It’s not really an established discipline and low-key kind of niche, so you’re usually either someone who knows AI/ML but not healthcare, or vice versa. The hybrid expertise is extremely rare unless you happened to work on the right project at the right time.
But something’s shifting. Since Anthropic introduced Model Context Protocol (MCP) in November 2024, this layer has seen a notable bump. MCP servers now make up 50% of this layer (11/21), and nearly all focus on FHIR server operations. It’s a promising expression of interest: developers want to wire LLMs into clinical workflows, and they’re building connectors because standardized tooling doesn’t exist yet.
The abundance of starter and demo projects shows this is still immature territory where developers share “here’s how I wired this together” rather than “here’s the standard way.” This mirrors early development in other dev tool categories: deployment scripts were shared before Docker emerged, demo apps were everywhere before streamlit/gradio, and devs were building custom chain-like logic in Jupyter Notebooks before LangChain came along. When you see this much DIY activity, it means: (1) real demand exists, (2) the right abstraction hasn’t formed yet, (3) whoever builds good abstractions wins.
I think it’s pretty exciting that we’re watching this layer form in real-time. The combination of agents/LLM tool calls and FHIR standardization means developers are tackling similar problems — fetching patient data, running inference, writing results back, handling errors.
Healthcare AI engineering is becoming a real thing, and this is what I hope HealthChain contributes to: helping those abstractions settle into something developers can actually build with.
Who’s Building (And Where It’s Going)
Looking at who’s actually contributing across all 400 repos:
Big tech dominated the early years: Google and Microsoft led infrastructure and interoperability, AWS launched HealthLake in 2021. But AWS quietly archived nearly everything by 2023 as they matured the managed service. Google and Microsoft still maintain repos, though activity has slowed.
The counter-trend is more interesting. Venture-backed startups like Medplum, Canvas Medical, Tuva Health are building based on transparency and positioning open source as core to their value proposition. Others like Flexpa and Momentum are experimenting with healthcare AI tooling in the open. The surprise of the year is Epic releasing its own open source AI evaluation tool: even the most locked-down vendor now participates in OSS.
There’s no doubt big tech owns a knowledge moat (compliance, infrastructure, regulatory). I’ve heard people say they’d rather have Google / Microsoft handle the infrastructure burden, and honestly that makes sense in a risk-averse industry like healthcare. But developer tooling operates differently. In general AI/MLOps, we saw this play out: AWS/Azure/GCP built managed ML services, but developers standardized on PyTorch, Hugging Face, and MLflow because those tools prioritized developer experience over integration with cloud billing.
Healthcare AI is following the same pattern. The compliance moat doesn’t help you build better abstractions for clinical workflows, it just means you have more stakeholders to satisfy. Open source tooling wins developer mindshare by focusing on making hard things easy, leaving the infrastructure layer as commodity hosting underneath.
As FHIR adoption grows and AI models improve, deployment is where the real gap lives. Healthcare AI is at an inflection point: will we repeat AWS’s pattern or see an OSS countermovement like Kubernetes and PyTorch? The evidence suggests the latter is possible. Startups are open-sourcing. Epic is participating. Healthcare infrastructure is maturing, and developer tooling is finally getting attention. It’s early and fragmented, but the direction is clear.
Data cut off around November 2025. I might update the metadata periodically.
An earlier version of this survey only included the initial search terms, and the repositories were categorized slightly differently.
Excellent foundation 🛠️