OpenMed: Local-First Clinical NER and PII Redaction Across Python, Swift, and Android

The Problem: Clinical Text That Must Stay In-House

Healthcare organizations face a hard constraint: clinical notes contain protected health information, and sending that text to a cloud API can violate privacy policies or regulations. OpenMed addresses this by moving extraction and de-identification to the device or server you control. The README's tagline, 'Your Data. Your Model. Your Hardware.', captures the core promise. The target user is a developer or data engineer building a clinical NLP pipeline that must process notes, discharge summaries, or billing data without external network calls. It is also aimed at mobile app developers who want on-device processing for iOS or Android. The project provides a Python SDK, a Swift package called OpenMedKit, and an Android/Kotlin library, all backed by a catalog of over 2,200 medical models covering 21 languages. That breadth is unusual for a local-first toolkit, but it comes with a caveat: the README stresses that network access may occur for model downloads and optional integrations, so 'local-first' does not mean 'never touches the network.'

How OpenMed Works: A Modular Runtime with Multiple Backends

OpenMed's architecture centers on a local runtime that performs extraction and de-identification after required model artifacts are available. The SDK exposes a simple Python API, as shown in the 30-second example: `analyze_text` takes a string and a model name, then returns a list of entities with labels, text, and confidence scores. Under the hood, the runtime supports several execution paths: CPU, CUDA, Apple's MLX, ONNX Runtime Mobile for Android, and Transformers.js for browsers. This is not a single monolithic model; it is a framework that loads specific models from a curated catalog. The README mentions a 'Nemotron Privacy Filter' for redaction and a 'disease_detection_superclinical' model for NER. The MLX backend claims 24-33x faster inference than CPU PyTorch for the Privacy Filter, according to the README's benchmark note. There is also a CoreML fallback path for token-classification artifacts on Apple devices. For agentic workflows, OpenMed offers an MCP server, a typed tool registry, and a command-line interface, making it possible to integrate with other tools programmatically.

Getting Started: Real Commands and Configuration

Installation is straightforward for Python: `pip install --upgrade "openmed[mlx]"` for Apple Silicon or a standard `pip install openmed` for other platforms. The README's example shows a minimal usage: import `analyze_text`, call it with a clinical sentence and a model name, then iterate over `result.entities`. For Swift, add the package dependency in your `Package.swift` with `from: "2.2.0"`, and then `import OpenMedKit`. For Android, add the JitPack repository in `settings.gradle.kts` and include `implementation("com.github.maziyarpanahi:openmed:v2.2.0")`. The Android library expects a model directory, as shown in the truncated Kotlin snippet: `OpenMedKit.fromDirectory(modelDir)`. These are concrete, copy-pasteable steps. However, the README does not detail how to download the model artifacts; it only says 'after required model artifacts are available.' That means you must separately fetch models from the Hugging Face catalog or another source, and the documentation links are the starting point. This is a gap for new users: there is no one-command setup that pulls and caches models automatically.

The Safe Harbor Claim: What It Does and Does Not Mean

OpenMed markets itself as 'Safe Harbor-aligned configuration' that can target the 18 identifier categories from the HIPAA Safe Harbor method. That sounds reassuring, but the README immediately qualifies it: 'expert deployment review remains required, and use of the SDK does not itself establish HIPAA compliance.' This is a crucial distinction. The SDK can help you redact names, addresses, IDs, and billing data, as shown in the synthetic discharge packet example, but it cannot guarantee that your output meets the legal standard. The reason is that Safe Harbor requires removing all 18 identifiers, including dates, geographic subdivisions smaller than a state, and any other unique identifying characteristic. A model may miss an uncommon identifier or a context-dependent one. Therefore, any production use must include a human or rule-based review of the redacted output. This is not a failure of OpenMed; it is a realistic boundary for any NLP-based de-identification tool. The README's honesty here is commendable, but it also means that OpenMed is not a turnkey compliance solution.

