What is a FHIR Resource?

A FHIR Resource is the building block of the HL7 FHIR - it represents a single concept that may contain information but may also reference other Resources within the same message.

Examples of FHIR Resources / bundles may be viewed and validated on the Tenasol FHIR Viewer.

Summary:

• The federal government has tightly mandated that EMR / Electronic Medical Record organizations be able to export or import data in FHIR resources.

• Unlike previous electronic health data formats, FHIR is broken into discrete concepts called "Resources", such as Patient, Practitioner, Claim, or Specimen.

• Resources have defined fields, but also are "extensible" meaning infinite custom fields may be added, however HL7 has defined the most common fields and how to populate them.

• A Resource’s permitted fields and requirements may be narrowed by a FHIR Implementation Guide.

• A FHIR Resource may reference other FHIR resources or be self-contained.

• FHIR Resources are structured in the JSON file format for easy API exchange between computer networks and the internet.

Here is the full map of R4 resources available for use:

Example: Patient Resource

Every Resource identifies its type through resourceType. Most Resource instances also have an id, although whether an id is required depends on how and where the Resource is used. Resources may include metadata, a human-readable narrative, extensions, and fields unique to that Resource type. A full list of Resources are available here.

Here is a Patient resource example, in the context of a single procedure and condition recorded during an encounter with a practitioner:

The singular Patient resource is highlighted to show that is what is being shown to the right. In theory there is a specified sequence of resources in a bundle, but in practice the order does not matter.

FHIR Resource References

In the above bundle, there are a LOT of resources referencing the patient, which makes sense as they are the subject of the bundle - but how does this get stored if they are not in the Patient resource?

Now looking at the Procedure resource, we see an appendectomy. The entries circled in red are the references to the linked Resources. The Green fullUrl represents the reference address used for other Resources to reference it if needed - in this case there are nothing that refers to this procedure.

urn:uuid: URN (Uniform Resource Name) indicates that it is a universal identifier for the resource. UUID (Universally Unique Identifier) specifies the type of identifier used - a 128 bit unique value. This is followed by the identifier itself. Here is a list of fullUrl structures that may be used to reference a Resource:

• urn:uuid:39336534-3863-6565-3064-653239303665 - an absolute ID reference as indicated in the above example.

• https://fhir.example.org/Procedure/12345 - in this case Procedure/12345 may be used when referencing a resource with this fullUrl. We can shorten the reference as it is on the same server/host.

Note that the id field is just the final identifier - in this case either 39336534-3863-6565-3064-653239303665 or 12345.

FHIR Datatypes Found Within a Resource

A resource may contain any of the following data types - note that special purpose data types includes reference which we just discussed.

These "primitives" may have their own constraints just like a Resource, but are not considered resources themselves. These are both structural or syntax in nature. Below is the example for the quantity datetype. For example, the decimal value must pass a regular expression to be considered appropriate in validation.

It is possible for a resource to "contain" another resource within its contained array, however this is uncommon and it is more often that they are separated and reference each other.

FHIR Extensibility of Resources with 'Extensions'

We mentioned earlier that a Resource can have custom fields. FHIR calls these "Extensions" because they extend beyond the base data model.

Tenasol performs direct transformation of all file formats to FHIR. In doing so, we use extensions unique to us that track the source file, the content, structured or unstructured nature, context, and in some cases page, filename, or token indexes to track the original source of information that a resource was generated from:

This is to say, an extension may contain any datatype, even a binary (generic object). The example above even shows an extension inside of an extension.

FHIR Revisions and Implementation Guides

Here, we mainly showed examples from "Base R4", however future revisions, e.g. R5 may contain more Resources, and different fields on those resources. Base R4 is by far the most popular and heavily used at present, but this may not always be the case, meaning rules can change about how Resources are defined and look over time.

In another blog we covered Implementation Guides but we must here also. These create narrower than already defined constraints about structure and codification of individual resources. IG's may inherit rules from base Revisions and other Implementation Guides. A resource constructed with a specified IG may store it in meta.profile.

Conclusion

FHIR Resources provide the fundamental building blocks for representing and exchanging healthcare information in a standardized, interoperable format. Rather than placing all information into a single document structure, FHIR separates clinical concepts into Resources such as Patient, Observation, Procedure, Condition, and Claim, which can then reference one another as needed. Each Resource follows the rules of the underlying FHIR release while remaining extensible through FHIR's extension mechanism.

Understanding the distinction between Resources, Datatypes, References, Extensions, and Implementation Guides is essential when working with real-world FHIR data. The base FHIR specification establishes the fundamental structure and capabilities, while Implementation Guides and profiles can impose additional requirements for specific use cases and healthcare workflows.

FHIR R4 remains one of the most widely implemented versions of FHIR, but organizations must be aware that FHIR continues to evolve through subsequent releases such as R5. Similarly, different Implementation Guides can place different constraints on the same underlying Resource. By understanding these layers, developers and healthcare organizations can better interpret, validate, transform, and exchange FHIR data while preserving the clinical meaning and provenance of the underlying information.