AzureFeeds

Co-Authors: Josh Mandel, Shrey Jain, Frank Tuan, Evan Miller, Matthias Blondeel, Aiden Gu, Manoj Kumar, Kumar Thirumalaiah, Arun C K, Juhi Patel, Will Guyman, Smitha Saligrama, Alexander Ersoy

Introduction:

Earlier this year, we announced the availability of the healthcare agent orchestrator in Azure AI Foundry Agent Catalog. It features pre-configured agents with multi-agent orchestration and open-source customization options that allow developers and researchers to build agents that coordinate multi-disciplinary multimodal healthcare data workflows, such as tumor boards, and streamline deployment into healthcare enterprise productivity tools (such as Microsoft Teams and Word). Modular, general reasoners as well as specialized, multimodal AI agents work together to address tasks that would take hours, with the goal of effectively augmenting clinician specialists with customized cutting-edge agentic AI.

In this blog we consider two interoperability scenarios, the first, where you access data directly from electronic health record (EHR) systems via established healthcare standards, and the second, where you access data from your institution’s harmonized multimodal healthcare data platform implemented using healthcare data solutions in Microsoft Fabric. We will provide background, architectural challenges and tradeoffs, and walkthroughs for each scenario, including links to full working code samples available in the healthcare agent orchestrator GitHub repository.

Connectivity to EHR systems

Implementing connectivity between advanced AI systems like the healthcare agent orchestrator to existing EHR systems involves significant challenges due to the diverse technical environments and infrastructure across healthcare institutions. Variability exists in data formats, interoperability capabilities, and compliance requirements, all of which lead to nuanced architectural tradeoffs. Adopting standards like HL7® FHIR®, which offer structured methodologies for achieving interoperability, are the preferred mechanisms to use for connectivity architecture. However, developers must also consider and implement to meet their real-world environments: balancing their IT systems support (or lack thereof) for interoperability standards, requirements for performance, scalability, and usability, as well as compliance with regulatory standards and internal policies.

HL7 FHIR and SMART on FHIR

HL7 FHIR is a standardized framework designed to facilitate the exchange of healthcare data across diverse systems. It combines the best aspects of HL7’s standards with modern web technologies, making it flexible and developer friendly. Its resource-based approach allows systems to operate seamlessly, leveraging a structured methodology for data management and communication. HL7 FHIR has widespread adoption across modern healthcare systems and provides support for RESTful APIs, making it straightforward for developers to utilize. SMART on FHIR builds on HL7 FHIR to enable secure and scalable extensions that integrate seamlessly into electronic health records.

Patterns for EHR Integration Using SMART on FHIR

To support real-world clinical workflows, there are multiple integration patterns that can be implemented with EHR systems using SMART on FHIR. These patterns reflect the diversity of use cases, from user-facing apps to backend services to patient-directed access, and ensure secure, standards-based access to patient data.

Regardless of the pattern, all approaches result in an OAuth2 access token that authorizes the app to query the EHR’s FHIR API in accordance with the US Core Implementation Guide (IG). This enables structured, standards-compliant access to clinical data.

1. User Authorization via SMART Scopes

UX Pattern: Authorization is initiated within the app’s own user experience, leveraging the user’s existing EHR credentials and permissions. This pattern supports:

• 
  
  
  
  • Single-patient access using launch/patient and patient/*.rs scopes
  
  
  • Multi-patient access using user/*.rs scopes, enabling access to all patients the current user is authorized to view
  
  
  
  

This ensures that the app only accesses data the user is permitted to see, while maintaining alignment with institutional access controls and audit requirements.

2. Backend Service Integration

UX Pattern: The app’s backend service connects directly to the EHR without requiring user interaction at launch. This is suitable for system-level workflows such as population health analytics or automated monitoring.

Because there is no user context, access must be explicitly scoped and governed through backend credentials and pre-authorized client configurations.

3. Patient-Authorized SMART App Launch 

UX Pattern: Patients can authorize apps to access their own health data using SMART on FHIR, without requiring any pre-arranged relationship between the app and the healthcare provider organization. This pattern uses:

• 
  
  
  
  • launch/patient and patient/*.rs scopes
  
  
  • A patient-facing login workflow provided by the EHR vendor
  
  
  
  

This approach enables any patient at any participating health system to connect a SMART-enabled app to their own data, provided the app is registered with the EHR vendor. It supports consumer health apps, personal health records, and research tools that empower patients to manage and share their data independently.

Example FHIR Queries

Once an access token is obtained, the app can issue standard FHIR queries such as:

  GET /Patient?identifier=patient_4

→ Returns matching patients for patients with an identifier (e.g., MRN) of “patient_4”

  GET /DocumentReference?patient=123

→ Returns all documents for patient with FHIR ID “123”.

  GET /Observation?patient=123&category=laboratory

→ Returns all lab observations for patient “123”.

Real-world Architectural Concerns and Tradeoffs

In the rapidly evolving landscape of healthcare technology and its intersection with AI, interoperability stands as a cornerstone for enabling seamless communication between systems and enhancing the delivery of patient care. From navigating the complexities of EHR systems to implementing robust frameworks like HL7 FHIR and SMART Health IT, healthcare institutions face a myriad of challenges and opportunities. Some examples of real-world tradeoffs that you may consider include:

• Scalability and performance: EHRs often have limited resources, and the impact on EHR performance needs to be carefully considered. In addition, large patient records, especially for those with chronic conditions, may take longer than your users want to wait. To address these, you could implement a strategy for prefetching data to ensure optimal user experience and minimized impact on the EHR.


• Legacy systems: While modern EHRs provide support for FHIR, many institutions have older systems that do not support FHIR. In these cases, you could integrate with vendors’ proprietary interfaces/APIs or an interface engine. Your approach would vary based on your systems’ capabilities.


• Distribution of patient data across multiple systems: While the EHR represents the system of record for longitudinal patient data, most institutions have other systems that hold additional patient data – e.g., PACS, Laboratory Information Systems, etc. Depending on your use cases, you may want to implement integration with these systems as well.


• Compliance, Privacy, and Security: When architecting software that interacts with patient data, compliance, security, and patient privacy must always be considered.

Connecting healthcare agent orchestrator to an EHR via FHIR

With the release of this blog, the healthcare agent orchestrator has been updated to include an option for accessing patient data and clinical notes through FHIR. Once this option is configured, the healthcare agent orchestrator must be redeployed, which will deploy a FHIR service instance with the appropriate test data to the environment. Instructions for configuring and redeploying can be found in the healthcare agent orchestrator GitHub repository.

We use the Azure Health Data Services FHIR service as a stand in for an HL7 FHIR-compliant EHR and considering that we are implementing a data access layer for an existing application; we chose to use SMART Backend Services pattern for connecting to the FHIR service.

At runtime, when the user asks the agent to prepare the tumor board documentation for a patient, the Patient History agent is selected, and it requests the data from the MCP server. The data access layer of the MCP server then authenticates to the FHIR service and then uses the token returned to issue FHIR queries to search for the Patient resource for the patient provided by the user, then fetches the clinical notes from the patient’s DocumentReference resources. The relevant data is brought into memory. The agents then use this data to perform their tasks to draft their sections, and the orchestrator assembles the tumor board content and presents it back to the tumor board members for review and confirmation.

The healthcare agent orchestrator GitHub repository also includes instructions on how you can connect to your own EHR’s FHIR service, implement additional authentication mechanisms, as well as how to modify the data access layer to retrieve from other FHIR resources.

Connectivity to healthcare data solutions in Microsoft Fabric

Many healthcare institutions use unified data platforms, such as Microsoft Fabric, to aggregate and normalize their data for AI and analytics. Connecting the healthcare agent orchestrator with a unified data platform provides a single point of integration and allows you to avoid dealing with the heterogeneity of integration methods across EHR systems.

Microsoft Fabric is a comprehensive platform designed to enable efficient management, analysis, and integration of data across various industries, including healthcare. It aims to break down data silos, harmonize disparate datasets, and support advanced analytics with AI-powered capabilities. It integrates various tools and services to manage every stage of the data lifecycle, including ingestion, preparation, storage, analysis, and visualization. Microsoft Fabric is built on a Software as a Service (SaaS) foundation, offering seamless experience for organizations to make data-driven decisions.

Healthcare data solutions in Microsoft Fabric is designed to help healthcare organizations manage and analyze vast amounts of data efficiently. These solutions address challenges like unstructured data, limited patient insights, and difficulties in accessing valuable analytics. Key features include:

• Unified data management: Break down data silos and harmonize disparate healthcare data in a single store.


• Advanced analytics: Tools to enable large-scale analytics, designing and building research and training/testing cohorts, implementing AI data enrichments, and generative AI applications.


• Industry compliance: Support standards like FHIR and DICOM while ensuring compliance with regulations such as HIPAA and GDPR.


• Multi-modal data handling: Ingest and analyze data from various sources, including electronic health records and imaging systems.

If you’re interested in getting started with healthcare data solutions in Microsoft Fabric, you can explore the learning path and check out the official blogs.

• Healthcare data solutions in Microsoft Fabric – Exploration Series


• General Availability – Medical imaging DICOM® in healthcare data solutions in Microsoft Fabric | Microsoft Community Hub


• Building Healthcare Research Data Platform using Microsoft Fabric | Microsoft Community Hub

Patterns for integrating with healthcare data solutions in Microsoft Fabric

As you would expect from a robust data platform, there are several patterns you can follow to integrate with Microsoft Fabric. The following are a couple of examples that could apply to integrating the healthcare agent orchestrator:

1. Microsoft Fabric User Data Functions (UDF):

User Data Functions in Microsoft Fabric allow you to write re-usable code that can then be executed externally by exposed endpoints. This is a useful pattern as it allows you to quickly realize an API layer by standing up endpoints that can surface a scoped subset of data stored in an HDS Lakehouse. This approach is preferred when there is a small subset of resources that need to be accessed and when the data might not have strict referential integrity (e.g., Silver / FHIR Lakehouse) where additional business logic might be needed to transform your data. You can find more information on user data functions here: Overview – Fabric User data functions (preview) – Microsoft Fabric | Microsoft Learn

2. Microsoft Fabric API for GraphQL:

Microsoft Fabric API for GraphQL is another way to expose a subset of your data with an external endpoint. It is offered directly in Microsoft Fabric and provides an editor and tools to accelerate the time to build and test your API. With GraphQL, you have the flexibility to request exactly the data you want without needing to write complex queries. The GraphQL API even supports hosting a unified API that aggregates data across multiple sources. For systems like HDS, this would allow fetching data across the medallion architecture (Bronze, Silver, Gold Lakehouses). This pattern is preferred when you have good referential integrity (e.g., Gold / OMOP Lakehouse) and several different resources being accessed that are highly related. You can find more information on the GraphQL API here: Microsoft Fabric API for GraphQL overview – Microsoft Fabric | Microsoft Learn

Connecting the healthcare agent orchestrator to healthcare data solutions in Microsoft Fabric

With the release of this blog, the healthcare agent orchestrator has also been updated to include an option to access relevant patient and clinical notes from healthcare data solutions in Microsoft Fabric. While you could use any of the integration patterns above, we chose to use Microsoft Fabric user data functions. The healthcare agent orchestrator GitHub repository has been updated to include detailed instructions for integrating with Microsoft Fabric as well as the steps required to prepare your own Fabric workspace with healthcare data solutions, ingest the demo data through a data transformation pipeline, and create a user data function  to expose access to the data through Microsoft Fabric’s REST APIs.

Conclusion

The latest healthcare agent orchestrator update includes examples for connecting to your data, whether in EHR systems or Microsoft Fabric. Healthcare interoperability is complex, with each institution facing unique challenges. Implementing robust production solutions requires careful architecture and design. The integration examples provide a starting point for integrating your systems using modern APIs and standards. We encourage you to explore the detailed instructions and code samples available in the healthcare agent orchestrator GitHub repository and try it yourself. This firsthand experience will help you understand the full potential of these integrations and how you can extend the healthcare agent orchestrator to address your specific use cases and workflows.

Disclaimer

Healthcare agent orchestrator is intended for research and development use. It is not designed or intended to be deployed in clinical settings as-is nor is it intended for use in the diagnosis or treatment of any health or medical condition, and its performance for such purposes has not been established. You bear sole responsibility and liability for any use of healthcare agent orchestrator, 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.