Use imaging data to enable healthcare scenarios

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

I keep this page open whenever I am working on Use imaging data to enable healthcare scenarios in Azure Healthcare APIs / Azure API for FHIR, because most teams I help do not need a marketing tour - they need someone who has already burned a weekend on the same problem. Last January 2026 I was on a call with Anita our cloud lead at a managed-services partner in Madhapur, and we spent forty minutes just clarifying the wording Microsoft uses for this exact thing. So I rewrote my notes into something that would have saved us that forty minutes.

This guide is in my own voice. It mirrors the official Microsoft Learn reference for Azure Healthcare APIs / Azure API for FHIR, but it adds the things I actually had to figure out the hard way: what breaks in production, what the portal will not warn you about, how much it costs in INR, and the exact commands I now keep in my runbook. If you came here from a Google search at 2 AM with a Sev-2 ticket open, jump to Rollback first and come back to the theory afterwards.

Quick context. I run a small consulting practice out of Mumbai, and most of my Azure work is for mid-sized Indian customers - tenants between 50 and 800 users, three to twelve subscriptions, mostly Central India and South India regions. Pricing assumptions in this article are based on the Microsoft India price sheet I checked on 4 June 2026. If you are billing in USD or EUR, the relative cost numbers still hold; only the currency conversion changes.

What this actually does, in plain English

The Microsoft Learn page is technically accurate but it is written for an internal audience that already knows the surrounding architecture. Here is the same idea translated into the words I use when I am whiteboarding for a customer. Use imaging data to enable healthcare scenarios sits at the boundary between something the platform handles automatically and something you have to design intentionally. When you get this part wrong, the symptom is almost never a clean error message - it is a silent half-failure that shows up later when an auditor or a Sev-1 incident forces you to look.

I've seen this fail when teams skip the design conversation entirely and just click through the portal defaults. One customer in Gurugram ran a hybrid network for nine months before noticing that their Azure Firewall was silently dropping ICMP echo replies because of a rule order issue introduced during a copy-paste from a sandbox. The fix took ten minutes. The forensic work to prove no production traffic had been affected took three days. That ratio is typical.

The takeaway: use imaging data to enable healthcare scenarios is not a setting you flick once and forget. It is part of a small set of Azure Healthcare APIs / Azure API for FHIR controls that should be reviewed at least quarterly, and definitely after any of these events: a tenant migration, a subscription move, a regional expansion, a compliance audit, or a personnel change on the cloud team.

Background you need before reading the official text

Medical imaging in Azure Health Data Services is the DICOM service alongside the FHIR service. It stores DICOM studies, exposes a DICOMweb REST API, and integrates with the FHIR service via the imaging-study FHIR resource type. The pairing turns a hospital archive into a queryable, AI-pipeline-ready datastore.

The security model is tighter than for plain FHIR data: a single DICOM study can contain hundreds of images, each potentially identifying the patient. I always enable customer-managed keys, private endpoints, and audit logging from day one for the DICOM service; the defaults are reasonable for evaluation but not for production patient data.

My step-by-step walkthrough

What follows is the exact sequence I run on a clean environment. I deliberately keep it portal-first because most engineers prefer that path on first read; the same flow is at the end of the section as Azure CLI or PowerShell for anyone scripting it.

1. Sign in to the Azure portal at portal.azure.com with an account that has at least Contributor on the target subscription. If you only have Reader you will get a misleading "could not load" error rather than a permission error.
2. Confirm the subscription chip in the top-right of the portal matches the subscription you intend to change. This is the single most common cause of "I changed the wrong resource" tickets I see.
3. Navigate to the resource - for Azure Healthcare APIs / Azure API for FHIR, search the global search bar for the service name and pick the specific resource. Bookmark the resource page in your browser if you will revisit it; the portal navigation tree is too deep to repeat from scratch every time.
4. Open the property pane relevant to use imaging data to enable healthcare scenarios. The pane name in the June 2026 portal is usually the same wording as the heading on Microsoft Learn - search the literal phrase in the portal's command bar if the left nav does not match.
5. Capture the current state before changing anything. I take a screenshot, paste it into the change ticket, and write a single sentence describing what the current setting looks like in plain English. This is the cheapest rollback insurance you will ever buy.
6. Apply the change. Most Azure Healthcare APIs / Azure API for FHIR property changes show a confirmation modal; read it. Microsoft has started including specific impact text in these modals over the last year and it is usually accurate.
7. Wait for the Azure Resource Manager confirmation. The portal will show a green tick once ARM has accepted the change. ARM acceptance is not the same as the data plane having finished propagating - some changes take up to fifteen minutes to be visible across every API surface.
8. Verify in a second surface. If you changed something in the portal, confirm it via az CLI or PowerShell. If you changed it via CLI, confirm it in the portal. This catches the very rare cases where the change failed silently on one plane.

