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

## General Requirements

This page documents requirements common to all MII actors in this guide. The conformance verbs - SHALL, SHOULD, MAY - used in this guide are defined in FHIR Conformance Rules.

### MII Conformance Artifacts

The Profiles and Extensions page lists the MII Profiles defined for this implementation guide. MII Profile StructureDefinitions define the minimum elements, extensions, vocabularies, and ValueSets that SHALL be present and constrain how the elements are used when using the profile.

The MII Profile elements include Mandatory and Must Support requirements. Mandatory elements are required and have a minimum cardinality of 1 (min=1). Must Support element Server and Client expectations are defined by MII. The Must Support page defines the Server and Client expectations for processing these element requirements and illustrates how they are displayed and documented.

The Capability Statements page outlines conformance requirements and expectations for MII Servers and Client applications. The MII CapabilityStatements identify the specific profiles and RESTful transactions that need support. The MII Profiles identify the structural constraints, terminology bindings, and invariants. Implementers must refer to the CapabilityStatements for details on the RESTful transactions, specific profiles, and the search parameters applicable to each MII actor.

### Standards and Alignment

The MII core dataset specifications are based, where possible, on international standards and terminologies. In particular, the following standards are highlighted:

- International Patient Summary (IPS) - International standard for patient summaries
- German Base Profiles (Basisprofil DE R4) - Adaptation to the general conditions of the German healthcare system
- KBV FHIR Specifications - Compatibility with specifications from the National Association of Statutory Health Insurance Physicians
- gematik FHIR Specifications - Compatibility with gematik specifications
- ISiK (Informationssysteme im Krankenhaus) - Reference specification for information systems in hospitals

All elements of the core dataset, adapted to the details and requirements for the use cases of the Medical Informatics Initiative, are described below in the form of FHIR StructureDefinitions. The necessity of adapting the FHIR profiles is explained in textual form on each profile page.

### Conformance Verbs

Requirements in this specification are indicated by the following keywords written in capital letters based on RFC-2119:

German | English | Meaning
--- | --- | ---
MUSS / MÜSSEN | MUST / SHALL | Required, mandatory
DARF NICHT / DÜRFEN NICHT | MUST NOT / SHALL NOT | Prohibited
VERPFLICHTEND | REQUIRED | Required by specification
SOLL / SOLLEN | SHOULD | Recommended
SOLL NICHT / SOLLEN NICHT | SHOULD NOT | Not recommended
EMPFOHLEN | RECOMMENDED | Recommended
KANN / OPTIONAL | MAY | Optional

### Claiming Conformance to MII Profiles

#### Profile Support

Systems may deploy and support one or more MII Profiles to represent clinical information. They use the profile's content model without any expectations to implement the MII interactions.

To support an MII Profile:

- Servers SHALL be able to populate all profile data elements that are mandatory and flagged as Must Support as defined by that profile's StructureDefinition§general-1
- Servers SHOULD declare support for an MII Profile by including its official URL in the Server's `CapabilityStatement.rest.resource.supportedProfile` element§general-2
  - The MII profile's official or "canonical" URL is located on each MII profile page

#### Profile Support + Interaction Support

Systems may deploy and support one or more MII Profiles to represent clinical information and support the RESTful interactions defined for those resources.

- A conformant server SHALL be able to populate all profile data elements that are mandatory and/or flagged as Must Support as defined by that profile's StructureDefinition§general-3
- A conformant server SHOULD declare conformance with the appropriate MII CapabilityStatement by including its official URL in the Server's `CapabilityStatement.instantiates` element§general-4
- A conformant server SHALL specify the full capability details from the MII CapabilityStatement it claims to implement§general-5
  - A conformant server claiming interaction support SHALL declare support for the MII Profile by including its official URL in the Server's `CapabilityStatement.rest.resource.supportedProfile` element§general-6
  - A conformant server claiming interaction support SHALL declare support for the MII Profile's FHIR RESTful transactions§general-7

### Using Codes in MII Profiles

The following rules summarize the requirements defined by FHIR Terminology for coded elements (CodeableConcept, Coding, and code datatypes).

#### Required Bindings for Coded Elements

