Download Latest Version OpenMed v2.1.0 source code.zip (39.3 MB)
Email in envelope

Get an email when there's a new version of OpenMed

Home / v2.0.0
Name Modified Size InfoDownloads / Week
Parent folder
sbom.cdx.json 2026-07-28 9.0 kB
0
openmed-2.0.0-py3-none-any.whl.sigstore.json 2026-07-28 10.9 kB
0
openmed-2.0.0.tar.gz.sigstore.json 2026-07-28 11.0 kB
0
python-distributions.intoto.json 2026-07-28 11.0 kB
0
release-artifact-digests.txt 2026-07-28 184 Bytes
0
release-source.json 2026-07-28 195 Bytes
0
image-sbom.cdx.json 2026-07-28 1.4 MB
0
image-sbom.cdx.json.sha256 2026-07-28 86 Bytes
0
openmed-image-sbom_7d19f01994f6f807172c42f4120c65ef8648889a.cyclonedx.json 2026-07-28 1.4 MB
0
OpenMed v2.0.0 source code.tar.gz 2026-07-28 26.9 MB
0
OpenMed v2.0.0 source code.zip 2026-07-28 28.1 MB
0
README.md 2026-07-28 45.8 kB
0
Totals: 12 Items   57.8 MB 0

OpenMed 2.0: Local-First Health Intelligence for Agents, Skills & Privacy

OpenMed v2.0.0 is here, expanding the local-first healthcare privacy and clinical AI platform across Python, Swift, Kotlin/Android, JavaScript, MCP, REST, and container deployments.

This major release adds 34 built-in PII language codes, deterministic identifier and safety-sweep paths, native-script surrogates, offset-preserving CJK and Indic processing, structured-data privacy-risk analysis, exact reference-population assessment, signed expert-review evidence, richer clinical extraction, new interoperability adapters, and broader on-device support.

OpenMed 2.0 also introduces radiology extraction, serial measurement trends, longitudinal document linking, clinical coreference and temporal normalization, multilingual relations, flowsheets, lab panels, discharge structures, typed MCP tools, watchOS and visionOS targets, Android span metadata, WebGPU and GGUF guidance, and reproducible release-evidence workflows.

The documented v1 Python entry points remain available, the REST surface retains the same 15 paths and 12 component schemas, and the static public Python inventory grows from 14,488 to 20,538 symbols with 6,050 additions and no removed, narrowed, or newly deprecated public symbols.

Install or upgrade:

:::bash
pip install --upgrade "openmed==2.0.0"
npm install openmed@2.0.0

Swift Package Manager:

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

Android through JitPack:

:::kotlin
implementation("com.github.maziyarpanahi:openmed:v2.0.0")

Container:

:::bash
docker pull ghcr.io/maziyarpanahi/openmed:v2.0.0

Release notes: https://openmed.life/docs/release/v2.0.0/

Migration guide: https://openmed.life/docs/migration/1.9-to-2.0/

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

Release scope

The audited v1.9.1..v2.0.0 candidate contains 540 reachable commits, including 142 merge commits and 299 first-parent commits, with 1,025 files changed. The release inventory maps 197 merged pull requests and every direct, integration, and release-preparation commit to the exact Git ancestry recorded in CHANGELOG.md.

The release contains 255,162 insertions and 12,770 deletions across the Python package, tests, documentation, examples, website, Swift, Android, JavaScript, service, MCP, deployment, evaluation, security, and release-engineering surfaces.