Limitations and Failure Modes: Where OpenMed Falls Short

The most obvious limitation is that the core runtime is not fully offline in all scenarios. The README states that model downloads, remote-provider adapters, telemetry-enabled paths, and user-configured integrations may use a network. So if your threat model requires zero network egress, you must pre-download all models and disable any telemetry, which the README does not explain how to do. Another limitation is the reliance on a curated catalog: you cannot bring your own model unless it matches the expected formats and naming conventions. The README mentions 'portable model naming' for MLX that can fall back to PyTorch checkpoints, but only 'where that mapping and artifact are available.' That is a conditional promise, not a guarantee. On the clinical side, the README warns that 'deployment owners validate model and dataset terms, privacy behavior, and clinical fitness.' That places a heavy burden on the adopter. If you need a model for a rare disease or a low-resource language, the catalog may not have it, and you will have to train or fine-tune your own, which OpenMed does not appear to support directly. Finally, the project's last push is August 2026, but there is no mention of long-term support or a maintenance policy, so you must assess the risk of relying on a project that may evolve quickly.

Alternatives: How OpenMed Compares to Cloud and Other Local Tools

The most direct alternative is a cloud-based clinical NLP service, such as AWS Comprehend Medical or Google Healthcare API. Those services offer managed models with high accuracy and no local hardware requirements, but they send patient data to a third-party server, which defeats the purpose of local-first processing. OpenMed's advantage is that it keeps data on-device, but you trade that for the responsibility of model management and validation. Another local alternative is an open-source library like spaCy with a custom clinical NER pipeline, or Stanza from Stanford. Those give you full control and do not require a curated catalog, but they do not provide the breadth of pre-trained medical models that OpenMed claims (2,200+). They also lack the multi-platform mobile adapters that OpenMed offers via OpenMedKit. A more niche alternative is the MLX ecosystem itself, where you could use Apple's MLX framework directly to run a model like BioBERT, but you would have to build the de-identification logic yourself. OpenMed abstracts that away, but at the cost of being tied to its model catalog and configuration conventions. For a team that wants a ready-made, multi-platform solution, OpenMed is stronger; for a team that needs to fine-tune every aspect, a general NLP library may be more flexible.

Maintenance and Licensing: What You Need to Verify

OpenMed's SDK source is released under Apache-2.0, which is permissive and allows commercial use, modification, and redistribution with attribution. However, the README is explicit that 'model and dataset terms vary.' That means each model in the catalog may have its own license, and some may be restricted to non-commercial use or require additional permissions. Before deploying, you must review the license for every model you plan to use. The project's release cadence is active: v2.0.0 in July 2026, v2.1.0 in August 2026, and v2.2.0 later that month. This suggests ongoing development, but it also means the API may change between versions. The README shows a Swift dependency pinned to `from: "2.2.0"`, and the Android setup uses an immutable release tag, which is good practice for stability. But the Python package does not show a version pin in the example, so you should pin your dependencies in a requirements file. There is no explicit statement about upgrade procedures or migration guides, so expect to read the changelog and test thoroughly when upgrading. The documentation links to a research paper and a dedicated docs site, which is a positive sign for maintainability, but the actual quality of those docs is not verified here.

Editorial conclusion

Adopt OpenMed if you need on-device clinical text processing and can commit to validating each model's license, dataset terms, and clinical accuracy for your specific workflow. It is a strong fit for privacy-sensitive environments where patient data must not leave the network. Do not use it if you expect a plug-and-play HIPAA compliance tool; the README explicitly states that use of the SDK does not itself establish HIPAA compliance and that expert deployment review is required. Before production, verify the model artifacts for your target languages and entity types, test the redaction output against the 18 Safe Harbor categories, and confirm that your chosen execution path (CPU, MLX, ONNX, or browser) supports the required models. The v2.2.0 release is current, but the project's last push is dated August 2026, so check the repository for ongoing maintenance and issue resolution.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes