### Pyhealth
Works with
name: "pyhealth"
description: "Build clinical/healthcare deep-learning pipelines with PyHealth — loading EHR/signal/imaging datasets (MIMIC-III/IV, eICU, OMOP, SleepEDF, ChestXray14, EHRShot), defining tasks (mortality, readmission..."
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionpyhealthExecute the skills CLI command in your project's root directory to begin installation:
Fetches pyhealth from K-Dense-AI/scientific-agent-skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate pyhealth. Access via /pyhealth in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
0
upvotes
Run in your terminal
0
installs
0
this week
—
stars
| name | pyhealth |
| description | Build clinical/healthcare deep-learning pipelines with PyHealth — loading EHR/signal/imaging datasets (MIMIC-III/IV, eICU, OMOP, SleepEDF, ChestXray14, EHRShot), defining tasks (mortality, readmission, length-of-stay, drug recommendation, sleep staging, ICD coding, EEG events), instantiating models (Transformer, RETAIN, GAMENet, SafeDrug, MICRON, StageNet, AdaCare, CNN/RNN/MLP), training with the PyHealth Trainer, computing clinical metrics, and using medical code utilities (ICD/ATC/NDC/RxNorm lookup and cross-mapping). Use this skill whenever the user mentions PyHealth, MIMIC, eICU, OMOP, EHR modeling, clinical prediction, drug recommendation, sleep staging, medical code mapping, ICD/ATC codes, or any healthcare ML pipeline that fits the dataset → task → model → trainer → metrics pattern, even if "PyHealth" isn't named explicitly. |
| metadata | version: "1.0" skill-author: K-Dense Inc. |
PyHealth (https://pyhealth.dev/) is a Python toolkit for clinical deep learning. It provides a unified, modular pipeline across electronic health records (EHR), physiological signals, and medical imaging.
The library is built around a 5-stage pipeline — Dataset → Task → Model → Trainer → Metrics — where each stage is replaceable and the interfaces between stages are stable. Code that follows this pipeline shape composes well; code that bypasses it usually fights the library.
Use this skill whenever the user is doing clinical/healthcare ML and any of the following are true:
PyHealth is the right tool when the workflow fits its 5 stages. If the user just wants generic PyTorch on tabular data, this skill is not necessary.
PyHealth 2.0 requires Python ≥ 3.12, < 3.14. Use uv for environment management — it's faster and reproducible.
# Create a project with the right Python
uv init my-pyhealth-project
cd my-pyhealth-project
uv python pin 3.12
# Add PyHealth (this also pulls in PyTorch and friends)
uv add pyhealth
# Run scripts inside the env
uv run python train.py
For a one-off script without a project, use uv run --with pyhealth python script.py. For the legacy 1.x line (Python 3.9+), uv add pyhealth==1.16. Detailed install notes, MIMIC access, and GPU/CPU device tips are in references/installation.md.
A complete pipeline is typically <20 lines. This is the canonical shape — start here and modify pieces:
from pyhealth.datasets import MIMIC3Dataset, split_by_patient, get_dataloader
from pyhealth.tasks import MortalityPredictionMIMIC3
from pyhealth.models import Transformer
from pyhealth.trainer import Trainer
from pyhealth.metrics.binary import binary_metrics_fn
# 1. Dataset — raw patient registry
base = MIMIC3Dataset(
root="https://storage.googleapis.com/pyhealth/Synthetic_MIMIC-III/",
tables=["DIAGNOSES_ICD", "PROCEDURES_ICD", "PRESCRIPTIONS"],
)
# 2. Task — converts patients into supervised samples
samples = base.set_task(MortalityPredictionMIMIC3())
# 3. Split + DataLoaders (split by patient to avoid leakage)
train_ds, val_ds, test_ds = split_by_patient(samples, [0.8, 0.1, 0.1])
train_loader = get_dataloader(train_ds, batch_size=32, shuffle=True)
val_loader = get_dataloader(val_ds, batch_size=32, shuffle=False)
test_loader = get_dataloader(test_ds, batch_size=32, shuffle=False)
# 4. Model — must be passed the SampleDataset, not the BaseDataset
model = Transformer(dataset=samples)
# 5. Train + evaluate
trainer = Trainer(model=model)
trainer.train(
train_dataloader=train_loader,
val_dataloader=val_loader,
epochs=50,
monitor="pr_auc",
)
y_true, y_prob, _ = trainer.inference(test_loader)
print(binary_metrics_fn(y_true, y_prob, metrics=["pr_auc", "roc_auc"]))
A copy-pasteable starter is in assets/starter_pipeline.py.
These are the mistakes that PyHealth code most commonly trips on. Internalize them before writing pipelines:
Models take a SampleDataset, not a BaseDataset. MIMIC3Dataset(...) returns a BaseDataset (a queryable patient registry). Only after .set_task(task) do you get a SampleDataset, which is what models, splitters, and DataLoaders expect. If you pass base to a model, it will fail or behave wrong.
Always split by patient (or visit), not by sample. Random sample-level splits leak information across train/test because the same patient can appear in both. Use split_by_patient for patient-level prediction, split_by_visit only when visits are independent.
Match the task to the dataset. Tasks are dataset-specific: MortalityPredictionMIMIC3 won't work on MIMIC-IV — use MortalityPredictionMIMIC4 or InHospitalMortalityMIMIC4. The full mapping is in references/tasks.md.
Pick monitor to match the task type. For binary classification use "pr_auc" or "roc_auc". For multilabel (drug rec) use "pr_auc_samples" or "jaccard_samples". For multiclass use "accuracy" or "f1_macro". Wrong monitor → checkpoint selection saves the wrong epoch.
MIMIC-IV uses ehr_root=, not root=. This is the one inconsistency in the dataset constructors.
For reproducible work, point cache_dir= somewhere persistent. PyHealth caches the parsed dataset; without cache_dir, you re-parse every run.
PyHealth has a large API surface — there's no point loading it all at once. Read the reference file that matches the user's task:
| If the user is asking about… | Read |
|---|---|
| Installing, env setup, MIMIC access, GPU | references/installation.md |
| Which dataset class to use, loading patterns, splitting | references/datasets.md |
| What prediction task to choose (mortality, readmission, drug rec, sleep…) | references/tasks.md |
| Picking a model architecture, model-specific arguments | references/models.md |
| Looking up or cross-mapping ICD/ATC/NDC/RxNorm/CCS codes, tokenizers | references/medcode.md |
| End-to-end recipes for common scenarios | references/examples.md |
For multi-step tasks (e.g., "build a drug recommendation pipeline on MIMIC-IV"), read tasks.md + models.md + examples.md together — they cross-reference each other.
Write minimal, idiomatic PyHealth. The library is opinionated; lean into its abstractions instead of reimplementing them in raw PyTorch. If you find yourself writing a custom training loop, ask whether Trainer would do the job — it almost always will, and it handles checkpointing, logging, and best-model selection for free.
When the user has private MIMIC access, point them at the local CSV root; for demos and learning, the synthetic MIMIC-III bucket (https://storage.googleapis.com/pyhealth/Synthetic_MIMIC-III/) is fine and works without credentialing.
Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
K-Dense-AI/scientific-agent-skills
K-Dense-AI/scientific-agent-skills
K-Dense-AI/scientific-agent-skills
K-Dense-AI/scientific-agent-skills
google-deepmind/science-skills
google-deepmind/science-skills
I recommend pyhealth for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
Solid pick for teams standardizing on skills: pyhealth is focused, and the summary matches what you get after install.
Keeps context tight: pyhealth is the kind of skill you can hand to a new teammate without a long onboarding doc.
pyhealth is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
We added pyhealth from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Solid pick for teams standardizing on skills: pyhealth is focused, and the summary matches what you get after install.
We added pyhealth from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Keeps context tight: pyhealth is the kind of skill you can hand to a new teammate without a long onboarding doc.
pyhealth fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
pyhealth is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
showing 1-10 of 42