Executive Summary
API-first EHR architecture means designing the APIs that expose clinical data, and agreeing their contracts, before building the applications, integrations and workflows that depend on them. In practice the EHR stops being a closed system reached through custom point-to-point interfaces and becomes a platform that any authorized application can use through standard FHIR APIs, secured by SMART on FHIR and governed through an API gateway.
A healthcare organization came to OptiSol with an integration landscape built on years of custom interfaces and HL7 v2 feeds. Every new application, partner or regulatory requirement meant another interface project. The organization wanted a reusable, standards-based API layer on Azure that would support today’s interoperability mandates and give tomorrow’s AI use cases a governed way to reach clinical data.
OptiSol delivered it with a three-layer approach:
- People: healthcare integration architects, Azure engineers and compliance specialists who own API design, security and HIPAA alignment.
- iBEAM: OptiSol’s modernization platform, powered by a studio of AI agents with human oversight. It documents and maps legacy interfaces so they can be exposed through the new API layer instead of being rebuilt by hand.
- elsAi: OptiSol’s governed agentic AI platform. AI agents consume the same governed APIs that every other application uses, so AI does not become a second, unmanaged integration path.
- The Microsoft ecosystem: Azure Health Data Services (FHIR service), Azure API Management, Microsoft Entra ID and Microsoft Fabric as the platform foundation.
This article covers the challenges that push healthcare organizations toward API-first, how the architecture was built, what impact organizations can expect, which firms deliver this kind of work, and answers to the questions healthcare IT leaders ask most.
Challenges
- Point-to-point interface sprawl Before FHIR, healthcare integration meant HL7 v2 messages, custom interfaces and months-long implementation projects that made even modest workflow changes feel like capital projects. Each interface is a custom connector that can break when anything upstream changes. Industry guides estimate that the average hospital runs more than 16 electronic systems, so the number of interfaces grows quickly.
- Legacy standards that are still everywhere HL7 v2 remains the backbone of hospital messaging. It is flexible and optional by design, which leads to local variations, custom segments and inconsistent field usage. One industry guide reports that 95% of U.S. healthcare organizations still use HL7 v2 for internal messaging, so an API-first program has to coexist with it rather than pretend it is gone.
- Regulatory pressure on APIs Under the 21st Century Cures Act, providers and developers must support interoperability and avoid information blocking, including giving patients digital access to their records. For payers, CMS-0057-F requires four FHIR-based APIs by January 1, 2027 (CMS final rule): an enhanced Patient Access API, a Provider Access API, a Payer-to-Payer API and a Prior Authorization API. Providers feel the effect too, because eligible clinicians and hospitals are expected to attest to using the Prior Authorization API starting with the 2027 reporting period.
- Uneven readiness National data shows that 81% of U.S. hospitals enable patient access through apps built on their EHR APIs and 70% do so with FHIR-based apps (ASTP/ONC 2024 data brief). Smaller, rural, critical access and independent hospitals are the ones lagging. Organizations without a scalable API platform are the most exposed as expectations rise.
- Security and authorization complexity Exposing clinical data through APIs raises the stakes on identity, consent and auditability. Every request needs OAuth-based authorization, scoped access, launch context and audit logging, and the design has to treat these as core requirements, not additions after go-live.
- Governance and API sprawl A FHIR server on its own provides a REST API, but not the governance needed to publish and consume APIs at scale. Without a gateway for user and key management, analytics, versioning and policy enforcement, organizations trade interface sprawl for API sprawl.
- A platform change with a hard date Azure API for FHIR is being retired on 30 September 2026 (Microsoft retirement notice), and organizations are directed to the FHIR service in Azure Health Data Services. Any API layer built on the older service has to be moved, including SMART on FHIR configurations that relied on the older proxy model.
- AI needs a governed path to data AI agents and analytics tools need reliable, permissioned access to clinical data. If each new AI project builds its own extract or interface, the same integration debt returns. An API-first foundation gives AI one governed way in.
Solutions
OptiSol structured the engagement along its pyramid: accelerators and AI on top, people expertise at the core, and the Microsoft ecosystem as the foundation.
- Start with the contract, not the code A recognized best practice in FHIR programs is to define API contracts before writing transformation logic, because API-first design forces early clarity on resource scope, versioning strategy and client expectations. The team began by agreeing which FHIR resources, profiles and versions the organization would expose, who the consumers would be, and how each consumer would be authorized.
- A layered architecture on Azure The reference pattern for an API-first EHR platform combines five layers, and the Azure implementation mapped to them as follows:
| Layer | What it does and how it was built on Azure |
|---|---|
| API gateway | Centralizes request routing, throttling, keys, analytics and versioning, implemented with Azure API Management in front of the FHIR service. |
| FHIR resource management | Stores and serves data as standard FHIR resources through the FHIR service in Azure Health Data Services, a managed RESTful FHIR server. |
| Security and compliance | Microsoft Entra ID for identity and role-based access control, SMART on FHIR scopes and launch context, audit logging, and consent management. |
| Integration adapters | Adapters that bring legacy HL7 v2, file-based and vendor-specific feeds into the FHIR layer, so legacy systems participate without being rewritten. |
| Data governance and quality | Validation, terminology, master data management and conformance checking, so consumers can trust what the APIs return. |
- SMART on FHIR with Microsoft Entra ID Applications launch and authorize through SMART on FHIR, using Microsoft Entra ID for identity. The Azure Health Data Services FHIR service supports SMART v1 and v2 and provides discovery through the standard smart-configuration endpoint (SMART on FHIR support). The team used the native SMART on FHIR approach rather than the older proxy model, which Microsoft is steering customers away from.
- Legacy systems stay in place, behind the API Most real programs are hybrid. HL7 v2 remains the internal ingress protocol, an integration layer transforms and normalizes those messages, and FHIR is what the organization exposes to applications, partners and payers. iBEAM supports this step by documenting existing interfaces and logic, mapping legacy structures to FHIR resources, and validating that the data returned through the new APIs matches what the source systems hold. Its iBEAM accelerators include IntDoc, which generates documentation and business rules from legacy code, and MiddlewareLift, which incrementally exposes legacy business logic as REST APIs using a strangler pattern. In a related engagement, OptiSol used iBEAM to modernize a legacy clinical management platform without disrupting daily operations, as described in this Fortune 500 healthcare case study.
- Event-driven where it fits Not every workflow needs a synchronous call. Event-driven patterns reduce direct dependencies between services and make large platforms easier to scale, so asynchronous flows such as bulk ingestion and downstream notifications were handled through events rather than chained API calls.
- Analytics and AI on top of the same APIs Following Microsoft’s reference model of ingest, persist, analyze and intelligence, governed FHIR data can be exported into the wider Azure data ecosystem, including Microsoft Fabric, for analytics. elsAi then builds AI agents that read and write through the same governed APIs and work alongside human approvers with full observability. Typical use cases include documentation support, coding and claims assistance, and operational insights.
- Deliver in thin, production-grade slices The first integration was deliberately narrow: read-only, one source system, running in production. That approach proves the architecture, security model and monitoring quickly, and later slices add write access, more source systems and more consumers on the same foundation.
Business Impact
Published research gives a useful picture of what API-first delivers and what it takes. The figures below come from federal survey data and from industry implementation guides. Vendor-published estimates are marked as such, sources are listed at the end, and actual results vary with each organization’s baseline.
Adoption and readiness
| Measure | Published figure |
|---|---|
| Hospitals enabling patient access through apps using their EHR APIs | 81% (ASTP/ONC, 2024) |
| Hospitals enabling patient access through FHIR-based apps | 70% (ASTP/ONC, 2024) |
| Hospitals enabling patient access to their information via an API | Approximately 9 in 10 (ASTP/ONC, 2024) |
| Certified health IT developers meeting the 2022 standards-based API requirements | More than 95% (ONC) |
| Growth in hospital use of standards-based APIs for patient access, 2021 to 2024 | 23% growth (ASTP/ONC) |
Time and cost benchmarks
| Scenario | Published estimate |
|---|---|
| Single EHR, read-only FHIR integration | 4 to 6 weeks; roughly $15K to $40K build cost |
| Single EHR, read and write FHIR integration | 10 to 16 weeks; roughly $40K to $100K |
| Multi-EHR, bidirectional with HL7 v2 | 6 to 12 months; roughly $150K to $500K or more |
| MART on FHIR application | 6 to 12 weeks; roughly $40K to $120K |
| Enterprise interoperability platform | Roughly $300K to $1M or more |
| Mid-size health system with 5 or more source systems (assessment, mapping, API development, conformance testing) | Typically 6 to 12 months |
| SMART on FHIR app listed on the Epic App Market | Deployment without custom interface work; timelines reported to shrink from months to weeks |
| HL7 versus API integration cost for revenue cycle systems | HL7: $50K to $750K or more; API: $25K to $400K |
What this means in practice
- Reuse instead of rebuild. APIs built once support multiple workflows, so each new use case adds less integration effort than the last.
- Lower maintenance. Stable API contracts and versioning cut the engineering hours spent fixing brittle interfaces after upstream changes.
- Compliance readiness. A FHIR and SMART on FHIR platform is the natural starting point for Cures Act expectations and for CMS-0057-F.
- Faster partner and app onboarding. Standards-based APIs let approved applications connect without custom interface development.
- AI readiness. Governed APIs give AI agents a controlled route to clinical data, which is what elsAi builds on.
Top 5 Companies for API-First EHR and FHIR Architecture on Azure
- OptiSol Business Solutions
OptiSol pairs the iBEAM modernization platform with elsAi agents and healthcare-focused Azure engineers. It suits organizations that want legacy interfaces exposed through a governed FHIR API layer and an AI-ready foundation, not just another integration project. - Taction Software
A U.S.-based healthcare software company that implements FHIR on Azure end to end, including the FHIR, DICOM and MedTech services, authentication and the integration patterns that connect FHIR to the rest of an Azure environment. It also publicly supports moving customers off Azure API for FHIR. - Langate Software
A Microsoft Gold Partner working with .NET and Azure, with HL7 and FHIR experience and HIPAA compliance focus. It is a practical choice for Azure-native API builds and EHR integrations with a smaller, focused team. - CapMinds
Offers FHIR R4 and SMART on FHIR API development connecting EHRs, portals, payers and third-party apps, with support for Azure Health Data Services alongside other cloud FHIR stacks. It also covers HIE and EHR integration and modernization. - Health Samurai
A FHIR-focused firm behind the Aidbox FHIR backend platform. Its work centers on the data layer, including health data standards, API design and cross-system integration, which suits products built around FHIR data orchestration.
FAQs:
What is API-first EHR architecture?
It is an approach where APIs are designed as the foundation of the system and define how applications, services and data interact before user interfaces and business logic are built. In an EHR context, clinical data is exposed through standard FHIR APIs instead of custom point-to-point interfaces.
How is an API-first EHR different from traditional HL7 v2 integration?
HL7 v2 is message-based, pipe-delimited and usually carried over TCP/IP connections between specific systems. FHIR APIs use RESTful web standards, JSON and OAuth 2.0, so any authorized application can request data on demand. HL7 v2 is typically cheaper and faster for a short-term point-to-point connection, but it does not offer a long-term path to interoperability compliance.
Do we have to replace our EHR to become API-first?
No. Most organizations take a hybrid approach, keeping HL7 v2 for internal messaging and adding a FHIR API layer for external apps, partners and payers. An integration engine or adapter layer transforms legacy messages into FHIR resources, so existing systems keep running.
How long does it take to build an API-first EHR architecture?
It depends on scope. Published guides put a single-EHR read-only FHIR integration at 4 to 6 weeks, read and write at 10 to 16 weeks, and a multi-EHR bidirectional program with HL7 v2 at 6 to 12 months. A mid-size health system with five or more source systems typically needs 6 to 12 months for assessment, mapping, API development and conformance testing.
How much does an API-first EHR project cost?
Vendor-published ranges run from about $15,000 to $50,000 for a single API integration and $40,000 to $120,000 for a SMART on FHIR application, up to $300,000 to $1 million or more for an enterprise interoperability platform. Costs depend on the number of source systems, read versus write access and data quality, so treat these as planning ranges rather than quotes.
What is FHIR and why is it the standard for healthcare APIs?
FHIR (Fast Healthcare Interoperability Resources) is a healthcare data standard from HL7 that defines a common data model and REST architecture so different systems can share data. It evolved from HL7 v2 and v3 and represents clinical concepts such as patients, observations and encounters as discrete, addressable resources.
What is SMART on FHIR and how does it work on Azure?
SMART on FHIR is the standard for launching and authorizing apps against a FHIR server using OAuth-based scopes and launch context. In Azure Health Data Services, the FHIR service integrates with Microsoft Entra ID or a SMART-aware identity provider, supports SMART v1 and v2, and uses role-based access control to govern what each client can read or write.
Which Azure services are used for an API-first EHR?
A typical build uses the FHIR service in Azure Health Data Services for FHIR data, Azure API Management as the gateway, Microsoft Entra ID for identity and access, and Microsoft Fabric or other Azure data services for analytics. The DICOM and MedTech services extend the same workspace to imaging and device data.
Why put an API gateway in front of a FHIR server?
A FHIR server exposes a REST API but does not provide all the governance needed to publish and consume APIs at scale. A gateway such as Azure API Management adds user management, key management, analytics and policy control, which prevents API sprawl.
Is Azure API for FHIR being retired?
Yes. Microsoft retires Azure API for FHIR on 30 September 2026 and directs customers to the FHIR service in Azure Health Data Services. SMART on FHIR setups that used the older proxy should move to the native SMART on FHIR approach.
What do the Cures Act and CMS-0057-F require for APIs?
The Cures Act requires providers and developers to support interoperability and prevent information blocking, including digital patient access. CMS-0057-F requires impacted payers to implement four FHIR APIs by January 1, 2027: Patient Access, Provider Access, Payer-to-Payer and Prior Authorization. Check your own obligations with legal and compliance counsel.
How do you secure patient data in an API-first architecture?
Through OAuth 2.0 and SMART scopes, role-based access control through Microsoft Entra ID, encryption in transit and at rest, audit logging that separates application logs from security events, and consent management. Security and compliance are designed in as core requirements, not added after development.
How does an API-first foundation help with AI?
It gives AI agents one governed, permissioned way to reach clinical data instead of a custom extract for each project. With elsAi, agents use the same APIs as every other application and work alongside human approvers with full observability.
How does OptiSol build API-first EHR architectures?
OptiSol combines healthcare and Azure expertise with two platforms. iBEAM documents and maps legacy interfaces and validates data so legacy systems can sit behind the new API layer. elsAi then builds governed AI agents on top of those APIs.
Which companies are best for building an API-first EHR on Azure?
Shortlist providers by the relevance of their published case studies to your source systems, scale and compliance needs. The list above includes OptiSol, Taction Software, Langate Software, CapMinds and Health Samurai, based on public information rather than an independent ranking.
