FHIR Resources: 146 resource types in FHIR R4

1. What is a Resource? Definition and common structure

In FHIR, a Resource is the basic unit of information exchange with its own structural and semantic definition. Patient represents a subject of care; Encounter represents a healthcare interaction; Observation represents a measurement or assertion. Resource types share a base data model and can be linked into records, documents, or workflows, but not every type has narrative, modifier extensions, or references.

The following distinctions apply across Resources:

• resourceType — required in the JSON representation to identify the Resource type; XML uses the corresponding root element name.
• id — a 0..1 element used as the logical id when an instance has one in its exchange or persistence context.
• meta — a 0..1 element that may contain versionId, lastUpdated, profile, security, and tag.
• Schema defined by a StructureDefinition — which is itself a Resource (in the Foundation group).
• Exchangeable through REST, documents, messages, or other mechanisms defined by the specification and the applicable Implementation Guide.

FHIR R4 defines the following RESTful interactions. A server may support only a subset for each Resource type and must advertise that subset in its CapabilityStatement:

read    GET    [base]/[type]/[id]
vread   GET    [base]/[type]/[id]/_history/[vid]
update  PUT    [base]/[type]/[id]
patch   PATCH  [base]/[type]/[id]
delete  DELETE [base]/[type]/[id]
create  POST   [base]/[type]
search  GET    [base]/[type]?[parameters]
history GET    [base]/[type]/[id]/_history

If the server supports the corresponding interactions, create uses POST on the collection path [base]/[type], while update uses PUT on [base]/[type]/[id]. A client must check the advertised interactions, conditions, and profiles rather than assume every endpoint is available.

On identifiers: an instance stored on a FHIR server commonly has a location URL in the form [base]/[type]/[id]; a business identifier such as a national identity number or social insurance number has different semantics from that logical id. Canonical Resources such as StructureDefinition, CodeSystem, ValueSet, and CapabilityStatement have a url element that serves as a stable canonical URL for cross-system references.

2. Inheritance structure: Resource and DomainResource

FHIR does not define a mandatory “four-layer anatomy” for every Resource. The common structure is expressed through inheritance in the specification:

1. Resource — the base class with optional id, meta, implicitRules, and language elements.
2. DomainResource — a subclass adding text, contained, extension, and modifierExtension. Most clinical and administrative Resources, including Patient, inherit it; some types such as Bundle inherit Resource directly.
3. Domain elements — each type defines its own fields, such as Patient.name, Encounter.period, or Observation.value[x].
4. References and terminology — present only where the definition provides the corresponding element. For example, Encounter.subject may reference Patient/vn-001; not every Resource contains a reference.

Here is a complete Patient that conforms to the VN Core profile (abbreviated). The {...} fragments are pseudocode for illustration — real JSON must contain concrete values, and Narrative.div must be valid XHTML rather than an ellipsis:

// pseudocode — illustrating common DomainResource elements
{
  "resourceType": "Patient",
  "id": "vn-001",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2026-04-30T10:00:00+07:00",
    "profile": [
      "http://fhir.hl7.org.vn/core/StructureDefinition/vn-core-patient"
    ]
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Nguyễn Thị Hoa, nữ, 1985-03-15</div>"
  },
  "extension": [
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-ethnicity",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-ethnicity-cs",
            "code": "01",
            "display": "Kinh"
          }
        ]
      }
    }
  ],
  "identifier": [
    {
      "type": {
        "coding": [
          {
            "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-identifier-type-cs",
            "code": "CCCD",
            "display": "Căn cước công dân"
          }
        ]
      },
      "system": "http://fhir.hl7.org.vn/core/sid/cccd",
      "value": "001185000123"
    }
  ],
  "name": [
    {
      "use": "official",
      "family": "Nguyễn",
      "given": ["Thị", "Hoa"]
    }
  ],
  "gender": "female",
  "birthDate": "1985-03-15"
}

The meta.profile field declares conformance to vn-core-patient. In v0.9.0, the CCCD slice has cardinality 1..1 (and may carry data-absent-reason in a valid exception); ethnicity is optional, but its value must use the VN terminology when present. An address, if supplied, must conform to VNCoreAddress: coded province and ward are both 0..1 MS, with a warning-level invariant expecting a province code when country = "VN".

