Google Healthcare NL API Alternative: Migration Guide

If your clinical text pipeline still calls Google's Healthcare Natural Language API, you are running on a product its owner deprecated on 27 May 2025. Google's own deprecation record, last updated on 26 October 2026, names one alternative: a generally available Gemini model on Vertex AI. That is a general-purpose model, not a clinical extraction service, so the migration is not a version bump. It is a redesign of what your pipeline expects to receive back, and it deserves the scrutiny of any AI placement decision.

The pressure to get this right is not unique to one vendor. McKinsey's State of AI survey (November 2025) found 88% of organisations using AI in at least one business function, yet only about a third reported AI in production. For a team that has made it to production, a deprecated dependency inside a clinical workflow is a risk to that hard-won status. This guide is written for the Head of Data Science or CIO who owns that dependency, and it stays at the level of migration mechanics: what the old API returned, what each replacement has to rebuild, and how to cut over safely.

It deliberately cedes two neighbouring arguments. The broader case for on-premise extraction over cloud APIs is made in our clinical document extraction guide, and the detail of Mira-Q2's published scorecard lives in the 782-document evaluation write-up. Neither is repeated here.

This guide is shipped by the team behind Dilr Mira, small private language models that turn clinical documents into schema-valid JSON on hardware you control. Or see DATS, our five-stage system for placing AI inside regulated operations.

What did Google actually announce about the Healthcare Natural Language API?

Google deprecated the Healthcare Natural Language API on 27 May 2025 and named a generally available Gemini model on Vertex AI as the alternative. On 27 October 2026 the API's concept page still carries a caution that it will be shut down on 27 May 2026, while Google's deprecation table leaves the decommissioned date blank. The safe reading is that the API is deprecated and should not carry new clinical workloads.

Those two pages disagree in a way that matters for planning. The caution notice on the Healthcare Natural Language API concept page gives a fixed shutdown date that has now passed, and the deprecation table that the notice links to has an empty decommissioned column for the same product. We have not tested whether the endpoint still answers, and you should not build a plan on the assumption that it does. Treat any remaining traffic as borrowed time and the AI operating model question, who owns the cutover, as already overdue.

The service was generally available for under four years before its deprecation. Google's release notes record it reaching general availability on 8 September 2021, gaining the europe-west2 London location on 12 May 2022, adding FHIR R4 bundle output on 31 July 2023, and adding Preview entity types for oncology, social determinants of health and protected health information on 20 March 2024. The deprecation notice arrived a little over a year after that last feature. For a UK team the London location matters, because it may well be part of why the API passed a data residency review in the first place, and any replacement will face that review again. The residency logic behind private models is set out in what Dilr Mira is.

What did the Healthcare Natural Language API return that a replacement must rebuild?

The Healthcare Natural Language API returned more than a list of words. According to Google's concept page, each call extracted medical concepts such as medications, procedures and conditions, functional features such as temporal relationships, subjects and certainty, and relations such as side effects and dosage, then linked each concept to codes in named medical vocabularies. A replacement has to reproduce every part your downstream systems actually read.

Start the migration with an inventory of the fields your code consumes, not the fields the API offered. Google's concept page documents five properties that shape that inventory, and if you want a second pair of eyes on it, book a scoping call:

• Predefined categories. The API "maps text into a predefined set of medical knowledge categories". Your schema was Google's schema, and your downstream code was written to it.
• Vocabulary codes. Each entity carried a preferred term and vocabularyCodes across vocabularies including ICD-10-CM, the ICD-10 Procedure Coding System, LOINC, RxNorm and MeSH.
• SNOMED CT for US users only. The concept page marks SNOMED CT as available only for US users, so a UK deployment was never receiving SNOMED CT codes from this API, whatever the clinical system expected.
• A 20,000 character ceiling. "The maximum size of the medical text is 20,000 Unicode characters", which means long discharge summaries were probably already being split upstream.
• English only. The API supported English text only, so multilingual intake was always handled elsewhere.

The vocabulary point is the easiest one to miss. It is tempting to describe the old API as "entity extraction" and forget that reporting, coding or cohort logic may depend on the codes, not the entities, which is the kind of dependency a placement diagnostic is designed to surface. Before you pick a replacement, grep your own codebase for every place a vocabulary code is read.

The table is our reading of each vendor's public documentation on 27 October 2026, cited in the sections below, not a benchmark. The architectural case behind the on-premise column is in the clinical document extraction guide.

Is a general Gemini model on Vertex AI a like-for-like replacement?

A Gemini model on Vertex AI is the replacement Google names, but it is not like-for-like. It can return JSON that follows a schema you define, which gives you flexibility the old API never had. It does not link entities to medical vocabularies as a service, and it moves the burden of prompt design, evaluation and model lifecycle onto your team.

Google's own structured output documentation is candid about why a schema is needed in the first place:

"Generative model outputs can have some degree of variability, so including a response schema ensures that you always receive valid JSON." -- Google Cloud, Vertex AI structured output documentation

