A clinical data team that cannot send patient documents to a cloud API usually ends up with a shortlist of two very different things. One is a licensed clinical NLP platform that installs inside the organisation's own environment. The other is an open-weight model the team downloads and runs itself. John Snow Labs is the established example of the first. Mira-Q2, the current release of Dilr Mira, is an example of the second. Both keep the documents in-house, so the buyer's real question is not "on-premise or cloud" but which on-premise shape fits the job.
This comparison is written for the Chief Data and AI Officer, or the Head of Data Science, who has to defend that choice to an information governance board and a finance director. It sets the two side by side on scope, licence terms, deployment mechanics and how each vendor's claims can be checked. John Snow Labs publishes large numbers about itself: it states more than 500 enterprise customers and more than 150 million downloads of its open-source libraries and models. Every figure below about John Snow Labs or Mira-Q2 comes from that vendor's own published pages, and is labelled as such.
Two neighbouring frames are deliberately left to other posts. How to read a medical model's benchmark table and run a head-to-head on your own documents is covered in our OpenBioLLM comparison, and cloud API migration belongs to the Google Healthcare NL API migration guide. This post holds the platform-versus-single-model question.
This guide is shipped by the team behind Dilr Mira, small private models that read clinical documents on hardware you control and return schema-valid JSON. Or see DATS, the five-stage method we use to place AI inside regulated organisations.
What does John Snow Labs actually sell for on-premise clinical NLP?
John Snow Labs sells a portfolio rather than one model: Healthcare NLP, which it describes as more than 3,000 small language models for de-identification, entity, relation and code extraction; Medical LLMs for question answering and summarisation; a de-identification solution; and Generative AI Lab for human-in-the-loop annotation. It positions the stack as deployable inside the customer's own environment, under a commercial licence.
The breadth is the point. The Healthcare NLP product page lists entity recognition, assertion status, relation extraction, de-identification and terminology resolution among its capabilities, and makes a headline claim of four to six times fewer errors than AWS, Azure or GCP. That is a vendor claim about its own product, and a buyer should treat it as a hypothesis to test rather than a result.
The company also states, on its homepage, a number one market rank for NLP in healthcare and life sciences for 2026, more than 80 public case studies and more than 30 peer-reviewed papers and patents. A buyer can read those as signals of maturity, and should still ask for references that resemble its own setting before building on the platform.
The licensed products sit on top of Spark NLP, the open-source library the company maintains. The Spark NLP repository is published under Apache-2.0 and is built on Apache Spark, and the Healthcare NLP page describes the clinical libraries as scalable to a cluster. John Snow Labs also documents a Databricks installation route, so a team already running Databricks has a documented path in. A team without a Spark environment should plan for that architecture as well as the models.
Our clinical document extraction guide already named John Snow Labs as the serious incumbent for teams that want a licensed, commercially supported platform. This post goes one level down, into what that choice involves day to day.
How is Mira-Q2 different in shape from a licensed NLP platform?
Mira-Q2 is a single small model with one job. Dilr Mira's current release is a 120 MB QLoRA adapter on Qwen2.5-3B-Instruct, a model of about 3.1 billion parameters, and it reads a clinical document and returns the same ten required JSON fields every time. It does no de-identification, no ontology linking and no question answering. The difference from a platform is scope, not quality.
The Dilr Mira models page sets out the ten fields: document type, patient age and sex, encounter, vitals, labs, medications, diagnoses, procedures, allergies and extraction notes. The patient object is de-identified by design, returning age and sex and never a name or record number, and the published identifier leak rate was 0.0% across all 782 evaluated documents. That is a property of the output schema, not a de-identification product: Mira-Q2 does not scrub identifiers from a source document for onward use.
The schema can be swapped. Mira-Q2 was trained on 2,000 schema variants, so it follows a schema passed in its prompt, and the models page says a new schema needs a schema file and a handful of seed examples rather than code changes. Our note on response schemas versus fine-tuned extraction explains when that matters.
The shape difference shows up most clearly in a side-by-side table.
| Dimension | John Snow Labs | Mira-Q2 |
|---|---|---|
| What you get | A portfolio: Healthcare NLP, Medical LLMs, de-identification, Generative AI Lab | One extraction model returning ten JSON fields |
| Size, as each vendor states it | More than 3,000 small language models (the headline count; other vendor pages give different totals) | A 120 MB adapter on a model of about 3.1 billion parameters |
| Runtime | NLP libraries built on Apache Spark, described as scalable to a cluster | Loads with Unsloth on a CUDA GPU per the model card |
| De-identification | A dedicated multimodal product | Not offered; output schema excludes identifiers |
| Code and terminology linking | Offered as a capability | Not offered |
| Languages | Vendor states multilingual support | English only |
| Licence | Commercial licence and installation credentials | Two-part: adapter Apache-2.0, base model non-commercial |
| How claims are checked | Vendor papers, case studies, a trial | Public weights, eval files and scorecard on Hugging Face |
Read the table as two different purchases. One buys coverage across many clinical NLP tasks with a vendor behind it. The other buys a narrow tool the team can inspect, run and adapt, with the support arrangement chosen separately, for example through an embedded execution office or the team's own engineers.
What does on-premise mean for each, from licence key to air gap?
On-premise means something slightly different for each option. John Snow Labs' licensed libraries are installed with a licence file or secret code from the vendor's portal, after which its products state they can run on-premise or air-gapped. Mira-Q2's weights are downloaded once from Hugging Face, and the models page says inference then needs no network connection. Both keep documents inside the estate; they differ in how software arrives.
John Snow Labs' own installation documentation is explicit about the licensed layer. Describing the Docker image for its enterprise libraries, the licensed installation guide says the image "does not contain the library itself, as it is licensed, and requires installation credentials." The same guide describes a licence JSON file, a secret code used to fetch the licensed packages, and a 30-day trial on Databricks that can be used once.
None of that means the platform phones home at runtime. The Generative AI Lab page lists cloud, on-premises or air-gapped deployments and says an on-premise deployment needs a licence key. The de-identification page lists on-premise, cloud and air-gapped environments. The Medical LLM page says the company supports on-premise deployments that keep patient data within hospital firewalls. The practical difference is procurement: the licensed path starts with a commercial relationship and credentials, while the open-weight path starts with a download.
For Mira-Q2 the arrival path is the Hugging Face repository. The models page shows the model card's example: it loads the adapter in 4-bit with Unsloth on a CUDA GPU, and warns that loading it with PeftModel gives a quantisation mismatch. DILR does not publish CPU benchmarks for Mira-Q2, so hardware planning should assume a GPU until your own test says otherwise. Either way, nothing in the inference path sends the document out, unlike the hosted route in our Healthcare NL API migration guide.
The flow below is the order we recommend for either option. It is a method, not a measured result.
Settling the job before the vendor is the core of our approach to placing AI: rank where a model belongs before anyone buys one.
Which licence terms does each option carry for commercial use?
Neither option is licence-free for commercial clinical work. John Snow Labs' Healthcare NLP is commercial software that needs a licence and installation credentials, though the underlying Spark NLP library is Apache-2.0. Dilr Mira's Mira-Q2 has two licences: the adapter DILR publishes is Apache-2.0, while the Qwen2.5-3B-Instruct base model it runs on is licensed for non-commercial use.
The Mira-Q2 position is set out on the Dilr Mira models page in plain terms. The adapter is Apache-2.0, which permits commercial use. The base model is licensed by Alibaba Cloud under the Qwen Research License for non-commercial use, and that licence asks commercial users to request a licence from Alibaba Cloud and to show a Built with Qwen notice. A team planning a commercial deployment has to clear both, and the models page says so before anyone downloads anything.
The John Snow Labs position is the familiar one for enterprise software. The licensed libraries are delivered against credentials, a trial exists, and after the trial the vendor makes a licensing offer. Some procurement teams prefer exactly that shape: a contract and a named supplier.
We make no argument here that one licence is better than the other. They answer different procurement instincts, and the right question for a legal or procurement lead is simply whether each licence covers the intended use, who signs it, and what happens to the deployment if the licence ends. If that question is still open, talk it through with us before a pilot starts. Read the full terms for both components of any open-weight model, not only the headline on the repository.
How should a buyer check each vendor's accuracy claims?
A buyer checks the two vendors' accuracy claims in different ways. John Snow Labs supports its claims with peer-reviewed papers, case studies and a 30-day trial on Databricks. Dilr Mira publishes Mira-Q2's weights, eval files and scorecard on Hugging Face so anyone can re-run them. Neither substitutes for a test on the buyer's own documents, and DILR states it has not benchmarked Mira-Q2 against other clinical models.
The John Snow Labs claim that is easiest to show with its comparison figures is about de-identification. Its de-identification page says Providence Health de-identified two billion patient notes with its pipeline, and quotes a paper accepted at an ECIR 2025 workshop reporting a 96% F1-score in protected health information detection, against 91% for Azure, 83% for AWS and 79% for GPT-4o. The chart below shows those figures exactly as the vendor reports them.
Those numbers measure de-identification, which Mira-Q2 does not offer, so they are not a comparison between the two vendors at all. They are useful as an example of what a published claim looks like and what a buyer should ask about it: which dataset, which entity types, which comparison settings, and whether the result held on documents like yours.
Mira-Q2's published numbers measure something else: JSON validity on four test sets. The models page reports 100.0% on 200 held-out documents, 100.0% on 150 documents in a different formatting dialect, 94.7% on 150 real physician documents that match its schema, and 85.8% on 282 real physician documents across 39 specialties. The drop on real documents is published rather than hidden, and the page attributes it to training on synthetic data. Our Mira-Q2 evaluation write-up breaks those sets down further.
How to run a fair test of either option on your own schema and documents is the subject of our OpenBioLLM head-to-head method; that method applies here unchanged.
Which jobs favour John Snow Labs, and which favour a single small extractor?
John Snow Labs suits jobs that need breadth: de-identifying records for secondary use, linking text to clinical code systems, handling PDFs, DICOM or FHIR inputs, or running many NLP tasks at cluster scale under one vendor. Mira-Q2 suits a narrower job: turning English lab reports, medication lists, discharge summaries and similar documents into a fixed JSON record on hardware the team controls, with the model open to inspection.
De-identification for research or secondary use. This is John Snow Labs' clearest strength. Its de-identification page lists notes, PDFs, DICOM, structured tables and FHIR as inputs, with consistent obfuscation per patient. Mira-Q2 has nothing equivalent; the Mira-3 work on removing identifiers before the model reads a document is listed as in development.
Code and terminology linking. If the downstream system needs ICD-10, SNOMED CT or similar codes attached to extracted concepts, a platform with terminology resolution does that work. Mira-Q2's diagnoses field returns a list of diagnoses; the models page says training drew on real ICD-10 codes but does not say codes are returned.
Many tasks, one supplier. A team that wants entity recognition, relation extraction, de-identification and annotation tooling from one contract will find that the platform shape fits.
A fixed record from routine documents. Where the job is a structured record from lab reports or discharge summaries, Mira-Q2's single-purpose design is an advantage: one model, one schema, one output to review. Our guide to discharge summary extraction shows that pattern in an NHS setting, and the pharmacovigilance post shows it for safety case intake.
Inspection before commitment. A team that wants to read the weights and re-run the scorecard before it signs anything can do that with Mira-Q2 on day one.
The same task mapping underpins our AI operating model work, which decides who owns each model, its review step and its retirement before it goes live.
What does each option leave to the buyer?
Both options leave the same governance duties with the organisation deploying them. Whether the team picks John Snow Labs or Dilr Mira, it still needs a lawful basis and an Article 9 condition for processing health data, a human review step, an audit record of each output and a view on clinical safety and medical device status. Running on-premise simplifies the data-location answer; it does not transfer the duty.
The ICO's guidance on special category data is where a UK controller starts on health data, and the duty sits with the controller, not with the model's developer. Our DCB0129 clinical safety guide covers the NHS clinical safety standards: DCB0129 binds the manufacturer of a health IT system, while DCB0160 binds the health organisation deploying it. The fuller treatment of review and audit design is in the OpenBioLLM comparison.
One difference is worth naming. John Snow Labs sells Generative AI Lab, a no-code platform for annotation, validation and model tuning with human-in-the-loop workflows, so part of the review tooling comes with the purchase. With Mira-Q2, every output is a draft for a person to check and the team builds or chooses its own review tooling. That is either a gap or a freedom, depending on what the team already runs.
Dilr Mira is an extraction tool and its outputs are drafts for human review, never autonomous clinical decisions. For any John Snow Labs product, read how its own terms and documentation describe clinical use before a pilot starts. For delivery support around either option, our execution office provides embedded long-term delivery inside the client's own environment.
The same diagnostic logic underpins our AI solutions catalogue, six recurring problems in regulated organisations and what we do about each.
What is the best John Snow Labs alternative for on-prem clinical extraction in 2026?
There is no single best John Snow Labs alternative, and DILR has not benchmarked Dilr Mira against John Snow Labs, so this guide does not claim one. For a narrow, English, fixed-schema extraction job where the team wants open weights it can inspect, Mira-Q2 is worth piloting. For de-identification, code linking, multimodal inputs or many tasks under one supported contract, John Snow Labs is the stronger fit.
Use four criteria, in this order:
- The job. List every task the deployment must do. If de-identification or code linking is on the list, the platform shape is likely to win before anything else is compared.
- The licence. Confirm that each component's licence covers commercial clinical use, including the base model under any open-weight adapter.
- The evidence. Separate vendor-stated results from results you can re-run, and ask what each number measures.
- Your documents. Run both on a stratified sample of your own documents and score them the same way, ideally through a reusable evaluation harness.
The concession is real and specific. A large organisation with a Spark estate, a de-identification programme and a procurement team that wants one supported supplier is better served by John Snow Labs than by a single small model. The Dilr Mira overview is explicit about what Mira-Q2 does not yet do, and the healthcare sector map shows where each kind of AI pays back across a UK health organisation.
Frequently asked questions
Is Spark NLP itself free to use?
Spark NLP, the open-source library John Snow Labs maintains, is published under Apache-2.0 on GitHub and is free to use under that licence. The clinical products built on top of it, including Healthcare NLP, are licensed commercial software that needs installation credentials. A team should not assume the healthcare models come with the open-source library's licence terms.
Does Mira-Q2 de-identify clinical documents?
Mira-Q2 does not de-identify documents. Dilr Mira's current release extracts ten fields into JSON, and its output schema returns patient age and sex but never a name or record number, with a published identifier leak rate of 0.0% across 782 documents. Removing identifiers from a source document before the model reads it is a Mira-3 feature still in development.
Can a team use both John Snow Labs and Dilr Mira?
A team can use John Snow Labs and Dilr Mira side by side, because they do different jobs. One plausible split is a licensed platform for de-identification and terminology work, with a small open model producing a fixed extraction record for one document type. Whether that is worth the extra integration depends on volume and on who supports each component in production.
Want to see this on your own documents? Read the Mira-Q2 scorecard on Hugging Face, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside regulated organisations. More comparisons sit in our AI strategy guides.
Pick the on-premise shape that fits the job.
30-min scoping call · No deck · Confidential. We will tell you whether a platform or a small private model fits your documents, and what a pilot should prove.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.