Skip to content

OpenMed v2.0.0

OpenMed 2.0.0 establishes the v2 local-first healthcare privacy and clinical AI platform across Python, Swift, Kotlin/Android, JavaScript, MCP, and container deployments.

Release date: 2026-07-28.

Reviewed range: v1.9.1..v2.0.0. The exact candidate head is re-audited immediately before tagging. The complete ancestry-derived pull-request and commit ledger is recorded in CHANGELOG.md.

Highlights

  • Multilingual privacy: 34 built-in PII language codes plus deterministic identifier-only packs, locale-aware validators, native-script surrogates, CJK/Indic offset preservation, and code-mixed routing.
  • Regional policy and evidence: China PIPL, India DPDP and ABDM, African privacy profiles, GDPR and EU AI Act templates, consent enforcement, data-residency attestations, and ISO control evidence.
  • Clinical and structured data: radiology parsers, serial trends, longitudinal document linking, coreference, temporal normalization, multilingual relations, flowsheets, lab panels, discharge summaries, automated quasi-identifier discovery, patient-level k/l/t assessment, exact reference-population risk, expert-review evidence, and additive clinical domains.
  • Interoperability: OpenMRS, DHIS2, OpenHIM, community health forms, WHO SMART profiles, PySpark, Prefect, scrubadub, LlamaIndex, scispaCy, QuickUMLS, and offline ICD-11 integration points.
  • Agent Skills for healthcare workflows: 72 portable Agent Skills across 14 categories teach Claude Code, OpenAI Codex, OpenCode, and compatible agents to assemble local de-identification, clinical NER, FHIR export, evaluation, compliance, and deployment workflows. A safe one-command installer preserves existing user-owned entries.
  • On-device and MCP tooling: watchOS and visionOS OpenMedKit targets, grapheme-safe Swift spans, Android span models, typed MCP tools, an MCP container, WebGPU and GGUF guidance, and LLM-ready docs.
  • Release safety: multilingual golden fixtures, throughput and latency budgets, parser fuzzing, adversarial-PHI tests, signed evidence, API compatibility output, and a fail-closed release-readiness decision.
  • Third-party attribution: Indic segmenter resources pin their ICU 57.1 source revision, use the valid SPDX ICU identifier, and carry the complete ICU notice inside Python distributions and every standalone converted-model bundle.

Agent Skills: from a prompt to a local pipeline

OpenMed 2.0 ships a catalog of 72 portable Agent Skills for building healthcare workflows with Claude Code, OpenAI Codex, OpenCode, and compatible agents. The catalog covers de-identification, clinical entity extraction, FHIR and OMOP handoffs, evaluation, compliance, document intake, analytics, and deployment. The multi-agent onboarding from #1866 installs every skill in one command and safely preserves existing files, directories, and unrelated symlinks.

git clone https://github.com/maziyarpanahi/openmed
cd openmed
./install-skills.sh

Or target one client:

./install-skills.sh claude     # ~/.claude/skills/
./install-skills.sh codex      # ~/.codex/skills/
./install-skills.sh opencode   # ~/.config/opencode/skills/
./install-skills.sh agents     # ~/.agents/skills/

Then ask the agent for a concrete local workflow using synthetic input:

Build a local OpenMed pipeline that de-identifies a synthetic discharge note and extracts medication entities. Keep the example synthetic.

The agent can combine the deidentifying-clinical-text and extracting-clinical-entities skills into runnable OpenMed code:

import openmed

note = (
    "Synthetic patient Jane Example (MRN 12345), seen 2024-03-02, "
    "started on metformin 500mg BID."
)
deid = openmed.deidentify(
    note,
    method="mask",
    policy="hipaa_safe_harbor",
)
meds = openmed.analyze_text(
    deid.deidentified_text,
    model_name="pharma_detection_superclinical",
)

After the one-time model download, inference runs locally. Keep real PHI out of cloud-hosted agent prompts, logs, and copied examples.

Compatibility

The static public Python comparison against v1.9.1 grows from 14,488 to 20,538 symbols: 6,050 additions, zero removals or narrowed signatures, and zero new deprecations. The REST surface retains the same path and component-schema set.

The new DEVICE canonical label is additive, but applications that model labels as a closed enum must add it. Optional dependency and tool-schema changes are covered in the 1.9-to-2.0 migration guide.

Documented v1 root imports remain available:

from openmed import OpenMedConfig, analyze_text, deidentify, extract_pii

Install and upgrade

Python

pip install --upgrade "openmed==2.0.0"

Install only the extras needed by the application, for example:

pip install --upgrade "openmed[hf,zh,indic]==2.0.0"
pip install --upgrade "openmed[service,mcp]==2.0.0"

Browser and Node.js

npm install openmed@2.0.0

The package remains unscoped and provides ESM and CommonJS exports.

Swift

dependencies: [
    .package(url: "https://github.com/maziyarpanahi/openmed.git", from: "2.0.0"),
]

OpenMedKit supports iOS, iPadOS, macOS, watchOS, and visionOS through the repository-root package.

Android

Add JitPack and use the immutable tag:

dependencies {
    implementation("com.github.maziyarpanahi:openmed:v2.0.0")
}

Container and Helm

Use ghcr.io/maziyarpanahi/openmed:v2.0.0. The Helm chart defaults to 2.0.0; when selecting the release image explicitly, set image.tag=v2.0.0.

Privacy and clinical boundaries

OpenMed keeps local processing as the default. Model downloads are explicit; after the required artifacts are present, runtime PHI processing does not require a cloud service. Telemetry remains off by default, and release evidence uses hashes, counts, offsets, and provenance rather than raw identifiers.

No de-identification system can guarantee zero residual risk. Validate direct identifier recall, leakage, span integrity, language coverage, policy behavior, and quantized-model deltas locally before deployment.

Clinical extraction is assistive software, not a medical device or a source of clinical ground truth. Outputs require qualified review and must not automatically trigger diagnosis, treatment, billing, or other clinical decisions.

Release qualification

Before the v2.0.0 tag is created, the exact candidate head must pass:

  • repository and dependency-license policy;
  • locked dependency, lint, formatting, and complete Python tests;
  • strict documentation and generated OpenAPI checks;
  • Python wheel/sdist build, metadata, content, Twine, SBOM, and provenance tests;
  • npm install, audit, build, typecheck, tests, and tarball inspection;
  • Swift resolve/build/tests plus hosted Apple platform compilation;
  • Android AAR build/tests and immutable JitPack coordinate checks;
  • Helm default and synthetic-value lint/render checks;
  • applicable multi-architecture container, signing, and SBOM workflows;
  • a real signed extraction/model gate report, API compatibility report, named golden-suite result, and final READY readiness decision.

A skipped or missing candidate report is incomplete evidence. Registry availability, live documentation, and consumer installation are verified only after publication and are not claimed by candidate preparation.

Full Changelog: https://github.com/maziyarpanahi/openmed/compare/v1.9.1...v2.0.0