FHIR glossary

An assortment of related but independent FHIR® resources. Bundles are used anytime collections of multiple FHIR® resources are sent or received as a unit.

For example, search queries return a bundle to combine the resources identified by the search parameters. FHIR® messaging also uses bundles to group related resources into a unit that one system sends to another.

A common datatype in a FHIR® resource, which indicates that the value is one of a certain fixed set of values. You can think of this as a code value within a codeset, which is a set of codes explicitly mandated by the FHIR® specification. In a sense, code is like coding where the system is FHIR® and the values can’t be changed.

At the end of the day, a code value can be anything within FHIR®’s predefined, standard code system.

A common datatype in a FHIR® resource to define an object’s code system with an associated text field.

A codeable concept could contain only a free-text field with a verbal description of the object’s code. Or it could contain a full package, so to speak, which includes a code, system, and free-text field. Codeable concepts are helpful when organizations use different code systems to identify the same thing.

For example, there may be a lab test that organizations codify differently, but the name of the test would be the same. Just remember that a codeable concept means that there’s a text field used to define the code system.

A codeable concept could also be used if you need to include multiple sets of coding.

1
codeableConcept: {
2
"text": "CBC WO DIFFERENTIAL"
3
}

1
codeableConcept: {
2
“code”: “43789009”
3
“System”: “http://snomed.info/sct”
4
“Text”: "CBC WO DIFFERENTIAL" 
5
}

A common datatype in a FHIR® resource that contains code and system fields, which define the code system and value for the related object. Using a coding array is a simple, direct way to reference the code and system, and it’s commonly used in extensions.

1
coding: {
2
"code": "2670"
3
"system": "RxNorm"
4
}

A related resource that's included within a source resource. A contained resource is an alternative to including a reference to a target resource. Check out our definitions on references and resources for more context.

You can think of a contained resource a bit like an embedded file in a request versus a link to a file in a repository. To provide a link, the destination system must have access to the file repository. It's the same with resources. If the related resource doesn't exist in the receiving system, you may need to include a contained resource instead of only referencing a resource ID.

A temporary ID is generated for a contained resource and is included within the contained field of the resource. You can identify these types of IDs because they start with a # symbol. For example, if you see an Appointment resource with a participant ID of #123456, then you know it's referencing a contained resource that's included within that resource.

A datatype is a structured field, element, or array used in FHIR® schemas. In concept, it’s similar to a resource type, but at a granular level for a piece of data within a resource. Datatypes are standardized across resource types.

There are four datatypes:

1. Simple types consist of one element with a primitive value. Some examples are id, code, boolean, uri, string, or integer.
2. Complex types consist of a set of elements. Some examples are attachment, codeableConcept, coding, quantity, or identifier.
3. Metadata types consist of standards for metadata for knowledge resources. Some examples are contactInformation, dataRequirement, parameterDefinition, or relatedArtifact.
4. Special purpose types are standards for a broader set of data for specific usages. Extensions and references are examples of these. Check out our definitions for extensions and references for more details.

An extension is a set of additional elements included in a standard FHIR® resource to create a unique resource profile.

Since resources are intended to be a base, extensions may be useful if there’s additional information you commonly want to include when exchanging data. Extension arrays could be named extension, or if we’re extending a simple field within a resource, it'd be _[element].

For example, the standard FHIR® DeviceRequest status indicates whether the status is completed or pending. The Redox extension for the DeviceRequest resource adds color by also including the number of devices requested.

An id is an internal FHIR® identifier for a resource. When a resource is stored in a database, it’s referenced using the resource ID. For data on demand, this is going to be a UUID.

On the other hand, an identifier is an external business identifier for a FHIR® resource. The value of an identifier is how content is identified in other systems outside the FHIR® server. For example, a Social Security number is one type of identifier for a patient record. Alternatively, identifiers can include a URI for a system within which that identifier is meaningful. In that case, the identifier could be a URL.

Interactions and operations are terms with a specific meaning in the context of a FHIR® RESTful API.

Interactions (often called CRUD requests) are RESTful, which means they allow you to read, update, or delete an existing resource, as well as create a new resource. Interactions are standardized and straightforward actions that allow you to modify the state of or read a resource stored in a FHIR® server. But many interactions (especially those not mandated by USCDI, like create or patch) aren’t likely to be available for every connection.

Operations are used for "non-RESTful" parts of the FHIR® HTTP API. Conceptually, they're similar to RPC-style endpoints that can trigger arbitrary logic on the server beyond just transferring the state of a resource. Operations are more flexible than interactions, but that also means they’re more complicated and less standardized.

You can distinguish between an operation and an interaction by its name since FHIR® operations start with $ (e.g., $convert, $message, $submit).

A FHIR® message is a payload sent from one FHIR® server to another. This type of data exchange follows the FHIR® messaging framework. Learn more about FHIR® messaging.

All FHIR® messages store their payload in a Bundle resource. The first resource in the bundle is a special one called a MessageHeader, which provides metadata about the origin and meaning of the message payload.

FHIR® users can take a base resource type (e.g., a Patient resource) and create a profile that extends the purpose of the resource to suit their business needs. In other words, FHIR® users can build their own standard on top of the base HL7 standard to define additional rules about how a FHIR® resource type should be used for a given scenario. This clarifies how end users may use that resource type.

Redox created a library of resource profiles specifically for customers like you, based on common use cases we’ve seen. With Redox profiles, we simplify and streamline the experience of real-world FHIR® integrations so that you can compose your own unique workflow.

A reference indicates a one-way relationship from one resource to another. The resource being pointed to (the metaphorical endpoint) is sometimes known as the target resource. The source resource may contain multiple references to target resources. You can think of this like a bubble map with a source resource at its center with branches (i.e., references) pointing outward to related target resources. Remember, though, that the reference is a unidirectional pointer.

The most common type is a literal reference, which points to a given target resource using the resource ID. Redox often uses literal references because it’s much easier to use literal references as much as possible. In a more everyday analogy, this might be like referring to a person not present in the conversation by using their given name.

You could have two different types of literal references. Relative literal reference and fully qualified literal reference. The first is relative to a specific FHIR® server; for example, a patient’s FHIR® id within a given FHIR® server. A fully qualified literal reference, on the other hand, is typically a full URL to a reference, which isn’t specific to a FHIR® server. The URL is used for queries across different FHIR® servers. You can see this in an event notification, in a field called fullURL, which contains a URL value that you download to view the full patient resource.

If you don’t know the ID, FHIR® still offers logical references, which point to a target resource using identifying information other than the id. To use the conversation analogy, a logical reference is like referring to a third person by their physical traits, residence, or occupation instead of their name.

Redox uses logical references for encounters. Instead of a literal reference, the only field we want to save is a visit number. We use that logical reference (i.e., visit number) to identify the encounter, which may or may not be in our system. However, references based on business logic can get complicated, and it’s not very robust either. In our conversation example, there may be several people with dark hair and glasses, not just one particular individual.

A resource is a piece of data exchanged between systems. All resources are an instance of a resource type that specifies the name, content, and meaning of the resource.

When querying for data, you may receive a resource with the data populated in the defined schema for that resource type. For example, if you search for a patient, you receive a Patient resource with a given patient’s data organized according to the Patient resource type.

A resource type is a standardized schema to organize data. A FHIR® resource type is the core architectural building block in that it provides a consistent format for how data should be shaped. Resource types define what data to provide and what data to expect back when exchanging resources. They also contain information about the meaning and clinical interpretation of the resource’s content.