3. Classifying 146 Resources into 5 main groups

FHIR R4 organizes its 146 Resources into 5 top-level groups as listed on the official Resource Index page: Foundation, Base, Clinical, Financial, Specialized. Sub-domains such as Workflow, Documents, Medications are commonly mentioned independently in community documentation, but in the official taxonomy they sit inside Clinical/Base.

The Resource count on the official hl7.org/fhir/R4/resourcelist.html page is 146. That number is used consistently in the title, hero, and throughout this page. Older documents that cite 145 or 147 typically differ because they include or exclude abstract Resources such as Resource and DomainResource.

4. 12 Resource types commonly encountered in EMR scope

Resource scope must be derived from use cases, exchange requirements, conformance statements, and applicable regulation. The table below is an illustrative set of 12 types commonly encountered in EMR and BHYT workflows, not a minimum list mandated by Circular 13/2025/TT-BYT:

5. Maturity level and Standards Status

FHIR distinguishes two concepts that are easy to confuse: the FHIR Maturity Model (FMM) and the Standards Status.

• FMM 0 — published in the current build.
• FMM 1 — considered substantially complete and ready for implementation feedback by the work group, with the build-warning criterion met.
• FMM 2 — tested by at least three independently developed systems over most of its scope.
• FMM 3 — meets conformance-quality criteria, has passed formal ballot, and meets the specified comment and substantive-change thresholds.
• FMM 4 — tested across its scope, formally published, supported by multiple prototype projects, and subject to implementer consultation before incompatible change.
• FMM 5 — has completed at least two formal release cycles at FMM 1 or higher and is implemented in at least five independent production systems in more than one country.

Standards Status is a separate axis from FMM. FHIR uses Draft, Trial Use, Normative, Informative, and Deprecated as applicable to an artifact or part of the content. Normative content is governed by stronger inter-version compatibility rules; changes may still occur within the constraints of the standards process, so “absolutely frozen” would be inaccurate.

Status is published on each Resource page and can vary across parts of the specification. A Trial Use Resource may still be suitable for production when profiles, testing, version governance, and an upgrade plan are explicit; conversely, Normative status does not replace use-case fit analysis.

When selecting Resources for a production EMR, review FMM, Standards Status, the system's CapabilityStatement, and the constraints in the applicable IG.

6. Resource vs Profile vs Instance

These three concepts often confuse newcomers. The simplest mental model is the abstraction axis:

Resource (FHIR base)          ←  abstract definition, applies globally
   ↓ adds context-specific constraints
Profile (VNCorePatient)       ←  constrains Patient for Vietnam
   ↓ filled with real data
Instance (Patient/vn-001)     ←  a real patient in the system

Resource is the base concept — Patient in general. Profile is a StructureDefinition that adds constraints — VNCorePatient requires the CCCD slice at cardinality 1..1; in a valid exception, the slice may omit a scalar value when it carries data-absent-reason and the invariant's alternative basis. Instance is concrete data — patient Nguyễn Thị Hoa with CCCD 001185000123. A single Instance can conform to multiple Profiles; meta.profile records a conformance claim, but listing a URL does not itself create or prove conformance.

7. Bundle: grouping multiple Resources into one transaction

Bundle is a container Resource holding entries. Depending on Bundle.type, it can represent a transaction, search result, history, document, or message. Serializing or signing a Bundle does not by itself give the content legal-record status; signature, preservation format, and validation workflow remain subject to applicable policy and law.

R4 defines exactly 9 values for Bundle.type:

• transaction — atomic. The server processes all entries as a single transaction; if one entry fails, the whole batch rolls back.
• batch — non-atomic. Each entry is independent; one entry's failure does not affect the others.
• searchset — the result of a search interaction (GET /Patient?...).
• transaction-response — the response to a transaction.
• batch-response — the response to a batch.
• history — the result of instance-, type-, or system-level history.
• document — a FHIR document whose first entry must be a Composition and whose entries must satisfy the specification's document rules.
• message — an event message with MessageHeader first; this is a FHIR exchange model, not a claim that every HL7 v2 implementation is replaced.
• collection — a set of entries without the semantics of the other Bundle types.

