• Point-to-point interface sprawl Before FHIR, healthcare integration often meant HL7 v2 messages, custom interfaces and point-to-point connections between individual systems. Each new application or partner could require another custom connector. As the number of healthcare systems increased, the organization had to maintain more interfaces, dependencies and transformation rules. This made even relatively small workflow changes difficult to implement and increased the ongoing maintenance burden.
• Legacy standards that are still everywhere HL7 v2 remains widely used across healthcare organizations. Its flexibility allows individual organizations and systems to implement local variations, custom segments and different approaches to representing information. For an organization moving toward FHIR, the challenge is therefore not simply replacing HL7 v2. The architecture needs to allow existing HL7-based workflows to continue while creating a standardized FHIR layer for modern applications and consumers.
• Regulatory pressure on APIs Healthcare organizations are facing increasing expectations around interoperability and digital access to healthcare information. Under the 21st Century Cures Act, providers and developers must support interoperability and avoid information blocking, including enabling patients to access their health information digitally. CMS-0057-F also requires impacted payers to implement four FHIR-based APIs by January 1, 2027: an enhanced Patient Access API, Provider Access API, Payer-to-Payer API and Prior Authorization API.
• Uneven readiness Healthcare organizations are at different stages of API and FHIR adoption. National data shows that 81% of U.S. hospitals enable patient access through apps built on their EHR APIs, while 70% do so with FHIR-based applications. Organizations without a scalable API foundation can face greater effort when responding to new interoperability requirements, applications and partner integrations.
• Security and authorization complexity Making clinical data available through APIs introduces additional requirements around identity, authorization, consent and auditability. Every API request needs appropriate authorization, access scopes, launch context and audit logging. The organization therefore treated security and authorization as core elements of the interoperability architecture rather than adding them after the APIs were developed.
• Governance and API sprawl A FHIR server provides the REST API required to access healthcare resources, but organizations also need governance when those APIs are consumed at scale. Without centralized API management, organizations can simply replace interface sprawl with API sprawl. The organization therefore introduced centralized API management for access policies, analytics, versioning and traffic control.
• A platform change with a hard date Azure API for FHIR is being retired on September 30, 2026, with Microsoft directing customers toward the FHIR service in Azure Health Data Services. Organizations using the older service need to consider their migration path, including changes to SMART on FHIR configurations that relied on the previous proxy model.
• AI needs a governed path to data As healthcare organizations introduce analytics and AI applications, these systems need reliable and permissioned access to clinical information. If every new AI initiative creates its own extract or integration, the organization can quickly recreate the same integration complexity it was trying to eliminate. A FHIR-first architecture provides a standardized and governed route to healthcare data that can be reused by multiple applications and services.

The organization structured the transformation around a FHIR-first architecture that could work with existing healthcare systems while providing a modern API foundation for new applications.

• Start with the contract, not the code The organization first defined what healthcare data needed to be exposed through APIs before beginning transformation and integration work.
  The team agreed on:
  1. FHIR resources
  2. Profiles and versions
  3. API contracts
  4. Consumer requirements
  5. Authorization requirements
  6. Versioning strategy

  This helped establish clarity around what data would be available, who could access it and how applications would interact with the platform.

• A layered architecture on Azure The FHIR-first platform was designed around five key layers:

The layered approach allowed the organization to introduce FHIR without requiring a complete replacement of its existing healthcare technology environment.

