Hierarchy and resource structure in FHIR (optional)
Note
This unit is optional. If you're familiar with the FHIR standards, you can skip this unit.
Resources in FHIR are the entities that form the main components of the FHIR data model. Previously, you learned how FHIR structures resources. Additionally, you learned how resources that reference each other can model real-world healthcare interactions to form a web of health information. Now, you can learn about what constitutes a resource in FHIR and what sets resources apart from each other.
Hierarchy
The foundation of the FHIR data model is an abstract base resource class that all resource types inherit from, whether directly or indirectly. Only three resource types inherit directly from the base resource class: Bundle, Binary, and Parameters. Additionally, a resource class inherits directly from the base resource class, DomainResource, which is the parent class to all familiar, real-world resource types in FHIR, such as Patient, Practitioner, Observation, Device, CarePlan, and so on. All resource types, aside from Bundle, Binary, and Parameters, inherit from the DomainResource class.
As stated in the HL7 FHIR documentation, "Only three resources - Bundle (collection of resources), Binary (the data of a single raw artifact in its native form), and Parameters (operation requests or responses) inherit directly from the base Resource. DomainResource (what most other resources are derived from) allows other resources to contain text, contained resources, extensions, and data elements specific to the particular domain of each resource.
Resource elements and structure
The FHIR specification defines each resource type with a set of attributes to capture information as generated in real-world healthcare scenarios. These attributes, or elements as FHIR refers to them, are what sets FHIR resource instances apart from each other on a FHIR server.
For example, each FHIR resource instance has an ID element to store that instance's unique ID on the FHIR server where the resource lives. The system assigns an ID to each resource instance so that you can differentiate each resource instance. For example, on a FHIR server, one Patient resource with an ID of 123 and another Patient resource with an ID of 124 could exist (and so on).
The four elements that all resource types carry in FHIR are ID, metadata, impicitRules, and language. That is, the Bundle, Binary, and Parameters resource types plus all common resource types that inherit from the DomainResource class.
In addition to these four elements are many other elements that are specific to the common resource types that inherit from the DomainResource class. For example, the Patient resource type has gender, birthDate, and address elements. Each patient resource instance on a FHIR server has its own unique set of elements as such that distinguish patients from one another. Beyond the Patient resource type, the Observation resource type has another set of elements. Similarly, the Encounter, Medication, and DiagnosticReport resource types also have other sets of elements.
FHIR defines each resource type with a structure for the different elements that the resource type supports. The following image shows the structure for the Patient resource type with some of its standard elements.
Identity
The two standard ways of identifying a resource instance on a FHIR server are: the resource ID element (as mentioned previously) and another variety of element known as a business identifier.
Resource ID - Included at the trailing end of a FHIR resource's location URL (for example,
{{fhirurl}}/Patient/123), the resource ID (such as 123) is unique to each resource instance on a FHIR server. If the resource instance is moved or copied to another FHIR server, then the system assigns a new resource ID to the copied or moved resource (with some exceptions in practice).Business identifier - Generally, in addition to a server-wide resource ID, resources have identifier elements to uniquely represent the entity in the real world. This identifier remains fixed if a resource instance is copied/moved to another FHIR server. For example, for a patient, a Social Security number (SSN) is an ID that (typically) doesn't change. If you use the SSN for a patient as a business identifier for that patient's FHIR resource instance, then that business identifier remains the same wherever the resource instance is hosted.
Note
In FHIR documentation, the term resource refers to a resource type or resource instance, depending on the context.
Other resource details
Resource extensions allow you to associate more data to a core resource definition. For example, a Patient resource contains required elements such as patient identifier, patient name, and gender. This resource must also support the following components: contact detail (such as a telephone number or an email address), a birth date, an address, a communication language, a race, an ethnicity, and a birth sex (as part of the HL7 international standard). When you extend a patient resource for other purposes, such as participation in a global clinical study, you might need to capture more details, such as nationality. Be mindful that this approach might disrupt standardization across platforms when an extension isn't included elsewhere.