FHIR glossary

An assortment of related but independent FHIR® resources. Bundles are used anytime collections of FHIR® resources are sent or received as a unit. Check out HL7's reference docs for the Bundle resource.

Redox uses bundles for large-scale data transfers and stateful messaging workflows. When we translate older standards to FHIR®, we convert the HL7v2 or CDA message to a FHIR® bundle. For example, an HL7v2 message may translate into anywhere from 10 to 100 FHIR® resources in a message, while CDA may easily start at least 50.

Another example for using bundles is for search queries, which typically return a bundle to combine the resources identified by the query parameters. Alternatively, FHIR® messaging also relies on bundles to group related resources into a package that one system sends to another.

For a simpler example, you can think of a bundle like sending a package to someone. The package may contain one or more items (i.e., resources), but the package includes a packing slip to list what's inside (i.e., header data). Additionally, the bundle type helps determine how the destination may process the bundle. Check out our bundle type definition below this to learn more.

Designates how the bundle was packaged and should be processed. Redox supports searchset and message bundles. Searchset bundles are for responses to queries, while message bundles are for FHIR® notifications and writebacks.

Searchset bundles are what's returned in response to a FHIR® query (_search interactions). Searchset bundles can have zero entries, meaning there are no results matching the search criteria, or one or more resources that do match the search criteria.

Message bundles are a more general bundle of resources with no specific instructions on how they should be processed. Redox still attaches an event type to convey some meaning, but your connection gets to decide what to do with the bundle. This is a flexible option that most systems can support without requiring a FHIR® server. Redox uses message bundles for FHIR® notifications and writebacks.

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, meaning it's created and maintained by a system outside the FHIR® server. An identifier has an associated system and value. The system defines the format and interpretation of the value. The system identifies the external system and should be expressed in a FHIR® payload as a URI. As an example, a Social Security number is a type of identifier for a patient record, and the external system defines that it should be a numeric value with nine digits, as well as assigns the specific value.

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.