Skip to content

OpenMed v2.1.0

Latest
Latest

Choose a tag to compare

View all tags
@maziyarpanahi maziyarpanahi released this 12 Aug 14:00
· 206 commits to master since this release
v2.1.0
6e0240f
This commit was signed with the committer’s verified signature.
maziyarpanahi Maziyar Panahi
GPG key ID: 58C6DE3FED1C5846
Verified
Learn about vigilant mode.

OpenMed v2.1.0 is here, delivering the first feature release on the stable v2 line for local-first healthcare privacy and clinical AI.

This release expands clinical section and note-type routing, temporal and coreference graphs, calibrated relations, radiology and discharge-summary structures, dosing checks, span-grounded fact recall, offline terminology grounding, OMOP loading, FHIR and OpenEHR export, cohort phenotype resolution, structured privacy, multimodal intake, and typed MCP workflows.

OpenMed 2.1 also strengthens the deployment surface: Android now follows the documented Unicode-scalar offset contract and ships a fail-closed 753-entry on-device catalog derived from the committed 2,266-entry public manifest; the browser and Node.js package remains available as openmed; and the Python, Swift, Helm, service, and container version surfaces are synchronized on 2.1.0.

The public Python inventory grows from 20,538 to 31,619 symbols with 11,081 additions, no removed or narrowed public symbols, and no new deprecations. The REST contract grows additively from 15 paths and 12 component schemas to 17 paths and 15 schemas.

Install or upgrade:

pip install --upgrade "openmed==2.1.0"
npm install openmed@2.1.0

Swift Package Manager:

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

Android through JitPack:

implementation("com.github.maziyarpanahi:openmed:v2.1.0")

Container:

docker pull ghcr.io/maziyarpanahi/openmed:v2.1.0

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

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

Full changelog: v2.0.0...v2.1.0

Release scope

The current published v2.0.0 tag resolves to rewritten-history commit 94ace7d and is an ancestor of current master through merge boundary b9ab7a3d. Public API compatibility compares the tagged trees directly, while the release integration ledger follows changes after that boundary.

The integration ledger in CHANGELOG.md records 213 PR-associated integrations and seven direct integrations, plus the final release-hardening change set. It covers the Python package, tests, documentation, examples, website, Android, JavaScript, service, MCP, deployment, model manifest, evaluation, security, and release-engineering surfaces.

Highlights

  • Clinical extraction: Note-type and section routing, temporal and coreference graphs, calibrated medication and problem relations, radiology and discharge structures, dosing sanity checks, clinical fact recall, and span-grounded faithfulness.
  • Grounding and interoperability: Caller-supplied offline terminology snapshots, hybrid grounding, OMOP loading, FHIR and OpenEHR export, local cohort phenotype resolution, and typed clinical MCP workflows.
  • Structured privacy: Declarative generalization, relational k-anonymity, streaming tabular anonymization, aggregate-only differential privacy, attacker-model reports, and review-first column semantics.
  • Multilingual and multimodal intake: Unicode and grapheme-safe routing, Vietnamese model-backed coverage, Urdu and Indic routing, Belgian and Swiss national-ID validation, RTF and DICOM-SR extraction, OCR layout reconstruction, and opt-in YASBD sentence segmentation.
  • On-device and distributed adapters: Android Unicode-scalar parity, grapheme repair, packaged R8 consumer rules, a 753-entry public on-device catalog, Flutter FFI support, and optional Beam, Ray Data, PySpark, Haystack, and LangGraph paths.
  • Evaluation and release safety: DirectID evidence, deterministic safety sweeps, signed scorecards, cross-corpus and cross-lingual evaluation, staged promotion, last-green rollback, public-API checks, and fail-closed release readiness.

Clinical extraction and terminology grounding

OpenMed 2.1 expands deterministic clinical document processing across section and document-type routing, coreference, temporal ordering, medication and problem relations, radiology findings, discharge structures, dosing checks, and span-grounded fact recall.

