AI Frameworks · maziyarpanahi

openmed

OpenMed is a Python-based healthcare AI framework for clinical named-entity recognition (NER) and PII de-identification that runs entirely on-device without cloud connectivity. It provides 1,000+ specialized medical models across 15 languages, with native support for iOS/macOS via Swift, Apple MLX acceleration, and browser deployment.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/maziyarpanahi/openmed

4.3k

GitHub stars

505

Forks

Python

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	maziyarpanahi/openmed
Owner	maziyarpanahi
Primary language	Python
License	Apache-2.0 — OSI-approved
Stars	4.3k
Forks	505
Open issues	461
Latest release	v1.7.0 (2026-07-01)
Last updated	2026-07-07
Source	https://github.com/maziyarpanahi/openmed

What openmed is

OpenMed exposes clinical NLP tasks through a unified Python API (transformers-based), supporting multiple backends: CPU, CUDA, Apple MLX for 24–33× speedup on Apple Silicon, and browser/WebGPU via Transformers.js. Models are published on Hugging Face; the framework includes PII detection (18 Safe Harbor identifiers), de-identification with format-preserving fakes, REST service via FastAPI, and native Swift bindings (OpenMedKit) for offline iOS/macOS inference.

Quickstart

Get the openmed source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/maziyarpanahi/openmed.git2cd openmed3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Regulated healthcare workflows requiring air-gapped processing

Deploy clinical NER and PII de-identification in HIPAA-subject environments (hospitals, payers, EHRs) where patient data cannot leave the premises. No cloud vendor, no data transmission, full audit control.

Native medical apps on iOS/macOS with offline inference

Use OpenMedKit (Swift) to embed clinical text analysis, redaction, and entity extraction directly into iPhone/iPad applications, enabling field scanning, offline note review, and privacy-first mobile workflows.

Multi-lingual clinical annotation at scale (CPU or CUDA)

Batch process large volumes of clinical text in 15 languages on institutional infrastructure (on-premise or managed cloud compute), extracting standardized medical entities without per-call API fees.

Implementation considerations

Model selection: Choose task-specific checkpoints (disease_detection_superclinical, privacy_filter, etc.) from 1,000+ options; incorrect model choice or parameterization can harm recall/precision.
Hardware requirements: CPU inference is feasible for modest throughput; CUDA or MLX strongly recommended for production latency. iOS apps must account for model download/storage (~100–500 MB per model).
PII de-identification workflow: Requires careful tuning of Safe Harbor rules, entity merging logic, and fake-generation format to meet your jurisdiction's requirements; not a turnkey compliance tool.
MLX on Apple Silicon: Requires macOS 14+, hardware Apple chips (M1+). CoreML fallback available but model coverage is limited; test thoroughly on target devices.
Version stability & maintenance: Latest release is v1.7.0 (July 2026). Monitor GitHub for breaking changes; no LTS or backward-compatibility guarantee documented.

When to avoid it — and what to weigh

You require commercial SLA, professional indemnity, or vendor support — OpenMed is community-maintained open-source. While Apache-2.0 permits commercial use, there is no formal support channel, SLA, or professional services tied to the project. Evaluate carefully for mission-critical clinical deployments.
Your infrastructure lacks GPU or Apple Silicon acceleration needs — CPU inference on large clinical corpora will be slow. If you need sub-second latency at scale, you will require CUDA or MLX infrastructure; cloud APIs may be simpler.
You depend on proprietary, closed-source model licensing — All models are open and published on Hugging Face under permissive licenses. If your compliance or business model requires proprietary model weights, this does not fit.
Real-time clinical decision support with highest confidence demands — OpenMed models are good but not validated by FDA or equivalent bodies. For critical care, emergency triage, or life-or-death decisions, a regulated medical-grade system is required.

License & commercial use

Apache License 2.0 (Apache-2.0). Permissive OSI-approved license allowing commercial use, modification, and distribution provided the original license and copyright notice are retained. No royalty or liability. All dependencies must also be checked for license compatibility.

