What Category Does Each Product Actually Belong To?
As with other cloud-native FHIR platforms, Azure Health Data Services isn't a direct substitute for an interface engine, since it's built around managing standardized FHIR and DICOM data rather than routing real-time messages between operational systems directly. The four points below clarify exactly where each product's actual responsibility genuinely begins and ends in a real, working architecture.
Mirth Handles Real-Time Message Routing and Transformation
Mirth Connect's core function is receiving messages from source systems, applying transformation logic, and routing the result to one or more destinations, which is fundamentally different from managing a standardized data repository.
Azure Health Data Services Manages FHIR, DICOM, and Event Data
Azure Health Data Services unifies FHIR service, DICOM service for medical imaging, and event-driven workflows within a shared workspace, integrating tightly with Microsoft's broader ecosystem including Entra ID, Power BI, and Azure Synapse Analytics.
Azure API for FHIR's Retirement Is a Separate, Time-Sensitive Issue
Anyone still running the older Azure API for FHIR service must migrate to Azure Health Data Services before its September 30, 2026 retirement date, independent of any decision about whether Mirth remains part of the architecture.
The Two Platforms Address Different Layers of a Healthcare Data Stack
Mirth operates at the interface and transformation layer moving data between systems, while Azure Health Data Services operates at the storage and management layer for standardized FHIR and imaging data once it has already arrived.
When Does Each Platform Actually Make Sense?
Recognizing which layer of your architecture each platform addresses clarifies whether you need one, the other, or genuinely both working together rather than treating this as a single either-or vendor decision. The four scenarios below cover the most common situations organizations actually face when making this specific architectural call.
Mirth Makes Sense Wherever Real-Time Interface Work Is Needed
Any HL7 v2 or FHIR message transformation and routing work between clinical systems, labs, or applications remains squarely Mirth's job, regardless of which cloud platform ultimately stores the standardized output downstream.
Azure Health Data Services Makes Sense for Microsoft-Centered Environments
Health systems already invested in the Microsoft ecosystem, needing DICOM medical imaging management alongside FHIR data and wanting native Power BI or Azure Synapse integration, benefit directly from Azure Health Data Services' unified platform.
DICOM Support Is a Genuine Differentiator Worth Noting
Azure Health Data Services includes a dedicated DICOM service for medical imaging that Mirth doesn't natively provide, making it relevant for organizations needing to manage imaging data alongside clinical messaging in the same environment.
Migrating Off Azure API for FHIR Doesn't Require Replacing Mirth
Organizations facing the Azure API for FHIR retirement deadline can migrate that specific service to Azure Health Data Services while continuing to run Mirth Connect unchanged for their interface and transformation needs elsewhere.
How Do They Actually Work Together in a Real Architecture?
Rather than choosing one platform over the other, most Microsoft-centered healthcare architectures benefit from a clear division of labor between Mirth's interface layer and Azure Health Data Services' storage and management layer. The four steps below describe exactly how that division works in a real production environment, without forcing a single-vendor choice.
Mirth Transforms Incoming Messages Into Standardized FHIR Output
Configure Mirth Connect to receive HL7 v2 messages from clinical source systems and transform them into FHIR resources, preparing standardized output rather than attempting to replicate Azure Health Data Services' own storage function.
Azure Health Data Services Receives That Standardized Data
Once Mirth has transformed and standardized incoming messages, Azure Health Data Services becomes the destination for that FHIR data, alongside any DICOM imaging data your organization needs to manage within the same workspace.
Plan Your Azure API for FHIR Migration Independently of Mirth Decisions
If you're currently on the older Azure API for FHIR service, plan that specific migration to Azure Health Data Services on its own timeline ahead of the retirement date, separate from any evaluation of your Mirth deployment.
Confirm Which Azure Region and Sub-Service Availability You Actually Need
Azure Health Data Services availability varies by sub-service and region, so confirm your specific requirements around FHIR, DICOM, or Events support are actually available in your target Azure region before finalizing an architecture decision.
Navigating this migration or architecture decision?
Start with a free Mirth Health Check to clarify where Mirth fits in your environment, send us the exact error if you're troubleshooting something specific, or check pricing for our own support plans.