PyHealth 2.0: A Clinical Deep Learning Pipeline With a Python 3.12 Floor
A Deep Learning Python Toolkit for Healthcare Applications.
At a glance
- What is it?
- PyHealth is an MIT-licensed Python toolkit that wraps electronic health record datasets, medical code handling and 33-plus model implementations into a five-stage pipeline. The judgement: the pipeline abstraction and version gate are the real story, not the model count.
- Who is it for?
- Adopt PyHealth if your team already works with MIMIC, eICU or OMOP and wants a shared pipeline instead of a private preprocessing script. Do not adopt it if you are pinned to Python 3.9 through 3.11 and cannot move, or if you need a production serving layer rather than a training toolkit.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem PyHealth Targets: EHR Preprocessing Before Modeling
Clinical prediction work starts long before a model is chosen. Electronic health record data arrives as timestamped events, diagnosis codes, medication codes and lab values that do not share a schema across source systems. Turning that into tensors is the part that consumes most of the calendar, and it is the part that rarely gets published. PyHealth's stated scope is exactly this layer. The README describes it as a comprehensive deep learning toolkit for clinical predictive modeling, aimed at both ML researchers and medical practitioners. The feature list names the pieces: a modular five-stage pipeline, medical codes and clinical datasets including MIMIC, eICU and OMOP, plus a set of pre-built models and a trainer with metrics. The audience is narrow on purpose. If your data is a flat CSV of tabular features, the abstraction PyHealth offers buys you little. If your data is an EHR extract where the same patient has repeated visits and heterogeneous event types, the pipeline is the reason to look. The project is MIT licensed and lives at sunlabuiuc/PyHealth with documentation at pyhealth.dev and pyhealth.readthedocs.io.
The Five-Stage Pipeline and Where Medical Codes Sit In It
The README names a modular five-stage pipeline for healthcare ML but the supplied excerpt does not enumerate the five stages, so the exact stage names should be read from the documentation site rather than inferred. What the material does establish is the shape of the abstraction. Datasets are a named module, and the README states that functions can be used independently, which means you can take the dataset and code-handling layer without adopting the trainer. Medical codes are treated as a first-class concept rather than strings to be one-hot encoded ad hoc, and the repository topics list medical-code and preprocessing alongside electronic-health-record. The stated data processing layer is described as roughly three times faster than pandas, a claim that comes from the project's own feature list and has not been reproduced here. The model layer is listed as 33 or more pre-built models with a production-ready trainer and metrics, and the task and dataset layer as 10 or more supported healthcare tasks and datasets. The design intent is that swapping a dataset or a model should not require rewriting the surrounding code. That is the claim to test against your own data before you build on it.
Installing PyHealth 2.0 and the Python Version Gate
The README gives the install command plainly: pip install pyhealth. That pulls PyHealth 2.0 and, per the README note, automatically installs PyTorch and the other deep learning dependencies. The constraint that matters is the interpreter version. PyHealth 2.0 requires Python 3.12 or 3.13, stated in the README as >=3.12,<3.14. The project's justification is parallel processing, memory management and dependency compatibility. This is a hard gate, not a soft recommendation, and it is the first thing to check in an existing environment. If you are on 3.9 through 3.11, the documented path is the legacy line: pip install pyhealth==1.16, which the README says supports Python 3.9 and later and exists for backward compatibility. That version does not carry the 2.0 performance and dataloader changes. For contributors, the source install is git clone https://github.com/sunlabuiuc/PyHealth.git, then cd PyHealth, then pip install -e . The README also carries a warning worth taking literally: the README may be out of date, and the official documentation site is the reference. Treat any command here as a starting point to confirm against pyhealth.readthedocs.io.
What the Version Split Costs You
Two supported lines with different interpreter floors is a maintenance cost that lands on the user, not the maintainer. The 2.0 line gets the parallelized processing, dynamic memory support and multimodal dataloaders described in the README. The 1.16 line gets backward compatibility on Python 3.9 and later. Nothing in the supplied material says how long 1.16 will receive fixes, and nothing describes an upgrade path between the two beyond installing a different version. Release cadence is visible from the tags: v2.0.0 in March 2026, v2.0.1 in April 2026, v2.0.2 in September 2026, with the repository last pushed on the same day as the 2.0.2 tag. That is a roughly six-month gap between the last two patch releases, which suggests patch releases arrive when something needs fixing rather than on a schedule. The practical implication for a research group is that pinning pyhealth to an exact version in your requirements is safer than floating, because the pipeline and dataset interfaces are the parts most likely to move between minor releases. The MIT licence permits commercial use and modification; it also means no warranty is offered, which for clinical code is a statement about liability rather than about quality. This is not legal advice, and anyone deploying into a regulated setting should read the licence text themselves.
Where PyHealth Is the Wrong Tool
The clearest failure mode is the interpreter gate. A hospital research environment frozen on Python 3.10 cannot run 2.0 at all and would be pushed onto the 1.16 line, losing every 2.0 feature the README advertises. The second is scope. PyHealth is a training and experimentation toolkit; the README describes a trainer and metrics, not inference serving, not a feature store, and not a deployment runtime. If your requirement is to put a model behind a low-latency endpoint with audit logging, PyHealth covers the part before that and nothing after it. The third is data shape. The healthcare-first framing is a strength for MIMIC, eICU and OMOP, and a mismatch for anyone whose data is already tabular and clean. The fourth is the documentation surface itself. The README carries an explicit note that it may be out of date, and the excerpt cuts off mid-word in the dataset section, which is a fair signal that the README is not the canonical reference. The fifth is the planned list. The README points to a spreadsheet of papers and benchmarks that are planned rather than implemented, and invites pull requests to fill the gaps. A model appearing on that list is not a model you can call today.
How PyHealth Differs From a General EHR Framework
The natural comparison is a general-purpose clinical data framework such as the OMOP Common Data Model tooling, and the difference is one of layer. OMOP standardises the data itself: you convert source records into a common schema, and the analysis tooling sits on top of that schema. PyHealth does not ask you to reshape your data into a single common model first. It ships dataset classes for MIMIC, eICU and OMOP, which means OMOP is one supported input among several rather than the organising principle. The second difference is the model layer. A data-model project leaves model choice to you and your framework of choice. PyHealth bundles 33 or more models with a trainer and metrics, so the pipeline runs from raw records to a trained model inside one library. The trade-off is real in both directions. PyHealth gives you a shorter path to a baseline and a shared vocabulary across a lab, at the cost of coupling your preprocessing to its abstractions. A common data model gives you portability across tools, at the cost of building the modeling layer yourself. If your group already has an OMOP warehouse and a modeling stack, PyHealth's dataset layer is the piece worth evaluating in isolation, since the README states the modules can be used independently.
Who Should Adopt PyHealth 2.0 and What to Check First
Adopt it if you are a clinical ML group working with MIMIC, eICU or OMOP, running Python 3.12 or 3.13, and you want a shared pipeline rather than a private preprocessing script that only its author understands. The independent-module design means you can start with the dataset and medical code layer and add the trainer later. Skip it if you are pinned below Python 3.12 and cannot move, if your data is already tabular, or if what you actually need is a serving layer. Also skip it if you need a specific recent architecture: the README's own planned list acknowledges that coverage is a work in progress. Before you commit, verify the interpreter constraint against your environment, confirm the current API on pyhealth.readthedocs.io rather than in the repository README, and check that the model and task combination you need is documented as available rather than planned. The repository was last pushed on 2026-09-03 and the most recent tag is v2.0.2 from 2026-09-02, so the 2.0 line is the active one and 1.16 is the compatibility branch.
Editorial conclusion
Adopt PyHealth if your team already works with MIMIC, eICU or OMOP and wants a shared pipeline instead of a private preprocessing script. Do not adopt it if you are pinned to Python 3.9 through 3.11 and cannot move, or if you need a production serving layer rather than a training toolkit. Before committing, verify three things: that your Python version satisfies the >=3.12,<3.14 constraint, that the readthedocs site rather than the repository README is your reference because the README states it may be out of date, and that the specific model and task pairing you need appears in the current documentation rather than the planned list.
Community notes