FHIR Constraints and Rules

The following text used the Refinement, Constraint and Localization document from HL7’s core principles. At the 2015 WGM in San Antonio on the Wednesday joint session (FHIR + templates + CGIT) we made a start to craft this document to capture the rules for profiling resources and other profiles in FHIR.

Constraints and Annotations

Constraints are the central feature of the refinement process when creating profiles, as they reduce the generality of the specification and focus it on a particular requirement. The constraints that may be asserted fall into six broad categories:

• Appearance constraints determine whether a particular element must appear derived from the base resource or profile, and/or whether the element is precluded from appearing therein.
• Cardinality constraints define the number of repetitions that may occur for a given element.
• Type constraints limit the structure or "type" of the element in question. These are constraints placed upon the data types and upon the use of resource references for associations.
• Vocabulary constraints limit the set of concepts that can be taken as valid values in an instance of a coded attribute or data type.
• Other value constraints provide for the declaration of constraints stated as text and, optionally, as testable expressions to establish "business rules", and for the assertion of default or fixed values.
• Annotations provide further explanations to educate prospective users and/or implementers. These are usually used to enhance the descriptions of the elements of the base specification in order to relate them to a particular Context.

Cardinality Constraints

Both the minimum and maximum cardinality may be constrained in a way that narrows the range of possible occurrences. Thus, either end of the cardinality range may be set to a new value within the closed range defined by the minimum and maximum values in the source model's range.

Two rules further constrain a cardinality change: (a) the minimum cardinality of the resulting range must be less than or equal to the maximum cardinality; and (b) the maximum cardinality must be greater than or equal to the new minimum cardinality .

Appearance Constraints

V3:

• Mandatory
• Conformance
  • Required
  • Not permitted

Conditional FHIR

• mustSupport: sender and receiver must support it
• Not permitted: 0..0 (see cardinality constraint)

If an element is Required, then all elements that derive from it in derived models SHALL also be Required . If an element is Not Permitted, then all elements that derive from it in derived models SHALL also be Not Permitted. The "Not Permitted" value may also be expressed in a derived model by simply omitting that element from the model. Thus, an attribute or association that is not "Required" in a source model may be omitted from a derived model, thereby creating a de facto declaration of "Not Permitted."

Consequently, an omitted element from a source model cannot be inserted again in derived models.

Type Constraints

Data type substitution was allowed in V3 and data type flavors substitutions are allowed in both V2 and V3. CDA uses templates to create data type flavors and allow similar substitutions.

FHIR add: The following table defines the allowable datatype substitutions when deriving a new model from an existing model. Eg. Datatype quantity substituted by money.

Profile reference to resources change

Questions:

• If you have a reference to resource A may I replace it by a resource B? Not in the general sense.
• An unrestricted type can be replaced by a profile type, and a profile type A can be replaced by another profile B type, if B is a correct restriction of A.
• If a reference can ref A | B | C you can constraint it to a subset, e.g. A | B

Choice Element Constraints

If you have an element value X in obs, multipleBirthX (is a int or boolean), you may constrain to only one of this choices.

One of this choices may also be constrained to a profile version of the same type.

• How to deal with isModifer?
• Vocabulary constraints

Other Value Constraints

• Length: maxlength
• Fixed value
• Default value (if missing)
• Pattern (regex?)
• isSummary ? May I change summary elements of a resource/profile
• Must support

If "must support" is defined as Yes in a profile, a derived profile must also define this as "must support" as Yes.

Annotations

The final group is made up of further explanations to educate prospective users and/or implementers. These are usually used to enhance the descriptions of the elements of the base specification in order to relate them to a particular Context. They do not introduce any new constraints.

Applies to:

• Short desc
• Formal desc
• Synonyms
• Mappings

Invariants and Co-Constraints

FHIR: done by XPATH “constraints”, not easy to determine what the rules would be. This section probably goes into section “Appearance” as this kind of constraints typically influence appearance/cardinality.

Extensions

A very important concept of FHIR is the use of extensions. Due to the 80:20 rules implementers are more or less enforced to introduce their own extensions. This document has to include them into rule set:

• Extensions can be introduced freely into derived profiles.

• Once an extension has been introduced into a derived profile, the fields/attributes become basic elements for this profile, ie. in further derived profiles they are treated as all the other elements.

Other Items Discussed

After this document was put together Ewout Kramer and others came up with a list of items that should be addressed, discussed, and/or added to this document:

• Slicing: a repeating reference allows to constrain the occurrences of to specify subclasses (e.g. Social History requires that the first "SocialHistoryObservation" be a "SmokingStatusObservation" while the other occurrences are not constrained. Weed to align slicing with how it can be done in HL7 Version 3 in C-CDA (as generic conformance statement applicable to repeated occurrences of a base class). HL7 v2 has something like this as well. (HL7 v2 allows to profile repetitions on either the position or a type/value of one component.) In principle is more-or-less the same. Similar to concept of co-occurrence.

• Open EHR has a set of rules similar to what we have been writing. Would like to check that document to see if we can reuse parts of this.

• Would be good to explicitly number the rules so the tool can reference the rule. Seems to be a good idea.

• Discussing meaningWhenMissing and defaultValue.

• Missing discussion about extensions and about excluding extensions.

• An important Use case: I have a CCDA template (id=x) with a set of constraints (x’) that is mapped to FHIR. The mapping represents x as:

{y} a given resource (with a given profile {z}) <union with>  specified extension(s){a(i)} to that profiled resource.> 
Note that the set of extension(s) may need to implement  some of the constraints defined in ccda template x).  
I need to be able to refer to both parts of the FHIR representation of that constrained template) with a single id
I.e. equivalent constraint rules  need to be supported that support tracking  of changes to sets of (a given profile union with specific set of profiled extensions) that are 1:1 mappable from the CCDA (or CDA) template .

• Operation definitions can be based on other operation definitions. Need to look at operations and how they can be derived. Need to support some changes (such as different address types/currency) but not to allow new parameters that might change the operation.

• We have some topics for vocab because not everything is fleshed out in RCnL. Vocabulary binding concepts are so complicated. It will make things easiest if we re-use concepts around vocabulary that we have already developed .

• There are some rules documented here: http://hl7-fhir.github.io/profiling.html