• SMART on FHIR with Microsoft Entra ID Applications need a secure and standardized way to authenticate and authorize access to clinical information. The organization implemented SMART on FHIR with Microsoft Entra ID to support application identity, OAuth-based authorization, scopes and launch context. The Azure Health Data Services FHIR service supports SMART v1 and v2 and provides discovery through the standard SMART configuration endpoint. This provided a standardized mechanism for applications to request access to the healthcare resources they were authorized to use.
• Legacy systems stay in place, behind the API The organization did not need to replace its existing EHR and clinical systems to introduce FHIR. Instead, existing systems continued to operate using their current interfaces, including HL7 v2, while an integration layer transformed and normalized information into FHIR resources. The resulting architecture followed a hybrid model: Legacy Systems → HL7 v2 → Transformation → FHIR → API → Applications This allowed existing clinical workflows to continue while providing modern applications, partners and payers with standardized API access.
• Event-driven where it fits Not every healthcare workflow requires a synchronous API request. For use cases such as bulk ingestion, downstream notifications and asynchronous processing, event-driven patterns can reduce direct dependencies between systems. The organization used event-driven patterns where appropriate to improve scalability and reduce unnecessary coupling between services.
• Analytics and AI on top of the same APIs Once healthcare information was standardized through the FHIR layer, the organization could extend the same foundation to analytics and intelligent applications. FHIR data could be made available to the broader Azure data environment, including Microsoft Fabric, for analytics and downstream intelligence use cases. This created a common data access model instead of requiring every new analytics or AI initiative to build its own separate clinical data integration.
• Deliver in thin, production-grade slices The organization started with a deliberately narrow implementation rather than attempting to connect every system at once.
  The first integration focused on:
  1. One source system
  2. Read-only access
  3. A defined set of FHIR resources
  4. Production deployment

  This approach allowed the organization to validate the architecture, security model and monitoring before expanding to additional systems, write access and more consumers.

Published research provides useful context for understanding the broader adoption of standards-based healthcare APIs. The figures below come from federal survey data and industry sources. They should be viewed as industry context rather than project-specific performance claims.
Adoption and readiness

Implementation Considerations The time and effort required to build a FHIR-first interoperability platform can vary significantly depending on the organization’s existing healthcare environment, number of source systems, data quality, integration complexity, security requirements and number of applications that need access to the platform.
Rather than treating interoperability as a single implementation project, organizations can approach it incrementally, starting with a focused use case and expanding the platform as additional systems and requirements are validated.

What this means in practice

• Start with a focused use case. Begin with a clearly defined interoperability requirement rather than attempting to modernize every interface simultaneously.
• Modernize without disrupting existing systems. Existing HL7 and EHR workflows can continue operating while FHIR is introduced as the modern API layer.
• Build for reuse. A well-designed FHIR API can support multiple applications and workflows instead of creating a separate integration for each consumer.
• Treat security as foundational. Identity, authorization, consent and auditability should be designed into the platform from the beginning.
• Scale progressively. Once the initial FHIR implementation is validated, organizations can expand to additional systems, resources, partners and use cases.
• Prepare for future digital initiatives. A governed FHIR foundation can support patient applications, partner integrations, analytics and future AI-driven healthcare workflows.

This list is drawn from public provider information and third-party roundups. It is not an independent ranking, so healthcare organizations should validate any shortlist against their own EHR environment, interoperability requirements, scale and compliance needs.

• OptiSol Business Solutions
  OptiSol works on healthcare interoperability, FHIR-based API architecture, legacy integration and Azure modernization. Its healthcare capabilities are relevant for organizations looking to introduce a modern interoperability layer while continuing to support existing systems.
• Taction Software
  A U.S.-based healthcare software company with experience implementing FHIR on Azure, including FHIR, DICOM and MedTech services, authentication and healthcare integration patterns. It also publicly supports migration from Azure API for FHIR.
• Langate Software
  A Microsoft Gold Partner with .NET and Azure expertise and experience in HL7, FHIR and HIPAA-focused healthcare solutions. It is suited to organizations looking for Azure-native API development and EHR integration.
• CapMinds
  Provides FHIR R4 and SMART on FHIR API development for EHRs, portals, payers and third-party applications. Its capabilities include Azure Health Data Services, HIE and EHR integration.
• Health Samurai
  A FHIR-focused organization behind the Aidbox FHIR backend platform. Its work focuses on healthcare data standards, API design and cross-system data orchestration.