MII Implementation Guide Core Dataset Base
2026.0.1 - Release
Germany
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
This section defines the conformance requirements for systems implementing the MII Kerndatensatz Basis profiles.
For implementation guidance, see the Guidance section.
For technical artifacts, see the FHIR Artifacts section.
The following table lists all conformance statements (sentences containing SHALL, SHOULD, or MAY) found in the narrative pages of this implementation guide, with links back to their source location.
| Id | Expectation | Rule |
|---|---|---|
| SHALL SHOULD MAY SHALL NOT | ||
| §general-1 | SHALL | 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-2 | SHOULD | Servers SHOULD declare support for an MII Profile by including its official URL in the Server's CapabilityStatement.rest.resource.supportedProfile element |
| §general-3 | SHALL | 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-4 | SHOULD | A conformant server SHOULD declare conformance with the appropriate MII CapabilityStatement by including its official URL in the Server's CapabilityStatement.instantiates element |
| §general-5 | SHALL | A conformant server SHALL specify the full capability details from the MII CapabilityStatement it claims to implement |
| §general-6 | SHALL | 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-7 | SHALL | A conformant server claiming interaction support SHALL declare support for the MII Profile's FHIR RESTful transactions |
| §general-8 | SHALL MAY | 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-9 | SHALL | When claiming conformance to a profile with required bindings, Clients SHALL be capable of processing the code from the bound ValueSet |
| §general-10 | SHALL | 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-11 | SHALL | 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-12 | SHALL | Servers SHALL support the HTTP POST-based search |
| §general-13 | SHALL | Servers SHALL support the GET-based search |
| §general-14 | SHALL MAY | For token search parameters, the Client SHALL provide at least a code value and MAY provide both the system and code values |
| §general-15 | SHALL | For token search parameters, the Server SHALL support both code-only and system+code token searches |
| §general-16 | SHALL MAY | For reference search parameters, the Client SHALL provide at least an id value and MAY provide both the Type and id values |
| §general-17 | SHALL | For reference search parameters, the Server SHALL support both id-only and Type+id reference searches |
| §general-18 | SHALL | 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-19 | SHALL | 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-20 | SHALL | For modifier elements that are Mandatory or Must Support, Servers and Clients SHALL be able to process them. |
| §missing-data-1 | SHALL | If the source system does not have data for an element with a minimum cardinality = 0 (including elements labeled Must Support), the data element SHALL be omitted from the resource. |
| §missing-data-2 | SHALL | If the data element is a mandatory element (minimum cardinality > 0), it SHALL be present even if the source system does not have data or does not know the reason for the absence of data. |
| §missing-data-3 | SHALL | For mandatory non-coded data elements where data is absent, systems SHALL use the DataAbsentReason-Extension with code unknown. |
| §missing-data-4 | SHALL | For mandatory coded elements with example, preferred, or extensible binding where the source has text but no coded value, systems SHALL use only the text element (or display for Coding datatypes). |
| §missing-data-5 | SHALL | For elements with a required binding, if the ValueSet does not have an appropriate "unknown" concept code, you SHALL use a concept from the ValueSet (otherwise the instance will not be conformant). |
| §missing-data-6 | SHALL | For mandatory coded elements with example, preferred, or extensible binding where neither text nor coded data is available, systems SHALL use an "unknown" concept from the bound ValueSet if one exists, or otherwise the unknown code from the DataAbsentReason Code System. |
| §must-support-1 | SHALL | 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-2 | SHALL | 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-3 | SHALL NOT | 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-4 | SHALL | 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-5 | SHOULD | 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-6 | SHALL | For Must Support primitive elements, the Server SHALL be capable of providing the element value. |
| §must-support-7 | SHALL | For Must Support primitive elements, the Client SHALL be capable of processing the element value. |
| §must-support-8 | SHALL | 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-9 | SHALL | For Must Support complex elements, the Client SHALL be capable of processing the Must Support sub-element values. |
| §must-support-10 | SHALL | 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-11 | SHALL | When a Must Support reference element has a single target profile, the target profile SHALL be supported. |
| §must-support-12 | SHALL | 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-13 | SHALL | For Must Support choice elements, the Server SHALL support the datatypes labeled as Must Support. |
| §must-support-14 | SHALL | For Must Support choice elements, the Client SHALL be capable of processing all datatypes labeled as Must Support. |
| §must-support-15 | SHALL | For Must Support slice elements, the Server SHALL be capable of providing data that conforms to the explicitly Must Support-tagged slices. |
| §must-support-16 | SHALL | For Must Support slice elements, the Client SHALL be capable of processing data that conforms to the explicitly Must Support-tagged slices. |