OpenMed SDK 2.0.0 · local-first clinical AI

Your data.
Your model.
Your hardware.

OpenMed extracts biomedical entities and supports de-identification across 50 registered PII entity labels on hardware you control. Label coverage varies by model. Core inference can run locally after required artifacts are present; downloads and configured integrations may use a network. The SDK source is Apache-2.0-licensed; model and dataset terms vary.

1,520 unique entries in the committed catalog snapshot · 34 supported PII routes · 33 model-backed

pii.detect() · local process 5/5 · masked
Patient [NAME], MRN [ID], DOB [DATE], contact [PHONE], admitted to [HOSPITAL].
Fictional patients · no real PHI Animation pauses with reduced motion
Community OpenMed SDK · community-driven

Committed model catalog snapshot

1,520

The committed catalog snapshot contains 1,520 unique entries. Availability can change upstream, so verify each repository before use. Join the work on GitHub.

662 MLX-format manifest entries
655 PII-family manifest entries
33 Model-backed PII languages
34 Supported PII routes, including one placeholder
Repository version OpenMed SDK 2.0.0 · publication status is separate
Local-first runtime Supported adapters vary by artifact and environment
Apache-2.0 SDK source Model and dataset terms vary by source

Committed repository snapshot · 29 July 2026 · exact values, not live service counters

Quickstart
openmed 2.0.0 · quickstart

Python

from openmed import deidentify, extract_pii

note = "Patient Casey Example, MRN 00123."
entities = extract_pii(note, lang="en")
print(deidentify(note, lang="en", method="mask").deidentified_text)

Install

uv pip install "openmed[hf]"

# Download or mirror model assets once.
# Then run inference in your own process.

Four lines, no account.

Install the library, choose a model route, and keep the processing boundary inside infrastructure you operate. Model downloads are explicit; inference can continue from a local cache or private mirror.

  • analyze_text(...) for structured clinical extraction
  • extract_pii(...) and deidentify(...)
  • Batch, REST, and gRPC surfaces with no-PHI logging controls
  • Deterministic validators and audit-oriented outputs
Read the quickstarts
Deployment checklist

Choose the deployment boundary before the model.

Clinical NLP can arrive as a remote API, a licensed self-hosted stack, a research toolkit, or an open runtime you operate. The useful comparison is what each delivery model requires from your data and team.

Deployment questions for OpenMed, cloud APIs, licensed self-hosted software, and research toolkits
Decision OpenMed Cloud API Licensed self-hosted Research toolkit
Inference location Hardware you operate Confirm processing region and subprocessors Confirm product architecture Confirm package and model behavior
Network needed for each inference Core inference can run after required assets are present Confirm runtime connectivity requirement Confirm runtime connectivity requirement Confirm package and model behavior
Library license Apache-2.0 SDK; model licenses vary Review current service terms Review current commercial agreement Review code, model, and dataset licenses
Phone and tablet runtime OpenMedKit and ONNX Runtime Mobile Confirm supported client boundary Confirm supported runtime Confirm integration path
Browser-local inference Transformers.js and WebGPU exports Confirm browser processing boundary Confirm supported runtime Confirm model compatibility
Reproducibility evidence Repository tests and evaluation tooling Request scoped evidence Request scoped evidence Inspect project evidence

Decision checklist, not a vendor capability matrix · reviewed 29 July 2026

Supported runtime paths

The same local-first contract, from a phone to a GPU server.

The OpenMed SDK keeps model selection and structured outputs aligned across native, browser, Python, and service surfaces. Validate exported artifacts on every target runtime.

Python · CPU · CUDA

Library and services

Run direct Python calls, batch pipelines, or Dockerized REST and gRPC services inside your own network boundary.

REST and gRPC guide

Apple Silicon · MLX

Local acceleration

Use MLX model artifacts on Apple Silicon with explicit download, cache, and local-directory paths.

MLX backend guide

OpenMedKit · Swift + Kotlin

On-device applications

Integrate local extraction and de-identification on Apple platforms and Android with platform-specific artifact validation.

OpenMedKit guide

Browser · WebGPU

Process before submit

Export compatible token-classification artifacts so text can be processed in the tab before an application chooses to send anything.

Browser export guide
Healthcare data privacy

De-identification you can inspect and test.

OpenMed can support a deployment's de-identification controls across 50 registered PII entity labels. Label coverage varies by selected model. Expert deployment review remains required; SDK use alone does not establish compliance.

View the built-in PII language contract

OpenMed exposes 34 supported PII language codes: am, ar, as, bn, cs, da, de, el, en, es, fr, he, hi, id, it, ja, ko, mr, nl, no, or, pt, ro, ru, sv, sw, ta, te, th, tr, uk, xh, zh, zu.

These codes identify 34 supported routes: 33 are model-backed, while Russian uses a named placeholder model. Optional user-configured routes and validator-only national-ID locales are documented separately.

Audit-oriented outputs

Keep span offsets, policy decisions, hashes, provenance, and risk evidence without placing raw identifiers in audit artifacts.

provenancerelease-gates

Context-aware detection

Combine model spans with nearby clinical cues and configurable thresholds, then validate recall on data representative of the intended use.

thresholdssafety-sweeps

Checksum and format validation

Deterministic validators cover formats including NIR, Steuer-ID, Codice Fiscale, DNI/NIE, BSN, CPF/CNPJ, RRN, and Luhn-based identifiers.

locale-awaredeterministic

Span-safe merging

Reassemble fragmented subword predictions before redaction and test that transformed text preserves expected offsets and boundaries.

BIO-tagsspan-integrity

Configurable transformation methods

Mask, remove, replace, hash, or shift dates with deterministic options and locale-aware surrogate generation.

maskreplaceshift_dates

Operator-controlled data path

The SDK adds no telemetry by default. Use local assets or a private mirror when deployments must avoid runtime network access; adapters and initial downloads may still use a network.

offlineno-telemetry

OpenMed provides technical controls, not legal compliance. Deployment owners remain responsible for policy, security, clinical validation, contracts, and regulatory review.

The model library

Pick the entity type, then validate the model.

Curated biomedical and clinical encoders cover diseases, chemicals, genomics, oncology, and privacy tasks across model sizes suited to different hardware.

Browse the catalog

Showing all six model examples.

ChemicalDetect

featured

ElectraMed · committed manifest family

chemical-entity-recognition · drug-discovery

Browse chemical models

DiseaseDetect

featured

BioMed · committed manifest family

disease-entity-recognition · pathology

Browse disease models

OncologyDetect

MultiMed · committed manifest family

cancer-genetics · gene-regulation

Browse oncology models

PharmaDetect

BigMed · committed manifest family

drug-recognition · pharmacovigilance

Browse pharma models

DNADetect

SuperClinical · committed manifest family

protein-recognition · molecular-biology

Browse molecular models

Examples come from the committed 29 July 2026 catalog snapshot. Check the current model card, license, intended use, and files before integrating any artifact.

Built with OpenMed

Open at the core. Separate products on top.

The library stands alone. Welna and OpenMed Agent use parts of the OpenMed stack but maintain their own product, licensing, release, and validation boundaries.

wel·na iPhone

Private patient intelligence on device

Welna can process permitted Apple Health data and de-identify text locally before presenting plain-language summaries and questions to discuss with a clinician.

vitality · local signals · longitudinal view synthetic identifiers redacted locally prepare questions for your next visit
View Welna on the App Store
openagent preview

Inspectable automation for clinical workflows

OpenMed Agent presents plans and auditable artifacts for workflows such as prior authorization, appeals, coding, and FHIR operations before an authorized person takes action.

Review request against configured criteria Read synthetic fixture · local Awaiting human review before action
Open agent.openmed.life

These products do not replace clinical judgment and must not automatically trigger diagnosis, treatment, eligibility, or other clinical decisions.

Paper · arXiv:2508.01630

Research you can inspect, then test on your own data.

Read the reference paper at its source, inspect the linked model evidence, and use the repository's evaluation tooling on representative notes. Do not inherit a benchmark result across datasets, hardware, or deployment settings.

Restricted datasets are not bundled. Obtain any required license, DUA, or institutional approval directly from the dataset owner before evaluation.

PaperRead methodology and reported results at the source
ModelsInspect model cards, licenses, and current files
HarnessEvaluate on representative local fixtures
BoundaryTreat every benchmark as scoped evidence

Questions from clinical, ML, and security teams

State the boundary before making the claim.

Open an issue when a deployment, language, or validation question is missing. Public answers can then be tested and kept current with the code.

The OpenMed SDK is Apache-2.0-licensed software for clinical extraction and de-identification workflows; model and dataset terms vary by source. Supported deployment surfaces depend on the selected artifact, adapter, and environment.

The committed catalog includes task-specific model artifacts for extraction and classification. Review each model card, architecture, license, intended use, and evaluation evidence before deployment.

Core inference can run on controlled hardware after required model artifacts are present. Downloads, remote-provider adapters, telemetry-enabled paths, and user-configured integrations may use a network; the surrounding deployment determines the complete data path.

OpenMed can support a deployment's de-identification controls, but the SDK does not make a deployment HIPAA or GDPR compliant and does not replace expert review. The deploying organization remains responsible for legal review, policy, security, validation, and operations.

OpenMed exposes 34 supported PII language routes. 33 are model-backed and the Russian route uses a named placeholder model. Optional user-configured adapters and validator-only national-ID locales are documented separately.

No. The OpenMed SDK source is Apache-2.0-licensed. Welna and OpenMed Agent are separate products with their own terms, release status, and validation boundaries.

OpenMed is a software library and research toolkit, not a diagnosis or treatment recommendation. It must not automatically trigger clinical decisions. Teams must validate models and workflows for their intended use and regulatory context.

OpenMed SDK, open invitation

Build the next release in public.

Report a redaction bypass, request a language, improve a validator, or send a focused pull request. Public evidence makes the toolkit safer and easier to audit.

Contribute on GitHub Request a language python · mlx · swift · kotlin · react-native · browser