Integration leads
Health system teams adding apps and data feeds to the EHR.
FHIR and SMART on FHIR Development
FHIR and SMART on FHIR development
Every EHR exposes FHIR a little differently, and an app that works in one sandbox can fail at the next site. Agnotic Technologies builds FHIR APIs, FHIR servers and SMART on FHIR apps, tested against Epic and Oracle Health sandboxes before they reach a clinician.
HL7 FHIR R4SMART on FHIRUS CoreCDS Hooks
Trusted by global innovators
What are FHIR development services?
FHIR development services are the engineering work of building software that exchanges health data through HL7 FHIR APIs: modeling resources and profiles, building or connecting FHIR servers, and creating SMART on FHIR apps that launch inside an EHR. Agnotic Technologies designs, builds and tests this work, with OAuth scopes and audit logging from the first release.
FHIR R4 is the version most EHRs and US regulations use today. Most projects combine three things: the FHIR data model, a server or API layer, and the apps that read and write through it.
What does a SMART on FHIR launch look like?
The app opens from the patient chart, receives the patient and user context, requests only the scopes it needs and reads and writes FHIR resources through the EHR's API.
Which FHIR resources and profiles do we model?
We model to published profiles first, so your data is exchangeable without custom mapping at every partner.
US Core profiles
Patient, Encounter, Condition, Observation, MedicationRequest and the other US Core profiles that cover the USCDI data classes.
International Patient Summary (IPS)
Patient summaries for cross-border or multi-country products that follow the IPS implementation guide.
Custom profiles and extensions
Extensions and profiles only where published ones do not fit, documented in an implementation guide your partners can read.
Terminology
SNOMED CT, LOINC, RxNorm and ICD-10-CM bindings, with a terminology service for validation and lookup.
Bulk data
FHIR Bulk Data export for population health, analytics and data warehouse feeds.
FHIR facades over legacy systems
A FHIR API in front of an existing database or HL7 v2 feed, so new apps can use FHIR without replacing the old system.
Who it is for
Who builds FHIR and SMART on FHIR software with us?
Most of our FHIR work is for one of these teams.
Health tech CTOs
Product teams whose app has to launch inside Epic or Oracle Health.
Payer IT teams
Payers building the FHIR APIs CMS rules require.
Data teams
Analytics teams pulling FHIR bulk data into a warehouse.
Reference architecture
What does a FHIR integration architecture look like?
The layout we start from and adjust to your EHRs and hosting.
Apps
- SMART on FHIR app
- Patient app
- Partner integrations
Authorization
- OAuth 2.0 and OpenID Connect
- Scopes per app
- Launch context
FHIR layer
- EHR FHIR API or your FHIR server
- US Core profiles
- Terminology service
Sources
- Epic
- Oracle Health (Cerner)
- Legacy systems behind a FHIR facade
Security and audit
- Audit log of every API call
- Encryption in transit and at rest
- BAA with every host
Compliance-First Healthcare App Development Services Backed by Global Standards
01
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.
Compliance and security
What compliance and security requirements apply to FHIR work?
Each requirement is an engineering decision. Agnotic claims no certification; we build so your product can pass your partners' reviews.
| Requirement | Who sets it | What it means for the build |
|---|---|---|
| HIPAA Security Rule | HHS | Access control, audit logs and encryption for every FHIR call and stored resource |
| Standardized FHIR API for certified EHRs | ONC (ASTP) | Certified EHRs must offer a FHIR API under 170.315(g)(10), which apps can build on |
| FHIR, SMART and US Core specifications | HL7 International | Resources, launch and profiles built to the published specifications |
| Payer FHIR APIs | CMS | Patient Access, Provider Access and Payer-to-Payer APIs for payers under CMS interoperability rules |
| Vendor app programs | EHR vendors such as Epic | App registration, review and production approval before go-live |
SMART on FHIR
How do SMART on FHIR launch, scopes and CDS Hooks work?
These are the pieces that put your app inside the clinician's workflow.
1.
EHR launch
The clinician opens the app from the chart. The EHR passes a launch context with the patient, encounter and user.
From the chart2.
OAuth 2.0 scopes
The app requests only the scopes it needs, such as reading a patient's observations, and the EHR authorizes them.
Least access3.
FHIR API calls
The app reads and writes FHIR resources through the EHR's API, with every call logged.
Read and write4.
CDS Hooks
Where needed, the EHR calls your service at moments like opening a chart or signing an order, and shows your cards in its own screen.
In the workflowScope and effort
What drives the scope, timeline and cost of FHIR work?
We do not quote before we understand these.
Read or write
Writing data back to the EHR needs more approval and testing than reading it.
Number of EHRs and sites
Each EHR and each organization adds configuration, testing and go-live work.
Server or no server
Running your own FHIR server adds hosting, scaling and operations.
Profiles
Published profiles are faster than custom ones that partners must learn.
Vendor approval
App review and client sponsorship follow the vendor's and the client's calendar.
FHIR servers
Which FHIR server should you use: HAPI, a cloud FHIR store or a managed option?
Many products do not need their own FHIR server. When they do, these are the usual choices.
| Option | Choose it when | Watch out for |
|---|---|---|
| Open source (HAPI FHIR) | You need full control, custom operations or on-premises hosting | You run, scale, patch and back it up yourself |
| Cloud FHIR stores | You already run on AWS, Google Cloud or Azure and want a hosted store under your cloud BAA | Each cloud supports a different set of FHIR features and search parameters |
| Managed FHIR platforms | You want a hosted FHIR platform with extra tooling and do not want to run the server | Vendor lock-in, pricing at scale and data residency |
| No server: use the EHR's API | Your app only reads and writes data that lives in the EHR | Each EHR's API differs, and write access needs vendor approval |
We recommend the simplest option that meets your data, hosting and partner needs.
Facts and sources
Which rules and facts shape FHIR work?
Short facts we design around, each linked to its primary source.
HL7 FHIR is a standard published by HL7 International for exchanging health data through RESTful APIs built on defined resources such as Patient, Observation and MedicationRequest.
Source: HL7 International (hl7.org/fhir)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)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)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)
Frequently Asked Questions
FHIR R4 for most projects today, because it is what US regulations reference and what Epic, Oracle Health and most EHRs support in production. Newer versions are useful to track, but your partners' systems decide what you can use.
Yes. A SMART on FHIR app can launch from the Epic chart with patient and user context. It needs to be registered through Epic's developer program and activated by the organization that runs Epic, and we plan for both steps from the start.
Yes. A FHIR facade puts a FHIR API in front of an existing database or HL7 v2 feed, mapping it to standard resources, so new apps can use FHIR while the old system keeps running.
Not always. If your app only reads and writes data that lives in the EHR, the EHR's FHIR API is enough. You need a server when you store your own clinical data, combine data from several sources or serve partners.