Terminology workflows accept explicit local snapshots and preserve version, code-system, match, abstention, and provenance evidence. OncoTree and other restricted or externally governed terminology inputs remain caller-supplied; the SDK does not silently download or bundle them.

Clinical MCP tools expose typed grounding, FHIR export, risk, signed-audit, model-search, and staged pipeline operations. Existing MCP clients should refresh cached schemas before enabling the new tools.

Interoperability and structured privacy

New local workflows cover OMOP loading, cohort phenotype resolution, FHIR and OpenEHR export, streaming tabular processing, declarative generalization, relational k-anonymity, aggregate-only differential privacy, and attacker-model risk reporting.

Apache Beam, Ray Data, PySpark, Haystack, LangGraph, and sdcMicro integration paths remain optional. The interop-gpl extra installs no GPL code; R and sdcMicro remain separate, out-of-process, user-managed software.

DUA-gated corpora and licensed terminologies are never bundled. Loaders require caller-supplied paths, credentials, or snapshots and preserve explicit local provenance rather than treating data availability as permission to redistribute.

Multilingual and multimodal processing

Vietnamese is now a model-backed PII language route, while Urdu and additional Indic codes gain explicit routing and user-supplied-model behavior. Script segmentation is grapheme-aligned and keeps combining sequences, virama conjuncts, zero-width-joiner sequences, and regional-indicator pairs intact.

RTF extraction is stdlib-only and maps extracted characters back to source offsets. DICOM-SR, OCR layout, and other multimodal paths continue to require deployment-specific validation and optional dependencies where documented.

The release advertises 35 built-in PII routes: 33 are model-backed and the Russian and Tamil routes are explicit placeholders. Production Russian or Tamil extraction requires caller-qualified weights and deployment evidence.

Python, REST, CLI, and MCP

The documented Python imports remain available, including:

from openmed import OpenMedConfig, analyze_text, deidentify, extract_pii

New CLI groups cover model-cache management, batch-run resume and reporting, OMOP loading, cohort resolution, OpenEHR export, registry lineage, and release rollback. Existing commands remain available.

REST adds POST /cohort/resolve and POST /omop/load without replacing an existing route. Applications that generate clients from OpenAPI can regenerate to expose the new operations; applications using only existing routes do not need a compatibility shim.

Android, Swift, browser, and deployment

Android OpenMedKit now returns half-open Unicode-scalar offsets consistently from entity predictions, spans, token decoding, and policy de-identification. Applications that pass offsets to Kotlin UTF-16 string APIs for non-BMP text must convert with EntityPrediction.utf16SpanIn.

The Android AAR derives a 753-entry permissively licensed ONNX/TFLite catalog from the committed 2,266-entry public manifest and fails the build if that derivation is empty. Catalog metadata identifies discoverable artifacts; it is not downloaded model data or model-quality evidence.

Swift package sources are unchanged in this release range. The package version coordinates and demo bundle versions are synchronized to 2.1.0, and the existing Unicode-offset parity tests remain green.

The unscoped npm package openmed continues to ship ESM and CommonJS exports for browser and Node.js use. Helm chart metadata, default image selection, and the generated REST OpenAPI version are synchronized to 2.1.0.

Compatibility and migration

The static public Python comparison against the published v2.0.0 tree records 11,081 additions, no removals or renames, no narrowed callable signatures, and no newly deprecated symbols.

Android Unicode offsets are the only called-out behavioral migration. ASCII and Basic Multilingual Plane-only text retains the same numeric offsets; code that applies offsets to strings containing emoji or other non-BMP characters must convert scalar offsets to Kotlin UTF-16 indices first.

Applications using the Android model catalog should re-evaluate pinned or filtered entries against the refreshed catalog. Applications relying on the former dedicated Tamil default must configure and qualify explicit weights.

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