subscription-notification is not a Bundle.type value in FHIR R4. Select a Bundle type from the semantics of the exchange rather than from a fixed “most common” list.

8. Versioning with meta.versionId

Every Resource can have multiple versions over time. FHIR manages this via the meta.versionId field — an opaque, server-assigned version identifier (not necessarily a monotonically increasing integer). Each time the server creates a new version of a Resource, versionId is updated along with meta.lastUpdated.

Versioning only works if the server declares support for it. That capability is exposed in CapabilityStatement.rest.resource.versioning with three values: no-version, versioned, versioned-update. The server can create a new version through several operations — not only PUT, but also PATCH, DELETE, or custom operations.

Two key endpoints for versioning:

GET /Patient/vn-001/_history          # full history (Bundle type=history)
GET /Patient/vn-001/_history/3        # vread with opaque versionId "3"

When the server supports version-aware update, a client can send If-Match: W/"3" to request an update only when the current version matches the opaque value "3". A mismatch returns 412 Precondition Failed. This is an optimistic-locking mechanism; support must be confirmed in the CapabilityStatement.

9. Frequently asked questions

Can I define new Resources of my own?

Do not invent an out-of-specification Resource type and treat it as interoperable FHIR. First assess existing Resources, Profiles, Extensions, and, in some cases, the Basic Resource. A proposal for a new core Resource must follow HL7 governance and ballot; an Extension is appropriate only when its meaning genuinely extends the selected Resource.

How are Patient and Person different?

Patient is a subject of care in a healthcare context. Person can link roles and identities for the same human, such as Patient, Practitioner, or RelatedPerson. An HIE or MPI may use Person, but it may also use another identity-linking pattern; Person is not mandatory for every HIE.

How are Encounter and EpisodeOfCare different?

Encounter is a single clinical visit — one outpatient consultation, or one inpatient stay from admission to discharge. EpisodeOfCare is a chain of multiple Encounters for the same clinical concern — for example, a 6-month cancer treatment course consisting of 12 chemotherapy Encounters. EpisodeOfCare is the right fit when you need aggregated cost and outcome reporting per disease rather than per visit.

Do I have to use all 146 Resources to roll out an EMR?

No. Derive the minimum Resource and profile set from use cases, exchanged payloads, reference dependencies, and applicable obligations. The 12 types above are only a starting reference: a narrow use case may require fewer, while documents, pharmacy, imaging, or reimbursement may require many more.

When should I use a Bundle instead of sending Resources individually?

Use transaction when the business operation requires atomicity and the server advertises support. Use document when FHIR document semantics with Composition first are required. Use message when the integration agreement selects FHIR messaging. Circular 13/2025/TT-BYT does not automatically turn every record into a document Bundle or require the Bundle to be one digitally signed file.

10. References and further reading

International standards

• FHIR R4 — Resource Index (146 Resources, 5 main groups)
• FHIR R4 — Resource definition
• FHIR R4 — RESTful API (create, read, update, delete, search, history)
• FHIR R4 — Standards Status (Draft / Trial Use / Normative)
• FHIR R4 — Bundle (transaction, batch, searchset, document, message)
• FHIR R4 — JSON serialization

Vietnamese legal references

• Circular 13/2025/TT-BYT — Electronic medical record (issued 06/06/2025, effective 21/07/2025) — operational context for EMR implementation; it does not prescribe the 12-Resource set above.
• Decision 4469/QĐ-BYT (28/10/2020) — Vietnamese edition of the international classification of diseases ICD-10 — binding for VNCoreCondition.
• Decision 387/QĐ-BYT (05/02/2026) — 2026 edition of the ICD-9-CM classification of surgeries and procedures — binding for VNCoreProcedure.
• Decision 3176/QĐ-BYT (29/10/2024) — Standard for clinical visit output data — input for VNCoreClaim.
• Circular 26/2025/TT-BYT (30/06/2025) — Outpatient prescriptions for chemical drugs and biologicals — binding for VNCoreMedicationRequest.
• See the full reference set of 172 documents in the VN Core legal corpus.

Continue reading in the knowledge hub