SMART on FHIR and the data trust surface area for third-party app access

SMART on FHIR opens a door. It does not verify what is behind it.

The protocol has become the standard mechanism for third-party health app access to EHR data, mandated by the 21st Century Cures Act and enforced through ONC certification requirements. Over 600 apps are now registered across major EHR platforms using SMART on FHIR authorization. But the entire framework is built on an assumption that the data behind the API is trustworthy, consistent, and appropriately consented for the use the app intends.

That assumption is wrong more often than most health systems realize.

What SMART on FHIR actually is (and what the acronym stands for)

SMART stands for Substitutable Medical Applications, Reusable Technologies. The acronym was coined by researchers at Boston Children's Hospital and Harvard Medical School as part of a 2010 ONC-funded project. The goal was to create a standard way for third-party applications to launch within an EHR context, authenticate users, and request access to specific FHIR resources.

The "on FHIR" part refers to HL7's Fast Healthcare Interoperability Resources standard, which defines how clinical data elements like Patient, Observation, MedicationRequest, and Condition are structured and exchanged via RESTful APIs.

SMART on FHIR combines OAuth 2.0 authorization with FHIR resource scopes. An app requests access to specific resource types (patient/Observation.read, for example), the user or administrator approves the scope, and the app receives a token that grants access to the permitted data.

This is a solved problem for authorization. It is not a solved problem for trust.

What "smart" means outside the acronym (and why the SERP is confused)

People searching for "SMART" often encounter a collision of meanings. The word itself derives from Old English "smeart," meaning causing sharp pain, and evolved over centuries to describe quickness of mind. A synonym for smart in the cognitive sense includes astute, sharp, or perceptive.

In goal-setting frameworks, SMART stands for Specific, Measurable, Achievable, Relevant, and Time-bound. In automotive contexts, Smart is a brand of microcar. In telecommunications, Smart is a major Philippine carrier.

None of these meanings overlap with SMART on FHIR. The healthcare interoperability meaning is the only one that matters for data trust, and it is the one that current search results explain least well.

The authorization layer is not the trust layer

SMART on FHIR trust surface area: what the protocol covers vs what it misses

SMART on FHIR governs who can access data and what resource types they can read. It does not govern:

Whether the data behind the scope is accurate

Whether the data was collected under consent that covers the app's intended use

Whether the data has been validated against a primary source

Whether the data is recent enough to be clinically meaningful

Whether the data has been transformed, inferred, or imputed before reaching the API

This is the data trust surface area. Every SMART on FHIR app that reads patient data inherits whatever quality and consent problems exist in the source system. The OAuth token does not filter for provenance. The FHIR scope does not check for recency. The launch context does not verify concordance.

Key statistics

Data Trust Index (DTI) dimension weights

The gap between authorization and trust is measurable:

Over 600 third-party apps now access EHR data via SMART on FHIR across Epic, Cerner, and other certified EHR platforms

The 21st Century Cures Act requires certified EHRs to support SMART on FHIR for patient-facing apps, covering an estimated 200+ million patient records in the US

SuperTruth's DTI Engine scores records across 8 dimensions with weighted distribution: Provenance (25%), Consent (20%), Recency (15%), Quality (10%), Concordance (10%), Validation (10%), Breadth (5%), Stability (5%)

In the imaware case study, 105,000 diagnostic records were standardized with a 95% time reduction (from 3 weeks to 2 hours per cycle), saving 200+ hours per month

A 2023 ONC report found that 88% of non-federal acute care hospitals had adopted certified EHR technology, but fewer than 15% had implemented any form of data quality scoring on their API-exposed resources

The consent problem SMART on FHIR does not solve

SMART on FHIR uses OAuth scopes to define data access boundaries. A patient-facing app might request patient/Condition.read and patient/Observation.read. The patient clicks "Allow" on a consent screen.

But that consent screen describes access, not use. The patient authorizes the app to read their conditions and observations. The consent screen says nothing about whether the app will:

Use the data for AI model training

Share the data with third-party analytics providers

Retain the data after the session ends

Combine the data with non-clinical data sources

Apply the data to a purpose beyond the stated app function

This is the consent layering problem. The original clinical consent that governed the data's collection at the point of care may not extend to the third-party app's actual use case. The SMART on FHIR authorization screen adds a second consent layer, but it rarely interrogates the first.

SuperTruth's ConsentOS addresses this through a five-tier consent architecture that tracks consent state from collection through every downstream use, including third-party API access.

What happens to data quality at the API boundary

When a SMART on FHIR app requests a Patient resource, it receives a JSON object with fields like name, birthDate, address, and identifiers. When it requests Observation resources, it gets lab results, vital signs, and other measurements.

The app trusts that these fields are populated, accurate, and current. But the FHIR specification does not require quality metadata. A Condition resource does not carry a confidence score. An Observation resource does not indicate whether the value was manually entered, device-captured, or imputed from a billing code.

Consider what a third-party app might receive through a SMART on FHIR connection:

A blood pressure reading from 2019 listed as the most recent Observation because no subsequent reading was recorded

A Condition resource for "Type 2 Diabetes" that was coded from a billing claim rather than a clinical diagnosis

An AllergyIntolerance resource that was copied from a prior system during migration and never re-verified

A MedicationRequest that was discontinued but not end-dated in the source system

Every one of these is a valid FHIR resource. Every one of them would pass a SMART on FHIR authorization check. And every one of them is a trust failure that the app consuming the data has no way to detect.

The third-party health app trust gap

