FHIR Resources: 146 core data units

1. What is a Resource? Definition and common structure

In FHIR, a Resource is the basic unit of data used to represent a healthcare concept. A patient is a Resource (Patient). A clinical visit is a Resource (Encounter). A lab result is a Resource (Observation). Each Resource solves exactly one problem — like each lego brick has its own shape, but they all snap together according to the same standard.

Every Resource has the following mandatory characteristics:

• resourceType — a string that identifies the Resource type (for example, "Patient", "Encounter").
• id — the logical identifier of that Resource on the FHIR server (assigned by the server or proposed by the client on PUT).
• meta — metadata containing versionId, lastUpdated, profile, security, tag.
• Schema defined by a StructureDefinition — which is itself a Resource (in the Foundation group).
• Readable and writable through the REST API using the standard interactions.

The standard set of RESTful interactions for a Resource in R4:

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

An important note: create uses POST to the collection path [base]/[type] (without an id — the server assigns one), while update uses PUT to [base]/[type]/[id]. Confusing these two endpoints is a common integration bug.

On URLs: most Resources (Patient, Encounter, Observation, etc.) are identified by a logical/location URL in the form [base]/[type]/[id] and by a business identifier (national ID number, social health insurance card number, etc.). Only a few special Resources in the conformance/knowledge group — StructureDefinition, CodeSystem, ValueSet, CapabilityStatement — carry a url field that acts as a canonical URL for cross-system references.

2. Anatomy: the four parts of a Resource

Every Resource in FHIR shares the same anatomy of four layers. Learn the layers once and you can read every Resource.

1. Metadata — id, meta, implicitRules, language, text (a human-readable XHTML narrative rendering).
2. Extensions — extension[] for extension data that does not change semantics, and modifierExtension[] for extensions that can alter the meaning of the entire Resource.
3. Domain data — fields specific to that Resource type: Patient.name, Patient.gender, Encounter.period, Observation.value[x], etc.
4. Reference — links to other Resources via the Reference data type, for example Encounter.subject pointing to Patient/vn-001.

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 the 4-layer structure
{
  "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": "
Nguyễn Thị Hoa, nữ, 1985-03-15
"
  },
  "extension": [
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-ethnicity",
      "valueCoding": {
        "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-ethnicity-cs",
        "code": "01",
        "display": "Kinh"
      }
    }
  ],
  "identifier": [
    {
      "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 that this Patient conforms to the vn-core-patient profile — that is how VN Core constrains the base Patient into a Vietnam-specific Patient (CCCD required, ethnicity required, address must include the commune/ward level).

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 core Resources for a Vietnamese EMR

Rolling out an electronic medical record under Circular 13/2025/TT-BYT (Ministry of Health) does not require all 146 Resources. The VN Core IG prioritizes 12 Resources that meet the minimum bar for the clinical visit and BHYT (Vietnam's mandatory social health insurance) workflow — mapped to VN Core profiles as follows:

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 — draft, only the skeleton exists.
• FMM 1 — published but no implementer feedback yet.
• FMM 2 — at least one implementer has confirmed it.
• FMM 3 — interoperability tested at a connectathon.
• FMM 4 — running in production across multiple environments, stable enough to build on.
• FMM 5 — only the formal review process to reach Normative is left.

Standards Status sits above FMM and has three levels: Draft, Trial Use, Normative. Once a Resource (or artifact) is Normative, HL7 commits to no breaking changes on the main branch of that release.

In R4, the Normative list contains 13 entries (per HL7's resourcelist.html), including the abstract bases Resource and DomainResource. Notable Normative Resources: Patient, Observation, Bundle. An important caveat: many Resources commonly used in Vietnam — including AllergyIntolerance, Encounter, Practitioner, Organization, Location — are still Trial Use in R4. That does not mean they are unsafe to use; it means HL7 reserves the right to adjust them between releases.

When choosing a Resource for a production EMR, read both FMM and Standards Status to balance stability against use-case fit.

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 identifier to contain at least one CCCD. Instance is concrete data — patient Nguyễn Thị Hoa with CCCD 001185000123. A single Instance can conform to multiple Profiles at once if listed in meta.profile.

7. Bundle: grouping multiple Resources into one transaction

Bundle is a special Resource that acts as a container — it holds many other Resources through its entry[] field. A Bundle is how FHIR sends multiple Resources in a single HTTP request, or packages an electronic medical record into a single digitally signed file.

R4 defines 5 commonly used Bundle types (via the Bundle.type field):

• 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?...).
• document — a packaged medical record/report: the first entry is the Composition, followed by the referenced Resources. Equivalent to the CDA Document concept.
• message — a workflow event payload, replacing the HL7 v2 message paradigm.

Beyond the 5 main types above, R4 also defines history, collection, and types for subscription notifications — but for a Vietnamese EMR, the 5 listed above cover most integration scenarios.

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        # read version 3 (vread)

When updating a Resource, the client can include the If-Match: W/"3" header to ensure the write only succeeds if the current server version is exactly 3 — preventing concurrent overwrites (optimistic locking). This mechanism is essential for protecting EMR integrity when multiple clinicians update the same record at once.

9. Frequently asked questions

Can I define new Resources of my own?

No. FHIR strongly recommends not creating brand-new Resources. Any extension need should be addressed through an Extension on an existing Resource, or through a Profile that adds constraints. Only when no existing Resource fits will HL7 consider adding a new Resource in the next release.

How are Patient and Person different?

Patient is the subject of care in a specific healthcare context — for example, a patient at Bach Mai Hospital. Person is a broader concept used to link the identity of one human across multiple systems (Patient at hospital A, Practitioner at hospital B, RelatedPerson on a child's record, and so on). In a single EMR, you use Patient. In an HIE that connects systems, you need Person.

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. Start with the 12 core VN Core Resources. When you expand into pharmacy management, add Medication, MedicationDispense, MedicationAdministration. When you expand into diagnostic imaging, add ImagingStudy. When you expand into research, add ResearchStudy. The FHIR philosophy is add as you grow.

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

Use a transaction Bundle when you need atomicity — for example, creating a Patient + Encounter + 5 Observations together, with no half-success outcome allowed. Use a document Bundle when you need to package an electronic medical record into a single digitally signed file under Circular 13/2025/TT-BYT. Use a message Bundle when an event needs context-aware processing (admit, discharge, transfer).

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) — the main driver for VNCoreComposition and the 12 core Resources.
• 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 57 documents in the VN Core legal corpus.

Continue reading in the knowledge hub