Healthcare applications increasingly need to exchange data with EHRs, patient apps, laboratories, pharmacies, medical devices, payers, and other clinical systems.
Traditional healthcare integrations can make this difficult because different systems may use different data models, interfaces, and messaging standards. HL7 FHIR Development Services provide a modern approach to building healthcare APIs and interoperability layers around a standardized data model.
FHIR is an API-focused healthcare interoperability standard developed by HL7. It uses modular resources and established web technologies to support the exchange of clinical and administrative information.
For developers, however, implementing FHIR is more than creating REST endpoints. The real work involves resource modeling, profiles, terminology, authentication, data mapping, validation, testing, and integration with existing healthcare systems.
What Is HL7 FHIR?
FHIR stands for Fast Healthcare Interoperability Resources.
The standard organizes healthcare information into modular components called Resources. Examples include:
Patient
Observation
Condition
Medication
Encounter
Procedure
DiagnosticReport
AllergyIntolerance
CarePlan
Device
These resources provide reusable building blocks for healthcare applications.
A developer can expose or consume resources through FHIR APIs rather than designing a completely custom data exchange format for every integration.
FHIR also supports JSON and XML representations and provides RESTful interaction patterns. HL7 describes FHIR as a framework designed around modern web standards and multiple exchange approaches.
Why Developers Use FHIR
FHIR addresses a common problem in healthcare development: connecting systems that need to exchange similar types of information but use different technical architectures.
A FHIR-based architecture can help developers build:
Patient-facing applications
EHR integrations
Provider dashboards
Telehealth applications
Health information exchanges
Remote monitoring platforms
Clinical analytics systems
Healthcare data platforms
Payer-provider integrations
The benefit is not simply having an API.
FHIR provides a common vocabulary and structure that applications can use when exchanging healthcare information.
Understanding FHIR Resources
Resources are the foundation of FHIR development.
Consider a simple patient workflow. A healthcare application may need demographic information, observations, medications, and encounters.
Instead of creating a single custom object containing everything, the application can work with separate resources and relationships between them.
For example:
Patient
├── Encounter
├── Observation
├── Condition
├── MedicationRequest
└── DiagnosticReport
This modular approach allows applications to request and process the information relevant to a particular workflow.
ONC describes FHIR resources as the basic data exchange format and model of FHIR.
Building FHIR REST APIs
A typical FHIR server exposes resources through HTTP-based operations.
For example:
GET /Patient/123
GET /Patient?name=John
GET /Observation?patient=123
POST /Observation
PUT /Patient/123
The API layer needs to handle more than HTTP routing.
A production implementation should consider:
Resource validation
Search parameters
Authorization
Versioning
Error handling
Audit logging
Pagination
Rate limiting
Concurrency
Transaction handling
FHIR APIs should also expose their capabilities clearly so consuming applications can understand what the server supports.
CapabilityStatement and API Discovery
FHIR includes the CapabilityStatement resource for describing a server's capabilities.
It can communicate information such as:
Supported FHIR version
Supported resources
Supported interactions
Search parameters
Operations
Profiles
Security capabilities
This becomes important when integrating with external EHRs or healthcare platforms.
Two systems may both support FHIR while exposing different resources, profiles, operations, and search capabilities.
Developers should therefore inspect the server's declared capabilities before designing the integration.
FHIR Profiles and Implementation Guides
Base FHIR resources are intentionally flexible.
Real healthcare workflows often need additional constraints.
This is where profiles and Implementation Guides (IGs) become important.
A profile can constrain a resource by specifying required elements, allowed values, cardinality, terminology bindings, and other implementation requirements.
For example, an implementation may require a Patient resource to contain specific demographic fields.
An Implementation Guide brings these definitions together with examples, terminology, API behavior, and workflow guidance.
A FHIR implementation should therefore start by identifying the applicable IG rather than simply implementing the base resource definitions.
FHIR and EHR Integration
One of the most common FHIR development scenarios is connecting an application to an EHR.
A typical architecture looks like:
Patient / Provider App
|
v
API Gateway
|
v
FHIR Integration Service
|
v
EHR FHIR API
|
v
Clinical Data
The integration service can handle:
Authentication
Token management
Resource mapping
Validation
Error handling
Logging
Retry logic
Vendor-specific behavior
This keeps EHR-specific integration logic away from the application's core business services.
SMART on FHIR
FHIR defines how healthcare information can be represented and exchanged. SMART on FHIR adds application authorization patterns for connecting applications to FHIR systems.
OAuth-based authorization allows applications to request specific access rather than receiving unrestricted access to a patient's entire record.
A typical workflow can look like:
User
|
v
Healthcare Application
|
v
Authorization Server
|
v
FHIR Server
The application receives an access token with defined permissions and uses that token when calling FHIR APIs.
For developers, this means authentication and authorization need to be designed alongside the API architecture rather than added later.
Mapping HL7 v2 to FHIR
FHIR does not mean legacy healthcare standards disappear.
HL7 v2 remains widely deployed, and many healthcare organizations need to connect existing HL7 v2 interfaces with newer FHIR applications. HL7 describes FHIR as having an evolutionary relationship with earlier HL7 standards, allowing different approaches to coexist.
A common architecture is:
HL7 v2 Message
|
v
Interface Engine
|
v
Transformation Layer
|
v
FHIR Resource
|
v
FHIR API
The transformation layer needs to handle field mapping, terminology, identifiers, data validation, and error conditions.
This is often one of the more complex parts of FHIR implementation.
FHIR Terminology Management
Healthcare interoperability depends on more than matching JSON structures.
Two systems may exchange an Observation successfully while using different codes or value sets.
Terminology services help developers validate and resolve clinical codes and value sets.
ONC's 2026 Cartos service provides a FHIR R4-based terminology API for terminology discovery, value set expansion, concept lookup, and validation. ONC specifically positions centralized terminology access as a way to reduce inconsistency and support semantic interoperability.
For production systems, terminology architecture should therefore be considered part of the interoperability design.
FHIR Search
FHIR APIs support search operations that allow applications to retrieve resources based on parameters.
For example:
GET /Patient?identifier=12345
GET /Observation?patient=Patient/123
GET /MedicationRequest?patient=Patient/123
Search implementation requires careful consideration of:
Supported parameters
Composite searches
Pagination
Sorting
Performance
Authorization filters
Indexing
A FHIR server can technically support an endpoint while still performing poorly if its underlying database and search indexes are not designed correctly.
FHIR Bundles and Transactions
FHIR Bundle resources allow multiple resources to be grouped into a single package.
Bundles can support use cases such as:
Search result sets
Document-style exchanges
Message workflows
Transaction requests
Batch processing
For transaction bundles, multiple operations can be processed together.
This becomes useful when an application needs to create or update several related resources while maintaining consistency.
Developers should distinguish between batch processing and transaction processing because their behavior and failure handling differ.
FHIR Subscriptions and Event-Driven Architecture
Some healthcare applications need to know when information changes rather than continuously polling an API.
FHIR supports subscription-based patterns for event-driven workflows.
A simplified architecture can look like:
EHR / FHIR Server
|
| Event
v
FHIR Subscription
|
v
Message Broker
|
+----> Patient App
+----> Provider Dashboard
+----> Analytics
+----> Notification Service
This architecture can reduce unnecessary polling and support near-real-time workflows.
The exact subscription capabilities depend on the FHIR version and implementation being used, so developers should validate the target server's supported operations.
Security in FHIR Development
Healthcare APIs handle sensitive information, making security a core architectural concern.
A production FHIR implementation should consider:
OAuth 2.0
OpenID Connect
SMART on FHIR
Access scopes
Role-based authorization
Encryption
Audit logging
Consent
Token lifecycle management
Rate limiting
API monitoring
Authorization should be granular enough to ensure applications receive only the information required for their intended workflow.
Security also needs to extend to logs. Developers should avoid writing sensitive patient information into application logs unnecessarily.
Database Architecture for FHIR
FHIR resources can be stored using different database strategies.
A relational database can work well when applications require structured querying and strong transactional consistency.
Document-oriented storage can also be useful because FHIR resources have hierarchical JSON structures.
A production platform may use a combination:
FHIR API
|
FHIR Service Layer
|
+---- PostgreSQL
|
+---- Redis
|
+---- Object Storage
|
+---- Search / Analytics
The correct architecture depends on resource volume, search requirements, transaction patterns, analytics workloads, and operational constraints.
The goal should be to optimize for the application's actual access patterns rather than choosing a database simply because it can store JSON.
Testing FHIR Implementations
FHIR testing should happen at multiple levels.
Resource Validation
Verify that resources conform to the required profiles and constraints.
API Testing
Test CRUD operations, search, pagination, errors, authentication, and authorization.
Integration Testing
Connect the implementation to external EHRs or FHIR servers.
Interoperability Testing
Verify that another compliant implementation can consume the resources correctly.
Security Testing
Test authentication, authorization, token handling, access scopes, and data exposure.
ONC lists Inferno among its conformance testing resources for FHIR-based standardized APIs and US Core implementations.
Testing against implementation guides and relevant conformance tools can reveal problems that ordinary API unit tests may miss.
Common FHIR Development Challenges
Choosing the Right Resources
Healthcare workflows can involve many related resources, making resource selection an architectural decision.
Vendor Differences
Different EHR vendors may implement FHIR capabilities differently.
Legacy Integration
Existing HL7 v2 systems may require transformation before information can enter a FHIR workflow.
Terminology
Codes, value sets, and terminology versions can create interoperability issues.
Performance
Large patient datasets and complex searches can create database and API performance challenges.
Security
Healthcare APIs require strong access control and careful handling of sensitive information.
Version Management
FHIR versions, implementation guides, profiles, and vendor capabilities need to be tracked carefully.
A Practical FHIR Development Workflow
A reliable implementation can follow these stages:
1. Define the workflow
Start with the clinical or business use case.
2. Identify data requirements
Determine which patient, clinical, administrative, or device information is required.
3. Select the FHIR version
Confirm the FHIR release supported by the target systems.
4. Identify implementation guides
Determine applicable profiles, extensions, terminology, and API requirements.
5. Design the architecture
Define FHIR servers, integration services, databases, authorization, and external interfaces.
6. Build the resources and APIs
Implement profiles, endpoints, search parameters, validation, and business rules.
7. Integrate external systems
Connect EHRs, applications, devices, or other healthcare platforms.
8. Test interoperability
Validate resources and workflows against target implementations and conformance requirements.
9. Monitor production
Track API latency, errors, authorization failures, resource validation issues, and integration health.
Current Direction of FHIR
FHIR continues to expand beyond basic clinical data exchange.
In July 2026, ONC finalized adoption of updated FHIR implementation guides covering areas such as prior authorization, payer-provider data exchange, drug formularies, provider directories, and clinical data exchange.
FHIR is also becoming increasingly relevant to terminology and AI-related healthcare workflows. HL7 has highlighted the machine-readable and developer-oriented nature of FHIR as an advantage for standards-aware software and AI systems.
For developers, this means FHIR implementations need to be designed for evolution rather than treated as one-time API projects.
How We Approach FHIR Development
At Oodles, we approach HL7 FHIR Development Services as an interoperability engineering problem.
Our development approach can cover FHIR API development, EHR and EMR integration, resource and profile modeling, HL7 v2-to-FHIR transformation, SMART on FHIR, healthcare data platforms, terminology integration, secure APIs, and interoperability testing.
The architecture is designed around the actual healthcare workflow and the capabilities of the systems being connected.
This helps avoid building a technically compliant API that does not work effectively with the real healthcare environment.
Final Thoughts
HL7 FHIR Development Services provide developers with a standardized foundation for building connected healthcare applications.
But implementing FHIR successfully requires more than understanding resources and REST APIs.
Developers need to consider implementation guides, profiles, terminology, authorization, legacy integration, database architecture, testing, and vendor-specific capabilities.
FHIR gives healthcare software teams a common framework. The engineering challenge is turning that framework into reliable, secure, production-ready workflows.
That is where careful architecture and healthcare interoperability expertise make the difference.
Top comments (0)