EHR / EMR integration
Primary use case: bidirectional data flow between your app and the EHR of record.
FHIR Integration
FHIR
FHIR integration across R4, R5, and R6 (US Core profiles, SMART on FHIR launch, and Bulk FHIR $export) connecting your product to Epic, Oracle Health (Cerner), athenahealth, and modern health systems with HIPAA-ready, correctly-scoped pipelines.
FHIR R4 / R5 / R6US Core ProfilesSMART on FHIRBulk FHIR
Trusted by global innovators
What is FHIR integration?
FHIR integration is connecting your software to an EHR, payer or app through HL7 FHIR REST APIs, so patients, encounters, results and medications move as structured resources. Agnotic Technologies builds these integrations against FHIR R4 and US Core, with SMART on FHIR authorization and Bulk FHIR export where you need population data.
The real work is conformance, not calls. US Core profiles, terminology binding (SNOMED CT, LOINC, ICD-10, RxNorm) and per-system coverage gaps decide what is buildable.
We read each target system's capability statement first to confirm its FHIR capabilities, then build read, write and Bulk FHIR flows that reach production, not only a sandbox.
What FHIR is
A REST API standard for health data
FHIR (Fast Healthcare Interoperability Resources) is HL7's modern standard for how health data is structured, shared, and accessed across systems via RESTful APIs. It replaces (or augments) bulk message-based approaches with real-time, resource-oriented endpoints.
FHIR supports JSON, XML, and HTTP. It models clinical data as Resources (Patient, Observation, MedicationRequest, etc.), supports events, documents, and APIs, and enables developers to build mobile and cloud apps against any compliant system.
How a FHIR integration fits together
A blueprint for connecting your platform over FHIR: REST resource access, SMART on FHIR launch, HL7 v2 compatibility, and the auth, terminology, and monitoring layers production needs.
FHIR APIs and standards we work with
We name the exact FHIR surface and version up front, because that determines what's buildable, and by when.
FHIR R4, R5 & R6 resources
Read and write against FHIR R4 (today's production target), with R5 support where systems expose it and an R6-aware migration path: Patient, Encounter, Observation, MedicationRequest, DocumentReference, and more.
US Core & implementation profiles
Conformance to US Core profiles and USCDI data classes, plus custom implementation-guide profiles and extensions, so data validates against the constraints regulators and partners expect.
SMART on FHIR launch + scopes
EHR and standalone SMART on FHIR launch with scoped OAuth2 (patient/*, user/*, system/*) for apps that call FHIR endpoints inside the chart.
Bulk FHIR $export
Population-level extraction via the Bulk FHIR $export operation for analytics, quality measures, and research pipelines.
HL7 v2 ↔ FHIR transformation
Bidirectional HL7 v2 ↔ FHIR mapping for hybrid deployments where legacy feeds and modern APIs have to coexist.
Terminology & observability
SNOMED CT, LOINC, ICD-10, and RxNorm resolution, plus interface health dashboards and failed-call alerting so a throttled or malformed FHIR request is caught before it becomes a clinical gap.
Where it runs
Where is FHIR integration used?
Mobile health apps
SMART-on-FHIR patient apps with authenticated access to clinical data.
Cloud platforms
FHIR-native cloud deployments on Azure, AWS, and GCP health platforms.
Telehealth systems
FHIR-integrated telehealth with real clinical context during visits.
Healthcare analytics
FHIR bulk export as source for analytics and research.
Third-party APIs
Integration with payer, lab, and specialty APIs via FHIR.
Readiness checklist
How do you run a FHIR integration readiness assessment?
A FHIR integration readiness assessment checks, before any code is written, that the target servers, access path, data and owners are in place. Open items become scope drivers or risks on the scoping call; the go-live test plan further down covers what follows the build.
- Target servers named: each EHR, payer or partner, its FHIR version and its sandbox and production base URLs
- CapabilityStatement read for every server, with each resource, interaction and search parameter you need marked present or missing
- Implementation guides agreed: the US Core version, plus any payer or specialty guide your partner expects
- Access path chosen: SMART EHR launch, standalone launch or backend services, with the narrowest scopes for each
- Developer program and app review steps known for each vendor, and a sponsor at the customer who approves production access
- Data mapped: your fields against FHIR elements, and the codes (LOINC, SNOMED CT, RxNorm) that need translation
- Read only or write back decided, and for writes, who reviews the data before it reaches the chart
- Volume estimated: patients, calls per day and any population export that needs Bulk Data
- Agreements in place: the BAA, the customer's API terms and any limits on how the data may be used
- Owners named for after launch: monitoring, vendor upgrades and support for each connected site
Architecture options
Which FHIR architecture fits your system?
We pick based on where data lives, message volume, and whether event-driven flows matter.
RESTful API-based integration
- Direct calls to EHR FHIR endpoints
- Simplest architecture, real-time access
- Best for single-EHR read-heavy workloads
Middleware-based integration
- FHIR gateway between your app and EHR
- Supports HL7 ↔ FHIR transformation
- Best for multi-EHR or legacy-mixed deployments
Event-driven architecture
- Subscribe to FHIR events and react
- Enables near-real-time downstream workflows
- Best for clinical decision support and RPM-style flows
FHIR first, HL7 v2 where needed
FHIR is the modern standard for health data exchange. We build for how Epic, Oracle Health (Cerner) and other EHRs expose it in production.
US Core
Profiles we validate against
R4
Target FHIR version for new builds
BAA
Signed before any PHI is shared
Compliance-First Healthcare App Development Services Backed by Global Standards
15-Minute Scoping Call01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Go-live test plan
What should a FHIR implementation checklist verify before go-live?
Before a FHIR go-live, verify that each production server supports every call your app makes, that your data validates against US Core, and that tokens, paging, errors and writes behave under real conditions. Each row gives the test and what counts as a pass.
| Check | How to test it | Pass criterion |
|---|---|---|
| CapabilityStatement against the app's calls | Fetch /metadata from each production server and diff it against every resource, interaction, search parameter and operation the app sends, taken from the code or from recorded sandbox traffic | Every call is declared by the server; anything missing has a fallback or is switched off for that site |
| US Core validation | Run the HL7 FHIR Validator on the resources the app writes and on a sample of what it reads; run the Inferno US Core tests against the server where you have access | No errors on written resources; each warning fixed or accepted in writing |
| Token lifetime and refresh | Let an access token expire mid-session, refresh it, revoke the grant at the server, then repeat with an expired refresh token | The app refreshes without user action, sends the user back to authorize when refresh fails, and never retries with a dead token |
| Search paging | Search a test patient with more results than one page, such as a long Observation history, and follow the Bundle next links to the end | The record count matches the source, and the app follows the server's next links rather than building page URLs itself |
| Errors and rate limits | Send invalid requests and read the OperationOutcome, then throttle calls until the server returns HTTP 429 and check for a Retry-After header | Errors are logged with the OperationOutcome issue code, 429 responses wait for Retry-After or back off, and no request loops |
| Duplicate-safe writes | Confirm the server declares conditional create, then post the same resource twice with If-None-Exist on its business identifier, including after a forced network retry | One resource exists afterwards; the repeat does not create a second |
| Provenance on writes | Write a resource with its Provenance (agent, time and source system) and read both back as the receiving organization would | Every written resource can be traced to the person or system that created it |
| Per-site configuration | Repeat the CapabilityStatement diff, scope check and a smoke test at each production site, because each one can run a different version and configuration | A signed-off record per site of base URL, client ID, enabled APIs and known differences |
| Monitoring thresholds | Agree alert thresholds for error rate, latency, token failures and empty results, then trigger each alert in a test environment | Every alert reaches a named owner, with a runbook entry for each |
Generic launch items such as keeping PHI out of logs, a sponsor at the customer and ownership after launch apply to every FHIR project. Our Epic integration checklist, linked below, covers them step by step.
Standards we build against
Which standards does FHIR work follow?
FHIRHL7HIPAAHITECHSMART
Our Process
How do we ship a FHIR integration?
Capability assessment, mapping, and access run as parallel tracks so the integration reaches a real system on a plan you can track.
1.
Discovery & Scope
We read the target system's FHIR capability statement, confirm the version (R4/R5), the US Core profiles in play, and the resources and scopes you need before any code is written.
Capability-first
2.
Sandbox & App Registration
We provision sandbox credentials, register the SMART app, and validate OAuth2 launch and scope approval against the vendor's test data.
Sandbox-gated
3.
Build & Test
We build the FHIR read/write flows, US Core-conformant mapping, HL7 v2 transformation where needed, and Bulk FHIR export, validating against synthetic and partner-assisted data.
Conformance-tested
4.
Go-Live & Monitoring
Phased production rollout with interface health dashboards, failed-call alerting, and version-compatibility monitoring as the ecosystem moves toward R5/R6.
Observable in production
FHIR vs HL7
How does FHIR differ from HL7 v2?
FHIR builds on earlier HL7 standards but is fundamentally different in architecture. Here's when each fits.
| Dimension | HL7 v2 | FHIR R4 |
|---|---|---|
| Architecture | Message-based feeds | RESTful APIs |
| Data format | Pipe-delimited text | JSON, XML |
| Access pattern | Bulk / event-driven messages | On-demand resource access |
| Implementation effort | Mature tooling, rigid format | Easier to implement and scale |
| Fit | Legacy EHR, clinical events | Mobile, cloud, modern apps |
| Our default | Support where required | Target for new builds |
Most modern builds run FHIR-first with HL7 v2 as a compatibility surface for legacy systems.
Facts and sources
Which rules shape FHIR work?
Short facts we design around, each linked to its primary source.
US Core is the HL7 FHIR implementation guide that profiles FHIR resources for the USCDI data classes used in the United States.
Source: HL7 International (US Core)The SMART App Launch implementation guide uses OAuth 2.0 and OpenID Connect so that apps can launch from an EHR with the user's and patient's context and only the access scopes they were granted.
Source: HL7 International (SMART App Launch)ONC certification criterion 170.315(g)(10) requires certified EHRs to offer a standardized API for patient and population services based on HL7 FHIR.
Source: 45 CFR 170.315 (eCFR)In FHIR R4, a conditional create sends an If-None-Exist header with search parameters: the server creates the resource if nothing matches, returns 200 OK without creating it if one resource matches, and returns 412 Precondition Failed if several match.
Source: HL7 FHIR R4, RESTful API (conditional create)
Featured case study
Read Case StudyLera Health: compliant health platform
Related proof of standards-based delivery: for Lera Health we built a privacy-first data layer and testing-to-insights workflow end to end, modeling clinical data in a standards-aligned way: the same discipline a production FHIR integration demands.
Frequently Asked Questions
Then that part of the use case needs another route: a resource the server does support, an HL7 v2 or C-CDA feed, or a request to the vendor or health system to switch the API on. We record each gap during the readiness assessment, so it is a scoping decision rather than a surprise in testing.
The readiness assessment happens before the build and checks that servers, access, data and owners are in place. Go-live testing happens after the build and proves the integration behaves against each production server, from token refresh and paging to error handling and duplicate-safe writes.
Yes. Agnotic signs a business associate agreement before any PHI is shared, and we use synthetic or de-identified data in development and test environments.
Yes. We connect FHIR APIs to your app, data platform or legacy HL7 v2 feeds, and translate between them where both must run side by side.
Yes. A common first scope is read access to one EHR for a few US Core resources through SMART on FHIR, then write access or more systems once it is live.
AI tools help our engineers draft code and tests, but a person reviews every change, and it passes the same automated tests and security checks as any other code. Which tools may see your code or data is agreed with you at the start, and FHIR mapping logic is still checked against validators and the target system's sandbox.
It depends on the target system's FHIR coverage, the resources and profiles in scope, and vendor app review. We assess the capability statement first, then give you a dated plan, so the timeline does not change mid-build.
Cost depends on the number of systems, resources and profiles, and whether SMART launch, write access and Bulk FHIR are in scope. We scope against your target systems and share a fixed estimate after a discovery call.
Usually, for production. Most EHRs require you to register in their developer program, such as Epic's open.epic or the Oracle Health (Cerner) developer program, and pass app review before production or write access. We plan those approvals into the timeline from the start.
Yes. We map device and wearable streams and telehealth encounters into FHIR Observations and Encounters, so RPM and virtual-care data lands in the same standards-based record as the rest of your clinical data.
R4 is what most EHRs run in production and what US Core targets, so it is our default. We support R5 where a system exposes it and keep the mapping layer separate, so a later move to R6 does not mean a rewrite.
Ready to connect your systems with FHIR?
Tell us your target EHRs and resource needs, and we'll return a scoped FHIR integration plan.
contact@agnotic.com
Partnerships
contact@agnotic.com