Skip to content

OpenMed v2.2.0

OpenMed 2.2.0 completes the trustworthy clinical-data-exchange milestone across terminology grounding, document intake, FHIR, OMOP, structured privacy, MCP, service security, Android local inference, and offline release evidence without removing a public Python symbol.

Release date: 2026-08-13.

Highlights

  • Terminology and clinical grounding: checksum-pinned vocabulary snapshots, exact and ranked grounding, calibration, section context, caller-supplied Athena and crosswalk support, value-free provenance, and explicit terminology-conflict decisions.
  • FHIR and OMOP exchange: FHIR R4 patient summaries and clinical documents, explicit R4/R5 conversion boundaries, local profile validation, Bundle reference-integrity reports, SDC privacy projection, OperationOutcome helpers, Bulk Data resume checkpoints, and FHIR-to-OMOP CDM 5.4 mapping.
  • Multimodal intake: deterministic clinical forms and key/value extraction, cross-format offset projection, PDF table reconstruction, XLSX/PPTX/ODT intake, HL7 v2 narrative handling, X12 837 redaction, and fail-closed MIME quarantine.
  • Structured privacy: k-anonymity, l-diversity, t-closeness, membership-inference self-tests, aggregate-only differential privacy, and qualified-review evidence for dataset release decisions.
  • Service and integration boundaries: grounding and streaming de-identification routes, GraphQL, backpressure and batching, CPU INT8 classification, model-cache quotas, and opt-in database, orchestration, and stream-processing adapters.
  • Security and consent: mTLS, HMAC replay protection, prompt-injection guards, MCP protected-resource and authorization boundaries, consent receipts, upstream endpoint policy, and aggregate Part 11-oriented evidence.
  • On-device safety: Android network-denial guards, no INTERNET permission, opt-in typed aggregate logging, hashed entity descriptions, and explicit assistive-use documentation.
  • Release conformance: hard-negative and multilingual traps, FHIR round-trip fixtures, timeline provenance, and a versioned synthetic v2.2 matrix with pinned FHIR, OMOP, and evidence hashes.

Compatibility

The static public Python comparison grows from 31,619 to 37,307 symbols: 5,688 additions, zero removals or narrowed signatures, and zero new deprecations. The REST surface grows additively from 17 to 19 paths and from 15 to 17 component schemas with POST /ground and POST /pii/deidentify/stream.

The v2.1 root import openmed.clinical.grounding.SnapshotManifest keeps its snapshot-cache meaning. The new vocabulary type is available as VocabularySnapshotManifest. The public OMOP ConceptResolver type alias is also retained.

Swift package source is unchanged in this release range. Android public method signatures are unchanged, but EntityPrediction.description now contains a SHA-256 digest instead of raw detected text. Applications that need a local UI preview must use the explicit text field and keep it out of logs, telemetry, crash reports, and remote diagnostics.

See the 2.1-to-2.2 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.2.0"
pip install --upgrade "openmed[hf,fhir]==2.2.0"

Browser and Node.js

npm install openmed@2.2.0

The web package remains unscoped and provides ESM and CommonJS exports.

Swift

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

Android

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

JitPack resolves the immutable v2.2.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.2.0. The Helm chart's app version and default image tag are synchronized to 2.2.0; explicit release-image selection uses image.tag=v2.2.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 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.

Standards conformance

The OpenMed v2.2 tested standards matrix is generated from synthetic fixtures and records the exact FHIR, OMOP, and evidence hashes used by the conformance gate. It is implementation evidence, not certification by HL7, OHDSI, a regulator, or a standards body.

Licensed vocabularies, real-patient records, DUA-gated corpora, UMLS, SNOMED CT, CPT, MIMIC, i2b2, and n2c2 assets are not bundled. Restricted integrations require caller-supplied rights, keys, snapshots, or out-of-process bridges.

Validation and publication

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 catalog checks;
  • Helm default and synthetic-value lint/render checks;
  • applicable amd64 and arm64 container build and smoke jobs;
  • API compatibility evidence against the published v2.1.0 tree; and
  • committed catalog and registry integrity with latest equal to retained last_green evidence.

OpenMed 2.2.0 does not promote a model pointer. PII/latest and PII/last_green remain OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx, and PII/canary remains unset. Model promotion remains a separate fail-closed workflow requiring a real candidate and benchmark evidence. Missing candidate files block that workflow but do not create a fictitious candidate for this SDK release.

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.1.0...v2.2.0