Three standards.
Different jobs.
FHIR describes healthcare data and how to exchange it. SMART adds a way for apps to obtain authorized access and launch with context. CDS Hooks lets clinical workflows call decision-support services.
FHIR: the data and the API
FHIR stands for Fast Healthcare Interoperability Resources. It models information using resources such as Patient, Encounter, Observation, and MedicationRequest. A FHIR server can expose supported interactions through an HTTP API; its capability statement describes what it offers.
FHIR is a family of specifications. Version, profiles, supported resources, search parameters, and organizational implementation choices matter. A working integration checks those capabilities rather than assuming every FHIR endpoint behaves identically.
SMART Flint is not a clinical data repository or a general-purpose FHIR server. Its optional gateway mediates supported JSON reads and searches against the upstream server. Read HL7’s FHIR overview ↗
SMART on FHIR: permission and launch context
SMART App Launch builds on OAuth 2.0 and OpenID Connect to help applications obtain authorized FHIR access. An EHR can launch an app with an issuer and launch identifier; a standalone app starts the authorization process outside an EHR launch. The resulting grant can include patient or encounter context where supported and authorized.
Client registration, exact redirect URLs, requested scopes, PKCE, discovery metadata, and safe credential handling all belong to this integration work. SMART Flint orchestrates that lifecycle and exposes an activation session for your app. Its gateway, direct, and handoff modes determine how the app obtains FHIR access and who owns credential renewal.
Read the SMART App Launch specification ↗ · Try a synthetic SMART launch →
SMART Backend Services: access without an interactive user
A backend service can use a preauthorized system-to-system workflow instead of an interactive browser launch. SMART Backend Services uses asymmetric client authentication. Real deployments still require registration, approved scopes, key publication, and organization-specific authorization.
SMART Flint supports backend service access using application-specific API credentials and configured upstream client profiles. Its optional Python SDK is useful for service-side integrations. Follow the backend services guide →
CDS Hooks: call a service at a workflow moment
CDS Hooks defines calls from a clinical workflow to a decision-support service at a named hook, carrying hook context and optionally prefetched FHIR data. The service can return cards and related response content defined by the specification.
SMART Flint forwards authenticated synchronous requests to configured handlers with context and prefetch bound to that request. It does not supply a validated clinical model or establish that a handler is safe for clinical decision-making. The included Health Compass handler is an educational example.
Read the CDS Hooks specification ↗ · Configure a handler →
How the pieces fit
- Register your application and the organization’s FHIR connection.
- Launch or acquire a backend grant using the supported authorization workflow.
- Receive authorized context and obtain a FHIR connection through your chosen access mode.
- Use your preferred FHIR HTTP client for the permitted resource interactions.
- Where applicable, configure a CDS Hooks handler and an authorized caller separately.
FHIR support, SMART support, and CDS Hooks support are distinct capabilities. A successful metadata check does not demonstrate every requested interaction. Real environments require vendor and customer validation.