Skip to content

Migrating from OpenMed 3.1 to 3.2

OpenMed 3.2.0 is a release candidate for global languages, synthetic clinical data and optional local decision backends. Publication is pending. The release notes describe the full scope and intended installation coordinates.

Python and dependencies

Before upgrading, move Python 3.10 environments to Python 3.11 or newer. The dependency security baseline requires the newer interpreter. Published v3.1.0 remains available for existing Python 3.10 installations; this is not a promise of ongoing security support for that environment. Recreate the environment and install the extras your application actually uses.

After publication:

python3.11 -m venv .venv
.venv/bin/python -m pip install "openmed==3.2.0"

GLiFormer, GLiNER2.5 and GLiClass remain optional. Select the documented gliformer, gliner2, gliclass or onnx-runtime extra for the backend you use. Keep checkpoint downloads and qualification separate from processing private inputs. Existing locally cached or caller-supplied models retain their license, offline-loading and calibration requirements. Review the dependency policy for the security floors and incompatible extra combinations.

Retained decision imports and wire contracts

The public openmed.service.schemas.DECISION_SCHEMA_VERSION import remains available as a compatibility re-export of openmed.structured.decision.DECISION_SCHEMA_VERSION. Applications may retain the existing import. New core-only callers should use the structured module without installing the service extra solely to read a constant.

Decision schema 1.0.0 requests continue to work. Schema 1.1.0 adds named question sets, instructions, option descriptions, ordered levels and System One conversions. Omitted versions resolve to 1.0 for legacy fields and 1.1 when the new fields require it. Explicit 1.0 requests cannot silently acquire 1.1-only context. The existing input bound remains the default; an increased bound requires an explicit max_input_chars value.

Qualification and registry defaults remain separate. Use development data to fit thresholds and disjoint evaluation data to check them with openmed decision-qualify. A generated profile does not install a backend as a default or authorize an autonomous clinical action. The decision-server bridge defaults to loopback; retain its explicit endpoint and PHI boundaries. See fixed-option decisions and local decision models.

Burned-in synthetic rendering

Previously, an unavailable font could fall back implicitly. Rendering now requires fonts that cover the requested glyphs and complex-script shaping where needed. A missing or unsuitable font fails rather than producing misleading truth boxes or unsupported script output.

Prefer an explicit covering font. If an application intentionally accepts the documented checked fallback, pass font_fallback=True to generate_burned_in_example or to builtin_recipe_generators(font_fallback=True) for dataset recipes. Preserve the resulting provenance and any rejection; do not turn a failed render into a passing synthetic artifact. See font coverage and shaping.

Languages, surrogates and generated datasets

Existing routes remain available, while deterministic identifiers, calendars, native digits and source-script surrogates gain coverage. Surrogate output can change with the provider version and the new locale rules. Pin providers and store the version manifest beside seeded corpora; compare drift evidence before replacing a dataset or updating downstream golden expectations.

The initial low-resource language cohort remains experimental. New patterns, synthetic augmentation routes, offline bundles or model-loader support do not fill native-review roles or establish clinical model quality. Preserve typed refusals and explicit experimental opt-ins. The graduation contract owns independent recall, review, uncertainty, packaging and cross-lingual regression gates.

For generated corpora, preserve synthetic labels, lineage, licenses, patient grouping, generator versions, truth mappings and release/withdrawal evidence. Do not mix generated truth with model predictions or use synthetic generator accuracy as held-out clinical evaluation. See the synthetic data overview and release controls.

Upgrade and release checks

  1. Retain v3.1 deployment and data provenance before changing the environment.
  2. Upgrade the interpreter, resolve the intended extras and review changed default rendering and surrogate behavior.
  3. Run application privacy, span, identifier, calendar and integration checks with synthetic fixtures; qualify optional models on the owner's permitted held-out data before deployment.
  4. Verify the release PR's API compatibility, golden-suite, model-continuity and platform results at the exact candidate commit.
  5. Use the immutable tag only after publication and verify the artifacts your application consumes. Candidate CI and synthetic tests do not establish clinical validation.

The v3.1 approval-receipt and aggregate-DP privacy remediations remain in force; the 3.0-to-3.1 migration is still required when upgrading from an older version. v3.2 does not introduce another exception to the public API deprecation policy or promote a model through an SDK version change.