FHIR R4 Resources Explained: Patient, Observation, Encounter and More
FHIR R4 resources are the building blocks of modern healthcare APIs, each representing one clinical or administrative concept, such as a patient, a lab result or a medication order. Understanding which resource answers which question is the fastest way to design reliable FHIR integrations. This guide explains the most-used R4 resources, their key elements under US Core, and search patterns that work against major EHR endpoints. If you are building a FHIR integration, our FHIR integration development team can help you plan it properly.
How FHIR R4 Resources Work
FHIR resource types are standardized data structures exchanged through RESTful APIs, usually as JSON. Each resource has a defined set of elements, data types and references to other resources. Instead of one large message, FHIR models healthcare data as a connected network: an Observation references a Patient, an Encounter and sometimes a DiagnosticReport. Understanding these relationships helps developers query efficiently, avoid unnecessary API calls and build data models that stay consistent across different EHR vendors.
Resources, Elements and Data Types
Each resource contains elements with specific data types, such as strings, dates, codes and references. Coded elements use terminologies like LOINC, SNOMED CT or RxNorm, keeping meaning consistent across EHR/EMR integration projects.
References Between Resources
Resources link through references, such as an Observation pointing to its Patient. Clients follow references to build complete clinical pictures, and search parameters like _include reduce the number of separate requests.
US Core Profiles
US Core constrains base R4 resources for use in the United States, defining required and must-support elements. Certified EHR APIs are built around US Core, so most US integrations and healthcare API development projects should target it.
Must-Support Elements
Must-support means servers must return the element when they have the data, and clients must handle it correctly. It does not guarantee data exists, so clients need graceful handling. Apply HIPAA technical safeguards to cached data.
Versions and Identifiers
Each resource has a logical ID assigned by the server and business identifiers, such as medical record numbers. Clients should store both and never assume IDs stay identical across servers. Ask our FHIR engineers about identifier strategy.
The Most-Used FHIR R4 Resources
A small set of FHIR R4 resources covers most integration needs, from patient demographics to results, problems and medications. Each serves a distinct purpose, and choosing the wrong resource leads to confusing data models and failed validation. The resources below appear in nearly every US Core implementation and power most patient apps, clinician tools and analytics pipelines. Learning their key elements first will make your FHIR API work far faster and more predictable.
FHIR Patient Resource
The FHIR Patient resource holds demographics: identifiers, names, birth date, gender, address, telecom and communication preferences. US Core adds race, ethnicity and birth sex extensions, which many EHRs return consistently.
{ "resourceType": "Patient", "id": "example-1", "identifier": [{ "system": "urn:oid:1.2.3.4", "value": "MRN12345" }], "name": [{ "family": "Doe", "given": ["Jane"] }], "gender": "female", "birthDate": "1980-04-12" }FHIR Observation Resource
The FHIR Observation resource carries measurements and findings, including lab results, vital signs and social history. Key elements are status, category, code, subject, effective time, value and reference range, plus interpretation.
{ "resourceType": "Observation", "status": "final", "category": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory" }] }], "code": { "coding": [{ "system": "http://loinc.org", "code": "2345-7" }] }, "subject": { "reference": "Patient/example-1" }, "valueQuantity": { "value": 98, "unit": "mg/dL" } }Encounter
Encounter represents a visit or admission, including class, type, period, location and participating practitioners. Observations, conditions and procedures often reference it, which lets applications group clinical data by visit accurately.
Condition
Condition captures problems and diagnoses, with clinical status, verification status, category, code and onset. US Core separates problem list items from encounter diagnoses using the category element, which clients should respect.
MedicationRequest
MedicationRequest represents prescriptions and medication orders, including medication code, dosage instructions, status and requester. Medications usually use RxNorm codes, and dosage structures vary considerably between EHR vendors in practice. Normalize dosages carefully.
AllergyIntolerance and DiagnosticReport
AllergyIntolerance records allergies with substance, reaction and criticality. DiagnosticReport groups related results, such as a lab panel or imaging report, referencing individual Observations and sometimes attached documents. Both are required under US Core.
Matching Clinical Questions to FHIR Resources
Developers often know the clinical question they need to answer but not which resource holds the answer. Mapping questions to resources early prevents over-fetching, missed data and inefficient queries. The patterns below reflect common product requirements in patient apps, care management tools and analytics platforms. For each, the right resource and search approach can reduce API calls dramatically, which matters when EHR endpoints enforce strict rate limits during customer onboarding.
Who Is This Patient?
Use Patient, searched by identifier or by name and birth date. Prefer identifier searches, because demographic searches can return multiple matches and require careful handling in your application logic. Confirm matches carefully.
What Are the Latest Lab Results?
Use Observation with category laboratory, filtered by patient and date, sorted by date descending. DiagnosticReport provides panel grouping when you need results presented together as the lab issued them. Our lab integration services cover the source side.
What Problems Does the Patient Have?
Use Condition with category problem-list-item and clinical status active. Encounter diagnoses live in the same resource with a different category, so filter carefully to avoid mixing lists. Resolved problems are excluded this way.
What Medications Is the Patient Taking?
Use MedicationRequest with active status for prescribed medications. Some EHRs also expose MedicationStatement or MedicationDispense, so confirm which resources each vendor supports before designing your medication features. Support varies by vendor.
When Was the Patient Last Seen?
Use Encounter, filtered by patient and sorted by date. Check the class and status elements, because cancelled appointments and planned visits may also appear depending on the EHR vendor. Filter by status.
FHIR Search Parameters That Work in Practice
FHIR defines many search parameters, but EHR servers support only a subset, and behavior varies between vendors. Queries that work perfectly on a test server may fail or return partial results in production. Always check each server's CapabilityStatement, test against real endpoints and design queries defensively. Good search design also improves performance and reduces the risk of exceeding rate limits, especially during bulk historical syncs for newly onboarded customers. These practices consistently help most.
Patient-Scoped Searches
Most EHR endpoints require a patient parameter for clinical resources. Searching Observation or Condition without one often fails, so design your application around patient-scoped queries from the very beginning. Plan queries accordingly.
Category and Code Filters
Use category to narrow Observations to laboratory or vital signs, and code with LOINC for specific tests. These filters reduce response sizes considerably and make results easier to process in your application.
Date Ranges and Sorting
Use date parameters with prefixes like ge and le for ranges, and _sort where supported. Not every server supports sorting, so be ready to sort results client-side when necessary. Test both behaviors.
Pagination and _count
Servers return results in pages with next links. Always follow pagination links rather than assuming one page contains everything, and use _count carefully, because servers may cap page sizes. Handle partial pages.
Checking the CapabilityStatement
Every FHIR server publishes a CapabilityStatement listing supported resources, interactions and search parameters. Read it programmatically at startup, so your integration adapts to each server's actual capabilities automatically. Cache it per server.
Frequently Asked Questions
What are FHIR R4 resources?
FHIR R4 resources are standardized data structures for healthcare information, such as Patient, Observation, Encounter and MedicationRequest. Each has defined elements and data types, and resources reference each other to form complete clinical records. They are exchanged through RESTful APIs, usually in JSON, and form the basis of certified EHR APIs.
How many resource types does FHIR R4 have?
FHIR R4 defines around 145 resource types, covering clinical, administrative, financial and infrastructure concepts. However, most integrations use a small subset, such as Patient, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, Procedure, Immunization and DiagnosticReport, which are the core resources profiled in US Core.
What is US Core in FHIR?
US Core is an HL7 implementation guide that constrains base FHIR R4 resources for use in the United States. It defines required and must-support elements, terminology bindings and search parameters. Certified EHR APIs follow US Core, so building to it maximizes compatibility across major EHR vendors and health systems.
What is the difference between Observation and DiagnosticReport?
An Observation represents a single measurement or finding, such as one lab value or a blood pressure reading. A DiagnosticReport groups related observations into a report, such as a complete lab panel or an imaging report, and can include narrative conclusions or attached documents from the performing service.
Do all EHRs support the same FHIR resources?
No. Certified EHRs support the US Core resources required for certification, but support for additional resources, write operations and search parameters varies widely. Always check each server's CapabilityStatement and test against real customer environments, rather than assuming identical behavior across vendors or even across customers.
Should I use FHIR R4 or R5?
For US healthcare integrations, use FHIR R4, because certified EHR APIs and US Core are built on it. FHIR R5 introduces improvements, but adoption remains limited. Design your internal data model cleanly, so migrating to later versions remains manageable when the ecosystem eventually moves forward.
Planning a FHIR R4 Integration?
Our integration engineers are ready to help. Free consultation, no obligation.