Healthcare applications need to exchange clinical information across EHRs, patient portals, laboratories, pharmacies, medical devices, and other systems. Traditional interfaces can make these integrations difficult to scale when every system follows different structures and workflows.
HL7 FHIR Development Services help development teams build standards-based healthcare applications and APIs around a common data model. FHIR supports structured resources, RESTful interactions, modern API patterns, and implementation guides that can be adapted to specific healthcare use cases.
For developers, understanding FHIR means understanding more than its resources. A production implementation also requires API design, authentication, terminology, validation, interoperability testing, error handling, and integration architecture.
What Is HL7 FHIR?
Fast Healthcare Interoperability Resources (FHIR) is an HL7 standard for exchanging healthcare information.
FHIR organizes healthcare information into modular resources. Examples include Patient, Observation, Condition, Encounter, MedicationRequest, DiagnosticReport, and AllergyIntolerance.
FHIR also defines RESTful interactions and formats such as JSON and XML. The FHIR specification provides the technical foundation for creating, reading, updating, searching, and exchanging these resources.
HL7's published specification currently lists FHIR Release 5 as the current published release, while Release 6 is progressing through the development and ballot process. FHIR R4 remains widely relevant because it contains normative portions of the specification and continues to appear in implementation environments.
The appropriate FHIR version should therefore be selected based on the target ecosystem, implementation guide, EHR, and interoperability requirements rather than simply choosing the newest release.
Why FHIR Matters for Healthcare Developers
Healthcare systems often contain information that must move between applications.
A hospital may need to expose patient information to a mobile application. A clinic may need to connect its scheduling platform with an EHR. A health platform may need laboratory observations for analytics.
FHIR provides standardized building blocks for these workflows.
HL7 FHIR Development Services can help teams build:
FHIR servers
FHIR-based REST APIs
Patient-facing applications
EHR integrations
Clinical data platforms
Provider applications
Healthcare mobile applications
Interoperability middleware
Medical device data integrations
Healthcare analytics pipelines
The implementation still depends on the capabilities of the connected systems and the applicable implementation guides.
Understanding FHIR Resources
Resources are central to FHIR development.
A resource represents a specific healthcare concept and contains defined elements that applications can exchange.
For example, a simplified Patient resource can contain information such as:
{
"resourceType": "Patient",
"id": "12345",
"name": [
{
"family": "Doe",
"given": ["Alex"]
}
],
"gender": "unknown"
}
In a real implementation, developers need to account for profiles, extensions, identifiers, references, terminology, validation, and implementation-specific requirements.
The resource itself is only one part of the integration. The surrounding API and security architecture determine how that resource is accessed and used.
FHIR REST APIs
FHIR's RESTful API model is familiar to developers who have worked with modern web services.
Common interactions include:
GET for retrieving resources
POST for creating resources
PUT for replacing resources
PATCH for partial updates
DELETE for removing resources
GET [type]?parameter=value for searches
For example:
GET /Patient/12345
can retrieve a specific patient resource when the server and authorization policy permit access.
A search request might look like:
GET /Patient?identifier=12345
The exact query parameters and supported interactions depend on the server's capability statement and implementation requirements.
Good HL7 FHIR Development Services should therefore include API discovery and capability analysis before integration work begins.
FHIR Capability Statements
A FHIR server does not necessarily support every resource or interaction defined by the specification.
The CapabilityStatement describes what a FHIR server supports.
Developers can use it to determine:
Supported FHIR version
Available resources
Supported interactions
Search parameters
Operations
Security mechanisms
Profiles
Implementation details
This is especially important when integrating with third-party EHR systems.
Instead of assuming that every FHIR endpoint behaves identically, integration code should inspect the server's capabilities and implementation documentation.
FHIR Profiles and Implementation Guides
Base FHIR resources are intentionally flexible.
Healthcare organizations often need additional constraints for specific workflows. Profiles can define required elements, allowed values, cardinality, and other constraints on resources.
Implementation Guides (IGs) package these requirements for particular use cases or jurisdictions.
An implementation guide can define:
Profiles
Extensions
Value sets
Code systems
Examples
Search parameters
Operations
Capability expectations
This is why HL7 FHIR Development Services should not treat the base FHIR specification as the entire implementation requirement.
A project may need to follow a national, regional, payer-specific, clinical, or organizational implementation guide.
FHIR Terminology and Clinical Codes
Interoperability depends on more than JSON structure.
Clinical concepts also need consistent terminology.
FHIR includes terminology resources such as:
CodeSystem
ValueSet
ConceptMap
Healthcare implementations may also use established terminology systems such as LOINC, SNOMED CT, RxNorm, and ICD-based coding systems, depending on the use case and jurisdiction.
Terminology mapping becomes important when two systems represent the same clinical concept differently.
A terminology service can help applications validate and translate codes while keeping business logic separate from individual code systems.
ONC launched Cartos in 2026 as a public, FHIR-enabled terminology service connected to ONC regulations and certification information.
EHR Integration With FHIR
EHR integration is one of the most common FHIR use cases.
A typical workflow can look like this:
A user launches a healthcare application.
The application authenticates the user.
The application obtains authorized access to the EHR.
The application requests permitted FHIR resources.
The integration layer validates the response.
The application maps the data into its internal model.
The user interacts with the approved clinical information.
This architecture separates the healthcare interoperability layer from the application's business logic.
It also makes it easier to support multiple EHR vendors without tightly coupling every frontend feature to a vendor-specific API.
SMART on FHIR and Authorization
Healthcare applications often need delegated access to clinical data.
SMART on FHIR provides an approach for building applications that connect to FHIR systems using OAuth-based authorization patterns.
A production integration should define:
Authentication flow
Authorization scopes
Token handling
Redirect URI controls
Session management
Access expiration
Refresh behavior
Audit requirements
Security should be designed before API integration begins.
HL7 FHIR Development Services should include authorization planning based on the application's users, data types, workflow, and regulatory requirements.
Building a FHIR Integration Layer
A dedicated integration layer can simplify complex healthcare architectures.
Instead of connecting every application directly to every external system, organizations can introduce an interoperability service.
For example:
EHR / Lab / Device
|
v
Integration Layer
|
FHIR Services
|
+---- Patient App
|
+---- Provider Portal
|
+---- Analytics
|
+---- AI Applications
The integration layer can handle authentication, transformation, validation, terminology mapping, logging, retries, and routing.
This approach also creates a central location for managing external system changes.
HL7 v2 and FHIR Together
FHIR does not automatically replace every existing healthcare interface.
Many healthcare organizations still operate systems using HL7 v2 messages, C-CDA documents, proprietary APIs, or other integration mechanisms.
A practical architecture may therefore use both legacy and modern interfaces.
For example:
HL7 v2 Messages
|
v
Interface Engine
|
Transformation
|
FHIR Resources
|
FHIR API
|
Applications
This allows organizations to modernize application access without requiring every existing system to migrate immediately.
FHIR and Medical Device Data
Medical devices create another important interoperability challenge.
Modern devices can generate high-frequency information, but moving that data into EHRs and analytics platforms requires reliable integration patterns.
In March 2026, HL7 launched the Caliper FHIR Accelerator to advance standards-based exchange of data from medical and personal health devices. HL7 describes the initiative as a way to support more consistent device data integration into EHRs, analytics platforms, and AI-enabled applications.
This creates opportunities for developers working on:
Remote patient monitoring
Connected medical devices
Wearable integrations
ICU data workflows
Home healthcare platforms
Clinical analytics
AI-enabled healthcare applications
The integration architecture must still account for device-specific protocols, data frequency, clinical context, and validation requirements.
FHIR for AI-Ready Healthcare Applications
AI systems need access to reliable clinical information.
FHIR can provide structured healthcare data that applications can use for analytics, retrieval, and other downstream workloads.
For example, an AI platform may consume:
Patient demographics
Conditions
Observations
Medications
Encounters
Diagnostic reports
Procedures
However, FHIR alone does not make data AI-ready.
Teams still need data quality controls, terminology normalization, patient identity management, provenance, access controls, and appropriate governance.
The value comes from combining standardized clinical data with a well-designed data architecture.
Security Considerations
Healthcare APIs handle sensitive information, so security needs to cover the complete request lifecycle.
A FHIR implementation should consider:
TLS for data in transit
Encryption at rest
OAuth-based authorization
Role-based access control
Least-privilege permissions
Audit logging
Token protection
Input validation
Rate limiting
API monitoring
Secure secrets management
Developers should also avoid exposing sensitive information through application logs, error messages, URLs, or debugging tools.
Security requirements should be mapped to the organization's regulatory obligations and risk assessment.
Testing FHIR Applications
FHIR testing requires more than checking whether an API returns HTTP 200.
Testing should cover:
Resource validation: Confirm resources follow required profiles and constraints.
Terminology validation: Check codes against required value sets.
API testing: Validate CRUD operations, searches, parameters, pagination, and error handling.
Authorization testing: Verify that users can access only permitted resources.
Interoperability testing: Test against actual partner systems and implementation guides.
Performance testing: Evaluate response times, concurrent requests, and large datasets.
Negative testing: Confirm invalid resources and unauthorized requests are handled correctly.
FHIR validation tools and implementation-guide-specific validators can help identify interoperability issues before production deployment.
Designing Scalable FHIR Applications
FHIR applications should be designed around expected workload and integration behavior.
Important architectural considerations include:
Stateless API services
Horizontal scaling
Caching where appropriate
Asynchronous processing
Queue-based integration
Retry mechanisms
Rate-limit handling
Pagination
Bulk data workflows
Monitoring
Disaster recovery
Large healthcare environments may process both real-time API requests and high-volume batch workloads.
A scalable architecture should support both without allowing one workload to negatively affect another.
Current FHIR Interoperability Direction
FHIR adoption continues to expand across healthcare interoperability initiatives.
ONC released USCDI v7 on July 23, 2026, adding new data elements to advance interoperability for patient care. ONC describes USCDI as a foundation for the access, exchange, and use of electronic health information.
HL7 is also continuing work through FHIR Accelerators focused on specific domains, including medical devices, oncology, public health, and payer-provider interoperability.
For developers, this means FHIR implementation increasingly involves domain-specific implementation guides and profiles rather than relying only on the base specification.
Our Approach to HL7 FHIR Development Services
At Oodles, we approach FHIR development as an interoperability architecture problem rather than simply an API development task.
The process typically starts with understanding the source and target systems, FHIR version, implementation guide, resources, terminology, authentication model, and business workflows.
The development workflow can include:
Integration analysis
Review EHRs, APIs, existing interfaces, implementation guides, and data requirements.
FHIR architecture
Define resources, profiles, APIs, terminology, and integration boundaries.
API development
Build FHIR endpoints and supporting services.
EHR integration
Connect the application with supported healthcare systems.
Security implementation
Configure authentication, authorization, encryption, logging, and access controls.
Validation and testing
Validate resources and test interoperability against target systems.
Deployment and monitoring
Deploy the platform and monitor API performance, failures, integrations, and security events.
Final Thoughts
FHIR gives healthcare developers a standards-based foundation for building interoperable applications, but successful implementations require more than creating a few REST endpoints.
The real engineering work involves understanding resources, profiles, terminology, authorization, implementation guides, legacy interfaces, testing, and production integration behavior.
HL7 FHIR Development Services can help organizations connect EHRs, patient applications, medical devices, analytics platforms, and other healthcare systems through a structured interoperability architecture.
As healthcare organizations expand API-based exchange and AI-enabled workflows, FHIR expertise becomes increasingly valuable for building applications that can work across complex healthcare ecosystems.
Frequently Asked Questions
1. What are HL7 FHIR Development Services?
They cover the design and development of FHIR-based APIs, healthcare integrations, FHIR servers, applications, resource models, terminology services, security, validation, and interoperability workflows.
2. Which FHIR version should a project use?
The choice depends on the target EHR, implementation guide, ecosystem, and integration requirements. Developers should verify the version supported by each external system.
3. Can FHIR integrate with existing HL7 v2 systems?
Yes. An integration layer or interface engine can transform HL7 v2 messages into FHIR resources when the required mappings and workflows are defined.
4. Is FHIR the same as HL7 v2?
No. Both are HL7 standards, but they use different technical approaches. HL7 v2 commonly uses message-based exchange, while FHIR provides resource-based models and modern API interactions.
5. Can FHIR support mobile healthcare applications?
Yes. FHIR APIs can provide standardized access to authorized healthcare information for supported applications.
6. Does FHIR solve healthcare interoperability by itself?
No. Successful interoperability also requires implementation guides, terminology, identity management, authorization, data quality, testing, and agreement between participating systems.
7. Can FHIR support AI healthcare applications?
FHIR can provide structured clinical data for AI and analytics workflows, but additional data quality, governance, terminology, provenance, and security controls are still required.
Top comments (0)