MII Implementation Guide Core Dataset Base
2026.0.1 - Release Germany

MII Implementation Guide Core Dataset Base - Downloaded Version 2026.0.1 See the Directory of published versions

## Must Support

For querying and reading MII Profiles, Must Support on any profile data element SHALL be interpreted as follows:

### Mandatory Elements

Elements of a FHIR resource can be defined in a profile as mandatory or "Must Support". Mandatory elements are elements with a minimum cardinality of 1 (min=1). When an element is mandatory, the data is expected to always be present. In rare cases, data may be missing despite a minimum cardinality of 1. Guidance for cases where data is missing can be found in the Missing Data section.

### Must Support Elements

Resource elements marked as "Must Support" (MS) in a profile must be supported by systems that claim conformance to that particular profile. This is different from cardinality. It is possible to have an element with a minimum cardinality of 0, but still expect systems to support the element.

Support (Must Support) of an element is understood within the MII core dataset specifications as follows:

A distinction is made between data-requesting systems (recipients/clients) and data-providing systems (senders/servers). In the context of the MII infrastructure, the FHIR API of a Data Integration Center (DIZ) is the sending system that accepts requests.

#### Server Expectations

For Must Support elements, the Server SHALL be capable of meaningfully populating the element if the data is locally available, storing it in a resource, and making it retrievable upon request.§must-support-1

The system (sender/server) SHALL be capable of:

- Meaningfully populating a Must Support element with data (e.g., via ETL processes from primary data sources), if the data is locally available
- Storing the element in a resource
- Making it retrievable upon request (e.g., feasibility query)

#### Client Expectations

For Must Support elements, the Client SHALL be capable of displaying the element to the user, considering it for calculations, and processing resource instances containing it without error.§must-support-2

The data-requesting system (recipient/client) SHALL be capable of:

- Displaying the element to the user
- Considering it for further calculations or other processing
- Processing resource instances containing the Must Support data elements without generating an error or causing the application to fail

#### Missing Data

- When information on a particular data element is not present, and the reason for absence is unknown, MII Servers SHALL NOT include the data element in the resource instance returned as part of the query results§must-support-3
- When querying MII Servers, MII Clients SHALL interpret missing data elements within resource instances as data not present in the MII Server's system§must-support-4
- When information on a particular data element is missing, and the MII Server knows the precise reason for the absence of data, MII Servers SHOULD send the reason for the missing information following the guidance in the Missing Data section§must-support-5

### Presentation of Must Support and Mandatory Elements

On each profile page, several different formal views of the profile contents are displayed in a tree format under tabs labeled "Differential Table", "Key Elements Table", and "Snapshot Table".

#### Differential Table View

Elements with a cardinality starting with "1" under the column header "Card." (e.g., 1..1) are Mandatory elements. Elements labeled Must Support in the "Differential Table" view are flagged with an S.

#### Must Support - Primitive Elements

Primitive elements are single elements with a primitive value. For Must Support primitive elements, the Server SHALL be capable of providing the element value.§must-support-6 For Must Support primitive elements, the Client SHALL be capable of processing the element value.§must-support-7

For example, if an element like `Patient.birthDate` is marked as Must Support:

- MII Servers SHALL be capable of providing a value in `Patient.birthDate`
- MII Clients SHALL be capable of processing the value in `Patient.birthDate`

#### Must Support - Complex Elements

Complex elements are composed of primitive and other complex elements. For any complex element marked as Must Support, the Server SHALL be capable of providing the sub-element values that are marked as Must Support. If no sub-elements are marked as Must Support, the Server SHALL be capable of providing at least one sub-element value.§must-support-8 For Must Support complex elements, the Client SHALL be capable of processing the Must Support sub-element values.§must-support-9 When sub-elements of a complex element are marked as Must Support, the support expectation for the parent element is fulfilled by supporting those marked sub-elements.

For example, if `Patient.name` is labeled Must Support and has Must Support sub-elements "family" and "given":

- MII Servers SHALL be capable of providing values in `Patient.name.family` and `Patient.name.given`
- MII Clients SHALL be capable of processing the values in `Patient.name.family` and `Patient.name.given`

On the other hand, if any sub-element is marked as Must Support and the parent element is not, there is no expectation that you must support the parent. However, for Must Support complex elements, if the parent element is represented in the structure but is not itself marked as Must Support, Servers SHALL support the Must Support sub-element(s).§must-support-10

#### Must Support - Resource References

When a Must Support reference element has a single target profile, the target profile SHALL be supported.§must-support-11

For example, if `Condition.subject` references the MII Patient profile and is marked as Must Support:

- MII Servers SHALL be capable of providing a `Condition.subject` with a valid reference to an MII Patient Profile
- MII Clients SHALL be capable of processing a `Condition.subject` with a valid reference to an MII Patient Profile

When a Must Support reference element has multiple target profiles and none are labeled as Must Support, at least one target profile SHALL be supported.§must-support-12

#### Must Support - Choice of Data Types

For Must Support choice elements, the Server SHALL support the datatypes labeled as Must Support.§must-support-13 For Must Support choice elements, the Client SHALL be capable of processing all datatypes labeled as Must Support.§must-support-14

For example, if `Observation.value[x]` has multiple Must Support datatypes:

- MII Servers SHALL be capable of populating the labeled Must Support datatypes (e.g., `valueQuantity`, `valueCodeableConcept`, `valueString`)
- MII Clients SHALL be capable of processing all labeled Must Support datatypes
- Systems MAY support other choice elements, but this is not a requirement

#### Must Support - Slices

FHIR profiles use slicing to define constraints on repeating elements. The element that defines the slicing discriminator ("slicer") may be marked as Must Support, but each slice must be explicitly tagged with the Must Support property to define that slice's conformance requirements. For Must Support slice elements, the Server SHALL be capable of providing data that conforms to the explicitly Must Support-tagged slices.§must-support-15 For Must Support slice elements, the Client SHALL be capable of processing data that conforms to the explicitly Must Support-tagged slices.§must-support-16

For example, if `Identifier` is a Must Support slicer element and defines slices for different identifier types, only the slices explicitly marked as Must Support are required:

- MII Servers SHALL be capable of providing identifiers that conform to the Must Support slices
- MII Clients SHALL be capable of processing identifiers that conform to the Must Support slices
- Systems MAY support other slices, but this is not required

For more information, see:

- General Requirements - Requirements common to all actors and profiles
- Missing Data - Guidance for handling missing data
- Conformance - General conformance requirements