Healthcare and Life Sciences Blog articles

Publish Copilot Prompts to Your Whole Org in Minutes

michaelgoad — Fri, 24 Jul 2026 19:03:00 GMT

If you rolled out Microsoft 365 Copilot and then watched most of your people ignore it, this one's for you.

I help organizations deploy Copilot in front of thousands of users, and the pattern is almost always the same. A company buys Copilot, starts the rollout, and then watches it sit there. It's easy to blame the tool. Most of the time we handed everyone a blank box and expected them to figure out what to type.

Your people aren't prompt engineers. They're nurses, knowledge workers, and HR. They open Copilot, see a blank screen, type something like "summarize this email," don't love what comes back, and quietly walk away. Do that across thousands of users and adoption stalls.

There's an admin setting that helps with exactly this. It's called organizational prompts, and if you own Copilot for your org, don't sit on it.

What organizational prompts do

Organizational prompts let you load a library of ready-to-use prompts straight into Copilot for your whole organization. You create and publish them once, and they show up for your users across Copilot Chat, Microsoft Edge, and Teams, suggested automatically as people type. Instead of a blank screen, your users open a menu and pick from prompts you already wrote for them, sorted by department. It gives people a starting point, which is the thing most of them are missing.

One heads-up before you go looking for it. This is rolling out right now, so if you don't see Prompts under Copilot yet, that's likely why, but most are already seeing it in their tenants, so it should be there soon. You'll also need the AI Administrator or Search Editor role to manage them.

How to set it up

Head to the Microsoft 365 admin center. On the left, drop down Copilot and open Prompts. That's where your organizational prompts live.

You've got two ways to add them:

Create them one at a time with the Create prompt button.
Import them in bulk. Download the CSV template, fill in one row per prompt, save it as CSV UTF-8, and import the set. You can import up to 100 prompts at a time (5 MB max per file), and publish up to 1,000 in your tenant. If you already have a prompt catalog in a spreadsheet, this is the fast path.

When you create or edit a prompt, you'll set a few fields:

Title and display prompt. The title is the label on the prompt lab card (35 characters). The display prompt is the short version shown on the pill suggestions and autosuggest (132 characters).
Prompt. The actual text sent to Copilot when someone picks it. This is required and gives you room to write a real prompt (up to 8,000 characters).
Supported apps. Pick where the prompt shows up. This one matters. Not everyone has a premium license, but everyone has Copilot Chat on the web, so you can make a prompt available there too.
Department. Heads up: departments don't map to a security group. They're free-text filters for the end user. Tag prompts with IT, Finance, HR, and so on so people can sort the library by their team.
Task type. These come from Microsoft (Analyze, Create, Edit, and so on). You can't make your own, but tagging them helps users filter.
Language. Set the language for the prompt. There's no auto-translation, so if you need a prompt in multiple languages, create a separate one for each.

Hit publish and it's live. Give it about 3 hours to show up in the prompt lab. You can also pin your most important prompts, up to four, and those pinned ones show up as suggested prompts on the Copilot home screen.

Check the analytics

There's an Analytics tab that's worth your time. Once the data populates, you can see active users and submissions per prompt over the last 7, 14, or 28 days. That tells you which prompts people actually use, which ones to fix, and where adoption is landing. It's a straight read on what's working.

Where your users find them

Setup is half the job. Users need to know where these live. They show up in three spots:

The Suggested button on the Copilot home screen, which opens your pinned prompts.
The prompt lab, where users search by keyword and filter by department or task type. Picking a prompt drops it into the message box so they can tweak it before sending.
Autosuggest right in the Copilot input box as someone starts typing.

So someone on IT can search "IT," grab a prompt that rewrites a help desk reply so it doesn't read like "did you try restarting your computer," and send something that sounds a lot nicer. Pre-made prompts, sorted by team, ready to go.

Do these two things after you turn it on

Tell people it exists. Send a note to your communication channel. You've got a prompt library, it's sorted by department, here's where to find it. A library nobody knows about doesn't move adoption.
Give people a way to submit prompts. Set up a channel where users can send you good prompts to add. When someone finds a prompt that works for Finance or IT, they should have a clear path to say "add this one." That keeps the library growing from the people actually using it.

Organizations have been asking for this because they want to hand users a foundation for getting started with Copilot. Organizational prompts are one of the cleanest ways to do it, and it takes minutes.

If you're an admin, this is a quick win with real impact. Set it up, tell your people, and give them a way to add to it.

For the full field reference and character limits, here's Microsoft's official documentation: Organizational prompts for Microsoft 365 Copilot.

Go push some buttons.

Fabric Data Agents can choose Query Language based on Context

Greg_Beaumont — Thu, 09 Jul 2026 16:12:47 GMT

What if you could combine decades of historical analysis with live, real-time data in one seamless AI chat experience? Traditionally, analyzing large volumes of past data (Analytics / Business Intelligence) has been a separate architecture, or has at least required separate toolsets, from monitoring what’s happening right now (real-time, IoT, etc). With Fabric Data Agents, analytics for large volumes of historical data can be accessible with real-time data via a single AI query endpoint. Analytics can be used to gain understanding from historical data, and findings can be put into action for real-time scenarios, all through a single interface for the end users.

Figure 1.0 – Fabric Data Agent can use different query languages for optimal performance with a lambda-style RTI architecture on Fabric

Many of the demos I’ve seen for Fabric Data Agents will highlight the capability to connect to different types of queries and sources via a single endpoint such as Lakehouses (SQL), Warehouses (SQL), Semantic Models (DAX), Eventhouses (Kusto), and Ontologies. What I have not seen frequently discussed is adding different query engines on the same data for the purpose of optimizing query performance based upon the context of the query and the latency of the data, as per Figure 1.0 above.

To be clear, I am not advocating duplication of data for the purpose of query performance. Rather, this architecture would enable Fabric Data Agents to choose the best query language for the context of the query. Hence the acronym I created for this blog article “NoDAX” which stands for “Not Only DAX.” NoSQL “Not Only SQL” is a real term referring to non-relational database systems designed for flexible schemas, horizontal scaling, and high-performance access to large, distributed datasets. NoDAX exists only within this blog post, and represents the availability of multiple query languages within a single Fabric Data Agent. The best query language can be used based on the context of the question and query. Not only DAX but also SQL, Kusto, and Ontologies can be queried to generate the most efficient contextual query.

Figure 1.1 – Explaining the NoDAX acronym created for this article

Why does this use case matter?

The ability to query both the past and the present in one interface isn’t just a novel technical capability. Many analytic solutions can benefit from a pattern of [analysis + action]. Analytics by itself is great at understanding the past. We can look at years of historical data to figure out patterns, drivers of performance, and what went right or wrong. Historical context is incredibly valuable, but understanding the past doesn’t improve outcomes in the future.

The real value comes when we connect findings from the past to decisions we make right now and in the future. If you discover historical data patterns that lead to an inventory shortage, a fraud event, or a patient risk score increasing, you can apply that insight to the latest operational data and act on ongoing workflows. Analytics and action have to reinforce each other. Analytics without action doesn’t create value. But action without understanding can easily make things worse. I once had a veteran analytics manager say to me “Without carefully considered and vetted KPIs you are flying blind. But be careful, because a KPI without proper context and understanding will quickly become a blunt object that an empty suit uses to whack somebody over the head.”

Figure 1.2 – The purpose of this architecture is to learn from the past to improve the present and future

Different Query Languages without data duplication

A Fabric real-time architecture can be part of a design pattern that is similar to if not a version of a Lambda architecture. With a Lambda architecture, hot path data is available for real-time alerting and analytics while cold path data is stored for deep and complete historical analytics and data science.

Figure 1.3 – NoDAX architecture can query a lambda-style architecture via multiple query endpoints

Per the diagram above, real-time data is available in Fabric ASAP and cycled through an Eventhouse. Historical data can either be batched into a Fabric Lakehouse / Warehouse or copied over from the Eventhouse. A Fabric Data Agent can then generate Kusto queries against the Eventhouse, SQL queries against the Lakehouse / Warehouse, or DAX queries against the Warehouse / Lakehouse via the Direct Lake Semantic Model. DAX is often the best query language for data having deep history with complext analytic logic. SQL can be the best query language for retrieving historical row-level information from a robust relational database. Kusto can be used to query what’s happening right now via a real-time Eventhouse.

Lambda architectures have been around for years, so why is this architecture a new option? Past lambda architectures would have hot path data available in a streaming toolset such as Azure Eventhub, and then store historical cold path data in a tool such as Azure Data Lake. Hot path alerting and reporting was usually disparate from historical cold path analytics. Per the diagram 3.4 below, with Microsoft Fabric, you can now:

implement both the hot and cold path in a single Fabric environment (Eventstream, Eventhouse, Lakehouse / Warehouse). Ontologies are also an option.
query the hot and cold path data via a single agentic endpoint using a Fabric Data agent
Query either the hot or cold path using the optimal query language for the context of the question (DAX, SQL, Kusto, Ontologies)

Figure 1.4 – Fabric not only unifies components of lambda-style architecture, but Data Agent also unites the query endpoints for AI unification

Example use case for Healthcare

Here’s an example of a Healthcare use case:

A user might ask a question “Show me the percentage of patients who had their pain scores checked every hour for gall bladder removals on floor 5 over the last 3 years.” This will ideally filter three years worth of data for patients with specific procedure codes, filtered for specific rooms, and calculate the pain score check compliance for those visits. This query is ideal for the DAX language with a Semantic Model.
The user might then want to see details for a specific time period, and ask “Show me the pain score results for patients who had their gall bladder removed on July 3 2024 on floor 5.” A SQL query might be the best option here against the Fabric Warehouse or Lakehouse, since SQL is better than DAX at retrieving row-level information.
Then the user might want to know what is happening today. “Show me the pain score checks for inpatients right now who had their gall bladder removed on floor 5.” The Kusto language can retrieve the information that streams into a Fabric Eventhouse via an Eventstream. Based on the findings, the user may take an action.

With the example above, a user was able to query deep history with analytic logic, retrieve historical row-level information from a robust relational database, and then view what’s happening right now for those patients. Action can then be taken in the here and now. Here are some additional use cases for Finance, Supply Chain, and Manufacturing in addition to Healthcare:

Figure 1.5 – Industry use cases for Fabric Data Agent with multiple endpoints

Video Summary

Below is my video summary and demo of the Fabric Data Agent NoDAX architecture:

Configure Fabric Data Agent for NoDAX query patterns

When more than one source is added to a Fabric Data Agent, by default the source used for a specific query will be chosen based on interpreting available metadata. The Data Agents have a field called "Agent instructions" which can be used to provide detailed instructions about choosing the right source for the right question. Here’s a screenshot of the Agent instructions:

Figure 1.6 – Agent instructions will guide the Fabric Data Agent to the best query endpoint

I would recommend extensive unit testing and iterative improvements to the Agent instructions based upon your own data and use cases. Here’s a few examples that worked for my initial testing. I would recommend much more robust and carefully designed prompts for a production solution, but this is a baseline of an approach I found to work based on the demo in the video above:

The KQL database named SeattleFireEventHouse is a live stream of 911 calls to the fire department in the city of Seattle. Whenever someone asks for “most recent” or “newest” or “latest” use SeattleFireEventHouse
The lakehouse SeattleFireLakehouse should be queried with a SQL statement when someone asks for a list of incidents before the year 2026. Use SQL to retrieve row level requests for historical data.
The semantic model SeattleFireSemantic Model should be queried when questions ask about historical analytic trends such as call volume averages, Year over year changes, and queries that aggregate data for analytic queries.

Right-Sizing Intelligence: Building a Multimodal Model Portfolio for Healthcare and Life Sciences

MichaelGannotti — Wed, 24 Jun 2026 20:58:16 GMT

For two years, the AI conversation in healthcare fixated on a single question: which large language model is best? That question is now out of date. The frontier didn't just get smarter, it got plural. The most capable healthcare AI systems being built today are not one model but a portfolio: large reasoning models, small efficient models, and specialized models for voice, images, and video, each doing the part of the job it does best.

Microsoft Foundry makes that portfolio practical. Its model catalog spans over 1,900 models from Microsoft, OpenAI, Anthropic, Meta, Mistral, xAI, DeepSeek, Hugging Face, and others, together with the tools to compare, ground, evaluate, and govern them in one place. For healthcare and life sciences (HLS) leaders, the strategic shift is from *pick the model* to *design the portfolio*.

This post walks through one concrete, high-value pattern, turning a clinician's spoken encounter into a verified, structured note, and uses it to show how a model portfolio works end to end, what it costs at scale, and how to keep it safe. Several of the newest capabilities referenced here are in preview; confirm current naming and availability before you build.

Why “model” is now a plural

A modern model strategy spans two axes: capability size and modality. Getting both right is the whole game.

On the size axis, Microsoft Foundry presents a clear menu. GPT-5-class models are the most capable for complex, multi-step reasoning and multimodal scenarios. GPT-4.1 strikes a balance of capability and cost for production workloads, and GPT-4.1 mini is tuned for the lowest-latency, highest-throughput jobs. Alongside them sit Microsoft's Phi small language models, Phi-4, Phi-4-mini, and Phi-4-multimodal, designed for strong reasoning with efficient deployment, including on-device through Foundry Local.

On the modality axis, the catalog reaches well beyond text. Microsoft's MAI (Microsoft AI) family includes MAI-Voice-1, an expressive neural text-to-speech model for natural, long-form English speech, and MAI-Transcribe, a speech-recognition model tuned for both accuracy and efficiency. Phi-4-multimodal accepts text, images, and audio in a single model. And a dedicated set of healthcare AI models, such as MedImageInsight, MedImageParse, and CXRReportGen, brings multimodal reasoning to medical imaging, pathology, and radiology. The point isn't to use them all; it's that the right answer to almost any real HLS workflow is several of them, composed.

A multimodal model portfolio in Microsoft Foundry: diverse inputs, the smallest capable model per task, governed outputs.

The business problem: documentation, education, and unread data

Start with the problem clinicians feel most acutely: documentation. Writing notes, orders, and after-visit summaries consumes hours that clinicians would rather spend with patients, and it is a leading contributor to burnout. Ambient AI scribing, listening to the visit and drafting the note, is one of the clearest near-term wins in healthcare AI.

But documentation is only the first domino. The same portfolio that drafts a note can generate patient-education material in plain language and natural voice, summarize a specialist's imaging findings for a referring physician, and make dense clinical text understandable for caregivers. Much of healthcare's most valuable data, audio, images, and scanned documents, has historically gone unread by software. Multimodal models change that.

The catch is economics. If every one of these tasks calls the largest available model, the combined cost and latency make the program impossible to scale. Right-sizing, matching each task to the smallest model that can do it well, is what turns a compelling demo into a sustainable service.

A technical walkthrough: from voice to verified note

Consider the ambient-documentation workflow in detail. It is a useful template because it touches every part of the portfolio, speech, small models, large models, retrieval, evaluation, and human review, in a single pass.

The inputs

The pipeline starts with two inputs: the ambient audio of the encounter, captured with patient consent, and structured context from the electronic health record (EHR), the patient's problem list, current medications, and recent results. Related images or documents can come along for the ride when the visit calls for them.

Which model does what

Here is where the portfolio earns its keep. No single model touches the whole job:

Speech-to-text. A speech model (Azure AI Speech, or MAI-Transcribe for high accuracy and efficiency) converts the conversation into an accurate, timestamped transcript.
Extraction and structuring. A small Phi model parses the transcript into discrete elements, problems, medications, and follow-ups, at a fraction of the cost and latency of a frontier model, and it can run close to the data.
Grounding (RAG). A retrieval step injects only approved context, the organization's clinical guidelines and the specific patient's record, so the draft reflects real, current, permissioned information rather than the model's memory.
Drafting. A larger GPT-class model composes the narrative note, reconciling the transcript, the structured extraction, and the grounded context into clean clinical prose.
Patient-facing media. For the after-visit summary, MAI-Voice-1 can render a plain-language version as natural speech, and avatar or video generation can produce short education clips for patients or providers.
Imaging insights. When images are involved, healthcare models such as MedImageInsight or CXRReportGen surface findings for a specialist to review, in supported, non-diagnostic configurations.

Orchestration, evaluation, and the human checkpoint

Foundry orchestrates these calls, and two stages matter as much as the models themselves. Evaluation runs automated checks on every draft, grounding and faithfulness, safety, and completeness, and routes low-confidence outputs for extra scrutiny. Human review is the non-negotiable final gate: the clinician reads, edits, and signs off before anything reaches the chart. The model drafts; the clinician decides.

From voice to verified note: each stage uses the smallest capable model, and a clinician signs off before anything reaches the chart.

Capture with consent. Record ambient audio and pull the relevant EHR context at the point of care.
Transcribe. Convert audio to text with a speech model sized for accuracy and throughput.
Extract. Use a small Phi model to structure the transcript into problems, medications, and actions.
Ground. Retrieve only approved guidelines and the patient's own record as context (RAG).
Draft. Have a larger model compose the note from transcript, structure, and grounded context.
Evaluate. Score each draft for faithfulness, safety, and completeness; flag the doubtful ones.
Review and sign off. The clinician edits and approves; the edits feed back to improve prompts and routing.

The economics at scale: right-sizing the portfolio

The difference between a pilot and a platform is cost-to-serve. A right-sized portfolio attacks it on several fronts at once.

Match model to task. Most steps above, transcription, extraction, classification, routing, are high-volume but not cognitively hard. They belong on small models like Phi, which deliver strong results at far lower cost and latency. Reserve the large, expensive models for the genuinely difficult step: composing and reconciling the final note. Spending frontier-model dollars on routine extraction is the single most common way AI programs blow their budget.

Cache and batch. Identical or near-identical requests, a common guideline lookup, a standard education snippet, can be cached and reused. Non-urgent work, overnight summarization or cohort processing, can be batched for throughput rather than instant response.

Run small models close to the data. Through Foundry Local, eligible Phi workloads can run on-device or at the edge, cutting per-call cost and keeping sensitive audio and text on local infrastructure, valuable in a hospital where latency and data residency both matter.

Make unit economics predictable. For specialized work, Microsoft's premium healthcare models are offered as pay-as-you-go serverless endpoints with predictable per-image economics, so finance can model cost per study rather than guess at infrastructure. The net effect: cost and latency scale with the difficulty of the work, not with raw volume.