Required binding to a ValueSet definition means that one of the codes from the specified ValueSet SHALL be used. For `CodeableConcept`, which permits multiple codings and a text element, this rule applies to at least one of the codings, and only text is not valid.

- When claiming conformance to a profile with required bindings, Servers SHALL provide at least one code from the bound ValueSet (additional codes from other systems MAY be provided)§general-8
- When claiming conformance to a profile with required bindings, Clients SHALL be capable of processing the code from the bound ValueSet§general-9

#### Extensible Binding for Coded Elements

Extensible binding means that one of the codes from the specified ValueSet SHALL be used if an applicable concept is present. If no suitable code exists in the ValueSet, alternate code(s) may be provided. For `CodeableConcept`, which permits multiple codings and a text element, this rule applies to at least one of the codings. If only text is available and it has no conceptual overlap with the bound coded values, then just text may be used.

- When claiming conformance to a profile with extensible bindings, Servers SHALL provide a code from the bound ValueSet if the concept exists in the ValueSet or an alternative code if the concept does not exist in the ValueSet or text if only text is available§general-10
- When claiming conformance to a profile with extensible bindings, Clients SHALL be capable of processing codes from the bound ValueSet, alternative codes, or text§general-11

#### Using Multiple Codes with CodeableConcept Datatype

Alternate codes may be provided in addition to the standard codes defined in required or extensible ValueSets. These alternate codes are called "additional codings". They may be equivalent to or narrower in meaning than the standard concept code.

For example, a diagnosis may include both an ICD-10-GM code and a SNOMED CT code for international interoperability:

    "code": {
      "coding": [
        {
          "system": "http://fhir.de/CodeSystem/bfarm/icd-10-gm",
          "code": "E11.90",
          "display": "Diabetes mellitus, Typ 2, ohne Komplikationen"
        },
        {
          "system": "http://snomed.info/sct",
          "code": "44054006",
          "display": "Diabetes mellitus type 2"
        }
      ]
    }

### Missing Data

There are situations when information on a particular data element is missing, and the source system does not know the reason for the absence of data. See the Missing Data page for detailed guidance on how to handle missing data in MII profiles.

### FHIR RESTful Search API Requirements

For all supported search interactions in this guide:

- Servers SHALL support the HTTP `POST`-based search§general-12
- Servers SHALL support the `GET`-based search§general-13

When searching using different search parameter types:

- Token search parameters - (how to search by token)
  - For token search parameters, the Client SHALL provide at least a code value and MAY provide both the system and code values§general-14
  - For token search parameters, the Server SHALL support both code-only and system+code token searches§general-15
- Reference search parameters - (how to search by reference)
  - For reference search parameters, the Client SHALL provide at least an id value and MAY provide both the Type and id values§general-16
  - For reference search parameters, the Server SHALL support both id-only and Type+id reference searches§general-17
- Date search parameters - (how to search by date)
  - For date search parameters, the Client SHALL provide values precise to the day for elements of datatype `date` and to the second + time offset for elements of datatype `dateTime`§general-18
  - For date search parameters, the Server SHALL support values precise to the day for elements of datatype `date` and to the second + time offset for elements of datatype `dateTime`§general-19

### Modifier Elements

A FHIR modifier element is an element that modifies the meaning of a resource element. Not all modifier elements are Mandatory or Must Support, and there is no requirement for supporting them. For modifier elements that are Mandatory or Must Support, Servers and Clients SHALL be able to process them.§general-20

FHIR Clients need to be aware of unexpected modifier elements in the data they receive because they can alter the meaning of the data and can potentially lead to errors or even security risks if not properly handled. Unless a Client determines they can process it safely, rejection is typically the only safe action if unexpected modifier elements are present.

Some examples of modifiers that may not be Must Support elements in MII Profiles include:

- `modifierExtension` element common to all profiles
- `Observation.valueQuantity.comparator`
- `Patient.active`

Implementers SHOULD review the profile pages carefully to understand which elements are modifiers and how they affect the interpretation of the resource

For more information, see:

- Must Support - Detailed Must Support requirements
- General Requirements - Additional general requirements
- Missing Data - Guidance for handling missing data
- Capability Statements - Server and Client capability requirements