Highlights

  • Multilingual privacy: OpenMed now routes 34 built-in PII language codes and adds deterministic identifier, date, phone, address, safety-sweep, and surrogate capabilities across Chinese, Indic, African, Nordic, Central and Eastern European, Russian, Urdu, Vietnamese, and regional Arabic workflows.
  • Offset and script integrity: Full-width and half-width text, native digits, Simplified and Traditional Chinese, Chinese numerals, Indic graphemes, legacy encodings, cross-script transliteration, Hinglish, and mixed-script confusables are handled with source-aligned offsets.
  • Regional privacy policy: China PIPL, India DPDP and ABDM, South Africa POPIA, Nigeria NDPA, Kenya DPA, Egypt PDPL, Morocco Law 09-08, the Malabo Convention, GDPR, the EU AI Act, ISO 27701/27001, consent tags, and data-residency evidence gain explicit local workflows.
  • Structured-data privacy risk: New offline workflows cover quasi-identifier discovery, reviewer overrides, patient-level k-anonymity, distinct and entropy l-diversity, variational t-closeness, bounded generalization and suppression search, materialized-output revalidation, and rollback-safe publication.
  • Reference-population assessment: Callers can evaluate k-map, exact-linkage risk, and delta-presence against an explicit row-level or longitudinal reference population while keeping aggregate reports free of raw profiles and privacy-unit values.
  • Expert-review evidence: Structured-risk dashboards, the strict openmed risk gate command, deterministic review records, and expert-authored Ed25519 attestations bind conclusions to data, schema, policy, integrity, and freshness evidence without claiming automated Expert Determination.
  • Clinical extraction: Radiology sections and findings, BI-RADS and Lung-RADS capture, serial measurement trends, longitudinal document linking, coreference, temporal normalization, abbreviation disambiguation, multilingual relations, flowsheets, lab panels, discharge summaries, procedures, pulmonology, and pediatrics expand the local clinical toolkit.
  • Interoperability: OpenMRS, DHIS2, OpenHIM, ODK Central, CommCare, KoBoToolbox, WHO SMART profiles, PySpark, Prefect, scrubadub, LlamaIndex, scispaCy, QuickUMLS, and offline ICD-11 integration points support deployment inside existing health-data environments.
  • Agent Skills for healthcare workflows: OpenMed 2.0 ships 72 portable Agent Skills across 14 categories for Claude Code, OpenAI Codex, OpenCode, and compatible agents. They cover local de-identification, clinical NER, FHIR and OMOP handoffs, evaluation, compliance, document intake, analytics, and deployment, with a safe one-command installer that preserves existing user-owned entries.
  • MCP and agent tooling: A typed MCP registry, structured tool outputs, the openmed-mcp entry point, an MCP-enabled container, and llms.txt documentation feeds make OpenMed easier to use from local agents without moving PHI into a hosted control plane.
  • On-device SDKs: OpenMedKit adds watchOS and visionOS targets, grapheme-safe Swift span parity, compact on-device segmenters, Android OpenMedSpan and EntityPrediction metadata, and guidance for WebGPU, WebAssembly, GGUF, and constrained ARM devices.
  • Release engineering: Multilingual golden fixtures, adversarial-PHI checks, parser fuzzing, throughput and latency budgets, model-integrity verification, API compatibility output, vulnerability policy, SBOM and provenance workflows, and signed evidence contracts strengthen the release path.

Agent Skills: from a prompt to a local pipeline

OpenMed 2.0 includes a 72-skill catalog that works unchanged in Claude Code, OpenAI Codex, OpenCode, and compatible agents. The multi-agent onboarding delivered in #1866 installs every skill in one command and safely preserves existing files, directories, and unrelated symlinks.

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

Or install for one client:

:::bash
./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 deidentifying-clinical-text and extracting-clinical-entities into runnable OpenMed code:

:::python
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.

Multilingual privacy and de-identification

The language-pack catalog is now the shared source of truth for runtime routing, model-backed languages, deterministic identifier-only packs, locale capabilities, service metadata, CLI reporting, fixtures, and documentation.

Chinese processing adds word-aware Pinyin romanization, Simplified and Traditional conversion through OpenCC, source-aligned numeral parsing, mixed-variant detection, address handling, name surrogates, and tone-insensitive consistency keys. Indic processing adds native-digit folding, grapheme-safe offsets, ISO 15919 transliteration, ITRANS and Harvard-Kyoto parsing, and cross-script name linkage.

African coverage adds Hausa, Yoruba, Igbo, Swahili-oriented documentation and safety sweeps, regional locale providers, Nigerian and Nigerien identifiers, context-aware clinical patterns, and data-residency evidence. Arabic coverage gains explicit Gulf, Levant, Egyptian, Algerian, and Moroccan locale routes with conservative fallbacks.

Russian and Vietnamese receive full local PII packs, while Czech, Hungarian, and additional regional routes add validator-backed national identifiers. Pattern-only packs remain explicit about their capabilities and do not silently claim a default neural model.

Surrogate generation preserves locale and script behavior where supported, validates checksum-bearing identifiers, and maintains deterministic identity consistency without writing raw identifiers into release evidence.

Structured privacy and quasi-identifier risk

The new structured release workflow separates advisory quasi-identifier discovery from reviewed policy. Every source column requires an explicit disposition, and every materialized output is revalidated before publication.

Patient-level privacy units can span multiple rows. The risk engine supports k-anonymity, distinct and entropy l-diversity, variational t-closeness, bounded hierarchy search, whole-unit suppression, utility constraints, and conservative failure behavior.

Reference-population analysis requires an explicit caller-supplied population and explicit thresholds. It does not infer that an available table represents the attack population, and it records separate data, schema, policy, and integrity digests.

Aggregate dashboards and audit artifacts report counts, hashes, provenance, thresholds, and risk scores rather than raw quasi-identifier values. Expert attestations verify authorship and evidence binding but do not replace qualified legal, statistical, or privacy review.

Clinical extraction and interoperability

Radiology workflows can segment sections, extract findings, bind laterality, measurements, and anatomy with provenance spans, and capture only explicitly stated BI-RADS or Lung-RADS categories.

Longitudinal tooling adds deterministic near-duplicate clustering, amendment relationships, retained superseded documents, source provenance, serial measurement normalization, timeline ordering, and conservative handling for incompatible units.

Clinical relation extraction expands to Chinese and Hindi with source character offsets, assertion propagation, constrained graph decoding, and language-specific evaluation. Additional domains cover procedures, devices, pulmonology, pediatrics, immunization, flowsheets, laboratory panels, and discharge summaries.

Interoperability adapters remain optional and local. Large frameworks, licensed terminologies, gated datasets, UMLS, SNOMED CT, CPT, MIMIC, i2b2, and n2c2 assets are not bundled.

Python, service, MCP, and CLI

The documented root imports remain stable:

:::python
from openmed import OpenMedConfig, analyze_text, deidentify, extract_pii

CLI commands now expose consistent --json success and error envelopes for automation while keeping human-readable output as the default.

The typed MCP registry provides annotations and structured outputs through openmed-mcp. Existing MCP clients should refresh cached schemas, and applications pinned to an older MCP runtime should retest against the new optional mcp>=1.27,<2 route.

The REST/OpenAPI contract retains the same 15 paths and 12 component schemas as v1.9.1. Regenerating clients is optional when only the release metadata is needed.

Swift, Android, browser, Node.js, and deployment

Swift OpenMedKit continues to use the repository-root package and adds watchOS and visionOS alongside iOS, iPadOS, and macOS. Span handling remains source-aligned and gains grapheme-safe parity across supported Apple platforms.

Android OpenMedKit adds OpenMedSpan, richer EntityPrediction metadata, immutable JitPack installation, and offline ONNX guidance while retaining the existing package coordinate.

The public npm package remains the unscoped openmed package and provides ESM and CommonJS exports for browsers and Node.js.

The service container, MCP container path, Compose configuration, Helm chart, multi-architecture image workflow, image SBOM, and provenance paths are synchronized on v2.0.0.

Security and hardening

  • Telemetry remains off by default, runtime PHI processing remains local after explicit artifact download, and no raw PHI belongs in logs, caches, temporary files, or audit evidence.
  • Model downloads and manifests gain stronger integrity, signature, digest, cache, and provenance checks.
  • Mixed-script, confusable-text, direct-identifier, leakage, span-integrity, and adversarial-PHI defenses gain dedicated deterministic tests and evidence structures.
  • ONNX-producing optional routes now require ONNX 1.21+ and spaCy 3.8.9+, with incompatible scispaCy and ONNX environments intentionally separated.
  • Release images exclude generated SBOM, audit, vulnerability, and JavaScript dependency artifacts from their Docker build contexts.
  • Dependency, license, workflow-reference, secret-scan, vulnerability, artifact-content, and reproducible-lock policies remain explicit release gates.
  • Indic segmenter resources pin their ICU 57.1 source revision, use the SPDX ICU identifier, and carry the complete ICU notice in Python distributions and every standalone converted-model bundle.