One large model for everything versus a right-sized portfolio: matching model size to task difficulty is what changes the economics.

Governance: safety, responsible AI, and human oversight

In healthcare, governance is not a layer you add at the end; it is the foundation. A right-sized portfolio actually makes governance easier, because each model has a narrower, better-understood job.

Responsible AI by design. Foundry includes built-in evaluation, content safety, and observability, so teams can test models against their own data and monitor them in production.
Data boundaries. The pipeline runs within your tenant, under your existing identity, permissions, and data-protection controls; grounding restricts the model to approved, permissioned sources.
Human in the loop. Microsoft's healthcare models are explicitly designed to support, never replace qualified professionals; many are in preview and intended for research and development, not autonomous clinical decisions. A clinician signs off on every clinically meaningful output.
Provenance and feedback. Capturing edits and approvals creates an audit trail and a continuous-improvement loop for prompts, routing, and model selection.

Responsibility stays with the deploying organization: you remain accountable for verifying outputs, meeting applicable healthcare regulations, and obtaining any clearances required before a model informs clinical decision-making. The portfolio approach supports that accountability by keeping each step inspectable and each consequential decision human.

How to start: a 30-day mini-playbook

Pick one painful, high-volume workflow. Ambient documentation, referral summaries, or patient-education drafting are strong first candidates.
Map the modalities. List the inputs (audio, text, images) and outputs (note, summary, voice) so you know which model types you need.
Draft the portfolio, smallest-first. Assign each step to the smallest capable model and reserve large models for the hardest step only.
Ground it. Connect approved guidelines and the relevant record through retrieval before you optimize anything else.
Stand up evaluation early. Define faithfulness, safety, and completeness checks, and a human-review step, from day one, not after launch.
Measure cost and latency per task, then tune routing, caching, and batching against real usage.
Expand by reuse. Once the portfolio works for one workflow, most of it, speech, extraction, grounding, governance, carries straight over to the next.

The organizations that win with healthcare AI over the next year won't be the ones who picked the single “best” model. They'll be the ones who designed the best portfolio, matching capability and modality to each task, grounding every output, and keeping clinicians firmly in the loop. Right-sizing isn't a cost-cutting afterthought; it is the architecture that makes AI affordable, fast, and safe enough to use everywhere.

Subscribe to the Microsoft Healthcare & Life Sciences blog for weekly, practical deep dives on building AI that scales. And one question to leave you with: if you mapped your top clinical workflow today, how many of its steps actually need a frontier model, and how many are quietly overpaying for one?

Sources

The Agentic Workday: A Technical Deep Dive into Microsoft Scout for Healthcare and Life Sciences

MichaelGannotti — Mon, 22 Jun 2026 16:22:22 GMT

The Agentic Workday: A Technical Deep Dive into Microsoft Scout for Healthcare and Life Sciences

Healthcare and life sciences teams do not have a motivation problem. They have a time problem. The people closest to patients, studies, and customers spend a striking share of their week assembling information — pulling records, reconciling notes, cross-checking criteria, and stitching together the context a single decision requires. The work is essential, but most of it is assembly, not judgment. And assembly is exactly what a well-governed agent can take off their plate.

That is the promise of agentic AI, and it is why Microsoft Scout — an agentic AI desktop assistant — belongs at the center of the modern HLS workday. This is a technical deep dive, not a teaser. We will walk two concrete workflows end to end: how the work happens today, how Scout would actually do it step by step, where a human stays in control, and how the whole thing stays inside your existing security and compliance boundaries. The product claims are kept functional and defensible, and the guardrails are made explicit — because in this industry the guardrails are the point.

From assistant to agent: why the shift matters in HLS

First-generation generative AI was reactive. You asked a question; it produced text. Helpful, but the human still did all the connecting — opening the file, navigating the portal, copying the answer into the next system. Agentic AI changes the unit of work. Instead of a single response, an agent can plan a sequence of steps, operate the tools already on your machine, draw on the sources you permit, and pause for your approval before anything consequential happens.

In most industries that is a convenience. In healthcare and life sciences it is the difference between a demo and a deployable workflow, because the steps between "knowing" and "doing" are wrapped in regulated systems, sensitivity labels, and review obligations. An agent that respects those boundaries does not just save time; it makes the time savings auditable.

How Microsoft Scout is grounded in your work

Microsoft Scout is designed to act, not just chat. It can read and organize files, run routine multi-step tasks across your everyday applications, browse the public web for current information, and reach into your Microsoft 365 work — Outlook email and calendar, Teams messages, and documents in OneDrive and SharePoint — to assemble the context a task genuinely needs. Where clinical or proprietary systems are involved, the practical and defensible pattern is to ground Scout in permitted exports and connectors and your existing permissions, rather than assuming a built-in line into any system of record.

Microsoft Scout draws on permitted sources and returns review-ready drafts — within your existing identity, permissions, and sensitivity labels.

The experience HLS leaders notice is momentum. Rather than narrating every click, you describe an outcome — "prepare the prior-authorization packet for today's queue" — and Scout drafts the path, does the assembly, and brings the result back for review with its work shown. Two design choices make that adoptable in a regulated setting: a human stays in the loop on anything consequential, and every step is visible, so reviewers can trust what they sign.

Deep dive 1: Prior-authorization preparation

The business problem, and what it costs today

Prior authorization is one of the most friction-heavy workflows in provider operations. Before a procedure or therapy can proceed, someone has to demonstrate it meets the payer's medical-necessity criteria — and that proof lives in fragments scattered across clinical notes, prior results, correspondence, and policy documents. The cost is rarely a single dramatic number; it is the steady drag of skilled coordinators and clinicians spending hours on document hunting and formatting, delays that push back care, and the rework that follows when a submission comes back incomplete. Every hour spent assembling is an hour not spent on patients or on the genuinely hard calls.

The manual process today

Walk the current path and the pattern is familiar: a coordinator identifies the cases in the queue, then opens system after system to locate the supporting documentation. They copy relevant notes into a working document, compare what they have against the payer's criteria for that specific service, and — often late — discover a missing result or an unanswered question. They chase it down, assemble the submission, give it a final review, and key it into the payer portal. The judgment at the end is real and valuable. Almost everything before it is assembly.

The agentic how-to: how Microsoft Scout would do it

Scout automates gathering, drafting, and gap-flagging; the coordinator reviews, approves, and submits.

Trigger — a scheduled run. Scout starts on a schedule (for example, early each morning) against the day's work queue, so a first-pass packet is waiting before the team sits down. It can also be launched on demand for a single case.
Gather from permitted sources. Operating under the coordinator's existing permissions, Scout pulls the relevant context: documentation provided through permitted exports or connectors, related Outlook email threads, and supporting files in OneDrive or SharePoint. It only ever sees what that user is already allowed to see.
Draft the packet against criteria. Scout assembles a structured summary, organized to mirror the payer's medical-necessity criteria for the specific service, and lines up the supporting evidence next to each requirement.
Flag gaps and questions. Crucially, it surfaces what is missing up front — an absent result, an unsigned note, an unanswered clinical question. The expensive "discovered late" moment moves to the very beginning, where it is cheap to fix.
Human review and edit (checkpoint). The coordinator or clinician opens a ready draft rather than a blank page. They verify every linked source, correct anything off, and resolve the flagged gaps. This is the human-in-the-loop checkpoint, and it is non-negotiable.
Approve and submit. The person — not the agent — makes the final call and submits in the payer portal. Scout prepared; the human decided.

The same standards are met, but the assembly that used to consume the morning is done before review begins.

The shape of the win is visible in the comparison: the standards do not move, but the order changes. Gaps are caught first, the human starts from a review-ready draft, and the rote assembly happens off the critical path.

Governance and compliance

None of this is adoptable unless it is safe, so the controls are the feature. Scout operates within your existing identity and permissions — it acts as the signed-in user and inherits exactly their access, no more. Microsoft Purview sensitivity labels travel with content, so classified material keeps its protections as it moves through the workflow and is not written out to unprotected destinations. Consequential actions — submitting, sending, finalizing — wait for explicit human approval. And because Scout shows its steps and the sources it touched, you get an audit-friendly trail of what was assembled, from where, and who approved it. In a setting where "show your work" is a compliance requirement, that visibility is as valuable as the speed.

How to start this week

You do not need a transformation program to begin. Pick one payer and one common service line with well-understood criteria. Confirm which sources are already permitted and which exports or connectors are available. Have Scout assemble draft packets for a handful of cases, and ask your coordinators to do what they always do — review and decide — while noting where the draft saved time and where it needed correction. Keep the human checkpoint firmly in place, and let the evidence from one narrow workflow make the case for the next.

Deep dive 2: Field medical pre-engagement briefs

The business problem, and what it costs today

In medical affairs, the quality of a field medical engagement often comes down to preparation. Before a meeting with a healthcare professional, a medical science liaison needs a clear, accurate picture: relevant background, the latest approved internal materials, prior interactions, and the open scientific questions worth exploring. Pulling that together is time-consuming, and when calendars are full it is the part that gets compressed — which means well-qualified experts sometimes walk in less prepared than they would like. The cost is a softer one: engagements that are good when they could be excellent, and institutional knowledge that lives in individual inboxes rather than in a repeatable process.

The manual process today

Today an MSL typically prepares by hand: scanning email and notes from previous interactions, hunting for the most current approved materials, checking the calendar for context, and drafting their own talking points. Done well it is excellent; done under time pressure it is uneven. And because it is manual, the standard varies from person to person and week to week.

The agentic how-to: how Microsoft Scout would do it

From a scheduled trigger through source-checked drafting to a required field-medical review before the brief is final.

Trigger ahead of the engagement. Scout runs on a schedule tied to upcoming engagements — for instance, the day before each scheduled meeting — so a draft brief is ready in advance.
Gather context from permitted sources. Under the MSL's own permissions, it draws on approved internal materials, prior interaction notes, related Outlook threads, and calendar context.
Summarize into a usable brief. Scout drafts a structured read-ahead — concise background, suggested talking points, and a short list of open scientific questions — shaped for the person to refine, not to send as-is.
Check sources. It grounds the brief in approved, permitted content and shows where each element came from, so nothing rests on an unverifiable claim.
Field medical review (checkpoint). The MSL edits and confirms accuracy. In medical affairs this review is essential — the human owns scientific accuracy and compliance, every time.
Brief ready. The reviewed read-ahead is in hand before the meeting, and the same high standard applies to every engagement, not just the ones with time to spare.

The benefit is consistency as much as speed: the floor rises, because every brief starts from a thorough, source-checked draft, and the expert's time goes to sharpening the science rather than gathering the inputs.

Governance and compliance

The same guardrails apply. Scout works within the MSL's identity and permissions; sensitivity labels stay attached to the materials it touches; the field medical review is a hard checkpoint before anything is finalized; and the trail of sources keeps the brief defensible. For regulated medical affairs work, an agent that drafts transparently and then steps back for human sign-off is precisely the right division of labor.

How to start this week

Choose one engagement type and one well-curated set of approved materials. Have Scout produce draft briefs for the next few meetings, and ask your MSLs to review and refine as they normally would. Compare the agent-drafted starting point with a blank page, and watch what happens to both preparation time and consistency across the team.

Where Cowork and Microsoft 365 Copilot fit

Scout is the star at the individual desktop, but it is part of a broader fabric. Microsoft Cowork extends agentic collaboration into the flow of teamwork, so momentum is shared rather than personal. Microsoft 365 Copilot keeps AI close to the documents, meetings, and messages where so much HLS work already lives. The practical sequence for most organizations is to start where the friction is sharpest — a recurring prep workflow like the two above — prove the model with the human firmly in control, and then extend across the team.

The throughline: do more with less, without doing less

Across both deep dives the pattern is identical. The agent does the assembling; the human does the deciding. Speed to market improves because the busywork shrinks, not because the standards do. Compliance gets easier because the agent operates inside your existing identity, permissions, and labels, and because every consequential action waits for a person. That is what makes agentic AI a fit for healthcare and life sciences specifically: it is fast and it is accountable, and in this industry you are not allowed to choose only one.

Subscribe to the Microsoft Healthcare and Life Sciences blog for weekly, practical deep dives on putting Microsoft AI to work — safely — across care, research, and commercial teams. If you mapped your own highest-friction prep workflow onto the six steps above, which step would you let an agent own first — and what evidence would you need before you trusted it with the rest?

Why AI Can't Find Your Files (And the Simple Fix)

michaelgoad — Mon, 22 Jun 2026 16:07:44 GMT

I was watching someone the other day and learned something about AI that I believe is going to be important in the future. It wasn't a flashy new model or some prompt trick. It was something way more practical: how the way we name and build our files is either going to help AI or quietly work against it.

And the more I sat with it, the more I realized this is going to matter a lot as we build for an AI-first world.

We organize files for humans, not for AI

Think about how most of us organize things today. We nest everything. A folder for 2026, then the customer, then the opportunity, and inside it a file called "Notes." Or maybe a policy and SOP folder tree that goes five levels deep with broad, generic titles.

That structure makes sense to us (humans). We navigate by memory and location. We know the file is in the customer folder, under this opportunity. That's how humans think.

But AI doesn't think like that.

Now picture that same sales folder with three or four different "Notes" files spread across different subfolders under the same customer. When you ask AI to find something in there, it's going to guess. A lot. Especially when everything is named "Notes." And the messier the structure, the worse the guessing gets.

It comes down to metadata

So here's what I learned that actually helps. It comes down to metadata.

When AI looks for a file, it isn't always reading every word of every file. It works in two levels, and once that clicked for me, the whole thing made sense.

Level one: the title

The first thing AI looks at is the title. And this is where most of us are leaving value on the table.

A file called "Customer, Opportunity, Subject" gives AI so much more to work with than a file called "Notes." Same thing on the policy side. A file named "Benefits, Parental Leave, 2026" tells AI exactly what it's looking at before it even opens it.

Compare these two:

notes.docx
acme-corp-renewal-q3-discovery-notes-2026

One of those is invisible to AI. The other one is basically answering the question before it's asked.

Level two: the top of the file

Once AI decides a file might be relevant, it starts reading it. And some of the most valuable real estate in the entire file is the very top.

If you put a short structured block at the beginning that spells out what the file is about and the topics inside it, AI immediately understands what it's looking at. Something like this:

Title: Parental Leave Policy (US)
Type: HR policy Topics: parental leave, benefits, time off
Effective date: January 1, 2026
Last reviewed: May 14, 2026
Version: 3.0 Status: active

That little block does a lot of work. It tells AI what this is, who it's for, and just as important, whether it's current.

So when I say metadata, that's really all I mean. It's the title of the file, plus a little bit of context right at the top, so that when AI scans it, it knows fast whether this is the file it actually needs.

You don't need this on every file

Now, I'm not saying do this for every file. That's overkill, and honestly it would be exhausting.

But think about the static stuff. The files that don't change much. HR policies. Benefits. SOPs. The things people search for in a ServiceNow or SharePoint knowledge base using AI.

For those files, a little structure does two things.

First, it helps AI find the right answer for the person asking. When someone types "how much parental leave do I get," the right file basically raises its hand.

Second, it cuts down the latency. If AI is sitting there scanning through a pile of vaguely named files, the user is just waiting around for it to think, and that gets annoying fast. When AI has the right context up front, it gets to the answer quicker.

Pro Tip: You can use AI to create the metadata for you, just ask it!!

Where this is headed

I keep coming back to this because it's such a small change with a real payoff.

We've spent years building file structures that make sense to people. Folders inside folders, organized by how we remember things. That's not wrong. But as more of how we find information runs through AI, the files that win are the ones that are easy for a machine to read, not just easy for a human to browse.

I don't think every file needs this. But as we get more serious about how we build file structures for an AI-first world, I think this is one of the concepts that's going to really matter.

Curious if anyone else is already thinking about this in how they build their knowledge bases. If you are, I'd love to hear how you're approaching it in the comments!

How Microsoft Scout Brings Agentic AI to Everyday Healthcare and Life Sciences Work

MichaelGannotti — Mon, 22 Jun 2026 15:36:14 GMT

Healthcare and life sciences teams are asked to do the impossible every day: deliver better outcomes, move faster, and stretch every dollar — all while navigating some of the most regulated, documentation-heavy workflows in any industry. The promise of AI has never been about replacing the experts who do this work. It’s about giving them their time back.

That promise is entering a new phase. We’re moving from AI that answers to AI that acts — agentic AI that can carry out multi-step work across your applications, your documents, and the web, with you in control. Nowhere is the opportunity more concrete than in the daily operational grind of healthcare and life sciences.

From answering to doing

Most knowledge work in HLS isn’t blocked by a lack of information — it’s blocked by the effort of pulling that information together and turning it into action. Gathering the right documents. Summarizing a thread. Drafting the first version. Updating five systems with the same three facts.

Microsoft Scout is designed for exactly this layer of work. Think of it as an agentic AI teammate on your desktop — one that can read and organize files, search across your email, calendar, and Teams, browse the web, and complete genuinely multi-step tasks on your behalf. Crucially, it can run on a schedule, so routine work happens before you sit down, and it keeps a human in the loop for anything that matters.

Real-world ways HLS teams can do more with less

Provider operations: Assemble the documentation needed for a referral or prior-authorization request, summarize the relevant history, and draft the submission — turning a 30-minute scramble into a two-minute review.
Clinical research coordination: Pull together study start-up documents, track outstanding site communications, and draft consistent follow-ups, so coordinators spend their time on sites and patients rather than inboxes.
Medical affairs and field medical: Prepare for an engagement by gathering the latest publications and prior interactions into a single brief, then capture a structured summary afterward — every meeting, consistently.
Commercial and market access: Stand up an account briefing or a competitive news roundup on a recurring schedule, so the team starts every week informed instead of researching from scratch.

The thread running through all of these is the same: reclaim capacity, increase consistency, and accelerate speed to market — doing more with the people and budget you already have.

Built for the trust HLS demands

In this industry, “helpful” is not enough; it has to be trustworthy. Agentic AI for healthcare and life sciences has to respect enterprise security and data boundaries, keep sensitive information under your control, and keep a person in command of consequential decisions. The goal is to automate the busywork around expert judgment — never to automate the judgment itself.