The market for SMART on FHIR apps spans patient-facing wellness tools, clinical decision support systems, population health dashboards, research data aggregators, and payer analytics platforms. Each category carries different data quality requirements.

A wellness app that displays lab results to patients needs accurate values and understandable reference ranges. A clinical decision support tool needs validated, current data with confirmed provenance. A research platform needs consent coverage that extends to secondary use.

SMART on FHIR treats all of these the same. The OAuth scope is identical. The FHIR resources are identical. The trust requirements are radically different, but nothing in the protocol distinguishes them.

This is why FHIR app authorization data quality matters. The authorization framework is resource-level. The trust requirement is use-level. That mismatch creates a surface area that grows with every new app registration.

How FHIR version differences compound the problem

FHIR R4 is the current baseline for US regulatory compliance. FHIR R5 introduced several improvements relevant to data trust, including better provenance tracking and more granular consent resources.

But the transition between versions creates its own trust problem. A SMART on FHIR app built against R4 may receive resources that were generated by a system still internally running on older data models. The FHIR facade presented by the EHR's API might translate internal data structures into compliant FHIR resources, but that translation can introduce mapping errors, drop metadata, or default missing values.

For a deeper analysis of how version changes affect trust architecture, see FHIR R4 vs FHIR R5: what the version change means for data trust architecture.

Provenance: the missing dimension in SMART on FHIR

FHIR defines a Provenance resource type. In theory, every clinical resource could carry a linked Provenance resource that describes who created it, when, from what source, and through what process.

In practice, almost no one populates it.

EHR vendors expose FHIR APIs to meet certification requirements. They populate the required US Core profiles. But the Provenance resource is not required for most resource types under current US Core implementation guides. So a SMART on FHIR app that requests Observation resources gets lab values without provenance. It gets data without a chain of custody.

This is why SuperTruth weights Provenance at 25% in the Data Trust Index. It is the single most important dimension for determining whether a data element can be trusted for downstream use, and it is the dimension most consistently absent from FHIR API responses.

The real surface area: what health systems expose without knowing

When a health system enables SMART on FHIR access, it exposes a trust surface area that includes:

Data quality variations across departments. Radiology data quality may be high because of DICOM standards. Free-text nursing notes converted to Observation resources may be low.

Consent state inconsistencies. A patient may have consented to clinical care but not to third-party app access for research purposes. The SMART on FHIR authorization does not check the original consent scope.

Temporal gaps. Data exposed through the API may include resources from 10 years ago alongside resources from yesterday, with no recency indicator that helps the consuming app distinguish them.

Mapping artifacts. ICD-10 codes mapped to SNOMED CT concepts for FHIR compliance may introduce semantic drift. A billing code for "chest pain, unspecified" becomes a Condition resource that a clinical app treats as a confirmed diagnosis.

The surface area is not the API. The surface area is the entire data quality and consent landscape of the health system, now accessible to every authorized app.

What trust scoring at the API boundary looks like

The fix is not to restrict SMART on FHIR access. The 21st Century Cures Act explicitly prohibits information blocking, and restricting API access to improve data quality would likely violate ONC rules.

The fix is to score the data before it crosses the API boundary.

SuperTruth's DTI Engine can sit at the integration layer between the EHR's FHIR server and the third-party app. Every resource that passes through the API receives a trust score across 8 dimensions. The consuming app receives both the FHIR resource and its DTI score, allowing it to make informed decisions about how to use each data element.

A clinical decision support app could set a DTI floor of 70 for any Observation it incorporates into an alert. A research platform could require Consent dimension scores above 80 for any data used in secondary analysis. A patient-facing app could flag low-provenance resources with a confidence indicator.

This turns SMART on FHIR from an authorization protocol into a trust-aware data exchange framework.

Why this matters for FHIR app authorization data quality

The ONC has signaled increasing focus on data quality in its interoperability roadmap. CMS has tied data quality requirements to payment programs. The FDA has published guidance on data provenance for AI/ML models used in clinical settings.

All of these regulatory vectors converge on SMART on FHIR, because it is the primary mechanism through which third-party apps access clinical data. If the data flowing through SMART on FHIR connections lacks quality, provenance, and consent integrity, then every downstream use of that data inherits those deficiencies.

The question is not whether third-party apps should have access to EHR data. That question was answered by the Cures Act. The question is whether anyone is measuring the trustworthiness of what those apps receive.

Right now, for the vast majority of health systems, the answer is no.

What health systems should do now

Three steps separate a SMART on FHIR implementation from a trust-aware one:

Audit your exposed resources. Identify which FHIR resource types are accessible through your SMART on FHIR APIs and assess the quality, provenance, and consent coverage of each.

Implement trust scoring at the API layer. Score every outbound resource before it reaches a third-party app. Use the score to inform, not block, data exchange.

Require DTI floor enforcement in app registration. When registering new SMART on FHIR apps, define minimum trust score requirements based on the app's intended use case.

These steps do not violate information blocking rules. They add metadata to exchanged data, improving its utility without restricting access.

The DTI Engine scores every health data record 0 to 100 across 8 trust dimensions before your AI model sees it. If your team is evaluating SMART on FHIR data for app development, clinical use, or regulatory compliance, contact Louis Simeonidis at louis@supertruth.ai or (215) 918-4140.

Further reading:

DTI™ Engine

Health systems solution

The consent layering problem: when downstream data use exceeds original consent

FHIR R4 vs FHIR R5: what the version change means for data trust architecture

Information blocking rules and data trust: what the ONC final rule means for AI