MII Implementation Guide Core Dataset Base
2026.0.1 - Release
Germany
This page is part of the MII Implementation Guide Core Dataset Base (v2026.0.1: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
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.
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.
The MII core dataset specifications are based, where possible, on international standards and terminologies. In particular, the following standards are highlighted:
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.
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 |
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:
CapabilityStatement.rest.resource.supportedProfile element§general-2
Systems may deploy and support one or more MII Profiles to represent clinical information and support the RESTful interactions defined for those resources.
CapabilityStatement.instantiates element§general-4CapabilityStatement.rest.resource.supportedProfile element§general-6The following rules summarize the requirements defined by FHIR Terminology for coded elements (CodeableConcept, Coding, and code datatypes).
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.
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.
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"
}
]
}
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.
For all supported search interactions in this guide:
POST-based search§general-12GET-based search§general-13When searching using different search parameter types:
date and to the second + time offset for elements of datatype dateTime§general-18date and to the second + time offset for elements of datatype dateTime§general-19A 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 profilesObservation.valueQuantity.comparatorPatient.activeImplementers 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: