One of the lesser-understood aspects in FHIR, we find, Is flags. To remedy this, we will talk about these annotations in general, as well as talk a little about two special flags: must-support and isModifier. Before we start, it’s very important to note that FHIR actually has a resource named Flag, which can be a little confusing. To make sure that we are on the same page, this article will not be talking about this resource.

In general, FHIR contains as part of the standard a set of annotations named flags. Each annotation carries with it a set of rules or things that any FHIR implementer – or even someone who just wants to be able to read a resource – must understand in order to be able to understand the entire context of the resource. As the FHIR spec says: “A set of information about the element that impacts how implementers handle them”. Most of these flags affect only the element on which it is set. In addition, all elements in a resource may have several flags set to annotate it.

As you can see in the photo above, flags will be found in the second column of a resource model, in this case, it is the simplifier.net view of the ILCore Patient profile. The FHIR spec has a similar, if somewhat different view. If you can read one, you’ll be able to read the other.

What flags are there?

The five main flags are (with links to the FHIR spec for a deeper dive):

Σ – Summary. Denotes that the element is part of the summary set – a short, concise representation of the data stored in the resource. FHIR allows users to retrieve, instead of the entire resource, only this subset of elements. This provides for a more at-a-glance experience of the data. For more on this topic, please see Summary Searches.

C (in Simplifier – I) – Constraints. denotes that the element is affected by constraints. Constraints are rules that are set on either the element or the entire resource. The possibilities for constraints are extremely varied and it is almost impossible to describe all the different ways that constraints can be used. It’s all about what the use case requires. Examples of constraints can be as simple as setting an exact length for a string element, through things that SHALL be present in a resource, conditions that must be met etc. For more on this topic, please see Constraints.

NE – “No extensions allowed”. This element cannot have extensions (some infrastructural elements only). This is extremely rare in the FHIR spec.

Must Support

S – The “Must support” flag. One of extreme importance! The tricky thing about the must support flag is the fact that there is nowhere in the entire spec, an actual definition of what this flag means in the real world. Generally speaking, the must support flag simply means that whoever makes use of the resource must be able to support some demand set by the creator of the implementation guide. That demand can, in many cases, simply mean “you must be able to retain this data on your system and return it on demand”. Another option can simply be a stipulation that your system should be able to understand the data in the element. These are by no means the only options. As this is not fixed in any way, a very important aspect of reading a resource structure is being able to find the description, within the implementation guide, for what “must support” actually means in this case. There are two ways to go about defining what must support means: either it is defined for the entire IG or it is defined element by element. A good IG will have a clear stipulation of where the definition of must support can be found. If you write an IG, you MUST define what MS means for you.

For more information on the topic see MustSupport Elements.

isModifier

?! – “isModifier” flag. This element is a modifying element. Whoa now. Here be dragons. We have saved the best for last. What it means is that the element cannot be ignored, under any circumstances, as its value can affect or change the meaning of the entire resource.  Ignoring this flag is dangerous and you absolutely MUST check the value of the element when processing the resource in any way.

Most Resources have at least one modifier element. Almost all resources have a `status` element, and it is usually a modifier. This makes sense, as we wouldn’t want to, for example, ignore something like the fact that a Patient is no longer a customer of your organization. Another example can be found in the `Patient.deceased[x]` element. Obviously, a dead patient shouldn’t receive medication requests, right?

Want another example? `AllergyIntollerance.clinicalStatus` is a good one. We know that certain allergies, especially in children, tend to sort themselves out as one grows older. In such a case, we would populate the element with the code #resolved, which will inform future medical care for the patient. The same Resource also has the element `AllergyIntollerance.verificationStatus` which can have the code #entered-in-error: a VERY important piece of information: the supposed allergy never actually existed!

As you can see, this flag is critical knowledge – tread with caution and do yourself a favor – see Modifier Elements for more on this.

Modifier extensions

The isModifier flag has a cousin – modifier extensions. In FHIR, there are instances where extensions modify the meaning of the containing element, often providing qualifying or negating information. These are known as “modifier extensions.” Examples include flags indicating certain conditions, asserting family history in a different context, indicating a request to not call the supplied phone number and many more. If there are modifier extensions, an application cannot safely process the resource unless it understands what the extension means for the data it will be using.

According to the FHIR® specs: “Implementers SHOULD avoid the use of modifier extensions where possible. Any use should be carefully considered against its possible downstream consequences. Inclusion of modifier extensions in an instance would be expected to significantly limit the ability of other systems to process the instance. However, implementers are often forced into these situations by the business arrangements around the use of resources, so this specification creates a framework for handling such cases. Implementers who are introducing an extension and are uncertain whether the extension should be marked as a modifier are encouraged to raise the question on chat.fhir.org.”

Conclusion

In conclusion, flags are an extremely important part of reading and defining FHIR resources. It is IMPERATIVE that any FHIR practitioner familiarize themselves not only with the meaning of each flag, but also with what is required of them when such a flag is present in the StructureDefinition.

—

Are you learning to define FHIR resources and profiles? Understanding slices and slicing is very important. Read more about it here.