Healthcare and Life Sciences Blog articles

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

Alberto_Santamaria — Thu, 23 Apr 2026 16:14:57 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.

Driving AI‑Powered Healthcare: A Data & AI Webinar and Workshop Series

CamilleWhicker — Fri, 10 Apr 2026 13:26:40 GMT

Across these sessions, you’ll learn how healthcare organizations are using Microsoft Fabric, advanced analytics, and AI to unify fragmented data, modernize analytics, and enable intelligent, scalable solutions, from enterprise reporting to AI‑powered use cases.

Whether you’re just getting started or looking to accelerate adoption, these sessions offer practical guidance, real‑world examples, and hands‑on learning to help you build a strong data foundation for AI in healthcare.

Date	Topic	Details	Location	Registration Link
May 6	Webinar: Microsoft Fabric Foundations - A Simple Path to Modern Analytics and AI	Discover how Microsoft Fabric consolidates fragmented analytics into a single integrated data platform, making it easier to deliver trusted insights and adopt AI without added complexity.	Virtual	Register
May 13	Webinar: Reduce BI Sprawl, Cut Cost and Build an AI-Ready Analytics Foundation	Learn how Power BI enables enterprise BI consolidation, consistent metrics, and secure, scalable analytics that support both operational reporting and emerging AI use cases.	Virtual	Register
May 19-20	In Person Workshop: Driving AI‑Powered Healthcare: Advanced Analytics, AI, and Real‑World Impact	Attend this two‑day, in‑person event to learn how healthcare organizations use Microsoft Fabric to unify data, accelerate AI adoption, and deliver measurable clinical and operational value. Day 1 focuses on strategy, architecture, and real‑world healthcare use cases, while Day 2 offers hands‑on workshops to apply those concepts through guided labs and agent‑powered solutions.	Chicago	Register
May 27	Webinar: Unified Data Foundation for AI & Analytics - Leveraging OneLake and Microsoft Fabric	This session shows how organizations can simplify fragmented data architectures by using Microsoft Fabric and OneLake as a single, governed foundation for analytics and AI.	Virtual	Register
May 27-28	In Person Workshop: Driving AI‑Powered Healthcare: Advanced Analytics, AI, and Real‑World Impact	Attend this two‑day, in‑person event to learn how healthcare organizations use Microsoft Fabric to unify data, accelerate AI adoption, and deliver measurable clinical and operational value. Day 1 focuses on strategy, architecture, and real‑world healthcare use cases, while Day 2 offers hands‑on workshops to apply those concepts through guided labs and agent‑powered solutions.	Silicon Valley	Register
June 2	Webinar: Delivering Personalized Patient Experiences at Scale with Microsoft Fabric and Adobe	Learn how healthcare organizations can improve patient engagement by unifying trusted data in Microsoft Fabric and activating it through Adobe’s personalization platform.	Virtual	Register
June 3-4	In Person Workshop: Driving AI‑Powered Healthcare: Advanced Analytics, AI, and Real‑World Impact	Attend this two‑day, in‑person event to learn how healthcare organizations use Microsoft Fabric to unify data, accelerate AI adoption, and deliver measurable clinical and operational value. Day 1 focuses on strategy, architecture, and real‑world healthcare use cases, while Day 2 offers hands‑on workshops to apply those concepts through guided labs and agent‑powered solutions.	New York	Register
June 10	Webinar: From Data to Decisions: How AI Data Agents in Microsoft Fabric Redefine Analytics	Join us to learn how Fabric Data Agents enable users to interact with enterprise data through AI‑powered, governed agents that understand both data and business context.	Virtual	Register
June 17	Webinar: Building the Intelligent Factory: A Unified Data and AI Approach to Life Science Manufacturing	Discover how life science & MedTech manufacturers use Microsoft Fabric to integrate operational, quality, and enterprise data and apply AI‑powered analytics for smarter, faster manufacturing decisions.	Virtual	Register
June 23-24	In Person Workshop: Driving AI‑Powered Healthcare: Advanced Analytics, AI, and Real‑World Impact	Attend this two‑day, in‑person event to learn how healthcare organizations use Microsoft Fabric to unify data, accelerate AI adoption, and deliver measurable clinical and operational value. Day 1 focuses on strategy, architecture, and real‑world healthcare use cases, while Day 2 offers hands‑on workshops to apply those concepts through guided labs and agent‑powered solutions.	Dallas	Register

How to Compute GPU Capacity for GPT Models (GPT‑4o and Later)

Yan_Liang — Mon, 30 Mar 2026 15:07:49 GMT

When deploying large language models like GPT‑4o, capacity planning is no longer about picking a GPU SKU. Instead, Azure abstracts GPU compute behind Provisioned Throughput Units (PTUs)—a model‑centric way to reason about GPU usage, throughput, and latency.

This post explains how GPU capacity is computed for GPT‑4o‑class models, and how to translate your workload into the right number of PTUs.

From GPUs to Tokens: The Mental Shift

With GPT‑4o and newer models, Azure does not expose GPUs directly. Instead:

GPU compute is consumed as token throughput
Throughput is measured in tokens per minute (TPM)
Capacity is provisioned using PTUs, which represent a fixed slice of GPU processing capacity

A PTU is not “one GPU.” It is a guaranteed amount of model‑processing capacity, backed by GPUs under the hood and optimized by Azure for that specific model. [learn.microsoft.com], [learn.microsoft.com]

The Key Change with GPT‑4o

For GPT‑4o and later models, input and output tokens are metered separately.

That matters because:

Input tokens (prompt processing) stress the model differently than
Output tokens (generation), which are more GPU‑intensive

Azure therefore assigns separate TPM budgets per PTU for input and output tokens.

GPT‑4o Throughput per PTU

For gpt‑4o, the effective per‑PTU capacities are:

Metric	Value
Input TPM per PTU	~2,500
Output TPM per PTU	~625
Input : Output ratio	4 : 1

These ratios are baked into Azure’s PTU calculators and provisioning logic.

The Core Formula

To compute required GPU capacity (PTUs):

Then:

Round up
Apply minimum deployment constraints (e.g., 15 PTUs for Global / Data Zone)

Step‑by‑Step Example

Assume this workload:

800 input tokens
150 output tokens
30 requests per minute

Compute TPM

Input TPM

Output TPM

Convert to PTUs

Input side

Output side

Take the bottleneck

Apply Azure’s minimum deployment size → 15 PTUs required.

This is why tables often show PTUs higher than a simple TPM ÷ constant calculation.

Why Output Tokens Matter More

Output tokens:

Are generated sequentially
Consume GPU compute longer per token
Drive latency and tail performance

That’s why GPT‑4o uses a 4:1 input‑to‑output ratio, and why output TPM often becomes the bottleneck in chatty or agentic workloads. [modelavail...bility.com]

Practical Guidance

Short prompts, long answers → output‑bound → more PTUs
Large prompts, short answers → input‑bound → more PTUs
Stable traffic → PTUs give predictable latency
Spiky traffic → consider Standard + spillover

Azure recommends validating sizing with the PTU Calculator and real traffic benchmarks before committing long‑term reservations.

Final Takeaway

For GPT‑4o and newer models, GPU sizing is token‑driven, not hardware‑driven.
PTUs abstract GPUs, and the required capacity is simply the maximum of input‑bound and output‑bound throughput needs.

Once you understand that, GPT‑4o capacity planning becomes predictable, explainable, and much easier to operate at scale.

Configuring Noise Detection and Barge‑In with Azure Voice Live API

Yan_Liang — Mon, 30 Mar 2026 14:17:45 GMT

Natural voice conversations depend on two things: knowing when a user is speaking and letting them interrupt naturally. Without reliable noise detection and barge‑in, voice agents feel rigid and frustrating—especially in real‑world environments like call centers or mobile scenarios.

Azure Voice Live API addresses this by providing built‑in noise handling, server‑side Voice Activity Detection (VAD), and native barge‑in support—all configurable with a single session update.

How Voice Live Handles Noise and Interruption

Voice Live performs server‑side speech detection on the incoming audio stream. Instead of relying on simple volume thresholds, it can use Azure Semantic VAD, which is more resilient to background noise and conversational fillers.

When enabled:

Background noise is ignored

Speech start and stop are detected automatically

User speech can interrupt the assistant mid‑response (barge‑in)

All of this happens without stitching together separate STT, silence detection, or TTS cancellation logic.

The Key Configuration: session.update

Noise detection and barge‑in are configured using the session.update event, typically sent immediately after opening the Voice Live WebSocket session from client side such as ACA or Azure function.

Below is a recommended baseline configuration:

{

"type": "session.update",

"session": {

"modalities": ["text", "audio"],

"input_audio_format": "pcm16",

"output_audio_format": "pcm16",

"input_audio_sampling_rate": 24000,

"turn_detection": {

"type": "azure_semantic_vad",

"threshold": 0.5,

"prefix_padding_ms": 300,

"silence_duration_ms": 500,

"interrupt_response": true,

"auto_truncate": true

}

What this configuration enables:

Ø Azure Semantic VAD for robust speech detection

Uses Azure’s semantic model to detect actual speech, not just sound energy. This dramatically reduces false positives from background noise.

Noise‑tolerant turn detection

True barge‑in via interrupt_response: true

Immediate stop and truncation of AI audio when interrupted

Ø threshold

Controls how sensitive speech detection is.

Lower value → more sensitive
Higher value → less sensitive

Typical values:

0.3–0.4 for quiet environments
0.5–0.7 for noisy call centers

What Happens at Runtime

Once configured:

The assistant begins speaking
The user starts talking
Voice Live detects speech server‑side
AI audio stops immediately
Unplayed audio is discarded
The user’s speech becomes the active turn
No custom interruption logic is required—your application simply reacts to speech start events.

Common Mistakes to Avoid

Sending audio before session.update
Forgetting interrupt_response: true
Using overly aggressive thresholds
Ignoring speech start events on the client

Best Practices

Use Semantic VAD in noisy environments (call centers, mobile)

Tune the threshold (higher for noisy spaces, lower for quiet rooms)

Enable echo cancellation and noise suppression on the client microphone

Always enable auto_truncate when using barge‑in

Sample JavaScript code:

import WebSocket from "ws";

const VOICELIVE_URL =

"wss://<your-resource>.services.ai.azure.com/voice-live/realtime" +

"?api-version=2025-10-01&model=<model>";

// Use Entra ID token or api-key header

const ws = new WebSocket(VOICELIVE_URL, {

headers: {

// Recommended:

// Authorization: `Bearer ${process.env.AZURE_AI_TOKEN}`

// or api-key for non-browser clients

// "api-key": process.env.AZURE_VOICELIVE_API_KEY

}

});

ws.on("open", () => {

console.log("Connected to Voice Live");

ws.send(JSON.stringify({

type: "session.update",

session: {

modalities: ["text", "audio"],

input_audio_format: "pcm16",

output_audio_format: "pcm16",

input_audio_sampling_rate: 24000,

turn_detection: {

type: "azure_semantic_vad",

threshold: 0.5,

prefix_padding_ms: 300,

silence_duration_ms: 500,

interrupt_response: true,

auto_truncate: true

}

}));

console.log("session.update sent");

});

Image Search Series Part V: Building Histopathology Image Search with Prov-GigaPath

Alberto_Santamaria — Mon, 16 Mar 2026 22:07:53 GMT

@Alberto Santamaria-Pang, Principal AI Data Scientist, Healthcare ISE and Adjunct Faculty, Johns Hopkins School of Medicine

@Asma Ben Abacha, Senior Applied Scientist, HLS AI

@Manoj Kumar, Director HLS, Data & AI HLS Frontiers AI

@Jameson Merkow, Principal Applied Data Scientist

@Mu Wei,

@Ivan Tarapov, Senior Director, Multimodal Healthcare AI at Microsoft

1. Introduction

In earlier posts, we showed how to build a practical 2D medical image search system: take an image, turn it into an embedding with a foundation model, and use similarity search to find the closest prior cases [1]. We also demonstrated why radiology + pathology together matters for cancer workflows, where imaging findings and tissue evidence complement each other and can be combined in a single pipeline [2,3]. But in real clinical practice, prediction alone isn’t enough. Doctors routinely need to pull up similar prior cases across modalities, compare patterns, and check whether what appears on MRI lines up with what is confirmed under the microscope.

This post focuses on making that workflow practical for pathology. Using a pathology foundation model (Prov-GigaPath) as a retrieval backbone, we convert pathology images into searchable embeddings, build an index, and return the most similar slides in seconds—using the same retrieval pattern introduced in the image search series [1]. Because this approach fits naturally alongside radiology representations used in multimodal pipelines, it helps close the radiology–pathology gap and supports diagnostic concordance with evidence clinicians can directly review [2,3]. An overview of the end-to-end workflow is shown in Figure 1.

Figure 1. Histopathology image search workflow with linked radiology (MRI) context.

2. Histopathology Data

Even with strong foundation models, clinicians still face a practical problem: they need to compare current cases against prior cases across radiology and pathology, not just receive a prediction. In real workflows, diagnostic concordance often hinges on questions like: “Do these MRI findings match what we see in the tissue?” and “Have we seen a similar slide pattern before, and what did it correspond to on imaging?” Our tutorial 2d_pathology_image_search.ipynb addresses this gap by treating pathology as a search problem: extract embeddings from pathology images, index them, and retrieve the most similar prior cases so clinicians can review evidence rather than rely only on model outputs.

A second problem is interoperability. Clinical systems evolve quickly, and the retrieval layer must remain usable even as models change. The architecture in this workflow is intentionally simple and model-agnostic: any foundation model that produces embeddings can plug into the same pipeline (embed → index → retrieve). In this tutorial we use pathology embeddings from Prov-GigaPath and take advantage of an existing radiology–pathology mapping (MRI linked to pathology cases) to make retrieval more impactful: once a relevant pathology case is retrieved, the corresponding radiology context can also be surfaced to support concordance. In this notebook the mapping already exists, but in practice the same idea can be extended to multi-modal indexing, where both pathology and radiology embeddings are indexed (separately or in an aligned space) so that search can pull relevant information across modalities as part of a single workflow.

For this tutorial, we use pre-computed pathology embeddings derived from TCGA-GBMLGG, a curated cohort of 170 subjects with H&E-stained histopathology slides and tumor Grade labels (0/1/2). We split the cohort into ~80% training (to build the FAISS index) and ~20% test (to evaluate retrieval performance), with each image represented as a 1536-dimensional embedding generated by GigaPath (Table 1).

Table 1. TCGA-GBMLGG dataset summary and embedding configuration

Property	Value
Total subjects	170
Split	~80% train / ~20% test
Tumor grades	Grade 0, Grade 1, Grade 2
Image type	H&E-stained histopathology slides
Embedding dimension	1536 (GigaPath)

3. Building the Image Search Engine

To build the pathology search engine, we follow the same practical steps described in the 2D image search blog: (1) turn each image into an embedding using a foundation model, (2) build a vector index (we use FAISS) over those embeddings, and (3) retrieve the nearest neighbors for any new query image. Concretely, we take a pathology image (typically a tile/patch from a whole-slide image), run it through the pathology foundation model to produce a spatial feature map, and then apply adaptive pooling to convert that variable-sized feature map into a fixed-length embedding. Adaptive pooling matters because it guarantees a consistent embedding shape even when patch sizes or resolutions vary. Without that, indexing and distance comparisons become brittle and hard to scale.

Once we can reliably generate embeddings, the rest of the search engine is straightforward: we compute embeddings for the pathology corpus, build a FAISS index (e.g., flat L2 for a baseline), and then run query → embedding → nearest neighbors to retrieve similar pathology cases. Example retrieval results across tumor grades (0–2) are shown in Figure 2. To make “similarity” more clinically meaningful, we optionally apply a lightweight adapter implemented as a small MLP, on top of the foundation embeddings. In the notebook, the adapter takes 1536-D GigaPath embeddings as input (in_channels=1536) and produces a compact 254-D representation (adapter_emb_size=254), trained with a simple 3-class objective (num_class=3, Grades 0/1/2). This is intentionally lightweight compared with retraining the foundation model: we only learn a small mapping from embeddings to a better-aligned space, then rebuild the FAISS index using the adapted vectors (gigapath_adapter_features) to improve retrieval relevance. The effect of this optimization is visualized in Figure 3, which contrasts the baseline embedding space with the adapter-optimized space.

Figure 2. Nearest-neighbor retrieval examples for Grade 0, Grade 1, and Grade 2 queries.

Figure 3. Embedding space before and after lightweight adapter optimization.

4. Results

We evaluated pathology image retrieval using cancer Grade (0/1/2) as the clinical label. For each query pathology tile/patch in the test set, we searched a FAISS index built from the training set embeddings and computed Precision@K, defined as the fraction of the top-K retrieved items that share the same Grade as the query. In the notebook, we evaluate K = [1, 3, 5], comparing baseline embeddings.

Table 2. Overall retrieval precision before and after refinement

Overall Precision@K using (i) baseline GigaPath embeddings and (ii) refined adapter-informed embeddings.

Embedding space	Precision@1	Precision@3	Precision@5
Baseline (GigaPath)	0.5795	0.5593	0.5739
Refined (adapter-informed)	0.7727	0.7967	0.7689

Overall retrieval quality improves substantially after refinement (Table 2), with consistent gains across all K values, indicating that nearest neighbors become more aligned with Grade-consistent similarity.

Table 3. Precision by cancer Grade before and after refinement

Precision@K stratified by pathology cancer Grade (0/1/2) for baseline vs refined embeddings.

Grade	Baseline P@1	Baseline P@3	Baseline P@5	Refined P@1	Refined P@3	Refined P@5
0	0.5000	0.5000	0.5500	0.6250	0.6667	0.6250
1	0.3636	0.3030	0.3091	0.8182	0.8485	0.7818
2	0.8750	0.8750	0.8625	0.8750	0.8750	0.9000

Performance differs by Grade (Table 3). Baseline retrieval is strongest for Grade 2, moderate for Grade 0, and weakest for Grade 1, suggesting Grade 1 is the most challenging cohort under raw embeddings. After refinement, Grade 1 improves markedly across all K values, while Grade 2 remains high and improves slightly at deeper retrieval (P@5).

Table 4. Absolute improvement in precision after refinement

Absolute change (Δ = refined − baseline) in Precision@K, overall and by Grade.

Cohort	Δ Precision@1	Δ Precision@3	Δ Precision@5
Overall	+0.1932	+0.2374	+0.1951
Grade 0	+0.1250	+0.1667	+0.0750
Grade 1	+0.4545	+0.5455	+0.4727
Grade 2	+0.0000	+0.0000	+0.0375

As summarized in Table 4, the improvements are driven primarily by Grade 1 (ΔP@1 = +0.4545; ΔP@3 = +0.5455; ΔP@5 = +0.4727). Note on Grade 2: ΔP@1 and ΔP@3 are 0.0000 because baseline retrieval for Grade 2 is already high (P@1 = 0.8750, P@3 = 0.8750; Table 3), so the adapter does not change top-1/top-3 correctness for that cohort. The improvement appears at deeper retrieval (ΔP@5 = +0.0375), suggesting the adapter mainly refines ranking beyond the top few results rather than increasing an already strong “hit rate.”

Collectively, these results indicate that the refined embedding space makes similarity more grade-consistent, which is exactly what diagnostic concordance workflows need: when clinicians retrieve “similar” pathology cases, they want those neighbors to reflect clinically relevant groupings (here, tumor grade), and to remain interpretable when linked to the corresponding radiology context. The fact that Grade 1 benefits most is also plausible from a pathology standpoint: intermediate grades often show more overlap in morphology with both lower and higher grades (i.e., less separable visual patterns), while higher grades may exhibit more distinctive features that are easier to retrieve correctly even without refinement. In that sense, the lightweight adapter acts as a targeted calibration step: shaping the embedding space so that ambiguous, overlapping cases (like Grade 1) are pulled closer to the right neighbors.

Figure 4. Histopathology (H&E) retrieval with linked radiology (MRI) context.

5. Conclusion

We built a practical histopathology image search engine using a simple, reusable pattern: generate Prov-GigaPath embeddings from pathology tiles (with adaptive pooling to produce fixed-length vectors), index them with FAISS, and retrieve nearest neighbors for any query. This matters because retrieval makes foundation models actionable for clinicians, returning similar prior examples that can be reviewed and compared, rather than only producing a prediction score. The implementation is lightweight and interoperable: once embeddings are available, the remaining steps are standard vector indexing and search, and the same design naturally extends to multimodal workflows by linking retrieved H&E cases to their corresponding MRI context (or by indexing radiology and pathology embeddings side-by-side for cross-modal lookup).

Image Search Series: Blog Posts & Jupyter Notebooks

The Microsoft healthcare AI models, including MedImageInsight, 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.

References

[1] Image Search Series Part 1: Chest X-ray lookup with MedImageInsight | Microsoft Community Hub
[2] Cancer Survival with Radiology-Pathology Analysis and Healthcare AI Models in Azure AI Foundry (Microsoft Healthcare & Life Sciences Blog) [3] Adapter training notebook (MedImageInsight). Microsoft healthcareai-examples GitHub repository (azureml/medimageinsight/adapter-training.ipynb)

Agents: Snack Pack

samhitaraman — Fri, 06 Mar 2026 01:07:32 GMT

It’s not just you.

Agents are everywhere, and everyone else seems to know exactly what they are.

If you’ve been nodding along while secretly thinking “I should probably look this up"... you've found the right place!

This Agents Snack Pack contains easy‑to‑digest content designed to help you understand agents, one piece at a time. Content is arranged from left to right in order of increasing complexity. If you're starting out, begin with Column 1 (Access) and progress as you build confidence!

#1. Discover

#2. Use

#3. Build

Drill in the fundamentals:

What are Microsoft 365 Copilot agents and how to use them | Microsoft

Ask big questions, let Researcher do the investigation.

Researcher: A reasoning agent in Microsoft 365 Copilot

Create your first agent:

Microsoft 365 Copilot Chat - Agent builder demo

Explore the Agent Store:

Agent Store in Microsoft 365 Copilot

When spreadsheets get messy, call in Analyst.

Analyst: A reasoning agent in Microsoft 365 Copilot - YouTube

*Create an Epic Tip Sheet Agent: https://youtu.be/ilL5j5qBdpE

*Agent requires premium Copilot license

Practical use cases:

Sales: Microsoft 365 Copilot Chat - Sales agent demo

Customer Service: Microsoft 365 Copilot Chat - Customer service agent demo

Demo: Leveraging Analyst to break down hospital occupancy data

https://youtu.be/0OG6yTpZoMU

*Build your first autonomous agent:

How to create an autonomous agent with Copilot Studio

*Agent requires premium Copilot license

Hungry for more? Join our live, instructor-led AgentRx sessions to get hands on guidance with Microsoft experts.

Bringing Organizational Knowledge into the Clinical Workflow

BertHoorne — Thu, 05 Mar 2026 17:40:47 GMT

This blog is co-authored by Hadas Bitran, Partner GM, Health AI, Microsoft Health & Life Sciences

Every day, clinicians spend valuable time looking for information that lives in different places. An email thread from a specialist colleague. A Microsoft Teams discussion about a complex case. Updated organizational processes buried in SharePoint or OneDrive. This information provides context that could be critical to their workflows or help inform their decisions. But that context is not part of their clinical workflow.

The result? Clinicians are forced to break their clinical workflow, searching manually across organizational resources, and mentally combining scattered data points, all while a patient is waiting. This isn't a knowledge problem. It's a retrieval problem. And it's costing time, focus, cognitive burden and clinical confidence every single day.

That's exactly the gap we're closing by bringing clinical intelligence and your organization's knowledge into one seamless, workflow-native experience.

Clinical workflow, now with your organizational context

Within Dragon Copilot, clinicians will be able to securely surface relevant information across Microsoft 365, without leaving the clinical workflow:

Email: retrieve relevant information that was exchanged with patients, colleagues or from specialist correspondence, referral communications, or care coordination threads.

find me the email from Dr. Ting that mentioned the latest research about this mutation.
In this example, the chat functionality in Dragon Copilot uses the patient and encounter context to resolve the referenced mutation, then leverages Microsoft 365 Copilot behind the scenes to locate the email from Dr. Ting that mentions it.
Microsoft Teams: surface information from Microsoft Teams chats that the clinician had with colleagues, discussions or group chat conversations.

The patient is traveling to Florida. Identify dialysis centers near the patient’s destination based on information shared by Dr. Salomon in Microsoft Teams and provide practical travel guidelines I can share with the patient.
In this example, Dragon Copilot uses trusted sources for travel guidelines and Microsoft 365 Copilot to retrieve relevant Microsoft Teams messages from Dr. Salomon, identifying nearby dialysis centers in Florida.
SharePoint and OneDrive: access organizational knowledge on demand: HR policies, facility procedures, compliance guidelines, shift schedules, and more

Who is on call for nephrology tonight and who is covering tomorrow morning?

In this example, Dragon Copilot leverages Microsoft 365 Copilot behind the scenes to locate the most up‑to‑date Excel file with upcoming shift and coverage information from the hospital’s SharePoint, and surfaces the answer directly in the conversation, without disrupting the clinician’s workflow.

With Microsoft 365 Copilot, work context is available directly inside Dragon Copilot, clinicians can choose if, and when to access their work information. Within Dragon Copilot, they can ask questions in natural language and receive the most relevant information, grounded in patient context, from trusted clinical sources and their Microsoft 365 data. One conversational flow. Full clinical and work context. No tab switching, no manual searching, no lost focus.

Trusted by design, built for healthcare

Security and privacy are built in from the ground up. Information is always accessed on behalf of the individual user, fully respecting existing Microsoft 365 identity and access management, compliance, and privacy controls, meaning clinicians see only what they're authorized to see, and that Dragon Copilot will only use their work context if the clinician consented to it. This also means no new security risks to manage, and no changes to how your organization governs access to information.

For healthcare organizations where data sensitivity, regulatory compliance, and patient privacy are non-negotiable, this better-together experience is designed to meet that bar from day one.

Join the Private Preview

If you're a Dragon Copilot customer, and your organization is using Microsoft 365 Copilot, we invite you to be among the first to experience this new capability. Register now for early access to the private preview and play a role in shaping the future of clinical workflow intelligence.

Register for private preview

Dragon Copilot centralizes trusted medical content and relevant contextual information in-workflow

hadasb — Fri, 06 Mar 2026 15:00:20 GMT

This blog is co-authored by Bert Hoorne, Principal Program Manager & Ksenya Kveler, Principle Medical Science Manager

Dragon Copilot delivers medical intelligence from trusted sources directly within clinical workflows for healthcare organizations in one solution.

We are pleased to announce that we are expanding those knowledge sources with additional best‑in‑class content providers and enabling broader access to your organization’s internal sources with Microsoft 365 Copilot integration.

Access information from new credible medical content providers

Dragon Copilot users will gain access to an additional robust collection of

trusted clinical content from leading evidence-based resources. We are partnering with renowned publishers to bring you the best, most trusted content, safely and securely, within clinician’s workflows while helping to reduce the use of unauthorized AI tools and applications, commonly referred to, as “shadow AI.”

Access content from Wolters Kluwer UpToDate

We’ve partnered with Wolters Kluwer UpToDate to bring trusted, evidence-based clinical guidance directly into Dragon Copilot. Customers with an active Wolters Kluwer UpToDate license will be able to access UpToDate content in Dragon Copilot, within the context of their clinical workflows.

This integration allows clinicians to ask both general questions and patient specific questions and receive answers grounded in UpToDate evidence, with clear references to supporting sources. Over time, it will also introduce contextual links to UpToDate concepts layered on top of Dragon Copilot–generated notes, further enhancing clinical insight at the point of care.

“Clinicians need reliable guidance that supports fast, confident decision-making without disrupting care delivery. We are excited to partner with Microsoft to bring UpToDate’s gold standard evidence and expertise-based clinical insights to Dragon Copilot, helping clinicians quickly access, actionable answers that reduce cognitive burden and support better patient care.”

Yaw Fellin, Senior Vice President and General Manager, UpToDate Clinical Decision Support and Provider Solutions
Wolters Kluwer Health

Here’s an example of UpToDate content embedded in the Dragon Copilot workflow:

Wolters Kluwer UpToDate powering Dragon Copilot Chat answers

Obtain trusted clinical evidence with Elsevier ClinicalKey AI

Elsevier’s ClinicalKey AI will be available in Dragon Copilot. This integration enables customers with an active Elsevier ClinicalKey AI license to surface trusted medical literature and clinical evidence directly within clinicians’ workflows.

“Clinicians are navigating a complex and rapidly changing healthcare landscape and need solutions they can trust. The ClinicalKey AI extension for Dragon Copilot transforms how clinicians interact with trusted medical literature and clinical answers. The conversational interface makes evidence discovery faster and more intuitive.”

Jukka Valimaki, SVP Clinical Solutions
Elsevier

Here’s an example of ClinicalKey AI content embedded in the Dragon Copilot workflow:

Support clinical decisions with EBMcalc

With the integration of EBMcalc medical calculators, Dragon Copilot enables clinicians to use evidence-based calculators directly within their workflows—applied in context to the patient they’re caring for.

“Clinicians need trusted, evidence-based insights exactly at the point of care. By integrating EBMcalc’s rigorously curated clinical calculators and references into Dragon Copilot, we’re helping make high quality medical evidence more accessible, more actionable, and easier to use within everyday clinical workflows”.

Louis Leff, MD, MACP, Founder and CEO
EBMcalc

Access independent evidence in Dragon Copilot with Wiley and Cochrane

Wiley and Microsoft are partnering to bring scientific literature and clinical evidence directly into the healthcare workflow, starting with the Cochrane Library. Through this integration, customers with an active Cochrane Library AI license will be able to access Cochrane’s high-quality, independent evidence, systematic reviews, and clinical answers, to inform more reliable and efficient decision-making. This includes the Cochrane Database of Systematic Reviews (CDSR), the home of gold-standard evidence syntheses, widely used to inform clinical guidelines worldwide.

"Working with Microsoft to bring the Cochrane Library into Dragon Copilot reflects a shared commitment to meeting researchers and clinicians where they are. Healthcare Institutions can now access independent, peer-reviewed evidence— right within their clinical workflow”

Josh Jarrett, SVP & GM of AI Growth
Wiley

Access work context with Microsoft 365 Copilot in Dragon Copilot

With the Microsoft 365 Copilot integration, Dragon Copilot enables clinicians to seamlessly access information from their emails, chats, OneDrive and SharePoint, within the flow of their clinical work. Clinicians can combine this information with additional questions and actions, all governed by existing organizational and user access controls. Use of this data within Dragon Copilot workflow remains fully at the user’s discretion.

Here’s an example of content from an email surfaced by Microsoft 365 Copilot accessible through the Dragon Copilot workflow:

Microsoft 365 organizational context in Dragon Copilot

Read more for a deeper dive on how Dragon Copilot enables work context access with Microsoft 365 Copilot integration.

Safe web search

Dragon Copilot safe web search delivers trusted, evidence linked answers when curated sources are unavailable—ensuring clinicians continue to receive timely support without disrupting their workflow.

The goal of safe web search is to prevent broken workflows and eliminate unsafe external browsing. Clinicians remain within their clinical context, focused on the patient—without tab hopping or the risk of landing on unreliable or unverified websites.

Safe web search eliminates “no response” dead ends by maintaining a seamless conversational experience in Dragon Copilot and reducing unanswered prompts.

This capability is enabled by using verified, secure, and responsible mechanisms designed for safe clinical experiences. It enforces multilayer protection through evidence validation, provenance linked responses, content filtering, and regulated search with built in safeguards.

Here’s an example of content from a safe web search in the Dragon Copilot workflow:

Conclusion

These advancements represent an important step forward in how Dragon Copilot delivers trusted medical intelligence - bringing together best‑in‑class clinical evidence, organizational knowledge, and safe web access in one governed, in‑workflow experience. We will continue to expand our partner ecosystem, deepen integrations with leading evidence providers, and evolve Dragon Copilot conversational extensibility to meet clinicians where they work.

Why nursing needs a different kind of AI—and how Dragon Copilot delivers

Allison_Novick — Thu, 05 Mar 2026 14:30:00 GMT

The Dragon Copilot experience for nurses was made generally available (GA) in December 2025 with a clear mission: help nursing staff focus on care, not the computer.

From the start, the goal was to create a comprehensive AI clinical assistant—one that works alongside nurses throughout their shift, reduces cognitive load, captures the full scope of care delivered, and translates real clinical work into automated next steps, including documentation—fundamentally transforming workflows to keep patient care at the center.

Microsoft has continued to execute on that vision. Recent enhancements include extended mobile access with Android support—enabling nurses to record care in Epic Rover on Android devices—as well as significant expansion in ambient documentation coverage. Together, these advances reflect a consistent approach: adoption follows when technology aligns with how nurses work.

Expansive nursing documentation coverage

Nursing work spans multiple flowsheet templates, assessments, state changes, and, at times, narrative notes. When solutions support only a subset of this work, nurses are left filling gaps after the fact—reintroducing cognitive load and eroding the value of this technology.

Microsoft has expanded Dragon Copilot’s ambient documentation capabilities by broadening the range of supported nursing value types—and by extending it to deliver complete coverage across all flowsheet templates in supported departments and settings. The result is comprehensive documentation generated from each recording including:

Lines, Drains, Airways, and Wounds (LDAs) documentation, including assessments, additions, and removals
Nurse notes, automatically generated from natural nurse-patient conversations and voice memos captured on the go
Full flowsheet template coverage—not just a subset—including admission and discharge flowsheets, blood administration, CIWA-Ar, and care plan-related flowsheets
Adaptations to each organizations charting philosophy, including macros support, chart-by-exception, pertinent positives, and more

This breadth matters because nursing work is rarely captured within only a narrow set of flowsheets—nor does it typically result in just narrative notes. Yet many solutions labeled “for nurses” prioritize what is easiest to automate, rather than what nurses need. The result can be a false sense of completeness, with nurses still managing gaps across their shift.

Why nursing ambient documentation is hard—and what makes Dragon Copilot unique

Achieving comprehensive, high‑quality nursing documentation has required specialized technology designed to address the structural, workflow, and feedback challenges unique to nursing—challenges that general narrative ambient models and physician‑oriented solutions are not built to solve:

Flowsheets are messy, complex, and frequently changing
Flowsheets are large, hospital-specific, internally ambiguous, and constantly evolving under governance. Complex logic—such as cascading rows, documentation‑by‑exception patterns, and duplicative or overlapping rows—makes it far from straightforward to accurately map a clinical observation to the correct field and value. Microsoft works directly with real hospital schemas, handling hierarchy, ambiguity, and multiple valid documentation destinations—without requiring flowsheet redesign or sacrificing quality.
Nurses don’t speak for documentation
Bedside language is optimized for care delivery, not chart completeness. Critical details are often implied or never spoken aloud. Microsoft’s technology translates natural nursing communication into accurate documentation without changing nurse behavior. Built on industry‑leading transcription accuracy and decades of speech recognition expertise, Dragon Copilot is informed by real‑world integration across diverse EHR environments, preserving accurate translation and clinical intent that directly impact downstream documentation accuracy.
Nursing audio is diverse
Recordings mix shorthand, dialogue, monologue, and unit-specific language. Dragon Copilot accounts for mixed speaking modes instead of flattening audio through a generic pipeline or requiring nurses to speak in constrained ways.
Feedback loops are noisy
Nurse corrections to AI output often reflect hindsight or personal preferences rather than model error. Microsoft’s approach analyzes correction patterns with clinical context, enabling calibration at the institution, department, and even individual user level.
Bedside workflows demand predictability
Baseline LLMs are not suited for real-world nursing accuracy, latency, and cost requirements — especially with tens-of-thousands of possible flowsheet values. Dragon Copilot is optimized for consistent performance across real nursing environments, exceeding the reliability and latency characteristics of baseline models.

Beyond specialized nursing architecture, Dragon Copilot enforces strict quality and safety gates for new documentation outputs—including oversight by Microsoft’s internal, nurse-led Clinical Integrity team, phased validation, and Responsible AI review—ensuring new documentation covered meets defined nursing standards before being introduced at scale.

Dragon Copilot represents a fundamental shift in how nursing work is supported by AI by meeting the full complexity of bedside care head-on. By delivering comprehensive ambient documentation across live inpatient care environments, Dragon Copilot helps ensure that the care nurses provide is accurately captured, trusted, and usable downstream. The result is an AI clinical assistant that keeps nurses focused on what matters most: their patients.

From dictation to intelligence at the cursor with Dragon Copilot Desktop

James_Jeffries — Mon, 09 Mar 2026 13:24:33 GMT

This blog is co-authored by Dr. David Ting, Chief Clinical Product Lead, and Sarah Grey, Senior Product Manager.

Today’s patient encounters are packed with friction that breaks clinicians’ flow, clouds clinical thinking, and drains the joy from practice. Instead of focusing on patients, listening, assessing, and collaborating on care, clinicians spend visits staring at a screen, wrestling with bloated EHRs, and acting as data entry clerks. They type into endless fields, check boxes, click buttons, and memorize arcane text shortcuts and key sequences designed to satisfy computer hard-stops, regulatory tests, and payer demands, not to deliver compassionate, high-quality care.

And it doesn’t stop with the EHR. Clinicians bounce between imaging systems, referral portals, messaging apps, mobile devices, specialty tools, and the nonstop demands of email, policies, training, credentialing, and CME. Managing care across dozens of disconnected systems every day makes one thing clear: clinicians and healthcare organizations are desperate for relief.

Can artificial intelligence help? Of course it can. But hope in AI is too often disappointed by the reality of AI solutions that are poorly integrated with each other and with clinicians’ holistic workflow. AI risks being trapped in a single application like the EHR, leading to disjointed and suboptimal experiences.

But if AI lives in a separate window from where clinicians actually work, it risks adding another source of friction, forcing context switching and manual copying and pasting across the EHR and other systems.

What clinicians need is a way to access a seamless clinical intelligence everywhere they work. This is precisely what Dragon Copilot brings to the beleaguered physician, nurse, and advanced practice provider.

Extending the power of AI to remove friction

The reality for most clinicians is that their patients’ information and care coordination is managed in an EHR and via complementary apps living on the Windows desktop. If an AI clinical assistant is to be helpful, it must be available anywhere the clinician is working, regardless of which of the many desktop applications happen to be in focus. As the clinician moves from the EHR to a PACS viewer, web browser, email client, or Teams meeting, the AI should be able to understand the underlying context and offer ways to streamline the clinician’s flow.

Dragon Copilot’s AI changes the dynamic. When editing text anywhere – in the EHR, in Outlook, Word, a web browser app, or within Dragon Copilot’s own editor – a clinician simply selects desired text, speaks or types a natural language instruction (e.g., “Expand this paragraph to reflect more of the patient’s description of the car accident”), and receives an inline rewrite or insertion directly in the target application.

A clinician searching for information can simply place their cursor over the text, and Dragon Copilot understands the context, allowing the clinician to make multi-part requests: “Given this diagnosis, what is the recommended treatment, and are any of those covered by the patient’s insurance plan?” Dragon Copilot gathers context, searches through approved, trusted knowledge sources, and provides the answer within the Dragon Copilot workflow.

Here’s another example: while reviewing an online guideline or internal protocol in the organization’s SharePoint, a clinician can select a passage and ask, “Give me the three key takeaways from this reading and summarize them in patient-friendly language to include in the after-visit summary.” The clinician receives the in-context summary directly in workflow.

Dragon Copilot overcomes EHR-constrained AI and disconnected tools by unifying and delivering intelligence in one centralized workspace.

Dragon Copilot is the AI clinical assistant connecting fragmented systems

Care doesn’t happen in a single app. Even though the EHR is the system of record, clinicians still do significant work outside of it. Yet EHR-based AI cannot reach outside the EHR itself. And most third-party tools don’t (and won’t) ship deep AI integrations quickly.

The result is a frustrating array of AI-powered experiences that can only perform a part of the required task – such as an EHR ordering agent that cannot read the hospital formulary in SharePoint, or a third-party coding solution that cannot automatically map the provider’s visit diagnoses. That leaves the clinician in an unhappy position of needing to be data courier, manually copying information from one application to the other, rather than spending time taking care of the patient.

Dragon Copilot acts as the connective tissue across that fragmentation. By working with standard text controls, it can bring a consistent interaction model, including dictation, commands, and cursor-native AI, across the clinical workflow.

Shifting from speech dictation to natural language editing

Over 650,000 providers worldwide have benefited from computerized speech-to-text dictation using Dragon Medical One. Traditional speech-to-text systems, like Dragon Medical One convert spoken audio into text word for word, like a courtroom transcript. But Dragon Copilot provides a new way to turn language into clinical content, in addition to capturing patient encounters ambiently.

With Dragon Copilot, clinicians can just say what they want by speaking naturally. They can instruct Dragon Copilot to perform targeted edits (“Summarize the HPI in two sentences”) and issue high-leverage whole-document edits that used to be tedious. Clinicians can even talk naturally to create documentation from scratch in new ways:

“Using only the details already documented, draft an HPI and list a few clarifying questions to ask.”

“Update the patient’s pronouns throughout the note (don’t change clinical facts).”

“Rewrite the entire note in a more concise style, preserving meaning and keeping all facts the same.”

“Write the A&P using my standard knee template with a conservative treatment plan.”

These are new use cases where a short instruction can yield large, efficient edits. And for Dragon Medical One users who have benefitted from Dragon Medical One voice macros (called Step-By-Step commands) and custom vocabularies, these are all transferrable to Dragon Copilot.

The cursor becomes a reusable (and extensible) primitive

The cursor provides a dependable, ubiquitous interface for AI. While EHRs and complementary clinical and non-clinical applications may present vastly different UIs, they generally rely on the underlying operating system to provide the same cursor. Hence, users have come to expect a common behavior and access to a core set of functions associated with the cursor, regardless of the underlying application. Thus, the cursor defines scope (selected text vs. current field), intent (summarize, rewrite, extract), and placement (results appear where the clinician expects them).

In-workflow, cursor-anchored AI like Dragon Copilot’s turn that repeatable pattern into a platform primitive—a foundational, reusable building block that developers can rely on to deliver consistent experiences across applications. For Microsoft developers as well as third-party extension partners, this platform primitive provides experience extensibility: app teams and agent developers will be able to deliver new skills at the cursor through Dragon Copilot. Rapid expansion of Dragon Copilot capabilities becomes possible, because internal and partner developers can focus on the capabilities themselves instead of reinventing the UI. And end-users benefit from a coherent, always-discoverable, always-available experience.

Cursor-anchored AI can be safer and more trustworthy, especially with integrations

Healthcare demands trust. Cursor-anchored AI keeps actions tied to what the clinician can see and edit, and it makes output reviewable, editable, and reversible.

That doesn’t mean ignoring backend-integrated context. The goal is to combine the value of integrations with an interaction model that keeps scope clear: what the AI acted on, what it used, and what it produced, so clinicians stay in control.

Conclusion: Dragon Copilot on the desktop unifies fragmented systems and delivers a seamless cross-application intelligence in one solution

Dragon Copilot represents the next and necessary step in the evolution of healthcare AI. With today’s status quo, clinical use of generative AI is largely restricted to algorithmic clinical decision support or ambient documentation creation. Clinicians are still faced with disparate AI systems that are either tightly bound to EHRs but limited in scope beyond the EHR, or poorly integrated with the EHR, such that the AI systems lack sufficient visibility into patient context or require manual data extract, transform and load. In either case, clinicians are stuck with the role of being human data couriers; and that is still a far cry from the patient-clinician relationship they went to medical school or nursing school to practice.

With Dragon Copilot, AI isn’t “somewhere else.” It is intelligence embedded in the act of information gathering, analyzing, synthesizing, writing, revising, deciding, and executing. It is AI assistance right where you work. It represents less context switching, better notes, and stronger knowledge work support.

Dragon Copilot brings AI into revenue cycle workflows

James_Jeffries — Thu, 05 Mar 2026 17:51:44 GMT

This blog is co-authored by Josh Waldo, Product Manager, Joeri Van der Vloet, Principal Research Manager, and Koen Mertens, Senior Research Manager.

Many health systems treat revenue cycle performance solely as a downstream problem. Clinicians complete documentation, teams send notes to coders, queries follow, and everyone works backward to recover what was missed. In some cases, recovery isn’t even possible in this model. With the rise and pervasiveness of AI, there is an opportunity to rethink the model by improving documentation quality and comprehensiveness at the point of care. In this new model, reimbursement accuracy can be captured before the opportunity has been lost.

In this blog post, we walk through three powerful approaches we use in Dragon Copilot to support revenue cycle management (RCM):

Embed revenue cycle intelligence directly into the clinical workflow, delivering built-in guidance as documentation is created—while the patient is still in the room—to ensure critical details are captured.
Deliver that intelligence directly into existing EHR workflows wherever possible.
Extend RCM capabilities through an open ecosystem, enabling specialized partners to bring their coding expertise directly into the same workflow.

Clinicians document using Dragon Copilot while revenue relevant insights surface in context before notes ever move downstream. The result is better reimbursement accuracy, fewer back and forth exchanges, and less rework for clinicians and revenue cycle teams.

The problem, the opportunity, and the shape of a workflow solution

Most revenue cycle friction traces back to incomplete or imprecise documentation. Missing specificity, unclear assessments, and undocumented work create queries, denials, delays, and rework. The opportunity is to move RCM support upstream to the point where documentation is being created, with help that is context aware, transparent, and clinician controlled.

Solutions must analyze the patient, context and resulting documentation as they are created and surface opportunities related to:

Diagnosis specificity and diagnostic comprehensiveness

HCC capture and recapture opportunities

Evaluation and management (E/M) level considerations

Completeness of documentation relative to established criteria, like MEAT (monitor, evaluate, assess, treat)

Prior authorization guidelines

Complete capture of CC’s/MCC’s and other inpatient guidance

The shape of the solution must also provide assistance that shows up inside the documentation flow. It should feel like a light touch and not a separate destination or a stream of alerts. The design goal is to minimize distraction, avoid overwhelming notifications, and make every suggestion easy to review with clear evidence. Further, the nudges need to be actionable. With the click of a button, a clinician should be able to accept/reject the insight and have the appropriate actions then ensue, such as updating documentation automatically.

Small improvements may look modest in a single note, but they compound across clinicians and visits when applied consistently. If we can help clinicians capture the full clinical picture once, downstream processes inherit better inputs without asking clinicians to do a second pass.

Recognizing the scope of RCM opportunities in both ambulatory and inpatient, we are taking a three-pronged approach to help healthcare organizations enable the broadest and deepest set of coding skills into their Dragon Copilot workflows.

Built-in suggestions

Dragon Copilot already provides built-in capabilities that support RCM by improving the note itself, and we are continuing to expand them. We start by capturing all the minute details of what happened during the encounter and helping clinicians turn that into clear and comprehensive documentation. The goal is accurate and complete capture of the work performed and the patient complexity.

Dragon Copilot also supports on-demand billing code support. For each documented diagnosis, we can suggest relevant ICD-10 code options with supporting evidence so clinicians can quickly validate what is being proposed. We can also generate a coding summary report for each note to support downstream review.

Next, Dragon Copilot includes built‑in, proactive diagnosis specificity suggestions designed to support clinicians in selecting the most accurate and specific diagnoses at the point of documentation. As clinical notes are created, Dragon Copilot analyzes the documented clinical context and identifies opportunities where a diagnosis may be underspecified or incomplete.

When applicable, Dragon Copilot surfaces suggestions to refine a diagnosis (for example, laterality, acuity, severity, underlying cause, or associated conditions). For risk‑adjusted conditions, it helps clinicians identify diagnoses that may impact Hierarchical Condition Categories (HCCs), while emphasizing the need for complete, clinically appropriate, and defensible documentation.

All suggestions are advisory and designed to fit naturally into the clinician’s workflow. Clinicians remain fully in control, able to review, accept, modify, or ignore suggestions based on their clinical judgment. It does not add diagnoses automatically and does not replace clinical decision‑making. Its goal is to reduce missed specificity, support accurate clinical representation of patient complexity, and help ensure documentation aligns with coding and compliance expectations.

At a user experience level, we want this to be simple and predictable as outlined in this workflow:

The clinician documents using Dragon Copilot’s suite of documentation tools.
Once the note is drafted, a set of relevant suggestions to refine a diagnosis is surfaced discreetly in workflow
Each opportunity includes the why, the evidence, and a suggested improvement.
The clinician can accept, ignore, or defer, and stays in control at every step.
The note is improved before it reaches coding, reducing the need for back-and-forth exchanges later.

Done well, this approach improves documentation quality without changing clinical practice. It reduces avoidable queries, supports more consistent coding outcomes, and helps revenue cycle teams spend less time on cleanup.

Looking ahead, these built-in proactive capabilities will be extended into additional high value areas such as E/M level considerations and completeness expectations such as MEAT (monitor, evaluate, assess, treat).

Integrated EHR context and workflow

Deep EHR connectivity is a force multiplier because it provides context and continuity. With the right backend integrations, Dragon Copilot can leverage chart data to understand the patient history, current problems, and the broader clinical picture that surrounds the encounter.

For example, this can include access to relevant prior notes, the problem list, medications, allergies, labs, imaging results, and structured diagnoses already documented in the chart.

This context helps us enrich the completeness and accuracy of notes before anything is presented to the clinician.

Connecting directly to EHR workflows also matters. When insights and supporting evidence can be presented in the same places clinicians already review the chart, reconcile problems, place orders, and finalize documentation, we reduce context switching and increase the likelihood that improvements happen at the right moment.

We are already building these powerful workflows with some of the most widely used EHRs in the world and are bringing the ability to get diagnosis specificity directly in workflow as one example.

This is also where we can align RCM support with clinical actions. Suggestions should appear when they are most useful, such as while the diagnoses are reviewed and the note finalized.

This strategy is also about trust and safety. Clinicians should be able to see where a suggestion comes from, what it is based on, and why it matters, without leaving their workflow.

Partner extensions

RCM is complex and it looks different across organizations, service lines, and care settings. No single approach fits every health system and covers all the targeted needs. An ecosystem approach allows specialized partners to bring their expertise into the same workflow. With an open ecosystem, any partner can integrate coding into workflow in a self-service and standardized fashion, opening coding at scale and giving health systems the widest range of options to choose from.

We see some of the most developed expertise and exciting innovations coming from our partners. Dragon Copilot now serves as a consistent channel into the workflow, so our partners can deliver value without having to reinvent access to encounter context, user experience patterns, and distribution inside the EHR.

Examples of what partner extensions can enable include:

Specialty specific documentation guidance that reflects local policy and payer mix.
HCC program support that includes organization specific rules for capture and recapture.
Prior authorization support that highlights requirements earlier, when care decisions are being made.
CC’s/MCC’s identification to accurately capture O/E ratios

The goal is to let health systems choose what to enable, where to enable it, and for whom, while keeping the clinician experience consistent and limiting disruption.

Patient-first is the best revenue cycle strategy

The most effective revenue cycle strategy starts with patients, not paperwork. Dragon Copilot augments clinician care, helps capture the full patient story, and supports accurate reimbursement as a byproduct of good clinical documentation.

When technology fades into the background and supports clinicians without interrupting care, everyone benefits: clinicians reclaim time, revenue cycle teams see fewer issues, and health systems are reimbursed accurately for the care they provide.

Can you use AI to implement an Enterprise Master Patient Index (EMPI)?

dondinulos — Thu, 05 Mar 2026 05:54:21 GMT

The Short Answer: Yes. And It's Better Than You Think.

If you've worked in healthcare IT for any length of time, you've dealt with this problem.

Patient A shows up at Hospital 1 as "Jonathan Smith, DOB 03/15/1985." Patient B shows up at Hospital 2 as "Jon Smith, DOB 03/15/1985." Patient C shows up at a clinic as "John Smythe, DOB 03/15/1985."

Same person? Probably. But how do you prove it at scale — across millions of records, dozens of source systems, and data quality that ranges from pristine to "someone fat-fingered a birth year"?

That's the problem an Enterprise Master Patient Index (EMPI) solves. And traditionally, it's been solved with expensive commercial products, rigid rule engines, and a lot of manual review.

We built one with AI. On Azure. With open-source tooling. And the results are genuinely impressive.

This post walks through how it works, what the architecture looks like, and why the combination of deterministic matching, probabilistic algorithms, and AI-enhanced scoring produces better results than any single approach alone.

1. Why EMPI Still Matters (More Than Ever)

Healthcare organizations don't have a "patient data problem." They have a patient identity problem.

Every EHR, lab system, pharmacy platform, and claims processor creates its own patient record. When those systems exchange data via FHIR, HL7, or flat files, there's no universal patient identifier in the U.S. — Congress has blocked funding for one since 1998.

The result:

Duplicate records inflate costs and fragment care history
Missed matches mean clinicians don't see a patient's full medical picture
False positives can merge two different patients into one record — a patient safety risk

Traditional EMPI solutions use deterministic matching (exact field comparisons) and sometimes probabilistic scoring (fuzzy string matching). They work. But they leave a significant gray zone of records that require human review — and that queue grows faster than teams can process it.

What if AI could shrink that gray zone?

2. The Architecture: Three Layers of Matching

Here's the core insight: no single matching technique is sufficient. Exact matches miss typos. Fuzzy matches produce false positives. AI alone hallucinates.

But layer them together with calibrated weights, and you get something remarkably accurate.

Let's break each layer down.

3. Layer 1: Deterministic Matching — The Foundation

Deterministic matching is the bedrock. If two records share an Enterprise ID, they're the same person. Full stop.

The system assigns trust levels to each identifier type:

Identifier	Weight	Why
Enterprise ID	1.0	Explicitly assigned by an authority
SSN	0.9	Highly reliable when present and accurate
MRN	0.8	System-dependent — only valid within the same healthcare system
Date of Birth	0.35	Common but not unique — 0.3% of the population shares any given birthday
Phone	0.3	Useful signal but changes frequently
Email	0.3	Same — supportive evidence, not proof

The key implementation detail here is MRN system validation. An MRN of "12345" at Hospital A is completely unrelated to MRN "12345" at Hospital B. The system checks the identifier's source system URI before considering it a match. Without this, you'd get a flood of false positives from coincidental MRN collisions.

If an Enterprise ID match is found, the system short-circuits — no need for probabilistic or AI scoring. It's a guaranteed match.

4. Layer 2: Probabilistic Matching — Where It Gets Interesting

This is where the system earns its keep. Probabilistic matching handles the messy reality of healthcare data: typos, nicknames, transposed digits, abbreviations, and inconsistent formatting.

Name Similarity

The system uses a multi-algorithm ensemble for name matching:

Jaro-Winkler (60% weight): Optimized for short strings like names. Gives extra credit when strings share a common prefix — so "Jonathan" vs "Jon" scores higher than you'd expect.
Soundex / Metaphone (phonetic boost): Catches "Smith" vs "Smythe," "Jon" vs "John," and other sound-alike variations that string distance alone would miss.
Levenshtein distance (typo detection): Handles single-character errors — "Johanson" vs "Johansn."

These scores are blended, and first name and last name are scored independently before combining. This prevents a matching last name from compensating for a wildly different first name.

Date of Birth — Smarter Than You'd Think

DOB matching goes beyond exact comparison. The system detects month/day transposition — one of the most common data entry errors in healthcare:

Scenario	Score
Exact match	1.0
Month and day swapped (e.g., 03/15 vs 15/03)	0.8
Off by 1 day	0.9
Off by 2–30 days	0.5–0.8 (scaled)
Different year	0.0

This alone catches a category of mismatches that pure deterministic systems miss entirely.

Address Similarity

Address matching uses a hybrid approach:

Jaro-Winkler on the normalized full address (70% weight)
Token-based Jaccard similarity (30% weight) to handle word reordering
Bonus scoring for matching postal codes, city, and state
Abbreviation expansion — "St" becomes "Street," "Ave" becomes "Avenue"

5. Layer 3: AI-Enhanced Matching — The Game Changer

This is where the architecture diverges from traditional EMPI solutions.

OpenAI Embeddings (Semantic Similarity)

The system generates a text embedding for each patient's complete demographic profile using OpenAI's text-embedding-3-small model. Then it computes cosine similarity between patient pairs.

Why does this work? Because embeddings capture semantic relationships that string-matching can't. "123 Main Street, Apt 4B, Springfield, IL" and "123 Main St #4B, Springfield, Illinois" are semantically identical even though they differ character-by-character.

The embedding score carries only 10% of the total weight — it's a signal, not a verdict. But in ambiguous cases, it's the signal that tips the scale.

GPT-5.2 LLM Analysis (Intelligent Reasoning)

For matches that land in the human review zone (0.65–0.85), the system optionally invokes GPT-5.2 to analyze the patient pair and provide structured reasoning:

{ "match_score": 0.92, "confidence": "high", "reasoning": "Multiple strong signals: identical last name, DOB matches exactly, same city. First name 'Jon' is a common nickname for 'Jonathan'.", "name_analysis": "First name variation is a known nickname pattern.", "potential_issues": [], "recommendation": "merge" }

The LLM doesn't just produce a number — it explains why it thinks two records match. This is enormously valuable for the human reviewers who make final decisions on ambiguous cases. Instead of staring at two records and guessing, they get AI-generated reasoning they can evaluate.

When LLM analysis is enabled, the final score blends traditional and LLM scores:

Final Score = (Traditional Score × 0.8) + (LLM Score × 0.2)

The LLM temperature is set to 0.1 for consistency — you want deterministic outputs from your matching engine, not creative ones.

6. The Graph Database: Modeling Patient Relationships

Records and scores are only half the story. The real power comes from how the system stores and traverses relationships.

We use Azure Cosmos DB with the Gremlin API — a graph database that models patients, identifiers, addresses, and clinical data as vertices connected by typed edges.

(:Patient)──[:HAS_IDENTIFIER]──▶(:Identifier) │ ├──[:HAS_ADDRESS]──▶(:Address) │ ├──[:HAS_CONTACT]──▶(:ContactPoint) │ ├──[:LINKED_TO]──▶(:EmpiRecord) ← Golden Record │ ├──[:POTENTIAL_MATCH {score, confidence}]──▶(:Patient) │ └──[:HAS_ENCOUNTER]──▶(:Encounter) └──[:HAS_OBSERVATION]──▶(:Observation)

Why a Graph?

Three reasons:

Candidate retrieval is a graph traversal problem. "Find all patients who share an identifier with Patient X" is a natural graph query — traverse from the patient to their identifiers, then back to other patients who share those same identifiers. In Gremlin, this is a few lines. In SQL, it's a multi-table join with performance that degrades as data grows.
Relationships are first-class citizens. A POTENTIAL_MATCH edge stores the match score, confidence level, and detailed breakdown directly on the relationship. You can query "show me all high-confidence matches" without any joins.
EMPI records are naturally hierarchical. A golden record (EmpiRecord) links to multiple source patients via LINKED_TO edges. When you merge two patients, you're adding an edge — not rewriting rows in a relational table.

Performance at Scale

Cosmos DB's partition strategy uses source_system as the partition key, providing logical isolation between healthcare systems. The system handles Azure's 429 rate-limiting with automatic retry and exponential backoff, and uses batch operations for bulk loads to avoid RU exhaustion.

7. FHIR-Native Data Ingestion

The system ingests HL7 FHIR R4 Bundles — the emerging interoperability standard for healthcare data exchange.

Each FHIR Bundle is a JSON file containing a complete patient record: demographics, encounters, observations, conditions, procedures, immunizations, medication requests, and diagnostic reports.

The FHIR loader:

Maps FHIR identifier systems to internal types (SSN, MRN, Enterprise ID)
Handles all three FHIR date formats (YYYY, YYYY-MM, YYYY-MM-DD)
Extracts clinical data for comprehensive patient profiles
Uses an iterator pattern for memory-efficient processing of thousands of patients
Tracks source system provenance for audit compliance

This means the service can ingest data directly from any FHIR-compliant EHR — Epic, Cerner, MEDITECH, or Synthea-generated test data — without custom integration work.

8. The Conversational Agent: Matching via Natural Language

Here's where it gets fun.

The system includes a conversational AI agent built on the Azure AI Foundry Agent Service. It's deployed as a GPT-5.2-powered agent with OpenAPI tools that call the matching service's REST API.

Instead of navigating a complex UI to find matches, a data steward can simply ask:

"Search patients named Aaron"

"Compare patient abc-123 with patient xyz-456"

"What matches are pending review?"

"Approve the match between patient A and patient B"

The agent is integrated directly into the Streamlit dashboard's Agent Chat tab, so users never leave their workflow. Under the hood, when the agent decides to call a tool (like "search patients"), Azure AI Foundry makes an HTTP request directly to the Container App API — no local function execution required.

Available Agent Tools

Tool	What It Does
searchPatients	Search patients by name, DOB, or identifier
getPatientDetails	Get detailed patient demographics and history
findPatientMatches	Find potential duplicates for a patient
compareTwoPatients	Side-by-side comparison with detailed scoring
getPendingReviews	List matches awaiting human decision
submitReviewDecision	Approve or reject a match
getServiceStatistics	MPI dashboard metrics

This same tool set is also exposed via a Model Context Protocol (MCP) server, making the matching engine accessible from AI-powered IDEs and coding assistants.

9. The Dashboard: Putting It All Together

The Patient Matching Service includes a full-featured Streamlit dashboard for operational management.

Page	What You See
Dashboard	Key metrics, score distribution charts, recent match activity
Match Results	Filterable list with score breakdowns — deterministic, probabilistic, AI, and LLM tabs
Patients	Browse and search all loaded patients with clinical data
Patient Graph	Interactive graph visualization of patient relationships using streamlit-agraph
Review Queue	Pending matches with approve/reject actions
Agent Chat	Conversational AI for natural language queries
Settings	Configure match weights, thresholds, and display preferences

The match detail view provides six tabs that walk reviewers through every scoring component: Summary, Deterministic, Probabilistic, AI/Embeddings, LLM Analysis, and Raw Data. Reviewers don't just see a number — they see exactly why the system scored a match the way it did.

10. Azure Architecture

The full solution runs on Azure:

Service	Role
Azure Cosmos DB (Gremlin + NoSQL)	Patient graph storage and match result persistence
Azure OpenAI (GPT-5.2 + text-embedding-3-small)	LLM analysis and semantic embeddings
Azure Container Apps	Hosts the FastAPI REST API
Azure AI Foundry Agent Service	Conversational agent with OpenAPI tools
Azure Log Analytics	Centralized logging and monitoring

The separation between Cosmos DB's Gremlin API (graph traversal) and NoSQL API (match result documents) is intentional. Graph queries excel at relationship traversal — "find all patients connected to this identifier." Document queries excel at filtering and aggregation — "show me all auto-merge matches from the last 24 hours."

11. What We Learned

AI doesn't replace deterministic matching. It augments it.

The three-layer approach works because each layer compensates for the others' weaknesses:

Deterministic handles the easy cases quickly and with certainty
Probabilistic catches the typos, nicknames, and formatting differences that exact matching misses
AI provides semantic understanding and human-readable reasoning for the ambiguous middle ground

The LLM is most valuable as a reviewer's assistant, not a decision-maker.

We deliberately keep the LLM weight at 20% of the final score. Its real value is the structured reasoning it produces — the "why" behind a match score. Human reviewers process cases faster when they have AI-generated analysis explaining the matching signals.

Graph databases are naturally suited for patient identity.

Patient matching is fundamentally a relationship problem. "Who shares identifiers with whom?" "Which patients are linked to this golden record?" "Show me the cluster of records that might all be the same person." These are graph traversal queries. Trying to model this in relational tables works, but you're fighting the data model instead of leveraging it.

FHIR interoperability reduces integration friction to near zero.

By accepting FHIR R4 Bundles as the input format, the service can ingest data from any modern EHR without custom connectors. This is a massive practical advantage — the hardest part of any EMPI project is usually getting the data in, not matching it.

12. Try It Yourself

The Patient Matching Service is built entirely on Azure services and open-source tooling https://github.com/dondinulos/patient-matching-service :

Python with FastAPI, Streamlit, and the Azure AI SDKs
Azure Cosmos DB (Gremlin API) for graph storage
Azure OpenAI for embeddings and LLM analysis
Azure AI Foundry for the conversational agent
Azure Container Apps for deployment
Synthea for FHIR test data generation

The matching algorithms (Jaro-Winkler, Soundex, Metaphone, Levenshtein) use pure Python implementations — no proprietary matching engines required.

Whether you're building a new EMPI from scratch or augmenting an existing one with AI capabilities, the three-layer approach gives you the best of all worlds: the certainty of deterministic matching, the flexibility of probabilistic scoring, and the intelligence of AI-enhanced analysis.

Final Thoughts

Can you use AI to implement an EMPI?

Yes. And the answer isn't "replace everything with an LLM." It's "use AI where it adds the most value — semantic understanding, natural language reasoning, and augmenting human reviewers — while keeping deterministic and probabilistic matching as the foundation."

The combination is more accurate than any single approach. The graph database makes relationships queryable. The conversational agent makes the system accessible. And the whole thing runs on Azure with FHIR-native data ingestion.

Patient matching isn't a solved problem. But with AI in the stack, it's a much more manageable one.

Tags: Healthcare, Azure, AI, EMPI, FHIR, Patient Matching, Azure Cosmos DB, Azure OpenAI, Graph Database, Interoperability

🚀 The Great Foundry Shift: Microsoft Foundry New vs Classic Explained

VinodSoni — Thu, 05 Mar 2026 00:16:49 GMT

Introduction

If you've been working in the Azure AI ecosystem, you've likely noticed a seismic shift happening at ai.azure.com. What was once Azure AI Studio, then became Azure AI Foundry, and has now been rebranded as Microsoft Foundry — but the rebrand is the least interesting part. The architecture, portal experience, agent capabilities, and developer workflows have been fundamentally redesigned.

Microsoft now ships two portal experiences side by side — Foundry (New) and Foundry (Classic) — accessible via a toggle in the portal banner. But this isn't just a UI facelift. Under the hood, the resource model, project hierarchy, agent framework, tool ecosystem, and governance surface have all changed in meaningful ways.

This article breaks down every major difference across every layer of the stack so you can make an informed decision about when to migrate, what you'll gain, and what still requires the Classic experience.

1. The Branding & Naming Evolution

Era	Name	Portal URL
Pre-2024	Azure AI Studio	ai.azure.com
Mid-2024 to Late 2025	Azure AI Foundry	ai.azure.com
2026 (Current)	Microsoft Foundry	ai.azure.com

💡 Key Point: "Azure AI Foundry" is now "Microsoft Foundry." Screenshots across Microsoft Learn documentation are still being updated. Both portals live at the same URL — a toggle in the top banner lets you switch between (New) and (Classic).

2. Portal Philosophy: When to Use Which

Portal	Best For
Foundry (Classic)	Working with multiple resource types: Azure OpenAI resources, Foundry resources, hub-based projects, and Foundry projects. Use this when you need features not yet available in the new experience (e.g., Prompt Flow, open-source model deployments on managed compute, Azure ML workloads).
Foundry (New)	A streamlined, agent-first experience for building, managing, and scaling multi-agent applications. Only Foundry projects are visible. Hub-based projects, Azure OpenAI standalone resources, and legacy project types are not shown.

The new portal is not a superset of the classic portal — it is a focused reimagining for the agentic AI era. If you need legacy ML capabilities, you still switch back to Classic.

3. Resource Architecture & Project Hierarchy

Foundry (Classic): The Hub-Based Model

Classic supports two project types:

Hub-Based Projects — Built on the Microsoft.MachineLearningServices resource provider. A "Hub" (Azure AI Hub) acts as the parent resource, and projects are children of that hub. Hubs required provisioning extra resources: Azure Storage, Azure Key Vault, and optionally Azure Container Registry as mandatory sibling resources.
Foundry Projects — A newer project type introduced under the Microsoft.CognitiveServices provider. These are child resources of a Foundry Resource (kind: AIServices).

Foundry (New): One Project Type to Rule Them All

The new portal only surfaces Foundry Projects. The resource hierarchy is simplified:

Foundry Resource (Microsoft.CognitiveServices/account, kind: AIServices)
└── Foundry Project (Microsoft.CognitiveServices/account/project)
└── Project Assets (agents, evaluations, files, indexes)

Aspect	Classic (Hub-Based)	New (Foundry Project)
Resource Provider	Microsoft.MachineLearningServices	Microsoft.CognitiveServices
Parent Resource	AI Hub	Foundry Resource (AIServices)
Required Sibling Resources	Storage Account, Key Vault (mandatory)	None required by default
Project Isolation	Via Hub RBAC	Native project-level RBAC
Agent Service GA	Preview only	General Availability
Foundry SDK & API	Limited	Full support
ML Training (AutoML, Pipelines)	Yes	No (use hub-based project)
Prompt Flow	Yes	No
Managed Compute (HuggingFace)	Yes	No

💡 Critical Takeaway: New generative AI and model-centric features are available only through the Foundry Resource and its Foundry projects. Hub-based projects will not receive new agent or model features.

4. Resource Provider Unification

One of the most impactful architectural changes is the consolidation under the Microsoft.CognitiveServices provider namespace:

Resource	Provider	Kind
Microsoft Foundry	Microsoft.CognitiveServices/account	AIServices
Foundry Project	Microsoft.CognitiveServices/account/project	AIServices
Azure Speech	Microsoft.CognitiveServices/account	Speech
Azure Language	Microsoft.CognitiveServices/account	Language
Azure Vision	Microsoft.CognitiveServices/account	Vision

This means:

Unified RBAC: The same Azure RBAC actions work across Foundry, Azure OpenAI, Speech, Vision, and Language.
Unified Azure Policy: Existing custom Azure Policies continue to apply if you're upgrading from Azure OpenAI to Foundry.
Unified Networking: Private Link, VNet configuration, and network isolation share the same management patterns.

In contrast, hub-based projects under Microsoft.MachineLearningServices had a completely separate RBAC model, networking stack, and policy surface.

5. Security & Governance: Separation of Concerns

Foundry (New) — Clear Control Plane vs. Data Plane Separation

Layer	Scope	Who	Examples
Control Plane	Foundry Resource (top-level)	IT Admins	Create deployments, configure networking, manage projects, set encryption
Data Plane	Foundry Project (child)	Developers	Build agents, run evaluations, upload files, test in playground

This means IT can set up governance once at the resource level, and developers can self-serve by creating projects as isolated workspaces without needing admin intervention.

Starter RBAC Assignments:

Azure AI User for each developer at the Foundry Resource scope
Azure AI User for each project managed identity at the Foundry Resource scope

Foundry (Classic) — Hub-Centric Governance

In Classic, hub-based projects relied on the Hub as the governance boundary. This worked but required IT to manage the Hub and its dependent resources (Storage, Key Vault). Foundry projects under Classic had the same new governance model as above, but the portal experience was merged with hub-based projects, adding confusion.

6. Agent Service: The Biggest Leap Forward

The Foundry Agent Service is arguably the reason Microsoft rebuilt the portal experience. Here's how agent capabilities differ:

Foundry (Classic) — Agent Service in Preview

Agents available in preview only within hub-based projects
Agents in GA within Foundry projects (accessed through Classic portal)
Single-agent interactions primarily
Limited tool selection
Basic observability
Required connection strings for SDK authentication

Foundry (New) — Agent Service, Fully Realized

a) Multi-Agent Orchestration & Workflows

Build advanced automation with the visual workflow builder using SDKs for C# and Python. Supports:

Sequential workflows — Agent A → Agent B → Agent C in defined order
Group Chat — Dynamic control passing between agents based on context
Human-in-the-loop — Approval steps, clarifying questions mid-workflow
Visual YAML editor — Edit workflows visually or in YAML; changes sync in real-time
Power Fx integration — Excel-like formulas for conditional logic, variable handling, data transformations
Versioning — Every save creates an immutable version with full history

b) Agent Types

Type	Kind	Description
Prompt Agent	prompt	LLM-backed agent defined declaratively with model config, instructions, tools, and prompts
Hosted Agent	hosted	Containerized agent running custom code, deployed and managed by Foundry
Workflow	YAML-based	Orchestrates multiple agents together using agentic patterns

c) Memory (Preview — New Only)

Long-term agent memory is a brand-new capability:

User Profile Memory: Stores preferences, dietary restrictions, language preferences — persists across sessions
Chat Summary Memory: Distilled summaries of conversation topics for cross-session continuity
Three Phases: Extraction → Consolidation → Retrieval
Memory search tool or low-level Memory Store APIs
Supports up to 10,000 memories per scope, 100 scopes per store

d) Foundry IQ — Knowledge Integration (Preview — New Only)

A managed, multi-source knowledge base for enterprise content:

Connects to Azure Blob Storage, SharePoint, OneLake, and public web
Automated document chunking, vector embedding generation, metadata extraction
Agentic retrieval engine: Decomposes complex questions into subqueries, executes in parallel, semantically reranks, returns unified responses with citations
Permission-aware: Synchronizes ACLs, honors Microsoft Purview sensitivity labels, enforces permissions at query time
One knowledge base can serve multiple agents

e) Expanded Tool Catalog (Preview — New Only)

The new portal introduces a Foundry Tool Catalog with 1,400+ tools:

Tool Category	Examples
Built-in	Azure AI Search, Code Interpreter, File Search, Grounding with Bing, Image Generation, Computer Use, SharePoint, Microsoft Fabric, Browser Automation, Web Search
MCP Servers (Remote)	Publisher-hosted servers using Model Context Protocol
MCP Servers (Local)	Self-hosted MCP servers connected to Foundry
Custom	OpenAPI 3.0 specs, Agent-to-Agent (A2A) endpoints, custom MCP endpoints
Private Catalog	Organization-scoped tools visible only to your team

Classic had a much smaller tool surface: primarily Azure AI Search, File Search, Code Interpreter, and custom functions.

f) Integration & Publishing Capabilities

The new portal supports:

Publish agents to Microsoft 365, Teams, and BizChat
Containerized deployments for portability
Open protocol support: MCP and A2A with full authentication
AI Gateway integration (Azure API Management)
Azure Policy integration for agent governance

7. Model Deployment: What Changed?

The model deployment story is shared across both portals but the new portal streamlines the experience significantly.

Deployment Types (Available in Both)

Deployment Type	SKU	Data Processing	Billing
Global Standard	GlobalStandard	Any Azure region	Pay-per-token
Global Provisioned	GlobalProvisionedManaged	Any Azure region	Reserved PTU
Global Batch	GlobalBatch	Any Azure region	50% discount, 24-hr target
Data Zone Standard	DataZoneStandard	Within data zone (EU/US)	Pay-per-token
Data Zone Provisioned	DataZoneProvisionedManaged	Within data zone	Reserved PTU
Data Zone Batch	DataZoneBatch	Within data zone	50% discount
Standard (Regional)	Standard	Single region	Pay-per-token
Regional Provisioned	ProvisionedManaged	Single region	Reserved PTU
Developer	DeveloperTier	Any Azure region	Fine-tuned eval only, no SLA

Key Differences by Portal

Capability	Classic	New
Models sold directly by Azure (Azure OpenAI, DeepSeek, xAI)	Via connections in hub-based; native in Foundry projects	Native
Partner/Community Models (via Marketplace)	Via connections in hub-based; native in Foundry projects	Native
Models on Managed Compute (HuggingFace etc.)	Hub-based projects only	Not supported
Serverless API Endpoints	Hub-based projects	Standard deployment only
Model Catalog Browsing	Available without sign-in	Requires project context

8. Observability & Monitoring

Capability	Classic	New
Azure Monitor metrics	Scoped to resource level	Scoped to resource + project level
Application Insights integration	Manual setup	Built-in for Agent Service
Conversation-level tracing	SDK-based (manual)	Real-time in portal with built-in metrics
Evaluation workflows	Available (preview)	Available with continuous evaluation via Python SDK
Agent monitoring dashboard	Not available	Built-in "Operate" section
Model tracking	Basic	Enhanced with centralized AI asset management

The new portal introduces a dedicated "Operate" section for centralized AI asset management — agents, models, and tools in one place. You can register agents from other clouds, get alerts when agents or models need attention, and manage fleet health at scale.

9. SDK & API Experience

Aspect	Classic	New
Authentication	Connection strings	Project endpoint + DefaultAzureCredential
SDK	azure-ai-projects (preview)	azure-ai-projects (GA), unified Foundry SDK
Languages	Python, C# (GA); JS/TS, Java (preview)	Same
API Surface	Foundry API (limited for hub-based)	Full Foundry API — agents, evaluations, models, indexes, data
VS Code Extension	Available	Available (enhanced)

Migration Example

Classic (Hub-Based, Preview SDK):

# Used connection strings
client = AIProjectClient.from_connection_string(
conn_str="your_connection_string",
credential=DefaultAzureCredential()
)

New (Foundry Project, GA SDK):

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
endpoint="your_project_endpoint",
credential=DefaultAzureCredential()
)

10. Data Storage & Encryption

Feature	Classic	New
Default Storage	Microsoft-managed (logical separation)	Microsoft-managed (logical separation)
Bring Your Own Storage	Supported	Supported
BYOS for Agent State	Standard setup available	Standard setup available
Customer-Managed Key Encryption	Supported (FIPS 140-2, 256-bit AES)	Supported (same)
Bring Your Own Key Vault	Supported	Supported
BCDR for Agents	Customer-provisioned Cosmos DB	Customer-provisioned Cosmos DB

The storage layer is largely unchanged between portals — both support the same bring-your-own patterns for compliance.

11. Networking & Private Access

Feature	Classic	New
Private Link	Fully supported	Supported (some limitations for end-to-end isolation)
VNet Integration (Container Injection)	Supported	Supported
End-to-End Network Isolation	Fully supported (SDK, CLI, Portal)	Partially supported — use Classic, SDK, or CLI for fully isolated deployments

💡 Important: If you require end-to-end network isolation in production, Microsoft currently recommends using the Classic experience, SDK, or CLI until the new portal reaches full parity.

12. Navigation & UX Differences

Classic Portal

Left pane navigation organized by development stages: Define & Explore → Build & Customize → Observe & Improve
Customizable left pane per project, per user (pin/unpin items)
Management Center — centralized hub for projects, quotas, permissions, usage metrics
Breadcrumb navigation showing project type (Hub vs. Foundry)
Supports browsing model catalog without signing in

New Portal

Top menu bar with Build/Operate sections
Project selector in upper-left corner — switch between recently used projects
"Operate" section for centralized AI asset management (agents, models, tools)
Streamlined navigation with redesigned interface
Faster load times with dynamic prefetching
Only shows default project per Foundry resource; "View all resources" opens Classic portal

13. Foundry Local — Runs Everywhere

A capability that works across both experiences: Foundry Local lets you run LLMs on your own device for free. Integrates with inference SDKs, supports HuggingFace model compilation, and provides a local development loop.

14. Feature Availability Matrix (Comprehensive)

Feature	Classic — Hub-Based	Classic — Foundry Project	New — Foundry Project
Agents (GA)	Preview only	GA	GA
Multi-Agent Workflows	No	No	Yes
Memory (Long-Term)	No	No	Yes (Preview)
Foundry IQ Knowledge Base	No	No	Yes (Preview)
Tool Catalog (1,400+ tools)	No	No	Yes (Preview)
MCP & A2A Protocol Support	No	No	Yes
Publish to M365/Teams/BizChat	No	No	Yes
Centralized AI Asset Mgmt	No	No	Yes
Models (Azure OpenAI, etc.)	Via connections	Native	Native
Models on Managed Compute	Yes	No	No
Prompt Flow	Yes	No	No
AutoML / ML Pipelines	Yes	No	No
Evaluations	Yes	Yes (Preview)	Yes (Preview)
Playgrounds	Yes	Yes	Yes
Content Understanding	Yes	Yes	Yes
Fine-Tuning	Yes	Yes	Yes
Datasets & Indexes	Yes	Yes	Yes
Full Foundry SDK & API	Limited	Full	Full
E2E Network Isolation	Full	Full	Partial
RBAC (Resource + Project)	Hub-level	Resource + Project	Resource + Project
Azure Policy Integration	Yes	Yes	Enhanced
Disable Preview Features	RBAC or Tags	RBAC or Tags	RBAC or Tags

15. Migration Path: Classic → New

Microsoft provides a clear migration guide:

Step 1: Locate your existing Foundry resource (the AIServices kind resource created alongside your hub)
Step 2: Create a new Foundry project under that resource
Step 3: What transfers automatically: Model deployments, data files, fine-tuned models, assistants, vector stores
Step 4: What doesn't transfer: Preview agent state (threads, messages, files), open-source model deployments, hub project access
Step 5: Update SDK code — replace connection strings with project endpoints
Step 6: Optionally recreate connections for tools and data sources
Step 7: Optionally clean up hub-based projects (keep them if you still need ML training or Prompt Flow)

Estimated migration time: 5–10 minutes for project creation; additional time for agent code migration depending on complexity.

16. When Should You Move to Foundry (New)?

Move now if:

You're building agentic applications and want GA Agent Service
You need multi-agent orchestration (workflows, sequential, group chat)
You want the Tool Catalog, Memory, or Foundry IQ
You want to publish agents to Microsoft 365/Teams
You're starting greenfield and want simplified governance

Stay on Classic (for now) if:

You depend on Prompt Flow for orchestration
You deploy open-source models on managed compute (HuggingFace, etc.)
You need Azure Machine Learning features (AutoML, ML Pipelines, training)
You require fully isolated end-to-end networking in the portal (not just SDK/CLI)
You have extensive hub-based project investments you're not ready to migrate

Final Thoughts

Microsoft Foundry (New) isn't just a portal redesign — it's a platform pivot from "AI Studio for building chatbots" to "the enterprise AI agent factory." The introduction of multi-agent workflows, long-term memory, Foundry IQ knowledge bases, a 1,400+ tool catalog with MCP/A2A support, and centralized fleet management represents a generational leap.

But it's also an honest work-in-progress. Network isolation parity, Prompt Flow, and managed compute for open-source models are still reasons to keep the Classic experience bookmarked. The good news is that both portals coexist at the same URL, and switching between them is a single toggle.

The direction is clear: Foundry (New) is the future. Start building there. Fall back to Classic only when you must.

Useful Links

What is Microsoft Foundry?: https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry
Microsoft Foundry Architecture: https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture
Foundry Agent Service Overview: https://learn.microsoft.com/en-us/azure/foundry/agents/overview
Migrate from Hub-Based to Foundry Projects: https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/migrate-project
Foundry Tool Catalog: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/tool-catalog
Foundry IQ Knowledge Base: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq
Agent Memory: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-memory
Workflow Builder: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/workflow
Deployment Types: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
Microsoft Foundry Portal: https://ai.azure.com

Note: All information sourced from Microsoft Learn documentation as of March 2026. Feature availability may change as Microsoft continues updating both portal experiences.

Claude in Copilot? Excel on Steroids!!

michaelgoad — Mon, 02 Mar 2026 21:18:15 GMT

If you’ve been paying attention to Claude lately, you’ve probably noticed one thing.

It’s really good at Excel.

Not formulas.
Not basic charts.

I mean understanding structured data. Reasoning across multiple sheets. Spotting correlations. Pulling out insights. The kind of work that usually takes a data analyst or data scientist a lot of time.

Here’s the part most people miss.

You already get that capability inside Microsoft 365 Copilot.

Let me show you what that actually looks like in the real world.

If you want to rebuild it yourself or follow along, I’ve published everything on GitHub:
- The mock Excel data
- All of the analyst and executive prompts
- Step‑by‑step flow used in the demo

Github Resources

The scenario: a very real executive ask

This is how the work showed up for me.

In this example scenario (all data is built using Copilot for demonstration purposes), an executive leader reached out and said:

“My CFO wants a Q2 financial summary of paramedic overtime across multiple counties.”

What I got back was raw data.

Messy.
Unstructured.
No story.

Normally, this turns into hours of work:

Cleaning data
Building formulas
Creating pivot tables
Designing dashboards
Writing an executive summary

Instead, I used Copilot in Excel with Agent Mode.

Six prompts.

That’s it.

Why Agent Mode matters

Copilot in Excel with Agent Mode is where Copilot goes from “helpful assistant” to something much closer to a reasoning partner.

Under the hood, it’s doing things like:

Reasoning across multiple sheets
Writing and running Python
Catching its own errors and fixing them
Structuring data so it can be reused for dashboards and reports

This is also where you might notice model selection.

If your IT admin has enabled Anthropic, you’ll see Claude as an option. If you don’t, that’s an admin setting, not a missing feature.

And that matters, because this is exactly the type of work Claude has been getting attention for.

From raw data to executive‑ready in minutes

Here’s what I built using natural language.

Data framing

I asked Copilot to take raw overtime data and turn it into structured tables that could actually support dashboards and reporting.

Dashboard creation

Without telling it which charts to build or how to lay things out, Copilot created a working dashboard and an SBAR‑style report structure.

Storytelling

I prompted it to explain what was happening in the data. It called out overtime spikes in May and flagged operational risk.

Executive brief

I asked for CFO talking points.

Copilot generated:

Key insights
Questions a CFO should be asking
Decisions that needed to be made

What‑if analysis

One prompt created an entirely new sheet to stress‑test scenarios.

All of this happened inside Excel.

No exporting.
No rework.
No separate AI tool.

Real Talk: The part people get wrong about AI and jobs

This is where the conversation usually goes sideways.

“Isn’t this replacing data scientists?”

No.

What it replaced was busy work.

AI is very good at:

Processing structured data
Generating insights
Updating models
Iterating quickly

Humans are very good at:

Understanding context
Knowing when something feels off
Asking the right questions
Applying judgment

In this sceanrio, I knew what the CFO cared about.
I knew the story that needed to be told.
I knew what to stress‑test.

Copilot didn’t replace that. It sped it up.

What used to take hours took about half an hour, including review.

That’s not a loss of skill. That’s leverage.

Copilot as a delegation tool

This is the mindset shift.

Stop thinking about Copilot as “AI that answers questions.”

Start thinking about it as delegation.

I delegated:

Data cleanup
Analysis
Visualization
First‑draft insights

Then I reviewed it, applied judgment, and refined.

When I handed this back to the CFO, I didn’t even use Agent Mode. I switched to standard Copilot and asked:

“Summarize this in one paragraph and give me three bullets a CFO would care about.”

That was it.

Copilot understood the entire workbook and produced executive‑ready talking points.

The real takeaway

Claude’s Excel capabilities are impressive.

What matters more is where you can actually use them.

Copilot brings that level of reasoning into the tools people already work in. Excel.
Teams.
Word.

AI isn’t here to think for you.

It’s here to handle the mechanics so you can focus on judgment, context, and decisions.

That’s the difference.

Go try it.
Have some fun.
And start delegating.

HLS Copilot Use Case Webinar Series

MichaelGannotti — Fri, 20 Feb 2026 22:36:29 GMT

Friday 2/27 - Taming the Excel Jungle of Clinician Scheduling
Nurse clinicians face enough pressure without spending hours wrestling with six‑week schedules in Excel. Even with time‑tracking systems in place, many teams still export schedules, staff details, and skills into spreadsheets to manually resolve conflicts and coverage gaps—adding frustration and stress to an already demanding role. In this HLS webinar on February 27 at 12:00 PM ET, Microsoft’s Michael Gannotti will demonstrate how Microsoft 365 Copilot can transform clinician scheduling—reducing work from hours or days to mere minutes, and making last‑minute changes easy to reconcile as new schedules go live.
Meeting link active on 2/27
Friday 3/13 - Supercharging Your Marketing Research and Executive Reporting with Microsoft 365 Copilot
Marketing and executive teams are under constant pressure to deliver high‑quality research, insights, and reporting—faster than ever. In this webinar on Friday, March 13 at 12:00 PM ET, Microsoft’s Michael Gannotti will demonstrate how Microsoft 365 Copilot can streamline and turbocharge marketing research, report creation, and supporting collateral—condensing days of manual work into minutes. Learn how Copilot helps teams move from raw information to executive‑ready insights with greater speed, consistency, and impact.
Meeting link active on 3/13

🚀 Git-Driven Deployments for Microsoft Fabric Using GitHub Actions

VinodSoni — Fri, 20 Feb 2026 15:48:00 GMT

👋 Introduction

If you've been working with Microsoft Fabric, you've likely faced this question:

"How do we promote Fabric items from DEV → QA → PROD reliably, consistently, and with proper governance?"

Many teams default to the built-in Fabric Deployment Pipelines — and they work great for simpler scenarios. But what happens when your enterprise demands:

🔒 Centralized governance across all platforms (infra, app, and data)
📜 Full audit trail of every change tied to a Git commit
✅ Approval gates with reviewer-based promotion
🔑 Per-environment service principal isolation
🧩 Alignment with your existing DevOps standards

That's exactly the problem we set out to solve. In this post, I'll walk you through a production-ready, enterprise-grade CI/CD solution for Microsoft Fabric using the fabric-cicd Python library and GitHub Actions — with zero dependency on Fabric Deployment Pipelines.

🎯 What Problem Are We Solving?

Traditional Fabric promotion workflows often look like this:

Step	Method	Problem
Build in DEV workspace	Fabric Portal UI	✅ Works fine
Promote to QA	Fabric Deployment Pipeline or manual copy	⚠️ No Git traceability
Promote to PROD	Fabric Deployment Pipeline with approval	⚠️ Separate governance model from app/infra CI/CD
Rollback	🤷 Manual recreation	❌ No deterministic rollback path
Audit	"Who clicked what, when?"	❌ Limited trail

The Core Issue

Fabric Deployment Pipelines introduce a parallel governance model that's disconnected from how your platform and application teams already work. You end up with:

🔀 Two different promotion systems (GitHub Actions for apps, Fabric Pipelines for data)
🕳️ Governance blind spots between the two
😰 Cultural friction ("Why do data teams have a different process?")

Our Approach: Git as the Single Source of Truth 📖

┌─────────────┐ push to main ┌─────────────┐ │ Developer │ ──────────────────▶ │ GitHub │ │ commits to │ │ Actions │ │ Git repo │ │ Workflow │ └─────────────┘ └──────┬──────┘ │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 🟢 DEV │ │ 🟡 QA │ │ 🔴 PROD │ │ Auto │────▶│ Approval │────▶│ Approval │ │ Deploy │ │ Required │ │ Required │ └──────────┘ └──────────┘ └──────────┘

Every deployment originates from Git. Every promotion is traceable to a commit SHA. Every environment has its own approval gate. One pipeline model — across everything.

🏗️ Solution Architecture

📁 Repository Structure

fabric-cicd-project/ │ ├── 📂 .github/ │ ├── 📂 workflows/ │ │ └── 📄 fabric-cicd.yml # GitHub Actions pipeline │ ├── 📄 CODEOWNERS # Review enforcement │ └── 📄 dependabot.yml # Automated dependency updates │ ├── 📂 config/ │ └── 📄 parameter.yml # Environment-specific parameterization │ ├── 📂 deploy/ │ ├── 📄 deploy_workspace.py # Main deployment entrypoint │ └── 📄 validate_repo.py # Pre-deployment validation │ ├── 📂 workspace/ # Fabric items (Git-integrated / PBIP) │ ├── 📄 .env.example # Environment variable template ├── 📄 .gitignore ├── 📄 ruff.toml # Python linting config ├── 📄 requirements.txt # Pinned dependencies ├── 📄 SECURITY.md # Vulnerability disclosure policy └── 📄 README.md

🔧 Key Components

Component	Purpose
fabric-cicd Python library	Deploys Fabric items from Git to workspaces (handles all Fabric API calls internally)
deploy_workspace.py	CLI entrypoint — authenticates, configures, deploys, logs
parameter.yml	Find-and-replace rules for environment-specific values (connections, lakehouse IDs, etc.)
validate_repo.py	Pre-flight checks — validates repo structure, parameter.yml presence, .platform files
fabric-cicd.yml	GitHub Actions workflow — orchestrates validate → DEV → QA → PROD

✨ Feature Deep Dive

1️⃣ Per-Environment Service Principal Isolation 🔐

Instead of a single shared service principal, each environment gets its own:

DEV_TENANT_ID / DEV_CLIENT_ID / DEV_CLIENT_SECRET QA_TENANT_ID / QA_CLIENT_ID / QA_CLIENT_SECRET PROD_TENANT_ID / PROD_CLIENT_ID / PROD_CLIENT_SECRET

Why this matters:

🛡️ Least-privilege access — the DEV SP can't touch PROD
🔍 Audit clarity — you know which identity deployed where
💥 Blast radius reduction — a compromised DEV secret doesn't affect PROD

The deploy script automatically resolves the correct credentials based on TARGET_ENVIRONMENT, with fallback to shared FABRIC_* variables for simpler setups.

2️⃣ Environment-Specific Parameterization 🎛️

A single parameter.yml drives all environment differences:

find_replace: - find: "DEV_Lakehouse" replace_with: DEV: "DEV_Lakehouse" QA: "QA_Lakehouse" PROD: "PROD_Lakehouse" - find: "dev-sql-server.database.windows.net" replace_with: DEV: "dev-sql-server.database.windows.net" QA: "qa-sql-server.database.windows.net" PROD: "prod-sql-server.database.windows.net"

✅ Same Git artifacts → different runtime bindings per environment
✅ No manual edits between promotions
✅ Easy to review in pull requests

3️⃣ Approval-Gated Promotions ✅

The GitHub Actions workflow uses GitHub Environments with reviewer requirements:

Environment	Trigger	Approval
🟢 DEV	Automatic on push to main	None — deploys immediately
🟡 QA	After successful DEV deploy	✅ Requires reviewer approval
🔴 PROD	After successful QA deploy	✅ Requires reviewer approval

Reviewers see a rich job summary in GitHub showing:

📌 Git commit SHA being deployed
🎯 Target workspace and environment
📦 Item types in scope
⏱️ Deployment duration
✅ / ❌ Final status

4️⃣ Pre-Deployment Validation 🔍

Before any deployment runs, a dedicated validate job checks:

Check	What It Does
📂 workspace exists	Ensures Fabric items are present
📄 parameter.yml exists	Ensures parameterization is configured
📄 .platform files present	Validates Fabric Git integration metadata
🐍 ruff check deploy/	Lints Python code for syntax errors and bad imports

If validation fails, no deployment runs — across any environment.

5️⃣ Full Git SHA Traceability 📜

Every deployment logs and surfaces the exact Git commit being deployed:

Why this matters:

🔄 Rollback = git revert <sha> + push → pipeline redeploys previous state
🕵️ Audit = every PROD deployment tied to a specific commit, reviewer, and timestamp
🔀 Diff = git diff v1..v2 shows exactly what changed between deployments

6️⃣ Concurrency Control 🚦

concurrency: group: fabric-deploy-${{ github.ref }} cancel-in-progress: false

Two rapid pushes to main won't cause parallel deployments fighting over the same workspace. The second run queues until the first completes.

7️⃣ Smart Path Filtering 🧠

paths-ignore: - "**.md" - "docs/**" - ".vscode/**"

A README-only commit? A docs update? No deployment triggered. This saves runner minutes and avoids unnecessary approval requests for QA/PROD.

8️⃣ Retry Logic with Exponential Backoff 🔁

The deploy script wraps fabric-cicd calls with retry logic:

Attempt 1 → fails (HTTP 429 rate limit) ⏳ Wait 5 seconds Attempt 2 → fails (HTTP 503 transient) ⏳ Wait 15 seconds Attempt 3 → succeeds ✅

Transient Fabric service issues don't break your pipeline — the deployment retries automatically.

9️⃣ Orphan Cleanup 🧹

Set CLEAN_ORPHANS=true and items that exist in the workspace but not in Git get removed:

Workspace has: Notebook_A, Notebook_B, Notebook_C Git repo has: Notebook_A, Notebook_B → Notebook_C gets removed (orphan)

This ensures your workspace exactly matches your Git state — no drift, no surprises.

🔟 Dependency Management with Dependabot 🤖

# .github/dependabot.yml updates: - package-ecosystem: "pip" schedule: interval: "weekly" - package-ecosystem: "github-actions" schedule: interval: "weekly"

fabric-cicd, azure-identity, and GitHub Actions versions are automatically monitored. When updates are available, Dependabot opens a PR — keeping your pipeline secure and current.

1️⃣1️⃣ CODEOWNERS Enforcement 👥

# .github/CODEOWNERS /deploy/ @platform-team /config/ @platform-team /.github/workflows/ @platform-team

Changes to deployment scripts, parameterization, or the workflow require review from the platform team. No one accidentally modifies the pipeline without oversight.

1️⃣2️⃣ Job Timeouts ⏱️

Job	Timeout
Validate	10 minutes
Deploy (DEV/QA/PROD)	30 minutes

A hung process won't burn 6 hours of runner time. It fails fast, alerts the team, and frees the runner.

1️⃣3️⃣ Security Policy 🛡️

A dedicated SECURITY.md provides:

📧 Responsible vulnerability disclosure process
⏰ 48-hour acknowledgement SLA
📋 Best practices for contributors (no secrets in code, least-privilege SPs, 90-day rotation)

🔄 The Complete Workflow

Here's what happens end-to-end when a developer merges a PR:

1. 👨‍💻 Developer merges PR to main │ 2. 🔍 VALIDATE job runs │ ✅ Repo structure checks │ ✅ Python linting (ruff) │ ✅ parameter.yml validation │ 3. 🟢 DEPLOY-DEV job runs (automatic) │ 🔑 Authenticates with DEV SP │ 📦 Deploys all items to DEV workspace │ 📝 Logs commit SHA + summary │ 4. 🟡 DEPLOY-QA job waits for approval │ 👀 Reviewer checks job summary │ ✅ Reviewer approves │ 🔑 Authenticates with QA SP │ 📦 Deploys all items to QA workspace │ 5. 🔴 DEPLOY-PROD job waits for approval │ 👀 Reviewer checks job summary │ ✅ Reviewer approves │ 🔑 Authenticates with PROD SP │ 📦 Deploys all items to PROD workspace │ 6. 🎉 Done — all environments in sync with Git

🆚 Comparison: This Approach vs. Fabric Deployment Pipelines

Capability	Fabric Deployment Pipelines	This Solution (fabric-cicd + GitHub Actions)
Source of truth	Workspace	✅ Git
Promotion trigger	UI click / API call	✅ Git push + approval
Approval gates	Fabric-native	✅ GitHub Environments (same as app teams)
Audit trail	Fabric activity log	✅ Git commits + GitHub Actions history
Rollback	Manual	✅ git revert + auto-redeploy
Cross-platform governance	Separate model	✅ Unified with infra/app CI/CD
Parameterization	Deployment rules	✅ parameter.yml (reviewable in PR)
Secret management	Fabric-managed	✅ GitHub Secrets + per-env SP isolation
Drift detection	Limited	✅ Orphan cleanup (CLEAN_ORPHANS=true)

🚀 Getting Started

Prerequisites

3 Fabric workspaces (DEV, QA, PROD)
Service principal(s) with Contributor role on each workspace
GitHub repository with Actions enabled
GitHub Environments configured (dev, qa, prod)

Quick Setup

# 1. Clone the repo git clone https://github.com/<your-org>/fabric-cicd-project.git # 2. Install dependencies pip install -r requirements.txt # 3. Copy and fill environment variables cp .env.example .env # 4. Run locally against DEV python deploy/deploy_workspace.py

GitHub Actions Setup

Create GitHub Environments: dev, qa (add reviewers), prod (add reviewers)
Add secrets to each environment:
- DEV_TENANT_ID, DEV_CLIENT_ID, DEV_CLIENT_SECRET
- QA_TENANT_ID, QA_CLIENT_ID, QA_CLIENT_SECRET
- PROD_TENANT_ID, PROD_CLIENT_ID, PROD_CLIENT_SECRET
- DEV_WORKSPACE_ID, QA_WORKSPACE_ID, PROD_WORKSPACE_ID
Push to main — the pipeline takes over! 🎉

💡 Lessons Learned

After implementing this pattern across several engagements, here are the key takeaways:

✅ What Works Well

Teams love the Git traceability once they experience a clean rollback
Approval gates in GitHub feel natural to platform engineers
Parameter.yml changes in PRs create great review conversations about environment differences
Job summaries give reviewers confidence to approve without digging into logs

⚠️ Watch Out For

Cultural resistance is the #1 blocker — invest in enablement, not just automation
Fabric items with runtime state (data in lakehouses, refresh history) aren't captured in Git
Secret rotation across 3+ environments needs process discipline (consider OIDC federated credentials)
Run a "portal vs. pipeline" side-by-side demo early — it changes minds fast

🤝 For CSAs: Sharing This With Customers

This solution is ideal for customers who:

☑️ Already use GitHub Actions for application or infrastructure CI/CD
☑️ Have governance requirements that demand Git-based audit trails
☑️ Operate multiple Fabric workspaces across environments
☑️ Want to standardize their promotion model across all workloads
☑️ Are moving from Power BI Premium to Fabric and want to modernize their DevOps practices

🗣️ Conversation Starters

"How are you promoting Fabric items between environments today?"

"Is your data team using the same CI/CD patterns as your app teams?"

"If something goes wrong in production, how quickly can you roll back to the previous version?"

📚 Resources

🏁 Conclusion

The shift from UI-driven promotion to Git-driven CI/CD for Microsoft Fabric isn't just a technical upgrade — it's a governance and cultural alignment decision. By using fabric-cicd with GitHub Actions, you get:

📖 One source of truth (Git)
🔄 One promotion model (GitHub Actions)
✅ One approval process (GitHub Environments)
🔍 One audit trail (Git history + Actions logs)
🔐 One security model (GitHub Secrets + per-env SPs)

No parallel governance. No hidden drift. No "who clicked what in the portal."

Just Git, code, and confidence. 💪

Have questions or want to share your experience? Drop a comment below — I'd love to hear how your team is approaching Fabric CI/CD! 👇

Compliance Meets AI: What’s New in Insider Risk Management for Copilot

Jay_Cotton — Fri, 06 Feb 2026 18:57:17 GMT

AI is moving fast—and so are the risks. That’s exactly why our latest Compliance Meets AI session, “What’s New – Insider Risk Management for Copilot,” focused on how organizations can confidently secure data in an increasingly agent-driven world.

In this session, Kevin Uy walked through what’s new (and what’s next) in Microsoft Purview Insider Risk Management, with a strong spotlight on Copilot, AI agents, and Security Copilot integration. From real-world risk scenarios to live demos, this was a practical deep dive into protecting your organization while still empowering innovation.

If you missed the session we have you covered! You can find the recording below.

https://aka.ms/Compliance-Meets-Ai-Insider-Risk-Management

🔍 Key highlights included:

Insider Risk for Copilot & Agents – How Microsoft now monitors both humans and AI agents with purpose-built policies.
Risky Agents (Preview) – New capabilities that provide visibility and governance for agents built in Copilot Studio and Azure AI Foundry.
Security Copilot Triage Agents – A powerful look at AI helping security teams prioritize what truly matters by summarizing and contextualizing Insider Risk and DLP alerts.
DSPM for AI – How organizations can gain insight into risky AI usage, prompts, and responses—inside and outside the Microsoft ecosystem.

💡 One of the biggest takeaways? AI security no longer stops at users. Agents operate at machine speed, and organizations need the same level of governance, risk scoring, and investigation capabilities to keep pace.

If you’re responsible for security, compliance, data protection, or AI governance, this session is packed with insights you can apply right away.

All past recordings Can be found here Jay Cotton - YouTube and dont forget to register for our session over the next three weeks here

Compliance Meets Ai 2026: Microsoft Purview in the Age of Ai | Microsoft Community Hub

Strategic Data Replication Enhances a Single Source of Truth Architecture for Analytics & AI

Greg_Beaumont — Fri, 06 Feb 2026 17:56:16 GMT

Strategic Data Replication is not Many Sources of Truth, and can be complimentary to a Single Source of Truth architectural design. Even in a highly regulated Healthcare data ecosystem, strategic replication can maintain a compliant source of truth as part of a larger strategy to scale and control costs.

The concepts of single source of truth, data replication, data redundancy, and data duplication are often convoluted and can lead to misunderstandings that result in poorly performing and unnecessarily expensive architectures. I've published a new video that attempts to unwind the problem. No matter what data tools or cloud platforms you work with, hopefully you can find value in the content. I've added some fun analogies to data replication for cryptocurrency (such as Bitcoin) and Biology (DNA) to help explain the benefits of data replication in a multi-cloud world of analytics and AI.

How can you plan for a highly scalable, cost optimized analytics and AI architecture with high query concurrency, global users, and rapidly evolving technology having an AI Agentic future? How did Kimball vs Inmon influence the single source of truth discussion? How do you have a multi-tool environment with both corporate reporting and self-service tools that provide consistent metrics? How can you prevent the self-service spreadmarts and shadow IT nightmares of the past without stifling innovation and progress? Hopefully the content in the video below helps explain the history and frames up the future:

Introduction to Copilot Role Stories

Christina_Tillbrook — Wed, 04 Feb 2026 14:23:51 GMT

AI is becoming a core part of how people across every industry get work done. From marketers creating content faster, to clinicians improving patient care, to insurance teams automating claims and authorizations, Microsoft Copilot and AI Agents are helping people focus on what matters most.

In Role Stories we walk through real-world scenarios in specific industries and job roles using M365 Copilot & Agents. Today we are focused on Marketing & Content Creation.

Marketing teams are under constant pressure to produce more content quickly and tell better stories. That’s exactly why Role Stories exists, it's a program designed to show real, practical examples of how different jobs can use Microsoft Copilot and AI Agents to get meaningful time back.

But, Marketing isn’t just making content, it’s shaping brand voice, driving engagement, and keeping teams ahead of tight deadlines. But the work takes time. Copilot changes that by helping marketers brainstorm, write, edit, and repurpose content in minutes.
Check out the story and video below.

Let's learn about Maya the Marketer
The Role Story: Marketing - Create Better Content

On Monday morning, Maya opened a blank doc and felt that familiar knot: new blog due, socials to plan, no time. So she asked Copilot for help.

Chapter 1: Finding the angle
Maya opened Copilot in Word and prompted: “Give me 10 SEO keywords to attract people ages 20–30 who want to reduce their carbon footprint.” Copilot gave back a tight list in seconds. Maya picked a theme, and keywords, and the fog started to lift.

Chapter 2: From idea to draft
“Draft a friendly, confident blog post using Chicago Style grammar using these keywords."
Copilot in Word shaped a clean outline, wrote sections, and matched her brand voice. Maya tweaked examples and added a customer quote. The draft felt like her, just faster.

Chapter 3: One draft, many moments

“Turn this into a 100‑word LinkedIn blurb with emojis and a headline.” Done. 👍
“Create an email to advertise this blog and give me 3 different subject lines to choose from.” Done. 👍
Then she used Copilot Create to generate a photo‑realistic image that fit the story’s vibe, no endless stock‑photo hunt.
"Generate a photo‑realistic image that fit a story’s vibe about people between ages 20–30 who want to reduce their carbon footprint." 👍
“Pull short captions for Instagram.” Done. 👍

Chapter 4: Result: Less work, more impact
By lunch, Maya had a polished blog, a LinkedIn teaser, captions, headlines, and a hero image. She saved hours and widened reach without burning out. That afternoon, the post went live, and the team had time left to plan the next story.

Marketing - Content Creation: Marketing scenario: Content creation (Copilot Scenario Library) – Microsoft Adoption
Find Your Role and Your Story: Microsoft Scenario Library – Microsoft Adoption