Local-first healthcare AI: clinical NER & HIPAA PII de-identification that runs 100% on-device. 1,000+ medical models, 12 languages, Apple MLX + Python, no cloud, no patient data leaving your network. Apache-2.0
4.4k
Stars
532
Forks
460
Open issues
30
Contributors
AI Analysis
OpenMed is a local-first healthcare AI platform that performs clinical named entity recognition and HIPAA-compliant PII de-identification entirely on-device, with no data leaving the user's network. It provides 1,000+ medical models across 12+ languages via Python, Swift/iOS, Apple MLX, and browser APIs. This project is specialized for healthcare organizations, regulated environments, and medical AI practitioners who require sovereign data processing and compliance guarantees; it is not a gen...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
On-device clinical NER and PII redaction for healthcare, runs locally on Python and iOS
OpenMed is a Python library and Swift framework for clinical natural language processing — primarily entity extraction and HIPAA-aware de-identification — that executes entirely on user hardware with no cloud calls. Built for healthcare organizations, compliance-sensitive workflows, and edge devices, it packages 1,000+ biomedical models across 12 languages. Targets practitioners who require data privacy guarantees, offline capability, or cost control over API-based alternatives.
Created October 2025, OpenMed emerged as a response to regulatory and privacy constraints in healthcare AI — specifically HIPAA concerns and the need for on-device inference. The project is centered on Apache-licensed models curated from Hugging Face and adapted for local inference via Apple MLX and Python backends.
227 stars gained in the last 7 days (as of 2026-06-28) suggests recent momentum, likely driven by healthcare industry interest in local-first AI and regulatory compliance tools. The project is less than 9 months old, so absolute star count (3,858) reflects early-stage traction rather than long-term adoption patterns. Multilingual documentation and native iOS support indicate deliberate positioning for global healthcare use.
Adoption not verified in README. No case studies, enterprise deployments, or user testimonials provided. arXiv paper suggests academic backing, but README does not cite production usage or pilot programs. Presence on PyPI and Hugging Face indicates infrastructure readiness, but real-world deployment scale is undocumented.
Appears to be a Python wrapper around curated biomedical models (primarily from Hugging Face) with routing to specialized tasks (NER, PII de-identification). README indicates Apple MLX backend for Silicon acceleration and a separate Swift/CoreML bridge (OpenMedKit) for iOS/macOS. Architecture not fully visible from README alone; likely uses transformer-based models with model cards published on Hugging Face.
Not documented in README. No mention of test suites, CI/CD pipelines, or validation benchmarks beyond the referenced arXiv paper (2508.01630).
Last push 2026-06-27 (1 day before evaluation date) indicates very recent activity. Repository is 8 months old and shows active development velocity. However, project maturity cannot yet be assessed — initial stability and long-term maintenance patterns unclear given short operational history.
ADOPT IF: your organization requires healthcare NLP with guaranteed on-device execution, HIPAA compliance via data minimization, or cost control for high-volume clinical text processing; you have Python or iOS deployment paths and can tolerate model curation/customization. AVOID IF: you need production SLAs, extensive model fine-tuning support, or real-time inference at enterprise scale without infrastructure investment; if your NLP tasks require models beyond the pre-curated 1,000 or you lack on-device compute. MONITOR IF: you are evaluating local healthcare AI and want to track adoption evidence, model coverage expansion, and long-term maintenance — the project is very early and production usage is not yet documented.
Independent dimensions
Mainstream potential
4/10
Technical importance
7/10
Adoption evidence
2/10
- Adoption not verified: no public production deployments or case studies documented; unclear if project is used in real healthcare workflows or remains primarily academic.
- Model curation maintenance burden: 1,000+ models require ongoing evaluation and updates; README does not detail model versioning, deprecation policy, or update frequency.
- Inference latency not benchmarked in README: on-device execution speed and hardware requirements (GPU, RAM, storage) for model loading not documented; may be a practical barrier for resource-constrained edges.
- Short operational history: project is 8 months old; long-term maintenance commitment, API stability, and community support patterns not yet established.
- Regulatory compliance: README claims HIPAA-awareness but does not detail compliance validation, audit trails, or liability/warranty terms; organizations cannot assume Apache-2.0 license satisfies regulatory obligations without legal review.
OpenMed is likely to remain a specialized, privacy-focused tool used by compliance-sensitive healthcare organizations and research groups. It may grow adoption within regulated healthcare settings (hospitals, clinics, research institutions) where data residency is non-negotiable, but is unlikely to become a dominant general-purpose medical NLP platform. Long-term viability depends on sustained model curation, community contributions, and documented production deployments.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- https://openmed.life/
- Language
- Python
- License
- Apache-2.0
- Last updated
- 23h ago
- Created
- 9mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Generate the 1.8-to-1.9 migration guide from an API-surface diff with a CI completeness gate
Add a ground-then-export FHIR pipeline example with a conformance round-trip test
Write a threat model and hardening pass for the multilingual ingestion surface
Sign release wheels and attach verifiable build provenance in the publish workflow
Verify signed model-manifest hashes at download and add an offline models verify command
Top contributors
Similar repos
Project-MONAI/MONAI
MONAI is a PyTorch-based open-source framework for deep learning in healthcare...
tinyhumansai/openhuman
OpenHuman is a local-first personal AI platform written in Rust that combines...
FreedomIntelligence/OpenClaw-Medical-Skills
OpenClaw Medical Skills is a curated library of 869 AI agent skills designed to...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
4.4k | +394 | Python | 8/10 | 23h ago |
|
|
8.4k | — | Python | 8/10 | 4d ago |
|
|
34.6k | — | Rust | 6/10 | 13h ago |
|
|
47.5k | — | Go | 8/10 | 5h ago |
|
|
2.8k | — | Python | 7/10 | 3w ago |
|
|
2.9k | — | Python | 8/10 | 3w ago |
MONAI is a PyTorch-based medical imaging framework focused on radiology workflows; OpenMed targets clinical text and NLP tasks. Different domains (imaging vs. NLP), though both serve healthcare. MONAI has 2.2x the GitHub stars and longer operational history.
LocalAI is a general-purpose local LLM server; OpenMed is healthcare-specialized with pre-curated medical models and HIPAA-aware components. LocalAI is significantly larger (47k stars) and language-agnostic; OpenMed trades generality for medical domain depth.
Both target medical NLP. OpenClaw focuses on medical knowledge and reasoning; OpenMed emphasizes privacy-preserving entity extraction and de-identification. Comparable star counts suggest similar early-stage adoption.
OpenMed's primary value proposition is local-first execution and zero data egress; cloud APIs offer managed service, broader annotation coverage, and enterprise SLAs at per-call cost. Orthogonal tradeoff: privacy vs. convenience.