OpenMed v2.3.0 spans Python, Swift, Android, and browsers
OpenMed v2.3.0 extracts clinical entities and personal identifiers, then supports masking, replacement, hashing, or date shifting through its Python API. The same project contains a FastAPI service, Apple MLX and Swift paths, Android ONNX support, browser exports, an MCP server, and agent skills. That range is useful when a team wants one naming and policy layer across devices, though each runtime depends on compatible model artifacts and its own integration work.
The base package requires Python 3.10 or newer and keeps its direct dependency list small, while optional extras bring in Hugging Face, MLX, service, OCR, MCP, tabular, workflow, and training stacks. Our chosen development environment installed 150 packages and occupied 941 MB. A model download adds another resource cost that our lab figures do not include. Air-gapped use is possible when model_id points to a local directory containing the required files.
Thirty-six PII language routes still require local validation
OpenMed documents 36 PII language codes, of which 33 use model-backed routes. Russian currently uses a multilingual default-model placeholder, while an optional Indic family requires an operator-supplied model setting. The catalog also covers clinical disease, drug, anatomy, gene, and privacy tasks with models of different sizes. Coverage on a list is a starting point; healthcare teams need representative notes, identifier formats, abbreviations, and misspellings from every population they serve.
De-identification can target the 18 HIPAA Safe Harbor identifier classes, and the package emits leakage or residual-risk evidence for review. OpenMed's compliance guide says the user still owns the legal and scientific decision: all identifier classes must be confirmed for the actual data, qualified experts must handle expert determination, and reversible pseudonym mappings need controlled custody. A valid function result therefore cannot be treated as a compliance certificate or a guarantee that no identifier remains.
What happened when we ran it
Our sandbox installed OpenMed in 67 seconds, adding 150 packages and using 941 MB on disk. The build completed successfully in 16 seconds. commit 6690c95 was much larger than a typical Python library checkout: 3,470 files, about 858,448 source lines, and 79.7 MB. We also found 34 CI workflow files, a Dockerfile, a Compose file, and a tests directory.
The test command exceeded our 900-second limit. Pytest progress moved through 70%, displayed a single F among passing dots at 73%, and continued to 75% before the run ended. The supplied log tail did not include the failing test's name or traceback, so we cannot identify the cause or report a final pass total. Pip-audit found 0 known vulnerabilities in the installed environment, which is useful but separate from model safety or clinical accuracy.
One missing golden test crosses five clinical pipeline stages
Open issue 1950 says unit coverage exists for individual stages, while a golden test connecting de-identification, NER, assertion, grounding, and FHIR export is absent. The issue specifically warns that an offset shift between stages could corrupt later grounding or exported resources without a frozen end-to-end expectation. That gap matters more than a cosmetic failure because users may compose the five stages into a clinical data pipeline.
The 900-second timeout does not prove that issue caused our visible failure marker, and the log gives no basis for that inference. It does mean commit 6690c95 did not finish its full suite in our 3-CPU, 8 GB sandbox. Before adopting OpenMed, run the exact language, model, de-identification method, grounding route, and export format you need against synthetic golden records. Keep a human review step around clinical codes and downstream decisions.
Port 8081 is safe only behind the documented MCP boundary
The local MCP guide uses stdio when the client and OpenMed share a machine, avoiding a network listener. Its Streamable HTTP example publishes port 8081 only on loopback. The built-in server does not validate API keys or bearer tokens, so a remote deployment needs a TLS-terminating gateway that authenticates every request. Hosted assistant connectors also cannot reach workstation loopback, which forces a private network or guarded HTTPS route.
The documented MCP workflow de-identifies first, then passes text-free spans, hashes, codes, and aggregate risk data through later stages. External-language-model stages stay disabled until an operator opts in, and raw source text is not supposed to cross that boundary. OpenMed also ships skills for Claude Code, Codex, and compatible agents. Real patient data should stay out of a cloud agent prompt even when the resulting code eventually runs on-device.
September 2026 activity includes 543 issues and pull requests
GitHub recorded the latest push on September 5, 2026, one day after the v2.3.0 release, with 5,241 stars and 543 combined issues and pull requests. Recent activity included FHIR validation, privacy-safe federated metrics, artifact references, and dependency updates. The pace is high, and the combined count includes proposed work plus pull requests, so it should not be read as 543 confirmed bugs.
The large queue does show how quickly OpenMed's scope is expanding beyond clinical NER. Open issues cover multimodal preflight, federated training controls, agent artifacts, and an end-to-end clinical test. Teams needing only PII removal may prefer Presidio; teams already centered on spaCy or Spark have narrower options too. OpenMed earns a trial when cross-platform clinical processing is the requirement, provided the 150-package footprint and unfinished full-suite result become part of the adoption decision.