A family of AI that works the way you do

Scout is part of a broader shift in how Microsoft is bringing AI to work. Where Microsoft 365 Copilot brings AI into the flow of the apps you already use, and Microsoft Cowork reimagines how teams collaborate with AI, Scout focuses on agentic action at the desktop — automating end-to-end tasks and recurring workflows. Together they point to the same future: more of your day spent on the work only you can do.

Start small, compound the gains

You don’t need a transformation program to begin. Pick one repetitive, high-friction workflow — the weekly roundup, the recurring briefing, the documentation prep that nobody enjoys — and let agentic AI take the first pass. The time you reclaim funds the next idea.

We’ll be sharing practical, healthcare- and life-sciences-specific playbooks here every week. Subscribe to the blog, and tell us in the comments: what’s the one recurring task you’d hand to an AI teammate first?

Learn more about Microsoft Scout:

Build a Financial Dashboard in Copilot Cowork (Ideas Coach to Researcher to Build)

michaelgoad — Thu, 18 Jun 2026 16:51:58 GMT

I sat down with Nick Aquino, a Principal Solution Engineer at Microsoft, because he built something that stuck with me. A real, interactive financial dashboard. No code. All of it in Copilot and Cowork.

I didn't want slides. I didn't want theory. I asked him to show me exactly how he did it, step by step, so you can do the same thing.

A few takeaways below.

The problem most of us recognize

Nick gets a financial export every month. Same format, same system, same columns every time. For a while he turned that file into Excel charts and pivot tables by hand.

Then people noticed he was good at it. The CFO asked for his own view. Then the COO. Then sales. Then marketing. Pretty soon one report became five, and a monthly task turned into two full days of work. Every single month.

If you've ever become "the Excel person" on your team, you know the trap. Lots of visibility, lots of extra work.

That repetitive, well-defined task is exactly what AI is good at.

The part that changed my mind: plan in Copilot first

This is where Nick's approach got interesting. He didn't jump straight into Cowork and start building.

He thinks about it like one gallon of gas and 15 packages to deliver. What's the most efficient route? Cowork can run for 10, 30, even 60 minutes on a single prompt, and there's a cost to that. So he does the thinking in Copilot first, using the built-in agents, then hands a tight, finished plan to Cowork.

His workflow looks like this:

Ideas Coach. He uploads the financial file and asks for dashboard ideas that would matter to a finance org. A CFO, a financial analyst, that kind of audience. Nick's a solution engineer, not a finance person, so he lets the agent fill the domain gap. Context matters, so he gives it the actual file instead of just describing it.
Prompt Coach. He takes those ideas into Prompt Coach and asks it to build a strong prompt he can actually run.
Researcher. This is the step that does the heavy lifting. He runs that prompt in Researcher, uploads the file again, and gets back an application requirements document. A real spec built around his ideas and his data.
Cowork. Now he feeds Cowork the requirements and the file. It reads the spec, reads the data, and builds the dashboard as a single-page HTML file.

The prompt Researcher produced followed a clean structure: goal, context, source, expectations. Single-page HTML. Client-side libraries from a CDN. No external calls. A file picker and a loaded-file summary in the interface. That's a prompt Nick says he'd never write from scratch. The agents wrote it for him.

The bonus that made me laugh

After the dashboard was done, Nick asked Cowork for one more thing. A click-through walkthrough to teach someone how to use the tool, because he'd be presenting it to the C-suite.

Cowork built the walkthrough. With real screenshots of the process. Choose your file, load it, here's your dashboard.

The funny part: the screenshots came back styled like a Mac. Small detail, but it tells you the model grabbed real screen captures to document the steps.

Why "Copilot first" actually matters

This is the line organizations need to hear. Cowork is powerful, and that power has a cost, especially once teams start building with it at scale.

Doing the ideation, prompting, and planning inside Copilot uses the agents that come with the license you already have. You save the expensive build time in Cowork for the build itself. Nick compares it to hiring an architect before you call the contractors. Get the plan right up front so you're not paying to fix mistakes later.

Same idea applies to scope. Crawl, walk, run. If your dashboard will eventually connect to a financial system, don't start with the integration. Start with the export you already get. Build the dashboard on that, prove it's useful, then take it to your IT team and talk about a real connection. You learn fast and you don't burn a build on the wrong approach.

Sharing it

A few people asked about getting an HTML file into something easier to send. Nick's take: ask Copilot first.

Upload the HTML to the PowerPoint agent and ask it to convert. It gets close to the original. If it's a flat, scroll-through page, print it to PDF. Pick the output that fits how the thing was built.

The bigger shift

Here's what I keep coming back to. Developers are still important. None of this replaces the back end or real engineering.

But a business leader with an idea can now build the front end. The UI, the experience, the demo. That's maybe 60% of the way there. Then you hand it to IT and developers and say, "this is the idea, here's the working interface, help me make it real."

That changes who gets to start. More people can turn an idea into something you can actually see and react to. And that moves the business forward faster.

Thanks to Nick for showing his work. If you build something with this, I want to see it.

Copilot Cowork is GA - Here's how to track your credit usage as an end user

michaelgoad — Wed, 17 Jun 2026 15:42:28 GMT

Now that Copilot Cowork is generally available, a lot of us in Healthcare & Life Sciences are putting it to work — drafting summaries, running research prompts, moving through tasks faster than ever. But with GA comes something worth paying attention to: Cowork now runs on billing and credit usage. And if you're not keeping an eye on that, it's easy to burn through credits without realizing it.

Here's the good news: you don't need to dig through settings or a billing portal to check (as an end user). There's a command built right into Cowork.

The trick: /cost

I actually picked this up from a peer this morning, and it's about as simple as it gets:

Open your Copilot Cowork session — one you've already been working in.
Go down to the prompt box at the very bottom.
Type /cost and hit enter.

That's it. Cowork instantly shows you the credit usage for that task, right inline. No extra clicks, no leaving your workflow.

Why monitoring can matter

In healthcare, we're mindful of how we use every resource — and AI consumption is no different. As teams lean on Cowork for more of their day-to-day, a quick credit check helps you:

Stay aware of what a given task actually costs.
Budget intentionally across sessions and projects.
Have the data when someone asks, "How are we using this?"

A 10-second habit now saves you from surprises later.

One honest heads-up

A heads up: a few of my peers haven't gotten /cost to work just yet, so your mileage may vary. In the cases I've used it, though, it's been reliable. If it doesn't show for you right away, you're not doing anything wrong — the feature is still rolling out.

Try it

Next time you're in Copilot Cowork, drop a /cost at the bottom of your session and see your credit usage for yourself. It's the fastest way to stay on top of consumption across your different sessions.

Give it a shot — and let me know if it works on your end.

Go push some buttons. 🚀

DLP for Copilot Prompts: How to Stop Sensitive Data From Leaving Your Tenant

michaelgoad — Fri, 12 Jun 2026 21:15:24 GMT

Picture this. A user types something sensitive into Copilot. Now you're left wondering what happens to it, how to prevent it from going out, and what to do after the fact.

That's a conversation I have with customers a lot. How do you get proactive about securing what goes into Copilot and stop sensitive information from going out, instead of just cleaning up after it happens.

Copilot's web grounding sends prompts out to Bing Search when it needs more context to answer a question. That's useful. It's also the problem, because once a prompt crosses your tenant boundary to Bing, it sits outside the privacy and security terms in your Microsoft agreements.

For a while, the fix was to turn off web grounding entirely. That closed the gap but left users with a weaker Copilot.

Microsoft's answer was to extend Purview's data loss prevention into Copilot prompts, giving IT teams the proactive controls they've been asking for. I talked through this with Arlie, one of our Purview solutions engineers and a former CISO, and walked through how it works.

I sar down with Principal Solution Engineer Arlie Hartman to talk about DLP for Copilot Prompts

Two ways to block a prompt

The first version Microsoft shipped stops Copilot from processing a prompt at all. If the prompt matches a DLP rule, conditioned on a sensitive information type or a custom keyword list, the user gets a flat response: "This request cannot be completed because your organization has blocked Copilot from processing or responding."

That worked, but customers wanted more. They wanted Copilot to keep reasoning and responding using its existing knowledge and whatever's already in the tenant's Microsoft Graph data, just without invoking a web search. So Microsoft added a second action: block web grounding only. Copilot still answers, but tells the user it can't use web search because of the org's security policy.

Building the policy

You build this as a DLP policy in Purview, scoped to the Microsoft 365 Copilot and Copilot Chat workload, then scoped to users or groups. Inside the policy, you create rules made of a condition and an action: if the prompt contains a sensitive information type, a custom keyword list, or matches a sensitivity label, then either block the prompt or block web search.

One catch worth knowing up front: each rule can only take one of those two actions, and you can't combine a sensitivity label condition with a sensitive information type condition in the same rule. If you want both, build two policies. Arlie splits these out: one policy for keyword-based blocking, one for sensitivity-label-based web search restriction.

Sensitivity labels add another layer. Tag a document "Highly Confidential" and you can stop Copilot from touching it at all, or let it summarize and reformat that document but never let it trigger a web search from that content.

What you can see in the logs

With the full Purview suite, every Copilot interaction lands in Activity Explorer under AI activity. You can see the prompt, the matched rule, the confidence score, and whether it got blocked or just flagged. Filter by policy and date range to see how a rule is performing.

That's where simulation mode comes in. Before turning a rule on for real, run it in simulation for a week or so. You'll get the DLP violation logged without blocking anything for the user. Tune the rule until you're catching real violations without burying your admins in false positives.

Licensing

DLP for Copilot prompts requires Information Protection and Governance, one of the mini-SKUs that make up the Purview suite under E5. E3 won't get you there.

One policy covers both Copilot Chat and full Microsoft 365 Copilot. Roll out Copilot Chat broadly on E5 but only license some users for full Copilot, and the DLP policy still applies to everyone, regardless of which Copilot license they're on.

Where this fits

Most security around AI tools has been reactive: something goes out, you audit it, you coach the user after the fact. This gives IT teams a way to balance user ability with protection of the organization, stopping sensitive data from leaving in plain text before it happens, while users still get value from Copilot.

If you're on E5 and haven't looked at this, set up one policy in simulation mode this week and see what you're working with.

What We Took Away from Build 2026 as Microsoft Field and Solution Engineers

michaelgoad — Wed, 10 Jun 2026 22:10:54 GMT

I pulled together four Microsoft Solution Engineers for a candid conversation about Build 2026, and I want to be upfront about what this is. No keynote recap, no announcement list. Four people who work with healthcare and enterprise customers every day, talking about what caught our attention and why.

I was joined by Arlie Hartman, a former CISO and now Principal SE with deep expertise in Purview and security; Thor Draper Jr., Senior Security SE covering security and identity; and Adam Hallbeck, a Principle Power Platform Copilot SE. Between the four of us we cover a pretty wide slice of the Microsoft field.

What we actually talked about

Microsoft Scout was one of the first things we got into. It's still frontier private preview, but I've been using it and it's already changing how I work. I had it reach out to Arlie on my behalf to schedule time, monitor his response, and book the meeting when he replied. It worked. That shift from "AI you type at" to "AI that does things while you're doing other things" is real, and Scout is one of the clearest examples of it right now.

Agent 365 got a lot of our attention too, especially the identity piece. Thor made a point that stuck with me: organizations are spinning up agents faster than they can track them. One customer had 1,400 agents and no clear picture of what any of them had access to. Agent 365 gives you sponsors, owners, and governance controls that map to how IT teams already manage people and service accounts. The mental model isn't new, the application to agents is.

Adam talked through Work IQ APIs and where that's heading, including how much easier it's getting to give agents access to organizational knowledge without having to wire up every tool individually. Arlie covered the Purview SDK changes in Foundry, which are a big deal for regulated industries because it moves the security configuration responsibility off developers and back to governance teams where it belongs. Thor walked through M-Dash and what a real DevSecOps process looks like when agents are doing the reconnaissance and triage work.

We also talked about Microsoft's in-house model lineup and what it means as models start to get treated more like infrastructure than differentiators. Copilot routing the right prompt to the right model quietly does a lot of work that most users never see.

The takeaway from our side of the field

Build 2026 felt different from where I sit. A year ago we were talking about what agents could do. Now we're talking about how to govern the ones already running. The product is catching up to the conversations we've been having with customers, and that matters a lot in healthcare where "we'll figure out governance later" isn't an option.

Watch the full conversation above. I'd love to hear what questions it surfaces for your organization.

A new chapter of efficient foundation models for medical imaging

ivantarapov — Wed, 24 Jun 2026 21:34:29 GMT

Authors: Ivan Tarapov, Naiteek Sangani, Mu Wei, Noel Codella, Mert Oez and Naveen Valluri, Microsoft Healthcare and Life Sciences

At HLTH 2024, we introduced three open-source healthcare AI foundation models on Microsoft Foundry: MedImageInsight (MI2), CxrReportGen (CXRRG), and MedImageParse (MIP). They quickly became the most popular healthcare industry models in the Foundry catalog, with consistent, growing usage by researchers, ISVs, and clinical teams over more than 15 months. Customer momentum has been real:

SECTRA has explored integrating MedImageInsight for real-time exam parameter determination.
University of Wisconsin is exploring the use of CxrReportGen to automate normal-case triage, focusing radiologists on complex work.
University of Washington fine-tuned MedImageInsight for brain tumor typing and localization from multi-sequence brain MRI scans.
Milvue is fine-tuning CxrReportGen to extend its capabilities into musculoskeletal pathologies and image-based reporting.

Early experimentation with these models across different scenarios provided clear signals on where customers needed more support. Across these efforts, four themes consistently emerged:

“We don’t want to manage our own VMs.” Radiology IT or ML platform teams don’t want to manage GPU infrastructure for provisioning and scaling.
“We want to pay for what we use.” Idle GPUs are a tax. Customers want elastic endpoints that scale with workload.
“We need enterprise-ready endpoints.” Production deployments require HIPAA coverage, BAAs, SLAs, managed security, and a pathway to integration into the surfaces clinicians already use — PowerScribe, PowerShare Image Sharing, and PACS.
“We want a simplified fine-tuning process.” Foundation models require fine-tuning for integration into clinical workflows. Fine-tuning needs to be fast, efficient, and easy to perform.

We set out to address these priorities to make it easier for customers to experiment, evaluate, and build on these models.

Introducing healthcare AI premium models

Microsoft now offers premium versions of its medical imaging foundation models on Foundry, available today as a private preview to approved customers. The trusted core architecture has been further optimized and enhanced, with frequent updates using larger, curated datasets and the models are delivered as fully managed endpoints. With the introduction of these premium models, we are committing to maintaining state-of-the-art performance across a broad range of medical image processing tasks.

Premium models on Foundry are designed for teams aiming to build medical imaging AI - including developers, ISVs, and enterprise health systems standardizing on managed AI endpoints within their Azure environments. They provide a strong starting point for researchers and advanced practitioners who want to experiment and extend capabilities without requiring access to large, specialized datasets.

These models are not medical devices and are not intended for out-of-the-box clinical use or autonomous clinical decision-making. Instead, they are designed to be fine-tuned, validated, and deployed within customer-controlled workflows, with appropriate human oversight and regulatory processes applied by the implementing organization.

Unlike the open-weight versions of the models which run on a dedicated virtual machine hosted in customer subscription, the premium models are available as “managed endpoints” (also known as “serverless models“) where the models are hosted on Microsoft-owned infrastructure. Customers benefit from a more flexible, “pay-as-you-go” billing model with charges based on images processed rather than per hour of VM uptime.

These first premium models - MedImageInsight Premium and CxrReportGen Premium bring managed, commercial-ready delivery to two high-value imaging scenarios: multimodal image encoding and chest X-ray findings generation.

MedImageInsight Premium: a multimodal embedding model for medical imaging

MedImageInsight Premium builds on the open-source version with up to 16% performance gains on imaging benchmarks. It’s a single general-purpose embedding backbone across nine modalities including X-ray, CT, MRI, ultrasound, pathology, dermoscopy, OCT, fundus photography, and mammography, that powers:

Image quality analysis and study routing
Image-to-image similarity search
Zero-shot and fine-tuned classification
Metadata extraction and outlier detection
Downstream report generation (as an encoder)

How does it compare to other similar models?

The table below summarizes results from a published comparison of radiographic classification performance across several foundation-model backbones. In the benchmarks shown, MedImageInsight Premium achieves the highest reported mAUC among the models listed, supporting its use as a general-purpose imaging representation for downstream classification and fine-tuning workflows.

	MedImageInsight Premium	MedImageInsight OSS	MedSigLip
LTCXR (Chest Xray mAUC)	0.83	0.79	0.74
IRMA2009 (X-ray Exam Params)	0.94	0.92	0.90
BUSI (Breast Cancer Ultrasound mAUC)	0.98	0.97	0.93
HMCQU (Echocardiography view mAUC)	0.97	0.97	0.86
PCAM (Histopathology mAUC)	0.95	0.94	0.93
RSNAMAMM (Mammography AUC)	0.86	0.84	0.77
Gastrovision (Endoscopy (GI) AUC)	0.92	0.89	0.89

Why it matters: a stronger embedding space can help reduce the amount of labeled examples needed for downstream tasks, lower fine-tuning cost, and support faster iteration during model evaluation and application development.

For more details about datasets and benchmarking methodology please refer to our MedImageInsight paper.

CxrReportGen Premium: chest X-ray findings generation

CxrReportGen Premium generates a structured list of findings for chest X-rays. It accepts current and prior studies plus clinical context such as indication, technique, and comparison and can run inference in well under a second. It offers best-in-class performance and a solid foundation for production workloads.

In Microsoft testing on a proprietary real-world dataset, CxrReportGen Premium showed an approximately 330% performance increase compared to the open-weight version. Results may vary by dataset, workflow, and evaluation approach, so teams should validate performance using their own data and clinical requirements.

Findings generation on MIMIC-CXR dataset:

	CXRReportGen Premium	CXRReportGen OSS
1/RadCliq-v1	1.26	1.34
BLEU-2	0.27	0.31
BERTScore	0.47	0.50
SembScore	0.50	0.50
RadGraph	0.31	0.31

Findings generation on proprietary real-world dataset

	CXRReportGen Premium	CXRReportGen OSS
