What is SMART on FHIR?

SMART on FHIR is an OAuth 2.0 profile layered on the FHIR API that defines how a health app authenticates and what patient data it may access. The app requests scopes such as patient/Observation.read, the user signs in to the EHR and approves them, and the app receives a short-lived access token that it refreshes through the OAuth 2.0 refresh flow. AppMatic Tech implements this flow in every EHR-connected mobile app.

Does every EHR expose a FHIR R4 API?

In the US, certified EHR systems including Epic, Oracle Health (Cerner), Meditech, and Athenahealth must expose FHIR R4 APIs under the 21st Century Cures Act. The resource types available and the level of write access vary by EHR and by each organisation's configuration, so AppMatic Tech reviews the EHR capability statement at GET [base]/metadata before any integration begins.

Can a mobile app write data back to an EHR over FHIR?

Yes, where the EHR grants write scopes such as patient/Observation.write, which remote patient monitoring apps use to push device readings into the clinical record. AppMatic Tech sends the resource's current version ID in the If-Match header on every write, so a concurrent update returns HTTP 409 Conflict instead of being silently overwritten.

Is FHIR integration possible without direct EHR access?

Yes. Health information exchanges and patient data aggregation platforms such as CommonWell, Carequality, and Apple Health Records expose FHIR APIs that aggregate data from multiple EHR sources. A mobile app can integrate with these aggregators to access a patient's records across providers without building an individual integration for each EHR.

How does AppMatic Tech handle FHIR in markets outside the US?

For Indian and Middle Eastern clients, AppMatic Tech designs the data layer to be FHIR-compatible by default, using FHIR resource schemas for internal data models even when the client's EHR does not yet expose a FHIR API. India's Ayushman Bharat Digital Mission already references FHIR, so this positions the app for integration as regulatory adoption grows.

FHIR API Integration for Mobile Health Apps: What Developers Building for US and International Healthcare Need to Know

Author: Vishal Sharma
Category: Healthcare
Published: February 15, 2026

AppMatic Tech integrates HL7 FHIR R4 APIs into iOS and Android health apps, implementing SMART on FHIR OAuth 2.0 authorisation, scoped resource access, pagination, version-safe writes, and offline caching against Epic, Oracle Health, and other certified EHRs. AppMatic Tech is based in Ahmedabad, India, and has shipped healthcare apps among 330+ products since 2017.

What is FHIR, and why does a mobile health app need it?

HL7 FHIR (Fast Healthcare Interoperability Resources) is the data standard that defines how healthcare information is structured, queried, and exchanged between systems. A hospital's EHR (Electronic Health Record) system, a patient-facing mobile app, a clinical analytics platform, and a telehealth service can all exchange patient data if each system speaks FHIR.

For developers building mobile health applications that need to read or write patient data, including appointments, lab results, medication lists, and clinical observations, FHIR is the integration layer. Understanding how FHIR works at the API level is not optional; it is the prerequisite for building a healthcare app that can connect to clinical systems.

AppMatic Tech builds FHIR-integrated mobile and web health applications for clients in India, the US market, and the Middle East. This article documents what the integration involves at the technical level.

Which FHIR version should a health app build against?

FHIR R4 (Release 4, published 2019) is the version mandated for certified EHR systems in the United States under the 21st Century Cures Act and the ONC's Interoperability Rule. US healthcare app developers building against Epic, Cerner (Oracle Health), Meditech, or Athenahealth are building against FHIR R4 endpoints.

FHIR R5 exists (published 2023) and adds capability improvements, but R4 remains the deployed standard in most clinical systems as of 2026. Building against R5-only capabilities risks compatibility issues with production EHR installations.

For international markets (India, Middle East, UK, EU), FHIR adoption is growing but regulatory mandates vary by jurisdiction. India's Ayushman Bharat Digital Mission (ABDM) references FHIR as its interoperability standard. The UK NHS uses FHIR UK Core. The EU European Health Data Space initiative is aligned with FHIR. The practical implication: building a FHIR-compatible data layer from the start positions a healthcare app for regulatory alignment in most markets.

Which FHIR resources does a mobile health app use?

FHIR organises healthcare data into Resources, self-contained JSON objects that represent a specific type of clinical entity. Each resource has a defined schema and can be read, written, searched, and updated via RESTful HTTP endpoints.

The resources most relevant to mobile health applications:

Patient: Demographics, contact information, identifiers. The anchor resource for all other clinical data.
Observation: Clinical measurements including vital signs (heart rate, blood pressure, oxygen saturation), lab results, and assessment scores. The most query-intensive resource in most health apps.
Condition: Diagnoses and clinical conditions. Used in care management and chronic disease apps.
MedicationRequest: Prescribed medications with dosage instructions. Used in medication management and adherence apps.
Appointment: Scheduled clinical encounters. Used in patient-facing scheduling apps.
DiagnosticReport: Structured lab or imaging reports, often referencing Observation resources for individual result values.
DocumentReference: Unstructured clinical documents (PDFs, scanned records) referenced by a FHIR metadata record.
Practitioner / PractitionerRole: Clinician identity and role. Used when the mobile app needs to display or select care team members.

A mobile health app that displays a patient's medication list, recent lab results, and upcoming appointments needs read access to MedicationRequest, Observation, DiagnosticReport, and Appointment resources for the authenticated patient.

How does SMART on FHIR authentication work in a mobile app?

The FHIR API standard specifies what data looks like and how to query it. SMART on FHIR specifies how a mobile app authenticates and what data it is authorised to access.