Read that sentence carefully. A response schema guarantees the shape of the answer. It does not guarantee that the medication field holds the medication the document actually names, or that a dose came from the source text rather than from the model. Valid JSON and a correct extraction are different tests, and a migration that only checks the first will pass validation and still ship wrong data into a clinical record. A useful evaluation reports field accuracy as well as validity, as the Mira-Q2 evaluation does on its held-out set. The same page notes that a complex schema can be rejected with an InvalidArgument error, so a large legacy schema may need to be split before it will run at all.

The second cost is lifecycle. Google's model versions page says its longer-lived Gemini models are available for at least 12 months after release, and that shorter-term models receive a fixed retirement date with at least 45 days to migrate. That is a clear policy for general software. For a clinical extraction pipeline it means you should expect to re-run your evaluation set every time the model under your prompt is replaced, which is a recurring cost to plan for from the start.

None of this rules Gemini out. A team that already runs on Vertex AI, wants to define its own fields and has an evaluation harness can do well with it. The point is to budget for the work honestly. In our view, naming who owns that re-evaluation matters as much as the model choice, which is a question of AI operating model design rather than engineering.

Where does Dilr Mira fit in a Healthcare Natural Language API migration?

Dilr Mira fits where the documents must not leave your own infrastructure and your extraction needs fit a defined schema. Mira-Q2, the current release, is a purpose-built extraction model that runs on hardware you control, on premises or air-gapped, and returns ten required JSON fields for a person to review. It is trained to follow a schema passed in its prompt, but it is not described as a terminology-coding service.

The facts on the live Dilr Mira page are specific, and they set the scope of what Mira-Q2 can replace. It is a 120 MB QLoRA adapter on Qwen2.5-3B-Instruct, a model of about 3.1 billion parameters. It reads English only, and it is strongest on lab reports, medication lists, discharge summaries, pathology reports, intake forms and progress notes. It was trained on 8,400 examples, 2,000 of them schema variants, which is why it follows a schema you pass in rather than a fixed category list. Every output is a draft for human review and never an autonomous clinical decision.

The published evaluation covers 782 documents across four test sets with zero identifier leaks. JSON validity was 100% on 200 held-out documents from the training distribution and 85.8% on 282 real physician documents across 39 specialties. That gap is published rather than hidden, and the full evaluation write-up explains what each test set measures. For a migration, the honest translation is this: on documents that look like its training data, Mira-Q2 is reliable at producing your schema; on narrative physician prose it is weaker. DILR states that Mira-Q2 was trained on synthetic data, and the model card says retraining on real documents from a design partner is what closes the gap.

A migration like this can also be run as a programme through our AI execution office, with a fixed cutover date and a named owner for each gate.

Two cautions belong in any procurement note. Mira-Q2 has two licences: DILR publishes the adapter under Apache-2.0, and the Qwen base model it runs on is licensed by Alibaba Cloud for non-commercial use, so check both before building a product on it, as the models page itself advises. And DILR does not publish CPU benchmarks for Mira-Q2, so size hardware against your own documents, not against an assumption.

How do you replace the vocabulary codes the old API returned?

Vocabulary codes need a deliberate decision, because neither a prompted Gemini model nor Dilr Mira is documented as linking entities to SNOMED CT, ICD-10 or LOINC as a service. A team that depended on the Healthcare Natural Language API's codes can either add a separate terminology mapping step after extraction, or choose a cloud entity-linking service whose job is exactly that, and accept that service's data-handling terms.

The entity-linking services are the closest functional match. Microsoft's Text Analytics for health performs entity linking to vocabularies in the UMLS Metathesaurus, adds assertion detection for certainty and conditionality, can return FHIR output, and supports English, German, French, Italian, Spanish, Portuguese and Hebrew. Microsoft notes that customers must separately license the source vocabularies they use under the UMLS terms, which is a contract step that is easy to overlook. Amazon's Comprehend Medical links extracted information to ICD-10-CM, RxNorm and SNOMED CT as a HIPAA-eligible cloud service.

The Azure option has one architectural detail worth reading closely. Microsoft offers Text Analytics for health as an on-premises Docker container, and its documentation says the container must be allowed to connect to Azure and send billing data. For some organisations that is acceptable; for an air-gapped environment it is not, and the decision belongs with whoever signs your special category data controls.

If you take the extraction-then-mapping route instead, keep the two steps separate in your design. Extraction pulls the clinical facts out of the document into your schema; mapping assigns the code from a terminology you license and control. Separating them means a model swap does not silently change your coding, and a coding change does not require retraining a model. It is the same separation our DATS methodology applies to any regulated AI build.

How should a UK team run the migration without breaking clinical safety?

A UK team should treat the migration as a change to a health IT system, not an infrastructure swap. That means updating the clinical risk management file under DCB0129 or DCB0160, confirming the lawful basis and condition for processing health data under UK GDPR Article 9, and running old and new outputs in parallel under human review before any downstream system reads the new fields.