1/RadCliq-v1	2.74	0.83
BLEU-2	0.38	0.16
BERTScore	0.57	0.37
SembScore	0.60	0.43
RadGraph	0.43	0.18

“Milvue is building a radiology-native VLM. By working with Microsoft and leveraging CXRReportGen, we could start from a strong foundation allowing our team to focus on what matters most: turning foundation-model capability into clinically validated, workflow-ready radiology solutions.”

— Alexandre Parpaleix, Co-Founder/CEO, Milvue (milvue.com)

How does it compare to other similar models?

The comparison below highlights how CxrReportGen Premium differs from open-source and publicly available chest X-ray reporting approaches across availability, output style, grounding, training data, and benchmark context.

Model	Availability	Output Style	Grounded Reporting	Key Training Data	Benchmark Performance
CXRReportGen Premium	Internal (closed)	Findings ± Impression	Yes	MIMIC-CXR + proprietary	Internal only: 1/RadCliQ↑ 1.88; RadGraph F1↑ 0.36
CXRReportGen (open)	Public (MIT)	Grounded findings	Yes	MIMIC-CXR + proprietary	MIMIC-CXR: RadGraph F1↑ 1.34; ROUGE-L↑ 39.1
UniRG-CXR	Public (research)	Findings ± Impression	No	ReXrank datasets	RexRank family: RadGraph F1↑ ~0.26–0.40
MAIRA-2	Public (research)	Findings ± Impression	Yes	CXR reporting data + prior/context inputs	ReXrank family: RadGraph F1↑ ~0.13–0.23
CXR-RePaiR	Public (MIT)	Free-text retrieval	No	MIMIC-CXR corpus; CheXpert eval	External CheXpert: F1↑ 0.352
R2Gen	Public	Free-text reports	No	IU X-Ray + MIMIC-CXR	External CheXpert: F1↑ 0.191
CvT2DistilGPT2	Public (GPL-3.0)	Free-text reports	No	MIMIC-CXR + IU X-Ray	ReXrank family: RadGraph F1↑ ~0.10–0.27
MedGemma	Public	Findings / report-like	No / mixed	Broad medical multimodal data	ReXrank family: RadGraph F1↑ ~0.14–0.27

Benchmarks cited here are not apples-to-apples comparisons. “Internal / Proprietary Performance” reflects Microsoft internal or proprietary evaluations for CXRReportGen Premium/open CXRReportGen. “Public Benchmark Performance” reflects the best headline metric explicitly reported in the public benchmark family cited for each model (for example, MIMIC-CXR card metrics, CheXpert clinical-efficacy metrics, or ReXrank-style RadGraph results). Metric families represented here include composite quality metrics such as 1/RadCliQ, clinical structure metrics such as RadGraph F1, and lexical metrics such as ROUGE-L

For more details on model architecture, datasets and evaluation methodology, please refer to our technical paper.

Building our premium healthcare AI models

The premium models achieve a different performance checkpoint trained on a materially larger, curated, clinically-vetted data mix and are designed for an ongoing training cadence. Key details developers typically ask about include:

Curated, licensed data mix. Expanded coverage across modalities and underrepresented pathologies, with particular attention to dataset provenance, patient de-identification, and license compatibility with commercial deployment.
Architecture-compatible. Same embedding dimensionality for MedImageInsight and same input/output contract for CxrReportGen, so code written against the OSS endpoints can move over with minimal changes.
Fine-tuning friendly. Stronger base representations can help reduce the amount of data needed and thus support more efficient fine-tuning and adapter-based specialization.
Managed inference. Packaged and deployed on Azure ML managed endpoints with elastic autoscaling, using A100-class GPUs.

Responsible AI

Every premium model has gone through Microsoft’s Responsible AI review, and Data Science Board review — the same internal gates that govern our 1P healthcare AI surfaces. Each model ships with a detailed model card covering intended use, out-of-scope use, dataset provenance, known limitations, subgroup performance, and evaluation methodology. These models are not medical devices and are not cleared for autonomous clinical decision-making. They are designed to be fine-tuned, validated, and deployed by customers into their own clinical workflows, with Microsoft supporting partners through SaMD submission paths where applicable.

Managed Security

Managed endpoints in Foundry act as a secure, policy-enforced gateway to model execution rather than direct access to underlying models. Every request to an endpoint is authenticated and authorized through Microsoft Entra ID or scoped API credentials so that only approved users and services can invoke specific deployments. Endpoints can be isolated within private networks and exposed through controlled access paths to control unintended public exposure. All data is encrypted in transit using TLS and protected at rest within Azure, while built-in controls such as content filtering, rate limiting, and activity logging provide continuous governance and auditability. As Azure resources, these endpoints inherit enterprise-grade security, compliance, and monitoring capabilities - helping ensure that model access remains tightly controlled, observable, and aligned with organizational policies.

Open source vs premium at a glance

The driving force behind premium models is enabling teams to deploy solutions faster, with less overhead. For many teams, the biggest gain isn’t just in model quality - it’s in how these capabilities are delivered and supported in production. Premium models are designed to remove the operational burden of managing infrastructure while giving organizations the flexibility, commercial terms, and integrations they need to move from experimentation to deployment.

Fully managed endpoints. No GPU VMs to provision, patch, or scale. Elastic by default.
Pay for what you use. Usage-based inference pricing helps reduce idle GPU costs by charging for model usage rather than continuously running self-managed infrastructure
Integrated where you work. Designed to plug into PowerScribe via Dragon Copilot for radiology
Improved performance. Unlike the open-source models, the premium models achieve a different performance checkpoint trained on a materially larger, curated, clinically-vetted data mix and are designed for an ongoing training cadence.

	Open source (2024)	Premium (2026)
Benchmark performance	SOTA baseline at release	+7–15% on imaging benchmarks
License	Research / academic only	Commercial use
Deployment	Self-managed GPU VMs	Fully managed Microsoft Foundry endpoints
Pricing	Compute you provision	Per-hour inferencing — pay for what you use
Scaling	Customer-managed	Autoscale, elastic from zero
Fine-tuning	DIY via Azure Machine Learning	Native Foundry UX

Comparing costs

From a cost perspective, the tradeoff between managed endpoints and self-managed infrastructure depends on the workload.

Customers incur a fixed cost for a self-managed endpoint regardless of how many images processed. With serverless models the costs are incurred only when images are processed by the models.

As a general guideline, self-managed endpoints may become more cost-effective at higher sustained throughput, while managed endpoints can be more cost-efficient for lower or variable workloads, especially when operational overhead for GPU infrastructure is included. The exact break-even point depends on model choice, endpoint configuration, utilization pattern, and current pricing. With launch private preview pricing self-managed endpoints break even with managed endpoints at approximately 6,000 images/hour for MedImageInsight and 1,500 images/hour for CxrReportGen.

Getting started

MedImageInsight Premium and CXRReportGen Premium are available in a limited preview. To request access, use the links below:

MedImageInsight Premium: https://aka.ms/hls/mi2premium
CxrReportGen Premium: https://aka.ms/hls/cxrrgpremium

To learn more about premium models as well as other models for healthcare and life sciences in the Foundry catalog, as well as review additional resources, take a look at our project page.

Premium models are one part of a broader shift in how healthcare organizations adopt and operationalize AI. For a wider industry perspective on how these capabilities are shaping healthcare delivery, read more in our latest industry blog.

Modernizing radiology reporting—without disrupting care: A practical path to PowerScribe One

Jeanne_Nauman — Tue, 09 Jun 2026 16:00:00 GMT

With growing imaging volumes, increasing complexity, and the rapid emergence of AI, healthcare organizations are reevaluating how their reporting environments support clinicians and strengthen operational performance. They are faced with how to modernize without interrupting the work that matters most. We developed our PowerScribe One solution and implementation approach with that reality in mind.

In active production across a wide range of healthcare environments (including large integrated delivery networks, academic medical centers, independent radiology practices, and community hospitals), PowerScribe One reflects a solution that is both proven in practice and designed for what comes next. Over 250 organizations and 10,000+ radiologists use PowerScribe One to generate millions of reports each month.

This scale is significant; it’s validation of what we bring through our solution and support. It reflects a system and team tested across diverse environments, integration landscapes, and operational models, performing reliably in real-world conditions. Combining the strength of our solutions with an experienced Microsoft team, we deliver a seamless implementation that minimizes disruption.

Redefining the migration experience

As I’ve worked with customers modernizing their reporting environments, I’ve noticed a consistent pattern of concern: how to modernize without disrupting the workflows teams rely on or the care they deliver.

In my experience, even when a solution offers meaningful capabilities, customers still worry about the potential downsides of a prolonged migration. I understand that perspective. Many have worked with vendors who promise a “lift-and-shift” implementation but fall short of that expectation.

Migrations can introduce real challenges, including downtime, retraining, and workflow disruption. Over time, we’ve seen that successful transformation is driven not only by the strength of the technology, but also by how effectively the transition is managed.

With years of experience supporting PowerScribe environments, we’ve taken those insights and applied them to our approach. We defined what a successful PowerScribe One implementation looks like and developed a migration model designed to reduce risk while supporting adoption.

Rather than viewing migration as a single milestone, PowerScribe One transitions are designed as a structured journey with clearly defined phases and timing:

Discovery: Align on goals, workflows, and integration requirements
Build: Preparing the technical and operational foundation
Testing: Validating workflows end to end and addressing issues proactively
Production: Supporting go-live with a focus on stability and adoption

Each phase includes checkpoints and shared accountability to increase transparency and reduce uncertainty. Our Microsoft team works closely with our customers to build a project timeline that fits their needs while existing PowerScribe 360 workflows and content are leveraged, eliminating the need to rebuild from scratch.

I’d also like to highlight at the center of this migration model is a parallel transition strategy. We enable PowerScribe 360 and PowerScribe One to operate side-by-side during our customer’s migration period.

This approach provides organizations with the flexibility to:

Introduce PowerScribe One to early adopters
Validate workflows and integrations in a live environment
Phase adoption across teams
Maintain continuity throughout the transition

In this measured approach, our customers can move forward with confidence, ensuring that systems, workflows, and teams are ready for successful adoption. The result is a model that is both repeatable and adaptable, capable of supporting organizations with varying levels of complexity. Our efforts to center our implementation process on the customer experience shows how migration work is not simply a technical capability proposition. This focus reflects our broader philosophy: transformation should be deliberate, not disruptive.

From implementation to enablement

Minimizing disruption doesn’t end with implementation. It extends into how teams are supported, trained, and enabled in their day-to-day workflows. Our focus on enablement is especially important in radiology, where even small workflow disruptions can have outsized impacts on productivity and the radiologist experience.

With PowerScribe One, organizations not only gain access to a modern reporting solution but also support from teams with deep experience in radiology workflows, integrations, and large-scale deployments.

With that in mind, I’ve seen firsthand how the healthcare landscape has radically changed over the last six years. Our customers tell us how workforce shifts in radiology means they are adapting their staffing models and workflows to include telework. With these changes in the workforce, organizations benefit from training and support models that are flexible, digital, and accessible remotely.

We made live expert access (known to our customers as “drop-in help”) easily accessible through a simple QR code. It can be an ad hoc or scheduled engagement which ensures the offering aligns with a radiologist’s schedule. The feedback on this level of access we’ve received has been extremely positive and is resonating strongly with customers. I know that for any healthcare solution deployment to be successful, it requires a learning and support model that aligns with clinical schedules and operational realities.

Modernizing radiology reporting is both a technical and operational effort with its success depending on advancing capability without disrupting clinical continuity. The transition to PowerScribe One shows this balance is achievable through phased adoption, low-disruption deployment, and strong user readiness.

Organizations can modernize without affecting day-to-day care delivery with our structured approach, proven expertise and a focus on provider experience and patient outcomes.

If you want to learn more about our approach or PowerScribe One, I’ll be at SIIM26, June 10-12, please stop by the Microsoft booth at 630-632.

You can also discover how we partner with our customers why they decided to move to PowerScribe One by reading our Industry Blog.

Driving AI-Powered Healthcare: Advanced Analytics, AI, and Real-World Impact Workshop

CamilleWhicker — Thu, 04 Jun 2026 14:57:17 GMT

What We Covered

The evolving role of data in becoming a frontier AI organization
The modern data estate and how Microsoft Fabric unifies analytics
Architecture patterns for healthcare data platforms
Real-world healthcare and life sciences use cases driving impact
Building unified data foundations in Microsoft Fabric
Applying governance and security best practices
Activating data with AI and agent-based solutions

Key Takeaways

Unified data is foundational to scaling AI effectively
Microsoft Fabric simplifies the analytics stack and accelerates time to value
Governance and security must be built-in, not added later
AI-powered agents unlock new ways to operationalize data across clinical and business workflows
Hands-on experience is critical to moving from concept to deployment

Session Content and Resources

Workshop materials linked at the bottom of this post.

Becoming a Frontier Firm The State of Data & AI
The Modern Data Estate Inside Microsoft Fabric
Unified Data Foundation for Analytics Fabric as the Unifying Layer
Unlocking AI Securely Data Protection & Governance
Unified Data Foundation for AI Activating Data with Agents

What’s Next

If you’re looking to continue the momentum:

View our upcoming healthcare focused Data & AI workshops & webinars
Set up your free Microsoft Fabric trial:
Get started with SQL Fabric
Create a Data Agent
Discuss with your Microsoft partner
Join our upcoming virtual RTI Hands-on Lab June 11

Build Less. Deliver More. A lesson I learned building AI apps and workflows #Cowork

michaelgoad — Fri, 29 May 2026 21:03:42 GMT

I want to share something that happened recently, because I think it can be relatable.

A while back I built out a meta prompt for my weekly manager 1:1. If you've seen it, you know I put real thought into it. It scans my interactions across accounts, pulls out what matters, and turns it into a structured update I can walk into a meeting with. I was proud of that build, and honestly I still use a lot of it.

But then I decided to take it further.

I added a full briefing package to the workflow. An executive summary PowerPoint. An HTML web app covering four key areas. The whole thing automated and emailed out an hour before the meeting. I tested it, it ran clean, and I thought my manager was going to love it.

I asked him if he saw the email with the web app and he said he didn't see it yet, it got lost in his Outlook.

When he opened it and we went over it at the end of the meeting he said, "Hey, those four bullet points you sent me in Teams earlier? That's all I needed for this conversation."

That stung a little. But it was honestly some of the most useful feedback I've gotten.

The overbuild trap

Here's the thing about building with AI tools like Microsoft Copilot and Copilot Cowork. They make it fast and easy to create things we genuinely couldn't build on our own before. A PowerPoint in seconds. A web app from a prompt. An automated workflow that runs on a schedule. It's impressive, and it feels productive.

But fast and easy also means it's easy to build more than anyone actually needs.

I built for the output. I should have built for the person.

My manager didn't need a web app. He needed four clear points to drive a ten-minute conversation. The moment I understood that, the whole workflow got simpler, faster, and more useful.

Why this matters beyond just workflow design

As AI moves toward a consumption model, this lesson has a real cost attached to it. Every output your AI generates uses tokens. Every document it creates, every summary it writes, every email it sends — that's compute running in the background. If you're generating things nobody reads, you're spending budget on noise.

Knowing your audience isn't just good design practice. It's cost management.

Before you build, ask one question: what does this person actually need to do their job? Start there. Build that. If they need more, they'll tell you.

What I do now

My 1:1 workflow now does one thing. It looks through the past week, finds what matters across my accounts, and outputs four bullet points. That's what drives the conversation. No PowerPoint. No web app. Just the information my manager needs, in the format he'll actually use.

It took less time to build, costs fewer tokens to run, and works better than everything I built before it.

Build less. Deliver more.

Operationalizing AI powered medical imaging pipeline for cohort building

jaerwin — Thu, 28 May 2026 21:07:59 GMT

Authors:

Jared Erwin, Senior Software Engineer, HLS Nursing AI and Data Platform, Faculty UW School of Medicine
Manoj Kumar, Director, HLS - Data & AI HLS Frontiers AI
Alberto Santamaria-Pang, Principal Applied Data Scientist, HLS Frontiers AI and Adjunct Faculty, Johns Hopkins Medicine

Overview

In Part 1, of this series, we showed how natural language could be used to define medical imaging cohorts and retrieve relevant studies in seconds instead of months. That proof-of-concept demonstrated the value of the idea — but not how to make it repeatable, or production-ready.

This post focuses on how we turned that prototype into a production-oriented Azure Machine Learning pipeline — to scale execution and produce clear, versioned artifacts that could drive an interactive cohort exploration UI.

If you're building ML pipelines for medical imaging, or any domain where data is large, messy, and locked behind access controls, we hope our experience saves you time.

From scripts to a pipeline: Why Azure ML components?

The original hackathon implementation consisted of notebooks and scripts that required careful manual execution. To make the system repeatable and auditable, we standardized it using Azure ML pipelines.

Azure ML pipelines gave us:

Componentized execution — each processing step is a self-contained unit with defined inputs, outputs, and dependencies
Parallel branches — steps that don't depend on each other run concurrently
Reproducibility — every run is versioned and logged with full lineage
Compute flexibility — run on CPU for metadata extraction, GPU for model inference, without manual orchestration

The pipeline architecture

The pipeline consists of 5 python components arranged in a DAG with two parallel branches:

[0]scans a DICOM directory and extracts metadata from headers — study/series UIDs, modality, body part, slice counts.
[1]classifies each series by anatomy and orientation using a multi-tier strategy (more on this below).
[2] and [3] form the search pipeline: anatomy labels are converted to natural language text templates, then encoded with BiomedCLIP into a FAISS vector index.
[4]generates 2D UMAP coordinates from the embeddings for the interactive scatter plot visualization in the UI.

The image depicts a flowchart detailing the process of DICOM metadata extraction, anatomy classification, visualization enrichment, and text template generation, followed by the creation of a FAISS vector index.

Components 2 and 4 run in parallel after component 1 completes, saving roughly 10-15% of total execution time. It's a modest gain for a single run, but it adds up when iterating on pipeline parameters.

[1] Anatomy classification, integrating MedImageInsight