SMART on FHIR is an OAuth 2.0 profile layered on top of FHIR. The authentication flow for a patient-facing mobile app works as follows:

The mobile app initiates an authorisation request to the EHR's SMART authorisation server, specifying the requested FHIR scopes (e.g., patient/Observation.read, patient/MedicationRequest.read).
The user authenticates with the EHR (hospital portal credentials or equivalent).
The user reviews and approves the requested data access scopes.
The authorisation server returns an access token to the mobile app.
The mobile app uses the access token as a Bearer token in subsequent FHIR API requests.

Access tokens are scoped and short-lived. The mobile app must handle token refresh using the OAuth 2.0 refresh token flow, or re-authenticate when the token expires.

FHIR Scopes and What They Control

FHIR scopes in the SMART model are structured as [patient|user|system]/[ResourceType].[read|write|*]:

patient/Observation.read: read access to Observation resources for the authenticated patient
patient/MedicationRequest.read: read access to the patient's medication records
patient/*.read: read access to all FHIR resources for the patient (broad, some EHRs restrict this)
user/Patient.read: clinician-facing scope for reading patient demographics

Write scopes (patient/Observation.write) enable the mobile app to push data back into the EHR. This is relevant for remote patient monitoring apps that need to push device-captured readings (blood pressure, glucose, pulse ox) into the clinical record.

How does a mobile app call a FHIR API?

FHIR API calls follow standard REST patterns with FHIR-specific conventions:

Read a specific resource:

GET [base]/Patient/[id]
Authorization: Bearer [access_token]

Search Observations for a patient:

GET [base]/Observation?patient=[patient_id]&category=vital-signs&date=ge2026-01-01
Authorization: Bearer [access_token]

Search active medications:

GET [base]/MedicationRequest?patient=[patient_id]&status=active
Authorization: Bearer [access_token]

Responses are JSON bundles containing matching resources. Each resource in a bundle includes the resource type, ID, metadata (version, last updated), and the clinical content in the FHIR schema.

What breaks in production FHIR integrations?

Pagination

FHIR search results are paginated via Bundle.link entries. The server returns a page of results and a next link for the subsequent page. Mobile clients must handle pagination for Observation queries (a patient may have thousands of vital sign readings) and must implement cursor-based pagination rather than loading all results at once.

Versioning and Conflict Handling

FHIR resources include a version ID (meta.versionId) and last-updated timestamp (meta.lastUpdated). When writing back to the EHR, the app must include the current version ID in the If-Match header to prevent overwriting concurrent updates. EHRs return HTTP 409 (Conflict) when a write is rejected due to a version mismatch.

Offline Capability

Mobile health apps used in clinical settings cannot assume reliable network connectivity. AppMatic Tech implements local FHIR resource caching with a defined staleness policy: resources are cached on device and served from cache when the network is unavailable, with background refresh when connectivity is restored. The cache invalidation policy is resource-type specific; Observation data may have a shorter TTL than Practitioner records.

How does AppMatic Tech deliver FHIR integrations?

AppMatic Tech builds FHIR-integrated mobile health applications for clinical platforms, remote monitoring services, and patient engagement tools. For clinical deployment examples, see how AppMatic Tech built the Capmedic asthma controller app for deployment at Northwestern Medicine, the Anvahi platform with a practitioner-validated AI transcription pipeline, and the Homecare2go home-healthcare platform. For related healthcare engineering, read remote patient monitoring app architecture and native vs cross-platform mobile development. Contact the team at contact@appmatictech.com to discuss the data integration requirements of a healthcare app project.

Related healthcare guides from AppMatic Tech: telemedicine app development, HIPAA-compliant app architecture, and medication adherence app development.

Frequently Asked Questions

What is SMART on FHIR?: SMART on FHIR is an OAuth 2.0 profile layered on the FHIR API that defines how a health app authenticates and what patient data it may access. The app requests scopes such as patient/Observation.read, the user signs in to the EHR and approves them, and the app receives a short-lived access token that it refreshes through the OAuth 2.0 refresh flow. AppMatic Tech implements this flow in every EHR-connected mobile app.
Does every EHR expose a FHIR R4 API?: In the US, certified EHR systems including Epic, Oracle Health (Cerner), Meditech, and Athenahealth must expose FHIR R4 APIs under the 21st Century Cures Act. The resource types available and the level of write access vary by EHR and by each organisation's configuration, so AppMatic Tech reviews the EHR capability statement at GET [base]/metadata before any integration begins.
Can a mobile app write data back to an EHR over FHIR?: Yes, where the EHR grants write scopes such as patient/Observation.write, which remote patient monitoring apps use to push device readings into the clinical record. AppMatic Tech sends the resource's current version ID in the If-Match header on every write, so a concurrent update returns HTTP 409 Conflict instead of being silently overwritten.
Is FHIR integration possible without direct EHR access?: Yes. Health information exchanges and patient data aggregation platforms such as CommonWell, Carequality, and Apple Health Records expose FHIR APIs that aggregate data from multiple EHR sources. A mobile app can integrate with these aggregators to access a patient's records across providers without building an individual integration for each EHR.
How does AppMatic Tech handle FHIR in markets outside the US?: For Indian and Middle Eastern clients, AppMatic Tech designs the data layer to be FHIR-compatible by default, using FHIR resource schemas for internal data models even when the client's EHR does not yet expose a FHIR API. India's Ayushman Bharat Digital Mission already references FHIR, so this positions the app for integration as regulatory adoption grows.