On this page
Key takeaways
- FHIR R4 is the API standard certified US EHRs must support; US Core defines the minimum data they expose.
- Bulk FHIR export loads a whole population at once; SMART on FHIR lets an approved app open inside the EHR with the right user and patient.
- Referrals and orders usually appear as ServiceRequest, with Appointment, Encounter, Procedure and Observation showing what happened next.
- Scheduling, claims and HIE data often arrive through HL7 v2 and X12, not FHIR.
- What an app can see depends on approved scopes, what each EHR exposes and how the practice records its work.
Most practice leaders do not need to know how APIs work. They do need to know what a vendor is asking for, what their EHR administrator will be asked to approve, and what a connection can and cannot provide. This guide covers the standards you will hear about, FHIR R4, US Core, Bulk Data and SMART on FHIR, plus the older formats that still carry scheduling and claims. The specifications themselves are published by HL7 at hl7.org.
What is FHIR?
FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard for exchanging healthcare data through web APIs. Data is organized into resources such as Patient, Appointment, Encounter, Condition, ServiceRequest and Procedure. US federal certification rules require certified EHRs to provide standardized FHIR R4 APIs, which is why most major EHRs now offer them.
US Core is the set of FHIR profiles that defines the minimum data US EHRs expose. If a vendor says it uses US Core, it is relying on data your EHR is required to provide. Definitions of these terms are also in our glossary.
Which FHIR resources matter for referrals, orders and visits?
A handful of FHIR R4 resources carry most of the data needed to see whether planned care happened. How each EHR populates them varies.
| FHIR resource | What it represents | How it is used | Common caveat |
|---|---|---|---|
| ServiceRequest | Referrals and orders for procedures, tests and services | The trigger: care that was requested | Some referrals arrive as scanned documents, not structured requests |
| Appointment | Booked, canceled and missed appointments | Progress: whether the requested care is booked | Scheduling may live in a separate practice management system |
| Encounter | Visits that took place | Evidence that a referral or follow-up visit happened | The link from a visit to the referral it fulfilled is often implicit |
| Procedure | Procedures that were performed | Evidence that an ordered or recalled procedure happened | Outside procedures may appear only as documents |
| Observation | Results, measurements and findings | Evidence that a test was resulted | Availability and coding vary widely by EHR and result type |
Each resource carries a status, such as active or completed for a request, or booked or canceled for an appointment. Statuses reflect how staff use the EHR. An order left active after the procedure was done at another facility still looks open, which is why matching across resources matters more than any single status. The idea behind that matching is explained in expected vs. actual events in healthcare.
What is Bulk FHIR export?
The FHIR Bulk Data Access standard, often called $export, lets an approved application request data for a whole population in one asynchronous job. The EHR prepares files and the application downloads them. It is how a platform loads two years of history without making millions of individual calls. After the first load, smaller incremental requests keep data current.
What is SMART on FHIR?
SMART on FHIR combines FHIR data with the SMART App Launch standard, which defines how an app is launched, how it is authorized using OAuth 2.0 and what context it receives. Together they give EHR vendors and app developers a shared pattern, though each EHR still has its own registration process, supported features and approval steps.
There are three common patterns:
- EHR launch: a user opens the app from inside the chart or schedule, and it opens with the current user, and where authorized the current patient, already known. This is how a panel of open items can appear next to the chart.
- Standalone launch: a user opens the app outside the EHR and signs in.
- Backend services: a server connects without a user, with its own credentials, for scheduled data loads such as a nightly refresh.
How does an EHR launch work?
- A user clicks the app from inside the EHR, for example from a patient's chart or the day's schedule.
- The EHR passes a launch signal to the app.
- The app asks the EHR's authorization server for access, naming the scopes it needs.
- The authorization server checks that the app is registered and approved for those scopes, and returns an access token with launch context.
- The app reads only the FHIR resources it is allowed to read and shows its view inside the EHR.
Context depends on approved scopes. User context lets the app show role-appropriate information and audit access; patient context lets it show the open patient's items without a search; some EHRs also pass encounter context. A schedule launch may not carry a single patient at all.
Why do read-oriented apps suit embedded views?
Most embedded views are there to inform the person who acts, not to act for them. A panel can show that a patient on today's schedule has an overdue recall or an open order; the MA, scheduler or provider then handles it in the EHR's own screens. That keeps the EHR as the system of record, and read access is a narrower request for the administrator to approve than access that changes records.
What does FHIR not cover well?
- Scheduling and charges in a separate practice management system, which often send HL7 v2 messages (SIU for scheduling, ADT for admissions) or file exports.
- Claims and payments, which move through clearinghouses as X12 transactions: 837 claims, 277CA acknowledgements, 835 remittances and 270/271 eligibility.
- Local codes, such as custom appointment types, which need to be mapped to standard codes once per practice.
- Some workflows, such as recalls, checkout follow-ups and local work queues, which a given EHR may not expose through standard resources.
Why does access vary by EHR?
The standards define a common pattern, not identical products. EHRs differ in which launch points they support, which resources and search options they expose, how they handle bulk export, and how app registration works. Organizations also differ in what they choose to enable, so two practices on the same EHR can end up with different access. An honest answer to "do you integrate with our EHR?" should include which data, through which method, approved by whom, and confirmed when.
For Nuvory specifically:
- athenahealth: a live connection. Nuvory reads athenaOne data through FHIR R4 and bulk data APIs and opens inside the athenaOne chart and schedule as a SMART on FHIR app.
- Epic, eClinicalWorks, ModMed, NextGen, AdvancedMD and Practice Fusion: supported. Nuvory is designed to work with their data through FHIR R4, bulk export and SMART on FHIR where the organization enables it, with scope and data availability confirmed during discovery.
What should you ask any vendor?
- Which FHIR resources and scopes do you request, and why is each needed? Do you write anything back?
- Do you use bulk export for history, and how do you keep data current?
- Do you launch inside our EHR, from the chart, the schedule or both, and which users see it?
- How do you map our local codes and locations, and who approves the mapping?
- Can you take scheduling from our PM system and claims from our clearinghouse?
- Who in our organization approves the app, and how is access audited?
- Will you sign a BAA, and do you have a SOC 2 Type II report?
How Nuvory connects
Nuvory reads FHIR R4 and bulk data from your EHR on a nightly schedule, launches inside the chart with SMART on FHIR where your EHR supports it, and accepts PM, clearinghouse and HIE feeds where they are connected. Staff keep booking and documenting in the EHR. On the security question above, HealthArc's platform is covered by a SOC 2 Type II report. For how this differs from built-in reporting, see EHR analytics vs. revenue leakage intelligence; the integrations page has details for each EHR.
Frequently asked questions
Is FHIR the same as HL7?
FHIR is a standard published by HL7 International. HL7 v2 is an older HL7 messaging standard that is still widely used for admissions and scheduling feeds.
Does SMART on FHIR give an app access to all our data?
No. Your organization approves the scopes the app can use, and the app sees only that data, in the context of the user who launched it. What is available also depends on which resources your EHR exposes.
Is SMART on FHIR enough to find every open referral or order?
Usually not on its own. An embedded launch works one patient at a time. Finding open items across a whole practice typically uses bulk export or backend access on a schedule, and the embedded view then shows the results inside the EHR.
Who approves a SMART on FHIR app in our organization?
It varies. In smaller practices an EHR administrator often approves it. In larger organizations, EHR analysts, security and compliance teams may all review the scopes and the vendor's agreements before access is enabled.
Do we need claims data for leakage intelligence?
Not to start. EHR data is enough for most leakage types. Claims and remittances make completion matching more precise and show paid amounts.