OpenMed v3.2.0¶

Status: release candidate; publication pending. The target stable version is 3.2.0. The package version is prepared on the release branch without an rc suffix; this page does not claim a published tag or registry artifact.

The baseline is v3.1.0. The release scope is global languages, synthetic data and local decision backends.

Global languages and privacy¶

• Localized medical-record labels, Nepali identifiers and dates, UK postcodes, African month-name dates, native-calendar detection and date shifting.
• Source-script and native-digit surrogates, local address conventions, honorific and name-order preservation, provider-version drift evidence and live surrogate-quality checks.
• Signed offline language bundles, transactional activation, script-tokenizer audits, readiness matrices and openmed i18n check.
• Native-review packets and adjudication, morphology and code-switch label projection, translation guards, dialect abstention and independent per-language regression and graduation gates.

The initial low-resource cohort remains experimental, with unfilled native review roles. Added deterministic patterns, synthetic fixtures or model-loader support do not graduate a language. See the cohort and graduation contract and language readiness.

Synthetic clinical data¶

The synthetic data APIs cover composable note grammars, longitudinal trajectories, medication courses, constrained lab series, prior-authorization packets, FHIR and OMOP records, HL7 v2, C-CDA, code-switched dialogues and patient-intake conversations. Locale generators also include explicitly marked augmentation-only routes and native-calendar and digit variants.

Dataset recipes bind patient and generator lineage, split planning, licenses, cross-artifact truth alignment, memorization and contamination audits, release capsules, subgroup evidence and withdrawal controls. Burned-in rendering now requires appropriate glyph coverage and shaping, with explicit checked font fallback when requested.

Synthetic outputs and their constructed truth labels are augmentation and technical test data. They do not establish clinical accuracy, anonymity or population equivalence. No restricted clinical records or terminology assets are added by this release.

Local models and fixed-option decisions¶

• Native GLiFormer and current GLiNER2/2.5 loading through the Python NER APIs, with optional extras, offline checkpoint loading and exact span handling. OpenMed/GLiNER2.5-BioNER-Disease-Base-v1 has an English disease-only label default and supports both its Hub id and saved boundary-extractor snapshots.
• Typed GLiNER2.5 extraction and fixed-option decisions, plus a pinned local language-decision evaluation command.
• Optional GLiClass v4 decision backends over torch or ONNX.
• Decision schema 1.1 question sets, ordered levels and System One converters, while retaining the 1.0 request contract.
• An opt-in bounded local decision-server bridge and offline openmed decision-qualify calibration tooling.

See fixed-option decisions and local decision models. Decoder models use the documented local-server bridge; a new in-process MedDecider runtime is not included. Backend availability is distinct from qualification for a deployment.

User-reported corrections¶

• Preserve teacher identity for typed weak-label spans, matching mapping-input consensus without changing acceptance thresholds (#4202).
• Keep active-learning memory unchanged when event persistence fails, so callers can retry queued and labeled events (#4203).
• Preserve form-feed PDF page breaks and all other plaintext line boundaries during geometry extraction and fixed-column redaction (#3567).
• Keep HTML highlights aligned with source offsets across escaped characters, retaining escaped text and metadata and exact label coverage for crossing, nested and adjacent spans (#4326).
• Shift Chinese, Japanese and Korean marker-based dates while retaining source numeric widths, whitespace and digit systems, including without dateutil (#4328).
• Require banking context for pattern-only SWIFT/BIC matches so ordinary clinical section headings are not redacted as bank identifiers (#4152).
• Keep security-support guidance version independent and distinguish stable releases from unpublished candidates (#4131).

The optional clinical Safe Harbor profile and global adjacent-span merging proposals remain separate follow-ups to #4152. These corrections do not change the default policy profile or claim the reporter's benchmark scores as release qualification.

Compatibility and installation¶

Read the 3.1-to-3.2 migration guide. Python 3.11 or newer is required. Existing public import paths are retained, including openmed.service.schemas.DECISION_SCHEMA_VERSION.

The optional cloud extra requires pyasn1 0.6.5 or newer for the upstream ASN.1 decoder security fixes. The core dependency set is unchanged.

After publication, the intended coordinates are:

The new Python language, generator and decision APIs do not imply native feature parity in the other SDKs. Existing platform contracts and documented experimental boundaries remain in force.

Candidate validation and release procedure¶

The frozen target branch is release/v3.2.0, cut from master 4a3b5899d8f64aef8cffd3178f566750a0a80a72. The preparation PR targets that branch. While that PR is open, reviewed fixes can target its prepare/v3.2.0 head so its checks validate the combined candidate. After the preparation PR merges, further v3.2 fixes target release/v3.2.0. Select only needed fixes without pulling later feature work from master into the candidate. Keep the release branch so the release can be tagged from its reviewed final commit.

The PR checks are the live source for candidate validation. The SDK readiness workflow uses v3.1.0, this release's migration guide, the API compatibility report, executed golden tests and retained model evidence. The model catalog, artifact pins, baseline metrics and registry pointers are unchanged by release preparation. New model training and model-promotion benchmarks are therefore not SDK-release prerequisites.

Before publication, require a READY SDK report and successful applicable Python, dependency/security, package, docs/browser, Swift, Android, Helm and container checks on the final candidate commit. Set the actual release date in the changelog, repeat the version/tag-availability preflight and obtain the maintainer's publication instruction. Publish the immutable v3.2.0 tag from that commit through the existing tag-driven workflows; never move an existing tag. Record registry and consumer-install verification after publication.

Federated/private learning and new multimodal/ambient work remain with their later release plans. Clinical deployment and model or language qualification remain separate decisions.