Compatibility and migration

The static public Python comparison against v1.9.1 records 6,050 additions, no removals, no narrowed callable signatures, and no newly deprecated symbols.

The new DEVICE canonical label is additive. Applications that treat canonical labels as an exhaustive enum or switch must add DEVICE; applications that accept arbitrary canonical-label strings require no change.

Pattern-only language packs no longer imply a neural default. Pass an explicit model identifier when combining deterministic language capabilities with model-backed inference, and validate that model against local fixtures before deployment.

The optional ONNX and multimodal routes require ONNX 1.21+ and are isolated from the scispaCy NumPy 1.x route. Applications needing both should use separate environments.

Structured-data release workflows now require explicit column dispositions and reviewed quasi-identifier policy. Existing text-only deidentify, extract_pii, and analyze_text calls are unaffected.

MCP clients should refresh cached schemas, closed label enums must recognize DEVICE, and custom CLI automation should select --json rather than scrape human-readable output.

See the complete migration guide at https://openmed.life/docs/migration/1.9-to-2.0/.

Validation completed during final release preparation

  • Complete ancestry inventory: 540 commits represented, including 197 merged pull requests plus all direct, integration, and release-preparation commits.
  • Python: 8,685 tests passed and 58 were skipped; the structured QI-risk scope passed 658 tests.
  • Static API compatibility: 14,488 to 20,538 public symbols, 6,050 additions, zero breaking removals or narrowed signatures, and zero new deprecations.
  • REST/OpenAPI: 15 paths and 12 component schemas retained; generated OpenAPI output matched the candidate checkout.
  • Release suite: 71 release, provenance, policy, changelog, and workflow regression tests passed on the final local release branch.
  • Documentation and examples: strict MkDocs builds, localized documentation trees, LLM documentation feeds, website checks, and structured-risk examples passed.
  • Python artifacts: wheel and source distribution built successfully, passed twine check, passed content inspection, and installed and imported successfully in clean isolated environments.
  • Swift: formatting, lint, resolve, build, and 70 tests passed with 14 expected local MLX-resource skips.
  • Android: AAR assembly and unit tests passed.
  • JavaScript: the browser and Node.js package passed 9 tests, audit with zero vulnerabilities, and dry-run packaging; the React Native package passed 4 tests, audit, and dry-run packaging.
  • Helm: default and CI values passed lint and template validation.
  • Security: dependency and container scanning evaluated 174 findings under repository policy with 23 accepted unfixable base-image findings and zero blocking findings.
  • Container: the production image built successfully after the Docker context was reduced from 139 MB to 307 KB by excluding generated evidence and JavaScript dependencies.
  • Version preflight: all 19 active release surfaces matched 2.0.0, and the v2.0.0 tag was unused locally and on origin at the time of preparation.

Registry availability, live documentation, immutable consumer coordinates, and published release assets are verified after the tag-driven release workflows complete.

Privacy and clinical boundaries

OpenMed keeps local processing as the default, but no de-identification system can guarantee zero residual risk. Validate direct-identifier recall, critical leakage, span integrity, language and script coverage, policy behavior, quantized-model deltas, and device behavior against deployment-specific fixtures before production use.

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.

Build hashes and package checksums establish artifact identity; they do not prove model quality. Model-specific evidence should be evaluated independently for each selected model, language, quantization, and runtime.

Contributor and change inventory

Thank you to every contributor whose work is included in this release. The complete pull-request and commit inventory, including every merged branch commit and every direct release-preparation commit, is recorded in CHANGELOG.md.

What's Changed

New Contributors

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

Source: README.md, updated 2026-07-28