The Anatomy classification component in the pipeline relies on MedImageInsight (MI2). MedImageInsight is Microsoft's foundation model for medical image understanding, available through the Azure AI Foundry model catalog. Unlike generative models, MedImageInsight is an embedding model — it maps medical images and text into a shared 1024-dimensional vector space, enabling tasks like classification and similarity search by comparing image embeddings against text label embeddings.

Given a DICOM image, we compare its embedding against candidate labels (e.g., "Brain", "Chest", "Abdomen") to determine the body part, scan orientation, and other imaging characteristics through zero-shot classification.

We also may get directly annotated anatomy from component 0, the DICOM metadata extractor component. We can combine both data points to build our final search index.

[2] [3] FAISS index construction

As an input to the FAISS index, we first run component 2, the text template generator. This component takes the metadata and anatomy information from components 0 and 1 and feeds them into 5 different agents with different instructions on how to describe the DICOM study. This results in textual descriptions which some variation, referred to as text templates, which can be indexed in the next component

The FAISS index builder (component 3) uses BiomedCLIP to encode all text templates into 512-dimensional vectors:

MODEL_NAME = "hf-hub:microsoft/BiomedCLIP-PubMedBERT_256-vit_base_patch16_224" @torch.no_grad() def encode(self, texts: List[str], batch_size: int = 256) -> np.ndarray: embeddings = [] for i in range(0, len(texts), batch_size): batch = texts[i:i+batch_size] tokens = self.tokenizer(batch).to(self.device) batch_embeddings = self.model.encode_text(tokens) batch_embeddings = F.normalize(batch_embeddings, dim=-1) # L2 normalize embeddings.append(batch_embeddings.cpu().numpy()) return np.vstack(embeddings)

We L2-normalize all vectors and use faiss.IndexFlatIP (inner product), which is equivalent to cosine similarity on normalized vectors. For our current dataset sizes (thousands of series), flat indexing is fast enough. For hospital-scale datasets with millions of images, we might switch to IndexIVFFlat or IndexHNSW for approximate nearest neighbor search.

In the cohort explorer app, a user will enter a natural language query, which is then converted to embeddings using the same BiomedCLIP model. This allows a search using the FAISS index to find relevant DICOM studies.

[4] Visualization: making embeddings explorable

The scatter plot in the UI is often the first thing users interact with. It needs to show meaningful clusters without requiring users to understand dimensionality reduction.

Component 4 takes the embeddings from component 1 and projects them to 2D with UMAP:

umap = UMAP( n_components=2, n_neighbors=10, # Balances local vs. global structure min_dist=0.5, # Prevents over-clustering metric='cosine', # Matches our embedding similarity metric random_state=42 # Reproducible layouts ) coordinates_2d = umap.fit_transform(features)

Each point in the scatter plot corresponds to a single DICOM series produced by the pipeline, with color, grouping, and hover metadata derived directly from the JSON artifacts emitted by components 1 and 4.

Each pipeline run produces a small set of well-defined artifacts — metadata tables, embedding vectors, UMAP coordinates, and the FAISS index — which are consumed directly by the cohort exploration UI. The cohort explorer application can reload or switch between datasets.

The diagram is a screen capture of an Azure ML pipeline. It includes 5 pipeline components along with connecting arrows showing incoming and outgoing data, including the final outputs of the pipeline.

Pipeline execution: time, cost, and what we learned

Here's what a typical pipeline run looks like for a dataset of ~4,500 DICOM series:

Component	Task	Approximate Time (CPU)	Approximate Time (GPU)
0 - DICOM Metadata Extractor	Scan files, extract headers	5-10 min	5-10 min
1 - Anatomy Classification	Classify anatomy/orientation	90-120 min	5-10 min
2 - Text Template Generator	Generate 5 templates per series	5-10 min	5-10 min
3 - FAISS Index Builder	BiomedCLIP encoding + FAISS build	60-90 min	10-15 min
4 - Visualization Enrichment	UMAP + color assignment	20-40 min	5-10 min
Azure ML overhead	Compute provisioning, env setup	5-10 min	5-10 min
Total		~200-300 min	~30-50 min

Key observations:

Azure ML overhead is significant when doing quick iteration and testing. Compute provisioning, conda environment builds, and data mounting add several minutes before any component code runs. We first built each component as python code to run locally and debug before our first Azure ML run. This way we quickly iterated and avoided cost until we were ready.
BiomedCLIP encoding dominates on CPU. Component 3 is the bottleneck. Moving to GPU compute for this component cuts encoding time roughly in half, but GPU clusters cost more. For a pipeline you run occasionally, CPU is fine. For frequent re-indexing, GPU pays for itself.
Batch size tuning matters. The default BiomedCLIP batch size of 256 balances memory and throughput. On GPU, you can push to 512. On CPU with limited RAM, drop to 128.

At Scale: 120,000 Images, CPU vs. GPU

We ran the full pipeline against a larger dataset of ~120,000 images to understand how compute choice affects end-to-end time and cost:

	CPU Pipeline	GPU Pipeline
Pipeline compute time	4 days, 12 hours (108 hrs)	15 hours
Pipeline compute cost	~$0.25/hr × 108 hrs = ~$27	~$3.00/hr × 15 hrs = ~$45
MedImageInsight endpoint (MaaP on Standard_NC4as_T4_v3)	~$151	~$21
Total estimated cost	~$178	~$66

Both pipeline runs make the same ~120,000 classification calls to the MedImageInsight endpoint, but those calls are spread out over different time periods depending on how quickly and efficiently the pipeline can make the calls to MedImageInsight. The hourly cost for MedImageInsight on a Standard_NC4as_T4_v3 VM is ~$1.40/hr. Resulting in the estimated costs for MedImageInsight in the table above.

GPU compute was roughly 7× faster at about 0.37× the total cost when endpoint costs are included. This was a key learning and clearly indicates the benefits of the more powerful compute resources.

MedImageInsight can be deployed in two ways, depending on dataset size and operational needs.
For smaller or infrequently processed datasets, we deploy MedImageInsight as a managed Azure ML online endpoint and invoke it from the pipeline. This keeps the pipeline simpler and avoids managing the MedImageInsight compute directly, while offering comparable performance at modest scale.

For larger batch workloads, an alternative approach is to load MedImageInsight directly on the Azure ML pipeline’s GPU-backed compute. In this model, the pipeline handles both model loading and classification, eliminating per-request network round trips and the fixed cost of hosting a persistent endpoint.

While this approach requires slightly longer pipeline run time, it becomes more cost‑effective at scale by avoiding endpoint overhead and improving throughput during bulk processing.

Possible future enhancements

Additional modalities: Extending the pipeline and classification to CT, X-ray, and ultrasound imaging, and build on the pattern for pathology images
Image embeddings fusion: Combining MedImageInsight image embeddings with text embeddings for hybrid search
Condition-aware search: Enabling queries about findings and conditions, not just imaging parameters

The gap between a hackathon demo and a production system is where the real engineering happens. We hope sharing our journey helps others building similar systems.

If you’re interested in partnering with us to work toward this goal or need access to the GitHub repo with the pipeline and UI code, contact authors through your Microsoft account team or reach out to Microsoft HLS AI frontier team

The healthcare AI models in Microsoft Foundry are intended for research and model development exploration. The models are not designed or intended to be deployed in clinical settings as-is nor for use in the diagnosis or treatment of any health or medical condition, and the individual models' performances for such purposes have not been established. You bear sole responsibility and liability for any use of the healthcare AI models, including verification of outputs and incorporation into any product or service intended for a medical purpose or to inform clinical decision-making, compliance with applicable healthcare laws and regulations, and obtaining any necessary clearances or approvals.

Capturing clinical conversations across dozens of languages with Dragon Copilot

Karen_Couchon — Tue, 26 May 2026 12:58:47 GMT

Language can shape trust, understanding, and the patient experience

Patient care doesn’t happen in just one language. To better reflect the diversity of patients and communities physicians serve, Dragon Copilot now supports dozens of languages, enabling clinicians to capture clinical conversations naturally without changing how they document care. This expanded capability helps physicians engage more confidently with diverse patient populations, transition smoothly from one appointment to the next, and spend more time focused on care rather than documentation.

Care that reflects the languages patients speak

In real world care settings, patient visits may occur across multiple languages throughout the day. Physicians can welcome each patient and carry on a natural, back-and-forth conversation in the language patients are comfortable speaking, without interrupting the flow of the appointment. When the visit concludes, Dragon Copilot seamlessly generates the clinical note in English for clinician review and signoff.

Recording languages available in Dragon Copilot

With a broad range of recording languages available, Dragon Copilot reflects the diversity of regions, communities, and patient populations clinicians serve every day. This language coverage helps clinicians engage patients more naturally and inclusively, reducing communication barriers that can affect understanding and trust. By conversing with patients in the language they speak, clinicians can deliver more effective care and reach more patients.

Physicians can record conversations in Dragon Copilot in the following languages: Afrikaans, Arabic, Armenian, Azerbaijani, Bengali, Bosnian, Bulgarian, Catalan, Chinese (Mandarin), Chinese (Cantonese), Croatian, Czech, Danish, Dutch, English, Estonian, Filipino (Tagalog), Finnish, French, Galician, German, Greek, Hebrew, Hindi, Hungarian, Icelandic, Indonesian, Italian, Japanese, Kannada, Kazakh, Korean, Latvian, Lithuanian, Macedonian, Malay, Marathi, Nepali, Norwegian, Persian, Polish, Portuguese, Punjabi, Romanian, Russian, Serbian, Slovak, Slovenian, Spanish, Swahili, Swedish, Tamil, Thai, Turkish, Ukrainian, Urdu, Vietnamese, and Welsh.

Building multilingual conversations into Dragon Copilot

Dragon Copilot’s multilingual ambient recording capability supports natural, real-world clinical conversations in multiple languages while delivering structured clinical documentation in English. It captures ambient speech during patient encounters, applies language identification, speech recognition, and clinical understanding, and transforms free-flowing dialogue into structured clinical notes. This allows clinicians to communicate in a patient’s preferred language while receiving an English summary aligned to documentation standards, helping reduce administrative burden and support more inclusive interactions.

Testing multilingual conversations with safety in mind

To evaluate multilingual ambient documentation, we started with clinical encounters in English. These served as our baseline so we could understand how performance changes when the same conversation is processed in different languages.

We transcribed each encounter into a target language, generated spoken audio, and ran it through Dragon Copilot’s multilingual workflow. The system then produced an English clinical note, which we compared to the original English reference. This allowed us to measure how well clinical meaning is preserved across languages, not just transcription accuracy, but the quality of the final clinical summary.

Conclusion: Designed for real world care

Multilingual recording support helps clinicians document conversations more naturally while maintaining consistent workflows and documentation standards. As Dragon Copilot continues to evolve, multilingual support remains focused on clarity, safety, and usability, so clinicians can spend less time documenting and more time with patients.

While Dragon Copilot captures conversations in many languages, it does not provide translation or interpretation. Clinicians should use the product only in languages they are comfortable practicing in and remain responsible for reviewing and validating all clinical content.

The Agent Era Has Already Arrived in Healthcare. Are You Ready to Govern It?

DolicaGopisetty — Tue, 05 May 2026 01:28:17 GMT

Start here. Answer honestly.

Right now, how many AI agents are running inside your organization? Who built them? Which patient data, claims information, or proprietary research are they configured to access?

If your CISO walked into your office tomorrow and asked for a complete inventory of every agent in your enterprise, including each one's owner, the systems it is permitted to access, and the policies that govern how it operates, could you produce that inventory before lunch?

When the analyst who built that clinical summarization agent moves to a new role next quarter, what happens to the agent? Does its access continue? Does anyone notice?

If a regulator opened an audit tomorrow, could you prove that every AI agent operating in your environment is subject to the same lifecycle controls, identity standards, and data protection policies you apply to your human workforce?

Could you disable a compromised agent enterprise-wide with a single click, the same way you would revoke a lost access credential?

If those questions made you hesitate, you are not alone. Almost no healthcare or life sciences organization can answer them confidently today. And that gap is exactly where the next decade of risk, and the next decade of competitive advantage, will be decided.

The quiet crisis nobody talks about yet

Healthcare and life sciences leaders are caught in a paradox.

You need AI to survive the operational pressures squeezing your organization from every direction. Physician burnout is at crisis levels, with 45.2% of US physicians reporting symptoms in recent Mayo Clinic research. Revenue cycle complexity continues to climb, and McKinsey now estimates that the cost to collect consumes 30 to 60 percent of net patient revenue at many provider organizations. Prior authorization backlogs delay care. Clinical trial timelines stretch into years. Documentation burden eats hours that belong to patients.

So you started piloting Microsoft 365 Copilot. You experimented with agents in Copilot Studio. Maybe a clinical team built an agent to draft discharge summaries. A revenue cycle group spun up an agent to triage denials. A medical affairs team built one to comb through literature. Each one delivered value. Each one was approved on its own merits. And then a quiet thing happened.

You lost track of how many agents you have.

According to KPMG's AI Quarterly Pulse Survey, 88 percent of organizations are now exploring or piloting AI agents. IDC projects that 1.3 billion agents will be in operation by 2028. Inside your own walls, the number is climbing fast. Each new agent is a digital identity that authenticates into your environment, accesses your data, and executes work on behalf of your business. Most have no formal owner. Most have no documented access scope. Most have no decommissioning plan. Most have never been reviewed by Compliance.

Microsoft's 2024 Data Security Index found that 84 percent of organizations lack confidence in their AI data security posture, and 40 percent have already experienced an AI related data security incident. That is not a future problem. That is a now problem.

If shadow IT was the defining governance challenge of the last decade, agent sprawl is the defining challenge of this one. And in healthcare and life sciences, where ePHI, member PII, and proprietary clinical trial data are at stake, the consequences are not theoretical. They are existential.

The reframe that changes everything

Here is the counterintuitive truth that separates HLS organizations that scale AI from those stuck in pilot purgatory.

Governance is not the brake on AI adoption. Governance is the accelerator.

When security, identity, and agent oversight are engineered in from day one, your teams stop tiptoeing. They build with confidence because the guardrails are real. They expand into clinical use cases because Compliance trusts the foundation. They scale wall-to-wall because IT can prove every agent is accounted for. The organizations that lead with trust end up moving faster in the long run, not slower.

This is the bet behind Microsoft Agent 365 and Microsoft 365 E7.

What Agent 365 and Microsoft 365 E7 actually are

Microsoft 365 E7, announced March 6, 2026 and now generally available, is the Frontier Suite. It is Microsoft's answer to a single question that every healthcare CIO, CISO, and COO is wrestling with: how do you run AI safely, at scale, across an entire organization?

E7 is not another SKU on top of your existing stack. It is one cohesive platform that brings together four essential capabilities:

Microsoft 365 E5 for your enterprise productivity, collaboration, and security foundation, including Microsoft Defender, Microsoft Purview, and Microsoft Intune.
Microsoft 365 Copilot for AI grounded in your organizational data through Work IQ, embedded in the flow of work for clinicians, researchers, operations teams, and administrators.
Microsoft Entra Suite for identity governance, Conditional Access, and Zero Trust network access, extended consistently across users, applications, and AI agents.
Microsoft Agent 365 as the centralized control plane to observe, govern, and secure every AI agent, whether built by Microsoft, your internal teams, or external partners.

Agent 365 is also available as a standalone capability. But the magic happens when it works alongside the rest of E7, because that is where AI, identity, security, and governance stop being separate disciplines and become one operating system for the agentic era.

The mental model that unlocks everything: agents are first-class digital identities

Here is the simplest way to understand what Agent 365 does.

Microsoft 365 governs your enterprise identities. Agent 365 governs your agent identities. The same control plane disciplines apply to both.

Think about the rigor you apply to any privileged identity in your environment, whether a service account, an API integration, or a third-party application connector. You issue it a unique identity in Microsoft Entra. You assign a human owner who is accountable. You scope its access to least privilege. You apply DLP, sensitivity labels, and Conditional Access. You monitor for anomalous behavior. You have a documented decommissioning path. Identities that no one watches over become identities that get exploited.

Now ask yourself how the last AI agent in your environment was created.

The honest answer at most organizations: someone opened Copilot Studio, pointed it at a SharePoint library of clinical protocols, gave it a name, and moved on. No documented owner. No access review. No retirement plan. Compliance was never consulted.

You would never stand up a privileged service account that way. Yet that is exactly how most organizations are standing up the fastest-growing class of digital identities in their environment.

Agent 365 closes that gap by extending the identity, security, and lifecycle controls you already trust for users and applications so they apply with the same rigor to AI agents.

Every agent receives a unique Entra Agent ID, a first-class identity in Azure AD with the same governance primitives as any other privileged identity.
Every agent has a designated human owner who is accountable for its scope and behavior.
Access is granted explicitly through Conditional Access and policy templates, so each agent operates only against the resources its purpose requires.
Microsoft Purview DLP and sensitivity labels govern which data the agent is permitted to read, generate, or share.
Microsoft Defender monitors agent activity for anomalies and surfaces alerts the same way it does for any other identity-driven risk.
Lifecycle rules flag or auto-retire agents that are dormant, orphaned, or risky, eliminating the unowned automations that quietly accumulate in every enterprise.

This is not metaphor. It is the actual architecture. The fastest path to governing agents is to extend the identity infrastructure you already trust.

The three pillars of Agent 365: Observe, Govern, Secure

Pillar 1: Observe. Know what is actually happening.

You cannot govern what you cannot see. The first job of Agent 365 is to give you complete, continuous visibility into every AI agent operating in your environment.

The Agent Registry is the single authoritative inventory of every agent, whether built by Microsoft, custom developed by your team, deployed by a partner, or discovered as a shadow agent operating without oversight. Each entry shows the owner, purpose, capabilities, lifecycle status, and business context. Agent Analytics tracks adoption, quality, performance, and business impact. Agent Map visualizes how agents connect with other agents, people, tools, and data sources, surfacing dependencies and risk concentrations you would never spot in a spreadsheet. Real time monitoring flows directly into Microsoft Defender, so unusual agent behavior generates alerts the same way unusual user behavior does today.

For a health system CISO, that means finally being able to answer the question: which agents are touching ePHI, and is every one of them authorized? For a life sciences compliance officer, it means audit ready visibility into every AI system operating across R&D, regulatory affairs, and commercial. For a payer operations leader, it means knowing which claims processing agents are actually delivering accuracy and throughput, and which are quietly underperforming.

Pillar 2: Govern. Set the rules. Control the lifecycle.

Visibility is the start. Control is what turns visibility into outcomes.

Agent 365 ensures that every agent is approved, compliant, and accountable from creation through retirement. IT led onboarding workflows make sure each agent launches with the right identity, access, and ownership before it ever touches data. Policy templates enforce data handling, permission, and usage rules consistently from day one through Defender, Entra, and Purview. Rules based agent management gives admins an automated If This Then That interface. If an agent is unused for 90 days, auto retire it. If an agent is flagged as risky, block it and alert the security operations team. No human in the loop required for the routine cases, full alerting and override for the exceptions.

Ownership enforcement requires every agent to have a designated human owner. When that owner leaves the organization, the platform flags the orphaned agent for bulk reassignment, so nothing operates without clear accountability. The Tools Gateway brokers and audits tool access for agents, enabling least privilege at the action level, not just the identity level.

For HLS specifically, that translates to outcomes you can take to your board. A hospital CIO can ensure any agent touching Epic or Cerner goes through standardized approval. A pharma IT director can enforce that clinical trial matching agents only touch de identified data unless elevated permissions are explicitly granted and documented. A payer compliance team can automatically retire agents tied to a completed open enrollment campaign instead of letting them silently expand the attack surface.

Pillar 3: Secure. Protect agents and data with the stack you already trust.

The final pillar is what makes Agent 365 production grade for healthcare and life sciences. Security and compliance are not bolted on. They are the same proven Microsoft security stack you already run for your users, extended natively to agents.

Microsoft Purview, your data security and compliance backbone:

Data Security Posture Management for AI gives visibility into how agents interact with sensitive data and detects risky usage patterns.
Data Loss Prevention stops agents from accessing or processing files labeled Highly Confidential, even when a user prompts them to.
Sensitivity labels are inherited automatically by agent outputs, governing how data is viewed, extracted, or shared downstream.
Insider Risk Management detects risky behavior by users interacting with agents, such as unusual prompt patterns or excessive access to sensitive data.
Communication Compliance monitors AI driven interactions for regulatory or ethical violations and unauthorized disclosures.
eDiscovery and Audit logs every agent interaction, giving legal, compliance, and IT teams the transparency required for HIPAA, GDPR, and FDA 21 CFR Part 11.
Oversharing Assessments run weekly checks for sensitive data exposure across SharePoint sites and agent access patterns.

Microsoft Entra, your identity control plane:

Entra Agent ID gives every agent a unique identity in Azure AD, so Conditional Access, role based access, and risk based policies apply individually.
Conditional Access for agents enforces policies like only allow this prior authorization agent to access claims data from approved devices and locations during business hours.
Identity Governance provides access packages for agents with reduced scope permissions and least privilege defaults.
Block at Scale lets you instantly disable all high-risk agents from Entra in a single action.

Microsoft Defender, your threat protection layer:

Security Posture Management identifies and remediates agent misconfigurations, such as agents running with no authentication.
Threat Detection and Blocking monitors suspicious agent activity, generates alerts, and blocks unauthorized tool invocations.
Threat Investigation and Hunting collects unified agent observability logs so SOC teams can forensically trace every action an agent took.
One Click Kill Switch instantly disables any agent and surfaces the complete audit trail of every action it took before being stopped.

For a hospital security operations team, that means the same DLP policies protecting patient records in email and Teams now protect agents that summarize clinical notes. For a life sciences data protection officer, it means agents accessing proprietary compound data respect the same sensitivity labels as human researchers. For a payer CISO, it means an anomalous claims agent can be killed in seconds, with a complete forensic record of every member record it touched.

Why this only works as an integrated platform

Individual capabilities are useful. Integration is what makes them transformative. Here is the contrast HLS leaders feel today versus what changes the moment E7 lights up.

Without an integrated platform, you operate with:

Fragmented tools for identity, security, compliance, and AI, each with its own console and its own gaps.
No centralized agent inventory, forcing your IT and security teams to track bots and automations in spreadsheets.
Inconsistent policy enforcement across agents, creating compliance gaps every audit team will eventually find.
Blind spots where agents access data, invoke tools, or interact with other agents without any oversight.
Manual triage when an incident hits, because nothing connects user identity, agent identity, and data classification in one view.

With Microsoft 365 E7, you gain:

A Unified Agent Registry providing a single source of truth for every agent, whether Microsoft built, custom developed, partner deployed, or shadow discovered.
Entra Agent ID giving each agent a unique identity, so Conditional Access, role based access, and risk based policies apply at the individual agent level.
Full lifecycle governance with standardized onboarding, periodic review, ownership transfers, auto retirement of dormant agents, and structured offboarding.
Policy by design, where Purview DLP, sensitivity labels, and compliance rules extend to all agent interactions through pre built templates applied consistently from day one.
One click disable to instantly freeze any agent, with Defender threat detection extended to agents and full audit trails for forensic investigation.
Expanded threat coverage that addresses agent sprawl, overprivileged access, tool misuse, misconfiguration, and inter agent risk patterns no legacy tool was designed to see.
Shared registry and controls that let IT, Security, and Compliance reference the same authoritative inventory across Defender, Entra, and Purview, eliminating the silos that slow incident response.

This is the reason E7 exists as a platform, not a bundle. AI, identity, security, and governance stop being separate disciplines and start operating as one system.

What this is actually worth: the Forrester numbers

Microsoft commissioned Forrester to conduct a Total Economic Impact study of Microsoft 365 Copilot, published in March 2025. The composite organization in that study, modeled on real customer interviews, achieved:

132 percent three-year ROI with payback in under one year.
9 hours saved per Copilot user per month through automation of routine work like drafting, summarizing, and analysis.
Up to 2.6 percent top line revenue lift through better qualified opportunities, improved win rates, and stronger retention in customer facing teams.
25 percent acceleration in new employee onboarding as new hires ramp faster on summarized institutional knowledge.

Those are the verified numbers. The bigger story for HLS is what they look like when applied to clinical, claims, and research workflows where every reclaimed hour is an hour that goes back to patients, members, or science.

AI is already defending AI

The same agentic capabilities transforming clinical and operational workflows are now embedded in your security stack. Microsoft Security Copilot agents work alongside human analysts inside Defender, Entra, Purview, and Intune, accelerating threat response and absorbing the manual load that today drowns most security operations teams.

Independent benchmarks back the impact. In a 162 admin randomized study published in 2025, the Conditional Access Optimization Agent in Microsoft Entra completed configuration tasks 43 percent faster and produced 48 percent more accurate Conditional Access policies than admins working without it. Security triage, alert investigation, and identity hygiene are following the same trajectory.

For HLS security teams already stretched thin, that is hours reclaimed every week to focus on the threats that actually matter, with the same Agent 365 governance applying to the security agents themselves. The defenders are governed by the same rules as the workforce they defend.

How HLS organizations are putting Agent 365 to work

Here is how the value shows up across the three biggest HLS segments.

For providers: reclaiming time for care

The challenge: clinicians spend more time on documentation than on patients. Care coordination is fragmented. Burnout is gutting retention.

The strategy: deploy agents that absorb administrative load while Agent 365 ensures every one of them respects ePHI boundaries.

Clinical documentation agents integrated with Microsoft Dragon Copilot structure dictation against EHR requirements, apply billing codes, and flag missing elements before submission.
Care coordination agents generate care plans, allocate tasks, and surface relevant patient context during multidisciplinary rounds, optimized for HL7 FHIR interoperability.
Patient intake and scheduling agents built in Copilot Studio handle appointment booking, reminders, eligibility verification, and referral management.
Handoff and shift summary agents pull from multiple systems to generate complete handoff summaries for nurses and physicians transitioning between shifts, reducing communication gaps that drive adverse events.

The aha moment: applied across a 10,000 employee health system, nine hours per user per month is more than one million reclaimed hours a year. That is the equivalent of hundreds of full time clinicians, returned to direct patient care, with every agent governed under the same Conditional Access and DLP policies your IT team already manages today.

For payers: transforming revenue cycle and member experience

The challenge: prior auth backlogs delay care. Denial rates climb. Member services teams drown in volume.

The strategy: agentic AI rewires the most expensive, most manual workflows in your operation while Agent 365 keeps every agent inside the lines on member PII.

Prior authorization agents autonomously gather clinical documentation, cross reference medical policy, determine approval criteria, and route decisions, accelerating turnaround from days to hours.
Claims processing agents automate billing and denial management. With cost to collect running 30 to 60 percent of net patient revenue at many organizations, even modest automation produces material margin recovery.
Denial resolution and appeals agents analyze denial patterns, surface root causes, generate appeal documentation, and track success rates over time, turning a cost center into a continuous improvement engine.
Member services agents integrated with Microsoft 365 Copilot Chat handle benefits inquiries, claims status, and self service triage, deflecting call volume and improving first contact resolution.
Fraud detection and risk adjustment agents scan claims data for anomalies and optimize coding accuracy for Medicare Advantage and ACA populations.

The aha moment: a payer CISO can disable an anomalous prior auth agent in one click and produce a complete forensic record of every member record it accessed, while Compliance simultaneously confirms the agent never violated DLP. That is regulatory readiness that legacy automation cannot deliver.

For life sciences and pharma: accelerating discovery and commercialization

The challenge: clinical trials take years. Regulatory submissions consume teams. Medical affairs cannot keep up with literature volume.

The strategy: orchestrate agents across R&D, regulatory, medical, and commercial, with Agent 365 enforcing the data classification rules that proprietary IP and clinical data demand.

Clinical trial matching agents scan patient profiles and eligibility criteria to surface trial opportunities, accelerating recruitment.
Regulatory document preparation agents assemble submissions, cross reference data across modules, and ensure consistency in FDA, EMA, and global filings.
Medical research and literature review agents powered by Microsoft GraphRAG retrieve research backed insights with verified source references, giving medical science liaisons trustworthy synthesis on demand.
Pharmacovigilance agents monitor safety databases, flag potential adverse events, and generate timely case reports.
Commercial insights and launch planning agents synthesize market data, payer policy, and HCP sentiment for sharper launch and field strategy.

The aha moment: cutting even three months off a regulatory cycle on a single high revenue product can mean tens of millions in additional sales, while Purview sensitivity labels guarantee every agent accessing proprietary compound data respects the same data classification as your senior researchers.

A phased path that actually works in regulated industries

In regulated industries, a big bang AI rollout is a recipe for incidents. The HLS organizations getting this right are following a five-phase pattern that builds expertise and validates governance before scale.

Establish. Form a cross-functional champion team across IT, Compliance, Clinical Operations, and Research. Define what risks you are mitigating and what outcomes you are unlocking. Inventory the agents already in flight.
Configure. Stand up identity, DLP, and policy templates in Microsoft 365 Admin Center, Power Platform Admin Center, and Microsoft Purview. Enforce that any agent handling PHI runs in a secure environment with audit logging on by default.
Pilot. Choose a small group of makers in a controlled environment. Start with non-critical workflows like internal reporting or scheduling before moving to clinical or member facing use cases. Run weekly reviews with Compliance and Security.
Empower. Launch role specific training for clinicians, researchers, makers, and IT. Stand up a Center of Excellence to provide templates, best practices, and reusable patterns. Promote success stories internally to build momentum.
Scale. Expand agent development across departments with governance as a guardrail, not a gate. Use pay as you go metering to track usage and optimize licensing. Refine policies continuously based on Purview signals and audit results.

The strategic insight: organizations that lead with governance reach scale faster than those that lead with experimentation. Trust is the unlock, not the obstacle.

Governance is a team sport

Here is the pattern we see again and again. The HLS organizations that succeed with AI at scale are not the ones with the smartest IT shop or the boldest Compliance officer. They are the ones whose IT, Security, Compliance, Clinical, Research, and Operations leaders sit at the same table on agent strategy from week one.

Agent 365 was designed for that table. The Agent Registry is the shared truth. Purview policies satisfy your Compliance officer. Entra controls reassure your CISO. The lifecycle workflows give your CIO confidence. The clinical and research outcomes give your COO and Chief Medical Officer the business case. Everyone gets the view they need from the same single source.

Stand up an agent governance council. Meet every two weeks. Use the Agent Registry as your standing agenda. Make decisions in plain sight. The organizations that do this consistently outperform on both speed and safety. The ones that try to keep AI inside a single function fall behind on both.

Who contributes what

Think back to the mental model. You would never let a single function authorize, configure, and oversee a new privileged system on its own, not when it touches ePHI, claims, or proprietary research. Security, IT, Compliance, Clinical, and the relevant business owner all weigh in because the stakes are too high for any one seat to carry alone. Agent governance demands the same multidisciplinary scrutiny, and the council is where that happens.

Each seat brings something the others cannot.

CIO. Owns the agent strategy and the platform investment. Translates board-level AI ambition into an operating model the rest of the organization can execute against.
CISO and Security Operations. Define agent identity standards, Conditional Access policies, and incident response playbooks. Without this seat, an anomalous agent touching ePHI becomes a breach instead of a contained event.
Chief Compliance Officer and Privacy. Translate HIPAA, GDPR, FDA 21 CFR Part 11, and state regulations into Purview policies and audit requirements. This is the seat that keeps you out of an OCR investigation or a 483 letter.
Chief Medical Officer and Clinical Operations. Validate that clinical agents are safe, accurate, and aligned with care standards. Own the clinical risk review for any agent that touches patient care, the same way you would for a new clinical protocol.
Chief Research Officer or Head of R&D. Govern how agents interact with proprietary trial data, compound libraries, and scientific IP. The seat that protects the next decade of pipeline value.
COO and Revenue Cycle Leadership. Prioritize the operational workflows where agents will move the needle on cost to collect, denial rates, and throughput, and own the business outcomes that justify the investment.
Center of Excellence Lead. Maintains templates, reusable patterns, and maker enablement. Turns every council decision into a guardrail builders can actually use the next morning.
Frontline champions. Clinicians, claims specialists, and researchers who pilot, give feedback, and carry credibility back to their peers. The seat that decides whether agents get adopted or quietly ignored.

When every one of these voices is in the room, your governance council operates like a tumor board for AI. Different lenses, one shared decision, full accountability. That is how regulated industries make complex calls safely, and it is exactly the muscle Agent 365 was built to support.

Seven questions to bring to your next leadership meeting

If you want to know whether your organization is ready, run through these together. The places you hesitate are exactly where Agent 365 and E7 deliver the most value.

Visibility. Do you know which AI agents, bots, and automations are running in your environment today, who built them, what they have access to, and whether they are still needed?
Control. If someone on your team builds a new AI agent tomorrow, what is the actual process to make sure it is approved and secured? Or could they deploy it with wide open access?
Security. What prevents an AI agent from reading or transmitting patient data it should not? Do you have a way to detect and stop a rogue or compromised agent?
Accountability. Who owns the outputs of an AI agent's actions? What is the offboarding process when the agent or its creator leaves?
Scale. Six months from now, you may have a hundred agents deployed across departments. Are your oversight and compliance structures ready for that volume?
Cross-functional alignment. How are your IT, Security, and Compliance teams partnering on AI today? Governance is a team sport.
Data readiness. How confident are you that your data estate is clean, labeled, and governed well enough for AI to surface accurate answers and not outdated or conflicting information?

If you hesitated on even one of those, you have just identified where Agent 365 and Microsoft 365 E7 will pay for themselves the fastest.

The path forward

Here is the honest truth. The healthcare and life sciences organizations that lead in the next decade will not be the ones that adopted AI first. They will be the ones that adopted AI safely, compliantly, and at scale, with intelligence and trust woven into every layer.

Microsoft Agent 365 and Microsoft 365 E7 give you the only integrated platform that brings AI, identity, security, and governance into one cohesive system, running in the flow of work you already use. This is not about adding another tool to your stack. It is about extending the investments you have already made in Microsoft 365, Entra, Defender, and Purview to cover the fastest-growing class of digital identities in your environment.

The agent era has already arrived. The question is whether you will govern it with confidence or chase it with anxiety.

We would love to help you lead.

Take the next step

Explore Microsoft Agent 365: The Control Plane for Agents
Microsoft Entra Agent ID: aka.ms/EntraAgentID
Learn more about Microsoft 365 E7, the Frontier Suite: Introducing Microsoft 365 E7
See Microsoft 365 Copilot in action: Microsoft 365 Copilot
Read the Forrester TEI study: The Total Economic Impact of Microsoft 365 Copilot

The Microsoft 365 Copilot Frontier Program: What Executives and IT Leaders Actually Need to Know

michaelgoad — Wed, 29 Apr 2026 20:36:25 GMT

If your business leaders are asking why they don't have the latest Copilot features they saw at Microsoft Ignite, someone has probably already said, "Have you looked at the Frontier program?"

That's where things get interesting.

Frontier is one of those programs that can be a real strategic advantage when you understand it well. But if you walk into it without the right governance in place, you're going to create headaches for your security and compliance teams fast.

Here's an honest, practical breakdown of what Frontier is, why organizations choose it, when you should wait, and what your governance teams need to know before you flip the switch.

What Is the Microsoft 365 Copilot Frontier Program?

Frontier is Microsoft's early access program that gives organizations access to the newest AI-powered Copilot capabilities before they reach general availability (GA).

Think of it as an on-ramp to the leading edge of Microsoft's AI roadmap.

When Microsoft's engineering teams build a new Copilot feature, it moves through a lifecycle:

Private Preview — Invitation only. A small group of design partners tests the feature under close partnership. Not self-service, not for everyone.
Frontier — Broader early access. Thousands of tenants can participate by opting in through the admin center. Still pre-GA, but real and working in your production environment.
General Availability (GA) — Full Microsoft SLA coverage, support agreements, and regulatory compliance standards your organization depends on.

Here's the part worth repeating: Features in Frontier are real working capabilities inside your production Microsoft 365 environment, but they are in active development. Microsoft is still refining them based on customer feedback.

A few things to understand right away:

Frontier is opt-in. An M365 administrator has to enable it. It doesn't happen automatically.
When you enable Frontier, you're not getting a separate test environment. These features run inside your existing tenant alongside your GA Copilot capabilities.
The feature set changes. Features get added as they mature and graduate out of Frontier into GA over time.

Why Organizations Choose to Enable Frontier

There are four strategic reasons I see most often.

Competitive velocity. In industries like financial services, healthcare, and professional services, staying ahead matters. Frontier lets your team start learning and building workflows around capabilities before your competition even knows they're coming. By the time a feature hits GA, your users are already fluent in it.
Direct influence on the product. This one is underappreciated. Microsoft actively collects feedback from Frontier participants. When your users encounter something that doesn't work the way your workflows require, that feedback goes directly to the engineering team. Your organization gets a seat at the table in shaping how these features evolve.
Organizational AI readiness. Participating in Frontier responsibly forces a healthy discipline. You need to mature your AI governance, adoption playbooks, and change management approach faster than you otherwise would. Many IT leaders I've talked to say that preparing for Frontier accelerated their overall Copilot adoption maturity because it forced them to get governance and IT strategy in place first.
Access to differentiated capabilities. Some features that debut in Frontier are genuinely transformational. Copilot Cowork. New reasoning models. Deeper cross-application intelligence. If those capabilities tie directly to your business outcomes, waiting for GA means leaving real value on the table.

One more thing worth saying directly: the choice to enable Frontier is a leadership decision, not an IT decision. It's about balancing how fast you want to move with how mature your governance actually is. This is a joint venture between IT and the business.

Frontier vs. Private Preview vs. GA: Feature Lifecycle Explained

Here's a quick reference so you and your leadership team are using the right language:

Stage	Access	SLA	How to Join
Private Preview	Invitation only	None	Microsoft selects you
Frontier	Opt-in via admin center	Preview feature expectations (not GA SLA)	Self-service
General Availability	All licensed users	Full Microsoft SLA	Automatic

The key callout: Frontier features do not carry the SLA commitments that apply to GA services. That matters a lot in regulated environments.

When Frontier Makes Sense for Your Organization

Frontier is a strong fit if:

Leadership actively values being first to adopt, with the discipline to do it responsibly
You already have a mature M365 Copilot deployment and power users who are hungry for more
You have clear IT governance and change management processes in place
Your compliance posture allows for preview feature participation

When You Should Wait

I want to be equally honest about when Frontier is not the right move yet.

Wait if you're in a heavily regulated environment and haven't completed a compliance assessment. Preview features may not have completed all compliance certifications. Talk to your Microsoft account team before you enable anything.

Wait if your M365 baseline deployment is still maturing. Get the foundations right first.

Wait if you don't have a clear feedback path from end users. Without a channel for users to report back to IT and business leaders, Frontier creates frustration instead of value.

Wait if your IT team is already stretched. Frontier requires active engagement with release notes, user communication, and feedback loops. If capacity is already thin, this will add to the bottleneck.

With the right framing, Frontier isn't a risk. It's a governance responsibility.

Five Governance Checkpoints Before You Enable Frontier

This section will save your compliance team the most headaches. Work through all five before you flip the switch.

Conduct a compliance assessment. Preview features may not have completed all compliance certifications. Work with your Microsoft account team to understand the compliance posture of specific Frontier features relevant to your industry.
Define your governance scope. Frontier doesn't have to be all-or-nothing. You can enable it for a defined set of users using Microsoft 365 security groups while keeping the broader organization on GA capabilities. More on that in the admin center walkthrough below.
Establish user communication protocols. Features can change quickly. Your users need to know what they're participating in, why their experience may differ from others, and how to submit feedback. ("Why does my UI look different than yours?" is a real conversation that happens all the time.)
Set up a feedback and monitoring cadence. Review Frontier release notes regularly. Track what's live in your tenant and synthesize user feedback back to Microsoft.
Plan for feature lifecycle transitions. Features can be updated, temporarily suspended, or graduated to GA. Your governance plan should address how you'll communicate changes and adjust workflows when that happens.

Think of governance here as a maturity accelerator, not a barrier.

How to Enable Frontier in the Microsoft 365 Admin Center

Here's exactly where to go and what to do.

Step 1: Navigate to Copilot Settings

Go to the Microsoft 365 admin center, navigate to the Copilot section, and select Settings. Click "View all" to see all settings on a single unified page. Use Ctrl+F to search for "Copilot Frontier."

Step 2: Scope Your Access

You'll have three options: enable for no one, for everyone, or for specific users. For most organizations, specific users is the right call. Set up a dedicated security group for your Frontier champions and assign access to that group only.

Step 3: Assign Frontier Agents

Enabling Frontier at the tenant level is just step one. You also need to assign specific Frontier agents to users. In the admin center, go to Agents > All Agents and search for "Frontier." From there, you can select individual agents (like Copilot Cowork) and assign them to your champion group or a subset of it.

This is the most common point of confusion: you can have Frontier enabled but still not have access to a specific agent like Cowork because you never assigned it. Both steps are required.

Step 4: Pull a Baseline Usage Report

Before your pilot starts, capture a baseline snapshot of your current Copilot usage. In the admin center, go to Reports > Usage > Microsoft 365 and look at the Copilot, Copilot Chat, and Agents tabs. Screenshot or export these. In four to eight weeks, you'll use this baseline to measure the impact of Frontier adoption across your pilot cohort and overall.

A Phased Rollout Model That Actually Works

Don't just turn Frontier on and hope for the best. Here's a five-phase model that turns it into a structured capability program.

Phase 1: Identify your Frontier champions. Target 50 to 200 users who are already Copilot power users, have a growth mindset toward AI, and can articulate business value from feature changes. These are your early adopters who will carry the signal back to the rest of the org.

Phase 2: Enable Frontier for your champion cohort. Follow the admin center steps above. Brief that group on what to expect, what's different, and how to submit feedback.

Phase 3: Evaluate and document. After four to eight weeks, pull up your Copilot usage dashboard and compare it to your baseline. Which features are driving measurable productivity gains? Document your findings.

Phase 4: Expand or adjust scope. Based on your champion cohort data, either expand to a broader user population or adjust scope if a specific feature is causing friction.

Phase 5: Establish steady-state governance. Formalize the feedback loop and user communication as a standard operating procedure within your Copilot governance framework. Start building documentation now so you're ready when features graduate to GA.

This approach turns Frontier from a feature toggle into a strategic capability program. That's where the real value shows up.

A Quick Decision Framework for Leadership

Before you bring this to your leadership team, run through these five questions:

Do we have a clear AI governance framework in place?
Are our Microsoft 365 GA deployments stable and delivering measurable value?
Have our compliance and legal teams assessed preview feature participation?
Do we have an identified Frontier champion cohort or IT bandwidth for a structured pilot?
Is there a specific business outcome we're trying to accelerate?

If you answered yes to four or five of those, you're in a strong position to move forward.

If you have two or more no's, invest in those foundations first. Getting governance, bandwidth, and a clear use case in place before enabling Frontier. It isn't about slowing down, it's setting yourself up to actually get value from it.

Bottom Line

The Microsoft 365 Copilot Frontier program is a strategic option for enterprise organizations that want to shape the future of AI productivity tools, not just consume them. But it's not for everyone, and it's not designed to be.

It's built for organizations that have the governance maturity, leadership alignment, and operational capacity to engage with early access AI responsibly.

When you do it right, Frontier can accelerate your AI program, sharpen your competitive edge, and give your organization a direct voice in how Microsoft AI evolves.

The tools are all right there in the admin center. It's just a matter of knowing where to look and using them intentionally.

Have questions about Frontier readiness or want to talk through your organization's Copilot governance strategy? Drop them in the comments or reach out directly.

Reimagining Cancer R&D with Agentic AI Using GigaTIME in Microsoft Discovery

Alberto_Santamaria — Tue, 28 Apr 2026 02:29:44 GMT

@Alberto Santamaria-Pang,
Principal AI Data Scientist, Industry Solutions Engineering Healthcare
Adjunct Faculty at Johns Hopkins School of Medicine
@Alexander Mehmet Ersoy,
Dir. Industry Advisory, Healthcare & Life Sciences

1. Introduction: From Images to insight in modern oncology

What if we could characterize every single cell in a tumor not just by how it looks under the microscope, but by the biological signals that shape how it behaves, how it evades the immune system, and how it responds to therapy? This question sits at the heart of modern oncology and precision medicine. Advances in artificial intelligence and spatial biology are rapidly lowering the barrier to understanding cancer at cellular and molecular resolution, supporting research into more precise, more personalized, and ultimately more effective treatments. Immuno-oncology already offers a glimpse of what becomes possible when therapy is guided by biology rather than averages. For example, the FDA approval of tisagenlecleucel for relapsed or refactory B-cell acute lymphoblastic leukemia was supported by an overall remission rate of 82.5%, underscoring how meaningful outcomes can be when treatment aligns with the right biological signals [1]. The challenge is scale: how do we make this type of biologically informed decision-making feasible across millions of patients, diverse tumor types, and real-world clinical settings?

Two recent Microsoft innovations help address that challenge, at different layers of the R&D stack: The GigaTIME AI Framework (a model and workflow for virtual mIF generation from routine pathology) and Microsoft Discovery platform (the agentic R&D platform that orchestrates data, tools, and AI Agents). In this time, we introduce GigaTIME in general (including a practical tutorial on how model can be used), and then show how GigaTIME could be used within, and in the context of, the Discovery platform as one tool that helps accelerate precision oncology discovery.

2. GigaTIME: Scaling tumor microenvironment insight from routine pathology

A routine hematoxylin and eosin (H&E) slide is a common cost-efficient diagnostic tool used to understand the specifics of patient’s oncological condition. It is like a high-resolution photograph of a complex cellular community. An H&E slide captures structure, morphology, and organization in remarkable detail, but it cannot fully reveal how cells are communicating or which molecular programs are active beneath the surface. This is why multiplex immunofluorescence (mIF) and related spatial proteomics assays have become so valuable in oncology research: they reveal protein patterns linked to immune identity, checkpoint signaling, proliferation, and tumor context. Their broad use, however, is limited by cost and throughput, which makes large-scale tumor immune microenvironment analysis difficult [2]. GigaTIME provides an important bridge. It translates routine H&E pathology slides into virtual mIF images across 21 protein channels, making it possible to infer spatially resolved, biologically meaningful virtual mIF patterns from a much more accessible input. In this blog, we focus on what that means at the tissue level: how to interpret selected virtual mIF signals, how to localize them in cellular context, and why that matters for understanding tumor–immune interactions in oncology [3].

Figure 1. GigaTIME Workflow schematic.

2.1 Reading virtual mIF signals in context

To make the virtual mIF panel easier to interpret, it helps to think of the tissue as two interacting compartments: the tumor compartment, where malignant growth and tumor-associated programs dominate, and the stroma or host compartment, where immune cells, vasculature, and connective tissue either resist, reshape, or sometimes enable tumor progression. The most important biology often happens at the boundary between these two worlds. Rather than reading the panel as a flat list of proteins, we can read it as a guide to tumor geography, immune access, checkpoint context, proliferation, and tissue infrastructure.

Table 1. Selected markers produced in GigaTIME.

Marker	What it represents	Why it matters biologically
CK	Tumor-rich epithelial regions	Defines where the tumor compartment is located.
DAPI	Cell nuclei	Anchors localization at the single-cell level.
CD8	Cytotoxic T cells	Helps assess whether immune cells are infiltrating tumor regions.
CD68	Macrophage-associated signal	Highlights myeloid context at tumor borders or within tumor-rich tissue.
PD-1 / PD-L1	Checkpoint-associated signaling	Provides context on whether immune activity may be locally restrained.
Ki67	Proliferation	Indicates whether tumor-rich regions are actively cycling.
CD34	Vasculature	Helps interpret access routes and stromal context around the tumor.

In this blog, we focus on a small set of markers that are especially useful for reading tumor geography, immune access, checkpoint biology, proliferation, and vascular organization. To make that concrete, we implemented a practical notebook that shows how the GigaTIME model can be deployed as an endpoint, used for inference on H&E patches, and combined with single-cell localization to support downstream phenotyping and interpretation. The main point is not any one marker in isolation, but how marker combinations organize in space and help us ask more meaningful questions about tumor–host interaction.

2.2 From H&E to virtual mIF: how GigaTIME works

The starting point is a sample-level H&E patch from the test dataset, paired with a compressed label file that contains binary marker masks and cell-segmentation scaffolds used downstream. The workflow is intentionally practical: load the H&E input, generate or reuse GigaTIME predictions, visualize selected virtual mIF channels, refine those predictions with single-cell localization, and summarize the results as virtual phenotypes and per-marker counts [4].

At the model-output stage, GigaTIME produces a multi-channel spatial prediction stack from the H&E patch. In the notebook, each channel can be visualized as a virtual mIF map indicating where the model predicts marker-associated signal in the tissue. However, these raw virtual mIF maps are not yet cell phenotypes. To make them biologically interpretable, the notebook converts dense predictions into cell-aware assignments. It uses labels_dapi for nuclear regions and labels_dapi_expanded for expanded cell regions, then computes the fraction of positive pixels within each segmented region. Marker positivity is assigned only when the overlap exceeds a threshold, with localization adjusted according to expected marker biology, such as nuclear versus non-nuclear signal [5].

This same localization scaffold also supports validation. Because the reference files provide binarized marker masks together with shared nuclei and expanded-cell labels, predicted signal and reference signal can be compared in the same segmented cellular space rather than only as unstructured image intensities. Once virtual mIF maps are tied to individual nuclei or cell regions, they become both quantitative and spatial, supporting measurements of infiltration, compartment-specific localization, and per-marker cell counts that can be aggregated across samples. You can access the tutorial here: https://aka.ms/gigatime-sample.

Figure 2. Example H&E patch and virtual mIF output.

2.3 Virtual Phenotyping

Once the virtual mIF maps have been localized to segmented cells, they can be interpreted as spatial phenotypes rather than diffuse prediction maps. In this tutorial, we use a limited sample dataset to demonstrate how these localized overlays can be reproduced and read biologically in practice. The goal is not to make broad claims from a small set of examples, but to show how virtual phenotyping connects marker prediction, cellular localization, and tumor microenvironment interpretation. In real applications, this type of workflow would typically require additional fine-tuning and validation to account for imaging conditions, tissue context, cohort composition, and study-specific marker panels.

At a high level, the figures in this section can be read through four themes: tumor–immune interaction, immune system structure, immune checkpoint biology, and stromal and vascular context. These themes translate localized virtual mIF signals into biologically meaningful spatial patterns. Rather than reading each marker in isolation, we can read how marker combinations organize near tumor-rich regions, immune niches, and tissue boundaries. These same concepts are already used in modern oncology, where immune infiltration, immune organization, checkpoint signaling, and vascular or stromal remodeling all shape how therapies are developed and interpreted [6–9].

Theme	Biological interpretation	Example marker trends	Therapy relevance
Tumor–immune interaction [6]	Tumor-rich compartment is being accessed by immune cells, shaped by myeloid cells, and actively proliferating.	• Higher CD8 near CK-rich regions suggests immune infiltration; • CD68 concentrated at the tumor border suggests a myeloid interface or barrier; • Higher Ki67 within CK-rich regions suggests active tumor proliferation.	Higher intratumoral CD8 is generally favorable for anti-tumor immunity; border-restricted CD68 may reflect a suppressive interface; high Ki67 in CK-rich regions is generally unfavorable because it suggests active tumor growth.
Immune system structure [7]	Immune compartment appears coordinated, sparse, balanced, or spatially segregated.	• CD3 and CD20 co-localized in organized clusters suggests structured lymphoid neighborhoods; • Balanced CD4 and CD8 distributions suggests a coordinated immune context; • Fragmented or separated patterns suggest a less organized response.	Organized lymphoid structure and balanced adaptive immune populations are generally favorable; fragmented or sparse immune organization may indicate weaker local immune coordination.
Immune checkpoint biology [8]	Immune cells are present but may be locally restrained by inhibitory signaling.	• CD8 overlapping with PD-L1 suggests immune presence in a potentially suppressive niche; • CD3 overlapping with PD-1 suggests T cells in a checkpoint-associated state consistent with local restraint.	Context-dependent: this may indicate a restrained immune response that could be relevant to checkpoint blockade, but not automatically a positive or negative finding in isolation.
Stromal and vascular context [9]	Tissue structure supports access, creates barriers, or concentrates inflammatory niches.	• CD34 aligned near CK-rich regions suggests vascular routes close to tumor compartments; • Tryptase and CD68 clustered in stromal or perivascular regions suggests innate inflammatory niches that may shape local signaling and access.	Context-dependent: vascular proximity can support access, while stromal or perivascular inflammatory niches may either facilitate response or reinforce barriers depending on the broader microenvironment.

Table 2. Quick guide to interpreting virtual phenotyping themes.

2.3.1 Tumor–immune interaction

Figure 3. Tumor–immune interaction.

We begin with a central question in the tumor microenvironment: can immune cells reach the tumor? In Figure 3, the CK-centered overlays provide a compact way to read this biology. CK + CD8 shows tumor-rich regions alongside cytotoxic T-cell signal, allowing us to ask whether immune cells are infiltrating tumor nests, remaining at the border, or being excluded from the tumor core. CK + CD68 adds macrophage context and helps highlight whether myeloid cells are embedded within tumor-rich regions or concentrated at the tumor–stroma interface. CK + Ki67 complements these immune overlays by showing whether the same tumor-rich regions also display strong proliferative activity.

Read together, these panels provide a concise illustrative summary of tumor geography, immune access, myeloid interface biology, and growth state. Are immune cells entering the malignant compartment, or is access limited? Are macrophages mixing with tumor cells or forming a border-associated niche? Are tumor-rich regions relatively quiescent, or are they actively cycling? Even in a tutorial setting, this combination of overlays shows how virtual markers can move beyond visualization and support structured interpretation of the tumor immune microenvironment.

2.3.2 Immune system structure

Figure 4. Immune system structure.

Virtual phenotyping is also useful for understanding how immune populations are organized beyond the tumor border itself. In Figure 4, overlays such as CD3 + CD20 and CD4 + CD8 provide a view into the composition and organization of the lymphoid compartment. Rather than asking only whether immune cells are present, these panels help us ask whether the immune landscape appears coordinated, sparse, balanced, or spatially segregated. This matters because immune presence alone does not fully capture immune effectiveness; spatial arrangement can suggest very different biological states.

2.3.3 Immune checkpoint biology

Figure 5. Immune checkpoint biology.

Checkpoint biology provides another layer of interpretation that is especially relevant in immuno-oncology. In Figure 5, overlays such as CD8 + PD-L1 and CD3 + PD-1 help connect immune presence with local regulatory signals. These panels are useful because they show that immune cells may be present in the tissue and still not be fully effective if their activity is being restrained by checkpoint-associated biology. Spatial overlap between T-cell markers and checkpoint-associated signal does not, by itself, prove immune exhaustion or therapeutic response, but it can provide context that is consistent with restrained or suppressed immune activity.

2.3.4 Stromal and vascular context

Figure 6. Stromal and vascular context.

The tumor microenvironment is also shaped by the surrounding tissue infrastructure. In Figure 6, overlays such as CD34 + CK and Tryptase + CD68 help reveal how vessels, stromal niches, and innate immune populations are positioned relative to tumor-rich regions. These patterns matter because immune access, tumor expansion, and local signaling are all influenced by the organization of the supporting tissue around the tumor. By including vascular and stromal context, the notebook helps show how virtual markers can support a more complete spatial interpretation of tumor–host interaction.

These examples show how virtual phenotyping transforms raw virtual mIF maps into interpretable spatial summaries of the tumor microenvironment. After localization, the outputs are no longer just probability maps; they become cell-aware patterns that can be read in terms of immune infiltration, tumor growth, checkpoint context, stromal organization, and compartment-specific localization.

The goal of examples is reproducibility and interpretation rather than broad biological generalization. The limited dataset is useful because it makes the workflow easy to follow and the figures easy to inspect, but real deployment would require additional tuning, validation, and adaptation for the target imaging workflow and marker set. Even with that caveat, this workflow illustrates the practical value of GigaTIME: virtual mIF predictions become most useful when they are localized, contextualized, and interpreted as part of a spatial system rather than as isolated channels.

3. Microsoft Discovery: Transform the end‑to‑end discovery process from hypothesis generation to simulation, evaluation, iteration, and design

Microsoft Discovery is designed as an enterprise agentic AI platform. It is built around a graph-based knowledge engine and teams of specialized AI agents that collaborate with scientists throughout the discovery cycle from literature reasoning and hypothesis formation to simulation and iterative learning. With Microsoft Discovery, teams can:

Accelerate end‑to‑end research with autonomous, multi‑agent systems that conduct literature analysis, scientific reasoning, simulation, and tool execution at scale
Unify institutional knowledge through GraphRAG‑powered Bookshelves that transform proprietary documents and scientific data into structured, queryable knowledge graphs
Scale advanced computation on Azure supercomputing infrastructure to support large‑scale simulation, modeling, and design‑space exploration
Collaborate with confidence in enterprise‑grade workspaces featuring built‑in RBAC, managed identities, and full data sovereignty

Figure 7. Microsoft Discovery.

Importantly, Discovery does not treat AI outputs as final answers. Instead, it embeds them into an explicit scientific reasoning loop, where:

Knowledge is represented as contextual, versioned graphs rather than static text
Conflicting evidence and assumptions are surfaced, not hidden
AI agents specialize, adapt, and learn across iterations
Researchers remain in control, with traceable sources and explainable steps

All outputs are intended to support, not replace, expert scientific and clinical judgment.

Figure 8. Microsoft Discovery Scientific Reasoning Loop.

Built on Microsoft Azure, Microsoft Discovery orchestrates teams of specialized AI agents using a graph-based knowledge engineering framework and able to leverage AI models available through Microsoft Foundry. The platform integrates advanced AI, high-performance computing (HPC) and quantum capabilities, and can connect insights back to the physical world to enable continuous experimentation and refinement. Meanwhile, Microsoft Discovery remains fully extensible to an organization’s own models, agents, tools, and datasets while meeting stringent enterprise requirements for trust, governance, security and compliance.

Figure 9. Enterprise Agentic R&D Platform Microsoft Discovery.

4. Using GigaTIME within Microsoft Discovery for precision oncology R&D

Microsoft Discovery is the overall agentic R&D platform. GigaTIME is one of the many AI tools that can be used on the Discovery platform to generate spatially resolved tumor microenvironment features from routine pathology, and then connect those features to downstream reasoning, validation, and iteration. GigaTIME provides population-scale, spatially resolved tumor microenvironment features derived from routine pathology.

When GigaTIME runs as a standalone notebook or point solution, the pipeline is often held together by ad hoc storage, cross-team handoffs, and manual input/output tracking (for example, whole slide images and patches in one location, predictions in another, single-cell localization outputs elsewhere, and downstream analyses in separate scripts).

In Microsoft Discovery, the pipeline is reshaped with governed ingestion, model execution, post-processing/feature extraction, and iterative reasoning. So that each stage produces typed, versioned inputs for the next instead of “files you have to hunt down”. Operationalizing GigaTIME in Discovery shifts the day-to-day experience from “run a model, then assemble context elsewhere” to “ask, explore, and iterate in one governed workspace”. In addition to that, Microsoft Discovery provides comprehensive suite of tools that transform data from sources like science catalog and AI models into actionable insights and validated findings. These tools include intelligent multi-agent orchestration, a cognitive discovery engine, a bookshelf, high-performance compute and validation of hypotheses, scientific reasoning, and an iteration framework.

Within a Discovery Platform, researcher can build customized analytics workflows for image ingestion, model inference, visualization, and these can become standardized building blocks rather than one-off analyses. Because the platform is extensible, teams can integrate additional models from Microsoft Foundry, third-party tools, or in-house pipelines alongside GigaTIME, creating a governed, end-to-end tumor immune phenotyping and discovery workflow.

Figure 10. Microsoft Discovery platform using GigaTIME as R&D tool (alongside other models, data sources, and R&D capabilities)

In the future, we expect Discovery to empower the research community to explore several other R&D applications by incorporating new models like GigaTIME alongside additional tools, datasets, experimental systems, and domain knowledge, including:

Exploring tumor responses to immunotherapy treatment by linking spatial immune context
Supporting drug-discovery research by connecting spatial phenotypes to molecular pathways and targets
Helping researchers generate hypotheses about candidate biomarkers and therapeutic targets by contextualizing population-scale signals against prior evidence in a knowledge graph.
Informing research on treatment stratification using cell-aware spatial signatures beyond bulk averages

GigaTIME and Microsoft Discovery are intended for research and development purposes. They are not medical devices and are not intended to diagnose, prevent, monitor, predict, prognose, treat, or alleviate any disease or condition. Any clinical application would require separate validation and applicable regulatory clearance.

5. From tutorial to platform scale impact

The virtual phenotyping the tumor immune microenvironment with GigaTIME shows that virtual mIF outputs are most useful value when they are localized, contextualized, and interpreted as part of a spatial system rather than isolated channels. When integrated into Microsoft Discovery, these outputs form the foundation for scalable, auditable, and collaborative oncology R&D.

With this integration, Microsoft Discovery reflects a broader shift in how AI is applied to science. The objective is no longer simply to run individual models or analyses faster, but to help evolve how R&D is conducted by embedding reasoning, learning, and orchestration directly into the scientific process. In this way, outputs from tools like GigaTIME can be translated into testable hypotheses and validated decisions.

Ultimately, this about providing tools that can help researchers examine complex systems, structure their reasoning, and iterate on their analyses.

Microsoft Discovery is now available in preview. Ready to take the next steps and try out platform with GigaTIME and any other Microsoft 1P or 3P Models available through Microsoft Foundry:

Microsoft Discovery expended preview announcement https://aka.ms/MicrosoftDiscoveryBlog

Learn and practice how Microsoft Discovery can help scientists and engineers transform research and development at https://aka.ms/microsoftdiscovery

Follow our tutorial notebook to understand how to deploy GigaTIME using Microsoft Foundry model catalog, reproduce the results described here, and understand how to use it for your own workloads: https://aka.ms/gigatime-sample

Access GigaTIME model card, learn model details and access deployment.

This post contains forward-looking statements regarding potential future capabilities, research directions, and applications of GigaTIME and Microsoft Discovery. These statements reflect current plans and expectations, are subject to change without notice, and do not constitute a commitment to deliver any functionality, feature, code, or service. Actual results may differ.

Special thanks to Microsoft cross functional team for their great support:

@Jeya Maria Jose Valanarasu, Sr. Scientist, Microsoft Research Health Futures
@Naoto Usuyama, Principal Researcher at Microsoft Research Health Futures
@Hao Qiu, Data Scientist, HLS Frontiers
@Ivan Tarapov, Senior Director, Multimodal Healthcare AI at Microsoft
@Saumil Shrivastava, Principal Product Manager, Microsoft Foundry
@Bella Chan, Principal Product Manager, Microsoft Discovery
@Ash Jogalekar, Senior Program Manager, Microsoft Discovery
@Nihit Pokhrel, Senior Product Manager, Microsoft Discovery
@Lily Kim, General Manager, Microsoft Discovery
@Samuel De Freitas Martins, Senior Director, Strategy and Partnerships
@Mu Wei, Principal Applied Science Manager, Health and Life Sciences
@Hoifung Poon, General Manager, Microsoft Research Health Futures

References

[1] U.S. Food and Drug Administration. FDA approves tisagenlecleucel for B-cell ALL and tocilizumab for cytokine release syndrome. 2017.

[2] Valanarasu JMJ, et al. Multimodal AI generates virtual population for tumor microenvironment modeling. Cell. 2026.

[3] Valanarasu JMJ, et al. Multimodal AI generates virtual population for tumor microenvironment modeling. Cell. 2026.

[4] Sood Anup et. al., Comparison of Multiplexed Immunofluorescence Imaging to Chromogenic Immunohistochemistry of Skin Biomarkers in Response to Monkeypox, Viruses 12 (8), 787

[5] Santamaria-Pang, A., et.al., Automated Phenotyping via Cell Auto Training (CAT) on the Cell DIVE Platform, 2019 IEEE BIBM,

[6] Brummel K, Eerkens AL, de Bruyn M, et al. Tumour-infiltrating lymphocytes: from prognosis to treatment selection. British Journal of Cancer. 2023.

[7] Zhao L, Jin S, Wu H. Tertiary lymphoid structures in diseases: immune mechanisms and therapeutic advances. Signal Transduction and Targeted Therapy. 2024.

[8] Sun Q, Hong Z, Zhang C, et al. Immune checkpoint therapy for solid tumours: clinical dilemmas and future trends. Signal Transduction and Targeted Therapy. 2023.

[9] Choi Y, Jung K. Normalization of the tumor microenvironment by harnessing vascular and immune modulation to achieve enhanced cancer therapy. Experimental & Molecular Medicine. 2023.

Modernizing Digital Health Record Governance with Microsoft Entra Identity Governance

Randall_Irwin — Mon, 20 Apr 2026 13:38:42 GMT

The digital transformation of healthcare continues to accelerate. Clinicians expect near-instant access to Electronic Health Records (EHRs), clinical workflows increasingly span cloud and on-premises systems, and regulatory pressures around identity, access, and auditability have never been higher.

For healthcare security and IT leaders, one challenge consistently rises to the top: ensuring the right clinicians have the right access to EHR systems—no more, no less—throughout their lifecycle.

Microsoft Entra Identity Governance was built to help address these challenges. By connecting authoritative workforce data to Microsoft Entra, automating joiner-mover-leaver processes, governing access through access packages, and recertifying access over time with access reviews, organizations can move from manual administration to policy-driven automation across the workforce lifecycle.

This represents an important evolution for healthcare organizations that have historically relied on on-premises identity tooling to synchronize data among HR systems, directories, and clinical applications. With Entra Identity Governance Microsoft provides cloud-driven identity lifecycle automation, application provisioning, entitlement management, and access reviews that can be applied to users, guests, agents, groups, and enterprise applications—including EHR systems.

EHR platforms such as Epic, Oracle Health (Cerner), and Meditech were designed to support complex clinical roles, dynamic care teams, and granular security models. Our goal with Entra Identity Governance is to simplify and automate the provisioning and lifecycle of these digital health records.

Provisioning

Provisioning starts with a source of authority. Microsoft Entra Identity Governance HR-driven provisioning creates digital identities based on human resources systems, and Microsoft’s API-driven inbound provisioning extends that model by supporting integration with virtually any system of record, including credential systems, payroll systems, spreadsheets, flat files, and SQL tables.

Once workforce data is in Microsoft Entra ID, IT administrators can standardize attribute mappings and establish the identity foundation for joiner, mover, and leaver processes. Entra Identity Governance Lifecycle Workflows can automate downstream tasks after the identity is established, helping organizations coordinate onboarding, internal moves, and offboarding with less manual effort.

From there, Microsoft Entra automatic app provisioning can create, maintain, and remove user identities and entitlements in connected applications. Provisioning is supported by using connectors, protocols, agents, and Azure function and logic apps for SCIM, LDAP, SQL, REST, SOAP, PowerShell, and even custom ECMA and API based scenarios. For healthcare organizations, that means Microsoft Entra can serve as the control plane for governed downstream access to the directories, groups, enterprise applications, and electronic health record (EHR) systems of their choice.

Entitlement Management

Provisioning establishes the identity, but Microsoft Entra Entitlement Management governs what that identity can request and maintain access to. Entitlement management is the identity governance capability that automates access request workflows and access assignments. The core construct is the Access Package, which bundles all resources a user needs together in one governed unit.

Access packages can include applications, entitlements, groups, Teams, and SharePoint Online sites. Policies control who can request access, whether approvals are required, whether business justification is collected, and how long the assignment should last. This helps organizations move away from one-off entitlement decisions and toward a repeatable, policy-driven model that is automated.

Electronic Health Records may have hundreds or several thousand granular entitlements within them. Using Microsoft Entitlement Management and Access Packages customers can model clinical roles and automatically assign entitlements to users throughout their lifecycle. This easily enables RBAC (role based access control) and ABAC (attribute based access control) scenarios. Instead of manually stitching together individual permissions, organizations can publish business-friendly access packages for healthcare roles that are approved, time-bound, and easier to audit.

Access Reviews

Assigning access is only part of the governance challenge; organizations also need a way to verify that access is still appropriate over time. Access reviews in Microsoft Entra Identity Governance help organizations manage group memberships, access to enterprise applications, and role assignments so that only the right people retain access at the right time.

Access Reviews can be scheduled or ad hoc, delegated to managers, resource owners, or users for self-attestation, and tracked for compliance or policy reasons. These reviews can be performed with business-critical application access, external users, and even scenarios where systems are disconnected from Entra ID.

When a review finishes, Microsoft Entra Identity Governance will apply the outcome and remove access from users who no longer need it. In a healthcare context, that gives security and compliance teams a structured way to recertify access to the groups, access packages, and applications tied to EHR workflows that clinicians need. Overall, this reduces access creep and maintains clearer audit evidence for ongoing governance and compliance.

Microsoft Entra Suite

You can experience the benefits described in this article by deploying Microsoft Entra Identity Governance, which is part of the Microsoft Entra Suite, the industry’s most comprehensive Zero Trust access solution for the workforce. The Microsoft Entra Suite provides everything needed to verify users, prevent overprivileged permissions, improve threat detections, and enforce granular access controls for all users and resources, including electronic health records.

Get started with the Microsoft Entra Suite with a free 90-day trial.

For additional details, please reach out to your Microsoft Representative or Microsoft Partner.

Read more on this topic

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

Healthcare and Life Sciences Blog articles

Publish Copilot Prompts to Your Whole Org in Minutes

What organizational prompts do

How to set it up

Check the analytics

Where your users find them

Do these two things after you turn it on

Fabric Data Agents can choose Query Language based on Context

Why does this use case matter?

Different Query Languages without data duplication

Video Summary

Configure Fabric Data Agent for NoDAX query patterns

Right-Sizing Intelligence: Building a Multimodal Model Portfolio for Healthcare and Life Sciences

Why “model” is now a plural

The business problem: documentation, education, and unread data

A technical walkthrough: from voice to verified note

The inputs

Which model does what

Orchestration, evaluation, and the human checkpoint

The economics at scale: right-sizing the portfolio

Governance: safety, responsible AI, and human oversight

How to start: a 30-day mini-playbook

Sources

Related links

The Agentic Workday: A Technical Deep Dive into Microsoft Scout for Healthcare and Life Sciences

The Agentic Workday: A Technical Deep Dive into Microsoft Scout for Healthcare and Life Sciences

From assistant to agent: why the shift matters in HLS

How Microsoft Scout is grounded in your work

Deep dive 1: Prior-authorization preparation

The business problem, and what it costs today

The manual process today

The agentic how-to: how Microsoft Scout would do it

Governance and compliance

How to start this week

Deep dive 2: Field medical pre-engagement briefs

The business problem, and what it costs today

The manual process today

The agentic how-to: how Microsoft Scout would do it

Governance and compliance

How to start this week

Where Cowork and Microsoft 365 Copilot fit

The throughline: do more with less, without doing less

Why AI Can't Find Your Files (And the Simple Fix)

We organize files for humans, not for AI

It comes down to metadata

Level one: the title

Level two: the top of the file

You don't need this on every file

Where this is headed

How Microsoft Scout Brings Agentic AI to Everyday Healthcare and Life Sciences Work

From answering to doing

Real-world ways HLS teams can do more with less

Built for the trust HLS demands

A family of AI that works the way you do

Start small, compound the gains

Build a Financial Dashboard in Copilot Cowork (Ideas Coach to Researcher to Build)

The problem most of us recognize

The part that changed my mind: plan in Copilot first

The bonus that made me laugh

Why "Copilot first" actually matters

Sharing it

The bigger shift

Copilot Cowork is GA - Here's how to track your credit usage as an end user

The trick: /cost

Why monitoring can matter

One honest heads-up

Try it

DLP for Copilot Prompts: How to Stop Sensitive Data From Leaving Your Tenant

Two ways to block a prompt

Building the policy

What you can see in the logs

Licensing

Where this fits

What We Took Away from Build 2026 as Microsoft Field and Solution Engineers

A new chapter of efficient foundation models for medical imaging

Introducing healthcare AI premium models

MedImageInsight Premium: a multimodal embedding model for medical imaging

CxrReportGen Premium: chest X-ray findings generation

Building our premium healthcare AI models

Responsible AI