Who each duty binds matters. NHS England describes DCB0129 as the standard that helps manufacturers of health IT software evidence clinical safety, with DCB0160 covering deployment and use, both published under section 250 of the Health and Social Care Act 2012. If you built the pipeline, the manufacturer duties may sit with you; if you deploy a supplier's product, the deploying organisation's duties do. NHS England has also started a review of both standards, so check the current release before you write the hazard log. Sector regulators' wider expectations are mapped in our UK AI risk management guide.

On data protection, health data is special category data, and the ICO's guidance on special category data sets out the conditions for processing it. A move from one cloud API to a different cloud service, or to on-premise processing, changes your processor arrangements and should be reflected in your records before go-live. The MHRA's Software and AI as a Medical Device Change Programme sets out reforms to make medical device regulation fit for software and AI products, and it is the place to track where an extraction tool ends and a regulated device begins. Dilr Mira is described by DILR as an extraction tool whose outputs are drafts for human review, never clinical decisions, and any replacement you choose should be assessed against the same boundary.

A cutover sequence we would use:

1. Freeze a reference set. Take a de-identified sample of documents the old API processed, with its stored responses, before you lose access.
2. Define acceptance per field. Agree with clinical safety which fields must match, which may differ, and what a reviewer does with a mismatch.
3. Run in parallel. Send the same documents to the replacement and compare field by field against the stored responses and a human reviewer.
4. Map codes separately. Validate the terminology step on its own, against codes a coder has checked.
5. Cut over by document type. Move the types where the replacement is strongest first, and keep a reviewer on every output, the same rule DATS applies to any regulated AI build.

Teams that want this run as a fixed programme rather than a side project can hand it to an AI execution office with a named owner for each step.

What is the best Google Healthcare NL API alternative in 2026?

The best Google Healthcare NL API alternative in 2026 depends on whether you need vocabulary codes and where your documents may be processed. For code linking with minimal redesign, a cloud entity-linking service fits best. For teams already on Vertex AI, a Gemini model with a response schema is the named path. For English documents that must stay on your own hardware, Dilr Mira is built for that job.

We would judge any option on five criteria: whether it returns the codes your downstream systems read, where the document is processed, whether you control the schema, which languages it supports, and how often you will have to re-validate it. On those criteria the answer splits honestly:

• Azure Text Analytics for health wins when you need UMLS-linked codes, FHIR output or languages beyond English with the least redesign, and when its container's billing connection is acceptable.
• Amazon Comprehend Medical wins for teams already standardised on AWS that need ICD-10-CM, RxNorm and SNOMED CT linking in the cloud, an option our health insurance claims guide also weighs.
• Gemini on Vertex AI wins for teams already on Google Cloud that want their own schema and can own evaluation through model retirements.
• MedGemma, Google's open health model family, is worth knowing about: its model card describes it as a collection of Gemma 3 variants trained for medical text and image comprehension, released under Google's Health AI Developer Foundations terms. It is a starting point that Google says needs validation and adaptation by developers, and it is not the alternative the deprecation notice names.
• Dilr Mira fits when the document may not leave your infrastructure, your documents are English and close to its training types, and you will review every output, and it is the option this guide's authors build. It loses where you need codes linked for you, and where you need languages other than English, which Mira-3, still in development, aims at.

If you are still weighing open models against each other, our OpenBioLLM comparison covers how to read their benchmark claims, and the clinical document extraction guide covers the architecture choice.

Is the Healthcare Natural Language API already switched off?

Google's documentation does not give a clear answer. On 27 October 2026 the Healthcare Natural Language API concept page still says it will be shut down on 27 May 2026, a date that has passed, while Google's deprecation table lists no decommissioned date. A team should not rely on the endpoint continuing to answer and should plan its migration as already due.

Can Dilr Mira return a FHIR bundle like the old API?

Dilr Mira does not describe FHIR output. DILR's models page describes Mira-Q2 returning ten required JSON fields, with a schema that can be swapped through the prompt. A team that consumed the Healthcare Natural Language API's FHIR R4 bundle would map Mira-Q2's JSON into FHIR resources as a separate, testable step in its own pipeline.

That mapping is the kind of integration work an AI execution office plans alongside the model work, so it is tested before cutover rather than after.

Does Mira-Q2 read clinical documents in languages other than English?

Mira-Q2 reads English only, which matches the Healthcare Natural Language API's own English-only limit, so an English pipeline loses nothing on language by switching. Support for more than one language, starting with Hinglish and code-switched clinical text, is a Mira-3 aim that DILR labels in development, and it should not be planned on as an available feature.

Want to see this applied to your own documents? Read about Dilr Mira and Mira-Q2, see how private models handle health insurance claims documents, read our NHS discharge summary extraction guide, or explore our approach to placing AI inside regulated operations.

More private-model work sits in our AI strategy articles.

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.