Security and release hardening

  • Core PHI processing remains local after explicitly required artifacts are available; telemetry remains off by default.
  • Model, terminology, and dataset downloads remain explicit trust and network boundaries with separate license and integrity review.
  • Release evidence records hashes, counts, offsets, thresholds, and provenance rather than raw identifiers or source clinical text.
  • Repository, license, secret, action-reference, dependency-vulnerability, SBOM, provenance, API compatibility, package-content, and deterministic test policies are enforced by dedicated gates.
  • Public model-manifest refreshes disable implicit Hub authentication, preserve reviewed metadata, and fail closed when Android catalog generation is empty.
  • Release readiness treats missing evidence as failure; an absent staged report is never interpreted as a successful no-op.

Local validation completed before merge

  • Python: 11,539 tests passed, 95 were skipped, one expected failure was recorded, and 20 warnings were reported by the complete suite.
  • Release-focused tests: 276 API-compatibility, publication-workflow, provenance, release-gate, and readiness tests passed.
  • End-to-end golden scope: 203 tests passed and three were skipped.
  • Static API compatibility: 20,538 to 31,619 public symbols, 11,081 additions, zero breaking changes, and zero new deprecations; migration completeness passed.
  • REST/OpenAPI: generated output is synchronized on 2.1.0, with 17 paths and 15 component schemas.
  • Documentation: strict multilingual MkDocs builds and the exact Pages staging pipeline passed route, asset, LLM-feed, metadata, and locale validation.
  • Browser and Pages: 386 tests passed across Chromium, Firefox, and WebKit with 46 expected skips; the 300-file staged artifact passed ownership, hash, and byte-budget checks without local model or runtime payloads.
  • Python artifacts: wheel and source distribution built successfully, passed twine check, passed content inspection, and installed with working imports and CLI entry points in a clean Python 3.11 environment.
  • JavaScript: dependency audit found zero vulnerabilities; build, typecheck, nine Node/browser-runtime tests, and dry-run npm packaging passed.
  • Swift: formatting, dependency resolution, package build, a generic iOS Simulator build, 70 package tests with 14 expected local MLX-resource skips, and the focused offset-parity test passed.
  • Android: debug AAR assembly, 87 unit tests, the 753-entry catalog, release version validation, release AAR assembly, and consumer-rule verification passed for 2.1.0.
  • Helm: default and CI values passed lint and template rendering.
  • Security: high-severity Bandit, secret scanning, license policy, GitHub Actions reference policy, pip-audit with zero known vulnerabilities, and a CycloneDX 1.6 SBOM for OpenMed 2.1.0 plus 135 runtime dependencies passed.
  • Version preflight: every active release surface resolves to 2.1.0, and the v2.1.0 tag was unused locally and on origin at validation time.

Required exact-commit and tag-time validation

The final merged release commit must still receive green hosted checks on that exact SHA. In particular, the Linux containerized browser job must compare the approved pixel snapshots, applicable Apple simulator jobs must pass, container build and smoke tests must pass on amd64 and arm64, and the secret-backed signed Android Central Portal bundle must be produced where configured.

Release readiness also requires real staged inputs at artifacts/release-candidate.json, artifacts/release-candidate-shield.json, and artifacts/staged-models.jsonl. Those inputs drive fresh golden and public SHIELD evaluation, signed release gates, evidence binding, and a final readiness decision of exactly READY. They are not fabricated or replaced by the synthetic unit-test results above.

Registry availability, immutable package and image coordinates, live documentation, checksums, attestations, and published release assets are verified only after the tag-driven 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 must be evaluated independently for each selected model, language, quantization, runtime, and deployment.

Contributor and change inventory

Thank you to every contributor whose work is included in this release, with a special welcome to first-time contributors @speedyk-005 and @josephkehan-prog.

The complete pull-request and commit inventory, including direct integrations and final release hardening, is recorded in CHANGELOG.md.

What's Changed

New Contributors

Full Changelog: v2.0.0...v2.1.0

Contributors

nikoolga, maziyarpanahi, and 4 other contributors
Assets 11
Loading