OpenMed v2.3.0¶
OpenMed 2.3.0 expands the stable v2 SDK across privacy-safe agent and trace workflows, multimodal asset intake, clinical evidence, local training, cross-platform runtimes, deployment adapters, and release hardening without removing a public Python symbol.
Release date: 2026-09-04.
Highlights¶
- Multimodal safety and provenance: bounded asset manifests, streaming digests, media-type detection, typed abstention, manifest profiles, PDF fidelity, local email intake, and metadata-safe document extraction.
- Agent and trace contracts: closed outcomes, deterministic run summaries, monotonic timing, consent verification, schema-preserving trace redaction, bounded streaming and sharding, transactional recovery, and fidelity proof.
- Clinical evidence: deterministic evidence tables, patient-record span filtering, substance-use SDOH extraction, and value-free review metadata.
- Local training: teacher-ensemble manifests, federated-round lifecycle records, reproducibility verification, and privacy-safe training schemas.
- Integrations: opt-in search, batch, notebook, orchestration, database, remote-function, Kubernetes, HPA, and self-hosted service adapters.
- On-device and desktop runtimes: iOS extensions, Android accelerator selection, browser PHI guarding, Electron and Tauri bridges, TensorRT, GGUF, WebGPU, MLX, and edge-SBC qualification paths.
- npm redaction correctness: a working default ONNX model, source-offset alignment for Transformers.js, Unicode-safe spans, and content-free failures when offset-less tokens cannot be aligned.
- Release hardening: deterministic CLI and schema contracts, package-size budgets, container digest policy, image security gates, and removal of hosted model publication automation.
Compatibility¶
The audited v2.2.0..v2.3.0 release-branch range contains 252 commits and 651 changed files. Commit subjects reference 127 unique issue or pull-request identifiers across that complete ancestry range.
The static public Python comparison grows from 37,735 to 41,729 symbols: 3,994 additions, zero removals or narrowed signatures, and zero new deprecations. The REST surface remains at 19 paths and 17 component schemas.
Swift, Kotlin/Android, JavaScript, CLI, configuration, trace schemas, evidence records, and deployment contracts expand. npm callers should account for the corrected default model, additive raw-token input types, and explicit alignment failures described in the 2.2-to-2.3 migration guide for the cross-surface review and upgrade checklist.
Install and upgrade¶
The immutable tag drives package and image publication. Registry availability can lag the source release while tag-triggered workflows complete, so automation should verify the required coordinate before deployment.
Python¶
pip install --upgrade "openmed==2.3.0"
pip install --upgrade "openmed[hf,fhir]==2.3.0"
pip install --upgrade "openmed[mlx]==2.3.0"
Browser and Node.js¶
The web package remains unscoped and provides ESM and CommonJS exports. Install @huggingface/transformers to use the default ONNX model, or inject a local token-classification pipeline. See the migration guide for the offset contract.
Swift¶
Android¶
JitPack resolves the immutable v2.3.0 repository tag. OpenMedKit performs local inference and declares no Android INTERNET permission.
Container and Helm¶
After publication, the immutable container coordinate is ghcr.io/maziyarpanahi/openmed:v2.3.0. The Helm chart's app version and default image tag are synchronized to 2.3.0; explicit release-image selection uses image.tag=v2.3.0.
Privacy and clinical boundaries¶
OpenMed keeps local processing as the default. Model downloads and optional remote integrations are explicit boundaries; after required artifacts are present, core PHI processing does not require a cloud service. Telemetry stays off by default, and release evidence uses hashes, counts, offsets, and provenance rather than raw identifiers.
No de-identification or structured privacy system can guarantee zero residual risk. Validate direct-identifier recall, leakage, span integrity, language and format coverage, policy behavior, and quantized-model deltas on the exact deployment path.
Clinical extraction, evidence, filtering, and mapping are 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, data release, or other clinical decisions.
Validation and publication¶
The optional agents, llamaindex, quickumls, and scrubadub dependency trees include NLTK 3.10.3. Its model-artifact path-security advisory CVE-2026-81726 has no published fixed version as of 2026-09-04. OpenMed does not call the affected model-file APIs, and the service image does not install NLTK. Applications using these optional dependencies must not expose NLTK model import/export paths to untrusted input. This is a known upstream limitation, not a claim that NLTK is patched. The repository's waiver is restricted to this CVE, the nltk package, and the uv.lock target, and expires on 2026-09-11. A fixed upstream release cannot be waived by this policy.
The exact release commit is required to pass:
- repository, dependency-license, secret, and action-reference policy;
- locked dependencies, lint, formatting, and the complete Python test suite;
- strict documentation, README translation drift, marketing staging, and regenerated OpenAPI checks;
- wheel/sdist build, metadata, contents, Twine, SBOM, and provenance tests;
- npm install, audit, tests, type checking, build, and tarball inspection;
- Swift resolve/build/tests plus applicable hosted Apple platform jobs;
- Android AAR build/tests, lint, network-denial, consumer-rule, and budget checks;
- Helm default and synthetic-value lint/render checks;
- applicable amd64 and arm64 container build and smoke jobs; and
- API compatibility evidence against the published
v2.2.0tree.
OpenMed 2.3.0 does not promote a model pointer. Model conversion, evaluation, and publication remain explicit local maintainer operations. A future model promotion still requires a real candidate, public SHIELD and golden evidence, signed extraction gates, and a final decision of exactly READY.
Hosted checks must refer to the exact release commit; successful jobs on an earlier source head do not qualify the release. Package publication, container publication, release assets, and registry verification remain tag-driven follow-up actions.
Full Changelog: https://github.com/maziyarpanahi/openmed/compare/v2.2.0...v2.3.0