FHIR conformance and cardinality

Back to FHIR

Introduction

As of v0.02, FHIR has the following fields that describe the rules around whether an element can or must be present or not:

• Cardinality
• Conformance: Mandatory | Required | Conditional | Optional | Prohibited.
• condition field - must be present if Conformance is conditional

The interplay between these fields creates some interesting dynamics, and there's things you want to say that you can't, things you can say that don't make sense, and things that aren't clear. This page considers how to improve this.

Note that there's three separate issues at play here: how resources and profiles are authored, how they are presented, and how they are properly understood. Ideally, the last two should be the same, but not all presentation formats are capable of that. XML schema, for instance, knows only cardinality.

Cardinality

For authoring a resource, the only allowed min cardinality is 0 or 1, and the only allowed max cardinality is 1 or *. Other values are not allowed (build fails). This is equivalent to

• must you have an element present
• are you allowed to have more than one element present (i.e. implementations use some kind of list for the element)

In a profile, you can specify any combination of cardinalities, as long as min <= max, and min >= 0.

Cardinality is authored in the spreadsheets by entering the M..N values directly into the column entitled "Cardinality"

Conformance

Conformance is edited in the spreadsheet by entering a code into the "Conformance" column. The following codes are allowed:

• Unstated - this element doesn't need to have a conformance flag on it. This means that the element is there fore purely structural reasons, has no inherent meaning, and is optional
• Mandatory - if this element is present, it may not have a dataAbsentReason on it (it's quite common to have min cardinality = 0, but to be mandatory)
• Conditional - the element has a minimum cardinality of 0. If the condition is true, then it must be present (or at least one must be present), and it cannot have a dataAbsentReason on it
• Optional - if the element is present, it may have a dataAbsentReason on it
• Prohibited - (only in a profile) if the element is present, it must have a dataAbsentReason on it. (when would you use this? -when the min cardinality of the content you are profiling is 1, and it is optional, and you don't want to use it. This is an edge case. - May be appropriate to remove prohibited?)

Condition

If the conformance type is conditional, then this is a human (english only in resources themselves) expression of the rules associated with the conditionality.

Problems

Enter your problems with this content here.

Grahame

• should deprecate prohibited? the case it represents is really very edge case
• do you ever want conditional to only refer to the cardinality, and not the dataAbsentReason as well?
• mandatory has an overlaid meaning. Perhaps better names would be: Unstated | NoAbsent | MaybeAbsent | MustBeAbsent?
• conditional is different - it applies to the cardinality as well as the dataAbsentReason. Should drop it, and be more explicit?
• related problem: is there mileage in being explicit about co-occurent constraints and model choice directly?
  • gg: no? So far, the cases in resources haven't often been as simple as (a xor b) - they've been more complicated.
  • gg: todo - gather a list of observed cases for conditional so far