OpenMed 2.3: PDF and email redaction without patient data leaving the building, running locally in the browser and on the phone

The open source healthcare AI library OpenMed has released version 2.3.0. The title of the release note sums the work up: "Local-First Healthcare AI Across Python, JavaScript, Swift, and Android." The repository has 5,200 stars.

Why "local first" is its own problem in this field

The obstacle in front of healthcare AI is not model quality but where the data goes. Once a patient record, discharge summary, image or message leaves the institution, the work turns into a legal problem. OpenMed's whole architecture is built on that: the processing happens on the institution's own machine and the data does not travel.

2.3 adds concrete capability on that side: a pipeline that reconstructs reading order in PDFs and performs burned-in redaction, with verification that the source text was actually removed and masked evidence produced. Visible text is extracted from HTML together with source offsets. Email (EML) redaction, an explicitly isolated optional MSG bridge, RTF and fixed-width text intake, and notebook-cell redaction are also in.

Open failure instead of a silent gap

One detail in the release note is worth more to a regulated institution than the headline. In the JavaScript side's redaction, when a token cannot be aligned the system now produces a content-free failure; previously it silently produced incomplete redaction.

In a security or compliance product that difference is everything. A document that was silently under-redacted gets shared as though it were redacted. An operation that fails openly stops and asks a human. In the same release the default model was switched from an unavailable one to the public ClinicalE5 33M ONNX model, source offsets were restored for Transformers.js output, and decomposed accents and supplementary Unicode letters are preserved.

Where it runs

• Browser: WebGPU with a deterministic WASM fallback
• Android: QNN/NNAPI selection with CPU fallback
• iOS: Share and Action extensions
• Desktop: Electron and Tauri bridges
• Server: TensorRT export, GGUF, MLX optimization, edge SBC qualification

On deployment there are KServe, Triton, a Kubernetes operator, HPA, self-hosted Compose and local service adapters. On the data side OpenSearch, Elasticsearch, Spark, Beam, Airflow, LlamaIndex, PostgreSQL and dbt connections are opt-in.

Clinical evidence and boundaries

The release adds deterministic evidence tables, scoped substance-use (SDOH) extraction, and experiencer-aware patient-record span filtering. Consent verification does not throw, it returns a result, and it does so together with assistive-use and qualified-review boundaries. The product positions itself not as something that diagnoses but as an assistive layer subject to human review.

Release discipline

The numbers stand out as a maturity signal. Since 2.2.0 there are 253 commits and 652 changed files; the public Python inventory grows from 37,735 to 41,729 symbols, meaning 3,994 additions with no removals, no renames and no narrowed signatures. The REST contract stays compatible at 19 paths and 17 schemas. The project also announced that 14,099 Python tests passed.

Installation is pip install --upgrade "openmed==2.3.0" on Python and npm install openmed@2.3.0 on JavaScript; Swift Package Manager and Android packages through JitPack are published as well.