Apache-2.0 explicitly permits commercial use. However, OpenMed is community-maintained with no formal vendor, SLA, or professional indemnity. Commercial users should: (1) audit dependencies for license compliance; (2) conduct your own validation and testing; (3) consider forking or maintaining internally if stability/updates are critical; (4) consult legal counsel on HIPAA Business Associate Agreement (BAA) implications (the project itself does not provide a BAA).

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Strong
Assessment confidence	High

Security considerations

OpenMed is designed for on-device inference, which minimizes network exposure and aligns with privacy-first principles. Key security considerations: (1) Model weights and code are open-source; if you require proprietary models, this does not fit; (2) No built-in authentication, encryption, or audit logging—implement these at the application layer; (3) Dependency chain security: verify all Python and system dependencies for CVEs before production; (4) iOS/macOS: relies on OS-level sandbox and data protection; test on target OS versions; (5) PII de-identification is a data utility, not cryptography—test redaction accuracy on your clinical text types before considering it production-safe; (6) No formal security audit, threat model, or incident reporting process published.

Alternatives to consider

Hugging Face Inference API (cloud-based clinical models)

Cloud-hosted alternative for clinical NER/PII detection; managed SLA, professional support, and scalability, but data leaves your network and incurs per-call costs. Best if you accept cloud processing and need vendor backing.

ClinicalBERT / MedSpaCy (self-managed open models)

Lower-level transformers and spaCy-based frameworks; more flexible but require custom pipeline engineering. Better for research or when you need non-standard entity types; less turnkey than OpenMed.

Proprietary HIPAA-compliant APIs (AWS Comprehend Medical, Google Healthcare NLP, etc.)

Enterprise-grade SLA, compliance certifications (HIPAA, SOC 2), professional indemnity, and regulatory support. Data processed in regulated environments; best for highly regulated institutions but costlier and vendor lock-in.

Software development agency

Build on openmed with DEV.co software developers

If you are building regulated healthcare systems, native mobile medical apps, or batch clinical NLP pipelines where patient data must stay on-premise, request a technical review and pilot. OpenMed is free and open; our team can help you assess model fit, deployment architecture, and compliance strategy.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

MedicalGPT OpenLLM opensquilla

Related on DEV.co

Explore the category and the services that help you build with it.

AI Frameworks AI/ML Application Development API Development & Integration Cloud Deployment & Infrastructure Talk to DEV.co

openmed FAQ

Is OpenMed HIPAA-compliant out of the box?

No. OpenMed provides de-identification and PII detection utilities, but compliance requires your organization to conduct a Risk Assessment, sign a Business Associate Agreement (BAA) with any cloud component used for hosting, ensure audit logging, and validate redaction accuracy on your data. The software itself does not provide a BAA. On-device processing helps reduce regulatory scope.

Can I use OpenMed in a production EHR or hospital system?

Technically yes, but with caution. OpenMed models are not FDA-cleared or clinically validated. Use only for administrative/de-identification tasks or as a pre-filter, not for diagnostic decision support. For clinical decision support, choose a regulated medical-grade system or conduct your own validation study and obtain informed consent.

What is the performance vs. cloud APIs like AWS Comprehend Medical?

Not directly benchmarked in provided data. OpenMed models are open and published; accuracy varies by model and domain. Cloud APIs offer managed tuning, SLA, and enterprise support. For detailed comparison, you must run head-to-head evaluation on your clinical text samples.

How do I deploy OpenMed to production at scale?

Options: (1) Python API + FastAPI REST service in Docker/Kubernetes for on-premise or managed cloud compute; (2) OpenMedKit for iOS/macOS apps with offline models; (3) Transformers.js/WebGPU for browser deployment (subset of models). No turnkey managed service; you own infrastructure and updates.

Work with a software development agency

Adopting openmed is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate ai frameworks software in production.

Evaluate OpenMed for Your Clinical Workflow

Talk to DEV.co Schedule a Consultation