This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

1.12.1 Conformance

The contents of the resource and the formats used to represent it SHALL conform to the rules described in this specification, as defined in the narrative of the specification, and as controlled by the conformance properties defined below.

Note: This spec uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119.

Because of its general nature and wide applicability, the rules made in this specification are generally fairly loose. As a consequence (unlike RFC 2119), this specification allows that different applications may not be able to be interoperate because of how they use optional features. To allow applications to manage this, FHIR provides a conformance layer that implementers and national/regional programs can use to provide a computable statement about how the resources and their exchange paradigms are used to solve particular use cases. The conformance layer itself is implemented using the following resources:

The specification also provides a number of tools that can assist with enforcing technical conformance to this base specification:

• Schema & Schematron
• Validator Package - use to check resources against profiles
• Reference Platforms (conformant code in various languages)

Note that none of these tools are able to check complete conformance to this specification.

Data elements defined in resources and data types have 3 properties that are directly related to conformance: Cardinality, Is-Modifier, and Must-Support. These interact to place conformance requirements on implementations.

1.12.1.1 Cardinality

All elements defined in FHIR have a cardinality as part of their definition - a minimum number of required appearances, and a maximum number. This number specifies the number of times the element may appear in any instance of the resource type. This specification only defines the following cardinalities: 0..1, 0..*, 1..1, and 1..*. Profiles that describe specific use cases may use other values for cardinality within the limits of the cardinality defined by the resource.

Note that when present, elements cannot be empty - they SHALL have either a value attribute, child elements, or extensions. This means that setting an element to a minimum cardinality of 1 does not ensure that valid data will be present; specific XPath constraints are required to ensure that the required data will be present.

In this specification, very few elements have a minimum cardinality of 1. Resources are used in many contexts, often quite removed from their primary use case, and sometimes even basic information is sometimes very incomplete. For this reason, the only elements that have a minimum cardinality of 1 are those where they are necessary to any understanding of the element that contains them. The minimum cardinalities should not be taken as a guide to what elements are expected to be present in any particular use of the resource, including their normal/primary usage purpose. This specification may publish additional profiles that define which elements are required in which situation, or alternatively, such profiles might be published by jurisdictions, vendors, or projects.

For elements that have cardinality > 1, the order in which they appear may have meaning. Unless the element definition (either in this specification or the extension) defines a meaning to the order explicitly, the meaning of the order is not defined, and implementations are allowed to reorder the elements. Note that it is not possible to define a meaning for the order of the elements in a profile. When there is no definition of the meaning of the order, implementations that need to choose a single element from a list of elements for some use SHALL do so based on the semantics of the content of the elements that repeats. Profiles and Implementation guides may often make rules about this selection process.

1.12.1.2 Is-modifier

Is-Modifier is a boolean property that is assigned when an element is defined, either as part of the base resource contents in this specification, or when profiles declare extensions. An element is labeled "Is-Modifier = true" if the value it contains may change the interpretation of the element that contains it (including if the element is the resource as a whole). Typical examples of elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty". Whether an element is a modifier cannot be changed when element usage is described in a Resource Profile. When an element is labeled as Is-Modifier, the documentation must be clear about why it is a modifier.

A typical example of a modifier element is one that negates the element that contains it. For instance, in the following element definition:

<AdverseReaction xmlns="http://hl7.org/fhir">
 <!-- Other information -->
 <exposureDate value="[dateTime]"/><!-- 0..1 When the exposure occurred -->
 <substance><!-- 0..1 Resource(Substance) Presumed to have caused the reaction --></substance>
 <didNotOccurFlag value="[boolean]"/><!-- 1..1 To say that a reaction to substance did not occur -->
 <!-- Other information -->
</AdverseReaction>

The element "didNotOccurFlag" affects the entire meaning of the resource - if it is set to true, the whole resource must be understood differently, and so it is not safe for implementations to ignore it.

Generally, elements labeled "Is-Modifier = true" also have a minimum cardinality of 1, to introduce certainty in their handling. If the value of such an element is not explicit in the instance, or known by the context, the resource cannot be safely understood. Irrespective of the minimum cardinality, implementations producing resources SHALL ensure that appropriate values for isModifier elements are provided. Is-Modifier elements SHALL be represented in the narrative summary of the resource.

Implementations processing the data in resources SHALL understand the impact of the element when using the data. Implementations are not required to "support" the element in any meaningful way - they may achieve this understanding by rejecting instances that contain values outside those they support (for instance, an application may refuse to accept observations with a reliability != "ok"). Alternatively, implementations may be able to be sure, due to their implementation environment, that such values will never occur. However applications SHOULD always check the value irrespective of this.

Note that processing the data of a resource typically means copying or filtering data out of a resource for use in another context (display to a human, decision support, exchange in another format where not all information is included, or storing it for this kind of use). Servers and background processes that simply move whole resources around unchanged are not "processing the data of the resource", and therefore these applications are not required to check Is-Modifier elements.

1.12.1.3 Must-Support

Labelling an element Must-Support means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way. Exactly what this means is impossible to describe or clarify as part of the FHIR specification.

For this reason, the specification itself never labels any elements as must-support. This is done in Resource Profiles, where the profile labels an element as mustSupport=true. When a profile does this, it SHALL also make clear exactly what kind of "support" is required, as this can mean many things.

Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.