A representative CLI sequence for Azure Healthcare APIs / Azure API for FHIR:

az login --tenant your-tenant.onmicrosoft.com
az account set --subscription "Prod-Subscription"
az group list --query "[?starts_with(name, 'rg-')].{ name: name, location: location }" --output table
az resource list \
  --resource-group "rg-prod-southindia-01" \
  --query "[?contains(type, 'Microsoft.Network/azureFirewalls') || contains(type, 'Microsoft.Blueprint') || contains(type, 'Microsoft.HealthcareApis') || contains(type, 'Microsoft.HealthBot')].{ name: name, type: type, location: location }" \
  --output table

Replace the subscription and resource group with your own values. For PowerShell users, the equivalent modules are Az.Network, Az.Blueprint, Az.HealthcareApis, and Az.HealthBot.

What this costs in INR (and USD for reference)

I keep a small spreadsheet of Azure Healthcare APIs / Azure API for FHIR costs that I update whenever Microsoft posts a price change in the India region. Here are the numbers I am working with on 4 June 2026, rounded so they are easy to remember:

For a representative small healthtech estate (1 Azure Firewall Standard, 1 NAT Gateway, 1 FHIR service at 400 RU baseline, 1 Healthcare Agent Service S1), my back-of-envelope is around ₹1.42 lakh to ₹1.65 lakh per month. That is roughly $1,700 to $2,000. Add bulk import and DICOM storage if you are doing imaging; expect another 20-30% on top.

The number I have seen go badly wrong: customers who provision the FHIR service at a much higher RU baseline than their workload needs because someone followed a "production sizing" guide written for a 10x larger tenant. Right-size to actual traffic; the service supports manual scale-up with no downtime.

If it breaks: rollback and recovery

Most Azure Healthcare APIs / Azure API for FHIR changes are reversible, but the reversal path is not always obvious from the portal. Here is what I do in the three common "I just broke prod" scenarios.

Scenario 1: I changed a setting and the service is degraded

1. Open the resource's Activity log blade. Filter by the last hour. The most recent change with status Succeeded is almost certainly the culprit.
2. Click the activity entry and copy the operation ID. The JSON payload of the change is in the entry; it tells you exactly what changed and what the previous value was.
3. Reverse the change in the portal or via CLI using the previous value. For most Azure Healthcare APIs / Azure API for FHIR property changes this is a single PATCH against the resource.
4. Wait two to five minutes for the change to propagate. If the service does not recover, escalate to Microsoft Support with the operation ID.

Scenario 2: I deleted something I should not have

1. For Firewall, Healthcare APIs, and Health Bot, deletion is immediate and not soft-deletable through the portal. The recovery path depends on whether you had IaC backing the resource: if Terraform or Bicep state has the resource, redeploy from there.
2. If you do not have IaC, file a Microsoft Support ticket within 24 hours. For Healthcare APIs and Health Bot, support can sometimes recover the underlying data store. For Firewall, you re-deploy and reattach.
3. Document the incident. Every customer who has had this happen ended up writing a permanent policy preventing deletion without a resource lock.

Scenario 3: I cannot get into the resource at all

1. Check the resource lock on the resource and on the resource group. A Delete lock will prevent destructive operations but should not block reads; a ReadOnly lock will block everything.
2. Confirm your RBAC assignment is still in place. Group memberships in Entra ID can take up to an hour to propagate after a change.
3. Try the resource from a different network. Some customers configure private endpoints that block access from outside the corporate VPN.

How I verify it actually worked

The portal gives a green tick once the change is accepted, but I do not trust that alone. My verification routine for any Azure Healthcare APIs / Azure API for FHIR change has three steps and takes about ten minutes:

1. Inspect the change via the alternate plane. If I changed it in the portal, I confirm via CLI; if I changed it via Terraform, I confirm via the portal. Two surfaces, same result, before declaring victory.
2. Trigger an end-to-end smoke test. For Firewall, that is a known-allowed and a known-blocked outbound request through the Firewall, with the result logged in AZFWApplicationRule. For Blueprints, that is a clean re-assignment to a sandbox subscription. For Health Bot or FHIR, that is the canonical "hello world" interaction documented in the service.
3. Confirm the activity log entry. Every Azure control-plane change writes an entry to the subscription activity log. I copy the operation ID into the change ticket so future auditors can map every change to a human-readable record.

For ongoing monitoring, I wire an alert on the relevant resource health metric into the team's PagerDuty rotation. The alert text I use is plain: "X has changed health state on resource Y - first responder, run the runbook at /docs/runbooks/x". Short, actionable, no jargon.

Common pitfalls I see on real customer projects

• Treating the docs page as exhaustive. Microsoft Learn pages describe the canonical case. Edge cases - private endpoints, customer-managed keys, sovereign clouds, regulated SKUs - are usually mentioned in a sub-heading but easy to skim past. Always grep the page for your specific configuration before committing.
• Skipping the smoke test. "The portal says succeeded" is not the same as "the system works as designed". I have lost count of the customers who only discovered their setting was not effective when an audit asked for evidence.
• Mixing dev/test and production in the same resource. The hourly fee makes this look attractive for small workloads, but it makes every audit harder, makes RBAC scoping clumsier, and makes blast radius bigger.
• Letting secrets and tokens live in app settings. If you would not put your Entra ID client secret in Confluence, do not put it in an App Service application setting either. Key Vault references work everywhere now.
• Forgetting to budget for diagnostic logs. The per-GB ingestion cost on Log Analytics adds up fast when you enable all categories. Pick the ones you will actually query, and route the noisy ones to Storage if you have to keep them.
• Disabling resource locks to "move faster". Resource locks cost nothing and they have saved more production incidents than every other Azure feature combined. Leave them on.

A real example from Gurugram, January 2026

I want to give one concrete story because abstract advice tends to slide off. January 2026, I was helping a customer in Gurugram - mid-sized healthtech, around 180 employees, three Azure subscriptions split between production, staging, and dev. They had asked for a "Azure Healthcare APIs / Azure API for FHIR review" because their cloud bill had crept past ₹6.4 lakh per month and the finance team wanted answers.

When I sat down to look at their setup, the Azure Healthcare APIs / Azure API for FHIR configuration was a textbook example of what happens when a service is built by a fast-moving team and never revisited. Anita had originally configured it under deadline pressure 14 months earlier and nobody had touched it since. There were redundant resources, overlapping policies, three different diagnostic-log destinations for the same resource type, and an Entra ID app registration that nobody could explain.

The fix was unglamorous and took most of a week. I documented the current configuration in a diagram, marked every component as keep / consolidate / delete, walked the team through it, and then we made the changes one at a time with a verification step after each. The monthly bill dropped by ₹1.18 lakh the following month. The customer reinvested some of the saving in better logging and a quarterly review cadence so the next 14 months would not repeat the pattern.

The lesson I drew, and which I now tell every customer at kick-off: every Azure Healthcare APIs / Azure API for FHIR deployment in any tenant older than twelve months has at least one piece of accumulated drift. Sometimes a dozen. The audit takes an afternoon to scope and a week to execute, and it almost always pays for itself within one billing cycle.

FAQ - the questions I get asked every week

Wrap-up

Use imaging data to enable healthcare scenarios is one small piece of a larger Azure Healthcare APIs / Azure API for FHIR story. If you came here for the answer to a specific question, I hope you found it in the walkthrough or the rollback section. If you came here while planning a wider Azure Healthcare APIs / Azure API for FHIR build, the cost table and the pitfalls list are the two parts I would re-read before writing your design doc.

The official Microsoft Learn page is linked in the References block at the bottom and is the source of record. This page exists because I wanted a version that reflected what actually happens on real customer tenants, not what the doc team had room to fit on the canonical page. Both have their place.

If you want to talk about a specific scenario, drop me an email. I usually reply within 24 hours, and I do not bill for the first conversation.

Related fixes

Related guides worth a look while you sort this one out:

• Manage medical imaging data securely and efficiently
• Azure Policy built-in definitions for Azure Health Data Services
• Integration with Azure Data Lake Storage is generally available
• Use cases for the FHIR service
• Custom scenarios and custom roles
• Use async APIs in the Azure SDK for Java